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: 8300Execute 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: /analysisIn 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
4.ImagePullPolicy
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
Unknown: exception
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: 5start pod
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 refusedAs 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
Notice:
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.
Summarize
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
