Table of contents
in previous articles "Atomic scheduling unit in kubernete: pod" As mentioned in the above, if kubernete is compared to the linux operating system, then the pod is a virtual machine, and the container in the pod is the process on the virtual machine. This analogy can be said to be very vivid. On Linux, processes are not completely independent, and there are some associations between some processes, such as a springboot application and a log collection service. Pods are orchestrated using these relationships between container processes.
create pod on kubernete
The following yaml file springboot-mybatis.yaml defines a parameter replicas: 2, which means to create two pods, and image: zjj2006forever/springboot-mybatis:1.2 defines the image that runs the container in the pod.
apiVersion: apps/v1 kind: Deployment metadata: name: springboot-mybatis-deployment spec: selector: matchLabels: app: springboot-mybatis replicas: 2 template: metadata: labels: app: springboot-mybatis spec: containers: - name: spingboot-mybatis imagePullPolicy: IfNotPresent image: zjj2006forever/springboot-mybatis:1.2 ports: - containerPort: 8300
Execute the following command to create these two pod s,
kubectl apply -f springboot-mybatis.yaml
We can see with the command
[root@master k8s]# kubectl get pods --all-namespaces NAMESPACE NAME READY STATUS RESTARTS AGE default springboot-mybatis-deployment-5b78f66997-6fbqk 1/1 Running 0 63s default springboot-mybatis-deployment-5b78f66997-qg5ng 1/1 Running 0 62s
The nature of pod s
pod is a logical concept, not a physical existence. The essence of a pod is that a group of related containers are scheduled together, and these containers can share the network namespace and volume of linux. So why do you need pod s?
Let's take an example, if we have three containers, container1 is a springboot application, container2 is responsible for collecting the logs of container1, and container3 is responsible for analyzing and processing the logs of container2. If we want to deploy these three containers on the same node, each container needs to allocate 1G of memory.
But we currently have 2 nodes, node1 has 2.5G memory, node2 has 3G memory, if there is no pod logic, container1 and container2 are scheduled to node1, but when container3 is scheduled to node1, it finds that there is not enough memory and fails. If we have a pod, we arrange these three containers in a pod, and the pod will be directly scheduled to node2 with 3G memory.
How do the containers in the pod share the namespace? in previous articles "On the flannel network plug-in in kubernete" As mentioned in the article, there is an infra container in the pod, which is always the first to be created when the pod is created. This container image uses k8s.gcr.io/pause, which occupies a very small space, and it is more than 100k after decompression. When the pod starts, the infra container is created first, and the container is used to control the networknamespace, so that other containers can share the network when they start.
How do the containers in the pod share the volume? Or the example of the above three containers, we write a yaml file, the code is as follows:
apiVersion: apps/v1 kind: Deployment metadata: name: springboot-mybatis-deployment spec: selector: matchLabels: app: springboot-mybatis replicas: 2 template: metadata: labels: app: springboot-mybatis spec: volumes: - name: boot-log hostPath: path: /tmp/boot-log containers: - name: spingboot-mybatis imagePullPolicy: IfNotPresent image: zjj2006forever/springboot-mybatis:1.2 ports: - containerPort: 8300 volumeMounts: - name: boot-log mountPath: /logs - name: spingboot-log-accumulate imagePullPolicy: IfNotPresent image: zjj2006forever/springboot-log-accumulate:v1 ports: - containerPort: 8400 volumeMounts: - name: boot-log mountPath: /accumulate - name: spingboot-log-analysis imagePullPolicy: IfNotPresent image: zjj2006forever/springboot-log-analysis:v1 ports: - containerPort: 8500 volumeMounts: - name: boot-log mountPath: /analysis
In the above yaml file, we define 3 containers, namely the application container spingboot-mybatis, log collection spingboot-log-accumulate, log analysis spingboot-log-analysis, we can see from the above file definition, these 3 Each container is mounted with the volum e boot-log, which corresponds to the host directory /tmp/boot-log. In essence, the directory /tmp/boot-log is bound to the above three containers, so the above three containers You can access the binding directory of other containers through this directory. That is, spingboot-log-accumulate can access /logs of spingboot-mybatis, and spingboot-log-analysis can access /accumulate of spingboot-log-accumulate.
So: the essence of a container is actually a collection of containers that share networknamespace and volume.
Key properties of a pod
A pod is the smallest scheduling unit in kubernete. In kubernete, attributes such as scheduling, network, storage, and security are all at the pod level. Let's take a look at several important properties of pod s
apiVersion: apps/v1 kind: Deployment metadata: name: springboot-mybatis-deployment spec: shareProcessNamespace: true hostNetwork: true nodeSelector: hostname: worker1 selector: matchLabels: app: springboot-mybatis hostAliases: - ip: "10.1.2.3" hostnames: - "foo.remote" - "bar.remote" replicas: 2 template: metadata: labels: app: springboot-mybatis spec: containers: - name: spingboot-mybatis imagePullPolicy: IfNotPresent image: zjj2006forever/springboot-mybatis:1.2 ports: - containerPort: 8300 lifecycle: postStart: exec: command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"] preStop: exec: command: ["/usr/sbin/nginx","-s","quit"]
1.shareProcessNamespace represents the shared pid namespace of the pod container, and hostNetwork represents the shared host network
2.NodeSelector represents the binding host label, the host label can be viewed with the following command
[root@master ~]# kubectl get nodes --show-labels NAME STATUS ROLES AGE VERSION LABELS master Ready master 17h v1.17.3 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=master,kubernetes.io/os=linux,node-role.kubernetes.io/master= worker1 Ready <none> 17h v1.17.3 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=worker1,kubernetes.io/os=linux
3.hostAliases defines the host file. After the yaml file above creates a pod, the hosts file in the pod will be added as follows:
/ # cat etc/hosts 10.1.2.3 foo.remote 10.1.2.3 bar.remote
Always: By default, creating pod s always pulls images
Never: never pull
IfNotPresent: Pull when the image does not exist on the host
5.lifecycle: It is a hook that triggers an event when the container changes.
postStart indicates that an operation is triggered when the container starts, which is triggered immediately when the container starts, and does not wait for the container to start to complete.
preStop means that an operation is triggered before the container is killed, and the action of killing the container is executed after the triggering of the operation. For example, eureka can be triggered gracefully here.
The life cycle states of pod s mainly include the following:
Pending: failed to create
Running: The pod was created successfully and at least one container is running
Succeeded: The container in the pod exits normally after running
Failed: At least one container in the pod was not created successfully
pod health check
The yaml file that deployed springboot before modification is as follows:
apiVersion: apps/v1 kind: Deployment metadata: name: springboot-mybatis-deployment spec: selector: matchLabels: app: springboot-mybatis replicas: 2 template: metadata: labels: app: springboot-mybatis spec: containers: - name: spingboot-mybatis imagePullPolicy: IfNotPresent image: zjj2006forever/springboot-mybatis:1.2 ports: - containerPort: 8300 livenessProbe: httpGet: path: /actuator/info port: 18082 initialDelaySeconds: 5 periodSeconds: 5
kubectl apply -f springboot-mybatis.yaml
View container status:
[root@master k8s]# kubectl get pod springboot-mybatis-deployment-dcd7f8bbf-9wfxl NAME READY STATUS RESTARTS AGE springboot-mybatis-deployment-dcd7f8bbf-9wfxl 1/1 Running 3 77s [root@master k8s]# kubectl describe pod springboot-mybatis-deployment-dcd7f8bbf-9wfxl Name: springboot-mybatis-deployment-dcd7f8bbf-9wfxl Namespace: default Priority: 0 Node: worker1/192.168.59.140 Start Time: Fri, 03 Jul 2020 03:56:44 -0400 Labels: app=springboot-mybatis pod-template-hash=dcd7f8bbf Annotations: <none> Status: Running IP: 10.244.1.19 IPs: IP: 10.244.1.19 Controlled By: ReplicaSet/springboot-mybatis-deployment-dcd7f8bbf Containers: spingboot-mybatis: Container ID: docker://19c4082ed706a80c308069ba3355d7192704ad518ced0e075d424bb6ebb16865 Image: zjj2006forever/springboot-mybatis:1.2 Image ID: docker-pullable://zjj2006forever/springboot-mybatis@sha256:bf43bc9d1d4bdb33d82a206282c8f82be3679847d1011806b72e3634ebe67564 Port: 8300/TCP Host Port: 0/TCP State: Waiting Reason: CrashLoopBackOff Last State: Terminated Reason: Error Exit Code: 143 Started: Fri, 03 Jul 2020 03:57:42 -0400 Finished: Fri, 03 Jul 2020 03:58:02 -0400 Ready: False Restart Count: 3 Liveness: http-get http://:18082/actuator/info delay=5s timeout=1s period=5s #success=1 #failure=3 Environment: <none> Mounts: /var/run/secrets/kubernetes.io/serviceaccount from default-token-qk5nc (ro) Conditions: Type Status Initialized True Ready False ContainersReady False PodScheduled True Volumes: default-token-qk5nc: Type: Secret (a volume populated by a Secret) SecretName: default-token-qk5nc Optional: false QoS Class: BestEffort Node-Selectors: <none> Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s node.kubernetes.io/unreachable:NoExecute for 300s Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 85s default-scheduler Successfully assigned default/springboot-mybatis-deployment-dcd7f8bbf-9wfxl to worker1 Normal Killing 28s (x3 over 68s) kubelet, worker1 Container spingboot-mybatis failed liveness probe, will be restarted Normal Pulled 27s (x4 over 84s) kubelet, worker1 Container image "zjj2006forever/springboot-mybatis:1.2" already present on machine Normal Created 27s (x4 over 84s) kubelet, worker1 Created container spingboot-mybatis Normal Started 26s (x4 over 84s) kubelet, worker1 Started container spingboot-mybatis Warning Unhealthy 18s (x10 over 78s) kubelet, worker1 Liveness probe failed: Get http://10.244.1.19:18082/actuator/info: dial tcp 10.244.1.19:18082: connect: connection refused
As can be seen from the following sentence, it failed 3 times. From the above Events, it can also be seen that the process of being deleted and recreated
Liveness: http-get http://:18082/actuator/info delay=5s timeout=1s period=5s #success=1 #failure=3
After the pod health check fails, the pod will be restarted by default, so check the pod status at this time and find that it has been restarted 4 times
[root@master k8s]# kubectl get pods --all-namespaces NAMESPACE NAME READY STATUS RESTARTS AGE default springboot-mybatis-deployment-dcd7f8bbf-9wfxl 1/1 Running 4 7m6s default springboot-mybatis-deployment-dcd7f8bbf-q7nhp 1/1 Running 4 7m6s
1. The restartPolicy of the pod in kubernete is Always by default, that is, as long as the container status is not RUNNING, the container is automatically restarted. In addition, there are OnFailure (automatic restart only when the container is abnormal) and Never (never restart the container).
2. In a pod with multiple containers, the pod will execute restartPolicy only when all the containers are not in the RUNNING state, otherwise the pod state is always RUNNING
3. There are many ways of livenessProbe, such as http, tcp, and you can also execute commands in the container to judge
4. In the yaml file we defined, we define kind: Deployment. If we define kind: pod, we can only restart the pod on the current host, so that if the current host fails, scheduling will always fail. But kind: Deployment can be scheduled to other host nodes in this way.
Pod is the most important concept in kubernete. It is very appropriate to compare a pod to a virtual machine on an operating system and a container in a pod to a process running on a virtual machine. The powerful orchestration function of kubernete, the atomic unit is pod, and pod is the atomic orchestration and scheduling object in kubernete.
WeChat public account, welcome to follow, learn and progress together