1. 为什么K8s不直接管理容器非要套一层Pod——从一次故障说起先说我踩过的一个真实坑。有一年我把公司某个核心服务从Docker Compose迁移到K8s当时图省事直接用Deployment管理单个Nginx容器没考虑Pod里需要同时跑日志采集的Sidecar。上线之后日志全部丢失排查了半天最后发现是日志采集进程没有跟着业务容器一起调度到同一台机器上。那次之后我才真正意识到Pod这个抽象层不是K8s设计者闲着没事搞出来的花架子它解决的是一个非常实际的问题一组需要协同工作的进程必须被当成一个整体来调度和管理。很多人刚接触K8s都会问同一个问题为什么不用容器作为最小的调度单位非要再包一层Pod这就要说到Docker和K8s在设计理念上的根本区别。Docker的核心价值是把一个进程装进隔离环境跑起来而K8s的核心价值是管理一组进程的生命周期和它们之间的关系。在真实的生产环境里一个业务往往不是单个进程就能搞定的你可能需要一个Nginx容器负责接收流量需要一个日志采集容器把日志转发到中央日志系统可能还需要一个配置同步容器定期拉取最新的配置。如果这三个容器被分开调度它们可能落在不同的机器上网络通信变成跨主机调用IO和内存竞争变得不可控日志采集更是无从谈起。Pod的本质就是把这一组生死与共的容器捆绑在一起。K8s保证同一Pod内的容器永远被调度到同一个节点上共享同一个网络命名空间和存储卷。你可以把Pod理解成一台微型服务器里面的容器就是在这台服务器上跑的进程它们通过localhost就能互相通信。这个设计直接继承自Google内部多年运行Borg集群的经验——在超大规模集群里进程之间的协作关系远比单进程的隔离性更重要。从实践角度看Pod的边界应该划在哪里是每个K8s使用者都需要想清楚的问题。我的经验是问自己两个问题这两个容器是否必须部署在同一台机器上它们是否共享同一份数据或网络空间如果答案都是肯定的就应该放进同一个Pod如果不是就应该拆成多个Pod用Service来关联。比如Web应用和它的本地缓存进程放进一个Pod没问题但两个无状态API服务各自管理自己的副本数拆开更合理。2. Pod生命周期管理从Pending到Failed状态机里的真实含义Pod的状态看起来简单就几个英文单词但每一个状态背后都对应着一整套调度器和kubelet的工作逻辑。我在给团队做培训时经常说如果你能准确说出Pod在每一个状态下集群里的各个组件分别在干什么你对K8s的理解就及格了。Pending状态是新手最容易困惑的。Pod刚创建时进入Pending很多人以为这就是正在启动其实这个状态表示的是还没有被调度器选到合适的节点。调度器这时候在干什么它在看这个Pod的CPU和内存请求是否符合节点的可用资源看节点上的污点是否被Pod容忍看Pod的节点亲和性和反亲和性规则是否满足条件。我遇到过很多次Pod卡在Pending一整天的案例原因五花八门节点资源被其他工作负载占满、PVC无法绑定导致调度器犹豫、忘记给节点打标签导致nodeSelector匹配不上。排查Pending状态第一件事就是执行kubectl describe pod看Events字段里调度器给出的具体原因。Running状态也不是万事大吉。Pod进入Running只代表容器已经创建并且至少有一个容器在运行不代表业务已经就绪。所以K8s引入了就绪探针ReadinessProbe的概念——只有通过就绪探针检查的Pod才会被纳入Service的端点列表。这里有个很多人不知道的细节如果就绪探针失败Pod的状态会退回Running但Endpoints里会把它摘掉流量不会打过来但Pod本身不会被重启。这和存活探针LivenessProbe有本质区别存活探针失败会导致容器被杀掉并重启。搞清楚这两个探针的分工是Pod健康管理的基本功。CrashLoopBackOff是运维人员最常遇到的状态。这个状态的意思是容器启动后崩溃Kubelet自动重启但反复崩溃于是一次次增加退避延迟。很多人在这个状态面前手足无措其实排查路径很清晰先看日志kubectl logs如果容器崩得太快日志来不及输出用kubectl logs --previous看上一次容器的日志如果日志正常就要考虑启动命令是否缺少前台进程——这是Docker和K8s最常见的用法错误进程如果以守护进程方式启动容器会立刻退出K8s只能一次次拉起重启。Failed和Succeeded状态对应于短时任务场景Job和CronJob。如果你的Pod是普通Deployment管的理论上不应该以这两个状态结束因为Deployment的控制器会保证Pod一直维持期望的副本数。但在Job场景下Pod正常执行完毕退出就是Succeeded执行出错就是Failed。很多做数据批处理任务的团队在这里踩过坑忘记给Job设置restartPolicy导致容器失败后一直重启任务永远结束不了。restartPolicy也是Pod管理里一个不起眼但很关键的参数。它有三个值Always、OnFailure、Never。Deployment管理的Pod必须用Always这没问题但Job管理的Pod如果也用AlwaysPod失败了会不断重启把错误日志淹没。我见过有人在CronJob里用Always结果每次任务失败就无限重启直到被下一次调度覆盖日志全乱了。正确的做法是Job场景用OnFailure或者Never配合Pod的backoffLimit来控制重试次数。3. 掌握Pod调度逻辑从nodeSelector到污点容忍让Pod去该去的地方调度是Pod管理里最像艺术的部分。默认情况下调度器会根据资源请求自动分配合适的节点但真实生产环境永远没有这么理想。你可能需要把某些Pod固定到有GPU的节点可能希望把同一个应用的多个副本分散到不同机架避免单点故障也可能希望某些测试负载永远不要跑到生产节点上。nodeSelector是最简单的调度约束方式给节点打上标签然后Pod指定要跑在哪些标签的节点上。比如我有三台机器插了GPU就给它们打上gputrue的标签需要GPU的训练任务指定nodeSelector: {gpu: true}就能精准调度。这种方式简单直观但它只支持硬性必须匹配不支持优先选择。如果你想表达的是最好跑在SSD节点上但实在没有也不强求nodeSelector就做不到了。节点亲和性nodeAffinity补上了这个短板。它有两种类型requiredDuringSchedulingIgnoredDuringExecution表示硬性要求preferredDuringSchedulingIgnoredDuringExecution表示软性偏好。软性偏好调度器会尽量满足如果实在不满足会退而求其次。这个设计非常实用比如批处理任务希望优先跑在内存大的节点上但当大内存节点资源紧张时能跑起来总比一直排队强。注意亲和性还有第二个半段IgnoredDuringExecution意思是调度完成之后如果节点标签变化了已经在跑的Pod不会受影响。K8s的亲和性只负责调度那一刻不负责运行中的迁移。Pod间亲和性podAffinity和反亲和性podAntiAffinity解决的是更复杂的场景。亲和性可以让两个Pod尽量落在同一个节点上——比如两个服务之间流量特别大放在一起可以省掉网络开销反亲和性可以让同一应用的副本分散到不同节点——比如我的Web服务有3个副本如果都在同一台机器上这台机器一挂服务就全挂了这反而违背了多副本的意义。反亲和性在Kafka、Elasticsearch这类有状态分布式应用里几乎是标配。污点和容忍是调度体系里最值得深入理解的部分。你可以把污点理解成节点的一种嫌弃标记节点被打上污点后默认情况下任何Pod都不会调度上来。而容忍则是Pod声明我不介意这个污点。污点有三个效果NoSchedule表示不会调度新的Pod上来但已经在跑的Pod不受影响PreferNoSchedule是软性版本尽量不调度NoExecute表示不但不调度新的已经在跑的Pod也会被驱逐。第三种效果常用于节点维护场景给节点打上NoExecute污点把上面的Pod全部赶走然后就可以放心维护硬件。等节点恢复了删掉污点Pod会重新调度回来。我这里给了你一套非常实用的调度排查口诀Pod起不来先看是否有节点满足亲和性和资源要求再看节点是否被打污点最后看PVC和存储卷是否能在目标节点挂载。很多时候一个简单的PVC的AccessModes设置有问题会导致Pod只能调度到特定节点这个坑我下面会细说。4. Pod网络与存储实践多容器通信和持久化数据的关键细节说完了调度再看Pod内部的网络和存储——这两个维度直接决定了Pod能不能正常对外服务、数据能不能持久化。Pod内的网络设计是K8s最优雅的地方之一。每个Pod只有一个IP地址Pod内的所有容器共享这个IP和网络命名空间。这意味着容器之间通过localhost就能通信端口不能冲突。我见过有人在一个Pod里同时跑两个都监听8080端口的容器结果第二个容器一直启动失败还找不到原因。这是个很常见的低级错误但排查起来往往要花不少时间因为日志里只显示端口被占用不会告诉你具体是被谁占用的。Pod的IP是集群内部的虚拟IP从集群外访问Pod有三种主流方式。第一种是NodePort在每个节点上开一个高位端口默认30000-32767流量经过节点端口转发到Pod适合测试环境快速暴露服务第二种是LoadBalancer云厂商的LB会把流量导入到NodePort适合云上生产环境第三种是Ingress它是七层负载均衡按照域名和路径把HTTP/HTTPS流量路由到不同的Service。Ingress是生产环境用得最多的方式因为你只需要一个公网入口就能路由到集群内所有HTTP服务。关于Pod的IP有个常见的错误认知有人以为Pod的IP是固定的重启后不会变。实际上Pod一旦被删除重新创建IP就变了。如果你的应用有服务发现的需求一定要走Service的DNS名字不要硬编码Pod IP。存储这块是新手翻车最多的区域。Pod里的容器默认是无状态的容器一删容器内写入的数据全部丢失。要持久化数据必须挂载存储卷。K8s的存储体系分三层Volume是最基础的挂载卷生命周期和Pod绑定Pod删了卷也跟着没PersistentVolumePV是集群级别的存储资源独立于Pod存在PersistentVolumeClaimPVC是用户对存储资源的申请请求。PVC和PV的关系很像编程里的接口和实现用户只声明我要5G的读写存储至于背后是云盘还是本地目录由管理员通过StorageClass自动Provision来保证。存储的访问模式AccessModes是一个极其重要又容易被忽视的配置。它有三种ReadWriteOnceRWO表示只能被一个节点挂载读写ReadOnlyManyROX表示可以被多个节点同时只读挂载ReadWriteManyRWX表示可以被多个节点同时读写。很多人创建PVC时根本不关心这个字段结果Pod调度到第二个节点上挂载失败卡在ContainerCreating。尤其注意云厂商的块存储比如云硬盘大多只支持RWO如果你的应用需要多个Pod同时读写同一份数据必须使用支持RWX的文件存储。在Pod存储配置里还有一个细节叫subPath。如果你把同一个卷挂载到Pod里的多个目录或者只挂载某个子目录而不是整个根目录就要用subPath。比如你的ConfigMap挂载了多个配置文件到不同路径不指定subPath的话K8s会帮你在卷的根目录创建目录结构跟预期往往不一致导致配置加载失败。这个坑我踩过至少三次每次都是配置文件路径不对查半天才发现是挂载方式的问题。5. 排障实战Pod卡在ContainerCreating时我通常这样定位Pod排障是每个K8s运维的日常。我不打算给你背一遍kubectl describe和kubectl logs的手册而是用我实际排查过的几个典型案例把排查思路串起来讲。案例一ImagePullBackOff镜像拉不下来。这个状态的原因就几种镜像名字写错、tag不存在、私有仓库认证失败、镜像仓库网络不通、镜像太大拉取超时。排查顺序也是固定的先kubectl describe pod看Events如果显示ErrImagePull或者ImagePullBackOff第一步检查镜像地址拼写第二步检查imagePullSecrets是否配置了私有仓库凭据第三步在节点上手动docker pull测试网络和仓库连通性。有个容易被忽略的细节如果你用的是新版的containerd而不是docker作为容器运行时docker login的认证文件对K8s是不生效的必须用kubectl create secret docker-registry创建镜像拉取凭据。案例二Pod一直Pending。如前面说的这个问题几乎都是调度器不给力导致的。最常见的原因是资源不足——你看一下节点的allocatable资源和已分配资源CPU和内存接近打满就会导致新Pod一直等。这个时候不要手动去删别的Pod腾资源正确做法是提高这个Pod的资源request让它被调度器优先考虑或者检查是不是忘记了节点亲和性导致没有节点匹配。有一个很容易忽略的点如果你给Pod设置了资源request但集群里每个节点上都没法同时满足request和已有Pod的request调度器就会一直pending。有些资源超卖很严重的节点上看free还有不少内存但因为request已经算满了调度器就是不让你调度过去。案例三CrashLoopBackOff反复重启。这个前面提过一次这里讲一个具体的定位技巧。当容器启动就崩溃日志看不到有效信息时可以先看启动命令确认进程是前台运行再检查环境变量和挂载的配置文件往往问题出在配置文件的格式或权限上。一个经典场景把ConfigMap挂载进容器后容器里读取的配置文件还是原来的默认值这是因为ConfigMap更新后Pod里的挂载不会自动更新需要重启Pod。从K8s 1.20之后挂载的ConfigMap更新后会有一定延迟同步的机制但不会触发重启这一点务必注意。案例四Pod状态Ready但是访问不通。这种问题最容易让人头疼因为Pod本身是正常的但流量就是进不来。排查思路从下往上先确认Pod的IP能不能ping通同节点内测试确认容器内的服务监听在正确的端口不要监听在127.0.0.1上K8s的Service转发是从宿主机网络进来的如果只监听backlog地址会全部拒绝确认Service的selector匹配到了这个Pod——这是最常见的错误selector写错导致Endpoints为空最后再检查网络策略NetworkPolicy是否放行了。排障的本质是快速缩小范围。我的习惯是先看Pod状态和Events再看容器日志再检查网络和存储最后才看代码和配置。按照这个顺序80%的问题都能在五分钟内定位。不要一上来就怀疑是网络插件的问题那是最后才查的。6. Pod管理进阶节点维护、滚动更新与资源规划的实际经验Pod管理做到最后你会发现核心问题不再是怎么建Pod而是怎么在生产环境安全地变更Pod。这里讲三个我最有发言权的场景节点维护时怎么优雅地腾空节点、发布新版本时怎么保证不中断服务、以及资源配额怎么规划才能不浪费又不踩坑。节点维护当你需要重启一台节点机器或者升级内核不能直接关机。K8s有一个优雅的机制叫节点排水cordon drain。先执行kubectl cordon 把节点标记为不可调度新Pod不会调度过来然后执行kubectl drain --ignore-daemonsets --delete-emptydir-data把节点上已有的Pod驱逐到其他节点。drain的过程会遵守Pod的terminationGracePeriodSeconds给Pod时间处理完存量请求再退出。这里一定要加--ignore-daemonsets因为DaemonSet的Pod是集群里的守护任务比如网络插件、日志采集驱逐了也会被DaemonSet控制器重新创建到原节点不忽略会报错。维护完成后kubectl uncordon 恢复调度。滚动更新Deployment的滚动更新策略是保证服务不中断的关键。默认情况下K8s会先创建一个新Pod副本等它Ready之后再销毁一个旧副本如此交替直到全部替换。但默认策略不一定适合所有场景。如果你的服务是单副本的滚动更新时会出现新旧版本并存短暂时间内流量被分到两个版本上可能引发数据格式不兼容的问题。这种情况下可以设置strategy: {type: Recreate}先杀掉旧Pod再创建新Pod牺牲短暂不可用换取数据一致性。另一个关键参数是maxUnavailable和maxSurgemaxUnavailable表示更新过程中允许多少个旧Pod不可用建议设置为0maxSurge表示最多允许多出多少个新Pod建议设置为1或者25%。这两个参数配合就绪探针可以做到发布期间一个Pod都不少新Pod完全Ready后才开始摘流量。资源配额Pod的资源请求与限制设置是运维里最需要经验的地方。请求值request是调度器做决策的依据限制值limit是运行时强制执行的阈值。很多人的误区是把request和limit设成一样的值这样Pod的QoS等级是Guaranteed不会被驱逐但资源利用率往往不高。我见过一个团队把所有的Java应用内存request都设为4Glimit也是4G结果一个节点16G内存只能塞3个Pod剩下4G内存永远闲着。更合理的做法是根据压测数据设定requestlimit设为request的1.2到1.5倍利用Burstable QoS来提升节点利用率。但要小心Pod内存超过limit会被OOM Killer杀掉和宿主机内存不足杀进程是两回事。Namespace层面的资源管理当团队人多项目杂时一定要用ResourceQuota和LimitRange来规范。ResourceQuota限制了整个Namespace的总资源上限防止某个团队把集群资源全部占满。LimitRange则给Namespace里的每个Pod设置默认的request和limit避免有人不写资源限制把节点打爆。我在公司里推行过一套规范每个Namespace必须有ResourceQuota每个Deployment必须显式声明resources字段CI流水线里检查这两个条件不满足直接拒绝发布。推行之后集群层面的资源争抢问题少了八成。还有一个容易忽略的点Pod的优雅终止Graceful Shutdown。terminationGracePeriodSeconds默认是30秒当Pod被删除时kubelet会先发送SIGTERM信号给容器的主进程等待这个时间之后才发送SIGKILL强杀。如果你的服务需要处理存量请求的时间超过30秒比如正在处理一个耗时的HTTP请求一定要调大这个值。但也不要无限调大否则节点排水会被拖得很久。我的建议是Web服务设60秒批处理任务设300秒同时业务代码里要正确处理SIGTERM信号——先停止接收新请求等存量请求处理完再退出。7. 给刚上手K8s团队的三条建议以及我踩过的代价最大的坑最后写一点心得。K8s上手曲线陡峭是公认的但我观察了很多团队之后发现大多数人不是被技术难倒的而是被不知道还有这么个概念难倒的。你如果不知道有Pod这层抽象就会拿它当Docker用怎么用怎么别扭你如果不知道有探针这个概念出了问题就只能靠人工盯着。第一个建议一定要在开发环境就启用资源限制。不要因为开发环境无所谓就省略resources字段。K8s集群是共享的一个没有资源限制的Pod可能把节点资源吃满导致其他的开发同学的Pod全部受影响。我们团队就出过一次大事故某个同事在开发环境跑了一个没有limit的数据导出任务内存暴涨触发了节点OOM把整个节点上的其他服务全拖垮了包括一个正在演示给客户看的重要环境。从那次之后我们用LimitRange做了兜底。第二个建议日志和监控一定要提前配好。K8s的Pod是脆弱的随时可能被重新调度、被驱逐、被扩容缩容如果你没有集中式日志和监控告警等Pod没了你连它发生了什么都不知道。我们在生产环境部署了Prometheus和Grafana监控Pod的CPU、内存、重启次数、网络流量告警规则里有一条Pod重启次数超过5次/15分钟必报警这条规则救过我好几次。第三个建议别过度设计。初学者容易一上来就想把所有高级特性都用上——HPA、VPA、PodDisruptionBudget、NetworkPolicy、ServiceMesh结果配置复杂到维护不起来。K8s最大的优势是标准化你的系统越简单K8s的威力越能发挥。先用好Deployment、Service、ConfigMap、PVC这四件套把业务稳定跑起来确有必要时再渐进式引入高级特性。代价最大的那个坑我想单独拿出来说生产环境直接删除Namespace。我记得有次做资源清理想删掉一个废弃的测试Namespace结果手滑删错了把生产Namespace删了。K8s删除Namespace会级联删除里面所有的Deployment、Service、ConfigMap、Secret、PVC而且这个过程是不可逆的——即使你开启了回收站机制PVC里的数据也没了。那次事故导致我们丢失了几天的数据库备份幸好数据库有跨集群的备份机制才没有全丢。从此以后我在任何生产集群里执行删除命令之前都会先执行kubectl get namespace确认名字然后在删除命令后面加上--waitfalse看看能不能通过计划任务恢复。Pod管理这件事说到底是K8s一切能力的载体。你把它理解透了Service、Deployment、StatefulSet这些高级对象都是在Pod之上的不同管理策略理解起来会顺畅得多。这篇文章里的很多经验都是用故障和事故换来的写出来只希望你能少走这些弯路。总之K8s不难难的是对它的心智模型跟传统的服务器运维不一样一旦转过弯来你会发现它是目前最优雅的集群管理方案没有之一。
Kubernetes Pod深度解析：从原理到实战排障与调度管理
1. 为什么K8s不直接管理容器非要套一层Pod——从一次故障说起先说我踩过的一个真实坑。有一年我把公司某个核心服务从Docker Compose迁移到K8s当时图省事直接用Deployment管理单个Nginx容器没考虑Pod里需要同时跑日志采集的Sidecar。上线之后日志全部丢失排查了半天最后发现是日志采集进程没有跟着业务容器一起调度到同一台机器上。那次之后我才真正意识到Pod这个抽象层不是K8s设计者闲着没事搞出来的花架子它解决的是一个非常实际的问题一组需要协同工作的进程必须被当成一个整体来调度和管理。很多人刚接触K8s都会问同一个问题为什么不用容器作为最小的调度单位非要再包一层Pod这就要说到Docker和K8s在设计理念上的根本区别。Docker的核心价值是把一个进程装进隔离环境跑起来而K8s的核心价值是管理一组进程的生命周期和它们之间的关系。在真实的生产环境里一个业务往往不是单个进程就能搞定的你可能需要一个Nginx容器负责接收流量需要一个日志采集容器把日志转发到中央日志系统可能还需要一个配置同步容器定期拉取最新的配置。如果这三个容器被分开调度它们可能落在不同的机器上网络通信变成跨主机调用IO和内存竞争变得不可控日志采集更是无从谈起。Pod的本质就是把这一组生死与共的容器捆绑在一起。K8s保证同一Pod内的容器永远被调度到同一个节点上共享同一个网络命名空间和存储卷。你可以把Pod理解成一台微型服务器里面的容器就是在这台服务器上跑的进程它们通过localhost就能互相通信。这个设计直接继承自Google内部多年运行Borg集群的经验——在超大规模集群里进程之间的协作关系远比单进程的隔离性更重要。从实践角度看Pod的边界应该划在哪里是每个K8s使用者都需要想清楚的问题。我的经验是问自己两个问题这两个容器是否必须部署在同一台机器上它们是否共享同一份数据或网络空间如果答案都是肯定的就应该放进同一个Pod如果不是就应该拆成多个Pod用Service来关联。比如Web应用和它的本地缓存进程放进一个Pod没问题但两个无状态API服务各自管理自己的副本数拆开更合理。2. Pod生命周期管理从Pending到Failed状态机里的真实含义Pod的状态看起来简单就几个英文单词但每一个状态背后都对应着一整套调度器和kubelet的工作逻辑。我在给团队做培训时经常说如果你能准确说出Pod在每一个状态下集群里的各个组件分别在干什么你对K8s的理解就及格了。Pending状态是新手最容易困惑的。Pod刚创建时进入Pending很多人以为这就是正在启动其实这个状态表示的是还没有被调度器选到合适的节点。调度器这时候在干什么它在看这个Pod的CPU和内存请求是否符合节点的可用资源看节点上的污点是否被Pod容忍看Pod的节点亲和性和反亲和性规则是否满足条件。我遇到过很多次Pod卡在Pending一整天的案例原因五花八门节点资源被其他工作负载占满、PVC无法绑定导致调度器犹豫、忘记给节点打标签导致nodeSelector匹配不上。排查Pending状态第一件事就是执行kubectl describe pod看Events字段里调度器给出的具体原因。Running状态也不是万事大吉。Pod进入Running只代表容器已经创建并且至少有一个容器在运行不代表业务已经就绪。所以K8s引入了就绪探针ReadinessProbe的概念——只有通过就绪探针检查的Pod才会被纳入Service的端点列表。这里有个很多人不知道的细节如果就绪探针失败Pod的状态会退回Running但Endpoints里会把它摘掉流量不会打过来但Pod本身不会被重启。这和存活探针LivenessProbe有本质区别存活探针失败会导致容器被杀掉并重启。搞清楚这两个探针的分工是Pod健康管理的基本功。CrashLoopBackOff是运维人员最常遇到的状态。这个状态的意思是容器启动后崩溃Kubelet自动重启但反复崩溃于是一次次增加退避延迟。很多人在这个状态面前手足无措其实排查路径很清晰先看日志kubectl logs如果容器崩得太快日志来不及输出用kubectl logs --previous看上一次容器的日志如果日志正常就要考虑启动命令是否缺少前台进程——这是Docker和K8s最常见的用法错误进程如果以守护进程方式启动容器会立刻退出K8s只能一次次拉起重启。Failed和Succeeded状态对应于短时任务场景Job和CronJob。如果你的Pod是普通Deployment管的理论上不应该以这两个状态结束因为Deployment的控制器会保证Pod一直维持期望的副本数。但在Job场景下Pod正常执行完毕退出就是Succeeded执行出错就是Failed。很多做数据批处理任务的团队在这里踩过坑忘记给Job设置restartPolicy导致容器失败后一直重启任务永远结束不了。restartPolicy也是Pod管理里一个不起眼但很关键的参数。它有三个值Always、OnFailure、Never。Deployment管理的Pod必须用Always这没问题但Job管理的Pod如果也用AlwaysPod失败了会不断重启把错误日志淹没。我见过有人在CronJob里用Always结果每次任务失败就无限重启直到被下一次调度覆盖日志全乱了。正确的做法是Job场景用OnFailure或者Never配合Pod的backoffLimit来控制重试次数。3. 掌握Pod调度逻辑从nodeSelector到污点容忍让Pod去该去的地方调度是Pod管理里最像艺术的部分。默认情况下调度器会根据资源请求自动分配合适的节点但真实生产环境永远没有这么理想。你可能需要把某些Pod固定到有GPU的节点可能希望把同一个应用的多个副本分散到不同机架避免单点故障也可能希望某些测试负载永远不要跑到生产节点上。nodeSelector是最简单的调度约束方式给节点打上标签然后Pod指定要跑在哪些标签的节点上。比如我有三台机器插了GPU就给它们打上gputrue的标签需要GPU的训练任务指定nodeSelector: {gpu: true}就能精准调度。这种方式简单直观但它只支持硬性必须匹配不支持优先选择。如果你想表达的是最好跑在SSD节点上但实在没有也不强求nodeSelector就做不到了。节点亲和性nodeAffinity补上了这个短板。它有两种类型requiredDuringSchedulingIgnoredDuringExecution表示硬性要求preferredDuringSchedulingIgnoredDuringExecution表示软性偏好。软性偏好调度器会尽量满足如果实在不满足会退而求其次。这个设计非常实用比如批处理任务希望优先跑在内存大的节点上但当大内存节点资源紧张时能跑起来总比一直排队强。注意亲和性还有第二个半段IgnoredDuringExecution意思是调度完成之后如果节点标签变化了已经在跑的Pod不会受影响。K8s的亲和性只负责调度那一刻不负责运行中的迁移。Pod间亲和性podAffinity和反亲和性podAntiAffinity解决的是更复杂的场景。亲和性可以让两个Pod尽量落在同一个节点上——比如两个服务之间流量特别大放在一起可以省掉网络开销反亲和性可以让同一应用的副本分散到不同节点——比如我的Web服务有3个副本如果都在同一台机器上这台机器一挂服务就全挂了这反而违背了多副本的意义。反亲和性在Kafka、Elasticsearch这类有状态分布式应用里几乎是标配。污点和容忍是调度体系里最值得深入理解的部分。你可以把污点理解成节点的一种嫌弃标记节点被打上污点后默认情况下任何Pod都不会调度上来。而容忍则是Pod声明我不介意这个污点。污点有三个效果NoSchedule表示不会调度新的Pod上来但已经在跑的Pod不受影响PreferNoSchedule是软性版本尽量不调度NoExecute表示不但不调度新的已经在跑的Pod也会被驱逐。第三种效果常用于节点维护场景给节点打上NoExecute污点把上面的Pod全部赶走然后就可以放心维护硬件。等节点恢复了删掉污点Pod会重新调度回来。我这里给了你一套非常实用的调度排查口诀Pod起不来先看是否有节点满足亲和性和资源要求再看节点是否被打污点最后看PVC和存储卷是否能在目标节点挂载。很多时候一个简单的PVC的AccessModes设置有问题会导致Pod只能调度到特定节点这个坑我下面会细说。4. Pod网络与存储实践多容器通信和持久化数据的关键细节说完了调度再看Pod内部的网络和存储——这两个维度直接决定了Pod能不能正常对外服务、数据能不能持久化。Pod内的网络设计是K8s最优雅的地方之一。每个Pod只有一个IP地址Pod内的所有容器共享这个IP和网络命名空间。这意味着容器之间通过localhost就能通信端口不能冲突。我见过有人在一个Pod里同时跑两个都监听8080端口的容器结果第二个容器一直启动失败还找不到原因。这是个很常见的低级错误但排查起来往往要花不少时间因为日志里只显示端口被占用不会告诉你具体是被谁占用的。Pod的IP是集群内部的虚拟IP从集群外访问Pod有三种主流方式。第一种是NodePort在每个节点上开一个高位端口默认30000-32767流量经过节点端口转发到Pod适合测试环境快速暴露服务第二种是LoadBalancer云厂商的LB会把流量导入到NodePort适合云上生产环境第三种是Ingress它是七层负载均衡按照域名和路径把HTTP/HTTPS流量路由到不同的Service。Ingress是生产环境用得最多的方式因为你只需要一个公网入口就能路由到集群内所有HTTP服务。关于Pod的IP有个常见的错误认知有人以为Pod的IP是固定的重启后不会变。实际上Pod一旦被删除重新创建IP就变了。如果你的应用有服务发现的需求一定要走Service的DNS名字不要硬编码Pod IP。存储这块是新手翻车最多的区域。Pod里的容器默认是无状态的容器一删容器内写入的数据全部丢失。要持久化数据必须挂载存储卷。K8s的存储体系分三层Volume是最基础的挂载卷生命周期和Pod绑定Pod删了卷也跟着没PersistentVolumePV是集群级别的存储资源独立于Pod存在PersistentVolumeClaimPVC是用户对存储资源的申请请求。PVC和PV的关系很像编程里的接口和实现用户只声明我要5G的读写存储至于背后是云盘还是本地目录由管理员通过StorageClass自动Provision来保证。存储的访问模式AccessModes是一个极其重要又容易被忽视的配置。它有三种ReadWriteOnceRWO表示只能被一个节点挂载读写ReadOnlyManyROX表示可以被多个节点同时只读挂载ReadWriteManyRWX表示可以被多个节点同时读写。很多人创建PVC时根本不关心这个字段结果Pod调度到第二个节点上挂载失败卡在ContainerCreating。尤其注意云厂商的块存储比如云硬盘大多只支持RWO如果你的应用需要多个Pod同时读写同一份数据必须使用支持RWX的文件存储。在Pod存储配置里还有一个细节叫subPath。如果你把同一个卷挂载到Pod里的多个目录或者只挂载某个子目录而不是整个根目录就要用subPath。比如你的ConfigMap挂载了多个配置文件到不同路径不指定subPath的话K8s会帮你在卷的根目录创建目录结构跟预期往往不一致导致配置加载失败。这个坑我踩过至少三次每次都是配置文件路径不对查半天才发现是挂载方式的问题。5. 排障实战Pod卡在ContainerCreating时我通常这样定位Pod排障是每个K8s运维的日常。我不打算给你背一遍kubectl describe和kubectl logs的手册而是用我实际排查过的几个典型案例把排查思路串起来讲。案例一ImagePullBackOff镜像拉不下来。这个状态的原因就几种镜像名字写错、tag不存在、私有仓库认证失败、镜像仓库网络不通、镜像太大拉取超时。排查顺序也是固定的先kubectl describe pod看Events如果显示ErrImagePull或者ImagePullBackOff第一步检查镜像地址拼写第二步检查imagePullSecrets是否配置了私有仓库凭据第三步在节点上手动docker pull测试网络和仓库连通性。有个容易被忽略的细节如果你用的是新版的containerd而不是docker作为容器运行时docker login的认证文件对K8s是不生效的必须用kubectl create secret docker-registry创建镜像拉取凭据。案例二Pod一直Pending。如前面说的这个问题几乎都是调度器不给力导致的。最常见的原因是资源不足——你看一下节点的allocatable资源和已分配资源CPU和内存接近打满就会导致新Pod一直等。这个时候不要手动去删别的Pod腾资源正确做法是提高这个Pod的资源request让它被调度器优先考虑或者检查是不是忘记了节点亲和性导致没有节点匹配。有一个很容易忽略的点如果你给Pod设置了资源request但集群里每个节点上都没法同时满足request和已有Pod的request调度器就会一直pending。有些资源超卖很严重的节点上看free还有不少内存但因为request已经算满了调度器就是不让你调度过去。案例三CrashLoopBackOff反复重启。这个前面提过一次这里讲一个具体的定位技巧。当容器启动就崩溃日志看不到有效信息时可以先看启动命令确认进程是前台运行再检查环境变量和挂载的配置文件往往问题出在配置文件的格式或权限上。一个经典场景把ConfigMap挂载进容器后容器里读取的配置文件还是原来的默认值这是因为ConfigMap更新后Pod里的挂载不会自动更新需要重启Pod。从K8s 1.20之后挂载的ConfigMap更新后会有一定延迟同步的机制但不会触发重启这一点务必注意。案例四Pod状态Ready但是访问不通。这种问题最容易让人头疼因为Pod本身是正常的但流量就是进不来。排查思路从下往上先确认Pod的IP能不能ping通同节点内测试确认容器内的服务监听在正确的端口不要监听在127.0.0.1上K8s的Service转发是从宿主机网络进来的如果只监听backlog地址会全部拒绝确认Service的selector匹配到了这个Pod——这是最常见的错误selector写错导致Endpoints为空最后再检查网络策略NetworkPolicy是否放行了。排障的本质是快速缩小范围。我的习惯是先看Pod状态和Events再看容器日志再检查网络和存储最后才看代码和配置。按照这个顺序80%的问题都能在五分钟内定位。不要一上来就怀疑是网络插件的问题那是最后才查的。6. Pod管理进阶节点维护、滚动更新与资源规划的实际经验Pod管理做到最后你会发现核心问题不再是怎么建Pod而是怎么在生产环境安全地变更Pod。这里讲三个我最有发言权的场景节点维护时怎么优雅地腾空节点、发布新版本时怎么保证不中断服务、以及资源配额怎么规划才能不浪费又不踩坑。节点维护当你需要重启一台节点机器或者升级内核不能直接关机。K8s有一个优雅的机制叫节点排水cordon drain。先执行kubectl cordon 把节点标记为不可调度新Pod不会调度过来然后执行kubectl drain --ignore-daemonsets --delete-emptydir-data把节点上已有的Pod驱逐到其他节点。drain的过程会遵守Pod的terminationGracePeriodSeconds给Pod时间处理完存量请求再退出。这里一定要加--ignore-daemonsets因为DaemonSet的Pod是集群里的守护任务比如网络插件、日志采集驱逐了也会被DaemonSet控制器重新创建到原节点不忽略会报错。维护完成后kubectl uncordon 恢复调度。滚动更新Deployment的滚动更新策略是保证服务不中断的关键。默认情况下K8s会先创建一个新Pod副本等它Ready之后再销毁一个旧副本如此交替直到全部替换。但默认策略不一定适合所有场景。如果你的服务是单副本的滚动更新时会出现新旧版本并存短暂时间内流量被分到两个版本上可能引发数据格式不兼容的问题。这种情况下可以设置strategy: {type: Recreate}先杀掉旧Pod再创建新Pod牺牲短暂不可用换取数据一致性。另一个关键参数是maxUnavailable和maxSurgemaxUnavailable表示更新过程中允许多少个旧Pod不可用建议设置为0maxSurge表示最多允许多出多少个新Pod建议设置为1或者25%。这两个参数配合就绪探针可以做到发布期间一个Pod都不少新Pod完全Ready后才开始摘流量。资源配额Pod的资源请求与限制设置是运维里最需要经验的地方。请求值request是调度器做决策的依据限制值limit是运行时强制执行的阈值。很多人的误区是把request和limit设成一样的值这样Pod的QoS等级是Guaranteed不会被驱逐但资源利用率往往不高。我见过一个团队把所有的Java应用内存request都设为4Glimit也是4G结果一个节点16G内存只能塞3个Pod剩下4G内存永远闲着。更合理的做法是根据压测数据设定requestlimit设为request的1.2到1.5倍利用Burstable QoS来提升节点利用率。但要小心Pod内存超过limit会被OOM Killer杀掉和宿主机内存不足杀进程是两回事。Namespace层面的资源管理当团队人多项目杂时一定要用ResourceQuota和LimitRange来规范。ResourceQuota限制了整个Namespace的总资源上限防止某个团队把集群资源全部占满。LimitRange则给Namespace里的每个Pod设置默认的request和limit避免有人不写资源限制把节点打爆。我在公司里推行过一套规范每个Namespace必须有ResourceQuota每个Deployment必须显式声明resources字段CI流水线里检查这两个条件不满足直接拒绝发布。推行之后集群层面的资源争抢问题少了八成。还有一个容易忽略的点Pod的优雅终止Graceful Shutdown。terminationGracePeriodSeconds默认是30秒当Pod被删除时kubelet会先发送SIGTERM信号给容器的主进程等待这个时间之后才发送SIGKILL强杀。如果你的服务需要处理存量请求的时间超过30秒比如正在处理一个耗时的HTTP请求一定要调大这个值。但也不要无限调大否则节点排水会被拖得很久。我的建议是Web服务设60秒批处理任务设300秒同时业务代码里要正确处理SIGTERM信号——先停止接收新请求等存量请求处理完再退出。7. 给刚上手K8s团队的三条建议以及我踩过的代价最大的坑最后写一点心得。K8s上手曲线陡峭是公认的但我观察了很多团队之后发现大多数人不是被技术难倒的而是被不知道还有这么个概念难倒的。你如果不知道有Pod这层抽象就会拿它当Docker用怎么用怎么别扭你如果不知道有探针这个概念出了问题就只能靠人工盯着。第一个建议一定要在开发环境就启用资源限制。不要因为开发环境无所谓就省略resources字段。K8s集群是共享的一个没有资源限制的Pod可能把节点资源吃满导致其他的开发同学的Pod全部受影响。我们团队就出过一次大事故某个同事在开发环境跑了一个没有limit的数据导出任务内存暴涨触发了节点OOM把整个节点上的其他服务全拖垮了包括一个正在演示给客户看的重要环境。从那次之后我们用LimitRange做了兜底。第二个建议日志和监控一定要提前配好。K8s的Pod是脆弱的随时可能被重新调度、被驱逐、被扩容缩容如果你没有集中式日志和监控告警等Pod没了你连它发生了什么都不知道。我们在生产环境部署了Prometheus和Grafana监控Pod的CPU、内存、重启次数、网络流量告警规则里有一条Pod重启次数超过5次/15分钟必报警这条规则救过我好几次。第三个建议别过度设计。初学者容易一上来就想把所有高级特性都用上——HPA、VPA、PodDisruptionBudget、NetworkPolicy、ServiceMesh结果配置复杂到维护不起来。K8s最大的优势是标准化你的系统越简单K8s的威力越能发挥。先用好Deployment、Service、ConfigMap、PVC这四件套把业务稳定跑起来确有必要时再渐进式引入高级特性。代价最大的那个坑我想单独拿出来说生产环境直接删除Namespace。我记得有次做资源清理想删掉一个废弃的测试Namespace结果手滑删错了把生产Namespace删了。K8s删除Namespace会级联删除里面所有的Deployment、Service、ConfigMap、Secret、PVC而且这个过程是不可逆的——即使你开启了回收站机制PVC里的数据也没了。那次事故导致我们丢失了几天的数据库备份幸好数据库有跨集群的备份机制才没有全丢。从此以后我在任何生产集群里执行删除命令之前都会先执行kubectl get namespace确认名字然后在删除命令后面加上--waitfalse看看能不能通过计划任务恢复。Pod管理这件事说到底是K8s一切能力的载体。你把它理解透了Service、Deployment、StatefulSet这些高级对象都是在Pod之上的不同管理策略理解起来会顺畅得多。这篇文章里的很多经验都是用故障和事故换来的写出来只希望你能少走这些弯路。总之K8s不难难的是对它的心智模型跟传统的服务器运维不一样一旦转过弯来你会发现它是目前最优雅的集群管理方案没有之一。
