K8s 场景面试题（一） | SiRius的夜星记

这是一份 K8s 模拟面试的问答汇总，涵盖集群管理、网络、调度、高可用等核心知识点。

Pod 如果一直 CrashLoopBackOff

Pod 处于 CrashLoopBackOff 状态表示容器不断崩溃并被重启。

常见原因：

应用启动失败（端口被占用、配置文件错误、依赖服务不可达）
OOMKilled（内存限制过低）
健康检查失败（liveness/readiness probe 配置不当）
权限问题（缺少必要的卷挂载或 RBAC 权限）

排查步骤：

kubectl get pod <pod-name> -n <namespace>
kubectl describe pod <pod-name> -n <namespace>
kubectl logs <pod-name> -n <namespace> --previous

集群 etcd 挂掉了，节点上 Pod 能运行吗

节点上已运行的 Pod 不会立即被 kill，但集群管理功能会瘫痪。

功能	状态
已运行的 Pod	继续运行（kubelet 独立工作）
新 Pod 调度	❌ 失败（API Server 不可用）
创建/删除资源	❌ 失败
节点心跳	❌ 无法上报，节点会变 `Unknown`

类比： etcd 像是 K8s 的"大脑"。大脑停了，已有的动作会继续执行，但无法做新的决策。

API Server 挂掉了会影响 Pod 运行吗

不影响已运行 Pod 的执行，但会影响 Pod 的生命周期管理。

操作	是否受影响
已有 Pod 运行	✅ 不影响（kubelet 直接通信）
新 Pod 调度	❌ 失败
kubectl 操作	❌ 全部失败
Pod 日志查看	❌ 失败
exec 进入容器	❌ 失败
HPA 自动扩缩容	❌ 失败

原理： kubelet 通过 kubelet → API Server 单向通信上报状态、获取 Pod Spec。Pod 运行时 kubelet 已经拿到了完整的 Pod 定义，不依赖 API Server 继续通信。

面试追问：

kubelet 挂了 → 节点上所有 Pod 会进入 Unknown 状态，最终被驱逐
controller manager 挂了 → 不会影响已有 Pod，但 Deployment 等控制器无法工作
scheduler 挂了 → 只影响新 Pod 调度，已有 Pod 不受影响

MySQL 突发性慢查询，CPU 飙升，怎么快速止血

第一步：先止损，不动数据库

切换读流量到从库（如果有读写分离）
开启缓存兜底（Redis 挡住重复查询）
限流/熔断（把入口流量降下来）

第二步：识别慢查询（只读不操作）

SELECT id, user, host, command, time, state, LEFT(info, 100) AS query
FROM information_schema.processlist
WHERE command != 'Sleep'
ORDER BY time DESC LIMIT 20;

第三步：确认是否需要紧急 Kill

涉及核心业务流程（支付、订单）→ 不 Kill，等流量自然消退
纯后台报表、ETL → 可以 Kill

生产环境原则：能加机器解决的不改配置，能限流解决的不 Kill 查询。

生产环境中发生 OOM 怎么处理

系统层面 OOM（Linux 进程被 Kill）：

# 查看 oom killer 杀的是谁
dmesg -T | grep -i "out of memory"
 
# 释放缓存
sync && echo 3 > /proc/sys/vm/drop_caches
 
# 防止进程被 OOM Killer 杀掉
echo -1000 > /proc/<pid>/oom_score_adj

K8s Pod OOM：

kubectl describe pod 的 Last State 显示 OOMKilled
解决：增大 resources.limits.memory 或调整 JVM 堆外内存参数

Kubelet 坏掉会有什么影响

Kubelet 是节点上的 Agent，坏了 = 节点上所有 Pod 失控。

功能	状态
节点上已有 Pod	❌ kubelet 无法管理，状态停滞
Pod 心跳上报	❌ 停止，节点变 `NotReady`
新 Pod 调度到该节点	❌ 失败，Pod 一直 Pending
容器运行时	✅ 不受 kubelet 影响，仍在运行

最危险的情况： Pod 实际活着，但 K8s 认为它死了 → 可能被双倍调度到其他节点 → 数据损坏。

最优解是重启 kubelet，而不是等控制器重建。

为什么节点 NotReady 后会创建新 Pod

核心：ReplicaSet 控制器看的不是 Pod 状态，是节点状态。

控制器判断逻辑（伪代码）：

for each pod:
    if pod.owner != me:
        continue
    if pod.node == "node-1" AND node(node-1).status == NotReady:
        # 节点 NotReady 了，就认为这个 Pod 死了
        healthy_pods.remove(pod)

ReplicaSet 控制器不是看 etcd 里 Pod 的 phase，而是：

这个 Pod 归我管吗（ownerReference）
它所在的节点还 Ready 吗

节点 NotReady 后，NodeController 认定节点上的 Pod 都被驱逐了（不管真假），直接创建新 Pod 补上。

Pod 访问不通怎么排查

按层次逐层定位：

Pod 内部能否解析 DNS → nslookup kubernetes.default
同节点 vs 跨节点 → CNI 插件是否正常
Service 访问 vs Pod 直接访问 → kube-proxy 是否正常

常见问题：

现象	可能原因
`curl http://pod-ip` 不通	Pod 本身没监听端口或崩溃了
Pod 内 `ping` 不通	CNI 插件故障、网络策略阻挡
DNS 解析失败	CoreDNS 异常、kubelet DNS 配置错误
Service 访问不通	Endpoints 为空、kube-proxy 异常
跨节点不通	CNI 插件故障、安全组/防火墙阻挡

K8s 整个网络链路是什么样的

Pod 到 Pod（同节点）：

Pod A eth0 → veth-pair → cbr0 桥接 → veth-pair → Pod B eth0

Pod 到 Pod（跨节点）：

Overlay 模式（Flannel/Calico IPIP）：包通过 TUN 设备封装，到目标宿主机解封装
Underlay 模式（Calico BGP/Host GW）：通过路由表直接路由

Pod 到 Service：

Service 的 IP 是虚拟的，kube-proxy 在每个节点维护 iptables/ipvs 转发规则（DNAT 把 Service IP 换成真实 Pod IP）。

记住：Service IP 是假的，靠 kube-proxy 转换。Pod IP 是真的，靠 CNI 直连。

调度比较慢是什么原因

调度流程： Pod 创建 → Filter（过滤）→ Score（打分）→ Bind（绑定）

常见原因：

阶段	原因
Filter	资源不足、端口冲突、亲和性不满足、污点不匹配
Score	节点太多（1000+ 节点打分耗时长）
Volume	PVC 动态创建慢（云盘挂载秒级到分钟级）
调度器自身	单进程，队列积压时处理不过来
外部依赖	etcd 慢 → API Server 慢 → 调度器慢

快速定位口诀： Pod Pending 调度慢？先看 Events，再看资源，再查 Volume，最后看调度器日志。

10 个节点做 K8s 集群怎么保证高可用

控制平面（3 节点）：

etcd 集群：3 节点独立部署，任意 1 台宕机不影响
API Server：无状态，多副本，前置 LB
Scheduler/Controller Manager：leader 选举，热备

数据平面：

Pod 多副本 + 反亲和性（打散到不同节点）
CNI 插件选型：Calico > Flannel（故障域更小）
节点分布在 3 个可用区（AZ），任意 1 个 AZ 全挂还有 7 节点

推荐部署：

控制平面（3 个专用节点）：
  node-1: etcd + API Server + CM + Scheduler
  node-2: etcd + API Server + CM + Scheduler
  node-3: etcd + API Server + CM + Scheduler
 
数据平面（7 个工作节点）：
  node-4, node-5, node-6  → AZ1
  node-7, node-8, node-9   → AZ2
  node-10                  → AZ3

Keepalived + HAProxy 实现 API Server 高可用

架构：

                    VIP (192.168.1.100)
                         │
              ┌──────────┴──────────┐
              │      HAProxy        │
              │   (VIP 监听 6443)   │
              └──────────┬──────────┘
                         │
        ┌────────────────┼────────────────┐
   ┌────▼────┐      ┌────▼────┐      ┌────▼────┐
   │ Master1 │      │ Master2 │      │ Master3 │
   │API Server│     │API Server│     │API Server│

Keepalived 负责 VIP 漂移： Master1 为主持有 VIP，Master2/Master3 为备。主挂了，VIP 自动飘到优先级最高的备机（秒级）。

HAProxy 负责负载均衡： 把 VIP 上的请求负载到三台 API Server，支持健康检查。

客户端连接 VIP 不变，HAProxy 切换对 kubectl 完全透明。

Prometheus 和 Zabbix 混用

两者定位不同：

维度	Prometheus	Zabbix
出身	云原生（K8s 生态）	传统运维（主机/网络设备）
擅长	K8s、应用层指标	主机、网络、硬件
数据模型	拉模式（Pull）	推/拉混合

实际分工：

Zabbix： 服务器硬件（IPMI/BMC）、网络设备（交换机/路由器）、存储、传统中间件（WebLogic、Oracle）
Prometheus： K8s 集群（kube-state-metrics、node-exporter）、Spring Boot/Go 应用、Nginx/Ingress、数据库 Exporter

告警统一收敛： 两个系统的告警都接入同一套 AlertManager，或 Zabbix 告警通过 webhook 转发到钉钉/飞书。

这些题目涵盖了 K8s 面试中最核心的知识点：集群组件协作、网络原理、调度机制、高可用设计。建议在理解原理的基础上记忆，重点掌握组件间的协作关系和数据流向。