Init Container 和 Sidecar 容器分别解决什么问题？K8s 1.29 的原生 sidecar 改进了什么？

结论：Init Container 在 Pod 主容器启动前串行执行，用于前置准备（等依赖就绪、初始化数据、生成配置、迁移数据库），全部成功才启动主容器；Sidecar 与主容器并行运行，提供伴随能力（日志采集、代理、配置热更）。K8s 1.29+ 的原生 sidecar（initContainers 里设 restartPolicy: Always）修复了传统 sidecar 的生命周期缺陷。

展开：传统 sidecar（普通 container 充当）的三个痛点：1）Job 场景主容器跑完了 sidecar 还在跑，Pod 永不 Completed；2）启动顺序无保证——主容器起来时 sidecar 代理可能还没就绪，流量丢失；3）探针/资源核算混乱。原生 sidecar 的语义：按 init 顺序启动、就绪后才放行下一个 init 和主容器，Pod 终止时最后关闭；对 Job，主容器完成后 sidecar 自动退出。Init Container 的要点：串行执行、任一个失败按 restartPolicy 重试、资源 requests 取所有 init 的最大值（而非求和）与主容器求和值二者取大——配额核算的常考点。

initContainers:
- name: wait-db
  image: busybox
  command: ['sh', '-c', 'until nc -z db 5432; do sleep 1; done']
- name: log-agent                    # 原生 sidecar
  image: fluent-bit
  restartPolicy: Always

易错点：Init Container 不适合放常驻进程（旧版直接阻塞后续启动）；sidecar 与主容器共享网络和存储卷，这是它能工作的前提。追问方向：service mesh 从 sidecar 到 ambient（无 sidecar）模式的演进、Pod 就绪 Gates 的用途。