K8s运维面试实录（五）：大规模集群架构与稳定性建设

前言

这是某候选人第五场K8s运维面试记录，候选人拥有3年工作经验。本场面试重点考察了大规模集群架构设计、稳定性建设、以及实际生产环境中的问题排查思路。以下为技术问题完整还原。

1. 团队规模和分工

面试官问：你们团队规模以及分工是怎样的？

答：

上家公司

嗯，我们上家公司的话，总人数大概是在120人左右。然后运维团队的话有4个高级运维，然后6个交付运维，然后还有20多个驻场运维。

分工

然后分工的话就是高级运维的话主要是负责打包项目给交付人员部署，然后还有一些驻场运维解决不了的这种疑难问题。然后交付运维的话就是现场部署，然后以及一线问题处理。

2. 请求链路（客户端到Pod）

面试官问：客户端发起请求到最终落到Pod，整个链路是怎么走的？

答：

完整链路

嗯，这个链路的话大概是这个样子的。就是客户端发起的请求，然后经过公网，然后如果有CDN的话会走CDN分配就近服务器，然后到Ingress-Nginx，然后到Service，然后到Endpoints，然后到Pod。

详细说明

然后这个Ingress-Nginx的话它是七层网关，它会解析URL然后路由到后端Service。然后Service的话是ClusterIP类型，它会做负载均衡到后端Endpoints。然后Endpoints的话就是Pod IP列表。然后最后才到Pod。

网络插件（Flannel）

然后跨节点通信的话是通过Flannel的三个表。一个是路由表，它会判断目标是否跨节点。然后ARP表的话是Pod网段到flannel MAC的映射。然后FDB表的话是flannel MAC到宿主机IP的映射。

大规模流量下的瓶颈

然后如果是大规模流量的话，最先出现的瓶颈是在API Server和ETCD这一块。

3. 大规模流量K8S瓶颈分析

面试官问：假设流量上升很多，最先出现的瓶颈在哪里？

答：

瓶颈分析

嗯，这个的话最先出现的瓶颈是API Server加ETCD这一块。

因为API Server它要集群模式部署的，要3节点以上。然后ETCD的话它是用Raft算法，需要半数以上节点。然后ETCD的话必须要用高性能SSD，就是IOPS要大于等于10K的。

然后第二个的话就是连接跟踪表，就是conntrack。因为请求进来会占用conntrack表项，然后需要开启ipv4转发优化。

应对方案

1. 集群拆分

然后应对方案的话，一个是可以做集群拆分。按业务域划分的话，可以分为算力集群、通用业务集群、灰度验证集群。按地域划分的话，可以分为华东、华北、华南这些。

2. 统一调度

然后可以使用联邦调度方案，比如说用KubeFed，或者Commander，或者自研组件。

3. 横向扩展

然后横向扩展就是节点横向扩展，然后提升容灾隔离性。

4. ETCD优化策略

面试官问：ETCD有哪些优化策略？

答：

部署优化

嗯，ETCD优化的话首先从部署方面来说的话，API Server和ETCD必须独立部署。然后每个ETCD节点的话要固定CPU和内存。然后要用高性能SSD，就是NVMe盘，IOPS要大于等于10K。然后网络的话要低延迟的，就是RTT延迟要低，然后内网调度。

读性能优化

然后读性能优化方面的话，可以用gRPC gateway来提升读性能，然后增量拉取，就是incremental fetch。

参数优化

然后参数优化的话主要是那个max-request-bytes，然后snapshot-count这些。

K8S组件优化

然后K8S组件优化的话，一个是我们可以调整Kube-controller-manager的这个参数，就是concurrent-deployment-syncs，控制并发同步数。然后还有Leader election加worker合并，减少事件风暴。

然后Kubelet心跳优化的话，有node-monitor-grace-period，默认是40秒，然后node-monitor-period，默认是10秒，可以调到30秒来减轻压力。

定期清理

然后还有的话就是定期删除无用CRD，然后清理测试灰度环境残留资源。

5. K8S List-Watch机制与Informer

面试官问：K8S的List-Watch机制是什么？

答：

List-Watch流程

嗯，List-Watch机制的话，首先客户端到API Server，然后List获取全量数据，然后Watch增量事件。然后存到Informer缓存，然后到Index索引，然后到Worker处理。

组件说明

然后主要组件的话有这些。一个是Reflector，它是做List和Watch API Server的。然后Store是存储数据到缓存的。然后Indexer是提供索引功能的。然后Work Queue是事件队列。然后Worker是处理业务逻辑的。

问题：事件风暴

然后如果是大量Pod频繁变化的话，会导致事件风暴。可以通过Leader election合并事件，还有Worker合并处理。

6. 网络插件对比

面试官问：Flannel、Calico、Cilium、eBPF这些网络插件有什么区别？

答：

Flannel

嗯，Flannel的话主要是两种模式。一种是Overlay模式，就是VXLAN，这个的话性能较低，需要封装解封装。然后还有Host-GW模式，这个性能好，但是需要二层网络互通。然后Flannel的话所有路由都存ETCD，压力比较大。适合小规模集群，就是小于500节点的。

Calico

然后Calico的话，它是使用BGP协议，分布式路由，分发到每台主机。然后它是纯三层转发，无需封装，性能好。

然后Calico组件的话主要是两个。一个是Felix，它运行在每个节点，通过DaemonSet部署，负责在节点上写路由规则和网卡ACL。然后Bird是BGP路由守护进程，将本节点Pod路由广播给其他节点。

然后Calico还有IPIP模式，是三层封装的，可以跨网段通信。

Calico vs Flannel

然后对比的话，Flannel性能较低，路由存在ETCD，网络策略基础，适用小规模。Calico的话性能高，路由存在本地BGP，网络策略丰富，适用大规模。

Cilium/eBPF

然后Cilium和eBPF的话，它是内核态处理，直接在网卡驱动层处理。然后无需封包，性能最高。然后还支持七层网络策略。

选型建议

然后选型建议的话，小规模用Flannel，大规模高性能用Calico，极高性能或七层需求用Cilium。

7. Calico BGP模式原理

面试官问：Calico的BGP模式是怎么工作的？

答：

架构

嗯，Calico的话主要是两个组件。一个是Felix，它运行在每个节点，通过DaemonSet部署，负责在节点上写路由规则和网卡ACL。然后Bird是BGP路由守护进程，将本节点Pod路由广播给其他节点。

通信流程

然后通信流程的话，首先Pod A发包，然后到veth pair，然后到宿主机网卡。然后通过路由表判断下一跳，然后通过IPIP隧道（跨网段）或直接路由（本地），然后到达目标节点，然后veth pair，然后到Pod B。

为什么快

然后Calico为什么快呢，主要是因为它是纯三层转发，无需Flannel的封装解封装。然后BGP动态分发路由，每个节点都知道全局路由。数据平面直连，Pod数据直接通过主机路由转发。

规则多时的问题

然后当路由规则非常多的时候，匹配会变慢。这个时候需要按业务域或地域划分AS，就是自治系统。

8. 容器化改造思路

面试官问：大量业务要上K8S，怎么做容器化改造？

答：

代码层面

嗯，容器化改造的话首先是代码层面。一个是要处理僵尸进程，引入Tini回收僵尸进程，然后代码层面修复GC回收问题。

然后镜像优化的话，主要是合并RUN、MV命令减少层数，然后删除无用文件和依赖。

服务分类

然后服务的话是按业务重要性分三个优先级。核心服务的话是4核8G或8核16G，多副本，有PDB保护，高QoS。中等服务的话是正常配置，正常副本，正常调度。低优先级的话可以单副本，可以超卖，可以接受一定停机。

上线流程

然后上线流程的话，核心服务优先部署。然后一比一部署，不切流量。然后配置PDB保护。然后高优先级服务亲和反亲和均匀调度。然后逐步切流量。

9. K8S集群规划

面试官问：集群规模规划怎么做？

答：

资源配置模板

嗯，核心服务的话是4核8G或8核16G。中间的话是根据实际需求。低优先级的话允许超卖。

调度策略

然后调度策略的话，核心服务的话有PDB保护，高QoS，就是Guaranteed，然后亲和反亲和分散调度。低优先级服务的话允许单副本，可以超卖，停机不影响业务。

集群拆分

然后集群拆分的话，按业务域可以分为算力集群、通用业务集群、灰度集群。按地域的话分为华东、华北、华南。然后通过联邦调度统一管理。

10. 监控体系搭建

面试官问：监控体系怎么搭？

答：

监控维度

嗯，监控维度的话主要是三个方面。基础设施层的话是节点CPU、内存、磁盘、IO，还有K8S组件API Server、ETCD、Scheduler、Kubelet。然后应用层的话是业务指标QPS、延迟、状态码，还有进程端口，数据库指标。然后网络层的话是上下行带宽和连接数。

技术方案

然后技术方案的话，指标是用Prometheus Operator或vmagent。然后模式的话是ServiceMonitor加LabelSelector。然后展示用Grafana，告警用Alertmanager。

黑盒监控

然后黑盒监控的话是用Blackbox Exporter，监控域名证书，HTTP、TCP探活，还有状态码。

告警优化

然后告警优化的话，一个是抑制，避免重复告警。然后降噪，聚合相似告警。然后升级，一层告警，十分钟无响应，升到上一层。

11. 数据库不放容器的原因

面试官问：数据库为什么建议物理部署？

答：

嗯，数据库不放容器的话主要是三个原因。

性能问题

一个是性能问题。数据库是高IO密集型服务，然后容器网络会有性能损耗。

数据一致性

然后第二个的话是数据一致性。容器调度可能导致数据不一致，然后存储卷管理复杂。

资源隔离

然后第三个的话是资源隔离。CPU、内存、IO需要稳定保障，然后容器共享宿主机资源。

应该监控的数据库指标

然后数据库应该监控的话是CPU、内存使用率，连接数，QPS，还有慢查询。

12. 告警抑制与MTTR

面试官问：告警管理怎么做？

答：

告警升级机制

嗯，告警升级机制的话是这个样子的。告警触发后，一线人员接收，十分钟无响应就升级二线，二十分钟再无响应就升级管理层。

MTTR（Mean Time To Recovery）

然后MTTR的话，就是定义SLO，就是Service Level Objective，还有SLI，就是Service Level Indicator。然后计算各服务MTTR。然后纳入绩效考核。

监控抑制策略

然后监控抑制策略的话，就是相同告警合并，维护窗口抑制，还有告警收敛。

13. 灰度发布

面试官问：灰度发布怎么做？

答：

两种方式

嗯，灰度发布的话主要是两种方式。

1. 标签灰度

一种的话是通过请求头标签区分用户，比如说领优惠券用户进入测试环境。

2. 权重灰度

然后还一种是权重灰度，按百分比分配流量，逐步提高新版本权重。

使用场景

然后使用场景的话是新功能验证，A/B测试，还有故障回滚。

14. 入口网关选型

面试官问：入口网关怎么选？

答：

小规模

嗯，小规模的话架构是LVS，就是DR模式，然后到Ingress-Nginx，然后到Service，然后到Pod。

大规模

然后大规模的话有两种方案。

方案1：动静分离

一种是动静分离。静态资源走CDN，动态请求走LVS然后到Ingress然后到K8S。

方案2：全站托管

然后还一种是全站托管，直接使用云厂商API网关，比如说阿里云。

LVS DR模式

然后LVS DR模式的话是基于MAC欺骗，请求到RS后，响应直接从RS返回客户端，性能高。

网关限流

然后网关限流的话，令牌桶算法是限流，漏桶算法是超过阈值直接丢弃。超过容量自动触发降级。

15. 动静分离与CDN

面试官问：动静分离怎么做？

答：

静态资源

嗯，静态资源的话是图片、视频、CSS、JS，走CDN分发，缓存到边缘节点。

动态资源

然后动态资源的话是API请求、数据库查询，走K8S集群。

架构

然后架构的话就是用户请求先到CDN，CDN判断就近接入。静态资源的话CDN边缘节点直接返回，动态资源的话回源到K8S集群。

优势

然后优势的话是降低K8S集群压力，提升用户访问速度，节省带宽成本。

总结

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

架构设计：请求链路、大规模集群拆分
深度优化：ETCD优化、List-Watch机制、心跳优化
网络插件：Flannel/Calico/Cilium对比
容器化改造：服务分类、镜像优化、上线流程
稳定性建设：监控体系、告警管理、MTTR
发布策略：灰度发布、入口网关选型
成本优化：动静分离、CDN