EN_K8s_Operations

Kubernetes Operations

16. Kubernetes Graceful Shutdown

In Kubernetes, configuring Graceful Shutdown and handling SIGTERM and SIGKILL signals play an important role in managing resources and preventing data loss when containers are terminated. Each concept is explained as follows:

terminationGracePeriodSeconds

When a Pod is terminated, Kubernetes sends a SIGTERM signal to the Pod and waits before forcefully terminating the Pod with SIGKILL.

• terminationGracePeriodSeconds is an option to set the Grace Period, which gives the container that received SIGTERM time to terminate gracefully.
• The default value is 30 seconds, and if the container is not terminated within this time, Kubernetes forcefully sends a SIGKILL to terminate the container.
• This setting allows services to safely perform cleanup operations (e.g., closing connections, saving state) without interrupting requests.

spec:
  terminationGracePeriodSeconds: 60 # Give the Pod a grace period of 60 seconds before receiving a SIGKILL.

preStop Hook

preStop is a Kubernetes Lifecycle Hook that specifies a command or script to be executed when a Pod is terminated. When a Pod receives a SIGTERM signal, this preStop hook is executed first, and after the configured actions are completed, the container starts its termination process.

• You can use this hook to perform tasks such as notifying external services or cleaning up logs before termination.
• The preStop hook runs before the SIGTERM signal is processed, allowing some preparation before the container starts its Graceful Shutdown.

lifecycle:
  preStop:
    exec:
      command: ["/bin/sh", "-c", "sleep 10"] # Wait 10 seconds before terminating the container.

• By using the preStop hook to delay for 10 seconds, the container waits before it begins handling SIGTERM. After this time, it can still use the remainder of terminationGracePeriodSeconds to finish cleanup tasks.

SIGTERM (Terminate Signal)

• SIGTERM is a signal that sends a graceful shutdown request to a container or process.
• Applications that support Graceful Shutdown need to capture and handle this signal, which can trigger tasks such as closing open connections or completing the current work.
• In Kubernetes, SIGTERM is sent first when a Pod is terminated. Upon receiving this signal, the application can proceed with cleanup operations for a graceful termination.

SIGKILL (Kill Signal)

• SIGKILL is a force kill signal that immediately terminates a process or container.
• This signal stops the process without allowing for cleanup operations, which can result in data loss or broken connections.
• In Kubernetes, if a container is not terminated within terminationGracePeriodSeconds, SIGKILL is sent to force the container to terminate.

Graceful Shutdown Flow Summary

1. When a Pod termination request occurs, Kubernetes first sends a SIGTERM signal to the corresponding Pod.
2. If a preStop hook is defined, it is executed, preparing the application for the SIGTERM signal.
3. The application processes the SIGTERM signal within terminationGracePeriodSeconds, performing any necessary cleanup tasks.
4. If the container is not terminated within terminationGracePeriodSeconds, Kubernetes sends a SIGKILL to force the container to terminate.

graph LR
    A[Pod termination request] --> B[SIGTERM sent to Pod]
    B --> C{preStop hook defined?}
    C -- Yes --> D[Execute preStop hook]
    D --> E[SIGTERM signal handled by application]
    C -- No --> E
    E --> F[Graceful shutdown within terminationGracePeriodSeconds]
    F -->|Success| G[Pod terminates cleanly]
    F -->|Timeout| H[SIGKILL sent to force termination]

Loading

---

17. Kubernetes imagePullPolicy

In Kubernetes, imagePullPolicy is a setting that controls how and when container images are pulled from the container registry. This is configured for each container in the Pod specification and determines whether Kubernetes should pull the image from the registry or use a locally cached version. There are three main imagePullPolicy values:

• Always
• IfNotPresent
• Never

Always

• Kubernetes always pulls the image from the registry whenever a Pod is created, even if the image already exists on the node.
• This is useful if you frequently update images in your container registry without changing the image tag (e.g., using the 'latest' tag or a fixed tag for continuous deployment).

IfNotPresent

• Kubernetes pulls the image from the registry only if the image is not yet on the node. If the image exists locally, it uses the cached version.
• This is the default policy if a specific image tag (other than 'latest') is used. It helps reduce the time and bandwidth required to pull the image if the same image is already available on the node.

Never

• Kubernetes does not pull the image from the registry and expects the image to already exist on the node.
• This is useful in environments where you manually preload container images on nodes or want to avoid pulling images from external sources.

Preferences

• Use the latest tag: When you use the latest tag, Kubernetes defaults to setting the image pull policy to Always.
• Use other tags: If you specify a tag that is not the latest tag, Kubernetes defaults to IfNotPresent.

---

18. Kubernetes Deployment Strategy

In Kubernetes, deployment strategies define how to update a Pod (or set of Pods) when deploying a new application version or container image. There are two main deployment strategies:

• RollingUpdate (default strategy)
• Recreate

RollingUpdate (default)

• RollingUpdate is the default and most widely used strategy in Kubernetes. It gradually updates Pods within a deployment.
• During a rolling update, Kubernetes creates new versions of Pods while simultaneously terminating older Pods in small batches. Downtime is minimal as some Pods continue to run during the process.
• This strategy is ideal if you need to maintain high availability.

Key configuration options:

• maxUnavailable: Specifies the maximum number (or percentage) of Pods that can be unavailable during the update. For example, maxUnavailable: 25% means that up to 25% of Pods may go down during an update.

• maxSurge: Specifies the maximum number (or percentage) of additional Pods that can be temporarily created beyond the desired number of replicas. For example, maxSurge: 1 means that one additional Pod can be created temporarily during an update.

• Advantage: Updates and deploys new Pods incrementally, so there is no service downtime.

• Use case: Ideal for production environments that require continuous availability during updates.

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

Recreate

• In the Recreate strategy, Kubernetes deletes all existing Pods before creating new ones.

• This strategy ensures that old applications are fully stopped when a new version is deployed.

• Advantages: Simple; terminates all existing instances before cleanly deploying the new version.

• Disadvantages: All Pods are terminated until new Pods are created, resulting in downtime.

• Use case: Suitable for applications where short downtime is acceptable or where the previous version must be fully stopped before deployment.

spec:
  strategy:
    type: Recreate

---

Reference

• ← Back to EN_Kubernetes