KubernetesPod生命周期与应用最佳实践

### Kubernetes 中 Pod 生命周期管理与客户端请求处理最佳实践 #### 1. Pod 生命周期基础 在 Kubernetes 里，容器运行方式不同，会影响其主进程。第一种形式的容器直接将 `mybinary` 可执行文件作为主进程运行；而第二种形式则是以 shell 作为主进程，`mybinary` 进程作为 shell 进程的子进程运行。 需要注意的是，生命周期钩子是针对容器，而非 Pod。像 `post-start` 和 `pre-stop` 这类钩子，与容器相关。不能用 `pre-stop` 钩子来执行 Pod 终止时才需要的操作，因为 `pre-stop` 钩子是在容器终止时被调用（可能是因为存活探针失败），这在 Pod 的生命周期里可能会多次发生，并非只在 Pod 关闭时触发。 #### 2. Pod 关闭流程解析 Pod 的关闭由通过 API 服务器删除 Pod 对象触发。当 API 服务器收到 HTTP DELETE 请求时，不会立刻删除对象，而是设置 `deletionTimestamp` 字段。设置了该字段的 Pod 就处于终止状态。 Kubelet 察觉到 Pod 需要终止后，会开始逐个终止 Pod 内的容器。它会给每个容器一定时间进行优雅关闭，这段时间就是终止宽限期，可针对每个 Pod 进行配置。终止流程开始，计时器就启动，随后按以下顺序执行： 1. 若配置了 `pre-stop` 钩子，则运行该钩子并等待其完成。 2. 向容器的主进程发送 `SIGTERM` 信号。 3. 等待容器优雅关闭，或者直到终止宽限期结束。 4. 若容器还未优雅终止，就用 `SIGKILL` 强制终止进程。 下面是这个过程的 mermaid 流程图： ```mermaid graph LR classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px; classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px; A([开始]):::startend --> B(设置 deletionTimestamp):::process B --> C(Kubelet 开始终止容器):::process C --> D{是否有 pre - stop 钩子?}:::process D -->|是| E(运行 pre - stop 钩子):::process D -->|否| F(发送 SIGTERM 信号):::process E --> F F --> G(等待优雅关闭或宽限期结束):::process G --> H{是否优雅关闭?}:::process H -->|是| I([结束]):::startend H -->|否| J(发送 SIGKILL 强制终止):::process J --> I ``` #### 3. 终止宽限期的配置 终止宽限期可在 Pod 规范中通过设置 `spec.terminationGracePeriodSeconds` 字段来配置，默认值是 30 秒，即 Pod 内的容器会有 30 秒时间进行优雅关闭，之后才会被强制终止。 建议将宽限期设置得足够长，让进程有时间完成清理工作。也可以在删除 Pod 时覆盖 Pod 规范中指定的宽限期，例如： ```bash $ kubectl delete po mypod --grace-period=5 ``` 这会让 Kubelet 等待 5 秒，让 Pod 优雅关闭。当 Pod 内所有容器停止后，Kubelet 会通知 API 服务器，Pod 资源最终被删除。若要强制 API 服务器立即删除资源，不等待确认，可以将宽限期设为 0 并添加 `--force` 选项： ```bash $ kubectl delete po mypod --grace-period=0 --force ``` 不过使用这个选项要谨慎，特别是对于 StatefulSet 的 Pod。StatefulSet 控制器会确保同一时间不会运行同一个 Pod 的两个实例。强制删除 Pod 可能会让控制器在被删除 Pod 的容器还未关闭时就创建替换 Pod，导致同一 Pod 的两个实例同时运行，使有状态集群出现故障。只有在确定 Pod 不再运行，或者无法与集群其他成员通信时，才强制删除有状态 Pod。 #### 4. 应用程序的关闭处理 应用程序应在收到 `SIGTERM` 信号时启动关闭程序，完成后终止。也可以通过 `pre-stop` 钩子通知应用程序关闭。但如果无法预测应用程序优雅关闭所需的时间，比如分布式数据存储应用，在缩容时，一个 Pod