云原生运维面试 Q&A 精简版

背诵用。每题只保留核心要点，记住关键词和一句话结论。

零、K8s 基础（必考）

K8s 是什么？ 容器编排平台。解决：自动部署/扩缩容/自愈/调度/服务发现/滚动升级。核心思想：声明式 API，描述期望状态，K8s 自动收敛。

Pod 是什么？为什么最小单位是 Pod 不是容器？ Pod = 一组共享网络+存储的容器。最小单位是 Pod 因为：

紧耦合容器（主容器+Sidecar）需要共享网络，必须同节点
原子调度，不会出现主容器和 Sidecar 分开的情况
pause 容器持有 Network Namespace，业务容器重启 Pod IP 不变

K8s 核心组件一句话记忆：

apiserver — 唯一入口，认证授权，etcd 的唯一访问者
etcd — 集群状态数据库，Raft 强一致
scheduler — 给未调度 Pod 选节点，写 nodeName
controller-manager — 一堆控制器，持续对比期望状态和实际状态
kubelet — 节点管家，创建容器，上报状态，执行探针
kube-proxy — 维护 iptables/IPVS，实现 Service 转发

Service 四种类型：

ClusterIP（默认）— 仅集群内，服务间调用
NodePort — 节点 IP + 端口，测试用
LoadBalancer — 云 LB，生产对外暴露
ExternalName — 映射外部 DNS，访问集群外服务
Headless（clusterIP: None）— DNS 直返 Pod IP，StatefulSet 专用

Ingress vs Service： Service = L4，按端口转发；Ingress = L7，按 Host/Path 路由，支持 TLS。 Ingress Controller = 真正干活的反向代理（Nginx/Traefik/ELB），Ingress 只是规则定义。

Label / Selector / Namespace：

Label：键值对标签，标识资源
Selector：通过标签筛选资源，是 K8s 资源关联的核心机制
Namespace：逻辑隔离，配合 RBAC 做多租户权限控制，ResourceQuota 限制资源配额

Pod 重启策略：

Always（默认）— 无论成功失败都重启，长期服务用
OnFailure — 只有异常退出才重启，Job 用
Never — 不重启，一次性任务
CrashLoopBackOff = 连续失败触发退避机制（10s→20s→40s...最长 5min）

一、Istio / Service Mesh

小区类比记忆法：

Istio = 物业公司
Sidecar（Envoy）= 每个住户的保镖，流量全代理，业务无感知
Service Mesh = 所有串门路线汇成的网
Gateway = 小区大门，外部流量入口
VirtualService = 交警，控制路由/超时/重试/故障注入
DestinationRule = 家法，熔断/连接池/负载均衡算法

核心价值：服务治理下沉到基础设施，业务代码零侵入。

Istio vs 普通 Ingress： 普通 Ingress 只管南北向（外→集群）；Istio 管南北向 + 东西向（服务间）。 Istio 多了：mTLS、全链路 Trace、熔断、故障注入。

Sidecar 原理： MutatingWebhook 自动注入 Envoy → iptables 劫持所有流量 → 业务容器无感知。缺点：每 Pod 多 50~100MB，增加轻微延迟（<1ms）。

二、K8s 核心资源

Pod 生命周期：Pending（等调度/拉镜像）→ Running（至少一个容器跑着）→ Succeeded（全部正常退出）/ Failed（有容器异常退出）/ Unknown（节点失联）

三个探针：

livenessProbe — 失败重启容器
readinessProbe — 失败从 Endpoints 摘除，不接流量
startupProbe — 启动慢的应用用，防 liveness 误杀

Deployment vs StatefulSet：

	Deployment	StatefulSet
Pod 身份	随机 hash，无固定	固定序号 pod-0/1/2
存储	共享/无状态	每 Pod 独立 PVC
启停顺序	并行	有序
网络	ClusterIP Service	Headless Service，独立 DNS
场景	无状态服务	MySQL/Redis/Kafka/ES

DaemonSet 场景： 每节点跑一个。日志采集（Filebeat）、监控（node-exporter）、网络插件（Calico agent）、安全扫描（Falco）。

ConfigMap vs Secret： ConfigMap = 明文配置；Secret = Base64 编码（不是加密！）敏感信息。生产建议：Secret 配合 Vault/KMS 真加密，挂 Volume 不用 env。

PV/PVC/StorageClass 关系：

StorageClass（怎么创建）→ 动态制备 PV（房子）→ 绑定 PVC（租房合同）→ 挂载到 Pod

访问模式：RWO（单节点读写）/ ROX（多节点只读）/ RWX（多节点读写，需 NFS/CephFS）

Service 转发原理： kube-proxy 监听 apiserver → 写 iptables/IPVS 规则 → 请求到 ClusterIP 做 DNAT → 转到 Pod IP。 iptables O(n) vs IPVS O(1)，大规模集群用 IPVS。

Headless Service： clusterIP: None，DNS 直返 Pod IP。StatefulSet 用它实现 pod-0.svc.ns.svc.cluster.local 固定 DNS，主从复制/选主必须。

三、网络与安全

K8s 网络三大要求：

每个 Pod 有唯一 IP
Pod 间直接通信，不需要 NAT
Node 和 Pod 间直接通信，不需要 NAT （由 CNI 插件实现）

CNI 插件对比：

Flannel — VXLAN overlay，简单，小规模
Calico — BGP 路由，性能好，大规模生产主流
Cilium — eBPF，性能最高，可替代 kube-proxy，支持 L7 策略
华为 CCE Yangtse — 与 VPC 路由深度集成，Pod IP 在 VPC 可见

NetworkPolicy 要点：

没有 Policy = 全通；有 Policy 选中 Pod = 未匹配流量默认拒绝
namespaceSelector + podSelector 同一 from 条目 = AND；分开写 = OR
验证时 curl Pod IP，不要 curl ClusterIP（同节点流量可能绕过 CNI）

RBAC 四件套：

Role — namespace 内权限定义
ClusterRole — 集群级权限定义（可跨 namespace 复用）
RoleBinding — 绑定到 namespace（可绑 ClusterRole，但只在该 ns 生效）
ClusterRoleBinding — 全集群生效

常用组合：ClusterRole + RoleBinding = 复用权限定义但限制范围。

ServiceAccount vs 普通用户： SA = K8s 原生资源，给 Pod 内程序用，Token 自动挂载；普通用户 = K8s 不管，靠外部证书/OIDC，给人用 kubectl。

PSP 废弃替代： K8s 1.25 移除 PSP → 用 Pod Security Admission（PSA）：privileged / baseline / restricted 三级。或 OPA/Gatekeeper、Kyverno。

四、调度与资源管理

三种调度机制：

NodeSelector — 硬性标签匹配，最简单
NodeAffinity — 支持软硬两种（required/preferred），支持复杂操作符
PodAffinity/AntiAffinity — 基于其他 Pod 标签，实现"靠近"或"分散"

Taint + Toleration： 节点打污点 → 普通 Pod 不调度上去 → 只有有对应 Toleration 的 Pod 才能上。

NoSchedule：新 Pod 不调度，已有不驱逐
NoExecute：新 Pod 不调度，已有 Pod 也驱逐 Master 节点默认有 control-plane:NoSchedule。

requests vs limits：

requests = 调度依据（Scheduler 看这个）
limits = 运行上限（超出 CPU 被 throttle，超出内存被 OOM Kill）
QoS：requests=limits → Guaranteed；只有 limits → Burstable；都没有 → BestEffort（最先被驱逐）

查看资源使用：

bash

kubectl top nodes
kubectl top pods -n <ns>
kubectl describe node <node> | grep -A10 "Allocated"

五、Prometheus 监控体系

CRD 是什么： K8s 扩展机制，自定义资源类型，像原生资源一样用 kubectl 管理。

Prometheus Operator 五个核心 CRD：

Prometheus — 管理 Prometheus 实例
ServiceMonitor — 通过 Service 抓取指标
PodMonitor — 直接抓取 Pod 指标
AlertmanagerConfig — 告警路由/接收器配置
PrometheusRule — 告警规则和记录规则

监控完整链路：

PrometheusRule（规则）
  ↓ Prometheus CR（serviceMonitorSelector 关联）
  ↓ ServiceMonitor（selector 匹配 Service 标签）
  ↓ Service（暴露 /metrics）
  ↓ Pod（业务代码暴露指标）

ServiceMonitor vs PodMonitor： ServiceMonitor 通过 Service Endpoints 抓，Pod 重建自动感知，推荐； PodMonitor 直接抓 Pod IP，适合无 Service 的 DaemonSet 组件（node-exporter）。

AlertManager 处理流程： Prometheus 触发告警 → 推送 Alertmanager → 去重 → 分组 → 路由 → 发送（钉钉/邮件/Webhook）

关键配置：

group_by — 合并同类告警
inhibit_rules — 根因抑制，高优先级告警压制低优先级（节点宕机时抑制该节点所有 Pod 告警）
silence — 维护窗口静默

实战效果：inhibit_rules 让告警数量减少约 60%，故障发现从 30min 降到 3min。

六、大厂高阶题

apiserver 高可用： 多实例 + 前端 LB（HAProxy+Keepalived 或云 LB）。apiserver 无状态，状态全在 etcd，天然水平扩展。

etcd 备份恢复：

bash

# 备份
etcdctl snapshot save /backup/etcd.db --endpoints=... --cacert=... --cert=... --key=...
# 恢复：先停 apiserver，再 snapshot restore，改数据目录，重启

生产：每天备份，存 OBS，定期演练。

Kubelet 证书过期：

提前配置：rotateCertificates: true，自动轮转
已过期：删旧证书 → kubeadm token create 重新 bootstrap → 重启 kubelet
排查：openssl x509 -in kubelet-client-current.pem -noout -dates

HPA 原理： 每 15s 从 Metrics API 拉指标 → 计算期望副本数 → 更新 replicas。公式：期望副本 = ceil(当前副本 × 当前值 / 目标值) 支持自定义指标：部署 Prometheus Adapter，暴露 custom.metrics.k8s.io API。

VPA vs HPA： HPA = 水平扩缩（改副本数）；VPA = 垂直扩缩（改 requests/limits）。两者不能同时作用于同一资源的 CPU/内存，会冲突。

Descheduler： Scheduler 只在创建时调度一次，Descheduler 负责驱逐调度不合理的 Pod 让其重新调度。场景：节点扩容后负载均衡、节点标签变化后重新满足亲和性。

Cilium 为什么性能高： 核心：eBPF（内核态程序，绕过 iptables）。

iptables 链式匹配 O(n)，eBPF 哈希表 O(1)
无内核态/用户态切换
可完全替代 kube-proxy
XDP 在网卡驱动层处理包，DDoS 防护极快

K8s 高可用：

etcd：3/5 节点 Raft，允许 (n-1)/2 故障
apiserver：多实例 + LB，无状态
controller-manager / scheduler：多实例 + Leader Election，只有主节点工作
应用层：多副本 + PodAntiAffinity + PDB + 跨 AZ 部署

etcd 为什么只能 apiserver 访问：

安全：etcd 存所有 Secrets，apiserver 统一做认证授权审计
一致性：apiserver 做版本控制和乐观锁，防并发写冲突
性能：apiserver 提供 Watch 机制和缓存层，减少 etcd 直接压力一句话：apiserver 是 etcd 的唯一守门人。

附：高频命令速查

bash

# 排查 Pod
kubectl describe pod <pod> -n <ns>          # 看 Events
kubectl logs <pod> -n <ns> --previous       # 上次崩溃日志
kubectl get events --sort-by='.lastTimestamp' -n <ns>

# 资源使用
kubectl top nodes
kubectl top pods -n <ns> --sort-by=memory

# 网络验证
kubectl exec -it <pod> -- curl <Pod-IP>:<port>   # 验证 NetworkPolicy 用 Pod IP
kubectl exec -it <pod> -- nslookup <svc>.<ns>.svc.cluster.local

# etcd
etcdctl snapshot save ...
kubeadm certs check-expiration              # 检查所有证书有效期

K8s 整体架构一段话

K8s 是容器编排平台，核心是声明式 API + 控制循环，你描述期望状态，它持续收敛并维护。

架构分两层：控制平面负责决策，工作节点负责执行。

控制平面四个核心组件：

apiserver：唯一入口，所有操作都经过它，也是唯一读写 etcd 的组件，负责认证、鉴权、准入控制三道关卡
etcd：集群数据库，基于 Raft 强一致，存所有资源状态，生产必须 3/5 节点高可用 + 定期备份
scheduler：决定 Pod 调度到哪个节点，分过滤（排除不满足条件的节点）和打分（选最优节点）两阶段
controller-manager：内置几十个控制器，持续收敛期望状态，常见的有：
- Deployment Controller：管理 ReplicaSet，实现滚动更新和回滚
- ReplicaSet Controller：保证 Pod 副本数等于期望值，Pod 挂了自动重建
- StatefulSet Controller：有序管理有状态应用，保证 Pod 稳定身份和独立存储
- DaemonSet Controller：保证每个节点运行且仅运行一个 Pod（日志采集、监控 agent）
- Job Controller / CronJob Controller：管理一次性任务和定时任务生命周期
- Node Controller：监控节点心跳，节点失联超时后驱逐其上的 Pod
- Endpoint Controller：维护 Service 和 Pod 之间的 Endpoints 映射关系
- ServiceAccount Controller：为新 Namespace 自动创建默认 ServiceAccount
- PV Controller / PVC Controller：管理持久卷的绑定、回收生命周期
- Namespace Controller：处理 Namespace 删除时的资源清理
- HPA Controller：根据 CPU/内存或自定义指标自动水平扩缩容

工作节点三个关键组件：

kubelet：节点代理，拉起容器、执行存活/就绪探针、上报 Pod 和节点状态
kube-proxy：维护 Service 转发规则，默认 iptables 模式，大规模推荐 ipvs（O(1) 哈希查找）
容器运行时（主流 containerd）：实际创建容器，K8s 通过 CRI 标准接口对接

附加组件：

CoreDNS：集群内 DNS，解析 svc.cluster.local 到 ClusterIP
CNI 插件（Calico/Cilium/Flannel）：Pod 跨节点网络，华为 CCE 用 VPC-CNI 直接走 VPC 路由
Ingress Controller：外部 HTTP/HTTPS 流量入口，按域名和路径路由到对应 Service

云原生运维面试 Q&A 精简版 ​

零、K8s 基础（必考） ​

一、Istio / Service Mesh ​

二、K8s 核心资源 ​

三、网络与安全 ​

四、调度与资源管理 ​

五、Prometheus 监控体系 ​

六、大厂高阶题 ​

附：高频命令速查 ​

K8s 整体架构一段话 ​

云原生运维面试 Q&A 精简版

零、K8s 基础（必考）

一、Istio / Service Mesh

二、K8s 核心资源

三、网络与安全

四、调度与资源管理

五、Prometheus 监控体系

六、大厂高阶题

附：高频命令速查

K8s 整体架构一段话