Shulou(Shulou.com)06/02 Report--

This article shares with you the content of a sample analysis of the pod life cycle in docker. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

View resource configuration list help

[root@master manifests] # kubectl explain pods.spec.containers # View help

Resource allocation list classification

Autonomous pod resources:

List format of resources:

First-level fields: apiVersion (composed of group/version), kind,metadata (including name,namespace,labels,annotations), spec, status.

Pod Resources-spec.containers

-name:pod name

Image: image name

ImagePullPolicy: means to pull an image from anywhere, Always (regardless of whether there is a local image or not, download the image from the repository, that is, even if there is a local image, you do not use the local image, but download it from the repository), Never (never download an image from the repository, that is, if you have an image locally, you can use it without it), IfNotPresent (use it directly if it exists locally, and download it from the repository only if it does not exist). The default policy is: when the image tag version is latest, the default policy is Always;. If you specify a specific version, the default pull policy is IfNotPresent.

As shown in the figure above, after you specify the ImagePullPolicy policy as ifNotPresent, even if the version specified by image is not latest, every time you start the container, the image will not be downloaded again from the repository.

Ports: specify the port number of the exposure container. You can specify multiple ports, as follows:

[root@master manifests] # cat pod-demo.yaml apiVersion: v1kind: Podmetadata: name: pod-demo namespace: default labels: app: myapp # kv format You can also use curly braces to indicate the hierarchy to which the tier: frontend # definition belongs spec: containers:-name: myapp # the sign preceding it indicates that it is in a list format, or you can use square brackets to indicate image: tomcat ports:-name: http containerPort: 80-name: https containerPort: 443-name: busybox image: busybox:latest imagePullPolicy: IfNotPresent # after specifying that the ImagePullPolicy policy is ifNotPresent, even if the version specified by image does not have latest In the future, every time you start the container, you will not download the image again from the repository: command:-"/ bin/sh"-"- c"-"echo $(date) > > / usr/share/nginx/html/index.html. Sleep 5 "# above command can also be written: command: [" / bin/sh ","-c "," sleep 3600 "]

Args: equivalent to cmd in dockerfile

Command: equivalent to Entrypoint in docker

If neither args nor command is specified, then dockfile's cmd and entrypoint are used by default.

If command is specified but args is not provided, run command directly.

If args is specified, but command is not specified, then the entrypoint command in the image will be used to pass the args we wrote as a parameter to the entrypoint in the image.

If you use both command and args, the cmd and entrypoint in the mirror will be ignored and the command with args provided by K8s will be used.

Reference document: https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/

Label

Tag is a very characteristic management mode of k8s. A tag can correspond to multiple resources, and a resource can have multiple tags, which are many-to-many relationships.

A resource has multiple tags, which can be managed in different dimensions.

The label is in key=value format, and the maximum length of key is 63 characters. It can only be letters, numbers, _, -,. A combination of five types. You can only start and end with a letter or number.

We can also use the tag selector to specify which tags can be used.

You can use the following command to see the label:

[root@master manifests] # kubectl get pods-- show-labelsNAME READY STATUS RESTARTS AGE LABELSpod-demo 1 CrashLoopBackOff 2 CrashLoopBackOff 24 1h app=myapp,tier=frontend

You can use-l to filter pod that contains app tags

[root@master manifests] # kubectl get pods-l app-- show-labelsNAME READY STATUS RESTARTS AGE LABELSpod-demo 1 CrashLoopBackOff 2 CrashLoopBackOff 25 1h app=myapp,tier=frontend

Tag the resource object, and then label the pod-demo pod created earlier as release=canary:

[root@master manifests] # kubectl label pods pod-demo release=canarypod/pod-demo labeled [root@master manifests] # kubectl get pods-l app-- show-labelsNAME READY STATUS RESTARTS AGE LABELSpod-demo 1 CrashLoopBackOff 2 CrashLoopBackOff 27 1h app=myapp,release=canary,tier=frontend

Modify the value of the label:

[root@master manifests] # kubectl label pods pod-demo release=stable-- overwritepod/pod-demo labeled [root@master manifests] # kubectl get pods-l app-- show-labelsNAME READY STATUS RESTARTS AGE LABELSpod-demo 1 CrashLoopBackOff 2 CrashLoopBackOff 27 1h app=myapp,release=stable,tier=frontend

Find objects that have both release tags and app tags:

[root@master manifests] # kubectl get pods-l app,release-- show-labelsNAME READY STATUS RESTARTS AGE LABELSpod-demo 1 CrashLoopBackOff 2 CrashLoopBackOff 27 h app=myapp,release=stable,tier=frontend

The tag selector is divided into two parts: the tag selector of equivalent relation and the tag selector of set relation.

Tag selector for equivalence relationship: you can use = or = to indicate that it is equal to,! = to indicate that it is not equal to:

[root@master manifests] # kubectl get pods-l release=stable-- show-labelsNAME READY STATUS RESTARTS AGE LABELSpod-demo 1 CrashLoopBackOff 2 CrashLoopBackOff 29 2 h app=myapp,release=stable,tier=frontend [root@master manifests] # kubectl get pods-l release=stable,app=myapp-- show-labelsNAME READY STATUS RESTARTS AGE LABELSpod-demo 1 CrashLoopBackOff 30 2 h app=myapp,release=stable Tier=frontend [root@master manifests] # kubectl get pods-l released rabbit stable-- show-labelsNAME READY STATUS RESTARTS AGE LABELSclient 1 Running 0 1d run=clientmyapp-fcc5f7f7c-4x2p7 0 pod-template-hash=977193937 1 ImagePullBackOff 0 1d pod-template-hash=977193937 Run=myappmyapp-fcc5f7f7c-dnkdq 0/1 ImagePullBackOff 0 1d pod-template-hash=977193937,run=myappmytomcat-5f8c6fdcb-7t5s2 1/1 Running 0 1d pod-template-hash=194729876,run=mytomcatmytomcat-5f8c6fdcb-lhcsc 1/1 Running 0 1d pod-template-hash=194729876 Run=mytomcatmytomcat-5f8c6fdcb-rntrg 1/1 Running 0 1d pod-template-hash=194729876,run=mytomcatnginx-deploy-5b595999-fpm8x 1/1 Running 0 1d pod-template-hash=16151555,release=canary,run=nginx-deploy

Tag selector for set relationships: key in (value1,value2...), key notin (value1,value2...),! key

[root@master] # kubectl get pods-l "release in (canary,beta,alpha)"-- show-labelsNAME READY STATUS RESTARTS AGE LABELSnginx-deploy-5b595999-fpm8x 1 Running 0 1D pod-template-hash=16151555,release=canary,run=nginx-deploy [root@master ~] # kubectl get pods-l "release notin (canary,beta) Alpha) "--show-labelsNAME READY STATUS RESTARTS AGE LABELSclient 1 Running 0 1d run=clientmyapp-fcc5f7f7c-4x2p7 0 ImagePullBackOff 0 1d pod-template-hash=977193937,run=myappmyapp-fcc5f7f7c-dnkdq 0 ImagePullBackOff 0 1d pod-template-hash=977193937,run=myapp

We know that both the pod controller and the service are associated by tags, usually using matchLabels,matchExpressions. Many resources support embedded fields to define the tag selector they use.

MatchLabels: give a key value directly, which is equivalent to using an equivalent relation.

MatchExpressions: a tag selector is defined based on a given expression in the format {key! "KEY", operator: "OPERATOR", values: [VAL1,VAL2,....]}. Common operators are:

1) the value of the In,NotIn,:values field must be a non-empty list

2) the value of the Exists,NotExists:values field must be an empty list

Not only pods but also nodes and other objects have tags, as shown below:

[root@master ~] # kubectl get nodes-- show-labelsNAME STATUS ROLES AGE VERSION LABELSmaster Ready master 4d v1.11.2 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=master,node-role.kubernetes.io/master=node1 Ready 4d v1.11.2 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux Kubernetes.io/hostname=node1node2 Ready 4d v1.11.2 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=node2

The above tag is a built-in tag, in which the beta.kubernetes.io part can be parsed in dns, and the length of this part cannot exceed 253 characters.

Similarly, we can tag the nodes, for example, we tag the node1 node as disktype=ssd

[root@master ~] # kubectl label nodes node1 disktype=ssdnode/node1 labeled [root@master ~] # kubectl get nodes-- show-labelsNAME STATUS ROLES AGE VERSION LABELSmaster Ready master 4d v1.11.2 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=master,node-role.kubernetes.io/master=node1 Ready 4d v1.11.2 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,disktype=ssd Kubernetes.io/hostname=node1node2 Ready 4d v1.11.2 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=node2 Node Selector-nodeSelector and nodeName

NodeSelector: you can have pod run on a specified node node, which is demonstrated by the following example.

[root@master] # kubectl get pods-o wideNAME READY STATUS RESTARTS AGE IP NODEclient 1 Running 0 2d 10.244.2.4 node2myapp-fcc5f7f7c-4x2p7 0 ImagePullBackOff 01d 10.244.1. 9 node1myapp-fcc5f7f7c-dnkdq 0/1 ImagePullBackOff 0 1d 10.244.2.6 node2mytomcat-5f8c6fdcb-7t5s2 1/1 Running 0 1d 10.244.2.8 node2mytomcat-5f8c6fdcb-lhcsc 1/1 Running 0 1d 10.244.2.7 node2mytomcat-5f8c6fdcb-rntrg 1/1 Running 0 1d 10.244.1.10 node1nginx-deploy-5b595999-fpm8x 1/1 Running 0 1d 10.244.1.7 node1pod-demo 1/2 CrashLoopBackOff 303 1d 10.244.2.11 node2

Above we see pod-demo running on the node2 node, let's run it on the node1 node next. We just tagged disktype=ssd on node1, so we use nodeSelector to define it in the resource list as follows:

[root@master manifests] # cat pod-demo.yaml apiVersion: v1kind: Podmetadata: name: pod-demo namespace: default labels: app: myapp # kv format You can also use curly braces to indicate the hierarchy to which the tier: frontend # definition belongs spec: containers:-name: myapp # the sign preceding it indicates that it is in a list format, or you can use square brackets to indicate image: tomcat ports:-name: http containerPort: 80-name: https containerPort: 443-name: busybox image: busybox:latest imagePullPolicy: IfNotPresent # after specifying that the ImagePullPolicy policy is ifNotPresent, even if the version specified by image does not have latest In the future, every time you start the container, you will not download the image again from the repository: command:-"/ bin/sh"-"- c"-"echo $(date) > > / usr/share/nginx/html/index.html. Sleep 5 "# above command can also be written: command: [" / bin/sh ","-c " "sleep 3600"] nodeSelector: # specify that the pod runs on a node node with a disktype=ssd tag: disktype: ssd [root@master manifests] # kubectl delete-f pod-demo.yaml pod "pod-demo" deleted [root@master manifests] # kubectl create-f pod-demo.yaml pod/pod-demo created [root@master manifests] # kubectl get pods-o wideNAME READY STATUS RESTARTS AGE IP NODEclient 1/1 Running 0 2d 10.244.2.4 node2myapp-fcc5f7f7c-4x2p7 0/1 ImagePullBackOff 0 1d 10.244.1.9 node1myapp-fcc5f7f7c-dnkdq 0/1 ImagePullBackOff 0 1d 10.244.2.6 node2mytomcat-5f8c6fdcb-7t5s2 1/1 Running 0 1d 10.244.2.8 node2mytomcat-5f8c6fdcb-lhcsc 1/1 Running 0 1d 10.244.2.7 node2mytomcat-5f8c6fdcb-rntrg 1/1 Running 0 1d 10.244.1.10 node1nginx-deploy-5b595999-fpm8x 1/1 Running 0 1d 10.244.1.7 node1pod-demo 2/2 Running 2 37s 10.244.1.14 node1

As you can see above, pod-demo is running on the node1 node with the disktype=ssd tag.

Then someone may ask if we can specify that pod-demo runs on the specified node. Of course, this option is nodeName. You can test it on your own.

Resource annotations annotations

Unlike labels, annotaitons cannot be used to pick resource objects, only to provide raw data for objects. This metadata may be used by some programs and is important. There is no character limit for the key-value pair of annotations.

View the comments for the resource:

[root@master manifests] # kubectl delete-f pod-demo.yaml pod "pod-demo" deleted [root@master manifests] # cat cat pod-demo.yaml cat: cat: No such file or directoryapiVersion: v1kind: Podmetadata: pod-demo namespace: default labels: app: myapp # kv format You can also use curly braces to indicate the hierarchy to which the tier: frontend # definition belongs annotations: chenzx.com/created-by: "cluster-admin" # this is the annotation key value pair spec: containers:-name: myapp # the-sign before indicates that this is a list format You can also use square brackets to indicate image: tomcat ports:-name: http containerPort: 80-name: https containerPort: 443-name: busybox image: busybox:latest imagePullPolicy: IfNotPresent # after you specify that the ImagePullPolicy policy is ifNotPresent Even if the specified version of image is not latest, every time you start the container, you will not download the image of command:-"/ bin/sh"-"- c"-"echo $(date) > > / usr/share/nginx/html/index.html" from the repository. Sleep 5 "# above command can also be written: command: [" / bin/sh ","-c " "sleep 3600"] nodeSelector: # specifies the life cycle of the pod running on the node node with the disktype=ssd tag disktype: ssd [root@master manifests] # kubectl create-f pod-demo.yaml pod/pod-demo created [root@master manifests] # kubectl describe pods pod-demoAnnotations: chenzx.com/created-by=cluster-adminStatus: RunningIP: 10.244.1.15pod

Multiple processes can be run in a container, but usually we only run one process in the container.

You can run multiple containers in a pod, but usually we only run one container in a pod.

Before a container is created, multiple initialization containers (init container) are used to initialize the environment, and when the init container is finished, it exits. The next step is to start the main container (main container), and initialize the environment inside the main container when the main container starts. After the main container has just started, the user can manually embed it to do an operation called post start. You can also do a closing operation pre stop before the main container ends, which is used to do a clean up before the main container ends.

After the post start, a health check is started. The first health check is called survival status check (liveness probe), which is used to check the survival status of the main container. The second health check is called readiness check (readyness probe), which is used to check whether the main container is ready to start.

The status of pod is:

A) Pending: when you start a container and find that the conditions are not met, you will enter the pending state

B) Runing

C) Failed

D) Succeeded

E) Unknown; if the kubelete fails, then the apiserver cannot connect to the kubelete and an unknown error will occur

The process of creating a pod: when the pod is created, it communicates with the apiserver, and then stores the information in the etcd; then the apiserver requests the scheduler and saves the scheduling result in the etcd. If scheduler dispatches the pod to the node1 node, the kublete on the node1 node will get the user-created list from etcd and run the pod on the node1 according to the list. Regardless of the success or failure of pod running on node1, the results are fed back to apiserver and saved in etcd.

Health examination is divided into three levels: 1, directly execute the command; 2, request to tcp connection; 3, send get request to http.

Summary: important behaviors in the pod lifecycle:

1) initialize the container

2) Container probe (liveness surviving row probe and readness readiness probe)

LivenessProbe (Survival State Detection) Survival is not necessarily ready. [root@master manifests] # kubectl explain pods.spec.containers.livenessProbe

You can see that there are three kinds of probes, exec, httpGet, and tcpSocket.

FailureThreshold indicates the number of probe failures. The default is 3 probe failures before it is considered a real failure.

PeriodSeconds: the interval between cycles. It is detected once every 10 seconds by default.

TimeoutSeconds: timeout, which means that a probe is sent, and the other party never responds. How long does it take to wait? by default, wait 1 second.

InitialDelaySeconds: by default, the container starts probing as soon as it starts, but the container may not have been started yet, so the probe must fail at this time. So initialDelaySeconds indicates how long it takes for the container to start probing.

[root@master manifests] # kubectl explain pods.spec.containers.livenessProbe.exec [root@master manifests] # cat liveness.exec.ymal apiVersion: v1kind: Podmetadata: name: liveness-exec-pod namespace: defaultspec: containers:-name: liveness-exec-container image: busybox:latest imagePullPolicy: IfNotPresent # if there is, do not download command: ["/ bin/sh", "- c", "touch / tmp/healthy;sleep 60poliRM-f / tmp/healthy" Sleep 3600 "] livenessProbe: # Survivability probe exec: command: [" test ","-e " "/ tmp/healthy"] #-e indicates whether the probe file exists initialDelaySeconds: 1 # indicates how long the container starts to probe periodSeconds: 3 # indicates that [root@master manifests] # kubectl create-f liveness.exec.ymal pod/liveness-exec-pod created [root@master manifests] # kubectl get pods-wNAME READY STATUS RESTARTS is detected every 3 seconds. AGEliveness-exec-pod 1 Running 2 4m [root@master manifests] # kubectl get pods-wNAME READY STATUS RESTARTS AGEliveness-exec-pod 1 Running 4 6m [root@master manifests] # kubectl get pods-wNAME READY STATUS RESTARTS AGEclient 1 Running 0 3dliveness-exec-pod 1 Running 59 m [root@master manifests] # kubectl get pods-wNAME READY STATUS RESTARTS AGEclient 1 Acer 1 Running 0 3dliveness-exec-pod 1/1 Running 9 23m

You can see that restart is growing over time.

The above example is probed using the exec execution command.

Let's take a look at the options based on tcp and httpget probes.

[root@master manifests] kubectl explain pods.spec.containers.livenessProbe.tcpSocket [root@master manifests] # kubectl explain pods.spec.containers.livenessProbe.httpGet

Here's an example:

[root@master manifests] # cat liveness.httpget.yaml apiVersion: v1kind: Podmetadata: name: liveness-httpget-pod namespace: defaultspec: containers:-name: liveness-httpget-container image: nginx:latest imagePullPolicy: IfNotPresent # do not download ports:-name: http containerPort: 80 livenessProbe: # Survivability Detection httpGet: port: http path: / index.html initialDelaySeconds: 1 periodSeconds: 3 # means to detect [root@master manifests] # kubectl create-f liveness.httpget.yaml [root@master manifests] # kubectl get podsNAME READY STATUS RESTARTS AGEliveness-httpget-pod 1 Running 04m [root@master manifests] # kubectl exec-it liveness-httpget-pod-/ bin/sh# rm-rf / usr every 3 seconds / share/nginx/html/index.html [root@master manifests] # kubectl get podsNAME READY STATUS RESTARTS AGEliveness-httpget-pod 1/1 Running 1 27m

As you can see above, when deleting the / usr/share/nginx/html/index.html,liveness in pod, the index.html file is detected to be deleted, so the number of restarts is 1, but it will only be restarted once and will not be restarted again. This is because after a restart, the nginx container is reinitialized and the index.html file is generated again. So there will be a new index.html file in it.

ReadlinessProbe (ready probe)

[root@master manifests] # cat readiness-httpget.ymal apiVersion: v1kind: Podmetadata: name: readdliness-httpget-pod namespace: defaultspec: containers:-name: readliness-httpget-container image: nginx:latest imagePullPolicy: IfNotPresent # do not download ports:-name: http containerPort: 80 readinessProbe: # prepared probe httpGet: port: http path: / index.html initialDelaySeconds: 1 periodSeconds: 3 # means to detect [root@master manifests] # kubectl create-f readiness-httpget.ymal pod/readdliness-httpget-pod created [root@master ~] # kubectl get podsNAME READY STATUS RESTARTS AGEreaddliness-httpget-pod 1 Running 0 16h [root@master ~] # kubectl exec-it readdliness-httpget-pod-- / bin/sh# every 3 seconds Rm-rf / usr/share/nginx/html/index.html [root@master ~] # kubectl get podsNAME READY STATUS RESTARTS AGEreaddliness-httpget-pod 0 Universe 1 Running 0 16h

As you can see above, ready has become 0 ready 1, but status is runing, which means that the nginx process is there, but the index.html is missing, and it can be determined that the nginx is not ready.

PostStart (post-boot hook) [root@master ~] # kubectl explain pods.spec.containers.lifecycle.postStart

PostStart refers to the operation performed by the container immediately after startup. If the operation fails, the container will be terminated and restarted. Whether to restart or not depends on the restart strategy.

[root@master manifests] # cat poststart-pod.yaml apiVersion: v1kind: Podmetadata: name: poststart-pod namespace: defaultspec: containers:-name: busybox-httpd image: busybox:latest imagePullPolicy: IfNotPresent lifecycle: # Lifecycle events postStart: exec: command: ["mkdir", "- p", "/ data/web/html"] # this command is the command command: ["/ bin/sh") that needs to be executed after defining postStart "- c", "sleep 3600"] # this is the command executed in the definition container But this command comes before command # args in postStart: ["- f", "- h / data/web/html"] #-f is the foreground, and-h is the home directory [root@master manifests] # kubectl create-f poststart-pod.yaml pod/posttart-pod created

Description: method of deletion

[root@master manifests] # kubectl delete-f poststart-pod.yaml pod "posttart-pod" deleted [root@master manifests] # kubectl get podsNAME READY STATUS RESTARTS AGEpoststart-pod 1 Running 03m [root@master manifests] # kubectl exec-it poststart-pod-/ bin/sh/ # ls / dataweb/ # ls / data/web/html/

As you can see above, the / data/web/html directory is established after the container starts. This is the use of postStart.

PreStop (hook before termination) [root@master ~] # kubectl explain pods.spec.containers.lifecycle.preStop

PreStop refers to the commands that the container executes immediately before it terminates, and the container can not terminate until these commands have been executed.

Container restart policy-restartPolicy

Once the container in pod is dead, we restart the container.

The strategy includes the following:

Always: indicates that the container is always restarted after it has hung up. This is the default policy.

OnFailures: restart only when the status of the table container is incorrect, that is, when the container terminates normally

Never: indicates that the container is hung up and does not restart.

For the strategy of Always, as soon as the container dies, it will restart immediately, which is very resource-consuming. So the Always restart strategy is like this: the first time the container is hung up, it will restart immediately, if it hangs again, it will be delayed for 10 seconds to restart, and the third time it will hang up and wait for 20 seconds to restart. And so on.

Termination policy of the container

K8s will give the container 30s to terminate, and if it is not terminated after 30s, it will be terminated forcefully.

Summary pod: apiVersion kind metadata spec status (read-only) spec: containers nodeSelector nodeName restartPolicy: Always,Never OnFailure containers: name image imagePullPolicy: Always 、 Never 、 IfNotPresent ports: name containerPort livenessProbe readinessProbe liftcycle ExecAction: exec TCPSocketAction: tcpSocket HTTPGetAction: httpGet Thank you for reading! This is the end of this article on "sample analysis of the life cycle of pod in docker". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, you can share it for more people to see!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.