题干与适用场景
你负责把一个已经运行在 Kubernetes 上的日志代理、服务网格代理或本地缓存守护进程，从“普通容器”迁移为 Kubernetes 原生 sidecar。应用容器必须先等代理完成准备，代理异常时要有明确的可用性边界；系统还要支持 Job、滚动发布、资源配额和回滚。请给出迁移方案，并说明如何处理版本差异、探针、终止顺序和故障。
这是一道 system-design 题。面试重点是边界与取舍，而不是背诵 YAML。回答应覆盖生命周期、兼容性、资源、可观测性和回滚。
面试官在考察什么
- 能否把业务 SLO 转成启动、就绪、终止和失败策略。
- 能否解释原生 sidecar 与普通容器、独立 Deployment 或 DaemonSet 的边界。
- 能否识别 API server、节点、webhook 和客户端之间的版本风险。
- 能否用资源预算、发布分批、指标和回滚降低迁移风险。
- 能否处理 Job 完成、代理卡死、探针失败和节点升级等反例。
Amazon 的 SDE II 面试准备材料把系统设计评价归纳为实用性、准确性、效率、可靠性、优化与扩展性；本题还要把这些目标落到 Pod 生命周期和发布控制上。
回答前需要澄清的问题
- 代理是每个 Pod 一份，还是每个节点一份？它是否必须与应用共享网络命名空间或卷？
- 应用在代理未就绪时能否接收流量？启动失败时是阻断发布、降级，还是允许旁路运行？
- 这是长驻服务、一次性 Job，还是两者都有？终止时需要先 flush 日志或上传数据吗？
- 集群的 Kubernetes 版本、API server 与节点版本是否一致？Admission webhook、模板渲染器和客户端会不会丢弃未知字段？
- 代理的 CPU、内存、临时存储和网络预算是多少？它的故障是否算应用 SLO 的错误预算？
- 能否先在一个 namespace 或一小组 workload 灰度，并保留普通容器格式作为回滚开关？
30 秒回答框架
先定义目标：代理与应用同 Pod、按顺序启动、可观测、可回滚，且不能让代理无限期阻塞发布。然后说明实现：用 initContainers 中 restartPolicy: Always 的原生 sidecar，配置就绪探针和资源预算；用 admission 与集群版本检查守住兼容性。最后说发布：双模板灰度、比较启动时延和错误率，异常时切回普通容器或旧版本，并单独处理 Job 完成与终止 flush。
分步骤深入解答
1. 先画出生命周期边界
Kubernetes 原生 sidecar 是一种特殊的 init container：容器级 restartPolicy: Always 让它在 init 阶段启动后持续运行。它仍遵循 init 容器的启动排序，所以后续 init 容器和应用容器要等它进入可用状态才继续。这样可以把“代理先准备”写成 Pod 的结构约束，而不是由应用脚本轮询。
应用与 sidecar 共享 Pod 的网络和存储命名空间。需要共享 Unix socket、日志卷或本地代理端口时，这个边界很清晰；若代理只需要节点级能力，则应评估 DaemonSet，避免为每个 Pod 重复消耗资源。
2. 定义 readiness 与故障策略
为代理设置能代表真实服务能力的 readinessProbe，例如检查控制面配置已加载、监听端口可用、关键证书未过期。sidecar 的 readiness 会影响 Pod ready 状态，因此探针失败可能把流量从整个 Pod 摘除。探针只能表达状态，不能替代重试、限流和降级策略。
需要明确三种失败：启动失败、运行中崩溃、依赖暂时不可用。启动失败通常阻止 Pod 进入可服务状态；运行中崩溃由 Always 重启，但要通过重启次数、恢复时延和错误率监控是否已超出 SLO。若代理只是增强能力，可设计应用旁路或旧路径；若代理负责安全鉴权，则应 fail closed，并在发布控制器中快速停止扩散。
3. 处理终止、Job 与 flush
原生 sidecar 会在应用容器之后终止，多个 sidecar 按反向顺序关闭。日志代理因此可以在应用退出后继续读取缓冲并 flush，但必须设置可接受的 termination grace period；flush 超时应记录丢失量并结束，不能无限等待。
对 Job，要验证控制器把主容器结束视为完成，而不会因为 sidecar 永久运行而卡住。sidecar 可能在 Job 完成前继续重启，所以应把“主任务结果”“sidecar flush 结果”和“最终数据完整性”分成不同指标与告警。
4. 做版本与变更链路检查
原生 sidecar 在 Kubernetes v1.33 已稳定并默认启用；相关能力在 v1.29 起作为 beta 默认开启。迁移前仍要逐节点确认 kubelet、API server 和 admission 组件的实际版本与 feature gate。
旧的 mutating webhook、模板工具或客户端可能不认识容器级 restartPolicy，并在修改对象时把字段丢掉。应在 CI 对最终提交对象做 schema 检查，在 admission 日志中记录 sidecar 形态，并用一个探针 Pod 验证实际运行时行为。无法保证链路一致时，保留普通容器模板作为 fallback，或暂停迁移。
5. 计算资源与调度影响
sidecar 不是免费附加项。它的 CPU、内存和临时存储请求会参与 Pod 的有效资源计算，影响 QoS、配额和调度。迁移前应以应用峰值、代理启动峰值和缓冲上限计算 request/limit，观察节点碎片、驱逐、OOM 和启动排队时间。
如果 sidecar 需要独立扩缩容、不同发布节奏或更宽的故障域，独立 Deployment 可能比同 Pod 更合适。原生 sidecar 的收益是本地共享与生命周期顺序，代价是两者共享调度、资源和发布单元。
6. 设计灰度、观测与回滚
准备两种 Pod 模板：原生 sidecar 与旧普通容器。按 namespace、标签或工作负载分批放量，每批设置自动停止条件。核心指标至少包括 Pod 从创建到 Ready 的时延、sidecar readiness 失败率、重启次数、应用请求错误率、代理缓冲深度、flush 丢失量、CPU/内存峰值和 Job 完成时延。
迁移期间要记录“期望形态”和“实际形态”，避免只看 Deployment 成功。若 webhook 丢字段、Ready 时延回归或代理重启超阈值，停止扩散并切换旧模板。回滚不仅是改镜像，还要确认旧模板不会残留新配置、卷格式或端口假设。
7. 把安全与可观测性放进边界
sidecar 与应用共享网络和卷，意味着它拥有同一 Pod 的访问面。为代理设置最小权限、只读根文件系统、明确的服务账号和网络策略；不要因为“只是辅助容器”而跳过审计。日志、指标和 trace 要带 Pod、容器与发布版本标签，才能区分应用故障和代理故障。
高质量示范回答
我会先把代理定位为每个 Pod 的本地依赖，并确认它确实需要共享网络或卷；若是节点级能力，我会选 DaemonSet。迁移模板使用 Kubernetes 原生 sidecar：把代理放到 init containers，并设置容器级 restartPolicy: Always。它先按 init 顺序启动，readinessProbe 表达配置和端口已准备，应用容器再进入服务。
我会把失败拆成启动失败、运行崩溃和依赖暂时不可用。安全代理采用 fail closed；可选增强能力保留旁路。终止时利用 sidecar 在应用之后关闭的顺序完成 flush，并给 grace period 上限。Job 单独验证主容器完成与 sidecar flush，不让长期运行的 sidecar 阻塞 Job 状态。
上线前检查 API server、每个节点、feature gate、webhook 和模板客户端，因为旧工具可能丢弃 restartPolicy。CI 校验最终对象，灰度环境验证实际 Pod 顺序和 readiness。资源预算把代理峰值计入 Pod 的 QoS、配额和调度，监控 Ready 时延、重启、错误率、缓冲和丢失量。发布采用新旧双模板分批放量，任何阈值越界就停止并回滚旧模板。这样既利用了原生生命周期保证，也把版本、资源和故障边界变成可观测的发布门槛。
常见错误
- 只贴一段 YAML，不解释为什么需要原生 sidecar，以及普通容器或独立工作负载何时更合适。
- 把
restartPolicy: Always写成 Pod 级字段，忽略它必须位于 sidecar 容器定义中。 - 只设置 livenessProbe，没说明 readiness 失败如何影响流量和发布。
- 假定 Kubernetes 版本满足要求，却没有检查节点、webhook 和客户端的版本偏差。
- 认为 sidecar 不影响资源配额，漏算启动峰值、缓冲和 QoS。
- 只验证长驻服务，忘记 Job 完成、flush 超时和反向终止顺序。
- 回滚时只改镜像，不验证旧模板、端口、卷和 admission 变更是否一致。
追问及应对
如果旧节点不支持原生 sidecar，怎么办？
先停止放量并按节点池隔离。若不能保证对象在旧链路中保留容器级策略，就使用普通容器模板或升级节点；不要把未知字段丢失当作成功兼容。
sidecar readiness 一直失败会怎样？
Pod 不应进入 Ready，发布控制器应停止扩散。随后区分配置错误、依赖不可用和探针误报，修复或回滚；不能用无限放宽探针来掩盖真实不可用。
Job 的主容器结束后，sidecar 还在运行吗？
原生 sidecar 可以继续运行并重启，但 Job 控制器可以识别主容器完成。应设置 flush 上限并分别记录任务结果与数据完整性，避免把 sidecar 的长期运行误判为任务失败。
为什么不把代理拆成独立 Deployment？
如果代理需要独立扩缩容、独立发布或更大的故障域，拆分更合理；如果必须共享本地 socket、网络和严格启动顺序，原生 sidecar 更直接。选择取决于耦合度与 SLO。
迁移后资源压力变大，如何定位？
比较迁移前后 Pod 有效 request、启动峰值、节点碎片、驱逐和 OOM，检查代理缓冲与并发。若 sidecar 只是共享节点能力，评估 DaemonSet；若必须同 Pod，调整预算或降低灰度规模。
如何证明回滚真的安全？
保留旧模板哈希，回滚时验证对象中的容器形态、端口、卷、服务账号和 webhook 输出，并观察一批 Pod 的 Ready 时延、错误率和 flush 丢失量。指标恢复后再继续扩散。