K8s常用命令速查手册：集群运维与故障排查实战

k8s命令记不住？这份常用操作手册直接拿去用

做容器平台运维这几年，跟Kubernetes打交道是每天的必修课。刚接触K8s那会儿，面对一大串kubectl命令确实容易懵，但随着踩的坑越来越多，慢慢总结出了一套自己的常用命令清单。今天把这些命令整理出来分享给大家，涵盖集群巡检、资源管理、日志排查、故障恢复等日常高频场景，希望对正在学习和使用K8s的朋友有所帮助。

1. 基础命令体系与集群信息查询

1.1 kubectl命令的基本语法结构

先来过一遍kubectl的基础语法，掌握了这个，后面所有命令都可以举一反三：

kubectl [command] [TYPE] [NAME] [flags]

• command：针对资源执行的操作，比如get、describe、create、delete等
• TYPE：资源类型，比如pod、deployment、service、node等
• NAME：资源名称，可以指定具体名字，也可以省略表示所有
• flags：可选参数，比如-n指定命名空间，-o指定输出格式，-l按标签筛选

有个要点需要特别提醒：kubectl的版本和集群版本最好保持一致，否则可能出现API兼容问题，导致命令执行报错或者行为异常。建议在本地装上和集群版本一致的kubectl客户端，或者直接使用集群控制节点上的kubectl。

查看版本信息可以用kubectl version，这个命令会同时输出客户端和服务端的版本号。如果两者之间有较大版本差异，建议优先升级客户端版本，因为新版客户端通常向后兼容旧版集群API。

1.2 集群节点与状态巡检

节点是K8s集群的底层基础设施，例行巡检第一件事就是看节点状态：

# 查看集群所有节点 kubectl get nodes # 查看节点详细信息，包括内网IP、内核版本、容器运行时等 kubectl get nodes -o wide # 查看单个节点的详细状态，包括资源使用情况、系统信息等 kubectl describe node <node-name> # 查看节点资源使用率（需要metrics-server组件） kubectl top node

kubectl get nodes -o wide显示的内容比默认输出丰富很多，可以看到节点的内网IP、操作系统版本、内核版本、容器运行时版本等关键信息。当集群跨多个可用区或者物理机房部署时，这些信息对排查网络和兼容性问题非常有用。

节点状态通常有Ready、NotReady、SchedulingDisabled等几种状态：

• Ready：节点健康，可以正常调度Pod
• NotReady：节点异常，通常是网络不通、kubelet宕机或资源耗尽
• SchedulingDisabled：节点被标记为不可调度，但不影响已有Pod运行

1.3 命名空间与资源列表查询

命名空间用于资源隔离，多环境、多团队共用一个集群的场景下，命名空间的合理使用至关重要：

# 查看集群所有命名空间 kubectl get namespaces # 查看default命名空间下所有资源 kubectl get all # 查看指定命名空间下的Pod、Service等资源 kubectl get pods -n <namespace> kubectl get services -n <namespace> kubectl get deployments -n <namespace>

不指定-n参数时，kubectl默认操作default命名空间，这点容易踩坑。曾经有同事改了十几个deployment，结果最后发现全操作到default命名空间去了，生产环境的服务没动到，虚惊一场但确实吓人。如果不想每次敲命令都带-n，可以通过kubectl config设置当前上下文默认namespace，但要注意切换上下文时namespace也会跟着变，操作前多看一眼上下文总没错。

2. 工作负载管理与部署操作

2.1 Deployment的基础操作

Deployment是K8s中最常见的无状态工作负载类型，负责管理Pod的副本数量、滚动更新和故障自愈：

# 创建Deployment（推荐使用yaml文件声明式创建） kubectl create deployment <name> --image=<image> --dry-run=client -o yaml > deployment.yaml kubectl apply -f deployment.yaml # 查看Deployment列表 kubectl get deployments # 查看Deployment详细状态 kubectl describe deployment <deployment-name> # 扩缩容 kubectl scale deployment <deployment-name> --replicas=3 # 更新镜像（直接修改容器镜像版本触发滚动更新） kubectl set image deployment/<deployment-name> <container-name>=<new-image> # 重启Deployment（不会改变配置，常用于重新拉取镜像或重置Pod状态） kubectl rollout restart deployment <deployment-name> # 查看滚动更新状态 kubectl rollout status deployment <deployment-name> # 回滚到上一个版本 kubectl rollout undo deployment <deployment-name> # 回滚到指定版本 kubectl rollout undo deployment <deployment-name> --to-revision=2 # 查看Deployment的历史版本记录 kubectl rollout history deployment <deployment-name> # 删除Deployment kubectl delete deployment <deployment-name>

创建Deployment时，我习惯先用--dry-run=client -o yaml生成一份yaml模板，再根据实际需求手动修改。这样比手写yaml快，又比直接命令行创建更灵活可控。生成的模板会包含基本的metadata、spec字段，改起来方便，也不容易遗漏关键配置。

2.2 Pod相关的核心操作

Pod是K8s最小的调度单元，日常排查故障时和Pod打交道最多：

# 查看Pod列表（默认default命名空间） kubectl get pods # 查看所有命名空间的Pod，并显示Pod所在节点 kubectl get pods -A -o wide # 查看Pod详细状态（包括事件、容器状态、资源等） kubectl describe pod <pod-name> # 进入Pod中的容器（-c参数指定容器名，适用于多容器Pod） kubectl exec -it <pod-name> -- /bin/sh kubectl exec -it <pod-name> -c <container-name> -- /bin/bash # 查看Pod日志 kubectl logs <pod-name> # 实时追踪Pod日志（-f参数） kubectl logs -f <pod-name> # 查看上一个容器实例的日志（排查容器反复重启的情况） kubectl logs <pod-name> --previous # 查看Pod内所有容器的日志（多容器Pod场景） kubectl logs <pod-name> --all-containers=true # 端口转发，本地访问Pod内服务 kubectl port-forward <pod-name> 8080:80 # 将文件从本地复制到Pod内 kubectl cp <local-path> <pod-name>:<remote-path> # 将文件从Pod内复制到本地 kubectl cp <pod-name>:<remote-path> <local-path>

kubectl exec -it里-i表示交互式连接，-t表示分配终端，两个参数搭配才能进入容器的交互式shell。有些基础镜像里没有bash，只有sh，docker和K8s场景下同样存在。还有些精简镜像连shell都没有，这时可以借助kubectl debug临时挂一个带调试工具的容器共享进程命名空间来排查问题，这个后面会提到。

2.3 标签筛选与字段选择器

当集群中Pod数量较多时，标签就是筛选和操作的利器：

# 按标签筛选Pod kubectl get pods -l app=web kubectl get pods -l app=web,env=production # 按标签筛选多个值 kubectl get pods -l 'app in (web,api)' # 按节点名筛选Pod kubectl get pods -o wide --field-selector spec.nodeName=<node-name> # 按状态筛选Pod（比如查看故障Pod） kubectl get pods --field-selector=status.phase=Failed # 给资源打标签或修改标签 kubectl label nodes <node-name> disktype=ssd kubectl label pod <pod-name> app=web --overwrite # 删除标签 kubectl label pod <pod-name> app-

标签筛选的语法有一些细节需要注意：-l可以用逗号分隔多个条件，条件之间是AND关系；还支持in、notin、!=这些集合操作符。实际排查问题时，用-l app=web,env=production这种组合条件能很快锁定目标Pod，避免在几百个Pod里翻来翻去。

字段选择器是另一种筛选方式，按资源字段的值来筛选，比如按节点名、按状态阶段等。它和标签选择器的区别在于，标签是自定义的键值对，字段是资源本身带的属性。两者的应用场景不同，灵活搭配能提升不少排查效率。

2.4 其他常见工作负载类型

Deployment之外，StatefulSet、DaemonSet、Job等类型也是日常高频接触的：

# StatefulSet（有状态应用，如数据库、中间件） kubectl get statefulsets kubectl describe statefulset <name> kubectl scale statefulset <name> --replicas=3 # DaemonSet（每个节点上跑一个Pod，用于日志采集、监控等） kubectl get daemonsets kubectl describe daemonset <name> kubectl rollout restart daemonset <name> # Job和CronJob（批处理任务和定时任务） kubectl get jobs kubectl get cronjobs kubectl logs job/<job-name> kubectl delete job <job-name>

StatefulSet和Deployment的扩容逻辑差别很大：Deployment的Pod是无状态的，扩容时可以随意创建和销毁；StatefulSet的Pod有稳定的网络标识和存储，扩容时按序创建，缩容时按序删除，操作时要清楚这个特性，避免意外中断服务。DaemonSet一般由系统组件创建（比如日志采集器、监控Agent），日常运维中主要关注它的更新和状态即可，不建议随意删除或手动调整副本数。

3. 服务发现与网络配置操作

3.1 Service相关命令

Service负责Pod的负载均衡和服务发现，把一组Pod封装成一个稳定的访问入口：

# 查看Service列表 kubectl get services kubectl get svc # 查看Service详细信息 kubectl describe service <service-name> # 创建Service（从已有Deployment暴露端口） kubectl expose deployment <deployment-name> --port=80 --target-port=8080 --type=ClusterIP # 查看Service对应的后端Pod端点 kubectl get endpoints <service-name> # 临时修改Service类型（常用NodePort调试） kubectl patch service <service-name> -p '{"spec":{"type":"NodePort"}}' # 删除Service kubectl delete service <service-name>

kubectl get endpoints查看Service后端Pod的IP列表非常实用。碰上服务间歇性不可用的问题，用这个命令能快速确认后端Pod是否都在线，IP有没有变化。Service和Pod之间的关联靠的是Selector标签，如果标签写错了，endpoints列表会是空的，服务自然不通。

Service类型有ClusterIP、NodePort、LoadBalancer三种，另有Headless Service（无集群IP）用于StatefulSet。ClusterIP只能在集群内部访问，NodePort会在每个节点上开一个随机端口让外部访问，LoadBalancer则是对接云厂商的负载均衡器。选型时先想清楚访问方在哪里，需要跨集群访问就要配合Ingress或外部负载均衡。

3.2 Ingress与IngressController

Service解决的是集群内部的服务发现，Ingress解决的是外部流量如何进入集群：

# 查看Ingress列表 kubectl get ingress kubectl get ingress -A # 查看Ingress详细信息 kubectl describe ingress <ingress-name> # 创建Ingress（示例） cat <<EOF | kubectl apply -f - apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-ingress spec: rules: - host: app.example.com http: paths: - path: / pathType: Prefix backend: service: name: web-service port: number: 80 EOF # 删除Ingress kubectl delete ingress <ingress-name>

有一点需要特别说明：Ingress只是规则定义，真正干活的是IngressController。没有部署IngressController的话，创建Ingress规则不会产生任何实际效果。常见的IngressController有NGINX Ingress Controller、Traefik、HAProxy等。当访问Ingress地址不通时，优先检查IngressController的运行状态和日志，而不是盯着Ingress资源本身看。

3.3 Service间通信与DNS解析

K8s集群内部有一套内置DNS服务（CoreDNS），Service之间的通信依赖DNS解析：

# 在Pod内解析Service的DNS kubectl run curl-test --image=curlimages/curl --rm -it --restart=Never -- sh -c 'nslookup web-service' kubectl run curl-test --image=curlimages/curl --rm -it --restart=Never -- curl http://web-service:80 # 查看CoreDNS状态 kubectl get pods -n kube-system -l k8s-app=kube-dns kubectl logs -n kube-system -l k8s-app=kube-dns

同一个命名空间下，Service通过名称直接访问即可；跨命名空间需要带上命名空间，比如web-service.production.svc.cluster.local。遇到服务间调用失败的问题，第一步先确认DNS解析是否正常，第二步确认目标Service的endpoints是否在线，第三步确认网络策略（NetworkPolicy）是否放行。大部分跨服务调用异常都出在这三个环节。

4. 配置管理与存储操作

4.1 ConfigMap与Secret的增删改查

应用配置和敏感信息不应该硬编码到镜像里，ConfigMap和Secret就是K8s管理配置和密钥的标准方案：

# 创建ConfigMap的几种方式 # 从文件创建 kubectl create configmap app-config --from-file=config.properties # 从键值对创建 kubectl create configmap app-config --from-literal=db_host=10.0.0.1 --from-literal=db_port=3306 # 从yaml文件创建 kubectl apply -f configmap.yaml # 查看ConfigMap列表 kubectl get configmaps # 查看ConfigMap内容 kubectl get configmap <name> -o yaml kubectl describe configmap <name> # 创建Secret（base64编码存储） kubectl create secret generic db-password --from-literal=password=MyPass@123 # 查看Secret kubectl get secrets kubectl get secret <name> -o yaml # Secret中的值默认以base64编码展示，需要base64解码查看原文 echo <base64-string> | base64 --decode # 删除ConfigMap或Secret kubectl delete configmap <name> kubectl delete secret <name> # 更新ConfigMap或Secret kubectl create configmap app-config --from-file=config.properties --dry-run=client -o yaml | kubectl apply -f -

修改ConfigMap后，已经挂载到Pod里的配置不会自动生效。大部分应用不会监听配置文件变化，所以需要滚动重启关联的Deployment或StatefulSet：

kubectl rollout restart deployment <deployment-name>

Secret的存储方式默认是base64编码，但这个编码不等于加密，任何人只要有权限查看Secret就能解码出原文。在正式的集群环境里，建议开启etcd加密存储，或者配合外部密钥管理服务（如云厂商的KMS、Vault）来增强安全性。

4.2 持久化存储PV与PVC操作

有状态应用需要持久化存储，这就涉及PV（PersistentVolume）和PVC（PersistentVolumeClaim）：

# 查看PV列表 kubectl get pv # 查看PV详细信息 kubectl describe pv <pv-name> # 查看PVC列表（按命名空间隔离） kubectl get pvc -n <namespace> # 查看PVC详细信息 kubectl describe pvc <pvc-name> # 创建PVC（示例） cat <<EOF | kubectl apply -f - apiVersion: v1 kind: PersistentVolumeClaim metadata: name:># 查看Pod的完整信息和事件 kubectl describe pod <pod-name> # 查看节点的完整信息和事件 kubectl describe node <node-name> # 只查看事件（Event）部分 kubectl get events --sort-by=.metadata.creationTimestamp kubectl get events -n <namespace> --sort-by=.lastTimestamp # 按资源类型过滤事件 kubectl get events --field-selector involvedObject.name=<resource-name>

describe输出中有两段最关键：一段是底部的Events，记录了从Pod创建以来所有的关键事件，包括镜像拉取、容器启动、健康检查等；另一段是Conditions，展示Pod当前各个条件的满足情况。排查思路基本是：先看Events找异常源头，再看Conditions确认当前状态，然后顺着这两个方向追查。

Events默认只会保留一段时间（通常是1小时），排查历史故障时，可以结合Prometheus等监控系统回溯时间线，或用kubectl get events --sort-by=.lastTimestamp按时间排序查看窗口内的事件，这样能把故障发生的完整过程还原出来。

5.2 Pod常见异常状态及处理

Pod的Phase有Pending、Running、Succeeded、Failed、Unknown几种，实际排查中更多遇到的是各种CrashLoopBackOff、ImagePullBackOff、Error状态：

# 查看Pod状态列，快速识别异常Pod kubectl get pods -A | grep -v Running # 查看CrashLoopBackOff状态Pod的日志 kubectl logs <pod-name> --previous # 查看容器退出原因，如果exit code是139之类的信号码，通常和内存或代码段错误有关 kubectl describe pod <pod-name> | grep -A 10 "Last State"

常见异常状态的排查思路：

• Pending：Scheduler还没把Pod调度到节点上，看describe里有没有FailedScheduling事件，检查节点资源是否充足、是否有污点或节点亲和性约束
• ImagePullBackOff：镜像拉取失败，检查镜像名是否写对、tag是否存在、私有仓库的认证信息是否正确
• CrashLoopBackOff：容器启动后立刻崩溃，K8s在不断重启它。用logs --previous看上一个实例的日志定位崩溃原因
• Running但NotReady：容器进程活着，但就绪探针（readinessProbe）没通过。确认探针路径、端口和预期响应是否有调整
• OOMKilled：容器内存超出limit被内核杀掉，检查应用的堆内存或缓存设置，同时确认内存limit是否合理
• Terminating卡住：Pod删除不干净，可能是挂载了存储卷释放慢，或者容器进程有僵尸（zombie）无法退出，配合--force强制删除

5.3 节点维护与Pod迁移

节点要重启或者下线维护时，需要先把Pod迁移走，这里有几个命令协同操作：

# 标记节点为不可调度（新Pod不会调度上去，已有Pod保持运行） kubectl cordon <node-name> # 驱赶节点上的Pod（会重新调度到其他节点） kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data # 节点维护完成后，重新启用调度 kubectl uncordon <node-name>

drain命令有几个参数需要特别留意：--ignore-daemonsets是必需的，因为DaemonSet的Pod本来就应该每个节点跑一个，不做忽略会卡在驱赶流程；--delete-emptydir-data用来删除emptyDir临时存储的Pod数据，如果节点上有使用emptyDir的Pod，不加这个参数会被拦截。执行drain前先确认该节点上的Pod是否有其他节点可以承接，集群资源紧张时drain可能长时间hang住。

有个细节容易忽略：cordon只会阻止新的调度，已经运行在节点上的Pod不会受到影响。只有drain才会把已有Pod赶走。日常计划内维护节点时，两个命令搭配使用：先cordon阻止新流量，再drain清空已有负载，维护结束再uncordon恢复调度。

5.4 资源清理与命名空间级操作

大规模清理测试环境的资源，用一条命令全部删除比一个个删高效得多：

# 删除指定命名空间下的所有资源 kubectl delete all -n <namespace> --all # 删除整个命名空间（这个命令会把命名空间下所有资源全部清空） kubectl delete namespace <namespace> # 按标签批量删除 kubectl delete pods -l app=test kubectl delete deployment,statefulset,configmap,secret -l env=test # 处理Terminating状态卡住的命名空间 # 先查看命名空间状态 kubectl get namespace <namespace> -o json > ns.json # 修改finalizers为空数组后，用代理方式更新 # 这种操作风险很高，非必要不建议在生产环境执行 # 强制删除Pod（无响应时） kubectl delete pod <pod-name> --force --grace-period=0 # 强制删除命名空间（风险极高，慎用） kubectl delete namespace <namespace> --force --grace-period=0

先说明一下：kubectl delete all -n <namespace> --all里的all是大意上的资源聚合，实际并不会删除ConfigMap和Secret等内容，所以测试环境重建后要注意残留问题。如果要彻底清空，针对configmap、secret、pvc、role、serviceaccount这些资源单独执行一遍删除命令更靠谱。

命名空间卡在Terminating状态是个比较头疼的问题。通常是该命名空间下还有未被彻底清理的资源（比如自定义资源CRD实例），或者APIService处于异常状态导致资源无法删除。前期排查用kubectl get namespace <name> -o json | jq '.status'和kubectl get apiservice | grep False配合定位原因，实在需要强清（编辑finalizers）也要非常谨慎，因为这可能掩盖底层依赖关系的破坏问题。

5.5 资源对象导出与迁移

从集群里导出资源定义用于备份或迁移，也是日常高频操作：

# 导出资源yaml（推荐） kubectl get deployment <deployment-name> -n <namespace> -o yaml > deployment-backup.yaml kubectl get service <service-name> -n <namespace> -o yaml > service-backup.yaml # 导出资源后去掉状态信息和运行时元数据，方便重新apply到新集群 kubectl get deployment <deployment-name> -n <namespace> -o yaml --export=true > clean-deployment.yaml # 导出所有Deployment（如果资源太多建议分命名空间执行） kubectl get deployments -n <namespace> -o yaml > all-deployments.yaml # 批量导出多个资源到一个文件 kubectl get deploy,svc,configmap,secret -n <namespace> -o yaml > all-resources.yaml

有个地方要留意：新版本kubectl（1.18以上）已经移除了--export参数，直接导出的大多包含status字段、uid等运行时数据。要把导出的yaml再次apply到新集群时，建议手动清理metadata.uid、metadata.resourceVersion、metadata.creationTimestamp这些字段，以及顶层的status块。用sed或yq工具批量处理会省不少事，不会的话手删几个资源也很快。

6. 进阶命令与实用技巧

6.1 多集群管理与上下文切换

生产环境通常不止一个集群，多集群管理需要熟练使用kubectl context：

# 查看所有上下文 kubectl config get-contexts # 查看当前上下文 kubectl config current-context # 切换到指定上下文 kubectl config use-context <context-name> # 查看当前kubeconfig内容 kubectl config view # 配置一个新的集群上下文 kubectl config set-context <context-name> --cluster=<cluster-name> --user=<user-name> --namespace=<namespace> # 直接切换默认命名空间（等价于修改当前上下文的namespace） kubectl config set-context --current --namespace=<namespace>

多集群切换最怕的是在错误的集群里执行了高危命令。我个人的习惯是：在敏感操作（比如删除资源、drain节点）前，先执行一次kubectl config current-context确认当前所在环境，再执行一个只读的查询命令验证上下文。这个习惯看着笨，但真的能救生产环境。

6.2 kubectl常用输出格式速查

# 不同输出格式的用法 kubectl get pods -o wide # 显示更多字段（IP、节点等） kubectl get pods -o yaml # 完整yaml格式输出 kubectl get pods -o json # 完整json格式输出 kubectl get pods -o name # 只输出资源类型和名称 kubectl get pods -o custom-columns=NAME:.metadata.name # 自定义列 kubectl get pods -o jsonpath='{.items[*].metadata.name}' # 用jsonpath提取字段 # 持续监听资源变化（Ctrl+C退出） kubectl get pods -w # 查看资源标签 kubectl get pods --show-labels # 格式化输出到文件 kubectl get deployment <deployment-name> -o yaml > deploy.yaml

-w参数在排障时很实用，可以实时看到Pod状态变化，比如滚动更新时新Pod的创建过程、旧Pod的终止过程，对着屏幕等几秒就能发现更新的节奏和卡点。JSONPath初学时不太好记，但掌握了基础语法后，从复杂资源对象中提取脚本需要的信息会变得非常顺手。

6.3 快速生成yaml模板的技巧

遇到需要创建某种资源但记不住完整yaml结构时，用--dry-run=client快速生成模板是最快的办法：

# 生成Deployment模板 kubectl create deployment nginx-demo --image=nginx --dry-run=client -o yaml # 生成Job模板 kubectl create job demo-job --image=busybox --dry-run=client -o yaml -- sleep 30 # 生成CronJob模板 kubectl create cronjob demo-cron --image=busybox --schedule="*/5 * * * *" --dry-run=client -o yaml -- echo hello # 生成Pod模板 kubectl run nginx-pod --image=nginx --dry-run=client -o yaml # 生成Service模板 kubectl create service clusterip demo-svc --tcp=80:8080 --dry-run=client -o yaml

这个方法能保证生成的yaml格式和字段一定是正确的，再在模板基础上增加需要的配置（比如探针、资源限制、环境变量、存储挂载等），比完全手写yaml节省不少时间，也能避免因为API版本或字段名记错导致的校验错误。

6.4 临时调试容器的使用

Pod处于运行状态但镜像里没有调试工具，比如容器连curl、netstat都没有，这时kubectl debug命令可以临时往Pod里附加调试容器，相当于给运行中的Pod加个带有排查工具的"外挂"。

# 为Pod创建临时调试容器 kubectl debug <pod-name> -it --image=nicolaka/netshoot --target=<container-name> # 复制Pod并在新Pod中调试（不影响原Pod） kubectl debug <pod-name> --image=nicolaka/netshoot --copy-to=<debug-pod-name> -it

--target参数指定和哪个容器共享网络命名空间，然后就能在那个容器的网络环境下执行netstat、tcpdump、nslookup等排查命令了。netshoot这个镜像集成了大量网络排查工具，做网络问题定位很方便。如果原Pod是因为缺少依赖或库才崩溃的，用--copy-to复制一个Pod并在里面手动执行启动命令，能快速验证是不是库文件或启动参数的问题。

7. 常用命令速查表与避坑建议

系统整理了一些按场景分类的速查命令，建议截图或收藏备用。

7.1 按业务场景快速定位命令

7.2 这些坑我踩过，提前帮你避一避

写一下实际运维中容易踩的坑，省得大家重走弯路。

坑一：忘了指定命名空间，改错了生产资源

默认情况下kubectl操作的是default命名空间。如果你不在命令行里加-n参数，很可能你本意是操作A环境（某个命名空间）的资源，结果动到了B环境（default）。多次出现这种情况后，我现在每次在操作前都会习惯性地加上-n参数把命名空间显式写出来，如果确实需要频繁切换命名空间，就在kubeconfig里每个上下文绑定各自的默认namespace，切换上下文时顺带切换环境。

坑二：强行删除Pod导致数据不一致

当Pod卡在Terminating状态时，很多人的第一反应是--force --grace-period=0一把梭。但强制删除Pod是绕过K8s正常终止流程的，对无状态应用还好，对有状态应用（数据库、消息队列等）可能导致数据文件损坏或脑裂。实际的建议是：先尝试正常删除，等待一段时间（比如30秒），确认卡住的真正原因再决定是否强制；如果确实需要强删，也建议先用kubectl describe pod和kubectl get pvc -n <ns>确认存储、分布式锁等关联资源的状态，评估好风险后再操作。

坑三：滚动更新后忘记了回滚的时间窗口

kubectl rollout undo可以回滚，但如果新版本已经稳定运行了很长时间，期间又有其他变更（比如修改过配置、扩缩过容），回滚可能会把这些变更一并带回旧版本，导致"回滚后反而出现新问题"。建议在以下两种场景谨慎回滚：容器镜像升级后运行已超过数小时，期间有别的配置变更；多副本服务滚动更新期间流量有大量报错，但新版本问题已经自行缓解。回滚前先查看rollout history，确认要回滚到的版本确实是预期的稳定版本。

坑四：日志查看时忽略了--previous参数

容器崩溃后自动重启，用kubectl logs看到的是最新实例的日志，退出前打印的错误信息往往沉淀在上一个实例里。排查CrashLoopBackOff时，不加上--previous参数，看到的只是启动过程中的正常输出，真正导致崩溃的异常日志看不到，问题定位就无从谈起。现在每当看到Pod状态是CrashLoopBackOff或Error，我都会第一时间用kubectl logs <pod> --previous抓上个实例的日志，再结合describe里Last State的exit code一起分析。

坑五：误以为ConfigMap修改后Pod会自动生效

这是很多人初学K8s时的误解。ConfigMap通过volume挂载到Pod后，kubelet会把ConfigMap的内容同步到Pod的文件系统里，但进程内部已经缓存的配置不会自动刷新，很多应用也不会监听配置文件的变化。修改ConfigMap后不重启关联的Pod，新的配置不会生效，表现就是"改了半天，重启服务还是旧配置"。常规做法是修改ConfigMap后执行kubectl rollout restart滚动重启，让Pod重新挂载新配置。

坑六：用旧版本kubectl操作新集群

Kubernetes的API组在持续演进，旧版本kubectl可能不认识新集群里的某些API资源，或者默认生成的yaml字段和当前集群的schema不一致，apply时报错。解决方式很简单：用于运维的机器或跳板机上，部署和集群版本相近甚至相同版本的kubectl，或者用kubectl插件管理工具（brew、asdf、kubectx/kubens等）多版本共存，按集群切换。

7.3 快速checklist：每天巡检时跑哪几条命令

可能会想，每天到了工位打开电脑，K8s集群巡检应该先看什么？分享一套我自己的巡检习惯，按顺序跑下来基本一眼能看出集群有没有潜在风险：

# 1. 先看集群节点状态 kubectl get nodes -o wide # 2. 看有没有异常状态的Pod kubectl get pods -A | grep -vE 'Running|Completed' # 3. 看核心组件（kube-system命名空间）是否健康 kubectl get pods -n kube-system # 4. 看节点磁盘和资源压力（有metrics-server时） kubectl top nodes # 5. 看有没有大量事件堆积（快速发现异常动态） kubectl get events -A --sort-by=.lastTimestamp | tail -20 # 6. 看证书剩余时间（防止集群证书过期导致kubelet失联） openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -dates # 或者用cert-manager的证书状态 kubectl get certificates -n cert-manager

巡检的价值不在多，在于能提前摸到苗头。比如某节点磁盘使用率持续走高、某命名空间出现大量OOMKilled事件，这类零星的小异常往往是故障的前奏。把巡检变成习惯，比等告警平台爆出大问题再冲上去救火要省心得多。

8. 从命令到理解：掌握K8s操作背后的逻辑

我在刚开始接触K8s时，喜欢把命令当作记忆负担，背来背去总觉得记不住。后来逐渐意识到，kubectl的命令本身并不难，难的是对K8s设计思想的理解。命令背后对应的是对象的增删改查、状态的编排调度、组件的分工协作。

举个例子，kubectl scale看似只是改了replicas这个数字，实际上触发的是ReplicaSet的期望状态和实际状态趋向一致的调协过程。K8s的ControllerManager会持续监视，发现实际Pod数量少于期望值，就自动创建Pod；多于期望值，就自动清理多余Pod。理解了这套声明式API的逻辑，很多命令的行为就是自然而然的推演了。

同样，kubectl rollout restart做的事情不是字面上的"重启"，而是通过修改Pod模板的注解来触发一次新的滚动更新。从用户角度看效果像是重启了所有Pod，背后的本质是创建新的ReplicaSet并逐步替换旧Pod。理解了这套机制，当滚动更新过程中出现Pod启动失败、健康检查不过等情况时，自然能预判到更新会暂停还是回滚，而不必死记命令参数。

所以我的最后一条建议是：命令手册只是起点，建立起对K8s控制循环、调协机制、资源对象之间关系的整体认知，才能在遇到复杂故障时真正游刃有余。就像用手写代码不一定要背语法书，但理解了对象、类和继承关系，写起来自然顺手。K8s的学习其实同样是这个道理。

在实际使用中，我把上面这些命令按频率高低梳理成了一张自己的速查卡，高频命令（get、describe、logs、exec、apply）几乎每天都会用，中频命令（scale、rollout、label、taint）每周用几次，低频命令（debug、port-forward、cp等）在特定场景下才需要。建议同学们也按自己的业务场景做一份类似速查，用顺手的工具永远是最高效的。