Self-study series for Kubernetes certification exam

Book source: "CKA/CKAD Test Guide: From Docker to Kubernetes Complete Raiders"

Organize the reading notes while studying, and share them with everyone. If the copyright is violated, it will be deleted. Thank you for your support!

Attach a summary post: Kubernetes certification exam self-study series | Summary_COCOgsta's Blog-CSDN Blog

5.4.1 Understanding initialization containers

Before running container C1, you need to do some preparatory work, so that container C1 can work normally, so you can run container A, container B, etc. to do some preparatory work before running container C1. After completing these preparations, and then running container C1, container A and container B can be configured as the initialization containers of container C1. The common container C1 can run only when all the initialization containers are running correctly, as shown in Figure 5-10.

If any initialization container fails to run, the normal container C1 will not run. If multiple initialization containers are defined, once an initialization container fails to execute, subsequent initialization containers will not be executed (in the order defined in the yaml file).

The initialization container is defined in initContainers, which is aligned with containers.

5.4.2 The first example of initializing a container

This example implements modifying the kernel parameters of the physical machine by initializing the container.

Step 1: Create the yaml file podinit.yaml for initializing the container, the content is as follows.

[root@vms10 pod]# cat podinit.yaml 
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: pod3
  name: pod3
spec:
  containers:
  - image: nginx 
    name: c1
    imagePullPolicy: IfNotPresent
    resources: {}
  initContainers:
  - image: docker.io/alpine:latest
    name: xx
    imagePullPolicy: IfNotPresent 
    command: ["/bin/sh", "-c", "/sbin/sysctl -w vm.swappiness=10"]
    securityContext:
      privileged: true 
    resources: {}
  dnsPolicy: ClusterFirst 
  restartPolicy: Always 
status: {}
[root@vms10 pod]#
复制代码

There are two containers in pod3 defined here, an initialization container xx and a normal container c1. The image used in the initialization container is alpine. After it runs, the value of the kernel parameter vm.swappiness is changed to 0. It seems that the initialization container xx modifies its own kernel parameters, in fact, it modifies the kernel parameters of the physical machine where the pod is located.

The normal container c1 will only run after the init container has finished running correctly and exited.

Step 2: First determine the value of swappiness on the two machines.

[root@vms11 ~]# cat /proc/sys/vm/swappiness
30
[root@vms11 ~]#
[root@vms12 ~]# cat/proc/sys/vm/swappiness 
30
[root@vms12 ~]#
复制代码

Step 3: Create an initialization pod.

[root@vms10 pod]# kubectl apply -f podinit.yaml 
pod/pod3 created 
[root@vms10 pod]#
复制代码

Step 4: Check the running status of the pod.

[root@vms10 pod]# kubectl get pods
NAME     READY   STATUS            RESTARTS     AGE 
pod3      0/1    PodInitializing     0          2s
[root@vms10 pod]#
[root@vms10 pod]# kubectl get pods
NAME     READY   STATUS            RESTARTS     AGE  
pod3      1/1    Running             0          4s
[root@vms10 pod]#
复制代码

The pod is now running normally.

Step 5: Check which machine the pod is running on.

[root@vms10 pod]# kubectl get pods -o wide
NAME   READY    STATUS    RESTARTS   AGE       IP            NODE          ...
pod3    1/1     Running      0       23s   10.244.14.15   vms12.rhce.cc    ...
[root@vms10 pod]# 
复制代码

The pod is running on vms12.rhce.cc.

Step 6: View the parameter value of swappiness on the two machines.

[root@vms11 ~]# cat /proc/sys/vm/swappiness
30
[root@vms11 ~]#
[root@vms12 ~]# cat /proc/sys/vm/swappiness
10
[root@vms12 ~]#
复制代码

Because pod3 is running on vms12, the initialization container first modifies the kernel parameters on vms12, and then starts to create the normal container C1 after the modification is successful. Finally, it can be seen that the parameters on vms12 have been modified, but the parameters on vms11 have not been modified.

5.4.3 The second example of initializing the container

This example demonstrates sharing data by initializing a container and a normal container.

Step 1: Create the second yaml file initpod2.yaml for initializing the pod, with the following content.

[root@vms10 pod]# cat initpod2.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: myapp 
  labels:
    app: myapp 
spec:
  volumes:
  - name: workdir 
    emptyDir: {}
  containers:
    - name: podx 
    image: nginx 
    imagePullPolicy: IfNotPresent 
    volumeMounts: 
    - name: workdir
      mountPath: "/xx" # 这里把workdir挂载到容器的/xx目录
  initContainers:
  - name: poda
    image: busybox 
    imagePullPolicy: IfNotPresent 
    command: ['shxxx', '-c', 'touch /work-dir/aa.txt']
    volumeMounts:
    - name: workdir
      mountPath: "/work-dir" # 这里把workdir挂载到容器的/work-dir目录
[root@vms10 pod]# 
复制代码

Create a pod named myapp here, and create a storage volume named workdir in this pod (there will be a special chapter on volume storage). Here poda is the initialization container. It mounts the storage volume workdir to the /work-dir directory of the container, and then creates aa.txt in the mount point /work-dir. In fact, this file is created in the storage volume workdir. .

In the ordinary container podx, the storage volume workdir will be mounted to the /xx of the container. When accessing /xx, the actual access is the storage volume workdir, so in the ordinary container podx, you should be able to see aa in /xx .txt.

But we look at the initialization container, the shxxx command should be wrong, that is, the initialization container cannot be executed correctly, and podx cannot be created.

Step 2: Create this pod.

[root@vms10 pod]# kubectl apply -f initpod2.yaml 
pod/myapp created
[root@vms10 pod]# 
复制代码

Step 3: Check the running status of the pod.

[root@vms10 pod]# kubectl get pods
NAME   READY  STATUS     RESTART  AGE
myapp   0/1   Init:0/1     0      0s
pod3    1/1   Running      0      55m
[root@vms10 pod]# 
复制代码

It can be seen that the initialization pod is being created now, because the command in the initialization container is wrong, so the execution of the initialization container will report an error, and the result is as follows.

[root@vms10 pod]# kubectl get pods
NAME    READY  STATUS                    RESTARTS   AGE 
myapp    0/1   Init:RunContainerError      0        4s
pod3     1/1   Running                     0        55m
[root@vms10 pod]#
复制代码

Step 4: Delete this pod.

[root@vms10 pod]# kubectl delete -f podinit2.yaml 
pod "myapp" deleted 
[root@vms10 pod]#
复制代码

Step 5: Modify the yaml file and modify the command correctly.

initContainers: 
- name: poda
  image: busybox 
  imagePullPolicy: IfNotPresent 
  command: ['sh', '-c', 'touch /work-dir/aa.txt']
  volumeMounts:
  - name: workdir 
    mountPath: "/work-dir"
复制代码

Step 6: Create the pod again.

[root@vms10 pod]# kubectl get pods 
NAME  READY   STATUS            RESTARTS   AGE 
myapp  0/1   PodInitializing      0        2s 
pod3   1/1    Running             0        55m
[root@vms10 pod]# kubectl get pods 
NAME   READY    STATUS   RESTARTS    AGE 
myapp   1/1     Running     0         5s
pod3    1/1     Running     0         55m
复制代码

It can be seen that the operation is normal now.

Step 7: View the content of /xx in podx in myapp.

[root@vms10 pod]# kubectl exec myapp -c podx -- ls /xx 
aa.txt
[root@vms10 pod]#
复制代码

Step 8: Delete this pod.

[root@vms10 pod]# kubectl delete -f podinit2.yaml
pod "myapp" deleted
[root@vms10 pod]#