Kubernetes Pod容器分类与多容器部署实践

先问一句你有没有想过为什么Kubernetes宁可定义Pod这样一个比容器大一圈的抽象而不是把一个个容器直接扔给调度器我第一次接触Pod的时候总觉得这是多此一举——容器本身已经够轻了再在外面套一层“组”的概念似乎只会增加理解成本。后来真正开始维护多容器业务才意识到这个设计有多关键。Pod不是简单包了一层壳它是把Linux里的“进程组”思想搬到了集群层面让调度器、网络、存储和生命周期都能围绕一个整体来运作。这篇文章想做的事很简单把Pod的运行机制和容器分类讲透。我会从最容易被忽略的pause容器讲起再到init容器、sidecar容器和业务容器的分工接着拆解Pod内部网络和存储是怎么共享的然后从生命周期、资源QoS、调度模型几个维度重新审视容器分类。无论你是在准备认证考试被面试官追问过“Pod里能不能跑多个容器”还是正在排查线上一个诡异的端口冲突这篇文章都应该能帮到你。1. 为什么Kubernetes没有直接调度容器而是定义了Pod1.1 单容器“裸奔”时的协作困境先想象一个最简单的业务一个Web服务一个日志采集进程一个配置同步小工具。如果不引入Pod的概念让这三个服务各自跑在独立容器里你会立刻遇到几件麻烦事。生命周期不一致是最头疼的。主业务容器可能因为发布、崩溃被反复创建销毁但旁边的日志采集容器还活着它读不到新的日志甚至会把旧容器的日志和当前容器的日志混在一起。反过来如果日志采集容器先挂了主业务容器还在跑磁盘上的日志没人管等你想排查问题的时候才发现关键时间段的历史记录已经丢了。网络和存储也不统一。三个容器各自有自己的IP地址和文件系统彼此要通信得走网络而不是直接读写共享目录要做服务发现还得依赖额外的注册中心。某一次临时调试要手动往某个目录塞一个配置文件你会发现根本塞不进去——除非你预先做了共享卷的规划。这些都是可以解决的但解决起来非常繁琐而且每套业务都得重复一遍。1.2 Pod模型把“进程组”从操作系统搬到集群熟悉Linux的人都知道进程组、会话这些概念解决的就是“一组进程需要一起管理”的问题。你在终端里启动一个前台程序它可能会fork出多个子进程CtrlC一按整个进程组都会收到信号一起退出。这种粒度比单个进程粗比整台机器细刚好适合组织服务。Kubernetes的Pod做的就是类似的事它把多个容器放进同一个“部署单元”这些容器共享同一个网络命名空间、同一个UTS命名空间主机名、同一个IPC命名空间还可以通过挂载卷共享同一份文件。这样一个Web容器和一个日志采集容器可以像在同一个进程组里一样工作一起被创建、一起被调度、一起被销毁彼此之间通过localhost就能通信。你可以把Pod理解成一栋小公寓楼楼里的住户是各个容器楼里的走廊和管道是共享的网络和存储楼本身是它们共同面对的调度、扩缩容和服务发现单元。一栋楼既可以只住一户人家也可以住两户协作的邻居但整栋楼是一起对外租赁的不会出现“一户搬走了另一户还留在原地址”的情况。1.3 Pod是调度器的唯一“眼里的对象”更关键的一点是调度器只认Pod不认容器。它计算的是Pod整体需要多少CPU、多少内存然后找一个能装下整个Pod的节点。扩容时也是按Pod的数量来扩不会说某个容器扩到10个、另一个容器扩到3个。服务发现和负载均衡同样以Pod为粒度一个Pod对应一个IP访问流量通过Service负载到这个IP上。这个抽象带来的结果就是你在Kubernetes里几乎不会直接操作容器日常创建、删除、更新、排障的对象都是Pod。尤其是当你用Deployment管理应用时Pod只是控制器手里的“模板实例”坏了就重建一个新的重建出来的容器可能是新的镜像但Pod本身依然是调度、网络、存储的最小边界。理解了这一层之后Pod内部的容器分类才有了意义。接下来我拆开外壳看看里面到底跑着哪几类容器。2. Pod内部的容器骨架pause容器、init容器与业务容器的分工2.1 pause容器为什么是所有容器的“地基”很多人在第一次查看Pod里进程的时候会愣住我的业务镜像里明明只写了一个主进程为什么节点上多了一个奇怪的镜像在跑那个就是pause容器英文文档里也常叫infra container。创建Pod的时候容器运行时会先拉起一个pause容器这个容器不执行任何业务逻辑只做一件看似简单但极其重要的事把整个Pod的网络命名空间、IPC命名空间、UTS命名空间先创建并稳定住然后一直保持存活。其他所有容器在启动时都会加入这个pause容器持有的命名空间而不是各自创建新的。为什么要多此一举因为如果先创建业务容器第一个容器退出了它创建的网络命名空间可能被释放剩下容器就没法继续共享这套网络了。pause容器永远不死业务容器随便重启Pod的网络栈始终稳定。它还有另一个隐藏职责在命名空间内部进行僵尸进程的回收避免PID资源被无谓地消耗。用个直白的类比pause容器是房子的地基和主体结构业务容器只是后来搬进来的住户。住户来来去去房子拆了整个单元才算结束。2.2 普通容器、init容器与sidecar容器的定位差异先看最常见的普通容器。它们在Pod里持续运行执行真正的业务逻辑比如Nginx承担流量、Java进程处理请求。一个Pod里可以同时存在多个普通容器它们共享pause带来的网络和存储。再看init容器。这类容器在Pod创建之后、业务容器启动之前执行且必须串行执行。第一个init容器退出码为0才会拉起第二个全部成功后才会进入主容器的启动阶段。它非常适合做前置准备等待数据库可用、初始化目录权限、把配置文件从远端拉下来、执行数据迁移脚本。init容器跑完即退不会长期驻留。sidecar容器则是伴随主容器一直运行的工具角色日志采集、流量代理、指标导出、文件同步它在主容器生命周期内持续工作。需要特别注意的是在较新的Kubernetes版本中sidecar容器已经得到了原生支持可以设置独立的启动顺序和生命周期管理但在很多还没升级的集群里所谓sidecar容器其实就是通过普通容器实现的——把工具容器和主容器一起写在containers列表里它们同生共死但调度情况要按平台版本来区分。为了不把“分类”理解成单一维度我先把最常用的角色分类放进一张表里后面讲资源的时候还有另一种分类方式。容器角色运行时机退出行为典型用途普通容器Pod生命周期内持续运行异常退出会被kubelet根据restartPolicy重启业务主进程、常驻辅助进程init容器业务容器启动前串行运行每次都必须成功退出失败则无法启动业务等待依赖、初始化配置、迁移脚本sidecar容器主容器生命周期内常驻与主容器并行随Pod或主容器生命周期结束而结束日志采集、网络代理、指标导出2.3 从“角色分类”过渡到“资源分类”很多初学者以为容器分类就这么简单init是一次性任务普通容器是业务sidecar是辅助。这个分类在理解生命周期时很有用但当你真正面对一台资源紧张的节点时你会发现另一种分类更致命——按QoS等级划分。一个容器有没有设置requests和limits设置得是否合理决定了它在节点内存不够时是被优先驱逐还是被保护到最后。这个维度我放到第5章详细展开因为那里牵扯到调度器和节点的实际行为。先记住这句话容器分类不只是看它是干什么的还要看它凭什么资源活着。3. 共享网络与存储Pod内容器协作的技术真相3.1 同一个IP同一个网络空间Pod内容器共享同一个网络命名空间这句话听起来抽象落到实际操作上有几个直接后果。第一Pod内的所有容器看到的IP地址是同一个也就是Pod的IP。它们对外通信时源IP都一样外部回访时也是先到Pod的IP再根据端口路由到对应容器。所以你直接用curl PodIP:容器端口就能访问到里面任何一个监听端口的容器。第二容器之间通过localhost就能互相访问。主容器监听8080端口sidecar容器可以直接访问localhost:8080不需要知道对方在哪个节点、被调度到了哪里。这在排查链路时特别方便只要进了Pod网络拓扑基本不存在。第三所有容器的主机名是共享的。你在任何一个容器里执行hostname结果都一样。很多依赖主机名的应用比如某些分布式框架会因此感到困惑也是排障时经常被忽略的点。第四端口不能重复。既然共享一个网络栈那Pod内的容器要是都想监听80端口第二个起来的时候必然失败。这是多容器Pod里最经典的启动失败原因之一后面第6章我还会提到。3.2 存储卷共享emptyDir、hostPath与持久卷的挂载边界Pod内容器共享存储靠的是挂载卷volume。最常用的是emptyDir。这个名字很直白一开始是空目录Pod创建时初始化Pod被删除时整个目录被清空生命周期跟Pod完全同步。它适合缓存临时数据、容器间交换文件、存运行日志但不适合保存需要跨Pod留存的数据。hostPath则直接把节点上的一个真实目录挂进Pod。这种卷容器重启不会丢但有一次明显隐患它突破了Pod的隔离边界让Pod直接影响节点文件系统如果两个Pod挂到同一个hostPath目录还会因为权限问题互相干扰。在生产环境我一般不推荐用它做常规存储除非你明确知道自己在干什么。持久卷是另一条路线。它通过PVC把外部存储网络存储、云盘等挂载进来Pod重建后数据还在适合有状态服务。但要注意同一个持久卷可以被多个容器同时挂载反而是它带来的新问题——多个进程要对同一份文件做并发写文件锁、格式冲突、文件归属都会冒出来。3.3 一个可直接复用的双容器Pod配置理论说再多不如直接看一个能跑的配置。下面这个Pod里跑着Nginx和一个日志采集sidecar两个容器共享一个emptyDir目录sidecar用tail命令把Nginx的访问日志打出来。apiVersion: v1 kind: Pod metadata: name: web-with-logshipper spec: restartPolicy: Always containers: - name: web image: nginx:1.25 ports: - containerPort: 80 volumeMounts: - name: shared-logs mountPath: /var/log/nginx - name: log-shipper image: busybox:1.36 command: [sh, -c, tail -F /var/log/nginx/access.log] volumeMounts: - name: shared-logs mountPath: /var/log/nginx volumes: - name: shared-logs emptyDir: {}两个容器挂载了同一个emptyDir路径都是/var/log/nginx。Nginx写日志的时候sidecar容器可以实时看到同一份文件。这种模式下你不用关心Nginx容器是否重启只要Pod没被删除这些日志就会一直累积在emptyDir里如果Pod重建了emptyDir会被清空所以这种方案适合临时排障或直接把日志外发sidecar同时往远端写不适合长期落盘。需要注意的是Nginx镜像里的/var/log/nginx目录可能挂在只读层或初始有默认文件。如果你在真实项目里遇到“sidecar一直看不到新日志”多半是Nginx没有写这个目录的权限或者日志被镜像内的符号链接指到了stdout。4. 启动顺序、探针与重启Pod生命周期的三个关键阶段4.1 init容器先跑业务容器组再起Pod从创建到Running内部执行顺序其实很有条理。Pod被调度到节点后kubelet开始拉取镜像并启动容器最先启动的是init容器。如果有多个init容器它们严格串行执行前一个退出码必须是0后一个才会被拉起。任何一个init容器失败Pod会留在Init状态主容器一个都不会启动。等所有init容器都成功退出kubelet才会进入业务容器的启动阶段。这里有个细节如果Pod里存在原生sidecar容器新版本中可以把sidecar的启动顺序调到主容器之前但传统实现里普通容器和sidecar容器基本是并行启动的谁先谁后取决于容器运行时的拉起顺序并不是严格串行。全部容器进入Running之后Pod才被标记为Running。不过这个状态只是“容器起来了”不代表业务就绪。业务是否就绪要靠探针来判断。4.2 三种探针在什么场景下怎么选Kubernetes提供三种探针startupProbe解决“启动慢”的问题livenessProbe解决“活没活”的问题readinessProbe解决“能不能接流量”的问题。最经典的坑是JVM应用。JVM冷启动通常需要几十秒甚至两分钟如果你只配了livenessProbe并且首次探测时间设得很短那么容器还在加载类的时候容器已经被判定为不健康、被重启了然后陷入不断重启的循环。正确的做法是先配startupProbe把初始化和失败阈值设得大一点让进程有时间完成启动startup成功之后livenessProbe才介入判断存活。readinessProbe则关系到流量接入。它失败时容器不会被重启但会被摘出Service的Endpoints暂时不接收新请求。这适合做优雅上线和下线比如应用启动好了但缓存还没预热完readiness直到预热完成才返回成功流量才会打进来。4.3 重启策略实际上是Pod级别的很多人把restartPolicy当成“容器重启器”其实它控制的是Pod内容器异常退出后的行为。restartPolicy支持Always、OnFailure、Never三个值默认是Always。容器自己崩溃退出后kubelet会按策略决定是否原地重启而且会遵循指数退避也就是一次比一次等得久。即使容器被重启了Pod本身还是那个Pod网络栈和存储卷都没有变化这种情况叫“容器级别故障恢复”。但如果是整个节点宕了Pod在节点上彻底消失控制器会创建一个全新建的Pod新Pod的IP都会变这叫“Pod级别重建”。两者的区别决定了你在排障时的思路容器重启后日志还在emptyDir还在Pod里但Pod重建后emptyDir可能就没了。还有一点容易被忽略CrashLoopBackOff不是一个稳定状态它只是容器反复重启、且每次间隔越来越长的中间状态。如果持续失败时间太长你会看到Pod卡在CrashLoopBackOff不要以为系统会无限重试下去必要时还是要人工介入。5. 资源视角下的容器分类从requests/limits到QoS再到调度分组5.1 QoS等级容器在资源紧张时的生死顺序我前面说过容器分类不止角色一种。从资源角度看每个容器都会被归入三个QoS等级之一Guaranteed、Burstable、BestEffort。判定逻辑是这样的。如果Pod里的每一个容器都同时设置了CPU和内存的requests与limits并且每个容器的request等于相应的limit那么这个Pod属于Guaranteed等级。这个等级的资源保障最高节点在遭遇内存压力时驱逐优先级最低。如果Pod里至少有一个容器设置了requests或limits但不满足Guaranteed的全部条件就属于Burstable。大多数项目里的Pod都在这个等级。如果Pod里所有容器都没有设置requests和limits那就是BestEffort。这类容器活得最没保障节点内存一紧张它们最先被驱逐OOM杀手优先杀它们。可以这样记Guaranteed是被层层保护的VIPBurstable是普通职工BestEffort是没有固定工位的临时工。节点资源不够的时候临时工最先被请出去。这个分类和业务分类是正交的——一个Sidecar容器完全可能是Guaranteed等级一个主业务容器反而可能因为配置不当落进BestEffort。所以你在排查资源争抢问题时不要只看谁是主容器。5.2 调度器怎么算账Pod才是资源计算的最小单位调度器在为Pod选节点时会把Pod内所有容器的requests累加起来用这个总需求去匹配节点的剩余资源。每个节点的可分配资源是总容量减去系统预留和kubelet预留后的值节点剩余又减去已调度Pod的requests总和剩下的才是新Pod能用的份额。所以如果某个Pod里放了三个1999m CPU的容器它们的requests加起来接近5997m这就会让调度器认为该Pod需要接近6个CPU。即使每个容器实际都用不到那么多调度结果也会受这个“账面数字”的影响。这解释了为什么多容器Pod特别容易因为资源总和过大而调度失败——只给单个容器配了很大的limits却没有考虑Pod总额。反过来limits的总和又决定了cgroup层面的限制。Kubelet会把Pod视为一个cgroupPod内所有容器都挂在这个Pod cgroup之下。当Pod内一个容器把内存耗尽时OOM发生的地方可能是该容器自己的cgroup也可能波及整个Pod cgroup。这跟QoS等级密切相关。5.3 一次OOM排查的实战复盘我之前在处理一个内部交付项目的时候就撞上过一个典型Case。某服务的Pod里有一个主容器和一个内存占用偏大的自定义sidecar。主容器设置了512Mi的limitssidecar没设limits。结果业务高峰期主容器内存一直在500Mi上下看起来还没到限制但整个节点的可用内存被sidecar悄悄吃掉了大半最终Pod cgroup触发了OOM主容器被强制杀掉然后不停重启。排查的时候第一眼看到的是主容器OOM Killed很容易误判成主进程内存不够。后来把两个容器的实际内存占用量拉出来对比才发现真正的内存大户是sidecar。那次之后我对多容器Pod定了一条铁律不管是什么角色的容器只要有资源行为必须显式设置requests和limits否则它很可能在关键时刻毁掉整个Pod。复盘之后还能得到一个更远的结论QoS等级不只是“理论分类”它在真实环境里决定了故障形态。同一个Pod里的主容器和sidecar容器如果资源配额设计得不一致它们会在极端情况下互相拖累。6. 多容器Pod设计的边界与高频踩坑记录6.1 什么时候该把多个容器放进同一个Pod我见过不少初学者把Pod当成“一个容器里放多个进程”的等价物来用想省资源就把所有东西塞进一个Pod。这个思路方向反了。要不要把多个容器塞进同一个Pod应该看三个条件是否同时满足。第一部署节奏必须一致。这些容器必须同时拉起、一起销毁不能一个更新了另一个还在旧版本。第二需要共享网络或存储。比如必须通过localhost通信或者必须读写同一个目录。第三它们是强耦合的协作组件拆开之后运维成本反而会上升。一个Web应用和它的日志采集器属于典型的强耦合一个用户服务和一个后台任务控制器则大概率不该塞一起。反过来如果你只是想让多个服务少占一点资源或者单纯觉得“反正都在一个Pod里方便”我建议你重新考虑。Pod内容器之间的资源争夺和故障扩散都是真实存在的代价。6.2 端口冲突与探针串扰是重灾区多容器Pod的端口冲突很好理解网络栈共享两个容器不能监听同一个端口。我在实际中遇到过更隐蔽的一种业务容器和sidecar都默认监听8080端口业务容器先启动成功了sidecar起来时发现端口被占直接CrashLoopBackOff。排查日志时看到的报错信息往往只说是“Address already in use”不会提示你具体是哪个容器和哪个进程冲突需要逐个进容器检查监听端口。探针串扰则是另一个经常被忽略的问题。有人会给sidecar容器也配上livenessProbe本来只是日志采集进程结果它因为上游日志源断了而连续探测失败Pod被判定不健康整个Pod被重启连带着主业务一起遭殃。这是把“辅助进程的故障”放大成了“Pod的故障”。我的建议是尽量克制。对于日志采集这类工具性容器可以不做livenessProbe或者只给readinessProbe即便sidecar内部出问题了最好的结果往往是等它自身恢复而不是让整个Pod重启。6.3 init容器镜像小而稳避免启动顺序被拖死init容器承担的是“前置条件”它如果拉不到镜像整个Pod卡在Init阶段主容器永远起不来。这比业务容器启动失败更难受因为业务容器至少CrashLoopBackOff还有重启动作init容器卡住之后变更根本无法进入下一阶段。有一个常见场景团队为了省事让init容器跑一个特别大的镜像里面装了一整套工具链。在镜像拉取速度慢的节点上这个init容器会卡很久发布窗口被白白占用。更合理的做法是让init容器镜像尽量小比如用一个几百MB的busybox带一条curl命令就够了如果需要复杂脚本可以把脚本做成ConfigMap挂进去而不是靠镜像体积撑着。另外别忽略init容器的失败重试机制。init容器失败后Pod不会直接消失kubelet会重新拉起它但同样有退避。如果init容器一直失败你会看到Pod反复重启init容器而业务容器始终不动。6.4 滚动更新时readiness探针决定发布能否推进最后提一个经常被误解的点Deployment滚动更新时是“先建新Pod等它ready之后再删旧Pod”。这里的ready标准是Pod内所有定义了readinessProbe的容器都返回成功。只要多容器Pod里有一个容器说“我还没准备好”新Pod就不会被加入服务负载旧Pod也不会被销毁发布会被卡住。所以如果你在一个Pod里放了很多容器它们每个都得配置合理的readinessProbe如果不配K8s会认为容器一启动就是ready的也很危险——看起来发布完成了实际上新Pod根本没接受到流量验证。我一般会建议核心业务容器必须配readinessProbesidecar容器如果影响Pod对外就绪也要慎重决定要不要参与这个判断。我自己维护多容器Pod最大的体会就是Pod设计本质上是在做部署单元边界的取舍。宁可让一个Pod只放一个主容器加一个真正必要的sidecar也不要为了省事把多个互不相干的进程硬绑在一起。容器分类的出发点不是“能不能放”而是“放进来之后故障、资源、发布、网络这些维度会不会变得更难掌控”。如果你在配置多容器Pod时还遇到过其他怪问题比如共享卷权限、探针误杀、资源抢占之类的欢迎在评论里贴出来——这些坑我大概率也踩过同一个。