K8S集群手动巡检

检查顺序：HAProxy+Keepalived → K8s 集群状态 → 全部 Pod 状态

你的架构：keepalived‑haproxy 作为 k8s apiserver 前端 VIP 10.10.6.100

第一部分：检查 Keepalived + HAProxy（在两台 lb 节点上面执行，不是 k8s master）

1、keepalived 检查

复制代码

#查看服务状态
systemctl status keepalived
#查看日志
journalctl -u keepalived -f

#看VIP是否绑定在网卡上（确认哪台是MASTER）
ip a
#看是否出现 10.10.6.100 这个IP，在哪台机器出现，这台就是当前主LB

正常：只有一台 LB 节点上存在 VIP (10.10.6.100)；另一台没有 VIP，处于 BACKUP。如果两台同时出现 VIP＝脑裂！故障。

2、haproxy 检查

复制代码

systemctl status haproxy
#查看haproxy的统计页面（默认配置的socket）
echo "show stat" | socat /var/lib/haproxy/stats stdio

重点看后端 apiserver 三个 master 节点状态，后端状态应该是 UP，不要是 DOWN。

简易验证 apiserver 通过 VIP 连通性（任意一台机器执行）

复制代码

curl -k https://10.10.6.100:6443/healthz

✅返回 ok → 通过 VIP 访问 apiserver 正常； ❌超时、拒绝连接，说明 LB 层故障，k8s 集群上层就会异常。

第二部分：判断 K8s 集群是否正常（在 k8s 的 master 管理节点执行）

复制代码

#1 查看node节点状态，全部Ready
kubectl get nodes

#2 查看control‑plane静态pod（k8s内部管控组件）
kubectl get pod -n kube-system
#核心组件：etcd、kube‑apiserver、kube‑controller‑manager、kube‑scheduler、coredns、calico(网络插件)
#这些pod全部需要Running；不要CrashLoopBackOff

#3 集群健康检查命令
kubectl get cs
#旧版本可以，新版k8s已经废弃get cs；改用下面健康访问
curl -k https://127.0.0.1:6443/healthz

额外验证：

复制代码

kubectl api-resources

能够正常输出资源列表，没有超时，代表 apiserver 服务整体正常。

第三部分：查看集群下所有命名空间全部 pod 状态

复制代码

#查看集群所有pod，所有ns，输出wide看节点
kubectl get pods -A -o wide

过滤异常 pod（筛选不是 Running 状态）

复制代码

kubectl get pods -A | grep -v Running

只要出现：ImagePullBackOff、CrashLoopBackOff、ContainerCreating、Error，都属于异常 pod，需要 describe 排查。

📋完整的排查顺序逻辑（运维流程）

先 LB 层：keepalived（VIP）→ haproxy 后端 → curl VIP:6443/healthz

如果 LB 异常，后面 kubectl 全部会超时报错！很多人直接查 k8spod，忽略前端负载均衡，踩坑。

再 K8s 集群层：node 状态、kube‑system 里面控制平面 pod、网络插件 calico、coredns
最后业务层：查看全部 namespace 下所有 pod（ingress‑nginx、harbor 等业务 pod）

📝面试简答记忆

先检查 keepalived 确认 VIP 归属无脑裂；检查 haproxy 后端 apiserver 节点状态；使用 curl 访问 apiserver‑VIP 的 /healthz 接口确认 LB 链路。
检查 k8s 集群：kubectl get nodes确认所有节点 Ready；查看 kube‑system 下控制平面与网络插件 pod；验证 apiserver api 访问。
最后查看集群全部 Pod：kubectl get pods -A，过滤非 Running 的异常 Pod。