【星海出品】pod管理

活跃的煤矿打工人

于 2025-04-28 17:38:26 发布

阅读量491

点赞数 8

文章标签： k8s

本文链接：https://blog.csdn.net/weixin_41997073/article/details/147590308

版权

pod在整个生命周期过程中总会处于以下几个状态：

Pending：创建pod资源并存入etcd中，但尚未完成调度。
ContainerCreating： pod调度完成，处于容器创建的过程中，通常是在拉取镜像的过程中。
Running： pod中所有容器都已经成功创建，并且成功运行起来。
Succeeded： pod中所有容器都已成功终止并不会被重启。
Failed: 所有容器都已经终止，但至少有一个容器终止失败，也就是说容器返回了非0值的退出状态或者已经被系统终止。
Unknown: 因为某些原因无法获取pod的状态，这种情况通常是因为与pod所在的主机通信失败。

初始化容器（initcontainer）
一个pod可以拥有任意数量的init容器。
init容器是按照顺序以此执行的，并且仅当最后一个init容器执行完毕才会去启动主容器。

https://kubernetes.io/docs/concepts/workloads/pods/init-containers/#init-containers-in-use

对Pod健康状态诊断，分为3种： StartupProbe（启动探测）、LivenessProbe（存活性探测）、ReadinessProbe（就绪性探测）

Startup（启动探测）:探测容器是否正常运行
Liveness(存活性探测)：判断容器是否处于runnning状态，根据重启策略决定是否重启容器
Readiness(就绪性检测)：判断容器是否准备就绪并对外提供服务，将容器设置为不可用，不接受service转发的请求

存活探针：用于检测容器是否正在运行。如果失败，Kubelet 将杀死容器并根据重启策略重启。
就绪探针：用于检测容器是否准备好服务请求。如果失败，Pod 的 IP 地址将从 Service 的端点中移除。
启动探针：用于检测容器是否已经启动。如果失败，Kubelet 将杀死容器并重启。

三种探针用于Pod检测：

ExecAction：在容器中执行一个命令，并根据返回的状态码进行诊断，只有返回0为成功
TCPSocketAction：通过与容器的某TCP端口尝试建立连接
HTTPGetAction：通过向容器IP地址的某指定端口的path发起HTTP GET请求。

存活探针的核心作用

存活探针用于定期检查容器是否健康运行。如果检测失败（如应用无响应），Kubernetes 会：
终止当前容器
根据 Pod 的 restartPolicy 策略（默认 Always）重启容器

apiVersion: v1
kind: Pod
metadata:
  name: liveness
spec:
  containers:
  - name: myapp
    image: myapp:v1
    livenessProbe:
      tcpSocket:          # 探针类型：TCP 端口检查
        port: 8080        # 检查目标端口
      initialDelaySeconds: 3  # 容器启动后等待 3 秒再开始首次检查
      periodSeconds: 1        # 每隔 1 秒检查一次
      timeoutSeconds: 1       # 每次检查超时时间为 1 秒

扩展

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 5

livenessProbe:
  exec:
    command: ["cat", "/tmp/healthy"]

参数

initialDelaySeconds 0 容器启动后等待多久开始首次检查（需覆盖应用启动时间，避免误判）
periodSeconds 10 检查间隔（建议 ≥5 秒，避免频繁检查增加负载）
timeoutSeconds 1 单次检查超时时间（需 ≤ periodSeconds）
failureThreshold 3 连续失败次数阈值（达到后触发重启）
successThreshold 1 失败后恢复所需的连续成功次数（通常无需修改）

将 livenessProbe 块添加到目标容器的定义中
设置 initialDelaySeconds 略大于容器初始化时间。

kubectl describe pod liveness | grep -A 10 "Liveness"

常见问题与解决方案

探针误判健康
现象：应用未就绪时探针已开始检查。
解决：增大 initialDelaySeconds（如设为应用启动时间 + 2 秒）。
探针过于频繁
现象：应用负载高时探针检查导致性能下降。
解决：增大 periodSeconds（如设为 10 秒）。
探针超时
现象：应用响应慢导致探针失败。
解决：增大 timeoutSeconds 或优化应用性能。

示例

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
spec:
  containers:
  - name: myapp
    image: myapp:v1
    livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
      timeoutSeconds: 3
    readinessProbe:  # 就绪探针（控制流量接入）
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 5

kubectl logs 和事件分析 kubectl describe pod 进行查看

容器的重启策略

定义是否重启Pod对象。

Always：但凡Pod对象终止就重启，默认设置。
OnFailure：仅在Pod出现错误时才重启。
Never：从不。

注：一旦pod绑定到一个节点上，就不会重新绑定到另一个节点上，要么重启，要么终止

pod终止过程

用户发出删除pod命令：kubectl delete pod、kubectl delete -f
pod对象随着时间的推移更新，在宽限期内（默认情况下30秒），pod被视为dead状态
将pod标记为Terminating状态，同时启动pod关闭过程。
endpoints控制器监控到pod对象关闭，将pod与service匹配的endpoints列表中删除
如果pod中定义了preStop钩子处理程序，则pod被标记为Terminating状态时以同步的方式启动执行；若宽限期结束后，preStop仍未结束执行，第二步会重新执行并额外获得一个2秒的小宽限期
pod内对象的容器收到TERM信号
宽限期结束后，若存在任何一个运行的进程，pod会收到SIGKILL信号
kubelet请求API Server将此pod资源宽限期设置为0从而完成删除操作