五、Pod生命周期 – Cedar-记录日常的小破站

本文最后更新于105 天前，其中的信息可能已经过时，如有错误请发送邮件到big_fw@foxmail.com

Table of Contents

流程图

1.initC（Init Containers）

initC 概念

初始化容器，大于等于0，如果有，就必须全启动成功为止，线性过程，第一个不成功第二个永不可能启动。

判断成功的标准是返回码为0（也就是说里面其实是脚本，不是进程）

可以挂载数据库，源码编译之类的，重启把现在创建的全部删除，是从头开始来，从创建pause开始。

比如可以设置死循环，等十二点在启动，或者判断数据库是否连接成功，成功了就退出循环返回0

initC 与运行容器的关系

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

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

Init 容器总是运行到成功完成为止
每个 Init 容器都必须在下一个 Init 容器启动之前成功完成

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

initC 的优势

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

它们可以包含并运行实用工具，但是出于安全考虑，是不建议在应用程序容器镜像中包含这些实用工具的
应用程序镜像可以分离出创建和部署的角色，而没有必要联合它们构建一个单独的镜像
Init 容器使用 Linux Namespace，所以相对应用程序容器来说具有不同的文件系统视图。因此，它们D能够具有访间 Secret 的权限，而应用程序容器则不能
它们必须在应用程序容器启动之前运行完成，而应用程序容器是并行运行的，所以 Init 容器能够提供了一种简单的阻塞或延迟应用容器的启动的方法，直到满足了一组先决条件

initC 的运行

在 Pod 启动过程中，Init 容器会按顺序在网络和数据卷初始化之后启动。每个容器必须在下一个容器启动之前成功退出
如果由于运行时或失败退出，将导致容器启动失败，它会根据 Pod 的 restartPolicy 指定的策略进行重试。然而，如果 Pod 的 restartPolicy 设置为 Always，Init 容器失败时会使用 RestartPolicy 策略
在所有的 Init 容器没有成功之前，Pod 将不会变成 Ready 状态。Init 容器的端口将不会在 Service 中进行聚集。正在初始化中的 Pod 处于 Pending 状态，但应该会将 Initializing 状态设置为 true
如果 Pod 重启，所有 Init 容器必须重新执行
对Init 容器 spec 的修改被限制在容器 image 字段，修改其他字段都不会生效。更改 Init 容器的image 字段，等价于重启该 Pod

注意事项

Init 容器具有应用容器的所有字段。除了 readinessProbe，因为 Init 容器无法定义不同于完成(completion)的就绪(readiness)之外的其他状态。这会在验证过程中强制执行
在 Pod 中的每个 app 和 Init 容器的名称必须唯一;与任何其它容器共享同一个名称，会在验证时抛出错误

总结图

2.mainC（Main Contain)

在Kubernetes中，Pod的生命周期包括多个阶段，其中mainc指的是主容器（Main Container）。主容器是Pod中实际运行用户应用程序的容器，它在所有初始化容器（init containers）成功执行并退出后开始启动。主容器的启动是Pod生命周期中的一个关键步骤，它标志着Pod准备提供服务的开始。

主容器可以包含启动前钩子（start hook）和关闭前钩子（pre stop hook），这些钩子允许在容器启动之前和关闭之前执行特定的命令或脚本。此外，主容器还可以定义就绪探针（readiness probe）和存活探针（liveness probe），这些探针用于监控容器的健康状态，并根据预设的规则采取相应的行动，如重新启动容器或将Pod标记为不可用

Pod是最小的可部署单元，它可以包含一个或多个容器。每个容器都有自己的入口点，通常是一个可执行文件或脚本，称为主进程（Main Process）。
当Pod启动时，容器的主进程会被启动并运行。主进程负责执行容器内的应用程序或服务。它可以是任何你在容器中定义的可执行文件，通常是应用程序的入口点。
并行过程，同时开始，可能有快有慢，但是确实是一起启动的

3.钩子

启动后钩子（初始化完成后）/启动前钩子（初始命令之前）

在初始化环境后可以先执行钩子，相当于执行了一条命令，可以挂载存储，下载代码，编译镜像，编译源码等等
钩子开始以后才开始执行启动命令，他比钩子执行的慢，但是不一定比钩子结束的慢，两个命令不能冲突。
官方说：无法保证启动命令一定在钩子之后完成

关闭前钩子

关闭的命令会被扣住，先执行钩子，比如数据保存，或者发个邮件之类的

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

Hook 的类型包括两种:

exec : 执行一段命令
HTTP : 发送 HTTP 请求

4.探针

探针的处理程序类型

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

ExecAction:在容器内执行指定命令。如果命令退出时返回码为0则认为诊断成功。
TCPSocketAction:对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开，则诊断被认为是成功的。
HTTPGetAction:对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 日小于 400，则诊断被认为是成功的

每次探测都将获得以下三种结果之一:

成功:容器通过了诊断
失败:容器未通过诊断
未知:诊断失败，因此不会采取任何行动

探针的种类

探针分为就绪探针与存活探针

readinessProbe:指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针，则默认状态为 Success
livenessProbe:指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其重启策略的影响。如果容器不提供存活探针，则默认状态为Success

就绪探针

readinessProbe

启动成功以后还需要准备时间，比如Tomcat就需要加载Java环境，可以去探针它的8080端口.如果没有就绪探针的话，那么没准备好就被负载均衡，那么用户是访问不到的
不是在容器启动就存在的，而是在容器启动一段时间之后才存在的，如果刚启动就问准备好了吗.那不用问就是没准备好，一般五秒一次探针，容器就绪以后就没有就绪探针了
当svc进行真实服务器选择的时候，会有标签选择器，只要你有这个标签，并且准备就绪了,那我就会把你拉进svc的集群中进行负载均衡，没就绪就不拉进来
虽然就绪探针是可有可无的，但是如果没有，在扩容的时候可能会有访问不到的情况，而加入了就绪探针就不会有这种情况
除了成功和失败还有第三种情况，未知，可能是代码错误，所以k8s会选择静默，什么也不做
未就绪就还是未就绪，等待下一次探测

存活探针

livenessProbe:

一直存在的，几秒一次都可以自定义，和就绪探针互不干扰。从容器创建以后的几秒开始，一直到关闭
如果死了就杀死容器，然后根据重启策略重新建立一个，默认是always。

示例

        livenessProbe:
          #表示容器的失败阈值为3次失败后，在一定的重试次数内，容器会被认为处于失败状态。
          failureThreshold: 3
          httpGet:
            path: /w/actuator/health
            port: 80
            scheme: HTTP
          #表示容器在启动后等待多久开始执行探测
          initialDelaySeconds: 10
          #表示容器重新进行探测的间隔时间
          periodSeconds: 5
          #表示探测成功的最小连续次数
          successThreshold: 1
          #表示探测过程中等待响应的超时时间
          timeoutSeconds: 2

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    velero.io/backup-name: wowjoy-dev
  name: node-pf-center
  namespace: wowjoy-dev
spec:
  #创建失败后的时间限制,超过十分钟就不会继续创建了
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      name: node-pf-center
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
    type: RollingUpdate
  template:
    metadata:
      labels:
        logging: "true"
        name: node-pf-center
    spec:
      containers:
      - env:
        - name: configFileName
          value: node-pf-center
        image: registry-hz.rubikstack.com/lichen/pf-node-center:1.0.1-f3261608-20231107
        imagePullPolicy: IfNotPresent
        #存活探针
        livenessProbe:
          failureThreshold: 3
          httpGet:
            path: /w/actuator/health
            port: 80
            scheme: HTTP
          initialDelaySeconds: 10
          periodSeconds: 5
          successThreshold: 1
          timeoutSeconds: 2
        name: node-pf-center
        ports:
        - containerPort: 80
          hostPort: 30666
          name: 80tcp306660
          protocol: TCP
        #就绪探针
        readinessProbe:
          failureThreshold: 3
          httpGet:
            path: /w/actuator/health
            port: 80
            scheme: HTTP
          initialDelaySeconds: 10
          periodSeconds: 5
          successThreshold: 2
          timeoutSeconds: 2
        resources: {}
        securityContext:
          allowPrivilegeEscalation: false
          capabilities: {}
          privileged: false
          readOnlyRootFilesystem: false
          runAsNonRoot: false
        stdin: true
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        tty: true
      dnsPolicy: ClusterFirst
      imagePullSecrets:
      - name: platform
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
status:

流程图