说到 kubectl 命令大全，我先说个现象：这些年负责过几套 Kubernetes 集群的日常运维，发现真正卡住新人的往往不是抽象的网络模型，也不是复杂的调度算法，而是命令行工具本身。Kubernetes 的玩法是声明式，你用 YAML 描述期望状态，控制面负责把实际状态往期望状态收敛，而 kubectl 就是你和 API Server 之间那条最快的路。比起 Web 控制台，kubectl 在任何环境都能用，脚本自动化、CI/CD 流水线、故障排查都绕不开它。这篇文章我不打算把命令一条条背给你听，而是按照真实干活时的需求重新梳理，配合参数解析、输出样例和踩过的一些坑，让刚开始接触或已经用了很久的同学都能找到自己需要的那部分。
1. 为什么要系统整理 kubectl 命令体系
1.1 命令行工具在 Kubernetes 日常运维中的位置
很多人喜欢用 Dashboard 或各种图形化管理界面，但在生产环境里，图形界面往往不是第一选择。Dashboard 需要单独部署，权限控制又是一个大麻烦；而且切换到另一个集群、另一个云厂商时，界面差异很大，换一套环境就要重新学一遍。kubectl 就没有这个问题，它是 API Server 的标准客户端，只要 kubeconfig 指向正确的集群地址和证书，你在任何 Linux、macOS 甚至 Windows 上都能执行几乎一样的操作。
更深一层的原因是，Kubernetes 本身就是一个 RESTful API 服务。kubectl 里的绝大多数命令，本质上是对 API 的封装。比如kubectl get pods底层是在请求列表接口，kubectl apply -f xxx.yaml是把 YAML 转换成 PATCH 或 POST 请求。理解这一点后，遇到404 Not Found或403 Forbidden时就不会慌：前者多半是资源类型或 API 版本写错，后者多半是 RBAC 权限没给够。这也是为什么命令掌握得越熟练，排障效率越高。
1.2 命令体系的基本分类与学习路径
kubectl 命令表面上看非常多，但如果按生命周期来分，其实就五类：查询、创建更新、运维维护、排障调试、集群权限管理。下面这个表格可以作为速查参考：
| 分类 | 常用命令 | 典型场景 |
|---|---|---|
| 查看与检索 | get、describe、logs、top、events | 查看资源状态、容器日志、节点性能 |
| 资源定义与生成 | create、run、expose、apply、patch、edit | 创建 Deployment、Service、ConfigMap 等对象 |
| 发布与维护 | scale、rollout、set、autoscale | 扩缩容、滚动更新、回滚、配置修改 |
| 节点与调度维护 | cordon、uncordon、drain、taint | 节点维护、Pod 迁移、污点管理 |
| 排障与调试 | exec、cp、port-forward、attach、debug | 进入容器排障、端口转发、临时调试 |
| 集群与权限 | config、auth、certificate、cluster-info | 切换上下文、权限检查、CSR 审批 |
学习路径上，我的建议是不要试图背命令，而是先熟练get，再上手describe和logs，这三个就能解决六成日常查看问题；然后学会用apply配合--dry-run生成 YAML，把变更固化到文件；最后排障类命令按需翻，用多了自然记住。真正需要持续积累的不是命令拼写，而是字段含义和资源对象之间的关系。
2. 查看类命令的实战细节：get、describe、logs 的隐藏技巧
2.1 get 的进阶用法：从默认输出到自定义字段
kubectl get pods几乎每个 Kubernetes 用户都敲过，但默认输出只显示几个固定的字段，遇到复杂排查时远远不够用。我先把最常用的一组参数列出来：
| 参数 | 作用 | 示例 |
|---|---|---|
-o wide | 展示节点 IP、Pod IP、所在节点等扩展信息 | kubectl get pods -o wide |
-o yaml | 输出完整对象定义 | kubectl get pod my-pod -o yaml |
-o json | 输出 JSON 格式完整对象 | kubectl get pod my-pod -o json |
-o custom-columns | 自定义列，适合提取关键字段 | kubectl get pods -o custom-columns=NAME:.metadata.name,NODE:.spec.nodeName |
-o jsonpath | 用 JSONPath 提取某个字段 | kubectl get pod my-pod -o jsonpath='{.status.podIP}' |
-l | 标签选择器筛选 | kubectl get pods -l app=nginx,env=prod |
--field-selector | 按对象字段筛选 | kubectl get pods --field-selector=status.phase=Running |
-A | 查看所有命名空间 | kubectl get pods -A |
-w | 实时监听资源变化 | kubectl get pods -w |
这里有几个容易踩的坑。第一，脚本里解析输出时，绝对不要用默认表格格式，因为默认输出随时可能新增或调整列；正确做法是用-o json配合jq，或者用 custom-columns 提取。比如我想看所有 Pod 的名称和镜像，可以这样写：
kubectl get pods -o custom-columns=NAME:.metadata.name,IMAGE:.spec.containers[*].image如果只需要某个 Pod 的 IP，用 jsonpath 更直接：
kubectl get pod my-nginx-xxxx -o jsonpath='{.status.podIP}'第二，kubectl get all -n demo看起来很省事，但从名字里的 all 并不能代表所有资源，实际上它通常只包含 pod、service、deployment、replicaset 等常见工作负载资源，像 events、ingress、pvc 这些都不在里面。想查全量资源类型，建议用kubectl api-resources先看清单，再配合kubectl get一个一个查。
第三，--field-selector和-l是两种完全不同的筛选方式。标签选择器针对.metadata.labels，字段选择器针对对象本身的字段，比如status.phase、metadata.name，不要混用。
2.2 describe 和 logs 在排障中的正确使用姿势
kubectl describe不是get的替代，它展示的是资源的详细画像：标签、注解、状态条件、容器列表、卷挂载、事件记录等。尤其是事件记录，Pod 为什么 Pending、为什么反复重启、镜像为什么拉取失败，大多数答案都在describe的 Events 部分里。
用describe查事件时，有个细节要记住：事件是按时间逆序排列的，最新的在最上面。如果你发现 Pod 处于 CrashLoopBackOff，第一件事就是执行：
kubectl describe pod my-pod -n demo然后重点看最后一段 Events，通常会有Failed to pull image、Back-off restarting failed container、Liveness probe failed这类关键信息。如果事件被刷掉了，再配合kubectl get events -n demo --sort-by=.lastTimestamp按时间正序看完整时间线。
logs方面，我最常用的参数是-f、--tail、--previous和-l。-f等同于 tail -f，--tail=200控制只显示末尾 200 行，避免在日志量大的容器里刷屏。排查容器崩溃时，--previous几乎是必备：它读取的是上一次容器实例的日志，比如容器因为启动失败不断重启，当前实例日志空空如也，但上一次实例里很可能已经打出了报错堆栈。示例：
kubectl logs my-pod -c nginx --previous --tail=50多容器 Pod 必须在 logs 命令里指定-c，否则 kubectl 会提示你选择容器。如果日志量特别大，还可以加--timestamps显示时间戳，方便和事件时间对上。
2.3 快速定位问题的三个组合技巧
单个命令看状态是零散的，真正高效的是组合使用。我习惯的排查流程是：
第一步，全局扫一遍，找出所有异常状态：
kubectl get pods -A | grep -v Running注意这里会包含已经完成的 Job 容器和 Evicted 的 Pod，但没关系，先缩小范围。
第二步，对异常对象执行 describe，看事件和状态条件：
kubectl describe pod my-pod -n demo | tail -40第三步，拉日志，根据事件里的线索看容器实际输出：
kubectl logs my-pod -n demo --previous --tail=100这套流程走完，大部分问题都能定位到原因，比如镜像拉取失败、探针失败、资源不足、启动命令写错。如果还没有结论，再看节点状态和kubectl get events -n demo --sort-by=.lastTimestamp，事件记录通常能给出更完整的上下文。
3. 资源创建与更新：用命令生成 YAML，再用 apply 落地
3.1 dry-run 和 -o yaml：不落地的“预演”命令
很多新手喜欢直接写 YAML，但字段记不全时经常犯语法错误。其实 kubectl 给你提供了一套“命令生成 YAML”的方法，核心就两个参数组合：--dry-run=client -o yaml。
举个例子，我想创建一个 Nginx Deployment，不想手写 YAML，可以这样：
kubectl create deployment my-nginx --image=nginx --replicas=3 --dry-run=client -o yaml执行后不会真的创建资源，而是把标准 YAML 输出到屏幕。你可以重定向到文件，再手动修改：
kubectl create deployment my-nginx --image=nginx --replicas=3 --dry-run=client -o yaml > nginx-deploy.yaml这个技巧对 ConfigMap、Secret、Service 同样适用。比如快速生成一个 ConfigMap 的 YAML：
kubectl create configmap app-config --from-literal=APP_ENV=prod --from-file=app.properties --dry-run=client -o yaml--dry-run有两种模式。client模式在本地完成生成，不请求 API Server；server模式会把对象发给 API Server 做准入校验，但不持久化。如果你想验证某个 YAML 能否通过集群里的校验 Webhook，就用：
kubectl apply --dry-run=server -f manifest.yaml这在生产发布前非常有用，相当于给配置变更加了一道检查闸门。注意client模式不会经过服务端校验，有些字段写错不一定能在本地发现。
3.2 create、run、expose、set 命令的常用姿势
kubectl create系列适合快速创建独立资源，比如命名空间、ConfigMap、Secret、Job、CronJob。下面是我常用的几个：
kubectl create namespace dev kubectl create configmap nginx-conf --from-file=conf/nginx.conf kubectl create secret generic db-secret --from-literal=password=xxx kubectl create secret tls tls-secret --cert=tls.crt --key=tls.key kubectl create job pi --image=perl:5.34 -- perl -Mbignum=bpi -wle 'print bpi(2000)' kubectl create cronjob scrape --image=busybox --schedule="*/5 * * * *" -- echo hellokubectl run命令值得单独说一句，因为不同版本的行为差异很大。在较新的 kubectl 版本里，kubectl run nginx --image=nginx直接创建的是裸 Pod；而老版本默认会创建 Deployment。想要一个稳定的工作负载控制器，请直接使用kubectl create deployment。如果只是临时跑一个调试容器，可以这样：
kubectl run debug -it --image=busybox --restart=Never -- /bin/sh--restart=Never在这里保证创建的是裸 Pod 而不是其他地方的管理控制器，退出后不会反复重启。
把工作负载暴露成 Service 用expose很方便：
kubectl expose deployment my-nginx --port=80 --target-port=8080 --type=NodePort --name=my-nginx-svc这里--port是 Service 的端口，--target-port是容器监听端口。如果不指定--target-port，默认等于--port，很多人的服务起不来就是因为 target-port 写错。
kubectl set image是修改镜像最直接的方式：
kubectl set image deployment/my-nginx nginx=nginx:1.25如果有多个容器，用逗号分隔：容器名=镜像,容器名2=镜像2。旧版本支持--record把变更原因写进 Annotation，新版本推荐用kubectl annotate deployment/my-nginx kubernetes.io/change-cause="升级到1.25"来记录，这样rollout history里能看到每次变更的原因。
3.3 apply vs create：为什么生产环境推荐 apply
简单来说，create是命令式的“新建”，如果资源已经存在会直接报错；apply是声明式的“确保最终状态一致”，不管资源是否存在，都会把当前声明应用到集群里。生产环境里强烈建议用apply，因为它背后有一套三方合并补丁机制。
当你第一次执行kubectl apply -f file.yaml时，kubectl 会把这份配置内容写入对象的kubectl.kubernetes.io/last-applied-configuration注解。之后再次 apply 时，控制器会对比三个版本：上次提交的配置、当前集群里的实际对象、以及新提交的配置，最终计算出需要变动的字段。这意味着你可以在 YAML 里删除某个字段，apply 之后集群里的该字段也会被删除。而create或replace不具备这种“按配置收敛”的能力，容易把其他系统维护的字段覆盖掉。
日常使用中还有几个细节要注意。第一，同一个资源不要混用create和apply，因为首次create创建的对象没有last-applied-configuration注解，之后apply管理时三方合并会缺少基准，删除字段的行为很不可控。第二，apply 的-f参数可以指向文件、目录，甚至 URL，配合 Kustomize 时用-k参数：
kubectl apply -k ./app/overlays/prod这也是 GitOps 流水线里的标准动作。第三，执行 apply 之前最好先跑一次--dry-run=server，借助集群的准入校验提前发现问题，而不是直接改线上对象。
4. 运维维护类命令：扩缩容、滚动更新、调度与存储
4.1 工作负载维护：scale、rollout、autoscale
手动扩容缩容用scale：
kubectl scale deployment my-nginx --replicas=5这个命令适合临时调整副本数。需要注意的是，如果集群里同时配置了 HPA，HPA 会根据指标自动调整副本数，这时手动 scale 很可能被 HPA 覆盖回去。遇到这种“明明改了副本数又变回去”的情况，先检查有没有 HPA 在管这个 Deployment。
滚动更新和回滚主要靠rollout。完整流程通常是这样的：
- 更新镜像：
kubectl set image deployment/my-nginx nginx=nginx:1.25- 等待滚动完成：
kubectl rollout status deployment/my-nginx --timeout=120s- 查看历史版本：
kubectl rollout history deployment/my-nginx- 如果新版本出问题，回滚到指定版本：
kubectl rollout undo deployment/my-nginx --to-revision=2rollout restart是另一个被低估的命令。它不会改镜像或配置，只是给 Pod 模板加上一个restartedAt注解，触发一次滚动重启。最常见的应用场景是 ConfigMap 或 Secret 更新后，Pod 不会自动感知，需要手动重启：
kubectl rollout restart deployment/my-nginxHPA 的创建用autoscale：
kubectl autoscale deployment my-nginx --min=2 --max=10 --cpu-percent=80这里有个关键前提：Pod 模板里必须定义了resources.requests.cpu，否则 HPA 无法计算 CPU 使用率。而且 HPA 计算 CPU 使用率时，分母是 Pod 的 request 值，不是节点的总 CPU。明白了这一点，就不会困惑“节点明明很空闲，为什么 HPA 还在扩容”。
4.2 调度与维护节点：cordon、drain、taint
节点需要维护时，第一件事是把节点标记为不可调度，也就是 cordon：
kubectl cordon node-1cordon 只会阻止新的 Pod 调度到这个节点，已经运行的 Pod 不受影响。如果还要把节点上的 Pod 迁移走，就需要 drain：
kubectl drain node-1 --ignore-daemonsets --delete-emptydir-data两个参数很重要。--ignore-daemonsets是必须的，因为每个节点上通常都有 DaemonSet 类型的组件，如果不去掉这个限制，drain 会一直卡在那里。--delete-emptydir-data用于清理使用 emptyDir 卷的 Pod，因为 emptyDir 是临时数据，节点下线后没有保留价值。
如果节点上有裸 Pod，也就是没有被 Deployment、StatefulSet 等控制器管理的 Pod，drain 会报错拒绝执行，这时需要根据实际情况加--force。我建议先检查这些裸 Pod 是否重要，而不是直接强杀。维护结束后记得恢复调度：
kubectl uncordon node-1这个命令太容易忘了，尤其是操作完就去忙别的事。后果就是不定期发现部分节点一直不接收新 Pod，新扩容的 Pod 卡在 Pending，回头一看才发现节点还挂着 SchedulingDisabled。
污点（Taint）和容忍度（Toleration）是调度控制的另一套机制。给节点打污点：
kubectl taint nodes node-1 dedicated=special:NoSchedule去掉污点：
kubectl taint nodes node-1 dedicated=special:NoSchedule-污点的三种效果要搞清楚。NoSchedule表示不调度新 Pod，已有 Pod 继续运行；PreferNoSchedule表示尽量不调度；NoExecute最严厉，不仅阻止新调度，已有且没有对应容忍度的 Pod 还会被驱逐。生产环境里通常在专用节点上打NoExecute污点，然后让关键业务通过 Toleration 调度上去，实现物理隔离。
4.3 存储、配置与密文操作
存储这块最常用的是看 PVC 状态：
kubectl get pvc -n demo kubectl describe pvc>kubectl create configmap app-config --from-literal=APP_ENV=prod --from-file=app.properties kubectl create secret generic app-secret --from-literal=password=xxx查看 Secret 里的某个值时，可以用 jsonpath 加 base64 解码：
kubectl get secret app-secret -o jsonpath='{.data.password}' | base64 -d但要记住，Secret 只是做了 Base64 编码，不是加密。不要在生产环境里用明文 Secret 管理真正的敏感信息，更不要把这个命令输出到 shell 历史里反复拷贝。
更新 ConfigMap 或 Secret 后，引用了它们的 Deployment 不会自动滚动。这是 Kubernetes 里最经典的坑之一，正确做法是：
kubectl rollout restart deployment/my-app如果 ConfigMap 是通过 volume 挂载进去的，kubelet 会周期性同步文件内容，但subPath挂载和 env 方式不会热更新，稳妥起见统一用 rollout restart。
4.4 状态与资源查看的辅助命令
除了前面这些，还有一组不算起眼但是高频使用的命令。查看节点和 Pod 的实际资源使用率：
kubectl top node kubectl top pod -n demo不过这个命令依赖集群里部署了 Metrics Server，没有装的话会直接报Metrics API not available，看到这个报错不要以为是集群坏了。
查看客户端和服务端版本：
kubectl version --client kubectl version -o json版本不一致时，尤其是客户端比服务端新很多，某些 API 兼容性会出问题。
查看集群支持哪些资源类型：
kubectl api-resources带--namespaced=true只看命名空间级资源，配合自定义 CRD 排查时很实用。
遇到不熟悉的字段，用kubectl explain：
kubectl explain deployment.spec.template.spec.containers.resources这比翻阅网页文档快得多，命令行直接给你结构化字段说明，还能用--recursive展开所有嵌套字段。
5. 故障排查与调试指令：exec、cp、port-forward 和事件流
5.1 进入容器排障与文件拷贝
进入容器是排障的常规操作：
kubectl exec -it my-pod -n demo -- /bin/sh多容器 Pod 必须加-c指定容器名，否则会报错。如果容器没有 shell，也可以直接执行单条命令：
kubectl exec my-pod -- ls /var/log文件拷贝用kubectl cp，语法类似 scp：
kubectl cp my-pod:/etc/nginx/nginx.conf ./nginx.conf kubectl cp ./nginx.conf my-pod:/etc/nginx/nginx.conf这个命令底层依赖容器里的tar命令，像 distroless 这类精简镜像没有 tar，拷贝会直接失败。遇到这种情况，要么换一个有 tar 的调试镜像，要么通过kubectl exec配合重定向手工传输。
Pod 处于 CrashLoopBackOff 时，exec 通常进不去，因为容器没有持续运行。以前只能干瞪眼等它启动，再用--previous看旧日志。现在 Kubernetes 提供了临时容器机制，用kubectl debug可以把调试容器注入到目标 Pod，比如：
kubectl debug pod/my-pod -it --image=busybox --target=nginx -- /bin/sh这个功能非常实用，相当于给运行中的 Pod 临时加了一个伴生容器，不会影响原有容器的启动状态。如果集群版本太旧不支持，备选方案是kubectl run debug -it --image=busybox --restart=Never --rm -- /bin/sh，然后用网络地址去探测目标服务。
5.2 端口转发让本地调试连上集群服务
本地想直接访问集群里的服务，port-forward是最快的办法：
kubectl port-forward svc/my-service 8080:80参数里的8080:80是“本地端口:Service 端口”。连 Service 时，kubectl 会自动挑一个后端 Pod；如果希望固定到某个 Pod，也可以直接转发 Pod：
kubectl port-forward pod/my-pod-xxxx 8080:80这个命令特别适合调试数据库、Redis、Elasticsearch 这类没有对外暴露的组件。比如本地连集群里的 PostgreSQL：
kubectl port-forward svc/postgres 5432:5432然后本地客户端直接连localhost:5432就能用。
有几个细节要注意。第一，port-forward 默认绑定127.0.0.1，如果想让局域网里别的机器访问，可以加--address 0.0.0.0，但这会暴露端口，使用时要谨慎。第二，如果 Service 的 Endpoints 是空的，也就是 selector 没匹配到任何 Pod，转发会一直卡住或连不上，这本身就是一个排查信号。第三，port-forward 适合临时调试，不适合当正式访问通道，它的性能远不如 Service 或 Ingress。
5.3 用事件流和日志回看定位故障根因
故障排查时最忌讳只看一个点。我的经验是“事件定方向，日志找证据，节点看环境”。事件可以通过 describe 或者直接查看：
kubectl get events -n demo --sort-by=.lastTimestamp事件会记录调度失败、镜像拉取失败、探针失败、节点驱逐、卷挂载失败等大量信息。比如一个 Pod 一直 Pending，事件里通常会出现FailedScheduling，后面跟着具体的错误，比如节点 CPU 或内存不足、没有匹配的节点标签、节点被污点拒绝等。
日志的作用是找到容器内部的报错：
kubectl logs my-pod -n demo --previous --tail=100 --timestamps--previous看上一次容器实例的输出，--timestamps加了时间戳后，可以和事件时间对比，还原整个故障时间线。
比如一个常见的 CrashLoopBackOff 场景：get pods只能看到状态，describe 事件里写着Back-off restarting failed container，退出码 127，再配合--previous日志看到 “command not found”，立刻就能判断是启动命令写错或镜像里没有对应程序。如果退出码是 137，多半是内存超限被 OOM Kill；如果是探针失败，事件里会直接给出Liveness probe failed和具体错误。
多副本日志聚合也很实用，标签选择器可以一次性拉取多个 Pod 的日志：
kubectl logs -l app=myapp --tail=100 --timestamps较新版本的 kubectl 还支持--prefix，给每行日志加上 Pod 和容器名前缀，排查多副本问题时会方便很多。
5.4 常见问题对照表
| 现象 | 可能原因 | 优先排查命令 |
|---|---|---|
| Pod 一直 Pending | 节点资源不足、节点被 cordon、污点未容忍、存储卷挂载卡住 | kubectl describe pod看 FailedScheduling 事件 |
| Pod 卡在 ImagePullBackOff | 镜像名打错、tag 不存在、私有仓库认证失败 | kubectl describe pod看事件；kubectl get pod -o yaml看 image |
| Pod 频繁重启 | 启动命令报错、探针失败、OOM | kubectl logs --previous；kubectl describe pod看退出码 |
| Service 访问不通 | selector 没匹配到 Pod、targetPort 写错、Endpoints 为空 | kubectl get endpoints；kubectl describe svc |
| Pod 被驱逐 | 节点磁盘或内存压力 | kubectl describe pod看 Evicted 原因；kubectl top node |
| PVC 一直 Pending | StorageClass 不存在、存储插件异常 | kubectl describe pvc看 Provisioning 事件 |
| Pod 卡 Terminating | finalizer 阻塞、节点失联 | kubectl get pod -o yaml看 finalizers；确认节点状态 |
这张表不能覆盖所有情况，但可以作为排查第一步的参考。遇到没见过的现象，先看事件，再看日志，最后看节点，基本能覆盖九成问题。
6. 多集群与权限校验：config、auth can-i 和资源校验
6.1 多集群上下文切换
一个人同时维护几套集群是很常见的事，kubeconfig 里的 context 就是用来管理这些连接信息的。先看当前环境：
kubectl config current-context列出所有可用上下文：
kubectl config get-contexts切换上下文：
kubectl config use-context prod查看当前上下文的详细配置：
kubectl config view --minify多集群环境下我强烈建议不要在脚本里全局切换 context，而是用--context参数临时指定，例如：
kubectl get pods --context prod这样不会污染默认配置，也不会因为切换后忘记切回来导致误操作。如果上下文特别多，还可以用环境变量KUBECONFIG指定多个配置文件，或者用kubectl config view --flatten合并配置。
防止生产误操作，我个人的习惯是在 shell 提示符里显示当前 context 和 namespace，每次敲命令前都先看一眼kubectl config current-context。尤其是要执行 delete、drain、cordon 这类破坏性命令前，这个确认动作能救很多人。
6.2 权限检查与资源校验
遇到Forbidden报错时，第一步不是怀疑集群坏了，而是检查 RBAC 权限。kubectl auth can-i可以快速判断当前用户有没有某个权限：
kubectl auth can-i create deployments --namespace=dev kubectl auth can-i --list -n dev--list会列出当前用户在指定命名空间内的全部权限，调试 SA（ServiceAccount）很方便。甚至可以用--as模拟其他身份：
kubectl auth can-i list secrets --as=system:serviceaccount:dev:my-sa -n dev如果 SA Token 需要临时获取，新版 kubectl 提供了kubectl create token命令，比手动拼接 Secret 简单得多：
kubectl create token my-sa -n dev集群里新节点加入时，kubelet 通常会生成 CSR（CertificateSigningRequest），需要管理员审批。查看和审批命令：
kubectl get csr kubectl certificate approve csr-xxxx如果 CSR 一直 Pending，节点状态就会长期显示 NotReady，审批后会自动转好。
最后，资源校验方面，除了前面提过的--dry-run=server，还可以用kubectl cluster-info检查集群整体健康状态。这个命令会输出 API Server 和核心插件地址，如果某个组件显示Unhealthy，通常是系统组件或网络问题。
7. 我平时使用 kubectl 的一些习惯
说了这么多命令，最后分享几个让我少踩坑的日常习惯。
第一，能用文件管理配置，就不要直接用kubectl edit去改生产对象。交互式编辑器里容易误改字段，而且改完没有版本记录的审计效果。我的做法是把当前对象导出成 YAML，修改后统一走kubectl apply：
kubectl get deployment my-nginx -o yaml > my-nginx.yaml第二，脚本里解析信息时，永远用-o json配合jq，或者custom-columns/jsonpath，不要用默认表格输出。默认输出不是为了程序解析设计的，格式一旦变化脚本就挂了。
第三，危险操作前做两道确认。先看kubectl config current-context确认环境，再执行kubectl get namespaces看列表是不是符合预期。如果要在生产环境执行kubectl delete、drain、cordon这类操作，我甚至会把命令先放在--dry-run=client里跑一遍。
第四，遇到不熟悉的字段，先查kubectl explain，而不是直接搜网页。命令行里给出的字段说明往往就是 API 定义本身，准确度最高。安了自定义 CRD 之后，api-resources和explain的组合尤其好用。
第五，多花一点时间把-o wide、-w、--sort-by、--field-selector这些“小参数”吃透。它们不会单独出现在命令大全的标题里，但真正到了排障现场，往往就是这些小参数帮你节省了几十分钟。
如果你刚开始接触 Kubernetes，别急着背命令。安装一套本地集群，把这篇文章里的命令都敲一遍，边敲边看输出内容，再对照官方文档理解字段含义，慢慢就会形成一套自己的命令地图。kubectl 这个工具的深度和操作习惯是成正比的，命令只是入口，对资源模型的理解才是让你真正高效的关键。
