This is the fifth day of my participation in the More Text Challenge. For details, see:

This article has participated in the weekend study program, click to see the details

steps

First kubectl interacts with API server, then etCD, and then kubelet of corresponding node

2 then Kubelet interacts with CRI on node, i.e. Docker, to start the initialization process shown in the diagram

Create a pause network stack inside the pod container, and then proceed with a series of Init C processes

4 After initialization is complete, each container has its own start initialization script to run

5 You can set a probe to check whether the container can provide services after initializing the script for a period of time. If the container can provide services, the running state is displayed. Readiness

6 Another probe is used to check whether the container is abnormal and determine whether to restart the container based on the restartPolicy. That’s the Liveness state up here

Finally, before destroying the container, you can run a stop script at the end

Let’s take an in-depth look at each of these processes with examples. In this video we’re going to look at the first step, Init C.

Init C

Init C is a container for initialization. It has two characteristics:

The Init container always runs until it successfully exits. If the Init container fails, k8s will restart the Pod until it succeeds. Each Init container must run after the last Init container successfully completes. Init container failure does not restart.

Because Init is a separate container from the business container, it can do the following:

Can install some can be used container business tools, these tools if encapsulated in the business of mirror will increase the redundancy to the business of business image of the container to separate code for creating and deploying two stages, will create the stage into the Init containers Init container belongs to Linux namespace, relative business container has higher file system permissions, For example, the Secret permission. Sensitive file processing is done in the Init phase to make the business container more secure. For certain pods that have a serious sequential dependency, you can decide in the Init of the Pod that needs to be started later, wait until the first Pod completes successfully, then exit the Init. So much for the first Pod, Let’s see the actual operation.

Create a yamL configuration file with Init container test-init-main.yaml as follows

apiVersion: v1
kind: Pod
metadata:
  name: test-init-main
  labels:
    app: myapp
    version: v1
spec:
  containers:
    - name: my-busybox
      image: busybox
      command: ['sh','-c','echo Main app is running && sleep 3600']
  initContainers:
    - name: init-myservice
      image: busybox
      command: ['sh','-c','until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
    - name: init-mydb
      image: busybox
      command: ['sh','-c','until nslookup mydb; do echo waiting for mydb; sleep 2; done;']
Copy the code

Busybox is a lightweight Linux system for embedded use. Busybox is used here as an image of the container. A master container is configured under containers, and the function simply prints a record when started, because the shell command is fetched from a string, so the -c option is used here. InitContainers are configured with two Init containers that wait for myService and mydb to come together before exiting Init. Once the service is up, the coreDNS will have the corresponding IP address to resolve, and the rest of the POD will automatically obtain it

Run kubectl apply -f test-init-main.yaml and you can see that the container stops at the init phase and that the two init containers only complete 0

[root@k8s-master k8s-test]# kubectl apply -f test-init-main.yaml pod/test-init-main created [root@k8s-master k8s-test]# kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES curl-6bf6db5c4f-kljp4 1/1 Running 1 40h 10.244.1.2k8s -node1 <none> <none> Hellok8s 2/2 Running 0 21h 10.244.1.6k8s -node1 <none> <none> Test-init-main 0/1 init :0/2 0 12s 10.244.1.8k8s -node1 <none> <none>Copy the code

You can see that the init-myService init container is still in the running state, so you cannot continue down.

Yaml file test-init-myService. yaml to create a service called myService

apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 6666
Copy the code

So this is port 80 of the service IP and port 6666 of the container, so I’m not going to worry about that. Make sure the service is up and running

If we look at the state of the POD, we see that the first Init container has already exited

Create the myDB service using the yamL file test-init-mydb.yaml

apiVersion: v1
kind: Service
metadata:
  name: mydb
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 7777
Copy the code

Also make sure the service is up

If you look at the state of the POD, all Init containers have exited, and the primary container is in the running state

Look at the log, it’s exactly what we want to print

[root@k8s-master k8s-test]# kubectl logs test-init-main
Main app is running
Copy the code