线上某个 Deployment 滚动更新后，新 Pod 一直处于 CrashLoopBackOff 状态，老 Pod 已经全部替换。请描述你的排查思路和处理过程。

这是一道故障排查类题目，建议用 SARC 框架 回答：

• S 状况描述
• A 分析路径
• R 解决操作
• C 复盘改进

现象是新 Pod 反复崩溃重启，说明容器能启动但随即退出。

先跑 kubectl logs --previous 看崩溃日志，再跑 kubectl describe pod 确认退出码——OOMKilled 就调内存 limit，探针超时就延长 initialDelaySeconds，配置错误就回滚 ConfigMap。

这次根因是环境变量缺失导致应用 panic，修正后重新发布。

复盘：在 CI 流水线加启动烟测，滚动更新设 maxUnavailable=0 保留回滚窗口。

请解释一下 K8s 中 Request 和 Limit 的区别，以及设置不合理会带来什么问题？

这是概念原理类题目，用 WHAT 框架 回答：

• W 是什么：一句话本质定义
• H 怎么工作：核心机制
• A 我用过：真实项目绑定
• T 踩过坑：1个注意事项

Request 是调度器选节点的依据，Limit 是 cgroups 的硬上限。

Request 设太小，Pod 会被调度到资源紧张的节点，实际跑起来触发 OOMKill；Limit 设太小，应用一旦流量突增直接被杀。

我们项目里曾把 Java 服务 limit 设成 512Mi，JVM 堆外内存一涨就 137 退出，后来统一改成 request/limit 1:2 比例，稳定很多。

踩过的坑：不设 limit 的 BestEffort Pod 在节点压力大时最先被驱逐。

你们团队是如何做 K8s 集群的可观测性的？用了哪些工具，解决了什么问题？

这是概念原理类题目，用 WHAT 框架 回答：

• W 是什么：你们可观测性体系的一句话概括
• H 怎么工作：工具链和数据流
• A 我用过：具体解决了什么真实问题
• T 踩过坑：1个注意事项

我们可观测体系覆盖三个维度：指标、日志、链路。

Prometheus 采集 K8s 和业务指标，Grafana 出图，核心接口 P99 超阈值自动告警；日志用 Loki 收集，按 namespace 分流；链路追踪用 Jaeger，业务侧注入 OpenTelemetry agent。

解决的真实问题：有个下单接口 P99 达到 3 秒，通过 Jaeger 定位到是第三方支付回调耗时 2.8 秒，优化后降到 400ms。

踩过的坑：Prometheus 没设 retention 策略，磁盘两周打满，现在统一限制 15 天。

你们 CI/CD 流水线是怎么设计的？从代码提交到上线经历了哪些阶段？

这是概念原理类题目，用 WHAT 框架 回答：

• W 是什么：一句话描述你们流水线整体设计
• H 怎么工作：各阶段流转和工具链
• A 我用过：具体解决了什么问题，有数字
• T 踩过坑：1个注意事项

我们整体基于 GitOps 理念，所有配置代码化托管 Git。

CI 阶段：代码提交触发 GitLab CI，依次做代码扫描、自动化测试、镜像构建，推送到 Harbor 制品库。

CD 阶段：CI 完成后自动更新部署仓库的镜像 tag，ArgoCD 检测到变更自动同步到对应环境。

效果：上线时间从人工 40 分钟压到 8 分钟。

踩过的坑：tag 用 latest 时 ArgoCD 不触发更新，改成 commit SHA 后解决。

Linux 中，某个服务突然响应变慢，你如何排查是 CPU、内存、磁盘 I/O 还是网络问题？

这是故障排查类题目，用 SARC 框架 回答：

• S 状况：一句话描述现象
• A 分析：排查路径，从可观测性入手
• R 解决：具体命令/配置变更
• C 复盘：预防和监控改进

响应变慢先从资源层排查，再到应用层。

先跑 top 看 CPU，free -h 看内存，iostat -x 1 看 I/O wait，ss -s 看连接数——定位资源瓶颈。

如果资源正常，往应用层看：Java 服务查 JVM 堆内存和 GC 频率，查 Redis 连接数和慢命令，查数据库慢查询和锁等待。

这次是 I/O wait 达 90%，用 iotop 定位到日志进程疯狂写盘，临时调低日志级别，响应恢复正常。

复盘：对 I/O wait 配置 Prometheus 告警，阈值 70% 触发。

K8s 中 Pod 调度失败，状态一直是 Pending，你如何排查？

这是故障排查类题目，用 SARC 框架 回答：

• S 状况：一句话描述现象
• A 分析：排查路径，从可观测性入手
• R 解决：具体命令/配置变更
• C 复盘：预防和监控改进

Pending 说明调度器还没找到合适节点，先跑 kubectl describe pod 看 Events 里的 Warning。

根因主要五类：资源不足、污点未容忍、亲和性标签不匹配、PVC 未绑定、节点选择器错误。

上次遇到的是节点加了 NoSchedule 污点做维护，Pod 没配容忍，加上 tolerations 字段重新发布即可。

复盘：对 Pending 超 5 分钟的 Pod 配置 Prometheus 告警，不等业务反馈。

pod怎么监控

我们对 Pod 的监控主要分为五个方面：Pod 状态监控、资源监控、业务监控、网络监控和日志监控。

第一，Pod 状态监控。

主要监控 Pod 是否 Running、是否频繁重启（CrashLoopBackOff）、Pending、OOMKilled、Evicted，以及 Ready 状态是否正常。

第二，资源监控。

通过 Prometheus 采集 CPU、内存、磁盘 IO、网络流量等指标，同时关注 CPU Throttling、内存使用率以及容器是否触发 OOM。

第三，业务监控。

采集应用暴露的 Metrics，例如 QPS、响应时间、错误率、HTTP 状态码、JVM 指标等，评估业务是否正常。

第四，日志监控。

通过日志平台统一采集 Pod 日志，根据 Error、Exception、Timeout 等关键字进行告警，方便快速定位问题。

第五，告警和可视化。

使用 Prometheus + Alertmanager 配置告警规则，例如 Pod 重启次数过多、CPU 超过 80%、内存超过 85%、Pod 不可用等，通过企业微信、钉钉等通知运维人员，再结合 Grafana 展示整体运行状态。

整个监控体系可以实现从基础资源到业务指标的全链路监控。

什么是 Kubernetes 的 HPA？它是如何工作的？你在项目中用过吗？

这是概念原理类题目，用 WHAT 框架 回答：

• W 是什么：一句话本质定义
• H 怎么工作：核心机制
• A 我用过：真实项目绑定
• T 踩过坑：1个注意事项

HPA 是 K8s 的水平自动扩缩容控制器，根据指标动态调整 Pod 副本数。

工作原理：依赖 metrics-server 每 15 秒采集一次 CPU/内存，用当前利用率 ÷ 目标阈值计算期望副本数，超过目标就扩容，低于目标就缩容，副本数限定在 min/max 之间。

我们给电商促销服务配了 HPA，CPU 目标 60%，最小 2 个 Pod 最大 20 个，大促期间自动扩到 14 个，扛住了 8 倍流量。

踩过的坑：缩容太激进导致流量抖动，加了 stabilizationWindowSeconds: 300 稳定后才缩。

你们是如何做容器镜像安全扫描的？发现高危漏洞后流程是怎样的？

这是概念原理类题目，用 WHAT 框架 回答：

• W 是什么：一句话描述你们镜像安全体系
• H 怎么工作：扫描时机、工具、流程
• A 我用过：真实案例
• T 踩过坑：1个注意事项

我们在 CI 流水线镜像构建后接 Trivy 扫描，按漏洞等级分级处理。

Critical/High 级别直接阻断流水线，开发必须修复才能合并；Medium 级别告警不阻断，限 7 天内修复；Low 级别记录备案。

真实案例：基础镜像 python:3.9 扫出 2 个 Critical，升级到 python:3.11-slim 后清零，同时把基础镜像扫描加入每周定时任务。

踩过的坑：只扫应用镜像，忽略了基础镜像，后来把 FROM 层也纳入扫描范围。

解释一下 K8s 中 Service 的几种类型，分别适用什么场景？

这是概念原理类题目，用 WHAT 框架 回答：

• W 是什么：一句话说 Service 的本质
• H 怎么工作：几种类型的核心区别
• A 我用过：真实项目中用了哪种，解决什么问题
• T 踩过坑：1个注意事项

Service 是 K8s 为 Pod 提供稳定网络入口的抽象，解决 Pod IP 随时变化的问题。

ClusterIP 只集群内可达，适合微服务间调用；NodePort 在每个节点开固定端口，适合测试环境快速验证；LoadBalancer 对接公有云 LB，生产环境对外暴露用它；Headless 不分配虚拟 IP，直接返回 Pod IP，StatefulSet 场景必用。

我们 Java 微服务内部用 ClusterIP，入口网关用 LoadBalancer 对接阿里云 SLB，日均流量 500 万次。

踩过的坑：NodePort 端口范围只有 30000-32767，端口冲突时排查麻烦，生产环境直接上 LB。

你们生产环境是如何做 K8s 集群升级的？升级过程中如何保证业务不中断？

生产环境我们是3个master节点，15个node节点，涉及到技术迭代，所以更新版本。我们先分析了升级的风险，包括了升级过程中版本兼容、服务能否不中断。编写升级手册，主要包括了，备份、实施、还原，一批一批升级的风险点。
具体步骤：先备份 etcd，master 逐个用 kubeadm upgrade apply 升级；node 逐个 kubectl drain 驱逐 Pod，升级后 kubectl uncordon 恢复调度，每批升完验证业务正常再继续。

全程配合 PDB 保证每个服务至少 1 个副本在线。

升级后压测核心接口，监控观察 24 小时无异常才算完成。

线上某个服务 QPS 突然下降 80%，告警触发，你作为值班 SRE 如何处理？

QPS 下降 80%，P1 故障，先通知业务方，确认是否刚有发布——有就先回滚。

同步看监控：CPU/内存正常，排除资源层；SHOW PROCESSLIST 发现大量慢查询堆积，EXPLAIN 定位到缺索引的全表扫描。

止血：临时对该接口限流 50%，缓解 DB 压力；根治：加索引 + 热点数据加 Redis 缓存，QPS 恢复正常水位。

复盘：慢查询阈值从 2 秒改为 500ms 告警，上线前强制跑 EXPLAIN 检查执行计划。

解释一下 etcd 在 K8s 中的作用，如果 etcd 出现故障会发生什么？

etcd 是 K8s 的分布式键值存储，所有资源对象状态都存在这里。

工作流程：kubectl → API Server → 写入 etcd；Scheduler 读 etcd 选节点；kubelet 读 etcd 拉起容器。

etcd 故障后：集群进入只读状态，无法创建/更新任何资源，但已有 Pod 继续运行，因为 kubelet 不实时依赖 etcd。

我们用 CronJob 每天凌晨跑 etcdctl snapshot save 备份，存到对象存储，保留 30 天。

踩过的坑：etcd 磁盘 I/O 打满导致选举超时，集群假死，现在单独给 etcd 挂 SSD 盘。

你们是如何做多环境（开发/测试/生产）隔离的？K8s 层面和网络层面分别怎么做？

我们隔离策略分两层：逻辑隔离用 K8s，物理隔离靠网络。

K8s 层：开发/测试/生产各自独立 namespace，RBAC 控制权限——开发只能操作 dev namespace，禁止触碰 prod；ResourceQuota 限制测试环境最多用 20 核 40G，防止压测打崩共享节点。

网络层：NetworkPolicy 默认拒绝跨 namespace 访问，生产环境额外独立 VPC，和测试网络物理隔离。

解决的真实问题：之前测试环境压测把数据库打崩波及生产，加了 ResourceQuota 和网络隔离后再没出现。

踩过的坑：NetworkPolicy 忘记放通 DNS 端口 53，导致服务发现全部失败。

什么是 K8s 的 Ingress？它和 Service 有什么区别？你们生产环境用的哪种 Ingress Controller？

Ingress 是 K8s 的 L7 流量入口，按域名和路径把外部 HTTP/HTTPS 流量路由到对应 Service。

和 Service 的核心区别：Service 是 L4 按端口转发，Ingress 是 L7 支持域名路由、路径匹配和 TLS 终止。

我们生产用 Nginx Ingress Controller，20 个微服务统一在 Ingress 层终止 TLS，按路径路由，省掉每个服务单独配证书。

踩过的坑：默认超时 60 秒，报表接口超时 504，改 proxy_read_timeout: 300 后解决。

什么是 K8s 的 ConfigMap 和 Secret？使用时有哪些注意事项？

ConfigMap 存明文配置，Secret 存敏感信息——两者都是 Base64 编码，Secret 默认并不加密。

挂载方式有两种：环境变量注入适合简单 KV；Volume 挂载适合配置文件，且支持热更新不用重启 Pod。

我们数据库密码和 Token 放 Secret，应用配置放 ConfigMap，都以 Volume 方式挂载，改配置不用重新发布镜像。

踩过的坑：Secret 默认 Base64 不安全，我们对接了 Vault 做动态密钥，etcd 同时开启静态加密。

线上某个 Pod 内存一直在增长，你怀疑是内存泄漏，如何排查和处理？

Pod 内存持续线性增长，流量低谷期也不回落，确认是泄漏而非正常增长。

先 kubectl top pod 确认增长趋势，进容器用 jmap 抓堆快照，下载后用 MAT 分析——发现是 ThreadLocal 没有 remove 导致大量对象堆积。

短期止血：调低 memory limit 让 Pod OOMKill 后自动重启，保住服务；长期根治：修复 ThreadLocal 泄漏点，重新发布。

复盘：对内存增长超 80% 配告警，同时在 CI 加内存泄漏静态扫描。

你们是如何保证 K8s 上服务的高可用的？从部署架构到故障恢复说一下。

我们高可用分两层：基础设施层和应用层。

基础设施：3 master 节点基于 etcd Raft 选举，1 个挂掉自动切换；15 node 节点，单节点故障 Pod 自动漂移到其他节点。

应用层：核心服务最少 3 副本，配置反亲和性保证副本分散在不同节点；PDB 设 minAvailable=2 保证滚动更新不中断；Readiness Probe 保证不健康 Pod 自动摘流；HPA 应对流量突增。

结果：核心服务 SLA 99.95%，单节点故障业务无感知。

踩过的坑：没配反亲和性，2 个副本落在同一节点，节点故障直接服务中断。

说一下你做过哪些印象最深刻的项目？

我印象最深的主要有两个项目。

**第一个是自动化部署平台建设。**当时发布流程依赖人工操作，效率低且容易出错。我负责搭建基于 GitLab CI、Docker、Harbor、ArgoCD 和 Kubernetes 的 CI/CD 流水线，实现代码提交、镜像构建、安全扫描、镜像推送以及 GitOps 自动部署，并结合 Istio 实现灰度发布和快速回滚。最终将发布时间从约 20～30 分钟缩短到 5 分钟左右，显著降低了人工操作风险。

**第二个是监控告警平台建设。**我负责搭建 Prometheus Operator、VictoriaMetrics、Grafana 和 Alertmanager 的监控体系，实现 Kubernetes 集群、Pod、Node、数据库和业务指标的统一采集，并制定了资源、应用和日志的分级告警策略。同时结合日志平台实现异常日志自动告警，帮助团队从“用户反馈后处理”转变为“系统主动发现问题”，大幅提升了故障发现和恢复效率。

什么是 K8s 的 StatefulSet？它和 Deployment 有什么区别？适用什么场景？

statefulset是有状态应用，一般是数据库在使用，保证有稳定的ip和存储持久化。deployment是无状态的应用，一般部署应用程序，数据没有持久化落地，重启会导致pod发成改变。
java微服务使用deployment保证高可用，mysql使用statefulset保证数据持久化。
StatefulSet 给每个 Pod 固定序号和稳定 DNS 名称，启动按 0→1→2 有序进行，每个 Pod 绑定独立 PVC。

踩过的坑：缩容后 PVC 不自动删除，忘记清理导致存储账单翻倍。

你们是如何做 K8s 集群的备份和灾难恢复的？如果集群完全崩溃如何恢复？

备份分两轨：etcd 快照 + PV 业务数据，RPO 目标 24 小时。

etcd 用 CronJob 每天凌晨跑 etcdctl snapshot save，先存本地再同步 OSS，保留 30 天；PV 数据用云厂商快照每日备份。

集群完全崩溃恢复流程：重建 master 节点 → etcdctl snapshot restore 恢复数据目录 → 重启 etcd → 验证 API Server 正常 → 检查 Pod 状态。

我们每季度做一次全量恢复演练，RTO 控制在 2 小时内。

踩过的坑：只备 etcd 忘备 PV，恢复后数据库数据全丢。