★ FEATURED ARTICLE 1. 从“能跑”到“懂跑”资源清单到底在写什么先聊一个很多人都会经历的阶段用命令直接创建资源很顺手kubectl run nginx --imagenginx一条命令就能起一个 Pod但到了企业环境里这种方式几乎没有任何用武之地。原因很简单命令行方式没法沉淀成标准化的交付物别人拿到你的命令还得重新执行一遍版本、参数、镜像Tag全都靠脑子记。而资源清单Manifest用 YAML 描述期望状态可以入库、可以做Code Review、可以走CI/CD流水线这才是企业级交付的基础。我见过不少刚接触 Kubernetes 的同学拿到一份 YAML 文件第一反应是“这不就是一份配置文件吗”。其实不然资源清单的本质是“声明式 API”的载体。你告诉 Kubernetes“我想要什么”而不是“你帮我怎么做”。比如 Deployment 清单里写了replicas: 3Kubernetes 就会持续保证集群里有3个副本Pod挂了它自动补一个新的哪怕没人手动操作。这种思维转换是从“运维思维”到“云原生思维”的关键一步。写资源清单有个特别实用的套路先搭骨架再填细节。骨架就是 K8s 资源的通用结构——apiVersion、kind、metadata、spec这四个字段几乎是所有资源清单的标配。先把它们列出来确认资源类型和命名空间再往 spec 里加具体内容。这个习惯能帮你避免很多低级错误比如字段写错位置、缩进对不齐导致的“解析失败”。企业实战中还有一个容易踩的坑分不清 apiVersion 的区别。同样是 Deploymentapps/v1和extensions/v1beta1是完全不同的世代后者早就不推荐使用了。判断准则其实很简单优先使用当前集群支持的最新稳定版本可以通过kubectl explain查看当前集群实际支持的字段和版本信息。从这段经历里我学到一件事资源清单看着枯燥但它其实是你理解整个 K8s 体系的“门钥匙”。后面要讲的 Pod 生命周期、控制器选型全都建立在“看得懂、写得好资源清单”这个前提下。所以这一节我打算把资源清单拆开揉碎讲讲字段到底怎么填、有哪些企业实战中特别要注意的细节。1.1 YAML 骨架拆解从空模板到能跑的 Pod我平时写资源清单的习惯是先起一个最小可运行的模板再根据需求往上加字段。拿最常用的 Pod 举例子一个空模板长这样apiVersion: v1 kind: Pod metadata: name: my-pod namespace: default labels: app: my-app spec: containers: - name: my-container image: nginx:1.25这套模板里apiVersion: v1是 Pod 所属的 API 组和版本kind: Pod声明资源类型metadata是元数据区spec是期望状态的描述体。metadata.name是资源名称同一个命名空间内必须唯一labels是标签后面控制器、Service 的关联全靠它。我先解释一下为什么这三个信息apiVersion、kind、metadata会放前面。Kubernetes 的 API 设计里它们决定了“这个对象是谁、属于哪个组、叫什么名字”类似于一个人的身份证信息。spec才是你要描述的具体行为。这里有个新手常见错误把containers误以为是container少写一个字母整个资源就会“无法识别”。我建议写完清单后用kubectl create --dry-runclient -f xxx.yaml做一次本地校验能发现大部分语法和格式问题。1.2 核心字段逐个拆镜像、容器端口、命令、环境变量spec.containers 是 Pod 里最重要的字段块。我挑几个企业里几乎天天用到的字段单独说。第一个是imagePullPolicy。它决定 Kubernetes 是否每次都从镜像仓库拉取镜像。取值有三种Always、IfNotPresent、Never。一个常见问题是本地节点上已经有某个镜像了但企业环境基本都要用私有仓库如果 tag 是latestK8s 默认会用 Always 策略强制拉取如果是具体版本号比如nginx:1.25.3则默认用 IfNotPresent。两者之间有个容易被忽略的性能差异——Always 会导致每次扩容都去仓库检查镜像网络抖动时甚至会造成 Pod 启动延迟。所以我在生产环境里坚持给镜像打具体版本号并且显式声明imagePullPolicy: IfNotPresent绝不裸用 latest。第二个是ports。很多新手以为只要写了containerPort容器就可以对外访问其实不是。这个字段只是“声明我开了这个端口”真正能不能访问取决于 Service 和网络规则。它的主要作用是给文档和运维工具看的。在 Istio 这类 Service Mesh 环境里它还能影响流量劫持行为所以端口一定要写准不要乱写。第三个常见需求是给容器传参数。K8s 里有两种方式command和args。注意它俩和 Docker 的 ENTRYPOINT、CMD 的映射关系command对应 Entrypointargs对应 Cmd。如果两个都写容器启动时的实际命令就会是 command args。多数时候我不建议在 YAML 里写 command除非镜像本身的启动方式确实需要覆盖。另一种传参方式是环境变量。env字段可以直接写值也可以引用 ConfigMap、Secret 或 Pod 自身的元数据。企业实战里最常见的场景是注入数据库连接串和密钥env: - name: DB_HOST value: mysql.default.svc.cluster.local - name: DB_PASSWORD valueFrom: secretKeyRef: name: db-secret key: password1.3 企业级必备resources、探针、挂载容器要想在企业环境里“有尊严地跑”资源限制必须从一开始就写好。resources.requests是调度器判断节点是否满足条件的依据resources.limits是容器运行时的硬上限。没有 requests调度器可能把很多 Pod 挤在同一个节点上导致资源争抢没有 limits某个容器内存泄漏可能拖垮整个节点。我常用的一个组合是CPU 的 requests 和 limits 保持一致的整数比如500m内存的 requests 比 limits 低一些比如512Mi对1Gi这样既保证 CPU 不超分过多又给内存留缓冲。这里要注意一个常识CPU 的1代表 1 核100m代表 0.1 核内存的单位是Mi或Gi分别对应 1024 的幂次和 MB/GB 的十进制计数不同。写错单位在集群里会产生十倍甚至千倍的偏差我有一次就是因为把128Mi写成了128M导致容器内存限制变成 128,000,000 字节几乎等于没限制。后来我把所有资源清单的 limits 做了规范化检查这种问题才绝迹。探针分三种livenessProbe存活探针、readinessProbe就绪探针、startupProbe启动探针。搞懂三者的区别是入门到进阶的必经之路。liveness 失败kubelet 会杀掉容器并重启readiness 失败流量不会打到这个 Pod 上startup 则是给启动慢的应用准备的防止它在启动阶段就被 liveness 误杀。企业实战里最常用的探针配置是 HTTP 请求readinessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 5 periodSeconds: 10探针参数每个都有讲究。initialDelaySeconds给容器留出启动时间不能设太短否则探针必然失败periodSeconds是探测间隔设太大了故障发现会变慢设太小又浪费资源。timeoutSeconds代表单次探测的超时一般建议 1-5 秒。失败阈值failureThreshold默认 3 次很多 Java 应用启动慢我会配合 startupProbe 把这一块处理好避免“启动即被杀”的恶性循环。挂载也是每天都用到的能力。volumeMounts是容器视角的挂载点volumes是 Pod 视角的存储源。注意两者是分开写的先声明有什么盘再把盘挂进容器。常见的emptyDir是临时目录Pod 删了数据就没了persistentVolumeClaim是持久卷适合数据库和有状态应用configMap和secret可以挂成文件或环境变量。2. Pod 生命周期从生到死的状态流转Pod 的 YAML 写好了接下来要搞清楚一个 Pod 从创建到销毁中间会经历哪些状态每个状态代表什么含义。这个问题看着基础但实际排查故障时90% 的问题都出在“状态不理解”上。我见过一些同事一看到 Pod 状态是CrashLoopBackOff就慌了不知道接下来该干什么。其实只要理解了 Pod 状态机的流转逻辑排查思路自然就有了。Pod 的整个生命周期可以总结成一句话从 Pending 开始经过 Running 到 Succeeded 或 Failed 结束。中间任何一步出问题都会卡在某个状态或者进入错误状态。下面我按状态逐个说顺便讲讲每个状态背后的排查思路。2.1 状态流转全景Pending、Running、Succeeded、Failed、Unknown先说 Pending。这个状态表示 Pod 已经被 API Server 接受了但还没有完成调度或者是镜像正在拉取。如果集群里没有足够的资源Pod 就会一直 Pending。资源不足的典型表现是节点 CPU 或内存不满足 requests调度器找不到合适节点。再看 Running。这个状态本身不代表容器 100% 正常只是说容器已经创建并开始运行。有些容器虽然 Running 但内部进程已经僵死这就需要靠探针来发现。这也是为什么我在前面强调探针配置必须到位。然后是 Succeeded 和 Failed。这两个状态通常出现在 Job 类型的 Pod 上。一个是容器正常退出、任务完成一个是容器非正常退出比如退出码非 0。对普通长期运行的 Pod 来说Succeeded 几乎不会出现因为容器一般不会主动退出。Unknown 是一个比较特殊的状态意思是 API Server 暂时联系不上节点上的 kubelet拿不到 Pod 的状态信息。常见原因是节点宕机或网络抖动。出现 Unknown 不代表 Pod 一定出问题了但需要关注节点的健康状态。我把这些状态的常用排查提示整理成了一张表状态含义常见原因第一反应Pending等待调度/镜像拉取资源不足、镜像不存在、节点亲和性不满足kubectl describe pod查看 EventsContainerCreating容器创建中镜像拉取慢、存储卷挂载失败、配置错误等待并查看 describeRunning容器已启动正常配合探针判断业务是否可用CrashLoopBackOff启动后反复崩溃启动命令错误、环境变量缺失、配置错误kubectl logs查看容器日志Succeeded正常退出一次性任务完成确认结果Failed非正常退出进程报错、退出码非 0查看日志并修复Unknown状态未知节点失联、kubelet 异常检查节点状态排查的时候我有一个自己的固定套路kubectl get pod先看状态kubectl describe pod看事件kubectl logs看日志。三步走完大部分问题都能定位。如果问题出在调度阶段describe 里会有 FailedScheduling 的记录会写出具体原因比如节点资源不足、端口冲突或 ImagePullBackOff 事件信息量比网上猜测要高得多。2.2 容器重启机制restartPolicy 怎么选Pod 是 K8s 里的最小调度单位但真正干活的是容器。容器挂了之后要不要重启、怎么重启由restartPolicy控制。它有三个取值Always、OnFailure、Never。Always 是最常用的适合持续对外服务的应用比如 Web 服务、API 网关。容器无论因为什么原因退出kubelet 都会重新拉起。OnFailure 表示只在容器异常退出退出码非 0时才重启正常退出不重启比较适合批处理任务。Never 就是退出后直接不重启这种用得少一般只在需要严格“run once”的场景下用。有一点需要注意虽然 restartPolicy 是 Pod 级别的字段但控制器类型的 Pod比如 Deployment 管理的 Pod默认会强制要求Always而且这个字段对系统行为有决定性影响——它直接决定了 kubelet 对容器退出事件的响应方式。如果你想用 Job 做一次性的任务restartPolicy 就必须写成Never或OnFailure不能是Always。这一点我在第一次写 CronJob 的时候踩过坑后面会专门说。另一个和重启相关的概念是“CrashLoopBackOff”。这个状态名的含义是容器启动后反复崩溃kubelet 按照指数退避策略重启退避时间从 10s 开始每次翻倍上限 5 分钟。看到这个状态别急着删除 Pod先查日志。如果是代码问题改了代码重新构建镜像才是正解。2.3 探针细节为什么明明 Running 却访问不了这个问题几乎每隔几天就会被问一次Pod 状态明明是 Running但通过 Service 访问时老是超时或不稳定。原因多半是 readinessProbe 出问题了。readinessProbe 决定“Pod 是否能被纳入 Service 的 Endpoints”。如果一个 Pod 没有通过就绪检查它虽然活着但不会接收流量。企业里最常见的配置错误是探针路径写错、端口写错、initialDelaySeconds 太短。比如你的应用启动需要 15 秒但你设了 3 秒开始探测探针连续失败几次之后Pod 就永远进不了 Ready 状态。还有一类问题更隐蔽探针检查的是一个进程内部状态如/healthz但外部依赖数据库、缓存没有就绪时接口会返回 503。这在滚动更新时会引发“新 Pod 一直没 Ready老 Pod 一直不缩容”的情况。我的建议是healthz 接口最好能反映应用的真实健康度至少要对当前运行所依赖的基础服务做一次连通性检查同时不要做得太复杂否则探针本身会变成性能瓶颈。livenessProbe 设不好也有风险。一个典型的反面教材是把超时时间设得比接口响应时间还短。Java 应用偶发 Full GC 时接口会卡几秒如果存活探针直接判定失败并重启容器反而引发“雪崩式重启”。所以我会把 startupProbe 专门留给启动慢的应用而 livenessProbe 的 failureThreshold 适当调大比如 5 次给程序留点自愈空间。提示探针不是配了就完事。每次发版后建议花几分钟看一眼 Pod 的 restart 次数和 readiness 通过率。如果 restart 次数持续增长说明探针或应用本身有问题早发现早解决。3. 控制器选型Deployment、StatefulSet、DaemonSet、Job 怎么挑单独创建一个 Pod 在企业里几乎是不可接受的原因很直白无人管理、不会自愈、无法扩容。控制器Controller就是用来解决这个问题的。它们负责维持 Pod 的期望数量处理更新、回滚、滚动发布等运维动作。控制器的种类不少但企业实战里常用的也就那么几个Deployment、StatefulSet、DaemonSet、Job/CronJob。很多人选型时拿不准主要是不清楚各自的适用边界。我自己的判断方法其实很简单先问三个问题——这个应用有状态吗它是不是每个节点都必须跑它是一次性任务还是长驻服务无状态服务用 Deployment。有状态服务特别是需要稳定网络标识、稳定存储的服务用 StatefulSet。每个节点都需要跑一个实例的比如日志采集器、节点监控组件用 DaemonSet。定时清理任务、离线数据处理任务用 CronJob 或 Job。3.1 Deployment无状态服务的默认解Deployment 是使用频率最高的控制器绝大多数 Web 应用、API 服务都跑在它下面。它做的事情很纯粹通过 ReplicaSet 维持 Pod 副本数支持滚动更新和一键回滚。Deployment 的 YAML 里有两个关键字段值得多说几句。spec.replicas是期望副本数spec.selector是它管理的 Pod 的标签选择器。注意 selector 一旦创建就不能改所以写之前一定要想清楚。selector.matchLabels里的标签必须与 Pod 模板template.metadata.labels保持一致否则 Deployment 会发现“没有 Pod 匹配我的选择器”表现就是不创建任何 Pod也不报错。Deployment 的滚动更新机制在企业实战里特别重要。默认的strategy.type是 RollingUpdate它有两个参数maxUnavailable和maxSurge。maxUnavailable 表示更新过程中最多允许几个 Pod 不可用默认 25%maxSurge 表示最多允许超出期望副本数几个 Pod默认也是 25%。这两个参数的组合直接决定发布时的流量变化形态。我举个例子。假设一个 Deployment 有 4 个副本默认策略下K8s 会先创建一个新的 ReplicaSet滚动替换旧的。发布过程中可能短暂出现 5 个 Pod41 surge也可能短暂只有 3 个 Pod 可用4-1 unavailable。这个流量波峰波谷在容量规划时必须考虑进去。如果业务上有严格的高可用要求可以把 maxSurge 调小但这样发布会变慢。如果对并发波动敏感把 maxUnavailable 调为 0压测一下发布耗时再上线。回滚也是一个高频操作。kubectl rollout undo deployment/xxx可以回退到上一个版本。但更可控的做法是用--to-revision版本号回退到指定版本。我在发布脚本里会把这一步写成固定的 rollback 流程防止误操作。3.2 StatefulSet有状态应用的正确打开方式StatefulSet 经常被拿来和 Deployment 对比。它最核心的差异是“稳定的网络标识”和“稳定的存储”。每个 Pod 的名字不再是随机后缀而是有序编号比如web-0、web-1、web-2。同时每个 Pod 可以绑定独立的持久卷Pod 重建后数据不丢。这个特性让 StatefulSet 成为数据库、缓存、消息队列等有状态服务的默认载体。比如部署一套 Redis Cluster 或一个分片的数据库实例用 StatefulSet 是最省心的方案因为节点间的发现机制可以依赖固定的 Pod 名称。不过 StatefulSet 有一个不能忽视的问题更新策略默认是按序更新RollingUpdate从序号最大的 Pod 开始一个一个更新前一个变成 Ready 之后才会继续下一个。这个设计是为了保证数据安全但也意味着更新过程很慢。如果我要批量更新时又不想重置集群可以用partition参数做金丝雀发布只更新部分副本。StatefulSet 的存储定义也比 Deployment 多一层volumeClaimTemplates。这个字段类似 PVC 模板StatefulSet 创建多少副本就会自动生成多少独立的 PVC。一个 3 副本的 StatefulSet配上volumeClaimTemplates后会自动创建>kubectl create namespace ns-project-x然后创建 Deployment。这是我平时用的一套通用模板适用无状态 Web 服务核心配置都标了注释apiVersion: apps/v1 kind: Deployment metadata: name: web-project-x namespace: ns-project-x labels: app: web-project-x spec: replicas: 3 selector: matchLabels: app: web-project-x strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0 template: metadata: labels: app: web-project-x spec: containers: - name: web image: registry.example.com/project-x/web:1.0.0 imagePullPolicy: IfNotPresent ports: - containerPort: 8080 resources: requests: cpu: 100m memory: 128Mi limits: cpu: 500m memory: 256Mi env: - name: TZ value: Asia/Shanghai - name: APP_CONFIG value: production readinessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 5 periodSeconds: 10 failureThreshold: 3 livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 15 periodSeconds: 20 failureThreshold: 5这份模板有几个我特意写成这样的设计考量简单解释一下。maxSurge: 1和maxUnavailable: 0意味着发布过程中最少保持 3 个 Pod 可用同时最多临时多出 1 个 Pod。这种策略适合有严格可用性要求的服务代价是发布速度稍慢。readinessProbe的 initialDelaySeconds 设成 5 秒因为我这个模拟服务的 Spring Boot 容器启动约 4-6 秒5 秒开始探测是安全的。liveness 的 initialDelaySeconds 设成 15 秒给应用充分的启动时间避免启动阶段被误杀。每个服务的启动时间不一样这个值要拿真实启动耗时来定不能拍脑袋。4.2 部署、验证与滚动更新操作实录清单文件保存为web.yaml然后依次执行kubectl apply -f web.yaml kubectl get deployment -n ns-project-x kubectl get pods -n ns-project-x -o wide kubectl get svc -n ns-project-x第一次部署后建议观察 Pod 状态是否到 Running 且 Ready 为 1/1。如果一直处于 ContainerCreating用 describe 看事件kubectl describe pod -n ns-project-x -l appweb-project-x常见的输出是拉取镜像卡住、调度失败或者探针检查失败事件里会有具体信息。比如节点磁盘不足、镜像不存在、端口被占用等等。根据事件内容逐步处理这一步是排查能力的分水岭能把 describe 用熟的人95% 的问题都能自己定位。接下来模拟一次版本更新。重新编辑 YAML 里的镜像版本把1.0.0改成1.1.0再 apply 一次kubectl apply -f web.yaml kubectl rollout status deployment/web-project-x -n ns-project-xrollout status 会实时输出滚动更新的进度直到全部新 Pod 就绪。如果你的服务流量波动较大可以边观察边看kubectl get pods -n ns-project-x -w这个命令可以实时观察 Pod 的变化过程你会看到旧的 Pod 一个一个被替换成新的。如果发布过程中发现问题立即回滚kubectl rollout undo deployment/web-project-x -n ns-project-x回滚后同样可以用 rollout status 确认恢复。从我的经验来看发布和回滚的演练动作每周最好做一次真正线上出问题时才能形成肌肉记忆。4.3 用 describe 和 events 定位问题的标准姿势排查问题的时候kubectl describe输出的信息量很大新手常不知道从哪里看起。我分享一个自己的“三栏定位法”。第一栏看 State 和 ReasonPod 当前处于什么状态为什么处于这个状态。第二栏看 Events 的最后几行注意事件的TypeWarning 级别的事件基本就是根因。第三栏看 Conditions确认 Pod 的初始化、就绪、容器启动等状态是否正常。真正到了执行阶段我会按下面这个顺序做kubectl get events -n ns-project-x --sort-by.lastTimestamp kubectl describe pod pod-name -n ns-project-x kubectl logs pod-name -n ns-project-x --tail100先说 events它按时间倒序显示集群中的事件。资源不足时事件里会反复出现 FailedScheduling镜像拉不到时会出现 Failed to pull image存储挂载失败时会有 FailedMount。这些事件会直接告诉你方向。再说 describe Pod 里的 Conditions正常情况下四项都是 TrueInitialized、ContainersReady、PodScheduled 和 Ready。任何一项不是 True说明问题出在对应阶段。最后用日志兜底如果容器已经跑过日志里的异常栈基本能定位到应用层问题。这套姿势的关键是顺序先外围事件、状态再内部日志不要一上来就翻日志有时候日志没有输出你反而会更迷茫。5. 常见故障与排查实录写到这里我把这些年踩过的、以及帮别人排查过的典型问题集中整理一下。这些问题几乎每个 K8s 集群都会遇到当成速查表存下来遇到类似的先对号入座能省不少时间。5.1 Pod 一直 Pending到底是谁的问题先说最常见的“Pod 一直 Pending”。这大概率是调度器找不到合适节点。我用一个完整案例说明排查思路。某业务发布时发现新扩容的 Pod 一直 Pendingdescribe 之后看到0/3 nodes are available: 1 Insufficient cpu, 2 Insufficient memory.这个事件。这意味着集群整体的资源不够了调度器在每个节点上都找不到满足 requests 的可用容量。这时候你有几个选择扩容节点或给节点打标签后再调度。检查现有 Pod 的 requests 是否设置过高有些团队没有资源规范每个 Pod 都抬很高的 requests集群可用容量被“预占”了。如果是临时高峰期直接调整 Deployment 的副本数或者缩容一些不重要的服务。另一个 Pending 的常见原因是节点亲和性nodeSelector或污点容忍度配置冲突。比如 Pod 要求调度到带disktypessd标签的节点但集群里根本没有这样的节点调度器就会一直失败。这类问题用 describe 看 Events 里的 FailedScheduling 原因通常都能看到具体限制条件一条一条对上就行。5.2 CrashLoopBackOff 的两种常见剧本第一种剧本容器启动后立刻退出退出码是 1。这种情况基本可以断定是应用本身的问题最直接的做法是kubectl logs看启动日志。我的经验里最常见的原因是环境变量缺失、数据库连不上、或者启动参数错误。第二种剧本相对隐蔽容器能启动但启动后一直处于“启动中-崩溃-重启”的循环退出码时 1 时而 137。137 是 SIGKILL 的信号码通常意味着容器内存超限被 kubelet 杀掉。如果 Pod 反复以 137 退出先去看 limits 和实际占用kubectl top pod可以查看实时用量。内存设置的 limits 一定要比实际业务峰值高一截否则你会经常在半夜收到“OOMKilled”的告警。处理 CrashLoopBackOff 还有个动作可以做把镜像里的 entrypoint 临时改成sleep 3600手动kubectl exec进去检查环境变量和配置。这是一种经典的“尸体解剖”排查手法能确认到底是应用配置问题还是环境问题。5.3 故障速查表一眼定位关键错误我把常见错误和对应的第一动作整理成了表格方便日常查阅。现象可能原因第一动作ImagePullBackOff镜像仓库认证失败、镜像不存在、仓库网络不通查看 describe 事件中的具体拉取报错本地手动 docker pull 验证CrashLoopBackOff应用启动失败、内存OOM、变量缺失查看容器日志、检查退出码、调整启动参数Pending 卡住资源不足、节点亲和性、污点冲突describe 看 FailedScheduling 事件Running 但访问失败readinessProbe 失败、Service selector 不匹配检查 Endpoints 与 Service selector、看探针日志容器反复重启livenessProbe 误杀调大 failureThreshold 或 initialDelaySeconds确认健康检查路径节点 NotReady节点负载高、kubelet 失联登录节点检查 kubelet 状态与磁盘水位这张表不追求覆盖所有情况但它能覆盖日常 80% 的问题。剩下 20% 的问题用三栏定位法总能找到头绪。6. 资源清单的进阶技巧与避坑指南这一节算是我个人经验沉淀的部分。如果你能把 YAML 写得既规范又省心日常维护成本会降很多。6.1 用 kubectl explain 摆脱死记硬背K8s 的字段体系庞大没有人能背下所有字段。kubectl explain是官方自带的一个“字段说明书”用法很简单kubectl explain deployment.spec kubectl explain pod.spec.containers.resources kubectl explain pod.spec.containers.readinessProbe它会输出字段的类型、说明和可选值。我在写不熟悉的资源时都是边写边用 explain 确认字段。如果想看某一个字段更详细的说明可以用--recursive参数把所有嵌套字段展开比如kubectl explain deployment.spec --recursive输出会非常长但用来对照检查字段拼写和层级关系会非常方便。6.2 用 dry-run 和 diff 避免误操作企业环境里最怕的就是手滑把生产环境资源改了。我会用--dry-run做预检kubectl diff做变更对比。kubectl apply --dry-runclient -f web.yaml kubectl diff -f web.yamldry-run 的 client 模式只做本地校验server 模式会真正发给 API Server 做准入检查但不落库。diff 命令则会把“当前线上实际配置”和“本次 YAML 想要达到的配置”之间的差异打出来。改动经 diff 确认无异常后再 apply是我在改生产环境清单时的固定流程。凡是跨过 diff 这一步直接 apply 的操作早晚要在某个凌晨付出代价。6.3 多环境差异化别把一套 YAML 模板用到底企业里通常有开发、测试、预发、生产多套环境。硬编码环境变量会把环境之间的差异写死导致一套 YAML 在不同环境无法通用。我建议把环境相关的信息抽离到 ConfigMap 和 Secret 里YAML 本身保持“环境无关”只保留镜像、标签和探针这些通用配置。实际操作中可以配套使用 Helm 这类模板化工具将不同环境的 values.yaml 单独维护。比如开发环境的副本数可能是 1生产是 5只需要在对应的 values 文件里改一下即可。没有引入 Helm 之前团队里全是复制粘贴改名字的 YAML 副本用模板化之后资源清单的维护量立刻降了一个量级而且减少了改错环境的概率。6.4 写清单的一个习惯代码化评审资源清单本质上是代码那就应该用代码的方式管理。我在团队里推过一个简单规矩所有 YAML 必须从 Git 仓库维护并通过 MR 评审合并禁止直接在生产服务器上编辑文件。每次变更都要在 MR 里附上“变更说明 kubectl diff 结果”让评审人可以直观看到改动内容。这套流程看似多了一步实际上救了无数次“半夜上线告警”的命。因为评审人往往能发现你没注意到的细节比如探针路径写错、资源 limits 填得离谱、或者 imagePullPolicy 设置成 Always 导致的发布性能问题。7. 结尾一次实战复盘与经验沉淀这篇写到这里内容已经不少了最后想以一个真实项目复盘来收尾也算是我个人完成这次“企业实战”主题的实践总结当然案例细节做了脱敏处理。当时某业务要从裸机容器化迁移到 Kubernetes我负责核心服务的容器化改造。第一版 YAML 几乎是从网上复制拼凑的副本数、探针、资源限制都没有系统规划。一次模拟压测中服务在发布高峰期出现了短暂不可用原因是 maxUnavailable 默认配置允许 25% 的副本同时被替换导致流量波动。那次事故之后我把资源清单全部推倒重写补齐了探针配置、resources 约束、滚动更新参数和告警规则重新做了三轮压测和故障演练才上线。上线后又遇到一个坑新版本镜像发布后readinessProbe 的 /healthz 接口突然没有纳入新的依赖检查导致 Service 流量打到尚未初始化完成的 Pod 上用户体感略有波动。最后通过给 healthz 增加依赖检查并把 initialDelaySeconds 调大才彻底解决。每一次故障复盘本质上都在加深你对资源清单、Pod 生命周期和控制器这三个主题的理解。Kubernetes 就这么大核心机制也不复杂但为什么有的人能写得一手好清单有的人天天在排查 CrashLoopBackOff差别就在于是否真正理解了“期望状态”和“控制器”这套思维方式——你越早掌握它投入产出的性价比越好。希望这篇实战总结能帮你少踩几个坑。
阅读完成 · 觉得有帮助？
