devbox
菜鸟追梦旅行
这个屌丝很懒，什么也没留下！
关注作者
热门标签
热门文章
当前位置:   article > 正文

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

作者：菜鸟追梦旅行 | 2024-05-18 12:40:32

赞

踩

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
  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4.   name: myapp-pod
  5.   labels:
  6.     app: myapp
  7. spec:
  8.   containers:
  9.   - name: myapp-container
  10.     image: busybox:1.35.0
  11.     command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  12.   initContainers:
  13.   - name: init-myservice
  14.     image: busybox:1.35.0
  15.     command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
  16.   - name: init-mydb
  17.     image: busybox:1.35.0
  18.     command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']

  1. kubectl apply -f initC-pod.yaml
  2.  
  3. kubectl get pod
  4.  
  5. kubectl describe pod myapp-pod

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

 

  1. kubectl create svc clusterip myservice --tcp=80:80
  2.  
  3. kubectl get svc

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

  1. kubectl create svc clusterip mydb --tcp=80:80
  2.  
  3. #稍等一会再次查看,就会加载完成
  4. 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
  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4.   name: readiness-httpget-pod
  5.   namespace: default
  6.   labels:
  7.     app: myapp
  8.     env: test
  9. spec:
  10.   containers:
  11.   - name: readiness-httpget-container
  12.     image: nginx:latest
  13.     imagePullPolicy: IfNotPresent
  14.     readinessProbe:
  15.       httpGet:
  16.         port: 80
  17.         path: /index1.html
  18.       initialDelaySeconds: 1	#延迟的间隔是一秒
  19.       periodSeconds: 3		#检测的间隔时间是3秒	
  20.       timeoutSeconds: 3		#超时时间是3秒
  1. kubectl create -f readiness-pod.yaml
  2.  
  3. kubectl get pod
  4.     #未就绪状态，因为请求不到index1.html文件

kubectl exec -it readiness-httpget-pod -- /bin/sh
  1. #pod中添加index1.html文件
  2. cd /usr/share/nginx/html/
  3.  
  4. echo "123" > index1.html
  5.  
  6. exit

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

4.livenessProbe-存活检测示例

vim livenessProbe-pod.yaml
  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4.   name: liveness-exec-pod
  5.   namespace: default
  6. spec:
  7.   restartPolicy: Never
  8.   containers:
  9.   - name: liveness-exec-container
  10.     image: busybox:1.35.0
  11.     imagePullPolicy: IfNotPresent
  12.     command: ["/bin/sh","-c","touch /tmp/live ; sleep 60; rm -rf /tmp/live; sleep 3600"]
  13.     livenessProbe:
  14.       exec:
  15.         command: ["test","-e","/tmp/live"]	
  16.       initialDelaySeconds: 1	#延迟的间隔是一秒
  17.       periodSeconds: 3		#检测的间隔时间是3秒	
  18.       timeoutSeconds: 3		#超时时间是3秒
  1. kubectl apply -f livenessProbe-pod.yaml
  2.  
  3. kubectl get pod

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

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

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4.   name: probe-tcp
  5. spec:
  6.   containers:
  7.   - name: nginx
  8.     image: nginx:latest
  9.     livenessProbe:		#存活探测
  10.       initialDelaySeconds: 5	#初始化间隔时间时5秒
  11.       timeoutSeconds: 1		#超时时间是1秒
  12.       periodSeconds: 3		#检测间隔是3秒
  13.       tcpSocket:
  14.         port: 80			#检测的端口是80

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

四、钩子

1.概述

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

Hook 的类型包括两种：

         exec：执行一段命令

         HTTP：发送 HTTP 请求

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

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

2.yaml模板

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4.   name: lifecycle-demo
  5. spec:
  6.   containers:
  7.   - name: lifecycle-demo-container
  8.     image: nginx:latest
  9.     lifecycle:
  10.       postStart:		#启动后
  11.         exec:
  12.           command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
  13.       preStop:			#关闭前
  14.         exec:
  15.           command: ["/bin/sh", "-c", "echo Hello from the preStop handler > /usr/share/message"]

3.示例

vim lifecycle-pod.yaml
  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4.   name: lifecycle-demo
  5. spec:
  6.   containers:
  7.   - name: lifecycle-demo-container
  8.     image: nginx:latest
  9.     lifecycle:
  10.       postStart:
  11.         exec:
  12.           command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
  13.       preStop:
  14.         exec:
  15.           command: ["/bin/sh", "-c", "echo Hello from the preStop handler > /usr/share/message"]
  1. kubectl apply -f lifecycle-pod.yaml
  2.  
  3. kubectl get pod

kubectl exec -it lifecycle-demo -- /bin/sh
  1. #pod中执行
  2. while 2>1;do cat /usr/share/message;done
  1. #再开一个终端删除pod，然后观察原终端的返回信息
  2. kubectl delete pod --all

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/菜鸟追梦旅行/article/detail/588293
推荐阅读
相关标签

Copyright © 2003-2013 www.wpsshop.cn 版权所有，并保留所有权利。

  

闽ICP备14008679号