k8s上Pod生命周期、重启策略、容器探测简介

已于 2023-11-22 00:15:03 修改
阅读量1k 收藏 3
点赞数 2
分类专栏： Kubernetes 文章标签： container kubernetes pod 容器探测 初始化容器
于 2023-11-18 16:46:47 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_64334766/article/details/134480101
版权

目录

一.Pod的创建过程

二.Pod的终止过程

三.Pod的重启策略（restartPolicy）

1.Always

2.OnFailture

3.Never

4.示例

四.Pod生命周期内的5种状态（相位）

1.Pending

2.Running

3.Succeeded

4.Failed

5.Unknown

五.初始化容器（init container）

1.运行初始化容器

2.以一个案例进行验证初始化容器的重要性

（1）首先只为mysql提供一个IP地址，tomcat的还没有提供

（2）编写文件

（3）应用验证

（4）为redis提供可用IP地址，并应用验证

六.主容器（main container）

1.钩子函数简介

（1）exec，只在容器内执行一次

（2）tcpSocket，在当前的容器中尝试访问指定socket，成功后继续执行

（3）httpGet，在当前的容器中向某url发起http请求，成功后继续执行

2.容器探测

（1）liveness probes

（2）readiness probes

（3）initialDelaySeconds和timeoutSeconds

（4）periodSeconds、failureThreshold和successThreshold

 

一.Pod的创建过程

1.用户通过kubectl提交pod信息传给apiserver，apiserver生成pod信息，将信息存入etcd，并像kubectl返回确认信息

2.apiserver开始记录etcd上apiserver传来的pod的变化，剩余其他组件使用watch机制跟踪apiserver信息变化

3.scheduler发现pod创建请求，为pod分配主机，向apiserver返回分配信息

4.node上kubectl接收到pod调度任务，使用现有容器引擎启动容器，向apiserver返回启动等结果

5.apiserver最后又将pod状态存入etcd

 f6fda7f00b874d1bbd66a62ff50676e2.png

二.Pod的终止过程

1.kubectl客户端向apiserver发出删除pod命令

2.apiserver中的pod信息在默认的30s宽限期内被视为dead，被标记为terminating状态

3.

（1）kubelet察觉到pod为terminating状态后会开始关闭该pod的进程，node上的设备察觉到进程关闭后会把该pod在此node上匹配的service资源都移出列表

（2）若是pod定义了prestop钩子相关部分，在terminating后会同步开启执行prestop

4.容器进程收到停止信号后，判断宽限期结束后是否还有运行中的进程，若存在，该进程和pod会被要求立即终止

5.apiserver收到kubelet将pod宽限期设置为0的请求，随后完成删除

三.Pod的重启策略（restartPolicy）

主要是针对容器探测时出现问题后的重启具体策略，主要有Always、OnFailure、Never三种策略，除首次重启外，以后的每次重启间隔一般都为10s-20s-40s-80s这样的双倍递增规律

1.Always

容器生效后，自动重启，默认就是Always

2.OnFailture

容器停止运行而且退出码不为0时才重启

3.Never

不管是处于什么状态，都不重启

4.示例

apiVersion: v1
kind: Pod
metadata:
  name: mynginx
  namespace: myns
  labels:
    run: nginx
    user: sulibao
spec:
  containers:
    - name: mynginx
      image: nginx
      ports:
      - name: nginx-port
        containerPort: 80 
      lifecycle:
        postStart:
          tcpSocket:
            port: 8080
  restartPolicy: Always
​
[root@k8s-master pod]# kubectl get pods -n myns
NAME      READY   STATUS             RESTARTS      AGE
mynginx   0/1     CrashLoopBackOff   1 (43s ago)   2m
[root@k8s-master pod]# vim nginx.yaml 
[root@k8s-master pod]# kubectl get pods -n myns
NAME      READY   STATUS             RESTARTS      AGE
mynginx   0/1     CrashLoopBackOff   2 (11s ago)   2m16s    #该容器无法正常创建，需要重启
​
​
#将策略更改为Never，不会重启，直接显示error
[root@k8s-master pod]# kubectl get pods -n myns
NAME      READY   STATUS   RESTARTS   AGE
mynginx   0/1     Error    0          54s
[root@k8s-master pod]# cat nginx.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: mynginx
  namespace: myns
  labels:
    run: nginx
    user: sulibao
spec:
  containers:
    - name: mynginx
      image: nginx
      ports:
      - name: nginx-port
        containerPort: 80 
      lifecycle:
        postStart:
          tcpSocket:
            port: 8080
  restartPolicy: Never

四.Pod生命周期内的5种状态（相位）

1.Pending

挂起状态，已经创建了pod，但没有被调度完成或者仍处于镜像拉取过程中

2.Running

运行中，pod已经被调度至受管节点，且pod要求的所有容器都已经创建完成

3.Succeeded

成功，pod中的所有容器都成功终止且不会被重启

4.Failed

失败，所有容器都停止，有一个或以上容器终止失败，容器返回非0值

5.Unknown

无法正常获取到pod状态信息，通常是网络通信问题

五.初始化容器（init container）

当需要用到主容器镜像中没有的代码或文件时、需要利用初始化容器去延缓主容器创建时间、或需要利用初始化容器去满足主容器依赖条件的情况下多用到初始化容器

1.运行初始化容器

（1）简单来说初始化容器就是在主容器执行之前要执行的工作，所以初始化容器必须完整运行完成不能失败才能执行到主容器，若运行失败，会一直被重启直到成功（理解为卡在初始化执行阶段）

（2）初始化容器严格按照定义的顺序执行，理解为第一个执行成功第二个才能开始执行

2.以一个案例进行验证初始化容器的重要性

准备创建三个容器，主容器为nginx，两个初始化容器为busybox、分别用于测试mysql和tomcat（这两个服务需要具有IP地址，仅供简单测试，两个服务并非真正启动）

（1）首先只为mysql提供一个IP地址，tomcat的还没有提供

[root@k8s-master pod]# ifconfig ens33:1 192.168.2.140 netmask 255.255.255.0 up

（2）编写文件

初始化容器中直到ping通两次指定的IP才算真正完成

[root@k8s-master pod]# cat test-nginx.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: test-nginx
  labels:
    name: mytest
  namespace: myns
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - name: nginx-port
      containerPort: 80
  initContainers:
  - name: test-mysql
    image: busybox
    command: ["/bin/sh","-c","until ping 192.168.2.140 -c 2; do echo preparing mysql; sleep 2; done;"]
  - name: test-tomcat
    image: busybox
    command: ["/bin/sh","-c","until ping 192.168.2.141 -c 2; do echo preparing tomcat; sleep 2; done;"]

（3）应用验证

[root@k8s-master pod]# kubectl apply -f test-nginx.yaml
[root@k8s-master pod]# kubectl get pods test-nginx -n myns   #始终位于初始化未完成状态，说明初始化容器中有未完成任务
NAME         READY   STATUS     RESTARTS   AGE
test-nginx   0/1     Init:1/2   0          2m24s
​
[root@k8s-master pod]# kubectl describe pod test-nginx -n myns  #describe查看详情
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  100s  default-scheduler  Successfully assigned myns/test-nginx to k8s-node1
  Normal  Pulling    99s   kubelet            Pulling image "busybox"
  Normal  Pulled     95s   kubelet            Successfully pulled image "busybox" in 4.515s (4.515s including waiting)
  Normal  Created    95s   kubelet            Created container test-mysql
  Normal  Started    95s   kubelet            Started container test-mysql
  Normal  Pulling    92s   kubelet            Pulling image "busybox"
  Normal  Pulled     89s   kubelet            Successfully pulled image "busybox" in 3.365s (3.365s including waiting)
  Normal  Created    89s   kubelet            Created container test-tomcat
  Normal  Started    89s   kubelet            Started container test-tomcat   
  #可以看到卡在test-tomcat初始化容器的执行上，因为我们没有为其提供可用IP地址，它无法完成文件中的command（ping不通两次）部分，也就无法进入主容器nginx的创建启动

（4）为redis提供可用IP地址，并应用验证

[root@k8s-master pod]# ifconfig ens33:2 192.168.2.141 netmask 255.255.255.0 up
[root@k8s-master pod]# kubectl get pods -n myns
NAME         READY   STATUS    RESTARTS   AGE
test-nginx   1/1     Running   0          14m
​
Events:
  Type    Reason     Age    From               Message
  ----    ------     ----   ----               -------
  Normal  Scheduled  3m40s  default-scheduler  Successfully assigned myns/test-nginx to k8s-node1
  Normal  Pulling    3m39s  kubelet            Pulling image "busybox"
  Normal  Pulled     3m35s  kubelet            Successfully pulled image "busybox" in 4.515s (4.515s including waiting)
  Normal  Created    3m35s  kubelet            Created container test-mysql
  Normal  Started    3m35s  kubelet            Started container test-mysql
  Normal  Pulling    3m32s  kubelet            Pulling image "busybox"
  Normal  Pulled     3m29s  kubelet            Successfully pulled image "busybox" in 3.365s (3.365s including waiting)
  Normal  Created    3m29s  kubelet            Created container test-tomcat
  Normal  Started    3m29s  kubelet            Started container test-tomcat  #已有可用IP地址，执行完成
  Normal  Pulling    38s    kubelet            Pulling image "nginx"   #进一步执行主容器nginx的任务
  Normal  Pulled     12s    kubelet            Successfully pulled image "nginx" in 26.146s (26.146s including waiting)
  Normal  Created    12s    kubelet            Created container nginx   #主容器执行成功
  Normal  Started    12s    kubelet            Started container nginx

六.主容器（main container）

1.钩子函数简介

主要是设置来感知生命周期事件，在特定的周期阶段执行用户特定的操作，又分为启动后（post start，指容器创建之后就执行的部分，此处执行失败会重启容器）和结束前（pre stop，指容器终止运行之前执行的部分，此处执行失败会导致删除容器失败）两种。

钩子函数定义方式

（1）exec，只在容器内执行一次

apiVersion: v1
kind: Pod
metadata:
  name: mynginx
  namespace: myns
  labels:
    run: nginx
    user: sulibao
spec:
  containers:
    - name: mynginx
      image: nginx
      ports:
      - name: nginx-port
        containerPort: 80 
      lifecycle:
        postStart:
          exec:
            command: ["/bin/bash","-c","cat /sdf.txt"]  #此时这个文件不存在，钩子函数执行失败
            
#换一个存在的文件就能够成功
[root@k8s-master pod]# kubectl get pods -n myns
NAME      READY   STATUS    RESTARTS   AGE
mynginx   1/1     Running   0          96s
[root@k8s-master pod]# cat nginx.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: mynginx
  namespace: myns
  labels:
    run: nginx
    user: sulibao
spec:
  containers:
    - name: mynginx
      image: nginx
      ports:
      - name: nginx-port
        containerPort: 80 
      lifecycle:
        postStart:
          exec:
            command: ["/bin/bash","-c","ls /root"]

（2）tcpSocket，在当前的容器中尝试访问指定socket，成功后继续执行

apiVersion: v1
kind: Pod
metadata:
  name: mynginx
  namespace: myns
  labels:
    run: nginx
    user: sulibao
spec:
  containers:
    - name: mynginx
      image: nginx
      ports:
      - name: nginx-port
        containerPort: 80 
      lifecycle:
        preStop:
          tcpSocket:
            port: 80

（3）httpGet，在当前的容器中向某url发起http请求，成功后继续执行

apiVersion: v1
kind: Pod
metadata:
  name: mynginx
  namespace: myns
  labels:
    run: nginx
    user: sulibao
spec:
  containers:
    - name: mynginx
      image: nginx
      ports:
      - name: nginx-port
        containerPort: 80 
      lifecycle:
        preStop:
          httpGet:
            path: http://192.168.2.150
            port: 80
            
[root@k8s-master pod]# kubectl get pods -n myns
NAME      READY   STATUS    RESTARTS   AGE
mynginx   1/1     Running   0          56s

2.容器探测

主要是用于检测容器中的应用实例工作状态是否正常，不符合预期的实例就会被剔除，不分配任务。两种容器探测探针也支持exec、tcpSocket、httpGet三种检测方式，用法和钩子函数中用法基本一致。

（1）liveness probes

存活性探针，用于检测应用实例是否处于正常状态，不正常则会重启容器

（2）readiness probes

就绪性探针，用于检测应用实例是否可以进行接受请求的工作，不能则不会为其分配工作

（3）initialDelaySeconds和timeoutSeconds

initialDelaySeconds是容器启动后多少秒开始探测，timeoutSeconds是探测超时时间为多少，默认单位是秒

[root@k8s-master pod]# cat nginx.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: mynginx
  namespace: myns
  labels:
    run: nginx
    user: sulibao
spec:
  containers:
    - name: mynginx
      image: nginx
      ports:
      - name: nginx-port
        containerPort: 80 
      livenessProbe:
        exec:
          command: ["/bin/bash","-c","ls /root"]
        initialDelaySeconds: 30
        timeoutSeconds: 5

（4）periodSeconds、failureThreshold和successThreshold

periodSeconds是指定执行探测频率（默认10s，最小1s）

failureThreshold是指定连续探测多少次失败才会被认为是失败（默认3，最小1）

successThreshold是指定连续探测多少次成功才会被认为是成功（默认1）

apiVersion: v1
kind: Pod
metadata:
  name: mynginx
  namespace: myns
  labels:
    run: nginx
    user: sulibao
spec:
  containers:
    - name: mynginx
      image: nginx
      ports:
      - name: nginx-port
        containerPort: 80 
      livenessProbe:
        exec:
          command: ["/bin/bash","-c","ls /root"]
        initialDelaySeconds: 30
        timeoutSeconds: 5
        periodSeconds: 15
        failureThreshold: 2
        successThreshold: 1

 

树下一少年
关注
  • 2
    点赞
  • 踩
  • 3
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 1
    评论
专栏目录
Kubernetes中Pod的生命周期、重启策略
YIYIYI
07-05 1319
Kubernetes中Pod的生命周期、重启策略
K8S之Pod常见的状态和重启策略
最新发布
weixin_40364776的博客
02-08 2254
pod常见状态解读和重启策略使用分析
Kubernetes-pod重启策略
咸鱼很闲
12-13 897
pod重启策略 在上一节中，一旦容器探测出现了问题，kubernetes就会对容器所在的Pod进行重启，其实这是由pod的重启策略决定的，pod的重启策略有3种，分别如下: Alwaysl:容器失效时，自动重启该容器，这也是默认值。 OnFailure :容器终止运行且退出码不为0时重启 Never : 不论状态为何，都不重启该容器 重启策略适用于pod对象中的所有容器，首次需要重启的容器，将在其需要时立即进行重启，随后再次需要重启的操作将由kubelet延迟一段时间后进行，且反复的重启操作的延迟时长以
实操：k8s中的pod的重启策略
Lfwthotpt的博客
05-13 1万+
前言： pod的重启策略restartpolicy：pod在遇到故障之后重启的动作有： 1.always：当容器退出时，总是重启容器，默认策略 2.onfailure：当容器异常退出(退出状态码非0)时，重启容器 3.nerver：当容器退出时，从不重启容器 备注：k8s中不支持重启pod资源，这里说的重启指的是删除重建pod 一：查看现有pod资源的重启策略 查看重启策略使用kubectl edit 查看 或者将pod资源–export -o yaml 查看 [root@master1 ~]# kubec
K8S中pod的重启策略和健康检查
qq_41296573的博客
05-09 386
重启策略+健康检查 重启策略（restartPolicy）： Always：只要容器终止退出后，就一直尝试重启容器，默认策略（适用于：mysql、nginx、redis等）。 OnFailure：只有容器异常退出后（退出状态码非0），才重启容器（适用于：定时任务）。 Never：当容器终止退出后，不重启容器（适用于：一次性任务） 健康检查类型 livenessProbe（存活检查）：当检查容器中应用无法访问时，就杀死容器，根据pod中的restartPolicy来操作。 readinessProbe（
【k8s】8、Pod详解（未完成）
clislog的博客
04-16 196
2）IfNotPresent:本地有就从本地拉取，本地仓库没有就从远程仓库拉取。2）可以在根容器上设置IP地址，其他容器都以此IP实现网络内部的通信；2）containerPort：容器要监听的端口。3）Never:只从本地仓库拉取，不从远程拉取。3）hostPort：容器要在主机上公开的端口。2）memory：可以使用Gi\Mi\G\M。1）cpu：core数，可以为整数或者小数。1）Always:总是从远程镜像仓库拉取。2）requests:需要的最小资源。1）limits:需要的最大资源。
k8s集群pod经常重启问题排查总结.doc
10-29
k8s集群pod经常重启问题排查总结
K8S – livenessProve – 存活性探测
01-07
如果存活性探测失败，则kubelete会杀死容器，并且容器受重启策略的影响。如果容器不提供存活性探针，则默认状态为Success。 [root@k8s-master01 k8s-test]# cat liveness.yaml apiVersion: v1 kind: Pod metadata: ...
k8s中pod监控看板
12-15
k8s中pod监控看板
k8s技术交流，包括Pod概念和特点Pod种类Pod镜像拉取策略Pod重启策略Pod控制器Pod探针、Pod调度
05-13
Pod是k8s系统中可以创建和管理的最小单元，是资源对象模型中由用户创建或部署的最小资源对象模型，也是k8s上运行容器化应用的资源对象。Pod的特点包括： * pod中的容器要求必须以前台命令作为启动命令 * pod可以由...
kmem问题造成K8S中pod内存溢出
01-20
在Kubernetes(K8S)集群中，当遇到“kmem问题造成K8S中pod内存溢出”的情况，这通常意味着内核内存(kernel memory)的使用超过了预期限制，导致了Pod无法正常运行或者性能下降。内核内存是操作系统用于内部数据结构和...
kubernetes 探针
weixin_38367535的博客
03-18 1392
探针包含三种： Liveness存活探针： 判断容器是否处于运行状态 Readness就绪探针： 判断服务是否正常工作 Startup启动检测： 1.16版本后加入，针对容器内应用服务是否已经启动监控，如果配置了该探针，则会先禁用其他探针，直到成功为止，成功后将不再进行探测 Liveness存活探针在容器启动时标记为成功，防止还没启动完成就被kill掉 Readness就绪探针在容器启动时标记为失败，防止还没启动完成就接收流量，避免请求失败 只配置Readness探针无法
深入理解K8S（六）
weixin_45857924的博客
07-29 458
深入理解K8S（六）
K8S 三种探针 readinessProbe、livenessProbe和startupProbe
热门推荐
Jerry00713的博客
04-16 3万+
介绍 K8S 提供了3种探针 readinessProbe livenessProbe startupProbe（这个1.16版本增加的） 1、startupProbe readinessProbe：指示容器是否准备好服务请求（是否启动完成并就绪）。绪探针初始延迟之前的就绪状态默认为Failure，待容器启动成功弹指指标探测结果为成功后，状态变更为 Success。如果未配置就绪探针，则默认状态为Success。 只有状态为 Success ，才会被纳入 pod 所属 service 中，也就是
存活探针(Liveness)、就绪探针(Readiness)、启动探针(Startup)
fhw925464207的博客
07-17 2795
首先，如果没有定义就绪探针，那么新创建的pod就会立即加入到service的endpoint列表，如果容器里的业务程序需要很长时间才能开始处理传入的链接，而此时service又将客户端连接转发给了该pod，那么客户端就会看到“连接被拒绝”等类型的错误，所以，为每个容器定义一个就绪探针是很有必要的，即使是定义一个简单的http get 探针。
k8s教程（pod篇）-生命周期、重启策略及健康检查
阿甘兄
10-08 2416
详细讲解pod生命周期、重启策略及健康检查
k8s中Pod重启方法
xiaohuangren_123的博客
08-20 1万+
文章目录 一、有yaml文件的重启方式 二、没有yaml文件的重启方式 使用scale命令 直接删除Pod进行重启 使用“-o yaml”参数导出Pod模板并重建Pod【推荐】 总结 在使用 docker 的过程中，我们可以使用docker restart {container_id}来重启容器，但是在 kubernetes 中并没有重启命令（没有 kubectl restart {podname}），有时候我们的 Pod 出现 Bug意外终止，导致我们需要重启 Pod ，却没有一个很好的方式，特别是没有
K8S系列：Pod重启策略restartPolicy（Always、OnFailure、Never）
NIO4444
05-15 5246
restartPolicy apiVersion: v1 kind: Pod metadata: name: nginx-pod spec: restartPolicy: Always containers: - name: nginx-pod image: nginx 策略： Always pod中容器不论如何停止都将自动重启 OnFailure Pod中容器非正常停止会自动重启，正常停止不会重启 Never Pod中容器不论以任何方式停.
pod重启策略和状态解释
yan_0916的博客
02-28 4159
一、Pod一直处于Pending状态二、Pod一直处于Waiting 或 ContainerCreating状态三、Pod 一直处于CrashLoopBackOff状态四、Pod处于Error状态五、Pod 处于Terminating或 Unknown状态 一、Pod一直处于Pending状态 Pending状态意味着Pod的YAML文件已经提交给Kubernetes，API对象已经被创建并保存在Etcd当中。但是，这个Pod里有些容器因为某种原因而不能被顺利创建。比如，调度不成功(可以通过kubectl.
k8s的pod生命周期
07-27
Kubernetes（简称为k8s）中的Pod是最小的可部署单元，用于运行容器化应用程序。Pod的生命周期可以分为以下几个阶段： 1. Pending（等待）：Pod被创建后，处于Pending状态表示Kubernetes正在为Pod分配资源（如CPU、内存等）。在这个阶段，Pod可能会处于排队等待状态。 2. Running（运行中）：一旦Pod获得了所需的资源，它将进入Running状态。在这个阶段，容器正在运行，并且可以被其他组件访问。 3. Succeeded（成功）：如果Pod中的所有容器成功完成了它们的任务，那么Pod将进入Succeeded状态。通常情况下，这意味着所有容器都已经退出，并且不会再重新启动。 4. Failed（失败）：如果Pod中的任何一个容器退出并返回错误代码，那么Pod将进入Failed状态。通常情况下，这意味着容器无法完成其任务。 5. Unknown（未知）：如果无法获取关于Pod当前状态的信息，那么Pod将进入Unknown状态。这可能是由于与集群通信故障或其他未知错误导致的。 除了上述状态之外，Pod还可以通过以下方式进行调整： 1. 创建（Create）：通过创建Pod规范文件或使用Kubernetes API来创建Pod。 2. 更新（Update）：可以通过更新Pod规范文件或使用Kubernetes API来更新Pod的配置（如镜像版本、资源请求等），这将触发Pod的重新调度。 3. 删除（Delete）：可以通过删除Pod规范文件或使用Kubernetes API来删除Pod。一旦Pod被删除，它将不再存在于集群中。 需要注意的是，Kubernetes会根据集群的状态和配置自动处理Pod的生命周期，例如自动重新调度失败的Pod或替换不健康的Pod。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

树下一少年

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值