Brief description of POD creation and deletion

The process of creating a Pod can be divided into the following steps:

• Users send a request to create a Pod to the API server using the kubectl create command or a YAML file.
• The API server converts the request into an internal Kubernetes object and sets the Pod’s status to Pending.
• The scheduler schedules the Pod to the appropriate node based on the resource requirements of the Pod and the resource status of the node.
• The kubelet on the node receives the Pod scheduled by the scheduler and sets its status to Running.
• kubelet creates containers for Pods and allocates resources to the containers.
  The container starts and starts running.

Vernacular explanation:

The user says to the API server: "I want to create a Pod."
The API server converts the user's words into Kubernetes' internal language and tells the scheduler: "This Pod is about to be created."
The scheduler tells kubelet about this, and kubelet starts preparing to create Pods.
kubelet creates containers for Pods and allocates resources to the containers.
The container starts and starts running.

User->>API Server: Submit Pod creation request
  API Server->>Scheduler: Convert Pod Creation Request
  Scheduler->>Node: Schedule Pod
  Node->>kubelet: receive Pod
  kubelet->>container: Create container
  Container->>: start

When you delete a Pod, Kubernetes performs the following steps:

• 1. Users use the kubectl delete command or YAML file to send a request to the API server to delete a Pod.
• 2. The API server converts the request into an internal Kubernetes object and sets the Pod’s status to Terminating.
• 3. The scheduler sets the Pod’s status to Terminating.
• 4. The kubelet sets the Pod’s status to Terminating and sends a SIGTERM signal to each container in the Pod to notify the container to prepare to exit.
• 5. The container exits within the specified timeout. If the container does not exit within the timeout period, kubelet will send the SIGKILL signal to the container to force the container to exit.
• 6. kubelet deletes Pod-related resources, including Pod definitions, container images, container logs, etc.

• etcd is the core component of the Kubernetes cluster and is responsible for storing all Kubernetes data. When deleting a Pod, etcd needs to perform the following operations:

• 1. Delete Pod definition.
• 2. Delete Pod-related resources, including container images and container logs.

Vernacular explanation

* The user says to the API server: "I want to delete a Pod."
* The API server converts the user's words into Kubernetes' internal language, and then tells the scheduler: "This Pod is going to be deleted."
* The scheduler tells kubelet about this, and kubelet tells the containers in the Pod: "You are going to be deleted."
* When the container hears the kubelet's words, it begins to prepare to exit. If the container does not exit within the specified time, kubelet will force it to exit.
* After the container exits, kubelet will delete all Pod-related resources.

etcd is the notepad of Kubernetes, responsible for remembering all Kubernetes information. When deleting a Pod, etcd will delete all relevant information about the Pod.

• Pods in Kubernetes follow a predefined life cycle, which consists of the following stages:

• Pending: The Pod has not yet been scheduled to any node.
• Running: The Pod has been scheduled to a node and all containers are up and running.
• Succeeded: All containers in the Pod have terminated successfully.
• Failed: At least one container in the Pod has failed.
• Unknown: The status of the Pod cannot be determined.

Pending stage

In the Pending stage, the Pod has not yet been scheduled to any node. There may be several reasons why a Pod is in this stage:

• The Pod has not been created by the user yet.
• The Pod has been created, but the scheduler has not yet scheduled it to any node.
• The Pod has been scheduled to a node, but the node is not ready to run the Pod.

Running Phase

In the Running phase, the Pod has been scheduled to a node and all containers are up and running. A Pod may be in this phase for a long time until the Pod is terminated.

Succeeded stage

In the Succeeded phase, all containers in the Pod have terminated successfully. There could be several reasons why a Pod is in this stage:

• The Pod definition contains the terminationGracePeriodSeconds field, and the timeout specified in this field has expired.
• The definition of Pod contains the restartPolicy field, and the policy specified by this field is Never.

Failed stage

In the Failed stage, at least one container in the Pod has failed. There could be several reasons why a Pod is in this stage:

• The definition of Pod contains the restartPolicy field, and the policy specified by this field is Always or OnFailure.
• The Pod’s definition contains the terminationGracePeriodSeconds field, and the timeout specified by this field has elapsed, but the containers in the Pod have not terminated successfully.

Unknown Stage

In the Unknown stage, the status of the Pod cannot be determined. There could be several reasons why a Pod is in this stage:

• The definition of Pod contains the restartPolicy field, and the policy specified by this field is Never.
• The Pod definition contains the terminationGracePeriodSeconds field, and the timeout specified in this field has passed, but the Pod has not yet been scheduled to any node.

Pod’s state transition

A Pod’s state may transition from one stage to another. The following are possible Pod state transitions:

• Pending -> Running: The Pod has been scheduled to a node and all containers have been started.
• Running -> Succeeded: All containers in the Pod have terminated successfully.
• Running -> Failed: At least one container in the Pod has failed.
• Pending -> Unknown: The definition of Pod contains the restartPolicy field, and the policy specified by this field is Never.
• Running -> Unknown: The Pod definition contains the terminationGracePeriodSeconds field, and the timeout specified in this field has passed, but the Pod has not yet been scheduled to any node.

Control the state of Pods

You can use the Kubernetes API or command line tools to control the status of Pods. Use the kubectl delete command to terminate the Pod.

You can also use the Pod’s restartPolicy field to control whether the Pod is restarted upon failure. If you set the restartPolicy field to Never, the Pod will not restart on failure.

Deployment and ReplicaSet are both objects used in Kubernetes to manage Pod replicas. Their main differences are:

• **Deployment is a higher level abstraction. **It provides some features that ReplicaSet does not have, such as:
  • Rolling updates: Deployments can automatically roll over Pod replicas without impacting application availability.
  • Rollback: Deployments can automatically roll back to previous versions.
  • Scaling: Deployment can automatically scale the number of Pod replicas.
• **ReplicaSet is a simpler object. **It is only responsible for managing the number of Pod copies.

Kubernetes versions 1.28.x still support ReplicaSets. However, new versions of Kubernetes recommend using Deployments to manage Pod replicas. Deployments provide functionality not found in ReplicaSets to simplify application deployment and management.

Here are the specific uses of Deployment and ReplicaSet:

• **Deployment is suitable for applications that require rolling updates, rollbacks, and scaling. **For example, web applications, microservices, etc.
• **ReplicaSet is suitable for applications that do not require rolling updates, rollbacks, and scaling. **For example, batch applications, databases, etc.

The specific choice of object needs to be decided based on the actual needs of the application.

The main reasons why StatefulSet is slow to update Pods are as follows:

• **The update strategy of StatefulSet is rolling update. **During the rolling update process, StatefulSet updates Pods one by one and deletes old Pods from the cluster. This results in unavailable time for the application.
• **StatefulSet’s storage volume is persistent. **When updating a Pod, StatefulSet needs to copy the storage volume data of the old Pod to the new Pod. This can cause the update process to slow down.

The reason why StatefulSet is still slow to update Pods without storage is that StatefulSet still needs to delete old Pods from the cluster. This results in unavailable time for the application.

Here are some suggestions to improve the speed of StatefulSet updates:

• **Use custom update strategy. You can use the “pause updates” policy to pause the application before updating all pods.
• **Use snapshot storage. **Snapshot storage can speed up the replication of storage volume data.
• **Use replicated Pods. **Replicating Pods can improve application availability.