k8s面试题-20260515

2026-05-15 即将失业了写一写面试题 （有大佬看上我话联系我，广州）

字节外包面试 记录：

k8s中探针有哪些？分别是什么作用？

1. Liveness Probe（存活探针）
   作用：判断容器是否处于“存活状态”
   失败行为：探测失败后 kubelet 会重启容器

用途：

• 进程死锁但容器未退出
• 服务卡死无响应
• 内存泄漏导致应用假死

特点：
用于“自愈”，通过重启恢复服务

---

2. Readiness Probe（就绪探针）
   作用：判断容器是否“可以接收流量”
   失败行为：探测失败后 Pod 会从 Service 的 Endpoints 中移除，但不会重启

用途：

• 应用启动未完成
• 依赖服务未准备好（如数据库/缓存）
• 初始化任务未结束

特点：
用于“流量控制”，避免请求打到不可用实例

---

3. Startup Probe（启动探针）
   作用：用于解决应用启动时间较长的问题
   失败行为：在启动阶段失败不会触发重启，直到启动完成窗口结束后才交由 Liveness 接管

用途：

• Java 启动慢
• 大模型加载时间长
• 初始化过程复杂的服务

特点：
用于“保护启动阶段”，避免被误杀

---

三种探针对比总结：

Liveness Probe：
判断是否存活，不存活则重启容器

Readiness Probe：
判断是否可用，不可用则停止接流量

Startup Probe：
判断是否完成启动，未完成启动前不触发重启

---

常见探针方式：

1. HTTP 探针
   httpGet:
   path: /health
   port: 8080

2. TCP 探针
   tcpSocket:
   port: 3306

3. Exec 探针
   exec:
   command: ["cat", "/tmp/healthy"]

---

生产中常见问题：

• Liveness 配置不合理导致频繁重启
• Readiness 过于严格导致服务无流量
• 未配置 Startup 导致启动慢应用被误杀

---

面试总结一句话：

Kubernetes 提供 Liveness、Readiness 和 Startup 三种探针，分别用于控制容器存活状态、流量接入状态以及启动保护机制，从而保证服务的稳定性与可用性。

pod 一直重启的原因有哪些？

1. 进程启动就退出
   原因：启动命令写错，主进程不是前台运行，CMD / ENTRYPOINT 配置问题

2. 程序崩溃（代码异常）
   原因：空指针异常，配置错误，依赖服务不可用（DB / Redis / MQ 等）

3. 配置错误
   原因：配置文件挂载失败，环境变量缺失，YAML 配置 key 写错或值不合法

二、资源问题（非常常见）

4. OOMKilled（内存爆了）
   原因：内存 limit 设置过小，Java / Go / Python 内存泄漏，突发流量导致内存溢出

5. CPU 被打爆导致 watchdog 重启
   说明：不会直接触发重启，但会导致应用卡死，livenessProbe 检测失败后被重启

6. livenessProbe 失败 → kubelet 强制重启
   原因：接口不可用，启动太慢，健康检查路径错误，端口错误，依赖服务未就绪

7. readinessProbe 配错
   原因：探针逻辑不合理或依赖外部服务，导致服务长期不可用（不一定重启，但影响流量）

8. PVC 挂载失败
   原因：存储类不存在，权限不足，PV 绑定失败，volume attach / mount 异常

9. ConfigMap / Secret 挂载失败
   原因：引用的 ConfigMap / Secret 不存在，key 写错，文件路径错误或权限问题

10. Node 不稳定
    原因：kubelet 重启，节点磁盘满，inode 满，节点资源耗尽或网络异常 `

PVC 一直 Pending 的原因有哪些？

1. 没有匹配的 StorageClass
   原因：PVC 指定的 storageClassName 不存在，或者集群默认 StorageClass 没配置

2. PV 不存在或不够用
   原因：没有可用的 PersistentVolume，或 PV 容量 / accessModes 不匹配 PVC

3. StorageClass provisioner 异常
   原因：动态供给器（如 EBS / Ceph / NFS provisioner）不可用或未部署成功

4. 访问模式不匹配（accessModes）
   原因：

• PVC 要 RWX，但 PV 只有 RWO
• 或者集群存储类型不支持对应模式

5. 存储容量不满足
   原因：PVC 请求的 storage 大于可用 PV 或 StorageClass 限制

6. selector 匹配失败
   原因：PVC 通过 label selector 指定 PV，但没有符合标签的 PV

7. PV 被其他 PVC 占用
   原因：PV 状态已经 Bound，不能再被绑定

8. provisioner 创建 PV 失败
   原因：

• 云盘 API 权限不足（如 AWS / 阿里云）
• CSI driver 未运行
• 存储后端不可用

9. namespace / 权限问题
   原因：

• CSI controller 没权限创建 PV
• RBAC 配置错误

10. 存储后端异常
    原因：

• Ceph / NFS / Longhorn 等存储集群不可用
• 网络不通或存储服务挂了

svc暴露的方式有哪些。

1. ClusterIP（集群内部访问）
2. NodePort（节点端口暴露）
3. LoadBalancer（云负载均衡）
4. ExternalName（外部域名映射）
5. Ingress（七层统一入口，常见生产方案

k8s 增加静态路由

1. 在 Node 上手动添加静态路由（最直接方式）
   原因：通过 Linux 路由表打通 Pod 网段或跨网段访问
   命令示例：
   ip route add 10.244.0.0/16 via 192.168.1.1

2. 永久静态路由配置（防止重启失效）
   原因：系统重启后路由丢失，需要写入系统配置
   方式：

• Ubuntu：netplan 配置 routes
• CentOS：/etc/sysconfig/network-scripts/route-eth0

3. CNI 自动路由（Calico / Flannel）
   原因：K8s 不手动配路由，依赖 CNI 自动生成
   说明：

• Flannel：VXLAN 隧道，不依赖静态路由
• Calico：通过 BGP 自动学习 Pod CIDR 路由

4. Calico BGP 路由模式
   原因：通过 BGP 在 Node 之间自动发布路由
   效果：
   每个 Node 自动学习对端 Pod 网段，无需人工配置

5. 跨 VPC / 跨机房路由配置
   原因：Pod 网段跨网络不可达，需要上层网络打通
   配置位置：

• 云厂商 VPC 路由表（AWS / 阿里云 / 腾讯云）
• 本地核心路由器添加静态路由

6. Node 网络未打通导致的手动补路由
   原因：节点之间二层/三层网络不通
   处理方式：
   手动补 route 或调整 underlay 网络

7. kube-proxy / Service 不依赖静态路由
   说明：
   Service（ClusterIP/NodePort）是通过 iptables/ipvs 实现，不靠路由表

8. Cilium eBPF 模式（无需传统路由）
   原因：使用 eBPF 在内核层转发流量
   特点：
   不依赖 iptables，也不依赖静态路由`

k8s 的网络插件有哪些？

1. Flannel
   特点：最经典的 CNI 插件，主打简单稳定
   实现方式：

• VXLAN 隧道（默认）
• Host-GW（静态路由模式）
  优点：
• 安装简单
• 稳定可靠
  缺点：
• 功能单一
• 不支持 NetworkPolicy（默认不支持）

2. Calico
   特点：企业级最常用 CNI 之一
   实现方式：

• BGP 路由（无隧道）
• IPIP / VXLAN（可选）
  优点：
• 支持 NetworkPolicy
• 性能好（接近原生网络）
• 可扩展性强
  缺点：
• 配置相对复杂

3. Cilium
   特点：基于 eBPF 的新一代 CNI
   实现方式：

• eBPF 内核转发（替代 iptables）
  优点：
• 高性能
• 支持 L7 网络策略
• 可观测性强（Hubble）
  缺点：
• 对内核版本要求高
• 学习成本较高

4. Weave Net
   特点：简单易用的 Overlay 网络
   实现方式：

• VXLAN / UDP 封装
  优点：
• 自动组网
• 配置简单
  缺点：
• 性能一般
• 社区活跃度下降

5. Kube-router
   特点：轻量级网络方案
   实现方式：

• BGP 路由 + iptables
  优点：
• 资源占用低
• 集成 Service + NetworkPolicy
  缺点：
• 使用相对较少

6. Canal
   特点：Flannel + Calico 组合
   实现方式：

• Flannel 提供 Pod 网络
• Calico 提供 NetworkPolicy
  优点：
• 功能互补
  缺点：
• 架构相对复杂

7. Antrea
   特点：VMware 开源 CNI
   实现方式：

• 基于 Open vSwitch（OVS）
  优点：
• 企业级支持
• NetworkPolicy 强
  缺点：
• 使用范围较小

总结（面试一句话）
K8s 常见 CNI 插件包括 Flannel、Calico、Cilium、Weave、Kube-router、Canal、Antrea，其中 Flannel 侧重简单 Overlay 网络，Calico 侧重 BGP 高性能网络与策略控制，Cilium 基于 eBPF 提供高性能与 L7 可观测能力，是目前新一代主流方向。

mysql 索引失效

1. 对索引列使用函数或表达式
   原因：索引列被加工后无法走索引
   示例：
   where date(create_time) = '2026-01-01'

2. 隐式类型转换
   原因：字段类型和查询类型不一致导致索引失效
   示例：
   where phone = 123456（phone 是 varchar）

3. like 以 % 开头
   原因：前缀无法确定，B+Tree 无法定位
   示例：
   where name like '%john'

4. 复合索引不满足最左前缀原则
   原因：没有从最左字段开始使用索引
   示例：
   索引 (a, b, c)
   where b = 1 ❌

5. OR 条件导致索引失效
   原因：OR 中某个条件不走索引会导致全表扫描
   示例：
   where a = 1 or b = 2

6. 使用 != 或 <> 或 NOT
   原因：优化器通常选择全表扫描
   示例：
   where status != 1

7. 使用 IS NULL / IS NOT NULL（视情况）
   原因：低选择性字段可能不走索引

8. 查询列无法覆盖索引（回表成本高被放弃）
   原因：优化器认为全表扫描更快

9. 索引列参与计算
   原因：
   where id + 1 = 10 ❌

10. 数据量小
    原因：优化器认为全表扫描比走索引更快

11. 统计信息不准
    原因：索引选择错误（需要 analyze table）

12. 索引区分度太低
    原因：如 gender / flag 字段，选择性太差

总结（面试一句话）：
MySQL 索引失效通常是因为对索引列进行了计算、函数操作、隐式转换，或者查询条件破坏了最左前缀原则，导致优化器放弃索引而选择全表扫描。

redis 怎么去做持久化。

1. RDB（快照持久化）
   原理：定期生成内存数据的快照（dump.rdb）
   触发方式：

• save（阻塞）
• bgsave（后台 fork 子进程）
• 自动触发（配置时间/次数）

优点：

• 文件紧凑，恢复速度快
• 适合备份 / 灾难恢复

缺点：

• 可能丢数据（两次快照之间的数据会丢）
• fork 过程有性能开销

使用场景：

• 主从备份
• 定期冷备

2. AOF（Append Only File）
   原理：记录所有写操作日志（类似 MySQL binlog）

写入方式：

• always（每次写都刷盘，最安全但慢）
• everysec（每秒刷盘，推荐）
• no（交给 OS）

优点：

• 数据安全性高（最多丢 1 秒数据）
• 可读日志，可重放恢复

缺点：

• 文件比 RDB 大
• 恢复速度较慢

使用场景：

• 对数据一致性要求高的业务（订单、支付）

3. RDB + AOF 混合模式（推荐）
   原理：

• 用 RDB 做全量备份
• 用 AOF 做增量日志

优点：

• 启动快 + 数据安全
• Redis 4.0+ 支持混合持久化

4. 持久化配置示例
   redis.conf：

RDB：
save 900 1
save 300 10
save 60 10000

AOF：
appendonly yes
appendfsync everysec

5. 恢复流程

• 优先加载 AOF（如果开启）
• 否则加载 RDB
• Redis 启动时自动恢复数据

6. 面试总结一句话
   Redis 持久化主要有 RDB 快照和 AOF 日志两种方式，RDB 适合备份恢复快但可能丢数据，AOF 数据更安全但文件更大，生产中通常采用 RDB + AOF 混合持久化来平衡性能和安全性。

给你一个模型你怎么部署？

1. 模型准备（模型格式转换）
   原因：统一推理格式，方便部署
   操作：

• PyTorch → TorchScript / ONNX
• TensorFlow → SavedModel / ONNX
• LLM → GGUF / HF format / TensorRT

目标：
让模型可以被推理引擎加载

2. 推理服务封装（API 层）
   原因：对外提供 HTTP/gRPC 调用能力
   方式：

• FastAPI / Flask（常见）
• gRPC（高性能场景）
• vLLM / TGI（大模型专用）

示例：
POST /predict → 返回推理结果

3. 模型加载优化（关键）
   原因：避免每次请求重新加载模型
   做法：

• 模型预加载（startup load）
• GPU/CPU device 固定
• batch inference（提升吞吐）

4. 容器化（Docker）
   原因：保证环境一致性
   内容：

• Python + 推理框架 + 模型文件
• requirements.txt / conda env

示例：
FROM pytorch/pytorch
COPY model /app/model
CMD uvicorn app:app

5. Kubernetes 部署（生产核心）
   原因：实现弹性伸缩与高可用
   方式：

• Deployment：多副本
• Service：服务暴露
• ConfigMap/Secret：配置管理
• GPU Node 调度

示例能力：
resources:
limits:
nvidia.com/gpu: 1

6. 服务暴露（对外访问）
   方式：

• ClusterIP（内部）
• NodePort（测试）
• LoadBalancer（云上）
• Ingress（统一入口）

7. 性能优化（生产重点）
   原因：提升吞吐和降低延迟
   手段：

• ONNX / TensorRT 加速
• 量化（int8 / int4）
• KV cache（LLM）
• batch 推理
• GPU 并发优化

8. 监控与日志
   原因：保证可观测性
   工具：

• Prometheus（指标）
• Grafana（可视化）
• Loki / ELK（日志）
  指标：
• QPS
• latency
• GPU 利用率
• error rate

9. 高可用设计
   原因：避免单点故障
   方案：

• 多副本 Deployment
• HPA 自动扩缩容
• readiness / liveness probe
• 多节点 GPU 分布

10.（大模型补充）
LLM 专用方案：

• vLLM（高并发）
• TGI（HuggingFace）
• llama.cpp（轻量CPU）
• API Gateway + RAG 系统

总结（面试一句话）：
拿到一个模型后，通常先进行格式转换，然后用 FastAPI/gRPC 封装推理服务，Docker 容器化后部署到 Kubernetes，通过 GPU 调度、服务暴露、监控与弹性扩缩容来构建完整的生产级模型服务架构。

模型用久了变慢的原因有哪些？

1. 内存泄漏（最常见）
   原因：程序长期运行未释放对象
   现象：

• 延迟越来越高
• CPU/内存持续上涨
• 最终 OOM 或卡死

常见于：

• Python 推理服务
• TensorFlow session 未释放
• Java/Go 缓存不当

2. 缓存膨胀
   原因：缓存没有过期机制或无限增长
   例如：

• embedding cache
• token cache
• Redis / 本地 LRU 未限制

结果：

• 查询越来越慢
• GC 压力变大

3. GC（垃圾回收）频繁
   原因：

• Java / Python / Go 对象过多
• 内存碎片化严重

现象：

• STW（Stop The World）
• 延迟抖动明显

4. 请求堆积（排队延迟）
   原因：

• QPS 上升
• 线程池 / worker 不够
• GPU batch 堵塞

现象：

• CPU不满但延迟很高
• 队列越来越长

5. GPU / CPU 资源被打满
   原因：

• 并发过高
• batch 太大或太小
• 计算资源不足

现象：

• GPU utilization 100%
• 推理变慢

6. 磁盘 / IO 变慢
   原因：

• 模型日志过多
• checkpoint / cache 频繁读写
• 容器写盘压力大

7. 模型热度下降导致缓存失效
   原因：

• CPU cache / GPU kernel cache 被替换
• page cache 被挤出

8. 数据分布变化（concept drift）
   原因：

• 输入变复杂
• 长文本比例增加
• 特征变重

导致：

• 推理路径变长
• attention 计算增加（LLM）

9. 连接 / 网络问题
   原因：

• RPC 连接泄漏
• gRPC channel 复用异常
• LB 转发延迟

10. 没有做 batch / pipeline 优化
    原因：

• 单请求推理
• 没有 micro-batching

导致：

• GPU 利用率低但延迟高

总结（面试一句话）：
模型变慢通常不是模型本身变慢，而是系统问题导致的，包括内存泄漏、缓存膨胀、GC压力、资源竞争、请求堆积以及GPU/CPU利用率不均衡等问题。