11-Init Container 与 Sidecar

Init Container 与 Sidecar概念引入到目前为止你创建的 Pod 都只有一个容器。单容器就像一人工作室——简单但能力有限。生产环境中Pod 里经常跑多个容器主要有两种模式Init Container运行完就退出完成后再启动主容器像装修队——装完就走业主再入住Sidecar和主容器一起运行提供辅助功能像保安——24 小时和你一起提供保护Sidecar 模式App 容器一直运行Sidecar: 日志收集一起运行Sidecar: Envoy 代理一起运行Init Container 模式完成退出完成退出Init: wait-for-dbInit: run-migrationApp 容器启动单容器 PodApp原理讲解Init Container按顺序执行的前置任务Init Container 的关键特性特性说明顺序执行多个 Init Container 按定义顺序依次执行前一个完成才启动下一个必须成功Init Container 必须成功退出exit 0否则 Pod 一直处于Init:Error状态独立镜像可以用和主容器完全不同的镜像主容器用 Node.jsInit 用 busybox 就够了独立资源Init Container 有自己的 volume 挂载和资源请求apiVersion:v1kind:Podmetadata:name:app-with-initspec:initContainers:# Init 1: 等待数据库就绪-name:wait-for-dbimage:busybox:1.36command:[sh,-c,until nslookup db-svc; do echo waiting...; sleep 2; done]# Init 2: 执行数据库迁移-name:db-migrateimage:myapp:latestcommand:[npm,run,migrate]containers:-name:appimage:myapp:latestports:-containerPort:3000✅ DB 可达✅ 迁移完成❌ 一直连不上Pod 创建Init 1: wait-for-db⏳ nslookup 循环等待Init 2: db-migrate 跑 SQL migrationApp 容器启动 服务就绪Init:ErrorPod 不会启动 AppSidecar辅助服务的容器Sidecar 和主容器同时运行通过共享资源volume、network协作apiVersion:v1kind:Podmetadata:name:app-with-sidecarspec:volumes:-name:logsemptyDir:{}containers:# 主容器写日志-name:appimage:nginx:1.27volumeMounts:-name:logsmountPath:/var/log/nginx# Sidecar收集并转发日志-name:log-shipperimage:busybox:1.36command:[sh,-c,tail -f /logs/access.log]volumeMounts:-name:logsmountPath:/logsPod: app-with-sidecar共享 Volume (logs)emptyDirApp 容器 (nginx)写入 access.logSidecar (log-shipper)读取 转发用户请求日志平台(Elasticsearch/Loki)Init Container vs Sidecar vs 多容器对比维度Init ContainerSidecar普通多容器运行时机主容器之前和主容器同时和主容器同时退出行为必须成功退出一直运行一直运行典型用途等依赖、初始化、迁移日志收集、代理、监控紧密耦合的服务生命周期执行完就结束和 Pod 同生命周期和 Pod 同生命周期经典场景场景用什么为什么等数据库就绪再启动Init Container阻塞式等待不需要一直跑运行数据库 migrationInit Container跑完一次就行从 Vault 拉取密钥Init Container启动前拉一次就够了收集应用日志Sidecar需要持续读取代理/服务网格EnvoySidecar代理所有进出流量健康检查上报Sidecar持续向监控系统汇报动手实验配套实验位于docs/labs/beginner/init-container-sidecar/本实验模拟Init Container 等待依赖就绪 → Sidecar 持续收集日志。步骤 1部署实验环境cddocs/labs/beginner/init-container-sidecarbashsetup.sh步骤 2观察 Init Container 执行顺序# 观察 Pod 状态变化kubectl get pods-w# 你会看到Pending → Init:0/2 → Init:1/2 → Init:2/2 → PodInitializing → Running# 查看 Init Container 日志kubectl logs app-with-init-sidecar-cwait-for-svc kubectl logs app-with-init-sidecar-cinit-config步骤 3验证 Sidecar 日志收集# 主容器产生一些访问日志kubectlexecapp-with-init-sidecar-capp --curl-slocalhost# 查看 Sidecar 收集到的日志kubectl logs app-with-init-sidecar-clog-collector步骤 4清理bashteardown.sh自检问题[基础]Init Container 和普通 Container 的启动顺序有什么区别如果 Init Container 失败了 Pod 会怎样[理解]以下场景分别适合 Init Container 还是 Sidecar① 数据库建表 ② 实时日志收集 ③ 从外部拉取配置文件到共享卷 ④ 代理所有出站流量[应用]你的应用需要等 Redis 启动后才能运行还需要在启动前执行数据预热脚本。Pod 里应该有几个 Init Container几个普通 Container查看答案Init Container 先于普通 Container 执行且多个 Init Container 按定义顺序依次执行。只有所有 Init Container 都成功退出后普通 Container 才会启动。如果 Init Container 失败exit ! 0Pod 会一直处于Init:Error状态并不断重试主容器永远不会启动。① Init Container跑一次建表脚本就行② Sidecar需要持续 tail 转发③ Init Container拉一次挂到共享卷即可④ Sidecar作为代理持续运行。需要2 个 Init Container 1 个普通 Container。Init 1wait-for-redisnslookup 循环等 Redis 就绪。Init 2data-warmup执行预热脚本。普通 Container你的应用本身。预热脚本因为依赖 Redis所以需要放在wait-for-redis之后。 本文来自 K8s Guide —— 开源免费的 Kubernetes 中文学习指南️ 初学者轨道 面试轨道从零基础到拿 Offer 一站式覆盖 每篇文章配套 Kind 实验脚本本地一键运行 本文源码docs/beginner/20-gateway-api.md⭐ 如果对你有帮助欢迎 Star github.com/callmebg/k8s-guide