What did you learn today ?

[Chetan_Tiwary_]

Today, I learned about Pod Disruption Budgets (PDBs) in OpenShift. I discovered how PDBs can be used to ensure application availability during maintenance operations or unplanned failures. By setting the minimum number of pods required for an application to function, PDBs can help prevent service disruptions and maintain a high level of resilience.

Pod Disruption Budgets (PDBs) are Kubernetes objects that define the minimum number of pods required for an application to operate without interruption. These disruptions can be planned ( Voluntary Disruptions ) , like scaling or maintenance, or unplanned ( Involuntary Disruptions ), like hardware failures or system crashes.

Also, there are two main incidents involving pod disruptions :

• Node Drain Without PDB: Draining a node forcefully evicts all pods, regardless of their criticality. This can lead to service outages if critical pods are disrupted.
• Node Drain with PDB: When a PDB is in place, the system checks if the node drain would violate the minimum availability requirements. If it would, the drain is delayed or prevented until the requirements are met.

You can define the pod disruption budget resource with either the minAvailable ( The minimum number of pods to be available, even during a voluntary disruption )

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: nginx-min
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: nginx

or the maxUnavailable  (The maximum number of pods that can be unavailable during a voluntary disruption) attribute.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: nginx-max
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app: nginx

https://kubernetes.io/docs/tasks/run-application/configure-pdb/

Every day is an opportunity to learn something new, and the Red Hat Learning Community is a fantastic place to share and discover valuable insights. With modules on various tools and products, there's always something fresh to explore in Red Hat Learning portal. Let's continue to enrich our technical knowledge together.

What have you learned today?

[Trevor]

What did I learn today?   Journald does NOT, be default, save journal entries from
the current and previous boots.

Now, a little bit about journald.

Journald is a component of systemd.

Journald collects and manages journal entries - basically log information from applications and the kernel - from all parts of the Linux system.

By default, journald only stores journal entries for the current boot.

The option that controls whether journald saves previous boot records, is in the
configuration file /etc/systemd/journald.conf file.  The option in that file is Storage=.

Setting the Storage= option to "persistent" will cause journald to store entries from the current and previous boots. This provides the opportunity to display only entries from
the current boot or, from both the current and previous boots.

[Trevor]

What did I learn today - September 14, 2024?
I learned today that - unit files stored in/etc/systemd/system override those from
 /lib/systemd/system that carry the same name.

The basic object that systemd manages and acts upon is a “unit”.

In systemd, a unit refers to any resource that the system knows how to operate on
and manage.

A unit is the primary object that the systemd tools know how to deal with. 

A unit is essentially a configuration file.

The following are the types of unit files available to systemd:

• .service: A service unit describes how to manage a service or application on the server. This will include how to start or stop the service, under which circumstances it should be automatically started, and the dependency and ordering information for related software.
• .socket: A socket unit file describes a network or IPC socket, or a FIFO buffer that systemd uses for socket-based activation. These always have an associated .service file that will be started when activity is seen on the socket that this unit defines.
• .device: A unit that describes a device that has been designated as needing systemd management by udev or the sysfs filesystem. Not all devices will have .device files. Some scenarios where .device units may be necessary are for ordering, mounting, and accessing the devices.
• .mount: This unit defines a mountpoint on the system to be managed by systemd. These are named after the mount path, with slashes changed to dashes. Entries within /etc/fstab can have units created automatically.
• .automount: An .automount unit configures a mountpoint that will be automatically mounted. These must be named after the mount point they refer to and must have a matching .mount unit to define the specifics of the mount.
• .swap: This unit describes swap space on the system. The name of these units must reflect the device or file path of the space.
• .target: A target unit is used to provide synchronization points for other units when booting up or changing states. They also can be used to bring the system to a new state. Other units specify their relation to targets to become tied to the target’s operations.
• .path: This unit defines a path that can be used for path-based activation. By default, a .service unit of the same base name will be started when the path reaches the specified state. This uses inotify to monitor the path for changes.
• .timer: A .timer unit defines a timer that will be managed by systemd, similar to a cron job for delayed or scheduled activation. A matching unit will be started when the timer is reached.
• .snapshot: A .snapshot unit is created automatically by the systemctl snapshot command. It allows you to reconstruct the current state of the system after making changes. Snapshots do not survive across sessions and are used to roll back temporary states.
• .slice: A .slice unit is associated with Linux Control Group nodes, allowing resources to be restricted or assigned to any processes associated with the slice. The name reflects its hierarchical position within the cgroup tree. Units are placed in certain slices by default depending on their type.
• .scope: Scope units are created automatically by systemd from information received from its bus interfaces. These are used to manage sets of system processes that are created externally.

Note:  Units can be of many types, but the most common type is a “service”
(indicated by a unit file ending in .service).