1. 为什么K8s的最小调度单位不是容器而是Pod很多人刚接触Kubernetes时都会有一个根深蒂固的疑问明明我们用的是Docker跑的也是容器为什么K8s不直接调度容器非要中间套一层Pod这个疑问我在刚上手K8s时也纠结了很久直到真正在生产环境里踩过坑才明白Pod这层抽象的设计哲学。先说结论Pod不是容器的简单包装而是一个共享命运的调度单元。K8s之所以不直接调度容器是因为在微服务架构里存在大量必须同生共死、同进同退的场景。比如一个日志采集容器它必须和应用容器跑在同一台宿主机上读同一个日志目录应用挂了它也要跟着退出否则就会产生日志断层。如果你把这两个容器分开调度它们可能落在不同的机器上日志就永远对不齐。用生活化的类比来说Pod就像一条船上的几个船员Container是各司其职的船员。船沉了大家一起沉船靠岸大家一起上岸。你不能让船长这条船和划桨那条船分开走因为它们的任务是一体的。这个同船共渡的概念就是K8s调度的最小原子单位。从技术实现上看Pod还有一个关键属性Pod内的所有容器共享同一份网络命名空间和存储卷。这句话翻译成人话就是同一个Pod里的容器共享同一个IP地址和端口空间。同一个Pod里的容器可以通过localhost直接互相访问。同一个Pod里的容器可以用内存共享的方式交换数据更准确说是IPC通信。同一个Pod里的容器挂载的存储卷是彼此可见的。这个设计带来一个非常实用的推论你在Pod里跑一个Nginx和一个业务进程Nginx监听80端口业务进程监听8080端口两者通过localhost:8080通信完全不需要经过网络层转发。这在非Pod的容器编排环境里是做不到的。所以当你决定要不要把两个容器塞进同一个Pod时第一个要问自己的问题不是能不能塞而是它们需不需要共享IP和存储需不需要同生共死。如果答案是是的那Pod就是为这个场景而生的。2. Pod的两种核心类型工作负载Pod与静态PodK8s里的Pod从创建方式上来分大体可以分成两大类。明白了这个分类很多概念就豁然开朗了。2.1 工作负载Pod由控制器管理这是我们在日常使用中接触最多的Pod。它不是你直接创建出来的而是通过Deployment、StatefulSet、DaemonSet这些控制器间接创建的。你把期望状态交给控制器控制器负责拉起Pod、维护副本数、处理滚动更新和故障恢复。我特别想强调一点你永远不应该直接创建一个孤零零的Pod。因为直接创建的Pod没有控制器盯着它一旦挂了Kubelet会老老实实地把它送走不会有人再帮你拉起一个新的。这就像你在公司门口摆了一盆花没有园丁给你管枯死了就是枯死了。生产环境里的正确姿势是写一个Deployment YAML声明副本数为3。提交给K8s API Server。控制器对比现状与期望发现没有足够的Pod于是创建3个Pod。如果某个Pod所在节点挂了控制器会在其他可用节点上重新拉起一个。这也是热词里k8s控制器被反复搜索的原因。控制器就是Pod的保险机制而Deployment是最常用的控制器之一。2.2 静态Pod由Kubelet直接管理静态Pod是另一种形态。它不经过API Server而是由节点上的Kubelet守护进程直接读取某个目录默认是/etc/kubernetes/manifests下的YAML文件发现文件就创建Pod删掉文件就销毁Pod。静态Pod最常见的应用场景就是K8s集群自身的核心组件。比如你查kubectl get pod -n kube-system会发现etcd、kube-apiserver、kube-controller-manager、kube-scheduler这些组件都是以静态Pod的形式存在的。这样设计的好处是显而易见的即使API Server挂了Kubelet依然能按照节点上的文件清单拉起核心组件保证集群的起搏器始终在工作。热词里有一条k8s三台master怎么保证高可用kubekey其实背后的机制就是让多个Master节点各自通过静态Pod方式运行核心组件再通过负载均衡器统一入口。某个Master挂了其他Master上的静态Pod不受影响集群依然对外服务。3. Pod的完整生命周期从Pending到TerminatedPod从诞生到销毁经历的一系列状态变化是我们排查问题最重要的依据。理解状态就理解了Pod的心电图。3.1 核心状态详解状态含义常见场景Pending已接受请求但尚未完成调度节点资源不足或镜像拉取中RunningPod已绑定节点所有容器已创建正常运行Succeeded所有容器成功退出一次性任务Job/CronJobFailed至少一个容器以非零状态退出应用崩溃、启动失败CrashLoopBackOff容器反复崩溃K8s暂时退避重启配置错误、依赖服务未就绪UnknownAPI Server无法获取Pod状态节点网络异常或者节点宕机这里我想把CrashLoopBackOff单独拎出来说说因为太常遇到了。这个状态翻译过来是崩溃循环退避意思是K8s发现你的容器启动后很快崩溃于是开始退避式重启——第一次等10秒重启第二次等20秒第三次40秒指数级增长上限是5分钟。这个机制是为了防止容器无限快速重启把节点CPU打满而设计的。很多新手看到CrashLoopBackOff就慌了其实排查思路极其固定kubectl logs pod-name看应用日志。kubectl describe pod pod-name看Events事件重点看有没有ImagePullBackOff、探针失败等信息。确认配置是不是有问题比如环境变量、ConfigMap、Secret没挂载对。3.2 探针Pod的健康自检机制热词里大家还喜欢搜k8s部署prometheus监控k8s但实际上在Prometheus介入之前K8s自己就有最基础的体检医生——探针Probe。探针分为三种存活探针livenessProbe判断容器是不是活着。如果失败Kubelet会杀掉容器并触发重启。就绪探针readinessProbe判断服务是否准备好接收流量。如果失败K8s会把Pod从Service的Endpoints列表里摘掉请求不会转发过来。启动探针startupProbe专为慢启动应用设计。在启动探针成功之前存活探针不会介入避免应用还在初始化就被误杀。我见过一个非常经典的生产事故某个Java应用启动需要40秒但存活探针在10秒后就开始探测连续失败3次后容器被强制重启。启动后又等待10秒探测再失败再重启——一个永远起不来的Pod。后来加了startupProbe把存活探针的保护期延后到60秒一切恢复正常。所以如果你负责的应用启动特别慢一定记得用启动探针别让K8s的好意变成帮倒忙。4. Pod与Deployment、Service、ConfigMap的协作关系热词里有pod configmap deploy这其实点出了一个核心问题Pod不是孤立存在的它要跟ConfigMap、Service、Deployment、存储卷这些组件协作才能组成一个完整的应用服务。4.1 DeploymentPod的副本控制器Deployment负责管理Pod的期望状态。它的核心字段包括replicas副本数selector匹配Pod标签templatePod模板含容器定义、资源限制、探针等strategy更新策略RollingUpdate滚动更新或Recreate重建为什么热词里有人搜如果给k8s deployment一个中文名字是什么——其实K8s资源命名遵循DNS规范只能是小写字母、数字和连字符理论上不支持中文。但可以用metadata.annotations加上中文备注作为业务描述信息。这个操作在排查问题时特别好用可以在kubectl get deploy时通过自定义列输出看到中文业务名。Deployment的滚动更新机制值得多说两句。默认的RollingUpdate策略会先创建一个新Pod等新Pod就绪后再下线一个旧Pod逐步替换。这个过程中最怕的就是新版本配置错误导致新Pod永远不就绪滚动更新卡死。所以务必在Deployment里配置progressDeadlineSeconds比如300秒超出时间后控制器会标记发布失败状态方便我们及时回滚。4.2 Service访问Pod的唯一入口一个Pod的IP是漂移的。它被删掉后重新创建IP就变了。如果业务请求直接打到Pod IP上Pod一重启就全网断线。Service就是解决这个问题的固定电话总机。Service通过Label Selector筛选后端Pod并为它们提供一个稳定的虚拟IPClusterIP。业务方只需要访问Service的IP或域名K8s底层把请求负载均衡到实际的Pod上。Pod再怎么漂移Service的入口始终不变。这里面有个细节很多人没注意到Service的负载均衡能力来自于它底层的Endpoint或EndpointSlice机制。每次Pod变化Kube-controller-manager都会更新Endpoint列表。如果Pod异常导致Endpoint列表为空Service就像一个没有座席的呼叫中心——电话能打通但永远没人接。4.3 ConfigMap与SecretPod的配置来源ConfigMap本质是键值对配置它的核心价值是把配置从镜像里解放出来。一个镜像打包好后在不同环境开发、测试、生产里跑就是靠ConfigMap注入不同的环境变量或配置文件来区分。热词里有人搜configmap deploy对应的就是kubectl create configmap然后在Deployment的envFrom或volumeMounts里引用。Secret的用法和ConfigMap几乎一样但存储的内容是敏感信息密码、证书。注意Secret在旧版本里是Base64编码存储的这不是加密只是编码。任何人只要能看到集群里的Secret对象就能解码出明文。要真正的加密需要开启etcd加密静态数据EncryptionAtRest。容易踩坑的点ConfigMap或Secret改了Pod里的内容是不会自动更新的除非使用了subPath方式挂载或配置了热更新方案。很多新手改了ConfigMap发现业务没变化就以为是配置不生效其实是Pod里的环境变量在创建时已经注入完毕之后改ConfigMapPod根本感知不到。解决办法是滚动重启Deployment让Pod重建重新拉取配置。5. 实操指南Pod的常用命令与YAML最佳实践热搜词里k8s常用命令出现了两次可见这是刚需中的刚需。下面这些命令是我在实际运维中几乎每天都要敲的按使用频率排序。5.1 高频命令清单# 查看Pod列表含所属节点和IP kubectl get pod -o wide # 查看带标签的Pod kubectl get pod -l appnginx # 查看Pod详情重点看Events字段 kubectl describe pod pod-name # 进入Pod内的某个容器多容器场景必须指定容器名 kubectl exec -it pod-name -c container-name -- bash # 查看Pod内某个容器的日志实时跟踪 kubectl logs -f pod-name -c container-name # 查看Pod的资源占用和恢复重启次数 kubectl top pod pod-name # 删除PodDeployment会自动重建 kubectl delete pod pod-name # 临时调试诊断网络在集群里起一个临时Pod kubectl run debug --rm -it --imagenicolaka/netshoot -- bash最后一条命令我要特别推荐。生产环境经常遇到某个Pod的网络不正常但Pod里又没有curl、ping这类工具这时候直接在Pod里装工具既不安全也不方便。用kubectl run debug --rm -it --imagenicolaka/netshoot -- bash拉起一个带全套网络诊断工具的临时Pod用它来访问目标Pod的地址定位问题又快又干净。5.2 一个相对完整的Pod YAML示例apiVersion: v1 kind: Pod metadata: name: myapp-pod labels: app: myapp env: production spec: containers: - name: myapp-container image: myapp:1.2.3 imagePullPolicy: IfNotPresent ports: - containerPort: 8080 env: - name: SPRING_PROFILES_ACTIVE value: production envFrom: - configMapRef: name: myapp-config resources: requests: cpu: 250m memory: 512Mi limits: cpu: 500m memory: 1Gi livenessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 30 periodSeconds: 10 readinessProbe: httpGet: path: /ready port: 8080 initialDelaySeconds: 10 periodSeconds: 5 volumeMounts: - name: log-volume mountPath: /var/log/myapp volumes: - name: log-volume emptyDir: {}虽然实际生产里通常不会直接写Pod而是把它作为Deployment的template模板但这个YAML能帮你理解Pod本身的骨架。尤其注意resources里的requests和limitsrequests是最低保障调度器根据它判断节点是否放得下这个Pod。limits是最高上限超过后容器可能被OOM Killer杀死。我见过不少公司只写limits不写requests导致节点上调度时觉得什么Pod都很小一运行起来资源直接被打爆。最好的实践是requests和limits都写上且维持一个合理的比例通常limits是requests的1.5到2倍左右。6. 高频报错排查failed to create pod sandbox 实战复盘热词里有一条非常具体的报错failed to create pod sandbox: rpc error: code unknown desc failed to create...。这条报错在kubelet日志里极为常见几乎每个K8s运维都遇到过。6.1 这个报错到底在说什么先把这条报错翻译一下Kubelet尝试为Pod创建沙箱Sandbox失败了然后底层容器运行时返回了未知错误。Pod沙箱是什么在Docker时代它对应的是pause容器也叫infra容器。这个容器非常特殊——它什么正经业务都不跑只负责持有Pod级别的网络命名空间和命名空间内的各种资源。Pod里其他容器启动时都会加入到这个pause容器的命名空间里。换句话说pause容器就是那条船本身的骨架。船骨架没搭起来船员业务容器根本没法登船。所以failed to create pod sandbox就是Kubelet连船骨架都搭建失败业务容器自然无法启动。6.2 完整的排查链路根据我的实操经验这条报错背后的原因通常集中在以下几个层面按顺序排查效率最高第一步确认容器运行时CRI的状态systemctl status containerd ctr version crictl version最常见的问题是containerd服务挂掉了或者版本与K8s不兼容。如果你用的是Docker作为运行时通过dockershim注意这个组件在K8s 1.24之后已被移除还需要确认docker服务正常。第二步检查底层的网络插件沙箱创建失败很大概率和CNI网络插件有关。因为创建沙箱的关键动作就是为pause容器配置网络。Calico或Flannel出问题直接导致沙箱无法完成网络设置。# 查看Calico相关Pod是否Running kubectl get pod -n kube-system | grep calico # 查看kubelet日志中的网络相关报错 journalctl -u kubelet --since 10 minutes ago | grep -i cni第三步检查磁盘与文件系统沙箱创建会涉及临时文件写入。如果节点的/var/lib/containerd目录所在的磁盘写满或者inode耗尽也会出现这个报错。很多人容易忽略inode问题它不像空间满了那么直观。检查方式df -h df -i /var/lib/containerd第四步检查操作系统兼容性这里有一个非常经典的坑。老版本K8s比如1.15-1.23使用Docker时如果宿主机内核太老或者缺少某些必要的安全上下文设置创建沙箱时在内核层面就会报错。尤其是CentOS 7.x 老版本docker K8s 1.20左右这个组合因为iptables和IPVS模块问题导致的沙箱失败我已经遇到不下三次了。如果你只想快速恢复可以先把节点上的容器运行时重启一下systemctl restart containerd经常有惊喜因为有些运行时状态卡死了重启后就好了。但这只能缓解一时必须找到根因否则问题会反复出现。6.3 防止沙箱问题的日常习惯说实话这类问题很多是攒出来的。节点长时间不重启临时文件越攒越多网络路由表越攒越杂最终以某个Pod调度到这台节点为导火索全面爆发。我的建议是给集群做定期的节点体检关注节点磁盘使用率超过70%就要预警因为镜像和容器日志会继续增长。定期清理长期退出的容器和无用的镜像crictl rmi --prune。K8s等基础组件的版本升级别拖太久。老版本里的很多bug在新版本里早已修复。7. 给初学者的Pod学习路线建议最后说点实际的。如果你正在学K8s绕开看文档-忘掉-再看-再忘的循环我推荐的学习路径是场景驱动。第一先把Pod当成一个小服务器来理解。不要一上来就陷入各种控制器、网络插件、存储插件的细节。先学会怎么创建Pod、怎么进Pod、怎么看日志、怎么删Pod。这些动作就像学会开关机、打开浏览器一样是最基础的肌肉记忆。第二理解Pod会死这个事实。一旦你接受Pod天生就是要被销毁重建的你对kubectl delete pod就不会有心理负担也会自然而然地理解为什么需要Deployment来管副本、为什么需要Service做固定入口。第三刻意练习排错。找一个测试集群故意把镜像名写错、把探针路径写错、把资源request写到节点装不下的程度然后去观察Pod的状态变化用describe和logs来定位问题。我自己带人学习最有效的方法就是制造事故-排查事故的循环。三个事故排查下来你对Pod的认知深度会超过很多人看一个月的文档。第四把热词里那些报错都亲手复现一遍。ImagePullBackOff、CrashLoopBackOff、failed to create pod sandbox每一个报错背后都对应着一个具体的组件交互逻辑。亲手解决过它们你对Kubelet、容器运行时、CNI插件这三者的协作关系才算真正的理解。Pod是K8s世界的细胞。把它弄透了后面的Deployment、Service、ConfigMap、HPA这些概念学起来会快得飞起。也希望上面这些踩坑和实战经验能帮你少走几步弯路至少在下一次看到Pod卡在Pending或CrashLoopBackOff时你不会一头雾水而是能顺着思路一步步找到答案。
