Kubernetes-容器的生命周期（init容器、健康检查探针、钩子）

目录

一、概述

二、init容器

1.概述

2.init容器作用

3.InitC容器示例

三、容器探针

1.概述

2.探针类型

3.readinessProbe-就绪检测示例

4.livenessProbe-存活检测示例

5.livenessProbe-tcp--检测端口模板

四、钩子

1.概述

2.yaml模板

3.示例

---

一、概述

1.当一个pod被创建的时候，会启动第一个容器pause。

         作用：挂载可能存在的存储卷，初始化网络栈，后来僵尸进程的杀死。维护。

2.pause容器启动后，就会启动另一个部分， 不是mainC，而是initC（初始化容器，initC>=0）

  initC初始化容器的特性：

1. 线性启动:

   • 阻塞特性，前一个initC-1必须退出，后面的initC-2才会运行。执行退出命令的返回码为0，代表成功退出。如果initC启动过程中失败，出现错误，那么pause会重新开始创建initC-1，initC-2，initC-3等等。只有所有initC全部成功启动退出，才会继续往下运行。

2. 独立于应用容器:

   • Init 容器可以有自己的独立镜像，这与应用容器使用的镜像可以完全不同。因此，它们具有其特殊的依赖和工具，不会影响应用容器的镜像构成。

3. 运行到完成:

   • Init 容器必须在终止前运行到完成。它们不是用来启动长期运行的进程的。一旦它们成功执行了启动命令，它们就会终止。

4. 重新启动策略:

   • 如果 Init 容器失败，Kubernetes 默认的重新启动策略是 'Always'，它会一直重试直到容器成功为止。这与应用容器的启动失败策略是独立的。

5. 资源限制:

   • 与应用容器一样，可以对 Init 容器设置资源请求和限制。

6. 与应用容器共享卷:

   • Init 容器可以访问与应用容器相同的数据卷。这意味着它们可以用来准备或修改数据，这些数据后续将由应用容器使用。

7. 运行环境隔离:

   • Init 容器和应用容器可以有不同的运行环境和根文件系统。它们甚至可以在不同的命名空间下执行，从而提供额外的安全隔离。

二、init容器

1.概述

       Pod 能够具有多个容器，应用运行在容器里面，但是它也可能有一个或多个先于应用容器启动的 Init 容器。

Init 容器与普通的容器非常像，除了如下两点：

        1. Init 容器总是运行到成功完成为止

        2. 每个 Init 容器都必须在下一个 Init 容器启动之前成功完成

       如果 Pod 的 Init 容器失败，Kubernetes 会不断地重启该 Pod，直到 Init 容器成功为止。然而，如果 Pod 对应的 restartPolicy 为 Never，它不会重新启动。

2.init容器作用

       因为 Init 容器具有与应用程序容器分离的单独镜像，所以它们的启动相关代码具有如下优势：

       1. 可以包含并运行实用工具，但是出于安全考虑，是不建议在应用程序容器镜像中包含这些实用工具的。

       2. 应用程序镜像可以分离出创建和部署的角色，而没有必要联合它们构建一个单独的镜像。

       3. Init 容器使用 Linux Namespace，所以相对应用程序容器来说具有不同的文件系统视图。因此，它们能够具有访问 Secret 的权限，而应用程序容器则不能。        

       4. 它们必须在应用程序容器启动之前运行完成，而应用程序容器是并行运行的，所以 Init 容器能够提供了一种简单的阻塞或延迟应用容器的启动的方法，直到满足了一组先决条件。

3.InitC容器示例

vim initC-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busybox:1.35.0
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox:1.35.0
    command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
  - name: init-mydb
    image: busybox:1.35.0
    command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']

kubectl apply -f initC-pod.yaml

kubectl get pod

kubectl describe pod myapp-pod

kubectl logs myapp-pod -c init-myservice
    #因为这里无法解析myservice的dns地址，所以才会报错

 

kubectl create svc clusterip myservice --tcp=80:80

kubectl get svc

kubectl get pod
    #这里只加载好一个是因为，只解析了myservice的DNS，找不到mydb的DNS，所以无法加载

kubectl create svc clusterip mydb --tcp=80:80

#稍等一会再次查看,就会加载完成
kubectl get pod

三、容器探针

1.概述

       探针是由 kubelet 对容器执行的定期诊断。要执行诊断，kubelet 调用由容器实现的 Handler。有三种类型的处理程序：

         （1）ExecAction：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。

         （2）TCPSocketAction：对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开，则诊断被认为是成功的。

         （3）HTTPGetAction：对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于 400，则诊断被认为是成功的

2.探针类型

       livenessProbe：指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其 重启策略 的影响。如果容器不提供存活探针，则默认状态为 Success

       readinessProbe：指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针，则默认状态为 Success

         存活探测：

                  探测失败：根据重启策略进行重载

                  探测成功：静默，等待下一次的存活探测

                  探测未知：静默，等待下一次探测

         就绪探测：如果mainC 不添加就绪探测，默认就绪，如果添加就绪探测，必须就绪通过后才标记就绪

                  探测失败：静默，等待下一次的探测

                  探测成功：将当前的未就绪状态，改为就绪

                  探测未知：静默，等待下一次探测

3.readinessProbe-就绪检测示例

vim readiness-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: readiness-httpget-pod
  namespace: default
  labels:
    app: myapp
    env: test
spec:
  containers:
  - name: readiness-httpget-container
    image: nginx:latest
    imagePullPolicy: IfNotPresent
    readinessProbe:
      httpGet:
        port: 80
        path: /index1.html
      initialDelaySeconds: 1	#延迟的间隔是一秒
      periodSeconds: 3		#检测的间隔时间是3秒	
      timeoutSeconds: 3		#超时时间是3秒

kubectl create -f readiness-pod.yaml

kubectl get pod
    #未就绪状态，因为请求不到index1.html文件

kubectl exec -it readiness-httpget-pod -- /bin/sh

#pod中添加index1.html文件
cd /usr/share/nginx/html/

echo "123" > index1.html

exit

#就绪状态，可以正常对外提供访问
kubectl get pod

4.livenessProbe-存活检测示例

vim livenessProbe-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec-pod
  namespace: default
spec:
  restartPolicy: Never
  containers:
  - name: liveness-exec-container
    image: busybox:1.35.0
    imagePullPolicy: IfNotPresent
    command: ["/bin/sh","-c","touch /tmp/live ; sleep 60; rm -rf /tmp/live; sleep 3600"]
    livenessProbe:
      exec:
        command: ["test","-e","/tmp/live"]	
      initialDelaySeconds: 1	#延迟的间隔是一秒
      periodSeconds: 3		#检测的间隔时间是3秒	
      timeoutSeconds: 3		#超时时间是3秒

kubectl apply -f livenessProbe-pod.yaml

kubectl get pod

kubectl get pod
    #再次查看，已处于error状态。
    #文件被删除，存活探测失败。

5.livenessProbe-tcp--检测端口模板

apiVersion: v1
kind: Pod
metadata:
  name: probe-tcp
spec:
  containers:
  - name: nginx
    image: nginx:latest
    livenessProbe:		#存活探测
      initialDelaySeconds: 5	#初始化间隔时间时5秒
      timeoutSeconds: 1		#超时时间是1秒
      periodSeconds: 3		#检测间隔是3秒
      tcpSocket:
        port: 80			#检测的端口是80

 说明：这种方式不太好，检测端口是否存在，不代表服务能正常响应。

四、钩子

1.概述

       Pod hook（钩子）是由 Kubernetes 管理的 kubelet 发起的，当容器中的进程启动前或者容器中的进程终止之前运行，这是包含在容器的生命周期之中。可以同时为 Pod 中的所有容器都配置 hook。

Hook 的类型包括两种：

         exec：执行一段命令

         HTTP：发送 HTTP 请求

启动后钩子可以编译软件，挂载存储。

关闭前钩子可以保存文件，解除存储。

2.yaml模板

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: nginx:latest
    lifecycle:
      postStart:		#启动后
        exec:
          command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
      preStop:			#关闭前
        exec:
          command: ["/bin/sh", "-c", "echo Hello from the preStop handler > /usr/share/message"]

3.示例

vim lifecycle-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: nginx:latest
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
      preStop:
        exec:
          command: ["/bin/sh", "-c", "echo Hello from the preStop handler > /usr/share/message"]

kubectl apply -f lifecycle-pod.yaml

kubectl get pod

kubectl exec -it lifecycle-demo -- /bin/sh

#pod中执行
while 2>1;do cat /usr/share/message;done

#再开一个终端删除pod，然后观察原终端的返回信息
kubectl delete pod --all