1, pod life cycle
- A Pod can contain multiple containers in which applications run. At the same time, a Pod can also have one or more containers
Multiple Init containers started before the application container.
- The Init container is very similar to an ordinary container, except for the following two points:
- They always run to completion.
- Init containers do not support Readiness because they must run before the Pod is ready.
Each Init container must run successfully before the next one can run.
- If the Init container of the Pod fails, Kubernetes will restart the Pod continuously until the Init container is full
Until the device succeeds. However, if the restart policy value corresponding to Pod is Never, it will not restart
What can the Init container do?
• the Init container can contain some utilities or personalizations that do not exist in the application container during installation
• the Init container can safely run these tools to avoid the security of application images caused by these tools
• the creator and deployer of the application image can work independently without the need to jointly build one
Separate application images.
• the Init container can run in a file system view different from the application container in the Pod. Therefore, the Init container
Can have access to Secrets, but the application container cannot.
• since the Init container must run before the application container starts, the Init container provides a
A mechanism to block or delay the start of the application container until a set of prerequisites are met. Once before
If the conditions are met, all application containers in the Pod will start in parallel.
Create init YML file, init The configuration in yaml is applied to pod
vim init.yml apiVersion: v1 kind: Pod metadata: name: myapp-pod labels: app: myapp spec: containers: - name: myapp-container image: busyboxplus command: ['sh', '-c', 'echo The app is running! && sleep 3600'] initContainers: - name: init-myservice image: busyboxplus command: ['sh', '-c', "until nslookup myservice.default.svc.cluster.local; do echo waiting for myservice; sleep 2; done"] - name: init-mydb image: busyboxplus command: ['sh', '-c', "until nslookup mydb.default.svc.cluster.local; do echo waiting for mydb; sleep 2; done"] kubectl apply -f init.yaml
Show running pod s
vim init.yml apiVersion: v1 kind: Pod metadata: name: myapp-pod labels: app: myapp spec: containers: - name: myapp-container image: busyboxplus command: ['sh', '-c', 'echo The app is running! && sleep 3600'] initContainers: - name: init-myservice image: busyboxplus command: ['sh', '-c', "until nslookup myservice.default.svc.cluster.local; do echo waiting for myservice; sleep 2; done"] - name: init-mydb image: busyboxplus command: ['sh', '-c', "until nslookup mydb.default.svc.cluster.local; do echo waiting for mydb; sleep 2; done"] --- apiVersion: v1 kind: Service metadata: name: myservice spec: ports: - protocol: TCP port: 80 targetPort: 9376 --- apiVersion: v1 kind: Service metadata: name: mydb spec: ports: - protocol: TCP port: 80 targetPort: 9377
Set init The configuration in yaml is applied to the pod, displayed and initialized
kubectl apply -f init.yaml kubectl get pod
The probe is a periodic diagnosis of the container performed by kubelet:
• ExecAction: execute the specified command in the container. If the command code is 0, it will be returned
For successful diagnosis.
• TCPSocketAction: TCP checks the IP address of the container on the specified port. If
If the port is open, the diagnosis is considered successful.
• HTTPGetAction: execute HTTP on the IP address of the container on the specified port and path
Get request. If the status code of the response is greater than or equal to 200 and less than 400, the diagnosis is considered
Each probe will obtain one of the following three results:
• success: the container passed the diagnosis.
• failed: the container failed the diagnosis.
• unknown: the diagnosis failed, so no action will be taken.
Kubelet can choose whether to execute and respond to three probes running on the container:
• livenessProbe: indicates whether the container is running. If the survival probe fails, kubelet
Will kill the container and the container will be affected by its restart policy. If the container does not provide survivability
Needle, the default status is Success.
• readinessProbe: indicates whether the container is ready for service requests. If the ready probe fails, the end
The point controller will delete the IP address of the Pod from the endpoints of all services matching the Pod.
The ready state before the initial delay defaults to Failure. If the container does not provide a ready probe, default
Recognize the status as Success.
• startupProbe: indicates whether the application in the container has been started. If a start probe is provided
(startup probe), all other probes are disabled until it succeeds. If the probe is started
If it fails, kubelet will kill the container, and the container will restart according to its restart policy. If the container does not
If start detection is provided, the default status is Success.
• there is a restartPolicy field in PodSpec, and the possible values are Always, OnFailure and
Never. The default is Always.
• generally, Pod will not disappear until they are artificially destroyed, which may be a person or controller.
• it is recommended to create an appropriate controller to create the Pod instead of creating the Pod yourself. Because alone
Pod can not recover automatically in case of machine failure, but the controller can.
• three available controllers:
• use job to run Pod that is expected to terminate, such as batch calculation. Job is only applicable to restart policy
Pod with OnFailure or Never.
• use ReplicationController, ReplicaSet, and for pods that are not expected to terminate
Deployment, such as a Web server. ReplicationController is only available with
There is a Pod with restartPolicy of Always.
• provide machine specific system services and run a Pod for each machine using the DaemonSet.
Example 1: livenessProbe survival probe
Establish pod and yaml (pod.yml can also be used) documents
apiVersion: v1 kind: Pod metadata: name: pod-example spec: # hostNetwork: true # nodeName: server4 #imagePullSecrets: containers: - name: myapp image: myapp:v1 imagePullPolicy: IfNotPresent resources: requests: cpu: "100m" memory: "50Mi" limits: cpu: "200m" memory: "100Mi" ports: - containerPort: 80 hostPort: 80 livenessProbe: tcpSocket: port: 80 initialDelaySeconds: 1 periodSeconds: 3 timeoutSeconds: 1
First set the retrieved port LivenessProbe Port to 8080
Run and view the pod
kubectl apply -f pod.yaml kubectl get pod -w
Because the port is open at 80, it is not detected that port 8080 is open, so the pod will be restarted all the time, the container will be deleted, and the configuration port will be changed to 80
Rerun pod,yaml, and display as running
Example 2: readinessProbe example of ready probe (with svc)
apiVersion: v1 kind: Pod metadata: name: pod-example spec: # hostNetwork: true # nodeName: server4 #imagePullSecrets: containers: - name: myapp image: myapp:v1 imagePullPolicy: IfNotPresent resources: requests: cpu: "100m" memory: "50Mi" limits: cpu: "200m" memory: "100Mi" ports: - containerPort: 80 hostPort: 80 # - name: busybox # image: busybox:latest # imagePullPolicy: IfNotPresent # tty: true # stdin: true livenessProbe: tcpSocket: port: 80 readinessProbe: httpGet: path: /test.html port: 80 initialDelaySeconds: 1 periodSeconds: 3 timeoutSeconds: 1
Run pod Yaml file and view it. status is not in ready state
At this point, we are in the resource list pod Add labels to yaml
Reset init The configuration in yaml is applied to pod
Create an SVC In yaml resource list, the tag of service selection is the tag of pod example above
vim svc.yaml apiVersion: v1 kind: Service metadata: name: mysvc spec: ports: - protocol: TCP port: 80 targetPort: 80 selector: app: myapp
Reset SVC The configuration in yaml is applied to the service
kubectl describe svc mysvc
Enter the container and create test HTML satisfies the above ready state probe
kubectl exec pod-example -i -t -- sh
ctrl+d returns, and you can see that pod example is ready
mysvc's endpoints also have the ip of pod example
Visit curl 10.107.27.32/test.com html
• autonomous Pod: the pod will not be created after exiting
• Pod managed by the controller: maintain the number of copies of the Pod throughout the life cycle of the controller
• Replication Controller and ReplicaSet
• full name of HPA: Horizontal Pod Autoscaler
Replication Controller and ReplicaSet
• ReplicaSet is the next generation of Replication Controller, which is officially recommended.
• the only difference between ReplicaSet and Replication Controller is selector support, ReplicaSet
Support new set based selector requirements.
• ReplicaSet ensures that a specified number of Pod replicas are running at any time.
• although ReplicaSets can be used independently, today it is mainly used by Deployments to coordinate Pod creation
Create, delete and update mechanisms.
• Deployment provides a declarative definition method for Pod and ReplicaSet.
• typical application scenarios:
- Used to create Pod and ReplicaSet
- Rolling update and rollback
- Expansion and contraction
- Pause and resume
• the daemon set ensures that a copy of a Pod is running on all (or some) nodes. When there is a festival
When you click to join the cluster, you will also add a Pod for them. When a node is removed from the cluster, these
Pod will also be recycled. Deleting a DaemonSet will delete all pods it creates.
• typical usage of daemset:
• run the clustered storage DaemonSet on each node, such as glusterd, ceph.
• run the log collection DaemonSet on each node, such as fluent D and logstash.
• run monitoring DaemonSet on each node, such as Prometheus Node
Exporter, zabbix agent, etc
• a simple usage is to start a daemon set on all nodes, which will be used as each node
Type of daemon.
• a slightly more complex usage is to use multiple daemonsets for each daemon type separately,
However, it has different flags, and has different memory and CPU requirements for different hardware types.
Instance 1: ReplicaSet
The purpose of ReplicaSet is to maintain a stable set of Pod replicas that are running at any time. Therefore, it is usually used to ensure the availability of a given number of identical pods.
vim rs.yaml apiVersion: apps/v1 kind: ReplicaSet metadata: name: replicaset-example spec: replicas: 3 selector: matchLabels: app: myapp template: metadata: labels: app: myapp spec: containers: - name: myapp image: myapp:v1
Run rs.yaml to view the display label
Change the label of one of the containers
kubectl label pod replicaset-example-w7qnj app=nginx --overwrite
Delete a pod with app=myapp and app=nginx. You can see the deletion, but the container with app=nginx has not been created
Specify the number of copies, from 3 to 6
Reapplying the configuration to the pod, you can see that three more copies have been generated
If you change the version from v1 to v2
After closing, re apply the configuration to the Pod and query the replica ip. It can be seen that ReplicaSet ensures that a specified number of Pod replicas are running at any time without updating your version
Example 2: Deployment example
vim deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: deployment labels: app: myapp spec: replicas: 3 selector: matchLabels: app: myapp template: metadata: labels: app: myapp spec: containers: - name: myapp image: myapp:v1
Running and viewing, we can see that Deployment is a more advanced concept. It manages ReplicaSet and provides declarative updates and many other useful functions to Pod
Modify the version myapp:v2. After closing, re apply the configuration to the pod and query the replica ip
Example 3: DaemonSet
Some typical uses of DaemonSet
Run the cluster daemon on each node
Run the log collection daemon on each node
Run the monitoring daemon on each node
vim daemonset-example.yaml apiVersion: apps/v1 kind: DaemonSet metadata: name: daemonset-example labels: k8s-app: nginx spec: selector: matchLabels: name: nginx template: metadata: labels: name: nginx spec: containers: - name: nginx image: nginx
Run and view
Example 3: Jobs
The Job will create one or more Pods and will continue to retry the execution of Pods until the specified number of Pods are successfully terminated. With the successful completion of Pods, the Job tracks the number of successfully completed Pods. When the number reaches the specified threshold number of successes, the task (i.e. Job) ends. Deleting a Job will clear all Pods created. Suspending a Job will delete all active Pods of the Job until the Job is resumed again.
Create a Job Yaml file, run to check the Job
vim job.yaml apiVersion: batch/v1 kind: Job metadata: name: pi spec: template: spec: containers: - name: pi image: perl command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] restartPolicy: Never backoffLimit: 4 kubectl apply -f job.yaml kubectl describe jobs/pi