云原生运维面试 Q&A

来源：整理自 temp/云原生 目录，覆盖 K8s 基础概念、Istio/Service Mesh、K8s 核心资源、网络与安全、调度与资源管理、Prometheus 监控体系、大厂高阶题七大模块。

零、K8s 基础概念（必考）

Q0：K8s 是什么？解决什么问题？

A：

K8s（Kubernetes） 是一个开源的容器编排平台，用于自动化部署、扩缩容和管理容器化应用。

解决的核心问题：

问题	K8s 的解法
容器部署繁琐，手动管理几十上百个容器不现实	声明式 API，描述"期望状态"，K8s 自动收敛
容器故障后需要人工重启	自动重启、自愈（Self-healing）
流量增大时需要手动扩容	HPA 自动水平扩缩容
多台机器上如何合理分配容器	Scheduler 自动调度，资源利用率最大化
服务发现和负载均衡	Service + DNS，屏蔽 Pod IP 变化
滚动升级、回滚	Deployment 滚动更新策略，一键回滚
配置和密钥管理	ConfigMap / Secret 与容器解耦

Q00：Pod 是什么？为什么 K8s 的最小调度单位是 Pod 而不是容器？

A：

Pod 是 K8s 的最小部署单元，一个 Pod 内可以包含一个或多个容器，这些容器：

共享同一个 Network Namespace（同一 IP、同一端口空间）
共享同一个 IPC Namespace（可以用共享内存通信）
可以共享 Volume（挂载同一个存储卷）

为什么不是容器？

紧耦合容器的需求：有些应用天然需要多个容器协作，比如主容器 + Sidecar（日志采集、Envoy 代理）。它们需要共享网络和存储，必须调度到同一节点，Pod 是这种"共生关系"的抽象。
网络模型简化：Pod 内容器共享 IP，容器间通过 localhost 通信，避免了复杂的跨容器网络配置。
原子调度：Pod 作为整体被调度，保证紧耦合容器一定在同一节点，不会出现"主容器在 A 节点，Sidecar 在 B 节点"的情况。

pause 容器：每个 Pod 都有一个隐藏的 pause 容器，它持有 Pod 的 Network Namespace，其他容器加入它的网络，这样即使业务容器重启，Pod IP 也不变。

Q01：K8s 的核心组件有哪些？各自做什么？

A：

控制平面（Control Plane）：

组件	作用
kube-apiserver	集群的唯一入口，所有操作（kubectl、组件间通信）都通过它；负责认证、授权、准入控制；etcd 的唯一访问者
etcd	分布式 KV 存储，保存集群所有状态（Pod、Service、ConfigMap 等）；强一致性，基于 Raft 协议
kube-scheduler	监听未调度的 Pod，根据资源、亲和性、污点等策略选择最合适的节点，写入 Pod 的 `nodeName` 字段
kube-controller-manager	运行一组控制器（Deployment Controller、ReplicaSet Controller、Node Controller 等），持续对比"期望状态"和"实际状态"，驱动收敛

工作节点（Node）：

组件	作用
kubelet	节点上的"代理"，监听 apiserver 分配给本节点的 Pod，调用容器运行时（containerd/Docker）创建容器，上报节点和 Pod 状态，执行健康检查
kube-proxy	维护节点上的网络规则（iptables/IPVS），实现 Service 的流量转发和负载均衡
容器运行时	实际运行容器（containerd、CRI-O），K8s 通过 CRI 接口调用

一句话记忆：apiserver 是大脑入口，etcd 是数据库，scheduler 是调度员，controller-manager 是自动化运维机器人，kubelet 是节点管家，kube-proxy 是节点网络员。

Q02：Service 有几种类型？区别是什么？

A：

类型	访问范围	说明
ClusterIP（默认）	仅集群内部	分配一个虚拟 IP，只能在集群内访问，适合服务间调用
NodePort	集群外部（通过节点 IP）	在每个节点上开放一个端口（30000-32767），外部通过 `NodeIP:NodePort` 访问，适合测试环境
LoadBalancer	集群外部（通过云 LB）	在 NodePort 基础上，自动创建云厂商负载均衡器（如华为云 ELB），生产环境对外暴露服务的标准方式
ExternalName	集群内部访问外部服务	将 Service 映射到外部 DNS 名称，返回 CNAME 记录，用于访问集群外的服务（如外部数据库）

Headless Service（clusterIP: None）：不分配 VIP，DNS 直接返回 Pod IP 列表，StatefulSet 专用。

Q03：Ingress 和 Service 有什么区别？Ingress Controller 是什么？

A：

维度	Service	Ingress
工作层	L4（TCP/UDP）	L7（HTTP/HTTPS）
路由能力	只能按端口转发	支持按 Host、Path 路由到不同 Service
TLS 终止	不支持	支持，统一管理证书
典型场景	服务间内部调用	对外暴露多个 HTTP 服务，统一入口

Ingress Controller：Ingress 资源本身只是规则定义，需要 Ingress Controller 来实现这些规则。Controller 监听 Ingress 资源变化，动态更新反向代理配置。

常见实现：Nginx Ingress Controller、Traefik、华为 CCE ELB Ingress Controller。

类比：Ingress 是"路由规则表"，Ingress Controller 是"真正干活的反向代理服务器"。

Q04：Label 和 Selector 的作用？Namespace 用来干什么？

A：

Label（标签）：附加在 K8s 资源上的键值对，如 app: nginx、env: prod，本身不影响资源行为，用于标识和分类。

Selector（选择器）：通过标签筛选资源，是 K8s 中资源关联的核心机制：

Service 通过 selector 找到后端 Pod
Deployment 通过 selector 管理 ReplicaSet
NetworkPolicy 通过 podSelector 选择目标 Pod

Namespace：集群内的逻辑隔离单元，用于：

资源隔离：不同团队/项目的资源分开管理，避免命名冲突
权限控制：RBAC 的 Role/RoleBinding 作用在 Namespace 级别，实现多租户权限隔离
资源配额：通过 ResourceQuota 限制某个 Namespace 的 CPU/内存总量
网络隔离：配合 NetworkPolicy 实现跨 Namespace 的访问控制

与用户权限配合：通过 RoleBinding 将用户绑定到特定 Namespace 的 Role，用户只能操作该 Namespace 内的资源，无法跨 Namespace 访问。

Q05：Pod 的重启策略有哪些？

A：

通过 spec.restartPolicy 配置，有三种：

策略	行为	适用场景
Always（默认）	容器退出（无论成功或失败）都重启	Deployment、StatefulSet，长期运行的服务
OnFailure	只有容器异常退出（exit 非 0）才重启，正常退出不重启	Job，批处理任务，失败需重试但成功后不重启
Never	无论如何都不重启	一次性任务，调试场景

注意：重启有退避机制（Exponential Backoff），连续失败后等待时间依次为 10s、20s、40s...最长 5 分钟，避免频繁重启消耗资源，这就是 CrashLoopBackOff 状态的原因。

一、Istio / Service Mesh 概念

Q1：用通俗的方式解释 Istio 和 Service Mesh 是什么？

A：

把微服务集群比作一个小区：

Pod = 小区住户
Istio = 物业公司，统一管理所有住户的进出、通信规则
Sidecar（Envoy） = 物业给每个住户配的保镖，住户进出门、串门、打电话都由保镖代理，住户本身感知不到
Service Mesh（服务网格） = 住户之间串门的路线汇聚成一张网，这张网就是服务网格，本质是所有服务间通信的集合
Gateway = 小区大门 + 保安，外部流量（快递、外卖）进来必须先过这一关，对应 Istio Ingress Gateway
VirtualService = 小区交警，控制客人去哪栋楼、哪层、超时几秒，对应流量路由规则（路由、重试、超时、故障注入）
DestinationRule = 物业老板定的家法，比如这栋楼最多接待 100 人，对应连接池限制、熔断策略、负载均衡算法

核心价值：把服务间通信的治理（负载均衡、熔断、限流、链路追踪、mTLS）从业务代码里剥离出来，下沉到基础设施层，业务代码零侵入。

Q2：Istio 和普通 Ingress 的区别是什么？

A：

维度	普通 Ingress	Istio Gateway + VirtualService
作用范围	仅处理南北向（外部→集群）流量	南北向 + 东西向（服务间）流量全覆盖
流量控制粒度	基于 Host/Path 路由	支持权重、Header、熔断、重试、超时、故障注入
可观测性	依赖 Ingress Controller 自身	全链路 Trace（Jaeger/Zipkin）、Metrics、访问日志开箱即用
安全	TLS 终止	mTLS 双向认证，服务间通信加密
实现方式	Nginx/Traefik 等 Controller	Envoy Sidecar 代理

一句话：普通 Ingress 只管"门"，Istio 管整个小区所有人的通信。

Q3：Sidecar 模式的原理是什么？有什么优缺点？

A：

原理：Istio 通过 MutatingWebhook 在 Pod 创建时自动注入 Envoy 容器，并用 iptables 规则将 Pod 的所有入站/出站流量劫持到 Envoy，业务容器无感知。

优点：

业务代码零侵入，语言无关
统一治理：限流、熔断、mTLS、链路追踪集中配置
独立升级，不影响业务

缺点：

每个 Pod 多一个 Envoy 容器，增加内存和 CPU 开销（通常 50~100MB/Pod）
增加网络跳数，引入轻微延迟（通常 < 1ms）
调试复杂度上升

二、K8s 核心资源

Q4：Pod 的生命周期有哪些阶段？

A：

阶段	含义
Pending	Pod 已被 API Server 接受，但容器还未启动（等待调度或镜像拉取）
Running	Pod 已绑定节点，至少一个容器在运行
Succeeded	所有容器正常退出（exit 0），不会重启，常见于 Job
Failed	所有容器已退出，至少一个异常退出（exit 非 0）
Unknown	无法获取 Pod 状态，通常是节点通信问题

容器状态（与 Pod 阶段不同）：Waiting / Running / Terminated

关键探针：

livenessProbe：失败则重启容器
readinessProbe：失败则从 Service Endpoints 摘除，不接收流量
startupProbe：启动慢的应用用这个，避免 liveness 误杀

Q5：Deployment 和 StatefulSet 的区别是什么？各什么时候用？

A：

维度	Deployment	StatefulSet
Pod 标识	随机 hash 后缀，无固定身份	固定序号（pod-0、pod-1），身份稳定
存储	共享或无状态	每个 Pod 独立 PVC，重建后数据不丢
启动/停止顺序	并行，无顺序保证	有序启动（0→1→2），有序停止（2→1→0）
网络标识	ClusterIP Service	Headless Service，每个 Pod 有独立 DNS
典型场景	Web 服务、API 服务、无状态微服务	MySQL、Redis Cluster、Kafka、ES、ZooKeeper

选择原则：服务实例之间是否有区别 → 有区别（主从、分片）用 StatefulSet，无区别用 Deployment。

Q6：DaemonSet 的典型使用场景？

A：

DaemonSet 保证每个（或指定）节点上运行且仅运行一个 Pod 副本，节点加入集群时自动部署。

典型场景：

日志采集：Filebeat、Fluentd，每个节点采集本节点日志
监控采集：node-exporter，采集节点级别的 CPU/内存/磁盘指标
网络插件：Calico、Cilium、Flannel 的 agent，每个节点都需要
存储插件：Ceph CSI、GlusterFS 客户端
安全扫描：Falco 运行时安全检测

Q7：ConfigMap 和 Secret 的区别？

A：

维度	ConfigMap	Secret
用途	存储非敏感配置（环境变量、配置文件）	存储敏感信息（密码、Token、证书）
存储方式	明文	Base64 编码（注意：不是加密）
etcd 加密	默认不加密	可配置 etcd 静态加密（EncryptionConfiguration）
挂载方式	环境变量 / Volume 文件	同左，但建议用 Volume 避免 env 泄露

注意：Secret 的 Base64 只是编码不是加密，生产环境建议配合 Vault 或 KMS 做真正的加密管理。

Q8：Volume、PV、PVC、StorageClass 的关系是什么？

A：

StorageClass（存储类，定义"怎么创建"）
    ↓ 动态制备
PV（Persistent Volume，集群级别的存储资源，管理员创建或动态创建）
    ↓ 绑定（1:1）
PVC（Persistent Volume Claim，命名空间级别，Pod 的存储申请）
    ↓ 挂载
Pod Volume（Pod 内挂载点）

PV：实际存储资源，类比"房子"
PVC：存储申请，类比"租房合同"
StorageClass：动态制备策略，类比"中介公司"，PVC 指定 StorageClass 后自动创建 PV
Volume：Pod spec 里的挂载声明，引用 PVC

访问模式：ReadWriteOnce（单节点读写）/ ReadOnlyMany（多节点只读）/ ReadWriteMany（多节点读写，需 NFS/CephFS 支持）

Q9：Service 是怎么把请求转发到 Pod 的？

A：

Service 创建时，kube-proxy 在每个节点上监听 API Server，获取 Service 和 Endpoints 变化
kube-proxy 将转发规则写入节点的 iptables（默认）或 IPVS（性能更好）
请求到达 ClusterIP 时，iptables/IPVS 做 DNAT，将目标地址替换为后端 Pod IP
Endpoints 对象维护 Service 对应的健康 Pod IP 列表，readinessProbe 失败的 Pod 会被自动摘除

iptables vs IPVS：

iptables：规则链式匹配，Pod 数量多时性能下降（O(n)）
IPVS：哈希表查找（O(1)），支持更多负载均衡算法，大规模集群推荐

Q10：Headless Service 是什么？StatefulSet 为什么需要它？

A：

Headless Service：clusterIP: None，不分配 VIP，DNS 解析直接返回所有后端 Pod 的 IP 列表。

StatefulSet 需要它的原因：

StatefulSet 的每个 Pod 需要稳定的网络标识，格式为 <pod-name>.<service-name>.<namespace>.svc.cluster.local
例如 mysql-0.mysql.default.svc.cluster.local 始终解析到 mysql-0 这个 Pod
这样主从复制、集群选主等场景才能通过固定 DNS 找到特定实例
普通 Service 会做负载均衡，无法定向访问某个具体 Pod

三、K8s 网络与安全

Q11：K8s 网络模型的三大要求是什么？

A：

每个 Pod 有唯一 IP，Pod 内容器共享该 IP（通过 pause 容器的 network namespace）
Pod 之间可以直接通信，不需要 NAT（同节点或跨节点）
Node 和 Pod 之间可以直接通信，不需要 NAT

这三条要求由 CNI 插件负责实现，K8s 本身不关心底层如何实现。

Q12：常见的 CNI 插件有哪些？各有什么特点？

A：

CNI 插件	实现方式	特点
Flannel	VXLAN overlay	简单易用，性能一般，适合小规模
Calico	BGP 路由（underlay）或 VXLAN	性能好，支持 NetworkPolicy，大规模生产常用
Cilium	eBPF	内核态处理，性能最高，支持 L7 NetworkPolicy，可替代 kube-proxy
Weave	VXLAN + 加密	支持加密传输，性能较低
华为 CCE	默认 Yangtse（基于 VPC 路由）	与华为云 VPC 深度集成，Pod IP 直接在 VPC 路由表可见

Q13：NetworkPolicy 怎么用？能实现什么效果？

A：

NetworkPolicy 是 K8s 的网络访问控制策略，基于标签选择器控制 Pod 间的流量。

默认行为：没有 NetworkPolicy 时，所有 Pod 互通；一旦有 NetworkPolicy 选中某个 Pod，该 Pod 的未匹配流量默认拒绝。

典型用法 — 默认拒绝所有入站，只允许特定来源：

yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-only
  namespace: backend
spec:
  podSelector:
    matchLabels:
      app: api-server
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: frontend
      podSelector:
        matchLabels:
          app: web

注意：namespaceSelector 和 podSelector 在同一个 -from 条目下是 AND 关系；分开写是 OR 关系。

实际排查经验（案例 004）：NetworkPolicy 作用在 Pod IP 层面，验证时应 curl <Pod IP> 而不是 curl <ClusterIP>，因为同节点流量可能绕过 CNI 的 NetworkPolicy 执行路径，导致间歇性超时难以复现。

Q14：RBAC 四个核心资源的区别？

A：

资源	作用域	说明
Role	Namespace 级别	定义某个 namespace 内的权限规则
ClusterRole	集群级别	定义集群范围的权限，或可被跨 namespace 复用
RoleBinding	Namespace 级别	将 Role 或 ClusterRole 绑定到用户/组/ServiceAccount（仅在该 namespace 生效）
ClusterRoleBinding	集群级别	将 ClusterRole 绑定到用户/组/ServiceAccount（全集群生效）

常见组合：

ClusterRole + RoleBinding：复用同一套权限定义，但限制在特定 namespace
ClusterRole + ClusterRoleBinding：全集群权限，如 node-exporter 需要读所有节点信息

Q15：ServiceAccount 和普通用户的区别？

A：

维度	ServiceAccount	普通用户（User）
管理方式	K8s 原生资源，存储在 etcd	K8s 不管理，依赖外部 IdP（证书/OIDC/LDAP）
使用场景	Pod 内程序访问 API Server	人工操作 kubectl
Token 挂载	自动挂载到 Pod `/var/run/secrets/kubernetes.io/serviceaccount/`	不自动挂载
命名空间	属于某个 namespace	集群全局

最佳实践：为每个应用创建独立 ServiceAccount，遵循最小权限原则，不使用 default ServiceAccount。

Q16：Pod Security Policy 已废弃，现在用什么代替？

A：

PSP 在 K8s 1.21 废弃，1.25 移除。替代方案：

Pod Security Admission（PSA）：K8s 1.23 GA，内置三个安全级别：
- privileged：无限制
- baseline：防止已知提权，允许大多数工作负载
- restricted：最严格，遵循 Pod 安全最佳实践
第三方方案：OPA/Gatekeeper（策略即代码，更灵活）、Kyverno（K8s 原生策略引擎）

华为 CCE 实践：CCE 集群默认启用 PSA，生产命名空间建议设置 baseline 或 restricted。

四、调度与资源管理

Q17：NodeSelector、NodeAffinity、PodAffinity 的区别？

A：

机制	灵活度	说明
NodeSelector	低	硬性要求，Pod 只能调度到有指定标签的节点，不满足则 Pending
NodeAffinity	中	支持 `requiredDuringScheduling`（硬）和 `preferredDuringScheduling`（软），支持 In/NotIn/Exists 等操作符
PodAffinity / PodAntiAffinity	高	基于其他 Pod 的标签决定调度位置，实现"和某类 Pod 在一起"或"分散部署"

典型用法：

将 GPU 工作负载调度到有 GPU 的节点 → NodeSelector 或 NodeAffinity
Web 和 Cache 部署在同一节点减少延迟 → PodAffinity
同一服务的多个副本分散到不同节点/AZ → PodAntiAffinity

Q18：怎么让某个 Pod 只能调度到特定节点？

A：

方法一：NodeSelector（简单场景）

yaml

spec:
  nodeSelector:
    disktype: ssd

方法二：NodeAffinity（复杂条件）

yaml

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/hostname
            operator: In
            values:
            - node-gpu-01

方法三：Taint + Toleration（节点主动排斥，Pod 主动容忍）

bash

# 给节点打污点
kubectl taint nodes node-gpu-01 gpu=true:NoSchedule

yaml

# Pod 添加容忍
spec:
  tolerations:
  - key: "gpu"
    operator: "Equal"
    value: "true"
    effect: "NoSchedule"

Q19：怎么让某些节点不接受普通 Pod？

A：

给节点打 Taint（污点），普通 Pod 没有对应 Toleration 就不会被调度上去。

bash

# NoSchedule：新 Pod 不调度，已有 Pod 不驱逐
kubectl taint nodes node01 dedicated=infra:NoSchedule

# NoExecute：新 Pod 不调度，已有 Pod 也被驱逐
kubectl taint nodes node01 dedicated=infra:NoExecute

典型场景：

Master 节点默认有 node-role.kubernetes.io/control-plane:NoSchedule，防止业务 Pod 调度上去
专用 GPU 节点只跑 AI 训练任务
基础设施节点（监控、日志）只跑运维组件

Q20：Resource requests 和 limits 的区别？不设置会发生什么？

A：

维度	requests	limits
含义	调度依据，Scheduler 保证节点有足够资源	运行上限，超出则被限制或 OOM Kill
CPU 超出	不会 Kill，会被 throttle（限速）	同左
内存超出	—	容器被 OOM Kill，Pod 重启
QoS 等级	requests = limits → Guaranteed	只设 limits → Burstable；都不设 → BestEffort

不设置的风险：

不设 requests：Scheduler 无法准确评估节点负载，可能导致节点资源耗尽
不设 limits：单个容器可能耗尽节点所有资源，影响同节点其他 Pod
BestEffort Pod 在节点资源紧张时最先被驱逐

生产建议：requests 和 limits 都设置，CPU limits 可适当放宽（throttle 比 OOM 好），内存 limits 要准确评估。

Q21：如何查看节点和 Pod 的资源使用情况？

A：

bash

# 查看节点资源使用（需要 metrics-server）
kubectl top nodes

# 查看 Pod 资源使用
kubectl top pods -n <namespace>
kubectl top pods --sort-by=memory -n <namespace>

# 查看节点可分配资源和已申请量
kubectl describe node <node-name> | grep -A 10 "Allocated resources"

# 查看 Pod 的 requests/limits 配置
kubectl get pod <pod-name> -o jsonpath='{.spec.containers[*].resources}'

Prometheus 查询（更精细）：

promql

# 节点内存使用率
(1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100

# Pod CPU 使用率（相对 limits）
rate(container_cpu_usage_seconds_total[5m]) / container_spec_cpu_quota * container_spec_cpu_period

五、Prometheus 监控体系（kube-prometheus-stack）

Q22：CRD 是什么？Prometheus Operator 的五个核心 CRD 分别是什么？

A：

CRD（Custom Resource Definition）：K8s 的扩展机制，允许用户定义自己的资源类型，像操作原生资源一样用 kubectl 管理。

Prometheus Operator 五个核心 CRD：

CRD	作用
Prometheus	创建和管理 Prometheus 实例，定义副本数、存储、告警规则引用等
ServiceMonitor	定义通过 Service 抓取指标的目标，关联到 Service
PodMonitor	定义直接抓取 Pod 指标的目标，关联到 Pod
AlertmanagerConfig	定义 Alertmanager 的路由、接收器、静默规则
PrometheusRule	定义告警规则和记录规则（recording rules）

Q23：ServiceMonitor 和 Service 是怎么关联的？整个监控链路是什么？

A：

关联方式：ServiceMonitor 通过 selector.matchLabels 匹配 Service 的标签，Prometheus 实例通过自身 YAML 中的 serviceMonitorSelector 关联 ServiceMonitor。

完整链路：

PrometheusRule（定义告警规则）
        ↓
Prometheus CR（通过 serviceMonitorSelector 关联）
        ↓
ServiceMonitor（通过 selector 匹配 Service 标签）
        ↓
Service（暴露 /metrics 端口）
        ↓
Pod（业务代码暴露 metrics 接口，如 :8080/metrics）

Prometheus 抓取流程：

Prometheus 读取 ServiceMonitor 配置，找到对应 Service
通过 Service 的 Endpoints 获取后端 Pod IP 列表
直接向每个 Pod 的 metrics 端口发起 HTTP GET 请求抓取指标

Q24：为什么有了 PodMonitor 还需要 ServiceMonitor？

A：

维度	PodMonitor	ServiceMonitor
抓取目标	直接抓取 Pod IP	通过 Service Endpoints 抓取
Pod 动态变化	需要重新发现	Service 自动维护 Endpoints，无感知
负载均衡	无	天然通过 Service 实现
适用场景	无 Service 的 Pod（如 DaemonSet 节点组件）	有 Service 的应用（推荐）

核心优势：通过 ServiceMonitor，当某个 Pod 被删除重建后，Prometheus 不需要重新配置，Service Endpoints 自动更新，新 Pod 自动被纳入监控。

Q25：AlertManager 是怎么处理告警的？

A：

告警流转链路：

Prometheus 评估 PrometheusRule
    → 触发告警，推送到 Alertmanager（通过 Prometheus YAML 中 alerting.alertmanagers 配置）
    → Alertmanager 处理：去重 → 分组 → 路由 → 发送
    → 接收端（钉钉 / 邮件 / Webhook / PagerDuty）

Alertmanager 核心处理能力（均通过 YAML 配置）：

去重（Deduplication）：相同 fingerprint 的告警只发一次，避免重复通知
分组（Grouping）：group_by: [alertname, cluster]，将同类告警合并为一条通知
抑制（Inhibition）：inhibit_rules，当高优先级告警触发时，压制低优先级告警（如节点宕机时抑制该节点上所有 Pod 的告警）
静默（Silence）：手动设置时间窗口，维护期间不发告警
路由（Routing）：根据标签将不同告警发给不同接收人

实际案例（案例 007）：通过 inhibit_rules 配置根因抑制，将告警数量减少约 60%，故障发现时间从 30 分钟降到 3 分钟。

Q26：PodMonitor 和 Pod 是怎么关联的？

A：

PodMonitor 通过 selector.matchLabels 直接匹配 Pod 的标签（不经过 Service），Prometheus 实例通过 podMonitorSelector 关联 PodMonitor。

yaml

apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: node-exporter
spec:
  selector:
    matchLabels:
      app: node-exporter   # 匹配 Pod 标签
  podMetricsEndpoints:
  - port: metrics
    path: /metrics

适用场景：DaemonSet 类组件（node-exporter、Fluentd）通常没有 Service，直接用 PodMonitor 抓取。

六、大厂高阶题

Q27：kube-apiserver 如何实现高可用？

A：

部署层面：

多个 apiserver 实例部署在不同 Master 节点（通常 3 个）
前端挂 负载均衡器（HAProxy + Keepalived，或云 LB），客户端访问 VIP
apiserver 本身是无状态的，所有状态存在 etcd，天然支持水平扩展

请求处理：

kubectl / kubelet / controller-manager 都通过 LB VIP 访问 apiserver
某个 apiserver 实例故障，LB 自动摘除，流量切到其他实例

华为 CCE 实践：CCE 托管集群的 apiserver 由华为管理，用户侧通过 ELB 访问，SLA 99.95%。

Q28：etcd 备份和恢复怎么做？

A：

备份（使用 etcdctl snapshot）：

bash

ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-$(date +%Y%m%d).db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

# 验证备份
etcdctl snapshot status /backup/etcd-20250525.db

恢复：

bash

# 停止 apiserver（避免写入冲突）
# 恢复数据
ETCDCTL_API=3 etcdctl snapshot restore /backup/etcd-20250525.db \
  --data-dir=/var/lib/etcd-restore \
  --name=master-01 \
  --initial-cluster=master-01=https://192.168.1.10:2380 \
  --initial-advertise-peer-urls=https://192.168.1.10:2380

# 修改 etcd 配置指向新数据目录，重启 etcd 和 apiserver

生产建议：

每天定时备份，保留 7 天
备份文件存到对象存储（OBS/S3），不要只存本地
定期做恢复演练，验证备份有效性

Q29：Kubelet 证书过期了怎么处理？

A：

排查确认：

bash

# 查看证书有效期
openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -noout -dates

# 查看 kubelet 日志
journalctl -u kubelet | grep -i "certificate\|x509\|expired"

处理方式：

方式一：自动轮转（推荐，提前配置）

yaml

# kubelet 配置开启自动轮转
rotateCertificates: true
serverTLSBootstrap: true

开启后 kubelet 在证书到期前自动申请续期，需要 CSR 自动审批（配置 kube-controller-manager 的 --cluster-signing-cert-file）。

方式二：手动重新 bootstrap

bash

# 删除旧证书
rm /var/lib/kubelet/pki/kubelet-client*

# 重新生成 bootstrap token
kubeadm token create --print-join-command

# 重启 kubelet，触发重新 bootstrap
systemctl restart kubelet

Q30：HPA 的原理是什么？支持自定义指标吗？

A：

原理：

HPA Controller 定期（默认 15s）从 Metrics API 获取指标
根据公式计算期望副本数：desiredReplicas = ceil(currentReplicas × currentMetricValue / desiredMetricValue)
更新 Deployment/StatefulSet 的 replicas 字段

三类指标来源：

类型	API	示例
资源指标	`metrics.k8s.io`（metrics-server）	CPU 使用率、内存使用率
自定义指标	`custom.metrics.k8s.io`（Prometheus Adapter）	QPS、队列深度、业务延迟
外部指标	`external.metrics.k8s.io`	云服务指标（SQS 队列长度等）

支持自定义指标：需要部署 Prometheus Adapter，将 Prometheus 指标暴露为 K8s Custom Metrics API，HPA 即可基于业务指标（如 HTTP QPS）扩缩容。

yaml

# 基于自定义指标的 HPA 示例
spec:
  metrics:
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: 100

Q31：VPA 了解吗？和 HPA 的区别？

A：

VPA（Vertical Pod Autoscaler）：自动调整 Pod 的 CPU/内存 requests 和 limits，而不是调整副本数。

维度	HPA	VPA
扩缩方式	水平，增减副本数	垂直，调整单 Pod 资源配额
适用场景	无状态、可水平扩展的服务	单实例应用、资源难以预估的服务
生效方式	实时生效	默认需要重建 Pod（In-Place 模式 K8s 1.27+ 支持）
注意事项	不能和 VPA 同时作用于同一资源	会修改 Pod spec，可能触发重启

生产建议：HPA + VPA 不要同时作用于同一 Deployment 的 CPU/内存，会产生冲突。可以 HPA 基于自定义指标，VPA 管理资源配额。

Q32：Descheduler 是什么？什么时候用？

A：

Descheduler：K8s 的补充调度组件，负责驱逐已运行但调度不合理的 Pod，让 Scheduler 重新调度到更合适的节点。

解决的问题：Scheduler 只在 Pod 创建时调度一次，之后不会重新平衡。随着时间推移，集群可能出现：

节点资源不均衡（某些节点过载，某些空闲）
节点标签/污点变化后，Pod 不再满足亲和性规则
拓扑分布约束（TopologySpreadConstraints）不再满足

常用策略：

RemoveDuplicates：同一 ReplicaSet 在同一节点上有多个副本时驱逐多余的
LowNodeUtilization：驱逐高负载节点上的 Pod，让其调度到低负载节点
RemovePodsViolatingNodeAffinity：驱逐不再满足 NodeAffinity 的 Pod

使用场景：节点扩容后希望 Pod 自动迁移到新节点；节点维护后恢复，希望重新均衡负载。

Q33：你用过哪些 Ingress Controller？

A：

常见 Ingress Controller：

Controller	特点
Nginx Ingress	最广泛，基于 Nginx，功能丰富，社区活跃
Traefik	自动发现，支持 Let's Encrypt，适合中小规模
HAProxy Ingress	高性能，适合大流量场景
Istio Gateway	与 Service Mesh 集成，支持高级流量管理
华为 CCE ELB Ingress	与华为云 ELB 深度集成，支持 WAF、DDoS 防护

华为 CCE 实践：CCE 集群使用 ELB Ingress Controller，Ingress 资源自动创建 ELB 监听器和转发规则，支持 HTTPS 证书托管和 WAF 联动。

Q34：Operator 模式是什么？举个用过的例子。

A：

Operator 模式：将运维专家的领域知识编码为 K8s Controller，通过 CRD + Controller 实现有状态应用的自动化运维（安装、升级、备份、故障恢复）。

核心组成：

CRD：定义自定义资源（如 Prometheus、ElasticsearchCluster）
Controller：监听 CRD 资源变化，执行对应的运维操作（Reconcile Loop）

用过的 Operator：

Prometheus Operator（kube-prometheus-stack）：通过 Prometheus CRD 管理 Prometheus 实例，ServiceMonitor 自动生成抓取配置，无需手动维护 prometheus.yml。在衢州政务云项目中用于构建统一监控体系。
Elasticsearch Operator（ECK）：在衢州警务云项目中，通过 ECK 管理 ES 集群，解决了 ES 版本升级和索引兼容性问题，滚动升级期间业务零中断。

Q35：Cilium 为什么性能更高？

A：

核心原因：eBPF（extended Berkeley Packet Filter）

传统 CNI（如 Flannel、Calico iptables 模式）的数据路径：

Pod → veth → iptables/netfilter（用户态/内核态切换）→ 路由 → 目标 Pod

Cilium 的数据路径：

Pod → veth → eBPF 程序（纯内核态，直接在网络栈执行）→ 目标 Pod

性能优势来源：

绕过 iptables：iptables 是链式规则匹配（O(n)），规则多时性能急剧下降；eBPF 用哈希表（O(1)）
减少内核态/用户态切换：eBPF 程序直接在内核执行，无需上下文切换
可替代 kube-proxy：Cilium 可完全接管 Service 转发，不再依赖 iptables DNAT
XDP（eXpress Data Path）：在网卡驱动层直接处理数据包，DDoS 防护场景下性能极高

实测数据：大规模集群（1000+ 节点）下，Cilium 的网络延迟比 iptables 模式低约 30%，吞吐量高约 50%。

Q36：K8s 是怎么实现高可用的？

A：

控制平面高可用：

组件	HA 方案
etcd	3 或 5 节点集群，Raft 共识，允许 (n-1)/2 个节点故障
kube-apiserver	多实例 + 负载均衡（无状态，水平扩展）
kube-controller-manager	多实例部署，通过 Leader Election 选主，只有主节点工作
kube-scheduler	同上，Leader Election 选主

数据平面高可用：

Pod 多副本（Deployment replicas ≥ 2）
PodAntiAffinity 将副本分散到不同节点/AZ
PodDisruptionBudget（PDB）限制同时不可用的 Pod 数量
跨 AZ 部署，节点故障不影响整体服务

华为 CCE 实践：CCE 托管集群控制平面由华为管理，用户只需关注工作节点和应用层 HA。在台州政务云项目中采用单 Region 多 AZ 架构，计算节点分布在 3 个 AZ，保障 AZ 级故障容忍。

Q37：etcd 为什么只能由 apiserver 直接访问？

A：

设计原因：

安全隔离：etcd 存储了集群所有状态（Secrets、配置、证书），直接暴露给所有组件风险极高；apiserver 作为唯一入口，统一做认证（mTLS）、授权（RBAC）、审计
一致性保证：apiserver 对 etcd 的读写做了版本控制（ResourceVersion）和乐观锁，防止并发写冲突；多个组件直接写 etcd 容易产生竞态条件
抽象层：apiserver 提供 Watch 机制，组件通过 List-Watch 监听资源变化，不需要直接轮询 etcd，减少 etcd 压力
扩展性：apiserver 可以在 etcd 前加缓存层（如 watch cache），降低 etcd 读压力

一句话：apiserver 是 etcd 的唯一守门人，所有读写都经过它的认证、授权和审计，保证集群状态的安全性和一致性。

附：常用排查命令速查

bash

# Pod 状态排查
kubectl get pods -n <ns> -o wide
kubectl describe pod <pod> -n <ns>
kubectl logs <pod> -n <ns> --previous   # 查看上次崩溃日志
kubectl exec -it <pod> -n <ns> -- sh

# 事件查看
kubectl get events -n <ns> --sort-by='.lastTimestamp'

# 节点状态
kubectl get nodes -o wide
kubectl describe node <node>
kubectl top nodes

# 网络排查
kubectl exec -it <pod> -- curl <target-pod-ip>:<port>
kubectl exec -it <pod> -- nslookup <service-name>.<namespace>.svc.cluster.local

# etcd 健康检查
ETCDCTL_API=3 etcdctl endpoint health \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

# 证书有效期检查
kubeadm certs check-expiration

七、K8s 系统性介绍（面试开场题）

Q27：请用一段话系统介绍一下 K8s，包括整体概念、组件构成和各组件功能

A：

Kubernetes（K8s）是 Google 开源的容器编排平台，核心思想是声明式 API + 控制循环：你告诉它"期望状态"，它负责把现实状态收敛过去，并持续维护。它解决的核心问题是：在多台机器上自动化地部署、调度、扩缩容、自愈和管理容器化应用。

整体架构：Control Plane + Node

K8s 集群分两层：

Control Plane（控制平面）：集群的大脑，负责决策和状态管理，通常部署在 Master 节点
Node（工作节点）：实际运行业务容器的机器，接受控制平面的指令并执行

Control Plane 组件

① kube-apiserver

集群的统一入口，所有操作（kubectl、控制器、kubelet）都通过它。它是唯一直接读写 etcd 的组件，提供 RESTful API，负责认证（Authentication）、鉴权（Authorization）、准入控制（Admission Control）三道关卡。

② etcd

分布式键值存储，是集群的"数据库"，存储所有资源对象的状态（Pod、Service、ConfigMap 等）。强一致性，基于 Raft 协议。etcd 挂了，集群状态就丢了，所以生产环境必须做 etcd 高可用（3 或 5 节点）和定期备份。

③ kube-scheduler

调度器，负责决定新建的 Pod 应该跑在哪个 Node 上。调度分两阶段：

过滤（Filtering）：排除不满足条件的节点（资源不足、污点不匹配、亲和性不满足等）
打分（Scoring）：对剩余节点打分，选出最优节点

调度策略可以通过 nodeSelector、nodeAffinity、podAffinity、Taints/Tolerations 等精细控制。

④ kube-controller-manager

控制器管理器，内置了几十个控制器，每个控制器负责一类资源的"期望状态 → 实际状态"收敛。常见的有：

Deployment Controller：管理 ReplicaSet，实现滚动更新和回滚
ReplicaSet Controller：保证 Pod 副本数始终等于期望值，Pod 挂了自动重建
Node Controller：监控节点心跳，节点失联超时后将其上的 Pod 驱逐
Service Account Controller：为新 Namespace 自动创建默认 ServiceAccount
Job Controller / CronJob Controller：管理一次性任务和定时任务的生命周期
Endpoint Controller：维护 Service 和 Pod 之间的 Endpoints 映射关系

⑤ cloud-controller-manager（可选）

云厂商专属控制器，负责与底层云平台对接，比如自动创建 LoadBalancer、管理云盘（PV）、同步节点信息。华为云 CCE 就有自己的 cloud-controller-manager 对接 ELB 和 EVS。

Node 组件

⑥ kubelet

每个 Node 上的"代理"，是控制平面和节点之间的桥梁。它从 apiserver 拿到分配给本节点的 Pod Spec，调用容器运行时（CRI）创建容器，并持续上报 Pod 状态和节点资源信息。它还负责执行存活探针（Liveness Probe）和就绪探针（Readiness Probe），决定是否重启容器或从 Service 摘流。

⑦ kube-proxy

负责集群内的网络代理和负载均衡，维护 Service 到 Pod 的流量转发规则。默认使用 iptables 模式（在节点上写 iptables 规则），高性能场景可以切换为 ipvs 模式（基于内核 LVS，性能更好，支持更多负载均衡算法）。注意：kube-proxy 实现的是 Service 的 ClusterIP 转发，不负责 Pod 间直接通信（那是 CNI 插件的事）。

⑧ 容器运行时（CRI）

实际创建和管理容器的组件，K8s 通过 CRI（Container Runtime Interface）标准接口对接。常见的有：

containerd：目前主流，轻量，K8s 1.24 后默认
CRI-O：专为 K8s 设计的轻量运行时
Docker（已废弃）：K8s 1.24 移除了 dockershim，不再直接支持

附加组件（Add-ons）

⑨ CoreDNS

集群内的 DNS 服务，负责 Service 名称解析。Pod 内访问 my-svc.my-namespace.svc.cluster.local 就是由 CoreDNS 解析到对应的 ClusterIP。

⑩ CNI 插件（网络插件）

负责 Pod 网络，实现跨节点 Pod 互通。常见的有 Calico（支持 BGP 路由和 NetworkPolicy）、Flannel（简单 Overlay 网络）、Cilium（基于 eBPF，高性能，支持 L7 策略）。华为云 CCE 默认用 VPC-CNI，Pod 直接使用 VPC 弹性网卡，性能接近裸金属。

⑪ Ingress Controller

处理集群外部 HTTP/HTTPS 流量的入口，根据域名和路径规则将请求路由到对应 Service。常见的有 Nginx Ingress Controller、Traefik、华为云 CCE 对接 ELB 的 Ingress Controller。

一句话总结各组件职责

组件	一句话
kube-apiserver	集群唯一入口，所有操作的网关，读写 etcd
etcd	集群状态数据库，强一致性键值存储
kube-scheduler	决定 Pod 跑在哪个节点
kube-controller-manager	内置几十个控制器，持续收敛期望状态
cloud-controller-manager	对接云平台，管理 LB、云盘、节点
kubelet	节点代理，拉起容器，上报状态，执行探针
kube-proxy	维护 Service 转发规则，实现集群内负载均衡
容器运行时（CRI）	实际创建和运行容器
CoreDNS	集群内 DNS，解析 Service 名称
CNI 插件	Pod 网络，实现跨节点互通
Ingress Controller	集群外部流量入口，HTTP 路由

面试口语版（2 分钟）

K8s 是一个容器编排平台，核心是声明式 API 加控制循环——你描述期望状态，它负责收敛并持续维护。
架构上分两层：控制平面和工作节点。控制平面有四个核心组件：apiserver 是唯一入口，所有操作都经过它；etcd 是集群的数据库，存所有资源状态；scheduler 负责决定 Pod 调度到哪个节点；controller-manager 里跑着几十个控制器，每个控制器盯着一类资源，Pod 少了就补，节点挂了就驱逐。
工作节点上有三个关键组件：kubelet 是节点代理，负责拉起容器、执行探针、上报状态；kube-proxy 维护 Service 的转发规则，实现集群内负载均衡；容器运行时（现在主流是 containerd）负责实际创建容器。
附加组件里，CoreDNS 做集群内 DNS 解析，CNI 插件负责 Pod 跨节点网络，Ingress Controller 处理外部 HTTP 流量入口。
我在华为云 CCE 上交付过多套生产集群，对这套架构的实际运作比较熟悉，包括 etcd 备份、scheduler 调度策略调优、以及 VPC-CNI 和 NetworkPolicy 的配合使用。

云原生运维面试 Q&A ​

目录 ​

零、K8s 基础概念（必考） ​

Q0：K8s 是什么？解决什么问题？ ​

Q00：Pod 是什么？为什么 K8s 的最小调度单位是 Pod 而不是容器？ ​

Q01：K8s 的核心组件有哪些？各自做什么？ ​

Q02：Service 有几种类型？区别是什么？ ​

Q03：Ingress 和 Service 有什么区别？Ingress Controller 是什么？ ​

Q04：Label 和 Selector 的作用？Namespace 用来干什么？ ​

Q05：Pod 的重启策略有哪些？ ​

一、Istio / Service Mesh 概念 ​

Q1：用通俗的方式解释 Istio 和 Service Mesh 是什么？ ​

Q2：Istio 和普通 Ingress 的区别是什么？ ​

Q3：Sidecar 模式的原理是什么？有什么优缺点？ ​

二、K8s 核心资源 ​

Q4：Pod 的生命周期有哪些阶段？ ​

Q5：Deployment 和 StatefulSet 的区别是什么？各什么时候用？ ​

Q6：DaemonSet 的典型使用场景？ ​

Q7：ConfigMap 和 Secret 的区别？ ​

Q8：Volume、PV、PVC、StorageClass 的关系是什么？ ​

Q9：Service 是怎么把请求转发到 Pod 的？ ​

Q10：Headless Service 是什么？StatefulSet 为什么需要它？ ​

三、K8s 网络与安全 ​

Q11：K8s 网络模型的三大要求是什么？ ​

Q12：常见的 CNI 插件有哪些？各有什么特点？ ​

Q13：NetworkPolicy 怎么用？能实现什么效果？ ​

Q14：RBAC 四个核心资源的区别？ ​

Q15：ServiceAccount 和普通用户的区别？ ​

Q16：Pod Security Policy 已废弃，现在用什么代替？ ​

四、调度与资源管理 ​

Q17：NodeSelector、NodeAffinity、PodAffinity 的区别？ ​

Q18：怎么让某个 Pod 只能调度到特定节点？ ​

Q19：怎么让某些节点不接受普通 Pod？ ​

Q20：Resource requests 和 limits 的区别？不设置会发生什么？ ​

Q21：如何查看节点和 Pod 的资源使用情况？ ​

五、Prometheus 监控体系（kube-prometheus-stack） ​

Q22：CRD 是什么？Prometheus Operator 的五个核心 CRD 分别是什么？ ​

Q23：ServiceMonitor 和 Service 是怎么关联的？整个监控链路是什么？ ​

Q24：为什么有了 PodMonitor 还需要 ServiceMonitor？ ​

Q25：AlertManager 是怎么处理告警的？ ​

Q26：PodMonitor 和 Pod 是怎么关联的？ ​

六、大厂高阶题 ​

Q27：kube-apiserver 如何实现高可用？ ​

Q28：etcd 备份和恢复怎么做？ ​

Q29：Kubelet 证书过期了怎么处理？ ​

Q30：HPA 的原理是什么？支持自定义指标吗？ ​

Q31：VPA 了解吗？和 HPA 的区别？ ​

Q32：Descheduler 是什么？什么时候用？ ​

Q33：你用过哪些 Ingress Controller？ ​

Q34：Operator 模式是什么？举个用过的例子。 ​

Q35：Cilium 为什么性能更高？ ​

Q36：K8s 是怎么实现高可用的？ ​

Q37：etcd 为什么只能由 apiserver 直接访问？ ​

附：常用排查命令速查 ​

七、K8s 系统性介绍（面试开场题） ​

Q27：请用一段话系统介绍一下 K8s，包括整体概念、组件构成和各组件功能 ​

整体架构：Control Plane + Node ​

Control Plane 组件 ​

Node 组件 ​

附加组件（Add-ons） ​

一句话总结各组件职责 ​

面试口语版（2 分钟） ​

云原生运维面试 Q&A

目录

零、K8s 基础概念（必考）

Q0：K8s 是什么？解决什么问题？

Q00：Pod 是什么？为什么 K8s 的最小调度单位是 Pod 而不是容器？

Q01：K8s 的核心组件有哪些？各自做什么？

Q02：Service 有几种类型？区别是什么？

Q03：Ingress 和 Service 有什么区别？Ingress Controller 是什么？

Q04：Label 和 Selector 的作用？Namespace 用来干什么？

Q05：Pod 的重启策略有哪些？

一、Istio / Service Mesh 概念

Q1：用通俗的方式解释 Istio 和 Service Mesh 是什么？

Q2：Istio 和普通 Ingress 的区别是什么？

Q3：Sidecar 模式的原理是什么？有什么优缺点？

二、K8s 核心资源

Q4：Pod 的生命周期有哪些阶段？

Q5：Deployment 和 StatefulSet 的区别是什么？各什么时候用？

Q6：DaemonSet 的典型使用场景？

Q7：ConfigMap 和 Secret 的区别？

Q8：Volume、PV、PVC、StorageClass 的关系是什么？

Q9：Service 是怎么把请求转发到 Pod 的？

Q10：Headless Service 是什么？StatefulSet 为什么需要它？

三、K8s 网络与安全

Q11：K8s 网络模型的三大要求是什么？

Q12：常见的 CNI 插件有哪些？各有什么特点？

Q13：NetworkPolicy 怎么用？能实现什么效果？

Q14：RBAC 四个核心资源的区别？

Q15：ServiceAccount 和普通用户的区别？

Q16：Pod Security Policy 已废弃，现在用什么代替？

四、调度与资源管理

Q17：NodeSelector、NodeAffinity、PodAffinity 的区别？

Q18：怎么让某个 Pod 只能调度到特定节点？

Q19：怎么让某些节点不接受普通 Pod？

Q20：Resource requests 和 limits 的区别？不设置会发生什么？

Q21：如何查看节点和 Pod 的资源使用情况？

五、Prometheus 监控体系（kube-prometheus-stack）

Q22：CRD 是什么？Prometheus Operator 的五个核心 CRD 分别是什么？

Q23：ServiceMonitor 和 Service 是怎么关联的？整个监控链路是什么？

Q24：为什么有了 PodMonitor 还需要 ServiceMonitor？

Q25：AlertManager 是怎么处理告警的？

Q26：PodMonitor 和 Pod 是怎么关联的？

六、大厂高阶题

Q27：kube-apiserver 如何实现高可用？

Q28：etcd 备份和恢复怎么做？

Q29：Kubelet 证书过期了怎么处理？

Q30：HPA 的原理是什么？支持自定义指标吗？

Q31：VPA 了解吗？和 HPA 的区别？

Q32：Descheduler 是什么？什么时候用？

Q33：你用过哪些 Ingress Controller？

Q34：Operator 模式是什么？举个用过的例子。

Q35：Cilium 为什么性能更高？

Q36：K8s 是怎么实现高可用的？

Q37：etcd 为什么只能由 apiserver 直接访问？

附：常用排查命令速查

七、K8s 系统性介绍（面试开场题）

Q27：请用一段话系统介绍一下 K8s，包括整体概念、组件构成和各组件功能

整体架构：Control Plane + Node

Control Plane 组件

Node 组件

附加组件（Add-ons）

一句话总结各组件职责

面试口语版（2 分钟）