K8s运维面试实录（六）：SRE稳定性建设与TCP丢包排查

前言

这是某候选人第六场K8s运维面试记录。候选人拥有3年工作经验，本场面试重点考察了SRE稳定性体系建设、监控告警实践、以及一个经典的TCP丢包问题内核层面排查案例。以下为技术问题完整还原。

1. 自我介绍

面试官问：先做简单自我介绍。

答：

面试官你好，我叫XX，本科计算机科学与技术专业，工作三年了。

第一家的话是南京某科技公司，从事教育和政务类产品研发交付。负责内部运维平台部署和私有化项目改造上线持续运营。

第二家的话是追觅科技，现公司。负责内部平台运维部署和线上服务稳定性建设。

技术方面的话我是熟悉容器化与K8S集群架构设计与运维管理，然后线上问题排查和性能优化经验。然后GPU机型调度优化、CICD自动化、EFK日志、Prometheus自动服务发现、MySQL索引优化这些。

开发能力的话我是编写HELM Chart包，然后Ansible Playbook剧本，然后Python Webhook，然后Go写过Operator控制器。

未来希望的话是在云原生基础上，向系统架构与稳定性建设方向发展，成为一名SRE工程师。

2. SRE稳定性建设理论

面试官问：SRE稳定性建设方向怎么做？

答：

CAP理论

嗯，SRE稳定性建设方向怎么做的话，主要是要懂CAP理论。分布式系统的话只能遵循CP或AP。CP的话是强一致性，数据同步到所有节点。AP的话是服务持续可用。

然后根据业务选择，数据类选CP，体验类选AP。

3. SRE体系建设

面试官问：具体怎么建设？

答：

体系层面

SLI/SLO指标化

嗯，体系层面的话主要是SLI和SLO指标化。SLI的话是Service Level Indicator，就是服务水平指标。SLO的话是Service Level Objective，就是服务水平目标。

核心指标

然后核心指标的话主要是三个。一个是可用性，就是成功请求数除以总请求数乘以100%。然后接口延迟的话是直方图统计，通过SDK采集错误率。然后MTTR的话是Mean Time To Recovery，就是告警触发到恢复的时间差。

制度建设

然后制度建设的话是每周生成健康报表，然后统计错误预算消耗率、告警响应率、MTTR，然后纳入绩效考核和稳定性评估。

轮值制度

然后轮值制度的话是每个工程师负责自己系统，然后第一时间响应执行应急预案，然后事后提交事故报告。

4. 执行层面

面试官问：执行层面具体做什么？

答：

四大方向

嗯，执行层面的话主要是四大方向。

1. 监控

监控的话主要是用Prometheus Operator和Alertmanager实现系统和业务监控。然后覆盖的话是CPU、内存、GPU利用率、接口延迟、错误率、消息积压。然后接入日志链路和链路追踪，实现全栈可观测性。

2. 自动化

然后自动化的话是定期健康检测，然后节点Pod状态检测，然后Ansible Playbook剧本快速执行。

3. 容量评估

然后容量评估的话是每季度进行容量压测，然后分析历史状态、QPS、数据库性能、GPU饱和度，预防容量不足导致的问题，这个占线上问题的话是60到70%。

4. 红蓝演练

然后红蓝演练的话是制定应急预案SOP手册，包括问题识别、熔断、限流、降级、流量切换、回滚流程。每季度演练，人为制造故障，比如说断网、打爆节点，验证团队应急能力。

5. 监控实践

面试官问：监控具体怎么做？

答：

指标优化

嗯，监控具体的话首先指标优化。一个是剔除无效指标，就是长期无波动、与业务无关的指标。然后聚合，减少告警数量。然后抑制，避免重复告警。

业务分级

然后业务分级的话，核心业务是影响收益、核心链路的，比如说网关、支付、登录。普通业务的话是部分影响，辅助功能。一般业务的话是不影响主链路，边缘功能。

告警升级

然后告警升级的话是一线人员接收告警，十分钟无响应就升级二线，持续不响应就升级管理层。

6. 链路追踪

面试官问：链路追踪做过吗？

答：

方案选型

嗯，链路追踪的话当时做过方案选型。非侵入式的话是虚拟机自动埋点，但效果不理想。侵入式的话是代码层面手动埋点，更精确。

实践

然后实践的话是当时定过方案，但因为侵入式需要改代码，最终没有落地。

价值

然后价值的话是通过每个服务间埋点，分析调用链哪里慢，生成拓扑图快速定位问题。

7. 自动化经验

面试官问：自动化做过哪些？

答：

Ansible Playbook

嗯，自动化的话我写过Ansible Playbook。就是写Hadoop、Spark主备集群部署剧本，然后通过shell脚本、systemctl管理服务，一键快速部署。

HELM Chart

然后HELM Chart的话是编写Chart包模板，然后部署时传参，镜像版本、配置值，一键部署。

8. TCP丢包问题排查（重点案例）

面试官问：遇到过什么典型问题？

答：

问题背景

嗯，这个的话是遇到过一个问题，是K8S算力集群，30台机器。客户反馈请求莫名卡顿。

现象

然后现象的话是不是所有请求都卡，大部分请求几十毫秒，少部分请求1点几秒，而且是固定时间，无波动的。

排查过程

第一步：检查资源

然后我首先是检查资源，用kubectl top pod和kubectl describe node。结果是Pod和Node资源都充足，CPU、内存、平均负载都不高。

第二步：检查链路

然后链路的话架构是用户到NGX到Node的Service到IPVS到Pod。

第三步：加日志分析

然后在NGX加日志分析，有request time，就是请求总耗时，还有upstream response time，就是上游响应耗时。用awk排序分析，发现大部分几十毫秒，少部分1点几秒。

第四步：检查TCP状态

然后检查TCP状态，用netstat -an | grep SYN。发现卡顿请求都在SYN队列状态。

第五步：抓包分析

然后用tcpdump抓包，导入Wireshark分析。发现Node发出SYN包，Service的eth0收到，同节点cni0发出，但Pod的eth0没收到SYN包，一秒后触发重传，第二次SYN才收到并返回ACK。

第六步：定位问题层次

然后查看IPVS连接表，用ipvsadm -L -n。还有查看conntrack TCP状态，cat /proc/net/stat/nf_conntrack。两边都没有SYN状态，说明包在IPVS层面就被丢了。

根因：内核Bug

问题原因

嗯，问题原因是这样的。当开启ipvs加conntrack联动时，就是nf_conntrack_ipvs，存在内核bug。连接表满或冲突时，第一个SYN包被直接丢掉，等待TCP超时重传。

触发条件

触发条件的话是五元组命中conntrack表项，conntrack timewait连接过多。

短期解决

短期解决的话是关闭连接复用，sysctl -w net.ipv4.vs.conntrack=0。

长期解决

长期解决的话是升级Linux内核到5.9以上，升级K8S到1.22以上。因为5.9内核引入了补丁，在不丢包情况下重用conntrack条目，消除超时重传。

9. 问题定位思路总结

面试官问：这个案例学到什么？

答：

定位方法

嗯，这个案例学到的话是定位方法。首先资源层面是CPU、内存、负载，排除明显问题。然后应用层面是日志分析耗时分布。然后TCP层面是SYN队列状态。然后网络抓包是定位到哪一层丢包。然后内核参数是conntrack状态。

关键命令

关键命令的话是查看SYN队列netstat -an | grep SYN，查看IPVS连接ipvsadm -L -n，查看conntrack cat /proc/net/stat/nf_conntrack，还有抓包分析tcpdump -i eth0 port 80 -w capture.pcap。

经验教训

经验教训的话是很多问题不是应用层，是内核层，需要逐层剖排除，内核bug要查内核源码或社区Issue。

10. 内核参数优化

面试官问：还有哪些内核参数需要关注？

答：

连接跟踪

嗯，连接跟踪的话主要是两个参数。一个是net.netfilter.nf_conntrack_max，是最大连接数。然后net.netfilter.nf_conntrack_tcp_timeout_established是超时时间。

IPVS

然后IPVS的话主要是开启conntrack联动net.ipv4.vs.conntrack=1，还有连接复用net.ipv4.vs.conn_reuse_mode=0，但5.9以下有bug。

网络

然后网络的话是开启路由转发net.ipv4.ip_forward=1，然后调整缓冲区net.core.rmem_max和net.core.wmem_max。

总结

本文完整还原了K8s运维工程师的技术面试，涵盖：

SRE理论：CAP、SLI/SLO、MTTR
体系建设：监控、自动化、容量评估、红蓝演练
监控实践：指标优化、告警分级、聚合抑制
自动化：Ansible Playbook、HELM Chart
问题排查：TCP丢包内核层面定位（经典案例）
内核优化：IPVS、conntrack参数

这个TCP丢包问题是难得一见的内核层面排查案例，体现了候选人扎实的基本功和深入的问题定位能力。