Pod与容器生命周期管理：Init容器、探针、资源限制、重启策略
核心知识结构
| 能力维度 | 关键技术点 | 面试高频词 |
|---|---|---|
| Init容器 | 串行初始化、依赖等待、工具镜像分离 | initContainers、失败重启、资源预留 |
| 探针 | liveness/readiness/startupProbe | 探测方式、超时、初始延迟、优雅停止 |
| 资源限制 | requests/limits、QoS、OOMKill | Guaranteed/Burstable/BestEffort、LimitRange |
| 重启策略 | Always/OnFailure/Never、backoff | CrashLoopBackOff、Pod原地重启 vs 重建 |
面试问答卡片
📌 面试问题：Init容器与普通容器的区别是什么？什么时候必须用Init容器？
🎯 考察点：对Pod初始化流程的理解；是否区分过init容器在资源调度与容器重启策略上的特殊性。
📐 回答框架：定义区别（串行/工具镜像/失败重启）→ 典型场景（等待数据库就绪/数据准备/权限配置）→ Init容器重启策略（失败则Pod重启）。
💬 示例回答：Init容器串行执行，成功后才启动业务容器。它使用独立镜像可避免引入依赖，且失败后Pod会整体重启。常见场景：等待外部服务可用、注入配置文件、执行数据库迁移。注意Init容器不参与探针检查。
🔍 可能追问：Init容器共享哪些资源？（网络、存储卷，不共享进程命名空间）如果Init容器一直失败怎么办？（增加重试间隔，最终被evict）Init容器支持资源限制吗？（支持，且影响Pod QoS）
📌 面试问题：liveness探针和readiness探针的区别？如何配置一个优雅的启动探针？
🎯 考察点：对健康检查机制的本质理解；是否踩过“探针配置不合理导致滚动更新失败”的坑。
📐 回答框架：三类探针定义 → 配置要点（initialDelaySeconds/periodSeconds/timeoutSeconds）→ 启动探针适用场景（慢启动应用）→ 滚动更新中readinessProbe作用。
💬 示例回答：liveness探针决定是否重启容器，readiness决定是否加入Service服务端点。配置启动探针可避免慢启动应用被误杀：设置initialDelaySeconds=60、failureThreshold=5。生产经验：readiness探针应检测应用业务接口，而非仅进程存活。
🔍 可能追问：探针的三种类型（HTTP/TCP/Exec）各自适用场景？探针超时没响应会怎样？（视为失败，计入失败次数）如何用startupProbe保护旧版本应用？（设置足够大的失败阈值，平滑过渡）
📌 面试问题：Pod被OOMKill后Kubelet会如何反应？如何根据业务特性设置合理资源限制？
🎯 考察点：对Kubernetes资源管控机制的深度理解；是否具备QoS分级、LimitRange、PodDisruptionBudget等生产经验。
📐 回答框架：OOMKill触发条件（实际内存>limit）→ 重启行为（取决于restartPolicy）→ QoS分类（Guaranteed/Burstable/BestEffort）→ 生产建议（限制不宜过低/设置LimitRange/结合HPA）。
💬 示例回答：Pod因OOM被kill后，Kubelet根据restartPolicy决定是否重建。若Always则立即重启。设置资源限制应基于压测数据：requests=平时峰值的70%，limits=峰值+20%缓冲。建议通过LimitRange约束命名空间，避免BestEffort Pod影响稳定性。
🔍 可能追问：OOMKill与Node压力驱动的Pod eviction有什么区别？（OOM是cgroup层，eviction是kubelet层）CPU限制软限制还是硬限制？（CPU是压缩资源，可超分但会被限流）重启策略OnFailure与Always在Job场景下的区别？
项目案例模板
项目名称：基于Kubernetes的微服务容器化平台（生命周期治理）
业务背景：某在线教育平台从虚拟机迁移至Kubernetes，解决资源利用率低、服务启动慢、健康检查不可靠等生产问题。
规模指标：3000+ Pod实例、200+微服务、5个生产K8s集群、每日滚动更新约150次。
技术栈：Kubernetes 1.20+、Docker、Prometheus、HPA、LimitRange、PodDisruptionBudget。
核心难点：
- Java应用启动慢（30s+），liveness探针过早触发导致CrashLoopBackOff
- 部分服务内存抖动频繁OOM，QoS全部BestEffort导致调度不稳定
- Init容器长时间阻塞后续容器启动，缺乏超时机制
面试高频追问：
- 你们如何排查OOM问题？用了什么工具？（kubectl describe/exec into container/查看cgroup stats）
- Init容器超时怎么解决的？（设置activeDeadlineSeconds，依赖超时由应用层处理）
- 滚动更新时readiness探针失效如何发现？（结合Prometheus监控端点移除事件）
- 你们用preStop hook做过什么？（优雅关闭：发送SIGTERM，等待10s后强制终止）
可迁移回答话术：“我们建立了生命周期治理规范：所有服务必须配置startupProbe（初始延迟基于压测数据+50%冗余）、readinessProbe检测业务健康接口、设置requests/limits比例为1:1.2~1:1.5。对于初始化依赖，使用Init容器+超时兜底，必要时以Job替代Init容器实现更灵活的超时重试。”