一、Pod 启动过程到底发生了什么

Pod 从创建到真正可接流量，通常会经历这些阶段：

  1. 用户提交 Pod 定义，请求进入 API Server
  2. 调度器为 Pod 选择节点，此时常见状态是 Pending
  3. kubelet 开始拉取镜像并创建容器，常见状态是 ContainerCreating
  4. 如果配置了 Init Container，先执行初始化容器
  5. 主容器启动后，开始执行探针检查
  6. 健康检查通过后，Pod 才会被加入 Service 对应的 Endpoints

启动流程图：

Day009-k8s核心单元-Pod入门与实战-图4

这也是为什么很多 Pod 明明已经是 Running，却还不能真正对外提供服务。

二、Pod 退出时又会经历什么

Pod 删除也不是瞬间消失，它通常会进入优雅终止流程：

  1. API Server 接收到删除请求
  2. Pod 状态进入 Terminating
  3. 控制面开始把该 Pod 从 Endpoints 或 EndpointSlice 中摘除
  4. kubelet 向容器发送终止信号
  5. 超过宽限时间后，如果进程还没退出，再强制结束

退出流程图：

Day009-k8s核心单元-Pod入门与实战-图5

所以，删除 Pod 时真正影响业务的关键，不只是“删没删掉”，而是“流量有没有先被摘除、进程有没有被优雅结束”。

三、Pod 的三种探针分别管什么

Kubernetes 里最核心的三种探针是：

  • startupProbe
  • livenessProbe
  • readinessProbe

可以把它们分别理解成：

  • startupProbe：应用启动阶段，先别太早判我死
  • livenessProbe：运行过程中，如果我已经卡死，就把我重启
  • readinessProbe：如果我暂时处理不了流量，就先别把请求打给我

更通俗地说：

  • 启动探针管“别在启动期误杀我”
  • 存活探针管“死锁了就拉起我”
  • 就绪探针管“忙不过来时先别给我流量”

四、探针可以用哪几种检查方式

探针实现方式常见有四种：

  • Exec
  • TCPSocket
  • HTTPGet
  • gRPC

通常来说：

  • HTTPGet 最直观，也最常用于业务接口健康检查
  • TCPSocket 适合判断端口是否能连通
  • Exec 适合检查容器内部状态
  • gRPC 适合基于 gRPC 协议提供健康检查的服务

而探测结果通常只有三种：

  • success
  • failure
  • unknown

五、为什么没有探针时，Pod 看起来正常却访问失败

这是最典型的新手坑之一。

例如容器内部先 sleep 25，然后才真正启动 Nginx：

command:
- sh
- -c
- sleep 25; nginx -g "daemon off;"

如果完全不配置探针，Pod 可能很快拿到 IP，状态甚至显示 Running，但此时用 curl 去访问仍然会连接失败，因为应用其实还没准备好。

这也是为什么健康检查在生产环境里几乎是必配项。

六、livenessProbe 和 readinessProbe 应该怎么配

一个典型配置如下：

readinessProbe:
  httpGet:
    path: /index.html
    port: 80
    scheme: HTTP
  initialDelaySeconds: 10
  timeoutSeconds: 2
  periodSeconds: 5
  successThreshold: 1
  failureThreshold: 2
livenessProbe:
  tcpSocket:
    port: 80
  initialDelaySeconds: 10
  timeoutSeconds: 2
  periodSeconds: 5
  successThreshold: 1
  failureThreshold: 2

这几个参数里最重要的是：

  • initialDelaySeconds：启动后多久开始探测
  • periodSeconds：探测间隔
  • timeoutSeconds：单次超时时间
  • failureThreshold：连续失败几次才算真的失败

在实际排查里，如果 Pod 显示 Running 但 READY 还是 0/1，通常第一时间就该看探针配置和探针事件。

七、健康检查时间可以怎么算

一个很实用的估算公式是：

  • 第一次检查：initialDelaySeconds + timeoutSeconds
  • 总时间大致为：
initialDelaySeconds + timeoutSeconds + (periodSeconds + timeoutSeconds) * (failureThreshold - 1)

这在排查“为什么容器这么久才变 Ready”时非常有用。

八、慢启动应用为什么更适合加 startupProbe

有些应用启动非常慢，比如：

  • 需要预热缓存
  • 需要连接数据库和注册中心
  • 需要加载大量配置或模型文件

这时如果只有 livenessProbe，很容易在应用还没真正启动完成前就被误判失败并重启。

典型配置：

startupProbe:
  tcpSocket:
    port: 80
  initialDelaySeconds: 2
  timeoutSeconds: 2
  periodSeconds: 5
  successThreshold: 1
  failureThreshold: 20

再搭配 readinessProbe 和 livenessProbe，就能把“慢启动容忍”和“运行期故障恢复”分开处理。

如果应用启动命令是：

command:
- sh
- -c
- sleep 30; nginx -g "daemon off;"

那么 startupProbe 就能很好地避免在这 30 秒初始化期间被过早判死。

九、这部分最核心的理解是什么

把 Pod 生命周期和探针放在一起看，核心逻辑其实就一句话：

用户声明一个 Pod，不等于它已经可用；真正可用，要经过调度、容器创建、应用启动、探针通过和流量接入这整条链路。

而探针的存在，就是为了把“进程活着”和“服务可用”这两件事严格区分开。