K8s运维面试实录（三）：GPU故障与网络问题排查
完整还原K8s运维工程师面试，涵盖GPU掉卡排查、Flannel网卡丢失、CICD灰度发布、多集群部署等核心技术问题。
K8s运维面试实录（三）：GPU故障与网络问题排查
前言
这是某候选人第三场K8s运维面试记录。本场面试重点考察了问题排查能力和实际运维经验，包括GPU掉卡、Flannel网卡丢失等典型问题的排查思路。以下为技术问题完整还原。
1. 集群规模
面试官问：你们SaaS平台集群规模管理的最复杂的大概是什么样规模？
答：
我们SaaS平台有五十多台机器。然后客户私有化的话，因为我们也是做K12学校以及高校，高校一般是部分微服的话，会迁移改造到他们的一个集群当中。然后他们的集群的话大概只有十几台机器。
业务模式
如果高校他没有K8S集群的话，那么就是我们来做的一个搭建。如果有的话，我们直接用他们的一个K8S，然后把我们的服务迁移进去。
服务迁移都是做成标准化的，二次发布就行。
团队构成
我们公司的话高级运维有四个，然后其中一个是leader，然后还有其他的话就是驻场运维。驻场运维的话有五六个。
2. GPU掉卡问题排查
面试官问：你们产品会用到GPU吗？主要做什么？
答：
我们是有一个AI分析系统的，主要是分析学生的一个上课的一个情况，他对GPU的资源需求有多大。
GPU配置
我们用的那个GPU卡的话是A10跟T4。A100也有吗？那么不便宜。对，主要是客户环境。我们自己SaaS平台是A100，但是客户的话我们是T4以及T4。
你们自己的SaaS环境是你们自己部署的独立的，不是云环境里面的局部的那种关系吗？不是云，因为我就是做学校的话，他们对数据安全性是有要求的，所以我们是自己的IDC机房。
问题现象
监控的话它是发现有几个VGPU的GPU利用率持续为零，然后它的那个pod也没有挂掉。
然后我是用那个kubectl describe的话去看了一下，知道这个节点的一个状况，然后看到它的一个资源状况，它是总资源的话这个有六张GPU卡。但是可分配的一个allocatable的话，它只有四张是可以分配的。然后这个一就就是那个Kubelet，它上报的一个认为只有四张卡是可以用的。
然后我是用那个英伟达snm去看了一下这几张卡的状况。然后这几张卡的话显示是还是有六张卡是可以用的那就说明驱动是没有硬件是没有发生故障的。
然后我就怀疑是不是因为那个英伟达那个驱动插件上报有问题。
深入排查
然后我去看了一下这个pod的日志，发现它是有一个报错，就是健康检测失败。然后原因是因为XID的一个错误。然后我去去查了一下这个错误，然后这个错误的话它是毫秒级会触发一次。然后如果被那个Kubelet去捕获到的话，那么就会被英伟达驱动插件的话认为这张卡是不健康的，然后就会上报给那个Kubelet，然后Kubelet的话它就会将那个allocatable中剔除掉，就把这张剔除掉。
然后我进一步的去看了一下这个XID的这个错误，它是英伟达驱动层面的一个错误。就像我这次遇到那个XID94，它是那个PCIe那个叫做通信异常，就是有可能是因为网络瞬时的抖动造成的。然后这个错误的话它是不会让那个GPU卡去做一个重启的。但是如果被捕获到的话，那么它就会认为这张卡是不健康的。
然后最关键的是因为最关键的是那个英伟达驱动插件这个pod的话，它是不支持将这个GPU卡的一个不健康的状态恢复成健康的。除非他是做一个重启，然后重新进行一个设备列表的一个刷新。所以的话它就会一直认为这张卡是不可以用的。
解决
所以我是写了一个巡检脚本，然后逐个去对比节点的一个status跟allocatable。如果发现不一致的话，那么就会去重启这个英伟达驱动插件这个pod。
后续的话我还是会去持续的官方关注英伟达这个官方，然后看一下他什么时候进行一个版本的更新，然后能够支持GPU恢复健康的话，能够自动的将这个状态改成为健康的一个状态。
3. Flannel网卡丢失问题排查
面试官问：在私有K8S环境里，碰到最大最常见的问题是什么？
答：
这个有遇到GPU掉卡的问题，又遇到那个叫做flannel网卡丢失的一个问题。
问题背景
这个网卡丢失它是是这样子的，我们也他他这个客户的话，他是他已经有自己的一个操作系统了。然后我们就是去在他的操作系统上去搭建我们的K8S，以及我迁移我们的一些微微服务。
然后突然因为做完这个部署之后，发现这个pod他去报报了那个叫做网络不通的一个错误。然后我就是做一个排查，我先先是做一些常规的，我反正也去排查了一下，就是DNS解析，然后那个网络策略，这些都是没有没有问题的，包括路由表这些的。
然后我然后我用那个tcpdump去抓包了一下，然后它是叫做跨节点的话，它是访问是不同的，同节点访问是没有问题的。然后用TC去抓包的话，是发现这个包的话，它是可以从数本端的一个主机eth0的话是可以正常的发出的。然后到对端的那个eth0的话也是能接到的。但是他从那个flannel的那就是接网卡的话，那就是接收不到这个包了。所以我就怀疑是不是overlay网络层出了问题。然后我去看了一下那个flannel那个pod的一个日志，然后它是没有进行一个就是没有报错，然后是正常的。
深入排查
然后用ip link命令去看了一下那个flannel这个网卡的一个信息，然后它是发现每个节点的flannel网卡的话，它的mac地址都是一样的。然后看了那个FDB表的话，它是那个FDB表，它是每个节点的话都是有不同的mac地址，跟网卡的那个mac地址它是不一致的。
然后我就尝试了重启了一下这个pod。然后重启完了之后，那个那个网卡的那个mac地址还是不变的，还是固定的一个mac地址。然后就是FDB的这个mac地址它是有进行一个刷新，所以我就是所所以我就看去查了一下那个flannel源码，去看一下这个mac地址到底是怎么生成的。然后那个mac地址，其实它不是那个flannel去自动生成的，它是做一个系统调用，然后去生成这个mac地址。
所以的话我就是在那时候就是在显示不是那个，要么就是他那个地址生成出了问题，要么就是说它生成没有问题，但是有可能是被某某一些服务都要进行了一个覆盖，所以我就是用那个内核那个跟踪工具ebpf那个内核工跟踪工具，去进行一个跟踪。
我是先是跟踪那个以太网那个设置函数，但是跟踪这个函数的话，并没有去抓到flannel注册的一个信息。只有发现那个docker去注册了那个eth0那个网卡的一个信息。后来我就换了一个思路，去跟踪那个叫注册函数，注册函数。
因为每个网卡的话都是会进行一个注册的，然后这次是有发现flannel的话，它是注册了这个mac地址以及这个时间。然后这个mac地址的话跟那个FDB上面的mac地址是一致的。然后说明的话它是那个mac地址生成是没有问题的，就是生成的时候就已经就已经是好了。
所以我又增加了那个叫设备跟踪函数，就是dev_set_mac_address这个就是跟踪函数，然后去打印这个设备的原mac地址，以及他那个叫做后续被修改的这个mac地址。以及是用哪个进程进行了一个修改，然后再进行一个跟踪。然后这次是发现了那个flannel他是先做了一个mac地址的一个生成，然后调用这个设备，然后又过仅仅过了2秒左右，就是被那个周围的NetworkManager这个进程的话被修改成其他的一个固定的mac地址了。
所以我去看了一下这个宿主机上确实起了一个NetworkManager，这个就是这个进程，并且的话它是它的配置上面的话去配置的那个mac地址的一个编码，就导致了那个flannel那个地址被做了一个修改。
解决
所以就查找完了之后，它就解决起来还是比较简单的。就是先把配这个NetworkManager这个配置的话，去忽略掉那个flannel.1这个网卡的一个设置。然后后续的话晚上我们去进行其他客户的一个基立的部署，也会去检查这一点。就是看一下它的系统上有没有起一个NetworkManager一个进程。
4. CICD技术栈
面试官问：你们CICD是怎么搭建的？
答：
CICD的我们是GitLab加那个Jenkins。原来后面我引入了那个ArgoCD。
主要主要的一个原因是因为我们之前的Jenkins的话是直接部署到那个K8S当中的，然后就缺乏要么清单的一个管理以及回滚也比较困难，只能在那个流水线进行上面进行一个回滚。
所以我引入那个ArgoCD，然后用GitLab去管理这个清单。然后ArgoCD的话只要监听到GitLab清单的一个资源的一个变化，它就可以做一个自动的一个部署。
5. 灰度发布场景
面试官问：灰度发布用在什么场景？
答：
因为有时候微服务变变更的话，它如果没有进行一个灰度发布的话，它就是如果没有功能的一个对比的话，可能就是会进行对数据库进行一个污染。
然后我们之前的话是有做一个做了一个是做了一个简单的一个分批，然后用那个Deployment作为一个简单的分批。然后简单的分批的话主要是可能不知道到底是不是灰度环境出了一个问题。
然后后面的话我就引入了那个Istio去做这个灰度发布。
6. 多集群/多可用区
面试官问：有没有涉及多可用区的维护？
答：
我们没有多集群。您说是多集群对吧？多可用区基本上都会涉及到多集群，因为就是一个大的集群。
对，我们是没有用多集群。如果多集群的话，其实我大概有个了解。
要么就可以做一个K8S联邦，或者是做用ArgoCD的话，去做一个多集群的一个部署，但是相对会比较麻烦一点。
你说哪一个方案会比较麻烦一点？就是说他涉及到了异地或者是多可用区里面，它的数据同步或者是一些灾备恢复会变麻烦。对，如果是数据库的话，确实是会比较麻烦。如果但是部署方面的话，就用ArgoCD是不，没有那么麻烦的。然后K8S联邦的话，它是主要就是可以将多个集群的一个资源的话，可以更好的做一个调度。
7. 信创/国产环境
面试官问：有用过信创的服务器吗？
答：
信创的话我们用的比较少。我们一般的话是用那个兆芯，或者是飞腾这些的。那你们用过ARM的吗？还是都是x86的？都是x86比较为主的。
比较少是吗？
对，了解。
8. 存储IO性能问题
面试官问：在校园环境部署碰到意想不到的状况吗？
答：
环境不好解决或不好处理的，不好处理的方面的话，我想想主要是有一个是有，但是这个有点模糊了，就是它比较久了。
主要是客户的话他是有那个存储，他是用了自己的一个存储。但是他的那个存储可能是效率不太，IO性能不太好，然后就就会导致我们的一个pod它不断的一个崩溃掉一个问题。
总结
本文完整还原了K8s运维工程师的技术面试，涵盖：
- 问题排查：GPU掉卡（XID错误）、Flannel网卡丢失（NetworkManager覆盖MAC）
- 平台建设：CICD流水线（GitLab + Jenkins + ArgoCD）
- 发布策略：灰度发布场景
- 架构扩展：多集群部署方案
- 特殊场景：信创环境、存储IO问题
希望对准备K8s运维面试的读者有所帮助。