本文聚焦 线上 Kubernetes 集群日常运维 中最常见的故障场景（节点异常、Pod 调度失败、镜像拉取失败、DNS/网络问题、存储故障、控制面高负载等），给出可直接复制的排查命令、配置片段和脚本，帮助快速定位并闭环问题。
适用场景 & 前置条件（≤10 行）
| 项目 | 要求 |
|------------|------|
| 适用场景 | 日均 PV 10 万+ 的 Web/API、内部微服务、Job/CronJob 集群 |
| 平台类型 | 物理机 / 虚拟机 / 云主机 + kubeadm / 托管 K8s（ACK/GKE/EKS 等） |
| OS | RHEL/CentOS 7.9+/8.x，Ubuntu 20.04+/22.04 LTS |
| 内核 | Linux Kernel ≥ 4.18，开启 cgroup v2 建议 |
| K8s 版本 | 1.32–1.34，测试参考：1.34.1（测试于 2025-10） |
| 容器运行时 | containerd 1.7+ 或 CRI-O 1.29+ |
| 资源规格 | Master ≥ 4C8G / 100GB SSD；Node ≥ 4C8G / 100GB SSD / 千兆网卡 |
| 网络 | 放通 6443、NodePort 范围、CNI 所需端口；集群 DNS 正常 |
| 权限 | 集群管理员 kubeconfig + Node sudo/root 权限 |
| 技能要求 | [中级] 运维：熟悉 Linux、容器基础、kubectl/系统调试 |
反模式警告（何时不适用）
⚠️ **以下场景不推荐直接套用本文方案：**
1.**纯托管全封闭环境**：如完全由云厂商托管控制面且禁止登录节点，很多命令无法执行。
2.**K8s 低版本（≤1.20）**：本文命令与字段以 1.24+ 为基准，老版本存在 API 差异。
3.**实验性单机 K8s（kind/minikube）**：非生产特性，性能与网络问题不具代表性。
4.**重度多租户场景**：需要额外的安全隔离（PSP/OPA/Gatekeeper），本文不展开。
5.**严格离线 + 无镜像仓库**：镜像拉取、升级策略需单独设计，不适合直接照抄。
**替代方案对比：**
| 场景 | 推荐方案 | 理由 |
|----------------------|--------------------------------|------|
| 仅需单机容器编排 | Docker Compose / Nomad | 复杂度更低 |
| 强合规 + ITSM 流程 | 结合 CMDB/ITSM + K8s Operator | 变更全流程可审计 |
| 极简开发测试环境 | kind/minikube + 本地脚本 | 上手快、失败成本低 |
| 完全托管云 K8s | 优先参考云厂商运维指引 | 控制面问题需工单处理 |
环境与版本矩阵（表格）
| 组件 | RHEL/CentOS | Ubuntu/Debian | 测试状态 |
|-----------------|----------------------------------------|---------------------------------------|----------|
| OS 版本 | RHEL 8.6+ / CentOS 7.9+/Stream 9 | Ubuntu 20.04 / 22.04 LTS | [已实测] |
| 内核版本 | 4.18.0-425+ | 5.4.0-150+ / 5.15.0-60+ | [已实测] |
| 容器运行时 | containerd 1.7.x | containerd 1.7.x | [已实测] |
| Kubernetes | 1.32.x / 1.33.x / 1.34.x | 同左 | [理论推导] |
| etcd | 3.5.x | 3.5.x | [理论推导] |
| CNI 插件 | Calico 3.28+ / Cilium 1.15+ | Calico 3.28+ / Cilium 1.15+ | [理论推导] |
| Master 最小规格 | 4C8G / 100GB SSD / 千兆网卡 | 4C8G / 100GB SSD / 千兆网卡 | [已实测] |
| Master 推荐规格 | 8C16G / 200GB NVMe / 千兆或万兆网卡 | 8C16G / 200GB NVMe / 千兆或万兆网卡 | [理论推导] |
| Worker 最小规格 | 4C8G / 100GB SSD | 4C8G / 100GB SSD | [已实测] |
| 网卡 | 千兆，支持多队列，开启 GRO/LRO（按需） | 千兆，支持多队列，开启 GRO/LRO（按需）| [理论推导] |
版本差异说明：
- • K8s 1.32–1.34：默认弃用大量 beta API，kubectl 日志/事件格式更稳定。
- • containerd 1.6 vs 1.7：1.7 对 CRI 整合更好，镜像拉取并发与 GC 更稳定。
阅读导航（快速上手 vs 深入理解）
📖 **建议阅读路径：**
**快速上手（15 分钟）：**
→ 章节「快速清单」
→ 章节「实施步骤」中 Step 1（节点异常） + Step 2（Pod 不跑）
→ 章节「常见故障与排错」对应表格
**深入理解（45 分钟）：**
→ 章节「架构与数据流说明」
→ 章节「实施步骤」完整 Step 1–5
→ 章节「可观测性」+「变更与回滚剧本」
→ 章节「最佳实践」+「附录脚本」
**故障排查：**
→ 直接跳到「常见故障与排错」表格
→ 按问题类型转到对应 Step（节点/网络/存储/控制面）
→ 使用「变更与回滚剧本」中的备份与回滚脚本
快速清单（Checklist）
- [ ] **准备阶段**
- [ ] 确认 kubeconfig 正确，能访问集群（`kubectl cluster-info`）
- [ ] 检查所有节点状态（`kubectl get nodes -o wide`）
- [ ] 确认容器运行时与 CNI 正常（`crictl ps`、`kubectl get pods -n kube-system`）
- [ ] 为 etcd/K8s 做快照或配置备份（`etcdctl snapshot save`）
- [ ] **实施阶段（问题排查与修复）**
- [ ] 当节点 NotReady 时，按 Step 1 执行节点体检脚本
- [ ] 当 Pod 处于 Pending/ImagePullBackOff，按 Step 2 检查调度与镜像
- [ ] 当服务访问失败，按 Step 3 排查 DNS/Service/CNI
- [ ] 当 PVC 绑定失败或 IO 异常，按 Step 4 检查存储后端
- [ ] 当 apiserver 慢/etcd 压力大，按 Step 5 检查控制面性能
- [ ] **验证阶段**
- [ ] 确认关键 Deployment 状态就绪（`kubectl get deploy -A`）
- [ ] 通过探针/探活接口验证业务（`curl http://svc/healthz`）
- [ ] 监控指标恢复正常（`kube_node_status_condition` 等）
- [ ] **回滚阶段**
- [ ] 使用 `kubectl rollout undo` 回滚错误 Deployment
- [ ] 使用 `etcdctl snapshot restore` 恢复 etcd（仅在必要时）
- [ ] 回滚前后记录 `kubectl get events -A` 和变更工单 ID
实施步骤（核心内容，命令为主）
架构与数据流说明（文字描述）
系统架构（典型三层）：
客户端 → Ingress / API Gateway
↓
Kubernetes Service (ClusterIP / NodePort / LoadBalancer)
↓
kube-proxy / CNI 数据平面（iptables/ipvs/eBPF）
↓
Pod (容器组) → 应用容器 → 后端数据库 / 外部服务
↓
控制面：kube-apiserver ←→ etcd ←→ scheduler/controller-manager
关键组件：
- • kube-apiserver：所有请求入口（kubectl、控制器、kubelet）。
- • etcd：集群状态数据库。
- • scheduler：负责 Pod 调度到合适的节点。
- • controller-manager：负责副本数、节点健康、自动修复等。
- • kubelet：每个 Node 上的 Agent，负责容器生命周期。
- • CNI 插件：如 Calico/Cilium，负责 Pod 网络与网络策略。
数据流向（以一次 HTTP 请求为例）：
- 1. 客户端经 LB/Ingress 访问集群入口。
- 2. 流量被转发到 Node 上的 Service VIP（iptables/ipvs/eBPF）。
- 3. kube-proxy 或 CNI 实现负载均衡，将流量转发到后端 Pod IP。
- 4. Pod 内应用处理请求，可能访问外部 DB 或第三方 API。
- 5. Pod 状态与指标由 kubelet 汇报到 apiserver，再持久化到 etcd。
Step 1：节点 NotReady / Unknown 排查
目标： 找出 Node 状态异常的根因（kubelet / 网络 / 资源 / 证书）。
1）快速定位异常节点
# 查看节点状态
kubectl get nodes -o wide
# 查看具体原因（注意 CONDITIONS 与 taints）
kubectl describe node <node-name>
常见 COND 状态：
- •
KubeletNotReady - •
NetworkUnavailable - •
DiskPressure/MemoryPressure
2）SSH 进入节点体检（RHEL/CentOS [已实测]）：
# 检查系统版本与内核
cat /etc/redhat-release
uname -r
# 检查基础资源
free -h
df -h
top -b -n1 | head -20
# 检查 kubelet 和 containerd
systemctl status kubelet
systemctl status containerd
# 查看 kubelet 日志
journalctl -u kubelet -n 50 --no-pager
Ubuntu/Debian：
lsb_release -a
uname -r
free -h
df -h
systemctl status kubelet
systemctl status containerd
journalctl -u kubelet -n 50 --no-pager
关键检查点：
- 1. kubelet 是否在运行，有无证书/连接 apiserver 失败日志。
- 2. containerd 是否正常，是否报存储驱动或镜像 GC 错误。
- 3. 磁盘是否爆满（尤其是
/var/lib/kubelet、/var/lib/containerd）。
3）常见错误示例与处理：
# 错误1：kubelet 无法连接 apiserver
E... kubelet networkPlugins cni: failed to read CNI conf
E... kubelet failed to run Kubelet: failed to create kubelet: misconfiguration: kubelet cgroup driver
# 快速修复示例：
# - 检查 /etc/kubernetes/kubelet.conf apiserver 地址是否可达
# - 确认 CNI 配置存在：/etc/cni/net.d/*.conf
# 错误2：磁盘压力
NodeHasDiskPressure True
# 快速修复：
du -sh /var/lib/containerd /var/lib/kubelet /var/log
# 清理无用镜像与日志（谨慎执行）
crictl images
crictl rmi <unused-image-id>
4）执行后验证：
# 重启 kubelet/containerd 后
systemctl restart containerd
systemctl restart kubelet
watch -n 3 'kubectl get nodes'
# 预期：节点状态从 NotReady → Ready
幂等性与回滚：
- • 重启服务属于幂等操作，但清理磁盘前必须做目录大小记录：
du -sh /var/lib/containerd > /tmp/containerd.size.before
du -sh /var/lib/containerd >> /tmp/containerd.size.after
Step 2：Pod Pending / Unschedulable / ImagePullBackOff
目标： 解决 Pod 无法调度或镜像拉取失败。
1）快速列出异常 Pod
kubectl get pods -A \
--field-selector=status.phase!=Running,status.phase!=Succeeded
查看详细事件：
kubectl describe pod <pod-name> -n <ns> | sed -n '/Events/,$p'
2）调度失败（Pending + 0/xx nodes are available）
常见原因：CPU/内存不足、节点污点、亲和性约束。
# 查看 Deployment/StatefulSet 的资源与调度约束
kubectl get deploy <deploy> -n <ns> -o yaml | grep -A5 'resources:\|affinity:\|tolerations:'
# 查看节点资源
kubectl describe node <node-name> | grep -A5 'Allocatable'
典型错误示例：
0/5 nodes are available: 5 Insufficient cpu.
0/5 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate.
修复思路：
- • 降低 Pod requests 或扩容节点；
- • 增加
tolerations或去掉无意义的污点。
示例 Patch 命令（降低 CPU request）：
kubectl patch deploy <deploy> -n <ns> \
--type='json' \
-p='[{"op":"replace","path":"/spec/template/spec/containers/0/resources/requests/cpu","value":"100m"}]'
3）ImagePullBackOff / ErrImagePull
kubectl describe pod <pod-name> -n <ns> | sed -n '/Events/,$p'
常见消息：
- •
Error: ErrImagePull - •
rpc error: code = Unknown desc = failed to resolve image "xxx": failed to do request - •
pull access denied, repository does not exist or may require 'docker login'
排查步骤：
# 在节点上测试镜像拉取（以 containerd 为例）
crictl pull registry.example.com/ns/app:1.0.0
# 检查镜像仓库证书/登录信息
ls /etc/containerd/certs.d
cat /etc/containerd/config.toml | grep -A3 'registry.example.com'
修复示例：添加 ImagePullSecret
# secret.yaml
apiVersion:v1
kind:Secret
metadata:
name:regcred
namespace:myns
type:kubernetes.io/dockerconfigjson
data:
.dockerconfigjson:<base64>
kubectl apply -f secret.yaml
# 关联到 Deployment
kubectl patch deploy app -n myns \
--type merge \
-p '{"spec":{"template":{"spec":{"imagePullSecrets":[{"name":"regcred"}]}}}}'
Step 3：Service 访问异常 / DNS 解析失败 / CNI 故障
目标： 当“集群内 Pod 访问 Service/DNS 异常”时快速定位。
1）DNS 基础检查
# 查看 CoreDNS 状态
kubectl get pods -n kube-system -l k8s-app=kube-dns -o wide
kubectl logs -n kube-system -l k8s-app=kube-dns --tail=50
# 在业务 Pod 内部测试 DNS
kubectl exec -it <pod> -n <ns> -- nslookup kubernetes.default
kubectl exec -it <pod> -n <ns> -- curl -I http://kubernetes.default
常见错误：
;; connection timed out; no servers could be reached
检查 kube-dns Service 与 Endpoints：
kubectl get svc -n kube-system kube-dns -o wide
kubectl get endpoints -n kube-system kube-dns -o wide
2）Service / Pod IP 联通性检查
# 检查 Service 与对应的 endpoints
kubectl get svc -n <ns> app-svc -o wide
kubectl get endpoints -n <ns> app-svc -o wide
# 在同 Node Pod 内 ping 对端 Pod IP（注意部分 CNI 禁止 ICMP）
kubectl exec -it <pod> -n <ns> -- ping -c 3 <peer-pod-ip>
CNI 基础信息：
# 节点上检查 CNI 配置与网桥
ls /etc/cni/net.d
ip addr show cni0
ip addr show flannel.1 # 如使用 flannel
典型错误示例：
# CNI 配置缺失
E... kubelet cniConfigPath /etc/cni/net.d: no networks found
# 修复：重新安装/生成 CNI 配置（如重新 kubectl apply calico.yaml）
Step 4：PVC Pending / 存储性能问题
目标： 当持久化存储无法绑定或 IO 异常时快速定位。
# 列出所有 PVC 状态
kubectl get pvc -A
# 查看某个 PVC 详情事件
kubectl describe pvc <pvc-name> -n <ns>
常见事件：
- •
waiting for first consumer to be created before binding - •
failed to provision volume with StorageClass "xxx"
典型 StorageClass 示例（CSI）：
apiVersion:storage.k8s.io/v1
kind:StorageClass
metadata:
name:fast-ssd
provisioner:csi.example.com
parameters:
type:ssd
reclaimPolicy:Delete
volumeBindingMode:WaitForFirstConsumer
Kubelet 节点侧检查：
# 查看挂载情况
mount | grep kubernetes.io
df -h | grep -E 'kubelet|containers'
# 查看存储相关日志
journalctl -u kubelet -n 100 | grep -i 'volume\|csi'
错误示例：
MountVolume.MountDevice failed for volume "pvc-xxx": rpc error: code = Internal desc = failed to format volume
快速修复：根据存储后端（NFS/CEPH/云盘）检查对应系统日志，并配合存储团队处理。
Step 5：控制面高延迟 / etcd 压力过高
目标： apiserver/QPS 过高、etcd 慢导致整个集群“卡顿”。
1）apiserver 状态检查
kubectl get --raw '/metrics' | grep apiserver_request_total | head
# 使用 kubectl top 查看控制面资源
kubectl top pods -n kube-system | grep kube-apiserver
2）etcd 健康与延迟（在 Master 上执行）：
export ETCDCTL_API=3
etcdctl --endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key endpoint status -w table
关注 DB Size 与 Avg/Max Latency 字段。
etcd 快照备份脚本示例（[理论推导]）：
#!/bin/bash
# /opt/scripts/etcd_snapshot.sh
set -e
TS=$(date +%Y%m%d_%H%M%S)
BACKUP_DIR="/backup/etcd"
mkdir -p "${BACKUP_DIR}"
export ETCDCTL_API=3
etcdctl --endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
snapshot save "${BACKUP_DIR}/snapshot-${TS}.db"
# 保留最近 7 份
ls -1t ${BACKUP_DIR}/snapshot-*.db | tail -n +8 | xargs -r rm -f
最小必要原理（≤200 字）
- • Kubernetes 是“声明式 + 控制循环”系统： 你只定义目标状态（YAML），控制器不断对比实际状态并调和。
- • 绝大部分“故障”本质是：控制循环无法完成调和（调度失败、容器起不来、网络不通、存储挂不上）。
- • 运维排查应围绕三个问题： 1）期望状态是什么？（Deployment/StatefulSet 定义） 2）当前状态到哪一步失败？（Events / 状态字段） 3）是哪一层组件阻断了调和？（调度 → 容器运行时 → 网络 → 存储 → 控制面）。
- • 因此，本质方法是：从外到内、从高层对象到底层组件，顺着“调和路径”查一遍。
可观测性（监控 + 告警 + 性能）
监控指标（Prometheus）
推荐监控项：
- kube_node_status_condition{condition="Ready"}
- kube_pod_container_status_restarts_total
- kube_deployment_status_replicas_unavailable
- node_filesystem_avail_bytes
- apiserver_request_duration_seconds_bucket
- etcd_disk_wal_fsync_duration_seconds_bucket
Prometheus 告警规则示例：
groups:
-name:k8s-ops-alerts
rules:
-alert:K8sNodeNotReady
expr:kube_node_status_condition{condition="Ready",status="true"}==0
for:5m
labels:
severity:critical
annotations:
summary:"Node NotReady"
description:"节点 {{ $labels.node }} 5 分钟处于 NotReady 状态"
-alert:PodCrashLooping
expr:increase(kube_pod_container_status_restarts_total[10m])>5
for:5m
labels:
severity:warning
annotations:
summary:"容器频繁重启"
description:"Pod {{ $labels.pod }} 在 10 分钟内重启次数 > 5"
-alert:ApiServerHighLatency
expr:histogram_quantile(0.95,sum(rate(apiserver_request_duration_seconds_bucket[5m]))by(le,verb))>0.5
for:10m
labels:
severity:warning
annotations:
summary:"apiserver 95 分位延迟过高"
description:"请检查控制面资源与大流量调用（如 list/watch）"
Grafana 面板（简化 JSON 片段）
{
"panels":[
{
"title":"节点就绪状态",
"type":"stat",
"targets":[
{"expr":"sum(kube_node_status_condition{condition=\"Ready\",status=\"true\"})"}
]
},
{
"title":"Pod 重启次数 Top N",
"type":"table",
"targets":[
{
"expr":"topk(10, kube_pod_container_status_restarts_total)",
"format":"table"
}
]
}
]
}
性能基线建议（[理论推导]）
- • 中小集群（<200 节点）在稳定状态：
- • apiserver p95 延迟 < 300ms；
- • etcd DB size 控制在 8–16GB；
- • 节点 CPU 使用率长期 < 70%。
常见故障与排错
| 症状 | 诊断命令 | 可能根因 | 快速修复 | 永久修复 |
|--------------------------------------|----------------------------------------------------|--------------------------------------------------------|----------------------------------------------------|---------------------------------------------------|
| Node NotReady / Unknown | `kubectl describe node` | kubelet 停止、containerd 异常、CNI 配置缺失、磁盘爆满 | 重启服务、清理磁盘、修复 CNI | 纳入监控和容量规划，初始化脚本标准化 |
| Pod 长期 Pending | `kubectl describe pod` | 资源不足、污点/亲和/配额限制 | 临时扩容节点/降低 request | 建立资源配额与 HPA，容量评估流程 |
| ImagePullBackOff | `kubectl describe pod` / `crictl pull` | 仓库不可达、认证失败、镜像不存在 | 配置 ImagePullSecret，修正镜像地址 | 标准化镜像命名与制品库流程 |
| 集群内部域名解析失败 | `kubectl logs -n kube-system -l k8s-app=kube-dns` | CoreDNS Pod 异常 / IPTables 问题 / 上游 DNS 挂了 | 重启 CoreDNS，修复 IPTables 与上游 DNS | 为 DNS 建立专用监控和备用上游 |
| PVC 一直 Pending / Volume 挂载失败 | `kubectl describe pvc/pod`，`journalctl -u kubelet`| StorageClass 配置错误，后端存储故障 | 与存储侧核对配置，重新创建 PVC | 统一存储策略与命名，定期演练挂载/故障恢复 |
| apiserver 响应慢 / 集群“卡顿” | `/metrics`、`kubectl top pods -n kube-system` | 大量 list/watch、etcd IO 瓶颈、Master 资源不足 | 限制大对象 watch，扩容控制面，优化 etcd 存储 | 设计多 Master，高性能盘，规范客户端访问模式 |
调试思路（通用流程）：
1）确认影响范围：单 Namespace / 全集群？单 Node / 多 Node？
2）从 kubectl 对象状态入手：get/describe/events。
3）定位到具体组件：kubelet / CNI / 容器运行时 / etcd / apiserver。
4）结合节点系统日志（journalctl）与应用日志交叉验证。
5）最后确认最近一次变更（Git/CI/CD/手工）是否相关。
变更与回滚剧本
应用层变更与回滚
滚动升级 Deployment（[已实测]）：
# 查看 rollout 进度
kubectl rollout status deploy app -n myns
# 查看历史版本
kubectl rollout history deploy app -n myns
# 回滚到上一个版本
kubectl rollout undo deploy app -n myns
# 回滚到指定版本
kubectl rollout undo deploy app -n myns --to-revision=3
变更前后检查清单：
# 变更前
kubectl get pods -n myns -l app=foo
kubectl get events -n myns --sort-by='.lastTimestamp' | tail
# 变更后
kubectl get pods -n myns -l app=foo
kubectl logs deploy/app -n myns --tail=20
集群升级与回滚（kubeadm 示例）
强制前提： 已有 etcd 快照与 kubeconfig 备份。
查看可用版本：
kubeadm version
apt/yum list kubeadm --showduplicates | grep 1.34
升级控制面示例：
# 1. 升级 kubeadm
apt-get install -y kubeadm=1.34.x-00 # Ubuntu
yum install -y kubeadm-1.34.* # RHEL/CentOS
# 2. 规划升级
kubeadm upgrade plan
# 3. 执行升级
kubeadm upgrade apply v1.34.x
Node 升级：
kubectl drain <node> --ignore-daemonsets --delete-emptydir-data
# 升级 kubelet/kubectl 后
kubectl uncordon <node>
回滚策略：
- • 若升级后控制面无法正常工作，使用 etcd 快照 + 旧版本二进制恢复。
- • 对 Node，原则上可通过重新加入集群：
kubeadm reset -f
kubeadm join <master>:6443 --token ... --discovery-token-ca-cert-hash ...
（此步骤一定要有文档和脚本，不要纯手工操作。）
最佳实践（决策性要点）
- 1. 所有 YAML 进 Git，不在集群直接 kubectl edit
- • 使用 GitOps（Argo CD / Flux）或至少通过 CI/CD 下发。
2. 默认开启资源限制与 HPA
resources:
requests:
cpu:"100m"
memory:"256Mi"
limits:
cpu:"1"
memory:"512Mi"
- 3. 为核心组件单独节点与污点
kubectl taint nodes master1 node-role.kubernetes.io/master=:NoSchedule
- 4. 统一日志收集与审计
- • Pod 标准输出统一收集到 Loki/ELK；
- • kube-apiserver 审计日志开启并有限保留时间。
- 5. 明确“变更窗口 + 冻结期”
- • 高风险操作（升级 K8s/CNI/存储）仅在低峰期进行；
- • 雪季/大促前严格冻结基础设施层变更。
FAQ（常见问题）
Q1：集群里各种组件版本要怎么选？A：保持控制面与 Node 在同一 minor 版本（如都在 1.34.x），且不超过官方支持窗口（最近三版）。
Q2：出现问题时，先看 kubectl 还是先上节点？A：优先看 kubectl get/describe/events，从“声明式对象”出发；确认是全局/局部问题，再决定是否登录节点排查。
Q3：CrashLoopBackOff 一直重启，该怎么办？A： 1）查看容器日志 kubectl logs； 2）如启动即挂，使用 kubectl logs --previous； 3）必要时用 kubectl debug 加 sidecar 或临时容器深入排查。
Q4：Service IP 与 Pod IP 冲突会不会影响外网？A：K8s 集群一般使用虚拟网段（如 10.96.0.0/12, 10.244.0.0/16），不应与物理网段重叠；如重叠可能导致路由混乱，应在规划阶段避免。
Q5：是否必须用 Ingress 才算“云原生”？A：不是。NodePort/LoadBalancer 也可以，但 Ingress/网关更适合统一流量控制与证书管理。
Q6：托管 K8s 还需要运维吗？A：需要，只是从“机器层运维”变成“配置/资源/成本运维”，例如：Pod 资源配额、命名空间隔离、Ingress/网关策略等。
附录：节点体检脚本 & 集群快速自检
节点体检脚本（Node Health Check）
#!/bin/bash
# /opt/scripts/k8s_node_healthcheck.sh
NODE=$(hostname)
echo"== Node: ${NODE} =="
echo"[1] 基础信息"
uname -a
echo
echo"[2] 资源情况"
free -h
df -h | grep -E 'Filesystem|/var|/tmp|/root'
echo
echo"[3] kubelet/containerd 状态"
systemctl is-active kubelet containerd
systemctl status kubelet --no-pager -n 5 | sed -n '1,15p'
echo
echo"[4] CNI & IP 信息"
ip addr show | grep -E 'cni|flannel|calico' -n || echo"No CNI iface found"
ls /etc/cni/net.d || echo"No CNI config"
echo
echo"[5] 最近错误日志（kubelet）"
journalctl -u kubelet -p err -n 10 --no-pager || true
定时运行（如每小时）并输出到本地日志，出现问题时方便回溯。
集群快速自检脚本（kubectl 版）
#!/bin/bash
# /opt/scripts/k8s_quick_check.sh
set -e
echo"== 集群信息 =="
kubectl cluster-info
echo
echo"== 节点状态 =="
kubectl get nodes -o wide
echo
echo"== 核心系统 Pod 状态（kube-system） =="
kubectl get pods -n kube-system -o wide
echo
echo"== 异常 Pod（非 Running/Succeeded） =="
kubectl get pods -A \
--field-selector=status.phase!=Running,status.phase!=Succeeded || true
echo
echo"== 最近 50 条集群事件 =="
kubectl get events -A --sort-by='.lastTimestamp' | tail -50
将以上脚本纳入 Git 管理，并在每次集群变更前后执行，可以极大提升“可回溯性”和“故障定位速度”。
扩展阅读
- • Kubernetes 官方发行版本与支持策略（中文）：发行版本与历史说明
- • Kubernetes 下载与版本选择指导（英文/中文）：组件下载与校验
- • 官方 Kubernetes 文档首页与任务指南（中文）：任务 → 管理集群与排错
建议新成员从“官方任务文档 + 本文脚本”开始实操，把常见问题真正跑一遍，会比只看文档更快形成肌肉记忆。
文末福利
网络监控是保障网络系统和数据安全的重要手段，能够帮助运维人员及时发现并应对各种问题，及时发现并解决，从而确保网络的顺畅运行。
谢谢一路支持，给大家分享6款开源免费的网络监控工具，并准备了对应的资料文档，建议运维工程师收藏（文末一键领取）。
备注：【监控合集】
100%免费领取
一、zabbix
二、Prometheus
内容较多，6款常用网络监控工具（zabbix、Prometheus、Cacti、Grafana、OpenNMS、Nagios）不再一一介绍， 需要的朋友扫码备注【监控合集】，即可100%免费领取。
以上所有资料获取请扫码
备注：【监控合集】
100%免费领取
（后台不再回复，扫码一键领取）
本文链接：https://www.yunweipai.com/47726.html
网友评论comments