容器运维常用命令清单：简化集群排查步骤

发布人：发布时间：6 天前阅读量：56

为什么需要一份容器运维命令清单

容器化环境中的故障排查，往往不是缺少工具，而是工具太多、命令太长、上下文太散。集群出现异常时，运维人员需要在节点、容器运行时、编排系统、网络与存储之间来回切换，如果每次都临时查文档，排查效率会明显下降。整理一份按场景分类的容器运维常用命令清单，可以把重复性的操作固化为可复用的步骤，让排查从“想到哪查到哪”变成“按顺序逐层确认”。

需要说明的是，不同发行版、不同容器运行时和不同编排版本的命令输出可能存在差异。下文列出的命令以通用用法为主，实际执行前建议先在测试环境确认参数含义，避免在生产环境误操作。

集群排查的总体思路

容器集群的问题通常可以按层次拆解：先确认集群控制面是否正常，再确认节点状态，然后定位到具体工作负载，最后进入容器内部查看进程、日志与网络。按照“由外到内、由整体到局部”的顺序排查，可以避免一开始就陷入单个容器的细节。

确认集群整体状态：控制面组件、节点数量、命名空间是否正常。
确认节点状态：节点是否就绪、资源是否紧张、运行时是否异常。
确认工作负载状态：Pod 是否处于 Running、是否有重启、调度是否失败。
查看事件与日志：通过事件和容器日志定位报错原因。
进入容器与网络排查：检查进程、端口、DNS、连通性。

集群与节点层面的常用命令

查看集群信息

kubectl cluster-info：查看集群控制面地址与核心服务信息。
kubectl get nodes -o wide：查看节点名称、状态、IP、版本与运行时。
kubectl get namespaces：查看命名空间列表，确认资源所属范围。
kubectl version --short：查看客户端与服务端版本，排查版本兼容问题。

查看节点详情与资源

kubectl describe node ：查看节点状态、污点、事件与资源分配情况。
kubectl top nodes：查看节点 CPU 与内存使用量，需要指标服务支持。
kubectl cordon ：将节点标记为不可调度，便于维护。
kubectl drain --ignore-daemonsets：驱逐节点上的工作负载，执行前需确认业务影响。

在节点内部，可以结合系统工具查看容器运行时与 kubelet 状态。例如使用 systemctl status kubelet 查看服务状态，使用 journalctl -u kubelet -f 跟踪日志。如果使用容器运行时提供的命令行工具，也可以通过其状态查询命令确认运行时是否正常响应。

工作负载与 Pod 排查命令

查看资源状态

kubectl get pods -A -o wide：查看所有命名空间的 Pod 及其所在节点。
kubectl get pods -n --field-selector status.phase!=Running：筛选非 Running 状态的 Pod。
kubectl get deployments,statefulsets,daemonsets -n ：查看控制器状态与副本数。
kubectl get events -n --sort-by=.lastTimestamp：按时间排序查看事件。

查看详情与日志

kubectl describe pod -n ：查看调度结果、容器状态、重启原因与事件。
kubectl logs -n --tail=200：查看容器最近日志。
kubectl logs -n -c ：多容器 Pod 指定容器查看日志。
kubectl logs -n --previous：查看上一次容器实例的日志，适合排查崩溃重启。
kubectl logs -f -n ：实时跟踪日志输出。

进入容器与执行命令

kubectl exec -it -n -- sh：进入容器交互式排查。
kubectl exec -n -- env：查看容器环境变量。
kubectl exec -n -- ps aux：查看容器内进程。
kubectl cp /:/path/file ./file：从容器复制文件到本地，需注意容器内是否包含对应工具。

网络与配置排查命令

网络问题通常表现为服务不可达、DNS 解析失败或连接超时。排查时先确认 Service 与 Endpoints 是否正常，再检查容器内网络配置。

kubectl get svc,endpoints -n ：确认服务与后端端点是否匹配。
kubectl describe svc -n ：查看服务端口、选择器与事件。
kubectl get networkpolicy -n ：查看网络策略是否限制了流量。
容器内使用 nslookup 或 getent hosts 检查 DNS 解析。
容器内使用 curl、wget 或 nc 测试目标地址与端口连通性。

如果容器镜像较为精简，可能不包含上述工具，可以借助临时调试容器或具备网络工具的诊断镜像进行排查，但应遵守集群的安全与合规要求。

把命令清单变成排查步骤

命令本身并不等于流程。更有效的做法是把常用命令组织成固定的排查路径，例如：收到告警后，先用 kubectl get pods -A -o wide 定位异常工作负载，再用 kubectl describe pod 查看事件，随后用 kubectl logs 查看应用报错，最后按需进入容器验证网络与进程。每一步都记录关键输出，便于复盘与交接。

对于高频场景，可以进一步把命令整理成内部文档或脚本片段，例如“Pod 重启排查”“服务不可达排查”“节点 NotReady 排查”。这些清单不需要追求大而全，而是要覆盖团队最常见的问题，并明确每步的预期结果与下一步动作。