Mastering Kubernetes from Scratch: Behind the Scenes of Pod and Deployment

5. Creating a Pod from Scratch

5.1 Steps to Create a Pod

1. Defining Pod

In Kubernetes, you need a YAML file to define the configuration of a Pod, including information about the container's image, resource requirements, ports, and so on. The following is an example of a basic Pod YAML file:

apiVersion: v1
kind: Pod
metadata:
  name: my-first-pod
  labels:
    app: myapp
spec:
  containers:
    - name: nginx-container
      image: nginx:1.24.0
      ports:
        - containerPort: 80

kubectl apply -f 

6. Creating a Deployment from Scratch

While creating a Pod directly is a basic operation in Kubernetes, in practice, most of the time we will use theDeployment Deployment provides more advanced features such as automatic fault repair, rolling updates, load balancing, and scaling replicas, making it a core approach to Kubernetes cluster management.

6.1 Steps to Create a Deployment

1. Define Deployment

Deployment is also defined in a YAML file. Unlike a Pod, a Deployment needs to describe more, such as how many copies of the Pod you want to start, how you want to do updates, what policy you want to choose, and so on.

Here is a basic Deployment YAML fileExample:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3 # Specifies that you want to run the Pod Number of copies
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.24.0
        ports:
        - containerPort: 80

Description:

• apiVersion：apps/v1 is the version of the API used by Deployment.
• kind: Here it is specified asDeployment。
• metadata: Defines the name and label of the Deployment.
• spec: A specific definition of Deployment.
  • replicas: Specify the number of copies of the Pod to start, set to 3 here.
  • selector: Define matching Pod labels to ensure that Deployment manages only specific Pods.
  • template: The template portion of the Pod is almost identical to the YAML file used to create the Pod directly, specifying the container image, port, etc.

2. Submission to the cluster

utilizationkubectl apply -f command commits the Deployment YAML file to the Kubernetes cluster:

kubectl apply -f 

This command commits the Deployment definition to theAPI ServerThe API Server is responsible for validating and saving the Deployment definition.

3. Inspection results

View the status of the Deployment and Pod with the following commands:

kubectl get deployments
kubectl get pods
kubectl describe deployment nginx-deployment

These commands allow you to see how the Deployment and the Pod replicas it manages are performing. You can see that Kubernetes starts multiple replicas and automatically manages the state of these pods.

6.2 How does Deployment manage Pods?

When you create a Deployment, Kubernetes generates the appropriate number of copies of the Pod and manages their lifecycle through the Deployment. If one of the Pods fails, the Deployment immediately starts a new copy of the Pod to replace the failed Pod, so the Deployment can ensure high availability of the application.

Behind the scenes at Deployment

The main difference between creating a Deployment and creating a Pod is that a Deployment does more than just create a Pod, it is also responsible forManaging the Pod Lifecycle. It does this byReplicaSet To ensure a consistent number of Pods, a ReplicaSet is a controller used in Kubernetes to keep a certain number of copies of a Pod always available.

Let's take a look at the exact behind-the-scenes workflow:

1. API Server Receiving Deployment Definition

When you submit a Deployment definition, theAPI Server is responsible for validating the syntax and configuration of the Deployment file and then saving it to theetcd Database.

2. Controller Manager creates the ReplicaSet.

The API Server does this by calling Kubernetes'Controller Manager to create aReplicaSetThe ReplicaSet is the controller and is responsible for maintaining the required number of Pod copies. the ReplicaSet itself is managed by the Deployment, which tells it how many Pod copies it needs to start.

ReplicaSet tasks include:

• Monitor the number of Pod copies: It ensures that a specified number of Pods are always running on the system. for example, if the Deployment requires 3 replicas, the ReplicaSet will check that the actual number meets the requirement.
• Creating a New Pod: If a Pod hangs up or needs to expand its replica, the ReplicaSet creates a new Pod.

3. Scheduler Scheduling Pod

The ReplicaSet is responsible for creating Pods, but these Pods are ultimately created by Kubernetes'Scheduler The Scheduler selects the most appropriate node to run the Pod based on the node's resource status.

4. Kubelet Launches the Pod

After the Scheduler identifies the node, the node'sKubelet Kubelet works with a container runtime (such as Docker or containerd) to pull the container image and start the container.

5. Automatic fault recovery

If a Pod hangs for some reason, Kubelet sends a message to theController Manager Reports on the status of the Pod. the ReplicaSet monitors that there are not enough replicas and immediately creates a new Pod to ensure that the total number of replicas meets the Deployment's requirements. This is how Deployment's automatic failback works.

6. Rolling update

Deployment also supportsRolling updates, which is one of its powerful features. Rolling updates allow you to upgrade the container image without affecting the normal operation of your application. For example, when you want to move thenginx:1.24.0 update tonginx:1.19 This approach ensures high application availability.

Rolling updates are possible with the following command:

kubectl set image deployment/nginx-deployment nginx=nginx:1.19

At this point, the Deployment starts a new copy of the Pod and terminates the old Pod when the new Pod is up and running correctly.This process is done incrementally and does not result in service interruptions.

6.3 Key Differences Between Deployment and Pods

7. Pod and Deployment Collaboration: From Single Pod to Mass Deployment

realizePod and Deployment CollaborationThe Pods can be compared to ships and commanders in a fleet of ships. A Pod is like a small ship, capable of performing a specific task; while aDeployment It's the commander of the fleet who is responsible for managing all the ships, making sure they are always sailing according to plan, and responding quickly when problems arise.

7.1 From a Single Pod to a Large-Scale Cluster

Small-scale applications: one ship does it all

In simple scenarios, such as when you want to quickly test an application or deploy some simple service, theOne Pod is all you need.A Pod is the smallest unit of compute in Kubernetes that encapsulates resources such as containers, storage, and networking to allow your application to run properly. In this scenario, you probably don't need a complex deployment, just a single Pod running on a node.

Example: Assuming you want to run a Nginx container as a web server, the simplest action is to create a Pod containing the Nginx container, like this:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx:1.24.0
    ports:
    - containerPort: 80

This YAML file defines a Pod, which starts a Nginx container listening on port 80, and acts as a small boat, performing tasks on its own.

Large-scale application: summoning the fleet!

But in reality, most apps don't rely on just one Pod. Imagine your app is suddenly flooded with thousands of users, and one small boat can't handle it. You need more boats - more Pods to spread the load. SoDeployment It came in handy.

Deployment Allows you to specify the number of Pods you want to run and automatically manage their lifecycle. Whether you need 5, 50, or even 500 Pods, Deployment helps you quickly and automatically distribute them across multiple nodes for large-scale deployments.

With Deployment, you can control a large fleet as easily as you can manage soldiers.

7.2 How do Pod and Deployment work together?

Pod cap (a poem)Deployment The two parts of Kubernetes are inextricably intertwined. Simply put, Pods are the basic execution units of computation, and Deployment is the chain of command responsible for managing these Pods. The relationship between the two is like that of a soldier and a commander:

Pod: Soldier, responsible for carrying out tasks

Pods do not inherently have advanced features such as auto-repair or scaling. It can run one or more containers that handle specific tasks, such as responding to user requests, processing data, or performing compute tasks.Pods are the most basic compute unit in Kubernetes, but they have a short lifecycle and are susceptible to hardware failures or network problems.

Deployment: Commander to ensure consistency and high availability

Deployment is responsible for managing the lifecycle of a Pod, ensuring that all Pods are always in a healthy state. If a Pod hangs, Deployment quickly starts a new Pod to replace it, so you don't have to worry about individual Pods failing and causing service outages. This way, you don't have to worry about individual Pods failing and causing service interruptions, and Deployment makes it easy to scale your application, for example, from 3 to 30 Pods, by simply changing the number of replicas in your YAML file.

Example:
You want to run 5 Nginx web servers through Deployment and make sure they are always online. Then you can define a Deployment file with the following contents:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 5
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.24.0
        ports:
        - containerPort: 80

What's going on behind the scenes?

1. API Server first receives your Deployment definition and then stores it in theetcd In the database.
2. Controller Manager Check to see if there is a match to the Deployment definition.ReplicaSetIf not, it creates a ReplicaSet.
3. ReplicaSet is a controller created by Deployment that is responsible for ensuring that a specified number of Pods are running at all times. If you define 5 replicas, ReplicaSet starts 5 Pods and monitors their status.
4. Scheduler Decide on which nodes these Pods should run on and notify those nodes of theKubelet。
5. Kubelet Start the Pod on the appropriate node, pull the Nginx container image and start the service.

The Deployment monitors the status of all Pods, and as soon as a Pod fails, it starts a new Pod as a replacement. In this way, your web services will always be highly available.

Pod and Deployment Collaboration for Efficient Deployment

To summarize, Pods are the most basic units of compute in Kubernetes, suitable for simple, short-term tasks, while Deployment is the advanced controller that manages Pods and ensures features such as high availability, auto-scaling, and rolling updates. With Deployment, you can easily scale from a single Pod to a large-scale cluster, ensuring that your applications run efficiently and reliably in any situation.

• Pod is the executor.: Responsible for specific calculation tasks.
• Deployment is the commander.: Responsible for scheduling and managing multiple Pods to ensure consistency and high availability.

8. Behind the scenes: how Kubernetes schedules and manages resources

In the world of Kubernetes, scheduling and resource management are at the core of its efficient operation. Think of it as a super-smart "traffic controller" and "resource manager" that is busy sending hundreds of Pods to the right nodes to do their work every day. It's not just making sure that each Pod has the right node for the job. Not only does it make sure that every Pod finds a home, but it also makes sure that each server's resources are not wasted or overused. how does the mechanism behind Kubernetes work? Let's take a closer look!

8.1 Scheduler operation

Thescheduler is the core component responsible for arranging each Pod to run on the appropriate node. Its task is like that of a seating planner in a restaurant, who not only looks at which tables are empty, but also takes into account whether guests have special needs (such as needing a window seat or a specific menu).

The scheduler takes many factors into account when scheduling Pods:

• Resource situation of the node
  The scheduler first looks at the resources of each node, such as theCPU、random access memory (RAM)、storage spaceand so on is sufficient. If a node is already strapped for resources, it will not schedule a new Pod to that node, but will choose an idle node instead.

  For example, if you have a Pod that requires 2 CPU cores and 1 GB of RAM to run, the scheduler will look for a node with enough resources to make sure that the Pod doesn't crash due to lack of resources.

• Pod requirements
  Some Pods may have special requirements, such as having to run on a computer with theGPU on the node, or need to access a specific type of storage device. The scheduler will filter the appropriate nodes based on these requirements.

  For example, if you have a machine learning task that requires GPU acceleration, the scheduler will assign the Pod to a node that has a GPU instead of letting it run on a regular node.

• Labeling and tainting of nodes
  Nodes in Kubernetes can be tagged with differenttab (of a window) (computing) Or setStains (taints), which is used to distinguish the function or purpose of a node. The scheduler can define a node according to the Pod's definition (via theAffinity rules cap (a poem)tolerance level) determines whether to schedule certain Pods to these particular nodes.

  For example, you may have some high-performance computing tasks that are only allowed to run on nodes labeled "high-performance," and the scheduler will specifically look for those nodes to place your Pod on.

What happens behind the scenes:

1. API Server Receives your Pod creation request and stores the Pod information in theetcd In the database.
2. Scheduler Start the job by scanning the resource status of all nodes and the requirements of each Pod to filter out the eligible nodes.
3. Once a suitable node is found, the scheduler assigns this node to the Pod and then informs theKubelet to start the Pod.

In this way, the scheduler not only ensures that each Pod finds a suitable node to run on, but also balances the load on each node within the cluster to avoid wasted or overused resources.

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: my-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-deployment
  minReplicas: 2
  maxReplicas: 10
  targetCPUUtilizationPercentage: 70

• The above configuration means that Kubernetes automatically scales between 2 and 10 replicas when a Pod's CPU utilization exceeds 70%.

Rationalization of probes

Health check probes are an important tool to ensure that your application is running properly, and properly configured can greatly improve application stability. If the probes are not configured properly, the pod may restart frequently or even incorrectly assume that a healthy pod is not healthy.

• Optimization Recommendations: Configure each Pod with the appropriateLiveness Probe cap (a poem)Readiness ProbeThe Liveness Probe ensures that the application's processes are not stuck, while the Readiness Probe ensures that the application is ready to process requests.

  Liveness Probe Example： 

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5