kubectl 是操作 Kubernetes API 的主要命令行工具。真正高效的用法，不是背下所有子命令，而是掌握“先确认上下文、再查询状态、然后缩小范围、最后执行变更”的固定流程。
这篇文章合并整理了两份旧命令笔记，并删除了已经弃用或依赖旧 Docker 运行时的做法。
一、先确认当前集群和上下文
任何变更前，先确认 kubectl 正在操作哪个集群：
kubectl config current-context
kubectl config get-contexts
kubectl cluster-info
切换上下文：
kubectl config use-context <CONTEXT_NAME>
查看命名空间：
kubectl get namespace
命令中明确指定命名空间：
kubectl get pod -n <NAMESPACE>
生产环境最常见的误操作之一，就是上下文或命名空间选错。执行删除、扩容、回滚前应再次确认。
二、发现集群支持的资源
查看 API 资源及其简称、是否属于命名空间：
kubectl api-resources
查看支持的 API 版本：
kubectl api-versions
查看资源字段结构：
kubectl explain deployment
kubectl explain deployment.spec.template.spec.containers
旧笔记里的 kubectl get cs 使用 ComponentStatus API，该 API 很早就已弃用。控制面健康检查应结合 API Server readyz、组件监控和实际工作负载状态：
kubectl get --raw='/readyz?verbose'
三、查询资源
查看当前命名空间的 Pod：
kubectl get pods
kubectl get pods -o wide
查看所有命名空间：
kubectl get pods -A
按标签筛选：
kubectl get pods -l app=web
同时查看多种资源：
kubectl get deployment,service,pod
持续观察状态变化：
kubectl get pods -w
查看某个对象的详细信息和事件：
kubectl describe pod <POD_NAME>
kubectl describe deployment <DEPLOYMENT_NAME>
查看近期事件：
kubectl get events --sort-by=.metadata.creationTimestamp
get 适合看列表和概要，describe 适合看配置、状态、调度结果及事件。
四、查看容器日志
查看 Pod 日志：
kubectl logs <POD_NAME>
持续跟踪：
kubectl logs -f <POD_NAME>
多容器 Pod 指定容器：
kubectl logs <POD_NAME> -c <CONTAINER_NAME>
查看上一次已退出容器的日志：
kubectl logs <POD_NAME> -c <CONTAINER_NAME> --previous
只看最近一段时间：
kubectl logs <POD_NAME> --since=30m
也可以按控制器查看日志：
kubectl logs deployment/<DEPLOYMENT_NAME> --all-pods=true
旧笔记把日志路径固定为 /var/lib/docker/containers。现代集群可能使用 containerd、CRI-O 或其他 CRI 运行时，底层路径不应写死。应用排障优先使用 kubectl logs；节点级问题再结合 journalctl、crictl 和具体运行时文档。
五、进入容器执行命令
打开交互式 Shell：
kubectl exec -it <POD_NAME> -- sh
指定容器：
kubectl exec -it <POD_NAME> -c <CONTAINER_NAME> -- sh
执行单条命令：
kubectl exec <POD_NAME> -- env
有些精简镜像没有 bash、curl 甚至 sh。不要为了排障临时修改生产镜像，可以评估使用 kubectl debug 创建临时调试容器：
kubectl debug -it <POD_NAME> --image=<DEBUG_IMAGE>
调试镜像同样应来自可信仓库，并受安全策略约束。
六、声明式创建和更新
上线前先校验：
kubectl apply --dry-run=server --validate=strict -f app.yaml
查看差异：
kubectl diff -f app.yaml
应用清单：
kubectl apply -f app.yaml
查看最终对象：
kubectl get deployment <NAME> -o yaml
推荐把 YAML 存入版本控制并通过 apply 管理。kubectl create -f 适合首次创建，但持续维护时应保持统一的对象管理方式，避免多套工具同时覆盖字段。
七、Deployment 发布与回滚
修改镜像：
kubectl set image deployment/web web=<IMAGE>:<TAG>
等待发布完成：
kubectl rollout status deployment/web
查看发布历史：
kubectl rollout history deployment/web
查看指定修订版本：
kubectl rollout history deployment/web --revision=<REVISION>
回滚到上一版：
kubectl rollout undo deployment/web
回滚到指定版本：
kubectl rollout undo deployment/web --to-revision=<REVISION>
触发滚动重启：
kubectl rollout restart deployment/web
旧命令中的 --record 已经不适合作为现代发布记录方案。更可靠的做法是使用 Git 提交、镜像摘要、CI/CD 记录和变更审计来追踪发布来源。
八、扩缩容与暂停发布
扩容到 5 个副本：
kubectl scale deployment/web --replicas=5
查看副本状态：
kubectl get deployment web
kubectl get replicaset -l app=web
暂停和恢复 Deployment 发布：
kubectl rollout pause deployment/web
kubectl rollout resume deployment/web
手工 scale 可能被 HorizontalPodAutoscaler 再次调整。如果资源启用了自动扩缩容，应先理解 HPA 的期望状态，避免两套控制逻辑互相覆盖。
九、临时访问应用
把 Deployment 暴露为 Service：
kubectl expose deployment web --port=80 --target-port=8080
本地临时端口转发：
kubectl port-forward service/web 8080:80
随后访问：
curl http://127.0.0.1:8080/
直接访问 Pod IP 通常只适合在集群网络内排查。面向用户的稳定入口应该通过 Service、Ingress、Gateway 或负载均衡器提供。
十、检查权限
确认当前身份：
kubectl auth whoami
检查自己能否执行某项操作：
kubectl auth can-i delete pods -n production
检查某个用户或服务账号权限：
kubectl auth can-i list secrets \
--as=system:serviceaccount:<NAMESPACE>:<SERVICE_ACCOUNT> \
-n <NAMESPACE>
排查 Forbidden 时，不要第一时间授予 cluster-admin。先确认身份、命名空间、Role、ClusterRole 和绑定关系，并遵循最小权限原则。
十一、常见故障的查询顺序
Pod 启动失败时，可以按下面顺序检查：
1. kubectl get pod -o wide
2. kubectl describe pod <POD_NAME>
3. kubectl logs <POD_NAME> --all-containers=true
4. kubectl logs <POD_NAME> --previous
5. kubectl get events --sort-by=.metadata.creationTimestamp
6. kubectl get pvc、service、endpointslice 等依赖资源
7. 必要时检查节点、kubelet、容器运行时和 CNI
如果 Pod 一直 Pending，重点看调度事件、资源请求、污点与容忍、节点选择、PVC 和拓扑限制。
如果处于 CrashLoopBackOff，重点看当前与 previous 日志、启动命令、配置、Secret、探针和依赖服务。
如果 Service 无流量，检查 selector 是否匹配 Pod 标签，以及 EndpointSlice 是否存在：
kubectl get service <SERVICE_NAME> -o yaml
kubectl get endpointslice -l kubernetes.io/service-name=<SERVICE_NAME>
十二、删除操作要谨慎
删除清单中的资源：
kubectl delete -f app.yaml
按名称删除：
kubectl delete deployment web
不要在未确认上下文、命名空间、标签范围和回收策略时批量删除。特别要注意 StatefulSet、PVC、Namespace、CRD 和带级联关系的资源；删除对象可能同时影响后端数据或大量从属资源。
总结
kubectl 的核心工作流可以概括为：确认上下文 → 查询资源 → describe 与 logs 缩小范围 → diff 和 dry-run 预览变更 → apply 执行 → rollout 与事件验证结果。把这套顺序养成习惯，比单纯收集大量命令更有价值。
参考资料：
https://kubernetes.io/docs/reference/kubectl/quick-reference/
https://kubernetes.io/docs/reference/kubectl/generated/
https://kubernetes.io/docs/reference/kubectl/generated/kubectl_rollout/