kubectl 命令速查表 - Kubernetes 常用命令大全

面向应用开发与集群运维的 kubectl 命令手册，覆盖资源查询、Pod 诊断、副本伸缩与集群上下文切换。与直接读 YAML 相比，kubectl 是观察集群状态、控制变更的一致入口，CrashLoopBackOff、Pod 卡在 Pending、滚动更新失败这类高频事故都能在命令层面快速定位。读完可独立完成"看状态 → 查事件 → 看日志 → 恢复或回滚"的完整排障闭环。

容器与编排·共 81 条命令·最后更新 2026-09-10

典型使用场景

面向 Kubernetes 集群的运维与交付：查看资源状态、扩缩容、滚动更新、排查 Pod 处于 Pending/CrashLoopBackOff/ImagePullBackOff 等异常，以及查看日志与事件定位根因。

查询资源 Get 5

kubectl get pods -n prod

列出指定命名空间的 Pod

kubectl get pods -o wide

额外显示节点和 Pod IP

kubectl get pods -A

列出所有命名空间的 Pod

kubectl get svc,ingress -n prod

一次查 Service 和 Ingress

kubectl get events --sort-by=.lastTimestamp

按时间排序看事件，定位调度/拉镜像失败

描述与诊断 Describe 5

kubectl describe pod <pod> -n prod

看事件、容器状态、探针，排查 CrashLoop/Pending

kubectl logs <pod> -n prod

查看 Pod 日志

kubectl logs <pod> --previous

查看上一次崩溃容器的日志，CrashLoop 必用

kubectl logs <pod> -c <container>

多容器 Pod 指定容器日志

kubectl exec -it <pod> -- sh

进入 Pod 容器调试

伸缩与更新 Scale & Rollout 5

kubectl scale deploy/app --replicas=3

声明式调整副本数，触发新 ReplicaSet 生成对应 Pod，扩容立即按需拉起

kubectl rollout status deploy/app

阻塞等待滚动更新完成；超时未就绪说明新版本探针失败，应加 timeout 参数避免无限挂起

kubectl rollout undo deploy/app

回滚到上一个版本，排障时首选而非手动改 image；可用 --to-revision 指定回滚目标

kubectl set image deploy/app c=app:1.1

更新镜像触发滚动更新

kubectl delete pod <pod>

删除 Pod，由控制器自动重建

上下文与配置 Context 4

kubectl config get-contexts

列出所有集群上下文

kubectl config use-context <ctx>

切换当前操作的集群，多集群必看

kubectl config set-context --current --namespace=prod

设置默认命名空间，省去每次 -n

kubectl top pod -n prod

查看 Pod CPU/内存用量，需 metrics-server

常见问题 FAQ 5

Q: 如何查看所有命名空间的 Pod？

A: kubectl get pods -A 或 kubectl get pods --all-namespaces，可查看集群中所有命名空间的 Pod。

Q: kubectl apply 和 kubectl create 有什么区别？

A: kubectl apply 是声明式（推荐），支持创建和更新；kubectl create 是命令式，重复执行会报错已存在。

Q: 如何查看 Pod 的日志？

A: kubectl logs <pod> -n <namespace>，加 -f 实时跟踪，--previous 查看上一次崩溃容器的日志。

Q: 如何进入 Pod 的容器？

A: kubectl exec -it <pod> -- sh（或 /bin/bash），多容器 Pod 用 -c <container> 指定容器。

Q: 如何查看集群节点状态？

A: kubectl get nodes 查看所有节点状态，kubectl describe node <name> 查看节点详细信息。

高频补充命令（容量增强 · REQ-02） 35

kubectl cluster-info

查看集群控制面端点与附加服务地址

kubectl config get-contexts

列出全部上下文及当前所选上下文

kubectl config use-context <ctx>

切换当前操作的集群上下文

kubectl api-resources

列出集群支持的所有资源类型与简写

kubectl explain pod.spec.containers

查看某字段的官方说明与类型（无需翻文档）

kubectl get all -n <ns>

查看命名空间内的全部工作负载与网络资源

kubectl get pods -l app=web

按标签选择器筛选 Pod

kubectl get pods -o wide

显示 Pod 所在节点与 Pod IP

kubectl get events --sort-by=.lastTimestamp

按时间排序查看集群事件（排障首选）

kubectl describe pod <pod>

查看 Pod 详情、事件与状态原因

kubectl logs <pod> -c <container>

查看指定容器的日志

kubectl exec -it <pod> -- bash

在 Pod 内打开交互式 shell

kubectl port-forward <pod> 8080:80

将本地端口转发到 Pod 端口便于调试

kubectl cp <pod>:/path ./local

在 Pod 与本地之间复制文件

kubectl apply -f - <<EOF

直接从标准输入创建/更新资源

kubectl create deployment web --image=nginx

快速创建一个 Deployment

kubectl scale deployment web --replicas=3

手动扩缩容副本数

kubectl rollout status deployment/web

阻塞等待滚动更新完成

kubectl rollout undo deployment/web

回滚到上一个稳定版本

kubectl rollout history deployment/web

查看该 Deployment 的修订历史

kubectl set image deployment/web web=nginx:1.25

更新容器镜像触发滚动发布

kubectl delete pod <pod> --grace-period=0

强制立即删除 Pod（绕过优雅退出）

kubectl cordon <node>

标记节点为不可调度（保留已有负载）

kubectl drain <node> --ignore-daemonsets

驱逐节点上负载以便维护

kubectl uncordon <node>

恢复节点可调度

kubectl taint nodes <node> key=value:NoSchedule

给节点打污点，限制可调度 Pod

kubectl label nodes <node> disktype=ssd

给节点打标签，供节点亲和性选择

kubectl top node

查看各节点 CPU/内存使用率

kubectl top pod

查看 Pod 资源使用率

kubectl get hpa

查看水平自动扩缩（HPA）当前状态

kubectl apply -k <dir>

使用 Kustomize 目录部署

kubectl get secret <name> -o jsonpath={.data.token}

提取 secret 中某字段（base64）

kubectl create configmap <name> --from-file=./cfg

从文件/目录创建配置映射

kubectl proxy

在本地启动 API Server 代理便于调试

kubectl auth can-i create pods

检查当前身份是否具备某权限

调试与输出格式化（REQ-02 补充） 22

kubectl get pods --field-selector=status.phase=Running

只列出处于 Running 阶段的 Pod

kubectl get nodes --selector='!node-role.kubernetes.io/control-plane'

仅列出工作节点，排除控制面

kubectl get pods --show-labels

显示 Pod 携带的全部标签

kubectl get services --sort-by=.metadata.name

按名称排序列出 Service

kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'

按重启次数排序 Pod，快速找异常

kubectl get pv --sort-by=.spec.capacity.storage

按容量大小排序持久卷

kubectl get nodes -o jsonpath={.items[*].status.addresses[?(@.type=="ExternalIP")].address}

提取全部节点的外网 IP

kubectl get secret my-secret -o go-template={{range $k,$v := .data}}{{$k}}:{{$v|base64decode}}{{end}}

用模板一次性解码输出 Secret 键值

kubectl get pods -A -o=custom-columns='DATA:spec.containers[*].image'

列出集群内运行的所有容器镜像

kubectl get node -o custom-columns='NODE_NAME:.metadata.name,STATUS:.status.conditions[?(@.type=="Ready")].status'

自定义列查看节点就绪状态

kubectl diff -f ./my-manifest.yaml

对比集群现状与应用清单后的差异

kubectl patch node k8s-node-1 -p {"spec":{"unschedulable":true}}

局部更新节点为不可调度

kubectl patch deployment web --subresource=scale --type=merge -p {"spec":{"replicas":2}}

通过 scale 子资源调整副本数

kubectl replace --force -f ./pod.json

强制替换资源（先删除再重建）

kubectl expose deployment web --port=80 --target-port=8000

为工作负载暴露一个 Service

kubectl logs -f -l name=myLabel --all-containers

按标签流式跟踪全部容器日志

kubectl logs my-pod --previous

查看上一次崩溃实例的日志

kubectl debug my-pod -it --image=busybox:1.28

在 Pod 内创建交互式调试容器

kubectl debug node/my-node -it --image=busybox:1.28

在节点上创建调试会话

kubectl cluster-info dump --output-directory=/path/to/cluster-state

导出集群状态快照到指定目录

kubectl api-resources --verbs=list,get

列出支持指定动词的资源类型

kubectl run nginx --image=nginx --dry-run=client -o yaml > pod.yaml

生成 Pod 清单而不真正创建

参数矩阵

参数	作用	示例
`-n`	指定命名空间，避免操作默认空间	`kubectl -n prod get pods`
`-o`	输出格式（yaml/json/wide/name）	`kubectl get pod web -o yaml`
`--kubeconfig`	指定集群凭证文件	`kubectl --kubeconfig ~/.kube/prod get nodes`
`-f`	按 YAML 文件创建/应用/删除资源	`kubectl apply -f deploy.yaml`
`--dry-run=client`	仅校验不创建，可生成清单	`kubectl run nginx --image=nginx --dry-run=client -o yaml`
`-l`	按标签筛选资源	`kubectl get pods -l app=web`
`--previous`	查看上一次崩溃容器的日志	`kubectl logs web --previous`
`-c`	指定多容器 Pod 中的某个容器	`kubectl logs web -c app`
`--watch`	持续观察资源变化	`kubectl get pods --watch`
`--record`	记录变更原因到修订历史	`kubectl set image deploy/web app=new:1.1 --record`

易错点与避坑指南

现象Pod 长时间处于 Pending。

原因节点资源不足、没有匹配的节点（taint/亲和），或 PVC 无法绑定。

处置kubectl describe pod 看 Events；检查节点资源（kubectl top nodes）与 PVC 状态；放宽资源请求或污点容忍。

现象Pod 反复重启，状态 CrashLoopBackOff。

原因应用启动即崩溃（配置错误、依赖未就绪、端口被占），或探针失败。

处置kubectl logs web --previous 看上一次崩溃日志；kubectl describe pod 看 Last State 与 Events；修正启动命令或探针阈值。

现象镜像拉取失败，状态 ImagePullBackOff / ErrImagePull。

原因镜像名/标签写错、私有仓库未配置 imagePullSecret、或节点无法访问仓库。

处置核对镜像地址与 tag；为私有仓库配置 imagePullSecrets；在节点上手动 crictl pull 验证网络。

现象kubectl top 报错 metrics not available。

原因集群未安装 metrics-server，不是命令写错。

处置确认 metrics-server 已部署（kubectl get apiservice v1beta1.metrics.k8s.io）；安装后再用 top。

现象误在本地把资源改到了生产集群。

原因当前 context 指向生产，操作时未确认集群。

处置任何写操作前执行 kubectl config get-contexts 与 kubectl config current-context 确认；用别名或工具防止误操作。

现象apply 之后改动未生效。

原因字段被其他控制器（如 HPA、Operator）覆盖，或字段不可变。

处置kubectl get 看实际值；对不可变字段（如 selector）需删除重建；排查是否有 controller 在管理该资源。

排障路径

1先看 Pod 状态与事件
kubectl describe pod web
Events 段通常有最直接的失败原因（FailedScheduling、BackOff、FailedMount 等）。
2读应用日志（含上一次崩溃）
kubectl logs web --previous -c app
CrashLoop 时当前容器已退出，必须加 --previous 才能看到崩溃前的输出。
3确认节点资源与调度
kubectl top nodes
Pending 多半是 CPU/内存不足或没有可调度节点。
4查看完整修订历史以便回滚
kubectl rollout history deploy/web
确认有可回滚版本后再 kubectl rollout undo deploy/web 回退。

命令示例

定位 CrashLoopBackOff 的标准三连

kubectl get pods -n prod
kubectl logs <pod> --previous -n prod
kubectl describe pod <pod> -n prod

restart 次数只说明在重启，真正的原因在上一次崩溃的日志里，所以 --previous 必用；describe 底部的 Events 给出探针失败、OOMKilled、镜像拉取失败等原因。

输出

NAME                     READY   STATUS                 RESTARTS      AGE
web-7d9f8b6c5-2xk4t     0/1     CrashLoopBackOff     7             12m

按重启次数排序，一眼找出异常 Pod

kubectl get pods -n prod --sort-by='.status.containerStatuses[0].restartCount'

集群里 Pod 一多，逐个 describe 根本来不及。按 restartCount 升序排，重启几十上百次的会直接浮到最上面，异常目标立刻收敛到一两个。

输出

NAME                     READY   STATUS                 RESTARTS   AGE
api-5f7c9d4b8-mq2xv     0/1     CrashLoopBackOff     142        3h
web-7d9f8b6c5-2xk4t     1/1     Running                0          3h

发布后阻塞确认，超时就回滚

kubectl set image deployment/web web=nginx:1.25
kubectl rollout status deployment/web
kubectl rollout undo deployment/web

rollout status 会一直等到新 ReplicaSet 就绪，超时未就绪基本就是新版本探针挂了；此时用 undo 回退上一个修订，而不是手动改 image 硬猜。

输出

deployment "web" successfully rolled out

导出集群里所有容器镜像清单

kubectl get pods -A -o=custom-columns='DATA:spec.containers[*].image' | sort -u

做版本盘点、找漏升的旧镜像时，一次 -A 加 custom-columns 就能拿到全集群镜像集合，再 sort -u 去重，比逐个 describe 快得多。

先生成清单再 apply，出错也不污染集群

kubectl run nginx --image=nginx --dry-run=client -o yaml > pod.yaml
kubectl diff -f ./my-manifest.yaml
kubectl apply -f ./my-manifest.yaml

--dry-run=client 完全在本地渲染，不发请求；kubectl diff 会打印应用后的实际差异，确认无误再 apply，避免手写 YAML 字段名打错就直接改集群。

常见坑与注意事项

kubectl config use-context 切错集群时，后面的 delete/scale 会直接作用在生产环境；每条破坏性命令前先跑 kubectl config current-context 确认。
kubectl delete pod <pod> --grace-period=0 跳过优雅退出，进程来不及刷盘或关闭连接就直接被杀，长请求会失败并丢数据。
kubectl drain 驱逐节点负载但不会自动 uncordon；维护完忘记 kubectl uncordon，该节点会一直保持不可调度，新 Pod 全堆到别的节点上。
kubectl replace --force 是先删后建，对有状态服务意味着数据卷重建和 IP 变化，比 kubectl apply 的原地更新危险得多。
kubectl get secret -o jsonpath={.data.token} 输出的仍是 base64 而非明文，直接拿去当密码用会在鉴权时莫名失败；日志里贴出来也等同于泄露凭证。
多容器 Pod 上不加 -c 直接 kubectl logs 会报「a container name must be specified」，且在只有 1 个容器时正常，容易养成「有时要加有时不要加」的错觉。

提示

排障顺序：get 看状态 → describe 看事件 → logs 看应用错误，CrashLoop 加 --previous。
操作前先 kubectl config get-contexts 确认当前集群，避免在生产集群误操作。
kubectl top 报错通常是没装 metrics-server，不是命令写错。

常见问题

Pod 一直 CrashLoopBackOff，按什么顺序排查最省时间？

固定三步：先 kubectl get pods 看状态和重启次数，再 kubectl describe pod <pod> 看 Events 里的调度/拉镜像失败原因，最后 kubectl logs <pod> --previous 读上一次崩溃实例的日志——不加 --previous 只能看到重启后的空日志。日志里有应用异常就顺着改镜像或配置；若 describe 显示 Pending，方向转为节点资源与污点（kubectl describe node）。

top 命令报错说连不上 metrics-server，是 kubectl 用错了吗？

不是命令写错，而是集群里没装 metrics-server 组件，Metrics API 没有服务端点可供查询，所以 kubectl top pod / kubectl top node 会返回连接被拒绝。补救顺序是：先确认集群版本与网络插件兼容，装好 metrics-server 后用 kubectl get apiservice 验证 metrics.k8s.io 是否 Available，在等待指标同步期间改用 describe 看资源 requests/limits 限流信息。

多集群环境下怎么避免把命令打到生产集群上？

动手前先 kubectl config get-contexts 看清当前星标指向哪个集群，再用 kubectl config use-context <ctx> 显式切换；把命名空间也固定下来：kubectl config set-context --current --namespace=prod，这样后续命令可以省略反复书写的 -n prod。切完再执行 kubectl cluster-info 复核端点，两步确认后才适合跑 delete、scale 这类有副作用的操作。

apply 和 create 都能建资源，为什么生产上更推荐前者？

create 是命令式的：对象已存在时它直接报错退出，不会更新字段；apply 是声明式的，会 diff 集群现状与你的 YAML 并补齐缺失字段、覆盖变动字段，所以同一份清单可以反复执行。实践里先 kubectl diff -f ./manifest.yaml 看清楚将要发生什么，再 apply；create 只适合一次性的 kubectl create deployment web --image=nginx 这类快速试验。

新版本上线后新 Pod 迟迟不 Ready，该回滚还是该继续等？

别无限等：kubectl rollout status deploy/app 会一直阻塞到超时，超时本身就是「新版本探针失败」的信号。加上 timeout 参数设定上限，配合 kubectl set image 回滚可用 kubectl rollout undo deploy/app（必要时 --to-revision 指定目标版本），然后用 kubectl rollout history deploy/app 看清修订历史。排障阶段优先用 undo 而不是手改 image，否则 revision 记录会与实际部署对不上。

官方参考来源

下方为命令对应的官方权威文档，供你核对最新用法与深入查阅。

Kubernetes 官方文档

由巧匠维护

公开更新于 2026年9月10日，内容持续校对官方文档。

联系我们

命令或描述有误？提交反馈、商务合作或产品建议都可发送邮件给我们。

联系我们

典型使用场景

查询资源 Get 5

描述与诊断 Describe 5

伸缩与更新 Scale & Rollout 5

上下文与配置 Context 4

常见问题 FAQ 5

高频补充命令（容量增强 · REQ-02） 35

调试与输出格式化（REQ-02 补充） 22

参数矩阵

易错点与避坑指南

排障路径

命令示例

定位 CrashLoopBackOff 的标准三连

按重启次数排序，一眼找出异常 Pod

发布后阻塞确认，超时就回滚

导出集群里所有容器镜像清单

先生成清单再 apply，出错也不污染集群

常见坑与注意事项

提示

常见问题

相关速查表

分享

官方参考来源

由 巧匠 维护

联系我们

由巧匠维护