完美世界云原生‑K8s高频题精简参考答案

适配：游戏后台、大数据Flink/Spark‑on‑K8s、容器+虚拟机混合架构，答案偏向实战，可以直接口述。

一、基础必问

1.k8s核心组件作用

  1. kube‑apiserver：集群唯一入口，所有操作都走它，校验、转发请求，读写etcd；无状态可多实例高可用。
  2. etcd：分布式键值存储，集群所有元数据，唯一持久化存储；必须高可用。
  3. controller‑manager：各类控制器，Deployment、Node、副本数维持，不断调谐，让实际状态等于期望状态。
  4. scheduler：调度器，监听新建Pod，挑选合适Node节点进行绑定。
  5. kubelet：每个节点上的代理，和apiserver通信，管理本机Pod生命周期，容器启停、状态上报。
  6. kube‑proxy：节点网络代理，维护Service转发规则(iptables/ipvs)，实现Service集群内负载均衡。

2.Pod、Deployment、StatefulSet、DaemonSet、Job、CronJob适用场景，游戏后台

  • Pod：最小调度单元，一般不直接创建。
  • Deployment：无状态服务，游戏后台运营服务、网关、web中台服务；支持滚动更新、扩缩容。
  • StatefulSet：有状态服务，稳定网络标识、稳定存储；数据库、消息队列。游戏战斗长连接一般不上k8s。
  • DaemonSet：每个节点跑一个Pod；日志采集、监控agent。
  • Job：一次性离线任务；一次性数据导出。
  • CronJob：定时任务；凌晨定时报表、游戏定时活动任务。

游戏后台无状态服务优先用Deployment。

3.Service 4种类型

  1. ClusterIP（默认）：集群内部可访问，仅Pod之间调用；微服务之间调用首选。
  2. NodePort：宿主机端口暴露，节点IP+端口访问；测试环境临时对外。
  3. LoadBalancer：云厂商负载均衡器，公网流量入口。
  4. ExternalName：服务别名，集群内访问外部域名。

4.Ingress是什么？Ingress与Service区别，控制器

  • Service：四层负载均衡；Ingress：七层http/https反向代理。
  • Service提供集群内访问；Ingress把外部http流量路由到后端Service。
  • 常用控制器：Nginx‑Ingress‑Controller、Traefik。

5.Label、Selector、Annotation、Taint、Toleration

  • Label：给资源打标签键值对；用于筛选。
  • Selector：标签选择器，根据标签匹配资源。
  • Annotation：注解，附加描述信息，不能用于筛选。
  • Taint污点：打在节点上，拒绝Pod调度到此节点，除非Pod有对应容忍。
  • Toleration容忍：Pod上配置，允许调度到带对应污点的节点。

6.Request、Limit，QoS，OOM驱逐优先级

  • Request：Pod申请最少资源，调度依据；节点剩余资源判断是否可以调度。
  • Limit：Pod最大可用资源，超过会被限流(Cpu)或者OOM杀死(内存)。 QoS三级（从高到低）：
  1. Guaranteed：Request=Limit；最高优先级，最后被驱逐。
  2. Burstable：Request<Limit；中间。
  3. Best‑Effort：没设置Request/Limit；最低优先级，最先驱逐。

7.RestartPolicy，和Deployment关系

三种：

  • Always：容器退出永远重启（Deployment默认）
  • OnFailure：异常退出才重启，成功退出不重启（Job）
  • Never：退出后绝不重启Deployment只能用Always，不能修改。

8.ConfigMap、Secret区别，Secret加密？生产密码方案

  • ConfigMap：存放普通配置明文；不能存密码。
  • Secret：存放敏感数据；etcd中只是base64编码，不是加密！生产密码方案：外部密钥管理服务（Vault）、云厂商密钥管理，不要单纯放Secret。

二、调度&高级编排（大数据高频）

1.污点容忍、节点亲和、Pod反亲和；业务场景

  • 节点亲和性：指定Pod调度带特定标签节点；例如大数据任务只调度到大数据节点池。
  • Pod反亲和性：不允许一批Pod落在同一个宿主机；核心后台服务打散，单点故障不会全部挂掉。
  • 污点+容忍：节点隔离；在线业务节点打上污点，离线大数据任务没有容忍就不会跑上来抢占资源。

2.PodDisruptionBudget(PDB)作用

用来限制自愿驱逐的最大Pod数量；节点排空、集群维护时，保证最少可用副本数。

适用：Flink实时长任务，核心后台服务，避免一次性大量实例被驱逐，业务中断。 注意：不能防止OOM、节点宕机这种非自愿驱逐。

3.默认调度器短板，Spark一次性上千Executor Pod问题，Volcano/Gang调度

默认调度器是最优适配逐个调度，不感知任务组；一次性提交上千Spark Pod会出现：部分Pod调度成功、部分资源不足；任务跑起来缺资源卡住。

  • Gang调度（组队调度）：一组Pod要么全部调度成功，一个都不能少；否则全部等待。
  • Volcano：K8s大数据批量调度器，支持gang调度、任务优先级、队列资源隔离；适合Spark/Flink离线批量任务。

4.PriorityClass优先级；在线离线混部隔离

PriorityClass给Pod设置优先级数值。 在线业务（游戏后台、实时Flink）设置高优先级；离线Spark大数据任务低优先级。资源紧张时，低优先级离线Pod会被抢占，保障在线业务资源。

5.在线服务、大数据任务节点池隔离方案

两种主流方案，一般一起用：

  1. 给节点打上标签，节点亲和：在线Pod调度在线节点，大数据Pod调度大数据节点。
  2. 大数据节点打上污点，只有大数据Pod带容忍才能调度；从根源阻止在线离线混跑。

三、存储

1.PV、PVC、StorageClass动态供给

  • PV：集群内存储资源；管理员预先创建。
  • PVC：用户存储申请；Pod挂载使用。
  • StorageClass：存储模板，实现动态供给：用户提交PVC，k8s自动创建对应的PV，不需要人工提前创建。

2.LocalPV适用场景；Spark‑Shuffle、Flink‑Checkpoint风险

LocalPV=宿主机本地磁盘；读写速度快，无网络开销。 Spark Shuffle适合LocalPV；

风险：Pod漂移到别的节点，本地盘数据不会跟着迁移；Flink Checkpoint如果用LocalPV，故障迁移会丢checkpoint；生产Checkpoint优先用共享存储（对象存储、NAS）。

3.游戏后台日志落地方案

  1. 容器标准输出stdout，节点部署日志采集器(Promtail/Fluentd)采集，存到Loki/Elasticsearch；简单易维护。
  2. 挂载宿主机日志卷，日志输出到文件；适合日志量极大业务；缺点需要管理磁盘生命周期。优先标准输出方案。

4.为什么长连接游戏战斗服不建议跑k8s

  1. Pod漂移、驱逐、节点维护会导致Pod重建，玩家长连接直接断开。
  2. 调度、资源抢占带来网络抖动，影响游戏延迟。
  3. 有状态会话存在内存中，漂移后会话丢失；状态迁移成本极高。完美方案：战斗服虚拟机；后台无状态运营服务、数据分析跑k8s。

四、网络

1.Pod通信原理；CNI插件

k8s所有Pod之间默认三层互通；CNI负责给Pod分配IP，配置网络。 常用CNI：Calico、Flannel。Calico支持NetworkPolicy网络策略。

2.iptables vs ipvs；大规模集群选择

  • iptables：简单，性能差；几千条规则后延迟上升。小规模集群。
  • ipvs：内核四层负载均衡；哈希表，大规模Service性能好。大规模集群优先ipvs模式。

3.NetworkPolicy

网络防火墙策略；控制Pod之间、Pod与外部的访问权限；实现Pod网络隔离。

4.内外访问链路

Pod访问外部：经过节点SNAT；外部访问Pod：Ingress七层 -> Service四层 -> 后端Pod。

五、监控日志告警（高频）

1.Prometheus监控k8s架构、核心指标

采集组件：kube‑state‑metrics、node‑exporter、cAdvisor。 核心指标： 节点：CPU、内存、磁盘、网络； Pod：CPU使用率、内存使用率、OOM次数、重启次数、CPU节流； 控制器：副本就绪数； etcd、apiserver延迟指标。

2.常见告警项

CrashLoopBackOff、OOMKilled、Pod重启次数过高、CPU节流(cpu‑cfs‑throttling)、节点NotReady、副本就绪数不足、etcd健康异常。

3.日志：标准输出 vs 文件挂载

  • stdout：运维简单，统一采集；推荐容器方案。
  • 日志文件挂载：适合超大日志量；但需要管理磁盘空间、日志切割。

4.Flink/Spark on k8s指标接入Prometheus

开启Flink/Spark内置Prometheus监控，暴露metrics端口；Pod内指标端口被Prometheus抓取；或使用Jmx‑Exporter。

六、Spark‑on‑K8s / Flink‑on‑K8s

1.Spark‑on‑K8s Client / Cluster模式，生产选择

  • Client：Driver跑在提交客户端机器；客户端断开任务失败；适合调试。
  • Cluster：Driver也作为Pod运行在k8s集群；客户端退出不影响任务；生产环境优先Cluster模式。

2.Flink on k8s Session / Application模式

  1. Session模式：预先启动一个长驻Flink集群，多个任务提交上去；适合大量小实时任务，资源复用。
  2. Application模式：每个任务启动一套独立集群；任务结束资源释放；任务之间完全隔离；适合大任务。 Flink‑Operator：CRD方式管理Flink任务生命周期，现在主流生产方案。

3.如何防止Flink长任务被驱逐

  1. 设置充足的Request资源，拉高QoS等级(Guaranteed)。
  2. 配置PDB，保障最小可用TaskManager副本。
  3. 离线任务节点打污点，不和低优先级离线任务混部。
  4. 设置高PriorityClass。

4.Spark Executor跑完没自动删除排查

  1. Spark程序本身异常退出，没有正常关闭资源；
  2. K8s API权限不足，Spark Driver无法删除Executor Pod；
  3. 网络问题Driver和apiserver通信失败。

5.在线离线混部风险、资源隔离

风险：离线大任务突发抢占CPU内存，造成在线业务卡顿、CPU节流。 隔离方案：节点池物理隔离、PriorityClass优先级抢占、资源Quota命名空间资源限制、Volcano任务队列。

七、CI/CD DevOps

1.代码提交到上线流水线示例

Git提交代码 → Gitlab‑CI/Jenkins拉取源码、编译、单元测试 → 构建镜像推送镜像仓库 → Helm更新release / ArgoCD同步 → K8s拉取镜像滚动发布 → 自动化冒烟测试、监控校验。

2.金丝雀(灰度)、蓝绿发布，k8s实现

  • 蓝绿：两套完全一样环境；新版本(绿)部署完成，流量一次性全部切过去；回滚快；资源占用翻倍。Deployment双部署+切换Service selector。
  • 金丝雀灰度：一小部分流量切到新版本；Ingress灰度流量，或者部署少量灰度Pod。

3.Helm3，helm2区别；生产管理Chart

Helm3移除了Tiller组件；权限模型更安全。 生产：Chart存私有Chart仓库；环境区分values.yaml(dev/test/prod)；版本管理，发布回滚。

4.多集群管理；KubeSphere

多集群方案：

  1. 联邦集群；
  2. 中央管理平台，统一接入各个集群kubeconfig，独立管理； KubeSphere：可视化容器管理平台，提供多集群、租户、监控、流水线一站式界面。

八、故障排查（口述按步骤说）

1.Pod Pending排查步骤

  1. kubectl describe pod xxx，看事件events；
  2. 常见原因：资源不足、污点容忍不匹配、节点亲和没匹配、PVC存储未绑定、镜像拉取失败；
  3. 逐一对应解决。

2.CrashLoopBackOff排查

  1. kubectl describe pod，看事件；
  2. kubectl logs 查看容器日志，找应用崩溃报错；
  3. 检查资源Limit是否OOM；
  4. 进入容器手动启动程序，复现问题。

3.突然OOM被杀排查

  1. 查看Pod日志，事件里OOMKilled；
  2. 监控看内存曲线，判断是突增还是内存泄漏；
  3. 分析应用程序内存使用；
  4. 调高内存Limit；或者优化程序；核对Request/Limit配置。

4.容器内部访问不通，宿主机访问正常

排查方向：

  1. 容器网络DNS解析；
  2. Service Endpoint后端Pod是否就绪；
  3. 安全组、NetworkPolicy策略拦截；
  4. kube‑proxy规则异常。

5.Node NotReady，集群现象，多久驱逐Pod

节点失联后，controller‑manager默认**5分钟(eviction‑timeout)**后，标记节点上Pod为Terminating，在其他节点重建Pod。 现象：节点上业务不可用，等待超时后漂移重建。

6.etcd故障影响；大规模集群优化

etcd故障 → apiserver读不到集群元数据；集群只读、无法新建/更新Pod；严重整个集群瘫痪。 优化：3/5节点高可用；独立服务器部署；SSD磁盘；定期备份etcd；限流apiserver请求。

7.apiserver压力高；上千Pod同时启动压垮apiserver

原因：大量Pod创建、list‑watch请求打满apiserver； 优化：客户端限流、分批启动任务；使用队列调度(Volcano)；apiserver扩容；缓存优化。

九、游戏行业特色题（完美重点）

1.容器虚拟机混合架构，统一监控发布

现状：战斗服‑虚拟机；后台‑k8s容器。 监控：统一监控平台；虚拟机node‑exporter；容器cAdvisor+kube‑state‑metrics，统一接入Prometheus。 发布：一套CI/CD流水线，区分部署目标：虚拟机走ansible，容器走helm发布。

2.长连接服务是否适合k8s，风险点

不建议；风险：Pod驱逐漂移、重建断开玩家长连接；会话在内存丢失；调度抖动带来延迟。

3.凌晨Spark瞬时大量Pod，白天保障在线/Flink资源

方案：

  1. 节点池隔离，离线任务单独节点；
  2. PriorityClass，离线任务低优先级；白天资源紧张离线任务被抢占让出资源；
  3. Volcano设置离线任务运行窗口，凌晨优先调度大计算任务。

4.游戏后台服务迁移上k8s方案、回滚

迁移步骤：

  1. 评估无状态后台服务；先测试环境部署；
  2. 双跑新旧两套服务；流量切一小部分验证；
  3. 逐步全量切流；观察监控指标； 回滚方案：流量切回旧虚拟机服务；停止k8s上新版本。

十、高阶开放问题（高级SRE/平台）

1.设计后台云原生平台，集群划分方案

推荐业务隔离多集群方案：开发集群、测试集群、预发集群、生产集群；生产内部在线业务集群、大数据离线集群分开。优点故障隔离，互不影响。

2.K8s高可用master部署

3个master节点；apiserver多实例负载均衡；controller‑manager、scheduler开启leader选举；etcd三节点高可用。

3.RBAC权限管控、多租户隔离

命名空间做租户资源隔离；RBAC绑定不同角色权限；ResourceQuota限制命名空间最大资源；NetworkPolicy网络隔离。

4.etcd备份与灾难恢复

定时快照备份etcd；灾难恢复：停止所有apiserver，使用备份快照恢复etcd数据；恢复后校验集群资源状态，定期做灾难演练。

十一、加分话术（面试主动带上）

我们容器平台采用虚拟机+容器混合架构；游戏战斗服部署在虚拟机；后台运营、玩家日志分析、实时风控Flink跑在K8s；大数据离线Spark任务通过Volcano调度，在线业务高优先级保障，在线离线资源隔离。

上一篇
下一篇