面试准备笔记（运维与实施 · 姜龙龙）— 项目二：移动云生产级 Kubernetes 集群与可视化运维管控体系

素材来源：本人一手文档《Kubernetes v1.28.2 移动云生产高可用集群搭建方案》《Kuboard v3.5.2.2 运维集群部署方案》《移动云原生生产高可用集群+可视化运维管控体系建设方案》《移动云服务资源清单》。 本项目在简历上的定位：负责（资源评估 + 方案编制 + 部署实施 + 验证）。体系本身是互联网项目的通用云原生最佳实践，我的价值是把它在移动云环境完整落地、踩平所有坑、并能把每个选型的理由讲清楚——面试口径是"落地者"而不是"架构发明人"，讲深挖题（避坑清单）时最自信。

一、项目介绍（口述版，约 1.5 分钟）

2025 年下半年公司业务拓展到软件定制外包，新项目要上线，传统虚拟机部署模式资源交付慢、环境不一致、命令行运维门槛高。这套云原生底座采用业界通用的成熟体系，我完成了资源评估和建设方案编制，并负责在移动云苏州节点落地实施。

架构：VPC 私有网络跨三个可用区部署，7 台 ECS——3 台 master 组三副本控制平面，3 台 8 核 16G 的 worker 组业务负载池，再加 1 台独立监控节点。控制平面入口用云负载均衡 CLB 做四层转发和健康检查自动摘除，集群版本 Kubernetes v1.28.2，运行时 containerd 1.7.8，网络 Flannel VXLAN。监控是独立节点二进制部署的 Prometheus + Grafana，加集群内的 kube-state-metrics 和全节点 Node Exporter；运维管控平台用的 Kuboard，覆盖工作负载编排、日志终端排障、RBAC 权限和操作审计，日常运维 80% 的操作在页面上完成。

成果：控制平面按 99.99% 可用性目标设计，做过故障切换演练——关掉一台 master 的 kubelet，CLB 秒级摘除、kubectl 无感；资源交付从天级到分钟级；这套方案沉淀成标准化方法论，成为公司后续所有外包项目的标准基础设施底座。部署过程中踩的坑我整理成了 9 项生产避坑清单，全部写进了方案文档。

二、架构与规模速记（数字必须张口就来）

项	配置
云平台	移动云（苏州节点），VPC 192.168.0.0/24 跨 3 可用区
计算	master ×3（2C4G）、worker ×3（8C16G 计算增强型）、监控节点 ×1（4C8G）＝ 7 台 ECS
接入	CLB 四层 TCP，VIP:6443 → 三台 master apiserver，健康检查自动摘除；NAT 网关 + EIP 统一公网出口
OS	Ubuntu 22.04 为主（监控节点 24.04）
集群	Kubernetes v1.28.2（kubeadm），三副本 etcd（堆叠式），certSANs 含 CLB VIP
运行时	containerd 1.7.8，SystemdCgroup=true，pause 镜像换国内源
网络	Flannel v0.22.0 VXLAN；Pod 10.244.0.0/16，Service 10.96.0.0/12
镜像	内网私有仓库为主（ImagePullSecret 认证）+ 阿里云公共仓库备选
监控	Prometheus（二进制）+ Grafana + kube-state-metrics 2.7.0（集群内）+ Node Exporter（apt 包，全节点 9100）
管控	Kuboard v3.5.2.2：固定 master-01 调度 + hostPath 持久化 + NodePort 30088
云服务配套	MySQL 8.0 主备高可用（8C16G/300G SSD）、Redis 5 主备双机热备、RocketMQ 5 两节点、Nacos、WAF、DDoS 原生防护 5G、主机安全企业版、数据库审计

设计原则五条（方案文档原文，能整段背）：冗余（核心组件至少三副本）、解耦（控制面与数据面分离）、故障自愈（健康检查 + 自动重启）、分层防御（节点级/组件级/应用级）、强一致（etcd Raft 多数派）。

部署顺序（面试官爱问"你们怎么部署的"）：基础设施初始化 → 控制平面（master01 init → 02/03 join）→ CNI 网络插件（必须在 worker 加入前，否则节点 NotReady）→ worker 批量加入 → 全量健康验证 → 监控部署。

三、面试必问（通用题标准答案）

1. 为什么 3 个 master？etcd 为什么要奇数？

三副本是可用性和成本的标准平衡点。etcd 用 Raft 协议，写请求要多数派确认才提交：3 副本容忍 1 台故障（2/3 仍过半），4 副本同样只容忍 1 台（3/4 过半）却多花一台机器，5 副本才容忍 2 台——所以偶数副本没有意义，生产一般 3 或 5。我们堆叠式部署（etcd 与控制面组件同节点），3 台 master 跨可用区，实现机房级故障隔离。

2. CLB 在架构里起什么作用？为什么不用自建 Nginx+Keepalived？

CLB 是云上四层负载均衡，做三件事：统一 VIP 入口（所有 kubectl 和组件都连 VIP:6443，不感知后端 master 变化）、健康检查（master 异常秒级摘除）、故障透明切换（流量自动到健康节点）。选 CLB 而不是自建 Nginx+Keepalived 的理由：云上 CLB 是托管服务无单点、免运维，不需要自己维护 VIP 漂移和健康脚本；我在银行项目里做过 Nginx+Keepalived 方案，两种都熟，云上首选托管——这个对比本身就是我的一个亮点，因为两个方案我都有实操。

3. containerd 和 Docker 什么关系？为什么换？

containerd 本来就是 Docker 捐给 CNCF 的核心运行时，K8s 1.24 之后官方移除了 dockershim，直接用 containerd 是标准演进方向，少一层 dockershed 转发，更轻更稳。落地三个关键配置：SystemdCgroup = true（和 kubelet 的 cgroup 驱动对齐，不一致会导致资源统计漂移）、sandbox 镜像换成国内源（pause 镜像拉不下来 kubelet 起不来）、/etc/crictl.yaml 显式绑定 containerd 的 socket 路径（否则 crictl 默认遍历多个 socket 报错——这就是避坑清单第 2 条）。

4. Kuboard 是怎么部署的？（细节题，全是我做过的）

五步：① 在能访问公网的节点 docker pull eipwork/kuboard:v3.5.2.2；② tag 成内网仓库地址格式（仓库/项目/镜像:版本）push 到移动云私有仓库——内网仓库只在 VPC 内可达，所以直接在 master 节点上操作最省事；③ 建命名空间 + kubectl create secret docker-registry 生成 ImagePullSecret（私有仓库认证）；④ Deployment 里四个要点：nodeSelector 固定调度到 master-01（管控链路最短）、tolerations 容忍 control-plane 的 NoSchedule 污点、imagePullSecrets 挂认证密钥、hostPath 类型用 DirectoryOrCreate 自动建 /data/kuboard 目录做持久化（Pod 重建配置和审计日志不丢）；⑤ NodePort 30088 暴露，首次登录强制改密。持久化验证做过实测：手动删 Pod 触发重建，重新登录配置还在。

5. Prometheus 这套监控怎么搭的？怎么发现目标？

混合方案：Prometheus/Grafana 在独立监控节点用 apt 二进制部署（不占集群资源、故障隔离），node-exporter 所有集群节点 apt 安装（内网仓库没有容器镜像，二进制版默认监听 9100 和容器版完全兼容），kube-state-metrics 部署在集群内（Deployment + NodePort 30080，用系统内置 view 只读 ClusterRole 做权限绑定）。发现方式是 static_configs 静态指定：node-exporter 六台、kube-state-metrics 一台、apiserver 走 CLB VIP（https + insecure_skip_verify）。Grafana 添加 Prometheus 数据源，导 Node Exporter 和 K8s 大盘。为什么不用服务发现？节点规模小、变更少，静态配置最直观可控；规模上去后再换 kubernetes_sd_configs——这个取舍我能讲清楚。

6. 说一次高可用验证的实际操作。

停掉一台 master 的 kubelet → CLB 健康检查失败把节点摘除 → 通过 CLB VIP 执行 kubectl get nodes 正常返回 → 恢复 kubelet，控制面组件自动重启、etcd 自动同步重新加入。另外 Worker 层面靠 Pod 反亲和和多副本保证节点故障时 Pod 迁移到健康节点，分钟级恢复。证书运维也做了规范：集群证书默认一年，提前 30 天 kubeadm certs renew all；etcd 定期 snapshot save 快照备份。

7. 云上这些配套服务为什么用托管的（MySQL/Redis/RocketMQ）？

业务要求快速上线，托管服务自带高可用（MySQL 主备、Redis 双机热备）、备份、监控，运维成本远低于自建；网络和安全配套（WAF、DDoS、主机安全、数据库审计）是等保和客户合规要求。我的职责是规划规格、配安全组和访问控制、把连接信息交付给应用——同时集群内的有状态服务我坚持不进 K8s（数据库用云托管，不在集群里跑 Deployment），这个取舍的原理我能讲（滚动更新与数据一致性、伸缩粒度不匹配）。

8. 这个项目你个人最大的产出是什么？

三个：① 把通用云原生体系结合公司实际环境（移动云内网、资源规格）完整落地，输出建设方案，成为公司外包项目的标准底座；② 9 项生产避坑清单，每条都是实际踩出来并验证过解法的；③ 标准化部署顺序文档（IaC 理念的全节点统一初始化），新环境可以快速复制。体系不是我发明的，但在我们环境里从 0 到生产可用的每一件事是我做的。

四、项目深挖问题（9 项避坑清单 = 9 个故障故事）

用法：每条按"现象 → 定位 → 解决 → 预防"讲。面试官问"印象深刻的故障"时任选 1-2 条展开。

坑 1：节点加入后一直 NotReady（最高频）

现象：worker join 后 kubectl get nodes 显示 NotReady。 定位：kubectl get pods -n kube-flannel 发现 Flannel Pod ImagePullBackOff——海外镜像（ghcr.io/Docker Hub）在内网拉取失败，CNI 起不来，节点网络没配好自然 NotReady。90% 的 NotReady 都是镜像拉取问题。 解决：镜像分层策略——首选移动云内网仓库（把 daemonset 里 init 容器和主容器镜像全局替换成内网地址），备选阿里云公共仓库，兜底 apt 二进制装。 预防：部署顺序强制"先 CNI 后 worker"；镜像清单提前入内网仓库。

坑 2：crictl 执行报错

现象：crictl ps 报连接 socket 失败。 原因：crictl 默认按 docker/containerd/crio 顺序遍历 socket，环境里有多个运行时残留配置就乱。 解决：/etc/crictl.yaml 显式写死 runtime-endpoint 和 image-endpoint 指向 containerd.sock。

坑 3：etcd 健康检查报 Pod NotFound

现象：kubectl get pods -n kube-system | grep etcd 正常，但按文档敲 etcdctl 健康检查命令说 Pod 不存在。 原因：堆叠式 etcd 的 Pod 命名规则是 etcd-<节点主机名>（如 etcd-k8s-master-01），不带 kube- 前缀，命令里的名字和实际资源对不上。 解决：校验命令必须匹配真实命名。etcdctl 带 --cacert --cert --key 三证书连 127.0.0.1:2379 查 endpoint health，三副本全 healthy 才算过。

坑 4：ClusterRoleBinding 更新报错

现象：给 kube-state-metrics 配权限，apply ClusterRoleBinding 报字段不可更新。 原因：roleRef 字段是不可变字段，K8s 设计上禁止原地改绑定关系。 解决：kubectl delete clusterrolebinding xxx --ignore-not-found 删除重建。我们直接复用系统内置 view 角色（只读权限够用），遵循最小权限原则。

坑 5：Grafana 装不上（GPG 404）

现象：apt update 报 Grafana 源 GPG 密钥 404。 原因：阿里云 Grafana 镜像站的签名公钥 URL 失效。 解决：源配置加 [trusted=yes] 跳过签名校验（内网可控环境），或者直接下 DEB 包本地装。

坑 6：promtool 找不到包

现象：apt install promtool 报 Unable to locate package。 原因：Ubuntu 官方源里 promtool 内置在 prometheus 主包里，没有独立包。 解决：apt install prometheus 即可，装完自带 promtool。

坑 7：node-exporter 没有容器镜像

现象：内网仓库找不到 node-exporter 镜像。 解决：全节点 apt install prometheus-node-exporter，systemd 托管二进制运行，默认 9100，指标输出和容器版完全兼容，Prometheus 侧配置不用改。

坑 8：命名空间删了重建部署失败

现象：删除 monitoring 命名空间后重新部署，ServiceAccount/权限/应用各种残留冲突。 解决：完整重建链路——命名空间 → ServiceAccount → 权限绑定 → 应用资源，严格顺序创建；删除时等 Finalizer 清完再建。

坑 9：认证频繁失败

现象：节点间认证/日志时间戳乱跳。 原因：节点时间不同步，TLS 证书校验对时间敏感。 解决：全节点 chrony 指向移动云内网 NTP，偏差毫秒级；把"时间同步检查"写进初始化基线。

Q：如果集群要升级，你怎么做？

先备份 etcd 快照 → kubeadm 滚动升级，先控制平面后 worker，小版本跨级不超过 1 个 → 每台升级完验证节点 Ready 和业务 Pod 正常再下一台 → 提前确认镜像和 API 兼容性（废弃 API 变更）。

Q：未来演进怎么规划？（方案文档第六章，答规划题的弹药）

六条线：CBS 云硬盘 CSI 动态供给（StorageClass 声明式供给 + 快照备份）；Kuboard 多集群纳管统一管多套集群；全链路可观测（日志集中 + 链路追踪 + 告警聚合降噪，探索故障自愈）；CI/CD 流水线 + 蓝绿灰度发布；服务网格流量治理；成本治理（资源画像、多维度成本分摊）。每条我都能讲为什么排这个优先级——业务驱动，先把底座和可观测做稳，再上交付效率和治理类能力。

五、分层八股自测清单（对照知识库「05-八股文」「K8s补充」）

• K8s 核心：两大节点七组件、四大控制器区别（Deployment/StatefulSet/DaemonSet/Job）、Pod 创建销毁三步、四种 Service、五种 Volume、Ingress 链路（浏览器→DNS→LB→Ingress→Service→Pod）、探针三类（kubelet 发起）、驱逐机制（资源请求/QoS/节点压力）、污点容忍与亲和性（Kuboard 部署就用了）。
• 证书体系：CA/apiserver/etcd/kubelet/ServiceAccount 五类证书、renew、SAN。
• Docker/containerd：网络四模式、容器通信、Dockerfile 指令、COPY vs ADD、镜像分层。
• Prometheus：架构六组件、采集模型（pull）、PromQL 基础、Alertmanager 分组抑制。
• 网络：VXLAN 封装原理、Pod 跨节点通信、Service 转发（iptables/ipvs）、TCP/IP 基础。
• Linux：内核参数调优项含义（ip_forward、bridge-nf-call-iptables、swappiness=0 的原因）、swap 为什么禁（容器内存调度与性能抖动）、文件句柄数调优。

六、注意事项与口径

1. 数字口径红线：99.99% 是设计目标（三副本 + CLB 秒级摘除保障），不是运行实测 SLA；"效率提升 300%/资源利用率提升 40%"是方案规划的收益预估，面试时说"按方案目标"——不把规划数字说成实测结果，被追问就讲保障机制（怎么设计出 99.99%），机制比数字更值钱。
2. 脱敏：不报 VPC 网段、内网 IP、仓库域名和账号；说"内网私有仓库""某云厂商华东节点"即可。
3. 与项目一的衔接：被问"为什么上一个项目 K8s 1.17 这个 1.28"——上一个受 BCS 版本配套约束，这个是新集群按当时（2023 年末）稳定版自主选型，顺手能讲 1.24 移除 dockershim 的演进。
4. 角色口径：体系是业界通用实践，方案是我编制、部署是我执行、验证是我做的——讲的时候用"我编制方案、我部署、我验证"；被问"这套架构是你设计的吗"就答："架构采用通用最佳实践，我负责结合公司环境做方案编制和落地，每个选择的原因我都能讲清楚"。协作部分（应用联调、云服务采购）如实说"配合业务和开发"。
5. 演进规划题的答法：被问"如果让你主导下一阶段"，答"在现有底座上按演进路线推进（CSI → 多集群 → 可观测 → CI/CD）"——这条路线我在方案里写过，正好把"落地者"往"规划者"的能力上引，这是你下一份工作要成长的方向。

七、人事问题与反问（速记）

• 离职原因：三年合同到期 + 公司业务转外包后项目模板化，希望到技术挑战更丰富的环境继续深入云原生与 AI 方向。
• 本项目延续价值：这套"建设方案 + 避坑清单 + 标准化初始化"方法论可直接复用到新公司集群建设——面试时主动提，是即战力证明。
• 反问：贵司集群规模和版本？是否有多集群/CI/CD 的规划（正好接我的演进规划答案）？