这是一份 Kubernetes 日常运维的实用手册。涵盖了核心命令、故障排查思路，以及那些书本上不常写、却让你深夜加班的“坑”。希望可以给到你一个参考和方向。
必知必会的 kubectl 命令
kubectl 是 Kubernetes 的指令中枢。高效地使用它，是运维 K8s 的第一步。为了提升效率，建议将 kubectl 设置为别名 k，并安装 kubectl 的自动补全插件。
资源查看与定位
| 场景 | 命令 | 说明 |
|---|---|---|
| 查看节点状态 | kubectl get nodeskubectl get nodes -o wide | 查看所有节点状态，-o wide 显示详细信息。 |
| 查看资源 (通用) | kubectl get podskubectl get deploymentskubectl get services -n kube-system | 查看Pod、Deployment、Service等资源，支持指定命名空间 -n，或使用 -A 查看所有命名空间。 |
| 描述资源详情 | kubectl describe pod my-pod | 展示Pod的完整信息，是排查 Pod 问题的首选命令，重点关注Events字段。 |
| 监控资源变化 | kubectl get pods -w | -w 参数可实时监控资源状态变化。 |
| 查看资源清单 |
| 导出资源的完整YAML定义，便于备份或深入分析。 查看节点资源压力、Pod分布、条件 |
资源操作与管理
| 场景 | 命令 | 说明 |
|---|---|---|
| 创建/更新资源 | kubectl apply -f app.yaml | 可创建或更新资源。 |
| 编辑运行中的资源 | kubectl edit deployment <name> | 直接编辑并实时更新运行中的资源配置。 |
| 删除资源 | kubectl delete -f app.yamlkubectl delete pod <node> | 通过文件或资源名称删除。 |
| 扩缩容 | kubectl scale deployment <name> --replicas=5 | 调整Deployment的副本数量。 |
重启 Deployment |
| 滚动重启Pod，常用于应用无感知更新配置。 标记节点不可调度 恢复调度 |
Pod 内部交互与调试
| 场景 | 命令 | 说明 |
|---|---|---|
| 执行命令 | kubectl exec my-pod -- ls /kubectl exec -it my-pod -- /bin/sh | 在容器内执行命令，-it 参数可开启一个交互式 Shell。 |
| 查看日志 | kubectl logs my-podkubectl logs -f my-pod -c sidecar | 查看Pod日志，-f 实时追踪，多容器时用 -c 指定。 |
| 查看崩溃日志 | kubectl logs my-pod --previous | 关键命令！可查看因重启而丢失的上一个容器的日志，用于分析 CrashLoopBackOff。 |
| 端口转发 | kubectl port-forward pod/my-pod 8080:80 | 将本地端口映射到Pod端口，绕过Service，直达Pod内部调试。 |
集群信息与资源统计
| 场景 | 命令 | 说明 |
|---|---|---|
| 查看集群信息 | kubectl cluster-info | 查看集群的控制平面和 CoreDNS 的运行地址。 |
| 查看资源使用 | kubectl top nodeskubectl top pods | 查看节点和Pod的实时CPU和内存使用情况，需要安装 metrics-server。 |
| 查看API资源 | kubectl api-resources | 列出所有支持的API资源类型，便于查找可用资源。 |
| 查看集群事件 | kubectl get events --sort-by='.lastTimestamp' | 列出集群事件，并按时间排序，是排查全局问题的利器。 |
故障排查全链路指南
日常故障排查可以遵循一条清晰的路径：Pod → 容器 → 应用 → Service → Ingress → 存储 → Node → 网络。
第一步：定位问题范围
列出所有Pod，找出非“Running”状态的Pod：
kubectl get pods -A | grep -v Running
查看Pod详细信息和事件：
kubectl describe pod <pod-name> -n <namespace>
查看Pod的日志：
# 查看当前日志
kubectl logs <pod-name> -n <namespace>
# 如果Pod在反复重启，务必查看上一个容器的日志
kubectl logs <pod-name> -n <namespace> --previous
进入Pod内部排查：
kubectl exec -it <pod-name> -n <namespace> -- /bin/sh
第二步：检查节点健康状况
如果Pod无法调度或莫名失败，往往是节点本身出了问题。可以使用以下命令检查：
# 检查节点状态
kubectl get nodes
# 查看节点的详细情况，重点关注 'Conditions' 和 'Events'
kubectl describe node <node-name>
节点常见的NotReady状态及其原因如下：
第三步：排查资源调度异常（Pod Pending）
当Pod状态为 Pending 时，说明调度器无法将其分配到任何节点。排查时可以重点关注以下几点：
集群资源不足：describe 命令通常会显示类似 0/3 nodes are available: 1 Insufficient cpu, 2 Insufficient memory 的错误，说明节点资源不足。
节点存在污点 (Taint)：如果节点有污点，而Pod没有对应的容忍 (Toleration)，调度器会拒绝调度。
持久卷 (PVC) 未绑定：如果Pod需要挂载存储，但PVC没有成功绑定到一个PV，Pod将无法调度。检查命令为 kubectl get pvc。
CPU/内存请求 (Request) 设置不当：Pod设置的CPU或内存请求超过了集群中任何节点的剩余资源。
第四步：排查服务无法访问（服务/网络视角）
这是应用部署好后最常见的问题，可以按以下顺序排查：
确认Pod内部的“健康”状态：
# 端口转发到本地，若能访问，则应用本身无问题
kubectl port-forward pod/<pod-name> 8080:80
检查Service是否正确关联Pod：
kubectl describe service <service-name>
进入Pod内部，测试DNS解析和Service连通性：
# 进入任意一个Pod
kubectl exec -it <any-pod> -- /bin/sh
# 尝试解析Service
nslookup <service-name>
# 测试Service能否连通
curl <service-name>.<namespace>.svc.cluster.local
检查Ingress配置：
kubectl describe ingress <ingress-name>
检查网络插件状态：
kubectl get pods -n kube-system | grep -E "calico|flannel|weave"
第五步：救火三板斧
扩容：kubectl scale deployment <deploy-name> --replicas=5
重启应用：kubectl rollout restart deployment <deploy-name>
强制删除“僵尸”Pod：kubectl delete pod <pod-name> -n <namespace> --force --grace-period=0
日常运维注意事项
避免踩坑的8个经验
镜像标签要具体，别用 latest：在生产环境使用 latest 标签就像在未知海域航行，无法确定哪个版本正在运行，也无法进行可靠的版本回滚。请始终使用明确的镜像版本号。
给所有Pod设置资源配额 (Requests & Limits)：如果不设置，某个“坏邻居”Pod可能会耗尽所有节点资源，导致其他Pod“饿死”。可以同时使用 ResourceQuota 限制Namespace总用量和 LimitRange 设置每个Pod的默认值，实现双重保障。
定期备份etcd：etcd 是K8s集群的数据库，一旦损坏，集群将无法恢复。养成使用 etcdctl snapshot save 定期备份的好习惯。
安全访问，禁用 Root 用户：在容器中，应用应使用非 root 用户运行，这是最小权限原则的体现，能有效降低安全风险。
正确配置健康检查 (Probe)：利用就绪探针 (Readiness) 告诉Service何时可以发送流量，利用存活探针 (Liveness) 让K8s自动重启“假死”的应用。不要将探针做得太重（如连接数据库），以免引发连锁反应。
小心 conntrack 表耗尽：在高并发场景下，节点连接跟踪表可能会被填满，导致服务间歇性无法访问。可以从节点层优化 conntrack 设置或使用 externalTrafficPolicy: Local 来规避。
妥善处理 Pod 优雅退出：Pod 收到 SIGTERM 信号后开始关闭流程。如果应用不处理该信号而直接退出，可能导致请求中断。
日志别只靠 kubectl logs：在生产环境中，应考虑部署集中式日志系统（如 EFK/ELK/Loki），避免因容器重启导致日志丢失，并方便统一检索和分析。
快速诊断的检查清单
| 检查项 | 检查命令 (在Master节点执行) | 期望结果 |
|---|---|---|
| 节点健康状况 | kubectl get nodes | 所有节点状态为 Ready。 |
| 核心组件状态 | kubectl get pods -n kube-system | 关键Pod (如 coredns, kube-proxy, calico-node) 状态为 Running。 |
| Pod 健康状况 | kubectl get pods -A | 理想状态是所有Pod Running，无频繁重启。 |
| kubelet 服务状态 | (在问题节点执行) systemctl status kubelet | 服务处于 active (running) 状态。 |
| 容器运行时状态 | (在问题节点执行) systemctl status containerd | 服务处于 active (running) 状态。 |
| API Server 连通性 | kubectl cluster-info | 能正常输出 Master 和 CoreDNS 的地址信息。 |
| DNS 解析 | kubectl exec -it deploy/debug-tool -- nslookup kubernetes.default | 能正确解析kubernetes.default.svc.cluster.local。 |
| 控制平面证书 | kubeadm certs check-expiration | 检查证书是否即将过期。 |
| Pod 资源使用 | kubectl top pods -A | 确认各Pod的CPU和内存使用是否正常。 |
| 节点资源使用 | kubectl top nodes | 确认各节点的CPU和内存使用是否正常。 |
这份手册涵盖了K8s运维的核心骨架。不过实践出真知，
本文最后更新时间 2026-06-04
文章链接地址：https://yrajsh.cn/index.php/archives/140/
本站文章除注明[转载|引用|原文]出处外,均为本站原生内容,转载前请注明出处
