这篇是Kubernetes系列的第五篇。前四篇我们基本把K8s的架构、网络、存储和集群初始化都过了一遍这一篇集中补两块硬骨头Rancher到底怎么部署Pod的各种细节怎么理解。为什么把这两件事放在一起因为在实际工作中它们是连着的——你用Rancher去做多集群管理和可视化运维界面上看到的每一个工作负载、每一份调度状态落到最底层都是Pod反过来如果你对Pod的机制理解不透就算把Rancher拉起来了出问题照样一头雾水。这篇文章适合两类人一是正在做Kubernetes企业项目实战、纠结Rancher怎么落地的人二是写Pod YAML只敢复制粘贴、排障只会翻日志尾部的同学。我会把Rancher从单机到高可用的部署路径讲清楚再把Pod的底层逻辑、字段含义、生命周期和常见故障一次性拆透全程用生产环境里真实踩过的坑说话。1. Rancher在生产环境的价值我为什么放弃裸kubectl1.1 多集群管理和权限隔离的真实痛点我自己最早管理Kubernetes集群的时候环境只有两套测试和生产用一台跳板机切kubeconfig也还凑合。后来业务规模上来开发、测试、预发、生产四个环境加上不同项目组要隔离问题马上就来了。首先是上下文切换明明在测试集群里执行了一个kubectl delete结果发现切错了context这种低级错误真是能让人一夜白了头。其次是权限直接把一个项目的负责人拉进集群管理没有边界他可以不看你的RBAC规则直接看所有namespace的配置。Rancher解决的就是这些实际问题通过一个统一入口管理多个集群每个集群的kubeconfig不需要给到每个人手里用户在Rancher上按项目授权能看到哪些namespace、能执行哪些操作全部由Rancher对接后端RBAC来控制。还有一点是审计Rancher会记录用户的操作轨迹出问题的时候往回一查谁在什么时候删了什么资源一目了然。对于做企业项目实战的人来说这一层管理和合规能力往往比K8s本身还重要。1.2 Rancher组件架构管理面与数据面如何连线很多第一次用Rancher的人都会困惑Rancher Server到底是个什么东西它和业务集群是什么关系。简单说Rancher Server本身跑在你指定的一个Kubernetes集群上这个集群在Rancher里叫local集群承载的是Rancher自身的Web UI、认证服务、API服务等。当你创建一个下游集群或者导入一个已有集群时Rancher会往下游集群里下发两类Agent一类是cattle-cluster-agent部署在下游集群内负责和Rancher Server保持通信把Rancher的指令翻译成对下游集群API的调用另一类是cattle-node-agent负责执行节点层面的操作比如给节点打标签、收集节点状态。值得注意的一个关键点Rancher Server不依赖下游集群里面的任何业务Pod存活下游集群的网络、存储、计算资源也都是自己管自己的。Rancher本质上是一个翻译官和控制台的角色通过Kubernetes API来操作下游集群。这意味着就算Rancher Server挂了你的业务集群里所有已经运行的Pod该跑还是跑只是暂时没人帮你做界面管理了。想明白这一点你就不会在生产环境里把Rancher Server和业务集群混在同一个节点上裸跑也不会担心Rancher挂了是不是我的业务也挂了。1.3 和原生Dashboard、K9s、Lens怎么选有人会问有Kubernetes原生的Dashboard还有K9s、Lens这些轻量工具为什么还要用Rancher我的看法是看场景。原生Dashboard功能一直比较简陋权限模型和RBAC对接得也不算顺很多企业用了一阵就弃了。K9s是终端神器适合一个人快速操作集群但它本质是增强版kubectl解决不了多租户、多集群的管理和审计问题。Lens的体验不错但它的部署形态和团队协作支持不如Rancher成熟。Rancher的核心优势是平台化它把多集群接入、身份认证对接LDAP/OIDC、RBAC授权、项目/namespace两级隔离、监控告警、应用商店、GitOps持续交付都整合在了一个产品里。企业里要的不是一个好看的终端而是一套能让运维团队和多条业务线团队同时使用、还能划清边界的管理体系。如果你是个人玩测试环境K9s完全够用但如果面对的是生产环境的Kubernetes企业项目实战Rancher是当前最成熟的选择之一。2. Rancher部署实操单机版与高可用的完整路径2.1 部署形态怎么选先想清楚规模和故障域Rancher的部署方式大体分三类Docker单机版、Helm部署在已有K8s集群上的高可用版、以及配合RKE/RKE2/K3s的一体化部署。选型逻辑其实很直白你的Rancher Server是管理面它挂了对运维的影响有多大以及你管理的业务集群有多少套。这里先说结论测试环境用Docker单机版图个省事生产环境至少用Helm高可用版也就是把Rancher Server跑在一个独立的Kubernetes集群上比如用RKE2搭一个三节点的管理集群然后在这个集群里通过Helm安装Rancher。很多人在这个环节犯的错误是直接用一个业务节点跑Docker版Rancher然后把所有业务集群都导进来。一旦这个节点磁盘满或者内核出问题Rancher和业务互相干扰排障的时候你会怀疑人生。2.2 Docker单机版测试环境的五分钟快速拉起单机版拉起确实很快一条命令就搞定docker run -d --name rancher \ --restartunless-stopped \ --privileged \ -p 80:80 -p 443:443 \ -e CATTLE_BOOTSTRAP_PASSWORD你设置的初始密码 \ rancher/rancher:v2.7.9启动后等一两分钟浏览器访问https://服务器IP就能看到初始化界面首次登录用CATTLE_BOOTSTRAP_PASSWORD设置的管理员账号进去然后按向导创建或导入集群。这个--privileged参数挺多人不理解它的作用是让容器内部的Rancher有足够权限管理iptables规则和mount这是它初始化local集群和运行底层组件时需要的。单机版有两个明显短板你要心里有数一是数据全在这个容器里升级、迁移、备份都得单独处理docker rm一下你就什么都没了二是它跑的是一个内嵌的K3s集群承载能力有限不适合管理大规模生产集群。我这边的经验是单机版只用来做功能演示、验证新版本特性或者管理两三个小规模测试集群生产环境绝不碰。2.3 Helm高可用部署生产环境的正确打开方式生产环境推荐的前置条件是这样一套组合先用RKE2或K3s搭建一个独立的管理集群至少三个节点然后在它上面安装cert-manager、ingress-nginx最后用Helm装Rancher。大致过程如下。先装cert-manager这个组件负责自动签发和管理TLS证书Rancher的Web和Agent通信都要用到HTTPS证书kubectl create namespace cert-manager kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.13.2/cert-manager.yaml然后添加Rancher的Chart仓库并安装kubectl create namespace cattle-system helm repo add rancher-stable https://releases.rancher.com/server-charts/stable helm repo update helm upgrade --install rancher rancher-stable/rancher \ --namespace cattle-system \ --set hostnamerancher.ops.example.com \ --set bootstrapPassword你的初始密码 \ --set replicas3 \ --set ingress.tls.sourceletsEncrypt这里有几个参数要格外注意。hostname一定要写一个能解析到Rancher Server的域名不要图省事写IP因为后面所有下游集群的Agent都要通过这个域名来回连Rancher Server中途换域名会让你陷入重新注册所有集群的噩梦。replicas3配合PodDisruptionBudget保证管理面在节点维护时不会全部宕掉。ingress.tls.sourceletsEncrypt是让Rancher通过cert-manager自动申请证书如果你有自己的证书改成secret并指定ingress.tls.secret也可以。装完之后验证一下kubectl -n cattle-system rollout status deploy/rancher kubectl -n cattle-system get pods -o wide等所有Pod进入Running访问配置的域名用bootstrapPassword登录第一步会让你修改初始密码这个动作一定要做别留给别人。2.4 导入已有集群与网络放行注意点Rancher支持两种方式纳入集群一种是直接在Rancher上创建Kubernetes集群它会帮你调用RKE/RKE2去节点上装另一种是导入已有集群这种方式对你的现有业务影响最小。导入操作用的是Rancher UI上的导入已有集群它会生成一段注册命令把命令在下游集群里执行一下Agent就会自动部署完成注册。导入之前网络放行是最大的坑。Rancher Server需要能够访问下游集群的kube-apiserver端口默认是6443下游集群的Agent需要能够访问Rancher Server的443端口。如果你的下游集群在另一个VPC或者有安全组策略没放行这两条路导入过程会一直卡在Waiting for agent to check in。另外导入命令会在下游集群里创建cattle-system命名空间和一堆ClusterRole权限不足会直接失败所以导入操作最好用有足够权限的管理员账号来执行。一个实操建议给下游集群加上集群标签比如regioncn-north、envprod后续在Rancher里做跨集群的资源检索和监控筛选都会方便很多。3. Pod底层逻辑为什么Kubernetes不直接管容器3.1 从合租理解Pod共享才是它的核心刚开始接触K8s的人大概率会问一个问题Docker已经把容器搞得好好的了为什么Kubernetes非要再包一层Pod我的答案是因为很多应用其实不是一个进程能搞定的而这一组进程之间需要共享网络、共享存储还要保证它们始终被调度到同一台机器上。我把Pod比作合租房容器是合租的室友Pod是这套房子。室友之间共用Wi-Fi网络命名空间、共用冰箱共享存储卷、门牌号是同一个一个Pod一个IP而且这套房子搬家的时候所有室友必须一起搬因为他们是作为一个整体存在的。最典型的场景就是日志采集主容器跑业务边车容器跑Filebeat或Prometheus Exporter两个容器共用同一个数据卷业务写的日志文件边车立刻能采集走。如果让这两个容器各活各的没有Pod这一层你没法保证它们永远在同一台宿主机上共享卷设计也会变得很别扭。3.2 pause容器整个Pod的船锚你如果到集群节点上去执行crictl ps会看到一个让人困惑的现象每个正常业务容器的旁边总有一个名字里带pause的容器状态还是Running。这个容器就是Pod的船锚也叫做Infra Container。kubelet在创建Pod的时候会先启动这个pause容器它负责创建并持有整个Pod的网络命名空间、IP地址和Mount命名空间。主容器和边车容器再加入时直接join到pause容器已经创建好的这些共享命名空间里。pause容器还有一个作用生命周期锚定。只要pause容器还活着这个Pod的网络就是通的一旦pause容器退出kubelet就会认为整个Pod需要重建哪怕业务容器还在跑也没用。理解pause容器能帮你在排障时避免不少误判。比如某个Pod显示ContainerCreating很久你去节点上看容器列表发现pause容器起来了、业务容器还没起来那问题多半出在镜像拉取或容器运行时上如果pause容器都没起来那问题多半在运行时containerd或CNI网络插件上。方向比瞎翻日志重要得多。3.3 Sidecar、Init容器多容器编排的基本功Pod里可以编排多个容器除了前面说的业务日志边车这种Sidecar模式还有更常见的Init容器。Init容器是串行启动的每个Init容器成功退出后才会启动下一个全部完成后才开始启动主容器。它适合做三类事情一是等待依赖服务就绪比如数据库、配置中心还没起来先在Init容器里循环探测二是做前置配置比如给数据卷初始化权限目录、生成配置文件三是下载需要在启动前准备好的数据。实际操作中我常用的一个套路是用Init容器等依赖避免业务容器一启动就连不上数据库而CrashLoopBackOff然后用Sidecar做日志采集主容器只负责写标准输出或本地文件两者通过共享EmptyDir卷中转。这样业务镜像可以做得非常干净代码里不需要考虑日志怎么外传的问题这也是企业项目实战里推荐的容器设计思路。4. Pod YAML逐字段拆解看得懂才能写得出4.1 一个完整Pod/Deployment配置的骨架很多同学到了提YAML就头大其实核心字段就那些把下面这个Deployment例子逐个字段吃透日常80%的配置都能自己写了。apiVersion: apps/v1 kind: Deployment metadata: name: demo-app namespace: production labels: app: demo-app spec: replicas: 3 selector: matchLabels: app: demo-app template: metadata: labels: app: demo-app spec: initContainers: - name: wait-db image: busybox:1.36 command: [sh, -c, until nslookup db-service; do echo waiting; sleep 2; done] containers: - name: app image: registry.example.com/demo-app:v1.2.3 imagePullPolicy: IfNotPresent ports: - containerPort: 8080 name: http resources: requests: cpu: 250m memory: 256Mi limits: cpu: 500m memory: 512Mi readinessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 5 periodSeconds: 10 livenessProbe: httpGet: path: /livez port: 8080 initialDelaySeconds: 15 periodSeconds: 20 securityContext: allowPrivilegeEscalation: false readOnlyRootFilesystem: true runAsNonRoot: true restartPolicy: Always说几个容易踩坑的字段。imagePullPolicy有三种取值Always、IfNotPresent、Never。如果镜像tag是latest默认策略就是Always每次启动都会去拉一次这在离线环境或者内网镜像仓库网络抖动时极易拉取超时生产环境建议镜像全部打上具体版本号策略用IfNotPresent既避免每次都拉取又能保证镜像内容可追溯。command和args容易和Dockerfile里的ENTRYPOINT混淆K8s里如果写了command它会覆盖Dockerfile的ENTRYPOINT如果只写args它会作为参数传给Dockerfile的ENTRYPOINT。这个规则我记错过好几次线上容器起不来往往就是这个原因。4.2 requests和limits调度与驱逐的博弈resources.requests和resources.limits是生产环境必须写的字段不是可选项。requests告诉调度器这个Pod最少需要多少资源调度器在选节点时会根据所有节点剩余可分配资源来判断能不能放下limits则是硬上限容器超过limits中CPU的限制会被限流超过内存限制会触发OOMKilled。这里有一个关键的知识点CPU的limits是会被Kubernetes用Completely Fair SchedulerCFS强制限制的但内存的limits是运行时层面的限制容器试图分配超过限制的内存就会被内核杀掉。这导致一个很常见的现象容器OOMKilled重启你自己看应用日志啥也没有因为不是应用主动报错是内核直接Kill了进程。遇到这种问题kubectl describe pod里看到Last State: Terminated Reason: OOMKilled就算破案了。还有一个容易被忽视的性能问题如果requests写得太高比如一个本来只需要128Mi内存的服务写成512Mi每个节点能塞下的Pod数量就会大幅减少资源利用率直线下降。我给团队定的规矩是requests按实际业务压测的稳态值来定预留20%-30%的bufferlimits按峰值来定一般是requests的1.5到2倍。别拍脑袋写拿监控数据说话。4.3 三种探针应用健康的三道防线Kubernetes给容器提供了三种探针分别是livenessProbe、readinessProbe和startupProbe它们解决的是不同的问题。livenessProbe判断应用是不是活着失败次数超过阈值就会重启容器适合捕获死锁、内存泄漏这类进程还在但实际已经无法继续服务的情况。readinessProbe判断应用能不能接收流量失败时Pod会被从Service的Endpoints中摘除不会影响滚动更新和负载均衡适合应对应用启动慢、依赖后端暂时不可用的情况。startupProbe是给启动特别慢的应用准备的在它成功之前livenessProbe和readinessProbe都不会执行避免启动慢的Java应用还没起来就被liveness探针反复打死。探针支持三种探测方式exec执行命令、httpGet请求HTTP接口、tcpSocket建立TCP连接。我的经验是优先用HTTP接口但前提是你得在应用里真的实现一个健康检查端点返回实际依赖状态比如/healthz里检查数据库连接和缓存连接而不是只返回200。有些Jenkins、老系统没有健康检查端点只能用tcpSocket探活端口这种方式能发现进程挂掉但发现不了应用假死。探针参数也要调明白initialDelaySeconds是启动后等多久再开始探测periodSeconds是探测间隔timeoutSeconds是单次探测超时failureThreshold是连续失败多少次才判死。很多同学照着网上模板抄livenessProbe写了个很短的failureThreshold结果应用偶发卡顿一下就被重启滚动更新永远都滚动不完这就是探针参数和业务实际不匹配。4.4 securityContext与镜像配置的细节扣分项securityContext是容器安全的门锁记录一下我自己的强制要求runAsNonRoot: true禁止用root跑业务容器allowPrivilegeEscalation: false禁止提权readOnlyRootFilesystem: true让容器根文件系统只读需要写的临时数据挂载到EmptyDir。刚接触这些的时候会觉得过于严格实际操作中你会发现大部分应用代码根本不需要在根文件系统里写东西别扭的其实是那些写日志到/var/log的老应用用EmptyDir转发一下就能解决。另一个经常被忽视的安全点是capabilities。容器默认虽然是非root但可能保留了一些不必要的Linux capabilities比如NET_RAW、SYS_PTRACE。安全要求高的环境建议用drop把不需要的权限全部删掉securityContext: capabilities: drop: - NET_RAW - SYS_PTRACE - ALL这样就算容器被打穿攻击者可用系统调用面也小得多这在做企业项目实战交付、过客户安全验收时会给你省很多功夫。5. Pod生命周期和调度机制从创建到运行的每一步5.1 一次Pod创建请求的完整旅行理解Pod的运行机制要先走一遍它从提交到运行的完整链路。你执行kubectl apply之后请求先到kube-apiserver它做认证、授权、准入控制然后把Pod对象写入etcd。接着kube-scheduler通过watch机制拿到这个未调度的Pod开始做过滤和打分。过滤阶段会剔除掉资源不足、有不可容忍污点、不满足节点亲和性的节点打分阶段则根据资源余量、拓扑分布、反亲和规则等给候选节点排序最后把Pod绑定到得分最高的节点上。节点上的kubelet watch到自己被分配了Pod就调用容器运行时接口CRI去创建容器。这个过程中kubelet会先创建pause容器设置好Pod的网络命名空间、挂载Volume再一个个启动Init容器和业务容器。业务容器起来之后kubelet启动探针、收集状态、上报给apiserver。最后kube-proxy根据Service的Endpoints更新iptables或IPVS规则流量才能打到这个Pod上。这里面有一个和热词相关的细节如果你在节点上用了GPU、FPGA这类扩展资源调度器要能感知并分配它们靠的是Kubernetes的Device Plugin框架。设备厂商提供的Device Plugin会以DaemonSet形式跑在每个节点上通过Unix Socket向kubelet上报可用设备调度器把它作为Extended Resource来计数。我在一个推理平台项目里就是靠Device Plugin把GPU资源纳入统一调度的业务方不需要关心Pod具体落在哪个节点只要在resources.limits里写nvidia.com/gpu: 1就行。这个机制理解之后你再看调度流程就会觉得非常顺。5.2 Pod阶段与容器状态别再傻傻分不清kubectl get pod看到的STATUS列和容器真正的状态不是一回事这个知识点经常让新手翻车。Pod有五个阶段Pending表示已创建但还没完成调度Running表示Pod已经绑定节点且至少有一个容器在运行Succeeded表示所有容器正常退出Failed表示至少一个容器以非零状态退出Unknown表示kubelet失联apiserver获取不到状态。而容器本身的状态是三个Waiting、Running、Terminated。看kubectl describe pod时Containers下面会显示两个字段State和Last State。State是当前状态Last State是上一次退出的状态里面会带Reason和Exit Code。排查CrashLoopBackOff时Last State里的Exit Code特别关键比如Exit Code: 137通常是被OOMKilledExit Code: 1通常是应用自己抛错退出。还有一个容易混淆的点Pod状态显示Running不代表所有容器都健康。比如一个Pod里主容器在跑但liveness探针已经失败了几次Pod可能仍然显示Running直到失败次数超过阈值触发重启。所以判断健康别只看Pod阶段要把Pod状态、容器状态、探针结果三层叠在一起来看。5.3 调度细节nodeSelector、亲和性和污点容忍调度器默认的规则不一定符合你的业务诉求所以我们有了三件套nodeSelector、亲和性和污点容忍。nodeSelector最简单粗暴Pod的YAML里写nodeSelector: gpu: true调度器只会把这个Pod放到打了这个标签的节点上。它的缺点是只能做等值匹配不支持尽量在这种软约束。亲和性分为nodeAffinity、podAffinity和podAntiAffinity每种都支持requiredDuringSchedulingIgnoredDuringExecution硬性要求和preferredDuringSchedulingIgnoredDuringExecution软偏好两种模式。比如你可以用podAntiAffinity保证同一个Deployment的两个副本不落在同一个节点上故障时不会一个节点挂了导致整个服务雪崩。污点和容忍是用来拒绝和绕过的给节点打污点比如keydedicated, valuegpu, effectNoSchedule普通Pod就不会被调度过来只有显式声明了对应容忍的Pod才能进来。我给GPU节点打污点然后配容忍再加nodeSelector三层一起做既保证GPU资源只给需要的工作负载用又防止普通业务Pod把GPU节点的CPU/内存抢光。5.4 不同控制器下的Pod行为差异我们平常很少直接创建独立Pod多数是创建Deployment、StatefulSet、DaemonSet、Job这类控制器由控制器负责Pod的创建、更新和调谐。委托关系通过ownerReferences来标记所以你删Pod不是真删控制器会立刻再拉起一个新的直到副本数回到期望值。Deployment负责无状态应用滚动更新、回滚、缩扩容都是它StatefulSet管有状态应用为每个Pod分配稳定网络标识和稳定的PVCPod重建后身份不变DaemonSet保证每个节点上都跑一份适合日志采集、监控Agent、Device Plugin这类基础设施组件Job和CronJob负责一次性任务和定时任务。写YAML之前先想清楚自己的应用属于哪一类比纠结某个字段怎么写重要得多——无状态服务写成StatefulSet浪费存储还拖慢发布有状态服务写成Deployment数据库重排后身份全变了那就是生产事故。6. 高频Pod排障实录这些报错我全都踩过6.1 failed to create pod sandbox运行时和CNI联合故障这个报错的热度非常高完整文案类似failed to create pod sandbox: rpc error: code Unknown desc failed to create containerd task: failed to create shim task: OCI runtime create failed。碰到这个方向基本锁定在容器运行时和CNI网络插件这两块。第一步先看事件kubectl describe pod pod-name事件里如果提示failed to setup network for sandbox或networks failed to prepare那就重点查CNI。检查节点上的CNI二进制和配置ls /opt/cni/bin cat /etc/cni/net.d/*.conf查看containerd日志journalctl -u containerd -f --since 10 minutes ago我碰到过的一个经典案例是节点磁盘快满了containerd创建sandbox时写shim日志失败报错是no space left on device但应用日志区好像还有空间很容易被忽略。用df -h /var/lib/containerd一看就明白了。清理镜像、日志把磁盘空间问题解决掉Pod立刻恢复正常。另一个高频原因是重建节点忘了恢复/opt/cni/bin里的插件或者CNI配置文件残留了旧网段和当前VPC网段冲突。特别提醒排查这类问题crictl ps -a和crictl logs container-id比kubectl更直接因为kubectl拿到的很多信息是kubelet转述的。6.2 ImagePullBackOff与ErrImagePull镜像拉取问题全解ImagePullBackOff和ErrImagePull基本都在说一件事镜像拉不下来。原因无外乎这几种镜像tag写错或仓库里根本不存在私有仓库需要认证没配secret镜像太大kubelet的拉取超时时间不够节点网络到镜像仓库不通。排查第一步永远是看事件详情kubectl describe pod pod-name里面会具体提示是manifest unknown还是401 Unauthorized还是dial tcp ... connection refused。如果是认证问题创建secret然后挂到Pod上即可kubectl create secret docker-registry regcred \ --docker-serverregistry.example.com \ --docker-username你的账号 \ --docker-password你的密码 \ --namespaceproduction然后在Deployment的Pod模板里加imagePullSecrets: - name: regcred另一个容易被坑的点是镜像仓库的tag策略很多内部CI/CD平台会给每个构建号打一个很长很怪异的tag比如xxx-20250515-abcdef123456从页面复制的时候容易多复制一个空格或截断。有个小技巧拉不下来先直接到节点上手动执行crictl pull或docker pull同一镜像能拉下来就说明问题在网络或配置拉不下来就看报错原文比在Pod事件里猜效率高。6.3 CrashLoopBackOff从日志到配置的排查闭环CrashLoopBackOff大概是生产环境最熟悉的报错了。它出现的直接原因是容器启动后很快退出kubelet按restartPolicy反复重启重启间隔指数退避。排查思路我按顺序走先看日志再看退出码最后看配置。看日志要带上前一个容器实例的日志因为当前实例可能启动后秒挂日志很少kubectl logs pod-name --previous然后看退出码kubectl get pod pod-name -o yaml重点看lastState.terminated.exitCode。137优先查内存limit和OOMKilled1一般看应用日志里的报错堆栈126、127通常是启动权限或命令本身的问题比如容器里没有这个可执行文件。一个我反复强调的经验CrashLoopBackOff不一定都是应用代码问题探针配置错误也会导致它。比如livenessProbe的initialDelaySeconds设得比应用真实启动时间短应用还在初始化接口没起来探针连着失败几次kubelet直接把容器杀了进程变成无限重启。这种假Crash在日志里往往看不出任何异常排查时一定要把探针参数和应用启动耗时对齐。最快定位方式是把livenessProbe临时去掉看容器能不能稳定Running能稳定就说明是探针的问题。6.4 Pod一直Pending或ContainerCreating卡住的原因清单Pod长时间卡在Pending说明调度还没完成优先看kubectl describe里最后一段Events。最常见的提示是0/3 nodes are available: 2 Insufficient cpu, 1 node(s) had taint ...前者说明资源不足后者说明节点有污点没被容忍。资源不足就缩副本、调requests或加节点污点问题要么给Pod加tolerations要么去掉节点上不需要的污点。卡在ContainerCreating则复杂一点常见原因有三类一是Volume挂载失败比如PV的storageClass没装对、PVC一直Pending、NFS路径不存在二是CNI网络初始化失败和前面sandbox问题同源三是镜像拉取卡住特别是超大镜像或仓库网络慢。排查命令也很固定kubectl describe pod看事件如果事件信息不够就去节点上结合journalctl -u kubelet和crictl ps -a两路一起看。有一次我们的PVC创建一直Pending查了很久发现是存储类的allowVolumeExpansion配错加上后端存储池没建好导致的这种问题在事件里会明确提示Provisioning failed跟着报错去查存储端配置就行。6.5 顺带说说API安全加固别让集群裸奔最后想借一个热词聊点安全Kubernetes集群要特别注意API端点的暴露风险。很多团队图方便把kube-apiserver的6443端口直接暴露在公网或者开了匿名认证又没有完善的RBAC这种配置基本就是把集群的钥匙挂在门口。作为运维方我能给的建议非常明确第一kube-apiserver只绑定内网地址通过安全组或防火墙限制来源IP第二关闭匿名认证确保所有请求都有身份第三RBAC遵循最小权限给普通用户、给项目的ServiceAccount只分配能完成工作的最小权限别动不动就cluster-admin第四开启审计日志定期查看敏感操作第五初始化Rancher后立刻改掉默认管理员密码并用LDAP或OIDC做统一认证。这些都是我能亲手落地、也建议每个团队做的加固项成本低收益大。我在实际项目里最大的体会是Rancher和Pod的知识看着是两块但在运维里永远是连在一起的。Rancher界面上你点开的每一个工作负载底层都是一组Pod在按生命周期机制运转你在命令行里排查的每一个Pod状态最终都要通过Rancher的Agent反馈到管理面上。所以别把它们当成两个孤立的话题建议先按这篇文章把Pod的机制吃透再用Rancher去实际管理几套集群练手积累几次真实排障记录对这套体系的掌握程度会完全不一样。
