在云原生时代，Kubernetes（K8s）已经成为企业自动化运维的绝对基石。然而，许多刚接触 K8s 的同学，往往会陷入“命令记不住、清单不会写、控制器原理搞不懂”的泥潭中。

一个合格的集群管理员，不仅需要熟练掌握通过 kubectl 检查节点状态（如处理常见的 NotReady 或内存、磁盘压力）、过滤 Pod 标签等日常高频命令，更需要深刻理解 K8s 的内核设计——即“一切皆资源”的声明式 API 。

本文将基于一线生产实战经验，带你系统性梳理 K8s 的高频常用命令、资源清单定义（YAML 结构）、Pod 核心生命周期（三大探针与钩子机制），以及 Deployment、DaemonSet、Job 等核心控制器的调谐原理 。

无论你是为了准备面试，还是为了解决生产环境中的扩容与滚动更新难题，这篇干货都将是你的案头必备手册！

kubernetes常用命令

Master 主机检查节点信息

1. 查看节点基本状态（最基础）

这是检查节点是否正常的核心命令，能快速看到节点的就绪状态、角色、版本等信息：

kubectl get nodes

正常输出示例：

NAME     STATUS   ROLES           AGE   VERSION
k8s-01   Ready    control-plane   10d   v1.28.0
k8s-02   Ready    <none>          10d   v1.28.0
k8s-03   Ready    <none>          10d   v1.28.0

关键解读：

• STATUS 列显示 Ready：节点健康，可调度 Pod；
• STATUS 显示 NotReady：节点异常，无法调度 / 运行 Pod；
• STATUS 显示 SchedulingDisabled：节点被标记为不可调度（手动设置或异常）。

2. 查看节点详细状态（定位异常原因）

如果 kubectl get nodes 显示 NotReady，用这个命令查看具体报错：

# 查看单个节点详情（替换为你的节点名，如 k8s-02）
kubectl describe node k8s-02

# 也可以查看所有节点详情（输出较多，可配合 grep 过滤关键信息）
kubectl describe nodes | grep -A 10 "Conditions"

重点关注 Conditions 部分（正常状态示例）：

Conditions:
  Type                 Status  LastHeartbeatTime                 LastTransitionTime                Reason                       Message
  ----                 ------  -----------------                 ------------------                ------                       -------
  NetworkUnavailable   False   Tue Feb 18 10:00:00 2026         Tue Feb 18 10:00:00 2026          CalicoIsUp                   Calico is running on this node
  MemoryPressure       False   Tue Feb 19 18:00:00 2026         Tue Feb 18 09:50:00 2026          KubeletHasSufficientMemory   kubelet has sufficient memory available
  DiskPressure         False   Tue Feb 19 18:00:00 2026         Tue Feb 18 09:50:00 2026          KubeletHasNoDiskPressure     kubelet has no disk pressure
  PIDPressure          False   Tue Feb 19 18:00:00 2026         Tue Feb 18 09:50:00 2026          KubeletHasSufficientPID      kubelet has sufficient PID available
  Ready                True    Tue Feb 19 18:00:00 2026         Tue Feb 18 09:50:00 2026          KubeletReady                 kubelet is posting ready status

异常解读：

• Ready 为 False：看 Reason 和 Message，比如 KubeletNotReady（kubelet 未运行）、NetworkPluginNotReady（网络插件异常）；
• MemoryPressure/DiskPressure 为 True：节点内存 / 磁盘不足，会触发驱逐 Pod。

3. 检查节点上的核心组件状态

节点异常常因 kubelet、容器运行时（containerd/docker）、网络插件（calico/flannel）异常导致，在 Master 节点可通过 ssh 登录异常节点检查（或直接在节点上执行）：

# 1. 检查 kubelet 状态（核心，节点必须运行 kubelet）
ssh k8s-02 "systemctl status kubelet"

# 2. 检查 containerd 状态（容器运行时）
ssh k8s-02 "systemctl status containerd"

# 3. 查看 kubelet 日志（定位具体报错）
ssh k8s-02 "journalctl -u kubelet -f"

4. 检查节点资源使用情况

节点资源耗尽也会导致异常，可通过以下命令查看：

# 查看节点CPU、内存、磁盘使用（需要安装 metrics-server）
kubectl top nodes

# 示例输出
NAME     CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%   
k8s-01   123m         6%     1200Mi          30%       
k8s-02   89m          4%     980Mi           25%

二、常见异常及快速修复

异常现象	常见原因	修复方法
节点 NotReady	kubelet 未启动 / 异常	ssh 节点名 "systemctl restart kubelet"
NetworkPluginNotReady	网络插件（calico/flannel）异常	重启网络插件 Pod：kubectl restart pod -n kube-system calico-node
DiskPressure 为 True	节点磁盘满	登录节点清理磁盘（删除无用镜像、日志）
MemoryPressure 为 True	节点内存不足	扩容节点内存或驱逐占用高的 Pod

总结

1. 快速检查：先用 kubectl get nodes 看节点是否 Ready，这是最直观的状态判断；
2. 定位原因：节点异常时，用 kubectl describe node 节点名 查看 Conditions 字段，找到具体报错原因；
3. 深度排查：登录异常节点检查 kubelet、容器运行时状态，或查看 kubelet 日志；
4. 资源检查：用 kubectl top nodes 确认节点 CPU / 内存是否耗尽。

获取当前的资源，pod

kubectl get pod 
	-A,--all-namespaces 查看当前所有名称空间的资源
	-n  指定名称空间，默认值 default，kube-system 空间存放是当前组件资源
	--show-labels  查看当前的标签
	-l  筛选资源，key、key=value
	-o wide  详细信息包括 IP、分配的节点
	-w  监视，打印当前的资源对象的变化部分

进入 Pod 内部的容器执行命令

 kubectl exec -it podName -c cName -- command
	-c  可以省略，默认进入唯一的容器内部

查看资源的描述

 kubectl explain pod.spec

查看 pod 内部容器的 日志

 kubectl logs podName -c cName

查看资源对象的详细描述

 kubectl describe pod podName

删除资源对象

 kubectl delete kindName objName
	--all 删除当前所有的资源对象

kubectl delete pod test-registry
kubectl delete pod --all

查看serviceIP地址

kubectl get service

资源清单

什么是资源

k8s中所有的内容抽象为资源，资源实例化之后，叫做对象（类与对象，Class与Object）

资源清单的编写

[root@k8s-01 calico]# kubectl api-versions
admissionregistration.k8s.io/v1
apiextensions.k8s.io/v1
apiregistration.k8s.io/v1
apps/v1
authentication.k8s.io/v1
authorization.k8s.io/v1
autoscaling/v1
autoscaling/v2
batch/v1
certificates.k8s.io/v1
coordination.k8s.io/v1
crd.projectcalico.org/v1
discovery.k8s.io/v1
events.k8s.io/v1
flowcontrol.apiserver.k8s.io/v1beta2
flowcontrol.apiserver.k8s.io/v1beta3
networking.k8s.io/v1
node.k8s.io/v1
policy/v1
rbac.authorization.k8s.io/v1
scheduling.k8s.io/v1
storage.k8s.io/v1
storage.k8s.io/v1beta1
v1

版本：apiVersion

种类：kind

元数据：metadata 描述信息

期望：spec 声明式表达

Pod的生命周期

init 容器（初始化）与普通的容器非常像，除了如下两点:

• init 容器总是运行到成功完成为止
• 每个 init 容器都必须在下一个 init 容器启动之前成功完成

如果 Pod 的 Init 容器失败，Kubernetes 会不断地重启该 Pod，直到 Init 容器成功为止。然而，如果 Pod 对应的 restartPolicy为Never，它不会重新启动

InitC 与应用容器具备不同的镜像，可以把一些危险 的工具放置在 initc 中，进行使用

initc 多个之间是线性启动的，所以可以做一些延迟性的操作

initC 无法定义 readinessProbe，其它以外同应用容器定义无异

探针是由 kubelet 对容器执行的定期诊断。要执行诊断，kubelet 调用由容器实现的 Handler。有三种类型的处理程序:

• ExecAction：在容器内执行指定命令。如果命令退出时返回码为0则认为诊断成功
• TCPSocketAction：对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开，则诊断被认为是成功的
• HTTPGetAction：对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于 400，则诊断被认为是成功的

每次探测都将获得以下三种结果之一:

• 成功:容器通过了诊断。
• 失败:容器未通过诊断。
• 未知:诊断失败，因此不会采取任何行动

startupProbe:开始检测吗?

livenessProbe:还活着吗?

readinessProbe:准备提供服务了吗?

顺序是：

1. startupProbe（启动探针）最先执行
2. startupProbe 成功后，才开始执行 readinessProbe 与 livenessProbe
3. readinessProbe 决定是否加入 Service 流量
4. livenessProbe 决定是否需要重启容器

记住一句话：
启动探针负责“容器能否起来”，就绪探针负责“能不能接客”，存活探针负责“卡住了要不要杀掉”。

readinessProbe就绪探针

介绍:k8s通过添加就绪探针，解决尤其是在扩容时保证提供给用户的服务都是可用的。

如果pod内部的 C 不添加就绪探测，默认就绪，如果添加的就绪探测，只有就绪通过后

才标记修改为就绪状态。当前pod内的所有的 C 都就绪，才标记当前pod就绪

成功：将当前的 C 标记为就绪

失败：静默

未知：静默

选项说明

• initialDelaySeconds：容器启动后要等待多少秒后就探针开始工作，单位“秒”，默认是 0秒，最小值是0
• periodSeconds：执行探测的时间间隔(单位是秒)，默认为 10s，单位“秒”，最小值是 1
• timeoutSeconds：探针执行检测请求后，等待响应的超时时间，默认为 1s，单位“秒”，最小值是1
• successThreshold：探针检测失败后认为成功的最小连接成功次数，默认值为 1。必须为 1 才能激活和启动。最小值为1。
• failureThreshold：探测失败的重试次数，重试一定次数后将认为失败，默认值为 3，最小值为 1。

linenessProbe存活探针

介绍:k8s 通过添加存活探针，解决虽然活着但是已经死了的问题。

如果pod内部不指定存活探测，可能会发生容器运行但是无法提供服务的情况。

成功：静默

失败：根据重启策略进行重启操作

未知：静默

选项说明

• initialDelaySeconds：容器启动后要等待多少秒后就探针开始工作，单位“秒”，默认是 0秒，最小值是0

• periodSeconds：执行探测的时间间隔(单位是秒)，默认为 10s，单位“秒”，最小值是 1
• timeoutSeconds：探针执行检测请求后，等待响应的超时时间，默认为 1s，单位“秒”，最小值是 1
• successThreshold：探针检测失败后认为成功的最小连接成功次数，默认值为 1。必须为 1才能激活和启动。最小值为1。
• fureThreshold：探测失败的重试次数，重试一定次数后将认为失败，默认值为 3，最小值为 1。

startupProbe 启动探针

保障存活探针在执行的时候，不会因为时间设定问题，出现无限死亡或者延迟很长的情况

成功：开始允许存活探测 就绪探测开始执行

失败：静默，等待下一次

未知：静默

介绍：k8s在 1.16 版本后增加 startupProbe 探针，主要解决在复杂的程序中 readinessProbe、livenessProbe 探针无法更好的判断程序是否启动、是否存活。

选项说明

• initialDelaySeconds：容器启动后要等待多少秒后就探针开始工作，单位“秒”，默认是 0秒，最小值是0
• periodSeconds：执行探测的时间间隔(单位是秒)，默认为 10s，单位“秒”，最小值是 1
• timeoutSeconds：探针执行检测请求后，等待响应的超时时间，默认为 1s，单位“秒”，最小值是1
• successThreshold：探针检测失败后认为成功的最小连接成功次数，默认值为 1。必须为 1才能激活和启动。最小值为1。
• failureThreshold：探测失败的重试次数，重试一定次数后将认为失败，默认值为 3，最小值为 1。

钩子

Pod hook(钩子)是由 Kubernetes 管理的 kubelet 发起的，当容器中的进程启动前或者容器中的进程终止之前运行，这是包含在容器的生命周期之中。可以同时为 Pod 中的所有容器都配置 hook

Hook 的类型包括两种:

• exec:执行一段命令
• HTTP:发送 HTTP 请求

关于preStop的延伸话题

在 k8s 中，理想的状态是 pod 优雅释放，但是并不是每一个 Pod 都会这么顺利

• Pod 卡死，处理不了优雅退出的命令或者操作
• 优雅退出的逻辑有 BUG，陷入死循环
• 代码问题，导致执行的命令没有效果

对于以上问题，k8s 的 Pod 终止流程中还有一个“最多可以容忍的时间"，

即 grace period( 在pod.spec.terminationGracePeriodSeconds 字段定义)，这个值默认是 30 秒，

当我们执行 kubectldelete的时候，也可以通过 -grace-period 参数显示指定一个优雅退出时间来覆盖 Pod 中的配置，如果我们配置的 grace period 超过时间之后，k8s 就只能选择强制 kill Pod。

值得注意的是，这与preStopHook和 SIGTERM 信号并行发生。k8s不会等待 preStop Hook 完成。

如果你的应用程序完成关闭并在terminationGracePeriod 完成之前退出，k8s 会立即进入下一步

Pod 生命周期中的 initC、startupProbe、livenessProbe、readinessProbe、hook 都是可以并且存在的可以选择全部、部分或者完全不用

Pod是如何被调度运行的

控制器

在 Kubernetes 中运行了一系列控制器来确保集群的当前状态与期望状态保持一致，它们就是 Kubernetes集群内部的管理控制中心或者说是”中心大脑”。

例如，ReplicaSet 控制器负责维护集群中运行的 Pod数量;Node 控制器负责监控节点的状态，并在节点出现故障时，执行自动化修复流程，确保集群始终处于预期的工作状态。

控制器种类：

ReplicationController（RC）和ReplicaSet（RS）

Deployment

DaemonSet

StateFulSet

Job/CronJobHorizontal Pod Autoscaling

控制器

Pod 控制器

        守护进程类型

                RC 控制器

                        保障当前的Pod 数量与期望值一致

                RS 控制器

                        功能与RC 控制器类似，但是多了标签选择的运算方式

                Deployment

                        支持了声明式表达，支持滚动更新和回滚

                        原理：deployment > RS > pod

                DaemonSet

                        保障每个节点有且只有一个Pod 的运行，动态

        批处理任务类型

                job 控制器

                        保证批处理一个或多个成功为止

                CronJob

                        周期性的创建 Job，典型场景：数据库的周期性备份

Pod 控制器

ReplicationController(RC）和ReplicaSet

保持副本值与期望值一致

ReplicationController(RC)用来确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退出，会自动创建新的 Pod 来替代;而如果异常多出来的容器也会自动回收;

在新版本的 Kubernetes 中建议使用 ReplicaSet 来取代 ReplicationController 。Replicaset 跟ReplicationController 没有本质的不同，只是名字不一样，并且 ReplicaSet 支持集合式的 selector

删除Pod

在删除Pod的时候，使用kubectl create pod podname命令会自动重建

如果要删除不重建

法一：删除整个RC,连带着所有

kubectl delete rc <rc名称>

法二：缩容RC副本数到0，相当于删除所有Pod

kubectl scale rc <rc名称> --replicas=0

selector.matchExpressions 匹配运算符

rs 在标签选择器上，除了可以定义键值对的选择形式，还支持 matchExpressions 字段，可以提供多种

选择。

目前支持的操作包括：

In：label 的值在某个列表中 包含

NotIn：label 的值不在某个列表中 不包含

Exists：某个 label 存在 存在

DoesNotExist：某个 label 不存在 不存在

示例：

Deployment

Deployment 为 Pod 和 ReplicaSet 提供了一个声明式定义(declarative )方法，用来替代以前的 ReplicationController 来方便的管理应用。典型的应用场景包括:

• 定义 Deployment 来创建 Pod 和 ReplicaSet
• 滚动升级和回滚应用
• 扩容和缩容
• 暂停和继续 Deployment

selector.matchLabels 的标签集合必须是 template.metadata.labels 标签集合的子集或完全相同

selector ≤ template（子集关系 理论上可以）

场景 1：临时删除某个 Pod（会自动重建）

如果只是想删除单个 / 部分 Pod（测试重启、清理异常 Pod），直接删除 Pod 即可，ReplicaSet 会自动创建新 Pod 补充到 8 个：

# 1. 查看所有Pod名称
kubectl get pods -l app=myapp  # -l指定标签（对应Deployment的selector）

# 2. 删除指定Pod（替换为实际Pod名）
kubectl delete pod myapp-xxxx-xxxx

# 3. 验证：新Pod会自动创建，总副本数仍保持8个
kubectl get pods -l app=myapp

场景 2：永久减少副本数（不再自动重建）

如果想永久删除部分 Pod（比如把副本数从 8 减到 3），需要先缩容 Deployment，再删除多余 Pod（或由缩容自动删除）：

# 1. 缩容Deployment到目标副本数（比如3）
kubectl scale deployment myapp --replicas=3

# 2. 验证：多余的Pod会被自动删除，最终保留3个
kubectl get pods -l app=myapp

场景 3：彻底删除所有 Pod（并停止 Deployment）

如果想彻底删除所有 Pod 且不再自动重建，需要删除 Deployment（会同时删除 ReplicaSet 和所有 Pod）：

# 删除Deployment（所有关联的Pod和ReplicaSet都会被删除）
kubectl delete deployment myapp

# 验证：Pod和Deployment都被清理
kubectl get pods,deployment

关键说明

• 直接删 Pod 会重建：因为 Deployment 的 ReplicaSet 会保证副本数 = 8，所以单独删 Pod 只是 “重启” 效果；
• 缩容才会永久减少：必须通过kubectl scale修改副本数，才能让多余 Pod 被永久删除；
• 删除 Deployment 才会彻底清理：适合不再需要该应用的场景。

Deployment滚动更新。当 Deployment 升级镜像版本时，会创建一个新的 RS，同时逐渐缩减旧 RS（RS wangyanglinux/myapp:v1.0）的 Pod 数量。

过程中新旧 Pod 会同时存在，新 RS 的 Pod 逐步增加、旧 RS 的 Pod 逐步减少，最终旧 RS 被完全替换，实现 “滚动式” 的版本迭代，保证服务不中断

kubectl set image deployment/nginx-deployment 
                            nginx-deployment-container=wangyang/myappv2.0

声明式和命令式

命令式是动作，声明式是结果

kubectl diff -f yaml文件名使用diff这个选项，查看资源清单内容有没有改变，进行对比

替换方式：

kubectl replace：使用新的配置完全替换掉现有资源的配置。意味着新的配置将覆盖现有资源的所有字段和属性。包括未指定的字段，会导致整个资源的替换

kubectl apply：使用新的配置部分地更新现有资源的配置。根据提供的配置文件或参数，只更新于新配置中不同的部分，不会覆盖所有的资源配置

字段级别的更新

kubectl replace：由于的完全替换，所以会覆盖所有字段和属性，无论是否在新配置中指定

kubectl apply：只更新于新配置中不同的字段和属性，保留未指定的字段不受影响

与其他配置的影响

kubectl replace：不考虑其他资源配置的状态，直接替换资源的配置

kubectl apply：可以使用-f 或-k 参数，从文件或目录中读取多个资源配置，并根据当前集群的资源状态进行更新

kubectl create 、apply 、replace对比

create ：创建资源对象

        -f 通过基于文件的创建，但是如果此文件描述的对象存在，

        那么那怕文件描述的信息发生了改变，再次提交时也不会应用

apply：创建资源对象、修改资源对象

        -f 基于文件创建，如果目标对象与文件本身发生改变，

        那么会根据文件的指定一一修改目标对象的属性（部分更新）

replace ：创建资源对象、修改资源对象

        -f 基于文件创建，如果目标对象与文件本身发生改变，

        那么会重建此对象（替换）

项目完整流程

产品 > 项目经理 > 开发 > 测试 > 运维

提出需求 评估 前端 功能性 上线

后端 安全性

滚动更新（金丝雀发布）

先配置不中断的更新策略 → 触发金丝雀发布（验证新 Pod） → 全量更新 → 支持状态查看、版本回滚，确保发布过程可观测、可回退。

第一部分：配置滚动更新策略 + 触发金丝雀发布

# 1. 配置Deployment的滚动更新策略
kubectl patch deployment nginx-deployment -p \
'{"spec":{"strategy":{"rollingUpdate":{"maxSurge":1,"maxUnavailable":0}}}}'

作用：修改 Deployment 的滚动更新规则

• maxSurge:1：更新时最多额外创建 1 个 Pod（避免资源过载）
• maxUnavailable:0：更新过程中不可用的 Pod 数为 0（保证服务不中断）

# 2. 更新Pod镜像 + 暂停滚动更新（触发金丝雀发布）
kubectl patch deployment nginx-deployment --patch '{"spec": {"template": {"spec": {"containers": [{"name": "nginx-deployment-container","image":"nginx:v2.0"}]}}}}' \
&& kubectl rollout pause deploy nginx-deployment

作用：

• ① 通过patch将 Pod 镜像更新为wangyanglinux/myapp:v2.0
• ② 立即执行rollout pause暂停更新，此时仅会创建1 个新镜像的 Pod（金丝雀 Pod），其余 Pod 保持旧版本
• 场景：金丝雀发布（先验证少量新 Pod，再全量更新）

第二部分：发布状态查看、版本回滚、操作控制

# 1. 查看Deployment的更新状态 + 检查执行结果
kubectl rollout status deployments nginx-deployment 
echo $?

作用：

• ① rollout status：实时查看更新进度（显示 “successfully rolled out” 表示完成）
• ② echo $?：输出命令执行结果（0表示成功，非0表示失败）

# 2. 查看Deployment的版本历史
kubectl rollout history deployment/nginx-deployment# 2. 查看Deployment的版本历史
kubectl rollout history deployment/nginx-deployment

作用：列出 Deployment 的所有更新版本（包含版本号、更新时间、配置变更），用于后续回滚

# 3. 回滚到指定版本
kubectl rollout undo deployment/nginx-deployment  --to-revision=2

• 作用：将 Deployment 回滚到版本 2（需先通过rollout history确认版本号）
• 场景：新镜像验证失败时，快速回退到旧版本

# 4. 暂停Deployment的滚动更新
kubectl rollout pause deployment/nginx-deployment

DaemonSet

生成模版控制器资源清单

kubectl create deployment myapp --image=nginx --dry-run -o yaml > delpoyment.yaml.tmp

job 控制器

修改版本号四种方式

1. 打补丁（kubectl patch）—— 适合批量 / 自动化操作

这是通过 JSON/YAML 补丁文件修改镜像版本的方式，适合脚本化、自动化场景，或批量修改多个配置时使用。

操作示例（修改 nginx 版本为 1.25）：

# 方式1：直接执行命令（JSON格式补丁）
kubectl patch deployment myapp -p '{"spec":{"template":{"spec":{"containers":[{"name":"nginx","image":"nginx:1.25"}]}}}}'

# 方式2：通过补丁文件（适合复杂修改）
# 1. 创建patch文件 patch.yaml
cat > patch.yaml << EOF
spec:
  template:
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
EOF

# 2. 应用补丁
kubectl patch deployment myapp --patch-file patch.yaml

特点：

• 精准修改指定字段，不影响其他配置；
• 可编写脚本批量执行，适合 CI/CD 自动化；
• 需要准确知道字段层级（如spec.template.spec.containers）。

2. set image —— 最快捷的镜像版本修改方式

这是 K8s 提供的专门用于修改容器镜像的快捷命令，无需记忆复杂的字段层级，是日常手动修改的首选。

操作示例：

# 基本用法：kubectl set image 资源类型/资源名 容器名=镜像:版本
kubectl set image deployment/myapp nginx=nginx:1.25

# 验证修改结果
kubectl rollout status deployment/myapp

特点：

• 命令简洁，无需写 YAML/JSON，上手成本最低；
• 仅针对镜像字段修改，专注性强；
• 支持批量修改多个容器（如kubectl set image deployment/myapp nginx=nginx:1.25 redis=redis:7）。

3. 修改资源清单（kubectl apply）—— 最规范的版本管理方式

先修改本地的 Deployment YAML 文件，再通过kubectl apply重新应用，适合有版本控制（如 Git）的场景，是生产环境推荐的方式。

操作示例：

# 1. 先获取当前Deployment的YAML文件（可选，若已有本地文件可直接编辑）
kubectl get deployment myapp -o yaml > myapp-deployment.yaml

# 2. 编辑YAML文件，修改image字段为nginx:1.25
vi myapp-deployment.yaml
# 找到containers下的image字段，改为：
# image: nginx:1.25

# 3. 重新应用配置
kubectl apply -f myapp-deployment.yaml

特点：

• 配置文件可纳入版本控制（Git），便于追溯和回滚；
• 适合生产环境，符合 “声明式 API” 的最佳实践；
• 修改后可统一审核、测试配置文件，更规范。

4. edit 修改（kubectl edit）—— 临时快速修改

直接在线编辑 Deployment 的配置，适合临时修改、快速验证场景，无需本地文件。

操作示例：

# 编辑Deployment配置（默认用vi编辑器打开）
kubectl edit deployment myapp

# 在编辑器中找到以下内容，修改image字段：
spec:
  template:
    spec:
      containers:
      - name: nginx
        image: nginx:1.25  # 把版本改为1.25

# 保存退出（vi编辑器：按Esc，输入:wq回车）

特点：

• 无需本地文件，直接在线修改，适合临时调整；
• 编辑器会自动校验语法，错误会提示无法保存；
• 不适合复杂修改或需要留存配置的场景（无文件记录）。

四种方式对比与选型建议

方式	优点	缺点	适用场景
patch	精准、可自动化	需记忆字段层级	脚本 / CI/CD 自动化、批量修改
set image	最快捷、无需记字段	仅能改镜像	日常手动快速修改
修改资源清单	规范、可版本控制	需维护本地文件	生产环境、需追溯配置
edit	临时、无需本地文件	无配置记录、不适合复杂修改	临时验证、快速调整

总结

1. 日常手动修改首选：kubectl set image（最简单）；
2. 生产环境规范操作：修改资源清单 + kubectl apply（可版本控制）；
3. 自动化 / 批量修改：kubectl patch（适合脚本）；
4. 临时快速验证：kubectl edit（在线修改，无文件）。

让我们用一张简短的清单来复盘今天的内容，建议收藏以备不时之需：

• 节点故障排查：先 get nodes 看状态，发现 NotReady 立即 describe node 盯紧 Conditions。

• Pod 标签过滤：善用 -l 参数（如 kubectl get pods -l app=nginx），在多服务的集群中快速定位。

• 健康检查三剑客：startupProbe（能不能起来）$\rightarrow$ livenessProbe（活不活）$\rightarrow$ readinessProbe（能不能接客），顺序与分工明确，切忌混淆。

• 核心控制器：无状态服务找 Deployment，每台机器搞一个找 DaemonSet，一次性任务找 Job。

Kubernetes 的学习曲线虽然陡峭，但只要抓住了“声明式 API”和“控制循环（Controller）”这两个核心灵魂，剩下的无非是命令的熟练度和 YAML 字段的累积。希望这篇高频命令与核心概念的拆解，能成为你日常搬砖、排查故障时的得力助手。

感谢阅读！如果你觉得这篇文章还不错，请把它分享给身边正在被 K8s 折磨的同事吧。我们下期再见！