1, Pod life cycle
• Pod can contain multiple containers in which applications run, and can also have one or more
Multiple Init containers started before the application container.
The Init container is very similar to ordinary containers except for the following two points:
• they always run to completion.
• Init containers do not support readability because they must be 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 succeeds. However, if the corresponding restartPolicy value of Pod is Never, it will not restart.
2, What can the Init container do?
• the Init container can contain some utilities or personalization that do not exist in the application container during installation
code.
The Init container can run these tools safely to avoid the security of application image caused by these tools
Lower.
• application image creators and Deployers can work independently without the need to jointly build a
A separate application image.
The Init container can run in a file system view different from the application container in the Pod. Therefore, the Init container
You 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
Mechanisms to block or delay the start of an 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.
3, Application of init container
Code acquisition: https://kubernetes.io/zh/docs/concepts/workloads/pods/init-containers/

[root@server2 manifest]# cat init.yml 
apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: myapp:v1
  initContainers:
  - name: init-myservice
    image: busybox:latest
    command: ['sh', '-c', "until nslookup myservice.default.svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
[root@server2 manifest]# cat service.yml 
kind: Service
apiVersion: v1
metadata:
  name: myservice
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

The pod container will not be started until the init container is started, and it is always ready
Unable to resolve address: myservice.default.svc.cluster.local

[root@server2 manifest]# kubectl apply -f service.yml  
init After the container is running, myAPP-pod Normal start

4, Probe
4.1 periodic diagnostics performed by kubelet on containers:
• ExecAction: executes the specified command in the container. If the return code is 0 when the command exits
The diagnosis was successful.

• 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: perform 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 as
successful.

• each probe will yield one of three results:
• success: the container passed the diagnosis.
• failed: the container failed the diagnosis.
• unknown: diagnosis failed, so no action will be taken.
4.2 kubelet can choose whether to execute and respond to three kinds of probes running on the container:
• livenessProbe: indicates whether the container is running. If the survival probe fails, kubelet
The container will be killed and will be affected by its restart policy. If the container does not provide a survival probe
Pin, the default state is Success.

• readinessProbe: indicates whether the container is ready for service requests. If ready detection fails, end
The point controller will remove the IP address of the Pod from the endpoints of all services that match the Pod.
The ready state before the initial delay defaults to Failure. If the container does not provide a ready probe, the
Recognize the status as Success.

• startupProbe: indicates whether the app in the container has started. If start detection is provided
(startup probe), all other probes are disabled until it succeeds. If detection is initiated
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 probe is provided, the default status is Success.
4.3 restart strategy
• there is a restartPolicy field in PodSpec, with possible values of Always, OnFailure and
Never. The default is Always.
• Pod's life
• generally Pod will not disappear until they are destroyed artificially, which may be a person or controller.
• it is recommended that you create the appropriate controller to create the Pod, rather than creating the Pod yourself. Because alone
Pod can't recover automatically in case of machine failure, but the controller can.
• three controllers available:
• use jobs to run pods that are expected to terminate, such as batch calculations. Job only applies to restart policy
Pod for OnFailure or Never.
• use ReplicationController, ReplicaSet, and
Deployment, such as a Web server. ReplicationController is only available for
There is a Pod with restartPolicy of Always.
• provide machine specific system services, using DaemonSet to run a Pod for each machine.
4.4 survival probe

[root@server2 manifest]# vim init.yml
apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: myapp:v1
    imagePullPolicy: IfNotPresent  Image pull strategy
    livenessProbe:  Survival probe detection
      tcpSocket:  Monitoring port
        port: 80
      initialDelaySeconds: 1  delay time 
      periodSeconds: 3   Interval time of each detection
      timeoutSeconds: 1  Timeout
  initContainers:
  - name: init-myservice
    image: busyboxplus
    command: ['sh', '-c', "until nslookup myservice.default.svc.cluster.local; do echo waiting for myservice; sleep 2; done"]

[root@server2 manifest]# kubectl describe pod myapp-pod 

The survival probe was detected continuously. When port 80 disappears, it will restart automatically, provided that restartPolicy is not Never

4.5 ready probe

[root@server2 manifest]# cat service.yml 
kind: Service
apiVersion: v1
metadata:
  name: myservice
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  selector:
    app: myapp
[root@server2 manifest]# cat init.yml 
apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: myapp:v1
    imagePullPolicy: IfNotPresent
    livenessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 1
      periodSeconds: 3
      timeoutSeconds: 1
    readinessProbe:   Ready probe
      httpGet:   
        path: /hostname.html   Monitoring release page
        port: 80
      initialDelaySeconds: 1
      periodSeconds: 3
      timeoutSeconds: 1  
  initContainers:
  - name: init-myservice
    image: busyboxplus
    command: ['sh', '-c', "until nslookup myservice.default.svc.cluster.local; do echo waiting for myservice; sleep 2; done"]

The restart container is running, but because the READY probe detects that the default publishing page does not exist, all "" READY "" is not READY


Restore default publishing page
Check the pod container and myservice again

Test access is only allowed inside the cluster

Load balancing of pod container

[root@server2 manifest]# kubectl run demo --image=busyboxplus -it --restart=Never

Load balancing