lihaonihao333

菜单

Administrator
发布于 2026-08-13 / 6 阅读
0
0

第四章.k8s资源清单-Pod的生命周期4

#Kubernetes

来源链接：https://www.bilibili.com/video/BV1PbeueyE8V?spm_id_from=333.788.videopod.episodes&vd_source=0e85828f19fba96334ebaebea2da3e2f&p=19

Pod 资源清单核心字段回顾

然后是内容：

  • 接口组合版本：核心组 v1 版本
  • 资源类型：Pod
  • 元数据（Metadata）：定义Pod名称、所属命名空间、标签（Labels），标签需匹配关联Service的标签选择器要求（如示例中要求标签包含 app=myapp 才会被Service匹配）
  • 规格（Spec）核心配置：
    • 期望容器组（Containers）：包含容器名称、镜像地址（如示例中的 myapp:v1.0）、镜像下载策略（IfNotPresent：本地存在镜像则不拉取，不存在再从远程仓库下载）

就绪探测（Readiness Probe）

readinessProbe:
httpGet:
port: 80
path: /index.html
initialDelaySeconds: 1
periodSeconds: 3

核心作用

仅当Pod的就绪探测通过时，Pod才会被关联的Service加入后端 endpoints，接入负载均衡向用户提供访问，避免流量转发到未准备就绪的Pod。

探测执行规则

从Pod创建开始，持续在整个容器生命周期内执行探测，并非仅探测一次：若后续探测失败，Pod会从就绪状态变为未就绪状态，自动从Service后端移除，停止承接流量。

常见探测方式

  1. HTTP GET 探测
    • 配置逻辑：向Pod指定端口发送HTTP GET请求，返回200状态码则判定为探测通过，否则失败。
    • 实验演示：
      • 示例配置：探测80端口的/index1.html路径，延迟1s开始探测，每3s进行一次重复探测。
      • 现象：因示例镜像中不存在index1.html文件，探测持续失败，Pod状态为Running但未就绪，虽标签匹配Service，但不会被加入负载均衡；手动进入Pod容器，在/usr/local/nginx/html/目录下创建index1.html文件后，探测通过，Pod变为就绪，自动接入负载均衡，访问可正常返回200。
  2. Exec 命令探测
    • 配置逻辑：在Pod容器内执行指定命令，命令退出码为0则判定为探测通过，否则失败。
    • 示例：执行test -f /tmp/live判断文件是否存在，文件存在则通过，否则失败。
  3. TCP Socket 探测
    • 配置逻辑：尝试与Pod指定端口建立TCP连接，连接成功则判定为探测通过，否则失败。
    • 注意：该方式使用率低，仅作补充了解，因为端口监听状态不代表服务一定可用（如服务死锁但端口仍处于监听状态）。

关键结论

就绪探测是保障服务流量的核心机制，可避免未准备就绪的Pod承接用户流量，建议所有对外提供服务的Pod都配置就绪探测。

存活探测（Liveness Probe）

核心作用

解决“容器进程存在但服务已损坏”的问题（如进程死锁、死循环、服务假死等），保障运行的Pod一定可正常提供服务，出现故障时自动恢复，实现自愈。

核心配置参数

参数 默认值 最小值 说明
initialDelaySeconds 0s 0s Pod启动后首次探测的延迟时间
periodSeconds 10s 1s 两次探测之间的间隔时间
timeoutSeconds 1s 1s 单次探测的超时时间，超时即判定为失败
successThreshold 1 1 探测成功的阈值，达到次数即标记为存活
failureThreshold 3 1 探测失败的阈值，达到次数即触发后续处理

探测行为规则

  • 探测成功：静默处理，不执行任何操作
  • 探测失败：根据Pod配置的重启策略执行操作，注意此处的“重启”实际为重建：K8s会杀死当前故障容器，创建全新的同规格容器替换原有容器，并非重启原有容器进程。

默认重启策略

  • Always（默认策略）：无论容器以0（正常退出）还是非0（异常退出）退出码终止，都会触发容器重建
  • OnFailure：仅容器以非0退出码终止时触发重建
  • Never：无论容器如何终止，都不会触发重建

常见探测方式及实验演示

  1. Exec 命令探测
    • 示例配置：容器启动后先执行touch /tmp/live创建文件，休眠60s后删除该文件，再休眠3600s；存活探测执行test -e /tmp/live判断文件是否存在。
    • 实验现象：
      1. Pod创建后60s内文件存在，探测通过，Pod处于就绪状态
      2. 60s后文件被删除，探测失败，因默认重启策略为Always，触发容器重建，新Pod启动后会重新创建/tmp/live文件，再次进入就绪状态
      3. 新Pod运行60s后文件再次被删除，探测再次失败，再次触发重建，Pod重启次数持续增加
    • 验证结论：存活探测会持续执行，失败后会重建容器，且新容器与原有容器是完全独立的实例。
  2. HTTP GET 探测
    • 示例配置：探测80端口的/index.html主页，延迟1s开始探测，每3s探测一次，超时3s判定为失败。
    • 实验演示：进入运行中的Pod容器，将/usr/local/nginx/html/下的index.html改名为index.html.backup，此时主页文件不存在，HTTP探测返回404失败，存活探测判定失败，触发容器重建；再次进入新Pod的对应目录查看，仅存在默认的index.html文件，原有的备份文件已消失，证明是全新容器被创建，原有故障容器已被杀死。
  3. TCP Socket 探测
    • 配置：延迟5s开始探测，超时1s，探测80端口的TCP连接。
    • 注意：该方式不推荐使用，仅作了解，因为端口通仅代表端口处于监听状态，不代表服务可正常处理请求。

关键结论

  • 未配置存活探测的Pod，可能出现容器运行但服务无法正常提供的情况，无法自动恢复，建议所有对外提供服务的Pod配置存活探测
  • 存活探测是K8s实现应用自愈的核心机制之一，可自动处理服务故障场景

AI 总结

主要讲解了Kubernetes Pod生命周期中就绪探测与存活探测的核心概念、配置方式及实验验证。就绪探测用于控制Pod是否接入Service承接流量，保障流量仅转发到可用Pod；存活探测用于保障运行中Pod的服务可用性，故障时自动重建实现自愈。两种探测均支持HTTP GET、Exec命令、TCP Socket三种实现方式，其中HTTP GET与Exec方式为常用方案，TCP Socket方式因局限性仅作补充了解。同时明确了Pod重启策略的默认规则，以及存活探测失败后的重建机制，强调了两类探测对于生产环境服务稳定性的重要价值，建议所有对外服务的Pod都配置对应的探测机制。

相关常用命令及细节补充

  • 查看Pod完整配置（含默认参数）：kubectl get pod <pod名> -o yaml，可查看重启策略等默认配置
  • 监视Pod状态变化：kubectl get pod -w，资源对象变更时仅打印变化部分，无需重复查询
  • 查看Pod事件与状态详情：kubectl describe pod <pod名>，可查看探测失败的具体原因（如404、超时等）
  • 查看Pod所在节点：kubectl get pod -o wide
  • 进入Pod容器执行命令：kubectl exec -it <pod名> -- <要执行的命令>，若Pod内仅有一个容器，可省略-c <容器名>参数
  • Pod内容器命名规则：k8s_<容器名>_<Pod名>_<命名空间>_<MD5哈希值>_<启动序号>，启动序号代表该容器是Pod内该容器的第几次启动实例，0为首次启动，1为第二次，以此类推
  • 查看Pod重启次数：kubectl get pod输出的RESTARTS列会显示该Pod的重启总次数
第四章.k8s资源清单-Pod的生...
第四章.k8s资源清单-Pod的生...

评论