Kubernetes 命令速查表
Kubernetes 常用命令速查：kubectl get、apply、delete、scale、rollout、port-forward 等高频命令对照，附中文说明，集群运维与排障时快速查阅。
原理解析
Kubernetes 编排容器化应用：把容器打包进 Pod（最小调度单元），用 Deployment 管理副本与滚动更新，用 Service 提供稳定访问入口。核心思想是「声明期望状态，系统持续调谐到该状态」。
kubectl 既支持命令式（run/create 直接改集群）也支持声明式（apply -f 用 YAML 描述期望状态，由控制器 reconciliation 保证一致）。排查常用 logs/describe/exec，扩容用 scale，发布用 rollout。
什么时候该查这张表
这张表在你要排查线上集群时有用。Kubernetes 的排障路径高度模式化：Pod 起不来看 describe 与 logs，副本不均衡看 get pods 的分布与节点亲和，发布卡住看 rollout status，容量不足看 describe node。命令本身是死的，判断顺序是活的。
不该查的情况：你在做集群架构设计或选型。kubectl 命令解决的是「怎么观察和修改」，解决不了「该用 Deployment 还是 StatefulSet」这类结构决策，那是设计问题。
判断标准：命令能让现状发生改变就是写操作（apply/edit/delete/scale），只读的只有 get/describe/logs/explain 三类。排障阶段应坚持只用只读命令——先看清再动手，否则一次误操作会把现场破坏掉。
特别注意 kubectl 不是 SSH：它连的是 API Server，所有操作都被 RBAC 鉴权并写进审计日志。生产集群上 kubectl delete 没有回滚，所以任何破坏性命令前先 kubectl get -o yaml > backup.yaml 存档。
边界与常见陷阱
Pending 状态几乎总是镜像拉取问题
Pod 长时间停在 Pending 而 Running 数为 0 时，九成是镜像拉不下来。查 「describe pod」 里的 Events，注意三类原因：仓库不存在或 tag 拼错、私有仓库缺 imagePullSecrets、网络不通（节点无法访问 registry）。describe 的 Events 段是排障第一现场，比猜更快。
CrashLoopBackOff 的根因在上一轮日志里
直接看当前 logs 常常是空的或误导性的，因为容器已经崩了。正确做法是 kubectl logs <pod> --previous 取上一个容器实例的日志，那才是崩溃原因。同时注意重启策略 backoff 会在多次失败后拉长间隔（最长 5 分钟），所以「等一会儿就好了」通常只是 backoff 生效，不代表问题自行修复。
Omitted 与指定值在滚动更新时行为不同
改了 Deployment 的 template 而没改 selector 会直接报错；改了 selector 会新起 ReplicaSet 并保留旧的一个，表现为「多了一组副本」，而不是原地更新。HPA 与 Deployment 配合时也要注意 selector 一旦变动，HPA 会失去绑定并停止扩缩容，因为 HPA 依赖 selector 找到目标。
资源 requests 与 limits 的差值决定调度与限流行为
未设 requests 时调度器按节点可分配量打分，可能把 Pod 挤到边缘节点并在高峰时被驱逐。设了 requests 但 limits 过紧，则容器会在内存压力下被 OOMKilled，且重启风暴掩盖真实错误。经验做法是 requests 取实测 P95、limits 给出足够余量，并让两者落在同一资源档位以避免调度与限流互相打架。
与相邻内容的分工
要查 kubectl 完整 flag 与子命令结构，本表是常用集合的速查而非手册，用 kubectl <cmd> --help 与官方文档更权威。
要编写或校验 K8s YAML，本表不含语法速查；JSON Schema 校验比人工比对可靠得多。
涉及网络不通、DNS 解析、Ingress 与证书时，问题多半落在集群外（DNS 提供商、负载均衡器、证书机构），kubectl 只能观测不能解决。
若只是想把 YAML 转成可读格式或做结构对比，用站内 YAML 相关工具；本表只覆盖集群交互命令。
实战片段
要点：① 排障阶段只用只读命令（get/describe/logs/explain），写操作会破坏现场；② Events 段是镜像拉取与调度失败的第一现场，比反复 describe Pod 的 status 更直接；③ 崩溃原因一律用 --previous 取上一个容器实例的日志；④ 任何 delete/scale/apply 之前先 -o yaml 存档，API Server 操作进审计日志但没有 undo。
# 只读排障顺序：先看清现状，再动手改
# ① 集群活着吗
kubectl cluster-info
kubectl get nodes -o wide
# ② Pod 到底卡在哪：Pending / CrashLoop / Running 但不 Ready
kubectl get pods -A -o wide | grep -vE "Running|Completed"
# 排障期间只看这一列：READY 永远是 1/N 就说明没就绪
kubectl get pods -A | awk 'NR>1 && $2!~/^([0-9]+)/\1$/'
# ③ 事件是排障第一现场（镜像拉取、调度失败、资源不足都在这里）
kubectl describe pod -n <ns> <pod> | sed -n '/Events:/,$p'
# ④ 崩溃原因在上一轮日志，不是当前日志
kubectl logs <pod> --previous --tail=200
# ⑤ 状态分布与节点亲和
kubectl get pods -n <ns> -o custom-columns='NAME:.metadata.name,NODE:.spec.nodeName,STATUS:.status.phase'
# 改之前先存档（kubectl delete 没有回滚）
kubectl get deploy <name> -n <ns> -o yaml > backup.yaml实践注解
- kubectl apply 与 create 的差异在「已存在」时的行为create 遇到已存在的资源直接报错，apply 会做三路合并更新。用 apply 管理却有字段被其它控制器写入时，会出现「apply 报 conflict」的问题，此时要看 last-applied-configuration 是否与实况漂移。
- delete pod 只是重建，不是修问题Pod 由 Deployment/StatefulSet 管理，删除后控制器会立刻起一个新的副本，故障可能原样复现。要真正排查应看 kubectl describe 的 Events 与上一次退出的日志（--previous）。
- 资源限制缺失会造成节点级雪崩没写 requests/limits 的 Pod 可以吃满节点内存，触发 OOM Killer 连带杀掉同节点其它 Pod。生产应至少设置 requests，并对内存设 limits，否则调度器无法做出合理放置决策。
数据来源
- Kubernetes documentation (kubernetes.io/docs)
- kubectl reference
上述编号、名称与定义均来自公开规范，本站不主张对规范数据本身的独创性；本页的编排方式、中文释义与实践注解由本站撰写。
| 命令 | 说明 |
|---|---|
| kubectl version | 查看客户端 / 服务端版本 |
| kubectl cluster-info | 查看集群控制面地址 |
| kubectl get nodes | 列出集群节点（-o wide 详情） |
| kubectl get pods | 列出 Pod（-A 所有命名空间） |
| kubectl get services | 列出 Service |
| kubectl get deployments | 列出 Deployment |
| kubectl describe pod | 查看 Pod 详情与事件 |
| kubectl logs | 查看 Pod 日志（-f 跟踪） |
| kubectl exec | 在容器内执行命令（-it 交互） |
| kubectl apply -f | 用清单文件创建 / 更新资源 |
| kubectl create | 从命令式参数创建资源 |
| kubectl delete | 删除资源（-f 或 资源名） |
| kubectl edit | 在线编辑资源定义 |
| kubectl scale | 扩缩容副本数（--replicas） |
| kubectl rollout status | 查看滚动更新进度 |
| kubectl rollout undo | 回滚到上一版部署 |
| kubectl port-forward | 把本地端口转发到 Pod |
| kubectl expose | 把资源暴露为 Service |
| kubectl config get-contexts | 列出 kubeconfig 上下文 |
| kubectl config use-context | 切换当前集群上下文 |
| kubectl top nodes | 查看节点 CPU / 内存占用 |
| kubectl top pods | 查看 Pod 资源占用 |
| kubectl cp | 容器与本地间拷贝文件 |
| kubectl cordon | 标记节点不可调度 |
| kubectl uncordon | 恢复节点可调度 |
| kubectl drain | 驱逐节点上的 Pod（维护用） |
| kubectl get all | 列出命名空间内全部资源 |
常见问题
kubectl apply 和 create 有什么区别？
apply 是声明式，比对清单与集群现状后做增量变更，可重复执行、适合 GitOps；create 是命令式，直接新建资源，重复执行会报错。
如何查看 Pod 一直重启 / 崩溃的原因？
先用 kubectl describe pod <名> 看 Events 与 Last State（Exit Code、Reason）；再用 kubectl logs --previous 看上一次容器崩溃前的日志。
如何把本地端口转发到 Pod 来调试？
用 kubectl port-forward pod/<名> 8080:80 把本机 8080 映射到 Pod 的 80 端口，然后访问 localhost:8080 即可本地联调，无需暴露 Service。
如何回滚一次失败的滚动更新？
kubectl rollout undo deployment/<名> 回滚到上一版；kubectl rollout history deployment/<名> 看历史，--to-revision=N 可指定回滚到某版本。