面试速查：这套平台 + 高频问答 + 真实踩坑

这页是给面试准备的"一页纸"。前面 00–08 是怎么搭，这页是怎么讲：能一句话说清做了什么、能答常见问题、能讲出真实踩过的坑（面试里这点最值钱）。

1. 一句话电梯陈述

我在 5 台裸 Ubuntu 上用 kubeadm 搭了一套高可用 K8s 平台（3 控制面 + 2 worker），CNI 用 Cilium、存储用 Longhorn、监控用 Prometheus+Grafana+Loki，并接通了完整 CI/CD：Gitea 存代码、Jenkins+Kaniko 构建镜像推 Harbor、ArgoCD 做 GitOps 自动部署。还跑通了一个 MySQL+Go+Vue 三层应用的真实发布，配了 HPA 自动扩缩、Ingress 域名、Hubble 流量观测。

2. 平台架构(能默画出来)

                kubectl / 业务
                     │
              k8s-api:16443 (每节点本地 HAProxy)
                     │
        ┌────────────┼────────────┐
     apiserver×3 + stacked etcd×3 (Raft 多数派=2,容忍挂1台)
                     │
   ┌───────┬─────────┼─────────┬──────────┐
 Cilium   Longhorn  Prometheus  Harbor/Gitea  Kyverno
 (CNI/eBPF)(块存储)  +Grafana   +Jenkins      (准入)
  Hubble   多副本    +Loki      +ArgoCD
                                  │
   CI/CD: git push → Jenkins+Kaniko → Harbor → ArgoCD(GitOps) → 滚动上线
   运行时: Ingress → Vue(nginx) → Go后端 → MySQL(Longhorn PVC),HPA 自动扩缩

3. 高频问答(围绕这套就能答)

Q: 为什么 3 个控制面? etcd 用 Raft,多数派 = (N/2)+1。3 节点多数派为 2,能容忍挂 1 台;2 节点挂 1 台就没多数派,不算 HA。所以控制面要奇数,最少 3。

Q: apiserver 怎么做高可用? 每个节点本地跑 HAProxy 监听 127.0.0.1:16443,后端是 3 个 apiserver(:6443)。kubelet/kubectl 只连本机入口,不依赖外部 LB,任一 apiserver 挂了 HAProxy 自动剔除。

Q: 节点 NotReady、Pod Pending 怎么排? 没装 CNI 时节点必 NotReady、coredns Pending(拿不到 Pod IP),这是正常的。装完 CNI(Cilium)恢复。真故障看 kubectl describe node 的 condition + kubelet 日志。

Q: Pod 之间怎么通信的?Service 怎么转发? Cilium(eBPF)给每个 Pod 分 IP、跨节点走 VXLAN 隧道封装;Service 的 ClusterIP 由 Cilium/kube-proxy 做负载均衡到后端 Endpoints。能用 hubble observe 看到实际流向和放行/拒绝。

Q: PVC 怎么工作?数据怎么不丢? PVC 申请 → StorageClass(longhorn)动态制备 PV → Longhorn 建多副本卷分布在不同节点 → CSI 把卷 attach/mount 到 Pod 所在节点。Pod 重调度到别的节点时重挂同一个卷,数据还在(我实测删 MySQL Pod 数据不丢)。

Q: CI/CD 整条链路讲一下? 源码 repo 和部署 repo 分开:push 源码触发 Jenkins,用 Kaniko(无需 Docker daemon,在 Pod 里构建)打镜像推 Harbor,然后 Jenkins 改部署 repo 的镜像 tag 并 push 回去;ArgoCD watch 部署 repo,检测到变更自动 sync,K8s 滚动更新。镜像 tag 每次变更都在 Git 里可审计、可回滚。

Q: HPA 怎么扩缩? metrics-server 提供 Pod CPU/内存指标,HPA 按目标利用率(如 CPU 50%)算期望副本数,在 min~max 之间调。我实测压测时 backend 从 2 扩到 6,停压测约 5 分钟缩回。

Q: 准入控制(为什么我的 Pod 被拒)? Kyverno 是准入策略引擎,Pod 创建时 webhook 拦截校验。比如"必须设 resources.requests" —— Audit 模式只记审计、Enforce 模式直接拒。报错 was blocked due to the following policies 不是 K8s 坏了,是策略在干活,按报错改 YAML 即可。

4. 真实踩坑(面试讲"我踩过的坑"最加分)

讲坑的套路:现象 → 怎么定位 → 根因 → 解法 → 教训。MTU 那个尤其能体现你懂封装开销和排查方法论。

5. 诚实差距(面试问"离生产还差什么",这样答=加分)

我搭的是核心控制回路的完整切片,生产还要在上面加几层加固和成熟度:

• 安全:密钥管理(Vault/External-Secrets,别明文)、TLS 全链路(cert-manager)、镜像签名扫描门禁、NetworkPolicy 微隔离、RBAC 最小权限 + SSO/审计
• 发布成熟度:多环境晋升(dev/staging/prod)、流水线测试门禁、金丝雀/蓝绿(Argo Rollouts)、webhook 自动触发
• 可观测性:补第三根支柱分布式追踪(OpenTelemetry/Jaeger),SLO/告警路由
• 可靠性:备份灾备(Velero+演练)、集群升级、节点级弹性(Cluster Autoscaler)、多集群/多 AZ
• 数据:DB 用 Operator(CloudNativePG/Percona)做主从+备份,别单副本

能说出"我知道差这些、以及大厂分别用什么补",比"我全做完了"更可信 —— 因为没人能在 5 台机器上把生产全做完,知道边界本身就是能力。

6. 各组件入口速记