K8s运维面试实录：七年经验工程师的真实问答

前言

这是一篇来自真实面试的整理记录。候选人拥有7年K8s运维经验，曾在两家教育类公司负责K8s平台管理与客户私有化项目交付。本文将完整还原面试中的技术问答，希望能为正在准备云原生运维面试的读者提供参考。

自我介绍

面试官问：能不能先简单把工作做个自我介绍？

答：

面试官你好，我叫XX，本科毕业，之前有七年的工作经验。之前是在两家公司任职过。

第一家，做跨境电商业务，我主要是做K8S平台的运营部署管理这些工作。

第二家，做教育类产品研发与交付，我主要负责K8S平台的管理，以及客户私有化项目的改造、交付、上线、持续运营这些工作。

然后技术方面的话，我比较擅长容器化以及K8S平台的架构设计和管理，也积累了比较丰富的线上排错经验以及性能优化的经验。同时我在CICD流水线建设、GPU调度优化、Prometheus自动服务发现、EFK平台搭建、日志性能优化方面都有落地的经验。此外我也具备一些开发能力，能独立开发Ansible Playbook和Webhook，也用Python开发过Operator控制器。

未来的话希望在云原生这个方向继续深耕发展。

K8S是自建还是用云上

面试官问：K8S都是完全是自建的吗？不是用云上的？

答：

不是完全一样的。

第一家：阿里云ACK，直接用云上的K8S
第二家：IDC机房自建K8S集群

之所以自建，是因为客户是学校，有安全性要求，必须部署在自建机房里面。

运维团队构成

面试官问：你能介绍一下运维团队的构成和分工吗？

答：

我们团队最近这家公司的构成是这样的：

Leader × 1
高级运维 × 4
驻场运维 × 若干

分工方面：

驻场运维负责客户现场日常维护
我们高级运维主要负责客户私有化项目比较多，主要是高校的一些项目，对项目进行改造上线
如果客户那边K8S平台有问题，驻场搞不定的，就会转给我们处理

客户规模

面试官问：有多少客户？

答：

我们主要是做浙江这边的，然后是有K12学校跟高校，高校大概有15家左右，每家客户都有自己独立的环境。

Flannel网卡丢失问题排查

面试官问：最近工作中K8S方面的具体问题和解决？

答：

我遇到过GPU掉卡，也遇到过Flannel网卡丢失的问题。我重点说网卡丢失这个。

问题背景

客户环境有些是买我们的机器，有些是他们已有现成环境的。这次客户已有现成环境，我们去搭K8S平台，迁移微服务过去之后，发现Pod之间访问不通，报连接性错误。

排查过程

首先用ping测试了一下，同节点访问正常，跨节点不通
排查基础配置：Flannel端口正常、DNS解析正常、网络策略正常
用TC抓包分析访问链路：
- 本端主机ES0网口：正常发出
- 对端ES0网口：能收到
- 但对端flannel.1网卡：没有收到
怀疑Overlay网络层有问题

深入定位

检查Flannel日志：无报错
用ip link查看网卡情况：
- 异常发现：每个节点的flannel MAC地址都一样（正常应该每节点不同）
- FDB表中每节点的MAC地址却不同，与网卡MAC不匹配
重启Flannel网卡：MAC地址不变，只有FDB表变化
查看Flannel源码：
- 发现它调用内核生成veth链式设备
- 然后调用系统的一个函数去生成这个MAC地址
排除生成问题：跟踪网卡注册函数，Flannel注册MAC时是正常的
怀疑被覆盖：跟踪dev_set_mac_address函数
定位根因：
- Flannel生成MAC后，仅过2秒就被NetworkManager进程修改成固定MAC
- 客户系统上跑了NetworkManager，配置里做了MAC地址归一化

解决

修改NetworkManager配置，忽略flannel网卡，不再进行MAC地址修改。

后续：部署到其他客户机房时，同步检查此问题以防再犯。

日志采集架构

面试官问：日志采集这块做过吗？遇到过什么问题？

架构

Pod日志 → Filebeat(DaemonSet) → Kafka(削峰填谷) → Loki(存储索引) → Grafana(可视化)

采集方式

DaemonSet部署Filebeat到每个节点
部分Pod没有标准化输出到宿主机目录，只在容器内输出

问题1：部分Pod无法收集

解决：开发Python Webhook，用MutatingWebhook在Pod创建时注入sidecar，收集容器内日志。

问题2：EFK架构崩溃

早期用纯EFK架构，生产者和消费者速率不匹配，消费者扛不住会崩溃。

解决：引入Kafka做削峰填谷。

数据库优化

面试官问：对数据库熟悉吗？

答：

我们有专职DBA，不是我的主要工作。但从开发和运维角度也做过：

慢查询优化
SQL语句优化
索引优化
死锁问题排查
脏数据/热数据优化

监控告警平台

面试官问：监控告警平台怎么做的？

整体架构

应用(metrics接口) ──→ Prometheus ──→ Alertmanager ──→ 钉钉/邮件/电话
                        ↓
                   Grafana(可视化)

指标采集

应用自身暴露metrics接口
MySQL/Redis/Kafka等无metrics接口的，用exporter采集后再暴露

服务发现

用Prometheus ServiceMonitor配合K8S Service注解做自动服务发现。Service打上特定注解后，Prometheus自动发现并收集。

告警

Alertmanager做去重、分组、路由
通过钉钉、邮件、电话发送

可视化

Grafana配置数据源，用Prometheus + TSDB数据源做展示。

部署规模

面试官问：系统部署规模多大？

学校客户：一般10+台机器，部署AI分析系统和人脸识别
公司SaaS平台：50+台，以K8S为主
- MySQL/Redis/Nginx：物理部署（性能要求高）
- 学校环境：用RabbitMQ Operator做自动主从复制和故障自愈

CICD和变更发布

面试官问：CICD和变更发布流程？

流水线

开发提交代码到GitLab → Jenkins触发流水线 → 单元测试 → 质量检测 → 容器镜像扫描 → 推送到Harbor

部署引入ArgoCD

原来直接部署到K8S，缺乏清单文件管理。

流程：

镜像推送到Harbor
修改GitLab清单文件
ArgoCD监听清单变化
拉取清单部署到K8S

环境策略

测试环境：自动部署
生产环境：手动点击确认部署（防止自动化风险）

灰度发布

面试官问：灰度发布怎么实现的？

网关层：Ingress-Nginx + Canary

基于请求头标签：带特定标签 → V2版本Service，不带 → V1版本

微服务层：Istio

Ingress只能做网关层灰度，Istio可以做到微服务层灰度。

Istio为需要灰度的Pod注入Sidecar，接管Pod流量。根据请求头标签匹配路由规则，DestinationRule收集各版本Pod IP列表，再路由到对应Pod。

灰度环境和生产环境通过Namespace隔离。

注入方式

Namespace级别：该Namespace下所有Pod都注入
Pod标签级别：只对带特定标签的Pod注入（我们用这种方式，只注入经常变更的Pod）

Istio的问题

每个Pod都注入Sidecar会占用集群资源。Istio官网后来出了Ambient模式（无Sidecar模式），每个节点起一个Waypoint Proxy统一管理流量，性能更好。

稳定性保障

面试官问：有没有碰到过灾难性事故，比如整个集群挂掉？

从未遇到

我们系统性的稳定性建设做得比较好，不会造成整个集群崩溃。

稳定性措施

高可用：集群本身高可用，防DDOS攻击，学校有高防，我们自己的集群也有
安全：防信息攻击，用外服做安全防护
容量规划：容器规划提前做，防止容量不足
限流熔断降级：引入限流、熔断、降级机制，防突发流量

限流熔断降级详解

限流

网关入口做，令牌桶机制。QPS超过阈值，只放行核心请求。

降级

根据流量情况关闭非核心服务，保障核心服务。

熔断

配合开发在代码框架层面做。下游服务不可用时，不再频繁访问，避免压垮下游。

网络架构

面试官问：整体网络流量路径？

外网 → WAF → DNS → 四层负载均衡(LVS) → Ingress-Nginx(HostNetwork模式) → Service(IPVS) → Pod

说明

WAF：不暴露集群内部安全给外部
DNS：解析
LVS：四层负载均衡
Ingress-Nginx：HostNetwork模式，用宿主机IP+端口
Service：通过IPVS做负载均衡到Pod

为什么用HostNetwork

HostNetwork模式每个节点都部署Ingress-Nginx（DaemonSet），流量直接到节点，不需要经过Service层转发，性能更好。而Service模式按需部署多少个Ingress Pod。

LVS和Ingress的区别

前面Ingress：做负载均衡，分发到K8S各个节点（防单点）
后面Ingress：做微服务分发，根据URL匹配不同微服务

微服务调用和健康检查

面试官问：微服务之间怎么调用？

通过Service（ClusterIP）调用
网络用Flannel或Cilium（性能要求高用Cilium）

健康检查

每个Pod配置存活探针和就绪探针。Pod不健康时从Endpoints摘除，不再有流量打过来。

限流熔断

微服务间不做限流。熔断降级是开发在代码框架层面做的，不是运维平台。

访问日志和故障定位

面试官问：线上故障怎么快速定位哪个接口慢？

监控方式

响应时间、错误率等通过黑盒监控（Prometheus）采集metrics指标，不用日志平台收集。

定位流程

告警触发：告警模板标注节点和Pod
日志排查：根据Namespace标签选择，去Grafana看该Pod详细指标
慢查询：通过慢查询日志工具查SQL语句

每台机器一般只部署一个exporter，定位到节点就知道是哪个Pod的问题。

网关日志问题排查

面试官问：遇到过网关日志问题吗？

问题

后端访问报连接性错误。

排查

网关日志报连接超时
抓包发现返回RST包

正常应该是TCP三次握手后才传数据。返回RST表示连接异常断开。

根因

IPVS超时时间设置过短（默认90秒），但网关到Service之间超时是120秒。

导致前面的连接还在，后面的连接已断开，返回RST包。

解决

调高IPVS超时时间。

总结

本文完整还原了一位7年K8s运维工程师的面试过程，涵盖了：

问题排查：Flannel网卡丢失、网关RST包问题
平台建设：日志采集、监控告警、CICD灰度发布
架构设计：网络路径、稳定性保障
日常运维：团队分工、变更发布、故障定位