vSphere 8 + Rocky Linux 10 内网生产级 Kubernetes 集群架构设计
vSphere 8 + Rocky Linux 10 内网生产级 Kubernetes 集群架构设计
1. 背景与目标
当前内网基础设施基于 vSphere 8：
- 3 台 Dell R730 物理服务器。
- 每台服务器安装 ESXi 8 Dell 定制版。
- 已部署 VCSA 8。
- vSphere / ESXi 具备企业许可。
- 每台物理机配置约：
- 40 核 CPU。
- 128 GB 内存。
- 512 GB SSD 系统盘。
- 2 TB NVMe SSD。
- RAID 后约 12 TB 机械盘。
- 1 张 4 口网卡。
- 当前物理网络：
192.168.9.0/24，已经被部分物理设备使用。 - 当前容器环境：已有 Docker，但 Kubernetes 生产运行时希望迁移到 containerd。
本设计目标是在现有 vSphere 8 上，通过 Rocky Linux 10 虚拟机构建一套严格生产级的 Kubernetes 集群，支持：
- 3 个 control-plane 节点。
- 3 个 stacked etcd 节点，与 control-plane 共部署。
- control-plane 与 worker 不混合承担业务角色。
- kubeadm 部署，并逐步封装为 Ansible 自动化。
- containerd 作为 CRI 运行时。
- Cilium 作为 CNI，启用 NetworkPolicy 与 Hubble 东西向可观测。
- Ingress Controller 暴露内网服务。
- 后续支持公网入口。
- dev / test / staging / prod 共用一个集群，但通过 namespace、RBAC、NetworkPolicy、Quota、NodePool 做强隔离。
- 支持 Harbor、GitLab、Java 后端、Nacos、Redis、PostgreSQL、AI/RAG、前端、SSR、监控、日志、链路追踪等服务。
- 支持滚动发布、灰度发布、蓝绿发布。
- 一小时内恢复目标。
2. 总体结论
2.1 推荐路线
推荐架构如下：
1 | |
第一阶段建议先建设：
1 | |
后续如果要把 PostgreSQL、Redis、Nacos、MinIO、Elasticsearch 等核心有状态服务迁入 Kubernetes，再单独扩展：
1 | |
2.2 关键技术选型
| 层级 | 推荐选型 | 原因 |
|---|---|---|
| 虚拟化 | vSphere 8 | 已有企业许可，便于 VM 生命周期、快照、备份、迁移、资源调度 |
| OS | Rocky Linux 10 | RHEL 系，适合生产标准化 |
| Kubernetes 部署 | kubeadm + Ansible | 官方、透明、可控，便于学习和生产排障 |
| 容器运行时 | containerd | 直接符合 Kubernetes CRI，不再依赖 Docker dockershim / cri-dockerd |
| CNI | Cilium | eBPF、NetworkPolicy、Hubble 东西向可观测能力强 |
| API Server HA | HAProxy + Keepalived VIP | 简单、成熟、内网可控 |
| Service LB | MetalLB L2 | 内网裸金属/虚拟化环境常用，给 LoadBalancer Service 分配内网 IP |
| Ingress | ingress-nginx，后续可评估 Cilium Gateway API | 运维资料多，兼容性强 |
| 证书 | cert-manager + 内网 CA | 内网统一签发 TLS，公网另走 ACME / DNS-01 |
| 镜像仓库 | Harbor + Trivy | 私有镜像、代理缓存、漏洞扫描 |
| GitOps | Argo CD | 环境声明式部署与回滚 |
| 灰度/蓝绿 | Argo Rollouts | 支持 canary、blue-green、分析指标联动 |
| 监控 | kube-prometheus-stack | Prometheus Operator + Grafana + Alertmanager 标准组合 |
| 日志 | Loki + Grafana Alloy | 轻量、与 Grafana 体系集成好 |
| 链路追踪 | OpenTelemetry Collector + Tempo | Java 服务接入简单，和 Grafana 联动好 |
| 备份 | etcd snapshot + Velero + MinIO/S3 | 免费开源，可备份 K8s 资源与部分 PVC 数据 |
| 策略治理 | Kyverno + Pod Security Admission | 镜像来源、权限、资源、运行时安全策略管控 |
3. 重要原则
3.1 Kubernetes 节点不要直接安装在 ESXi 物理宿主机上
虽然可以把 Rocky Linux 10 直接装在物理机上，但当前已经有 vSphere 8 与 VCSA 8，建议 Kubernetes 节点全部使用 VM。
原因：
- 不污染 ESXi 宿主机。
- VM 可复制、快照、迁移、重建。
- control-plane 可通过反亲和规则分布到不同 ESXi。
- 后续新增、缩容、替换节点更方便。
- 物理层故障与 K8s 节点故障边界更清晰。
3.2 Docker 保留给构建，Kubernetes 运行时切换到 containerd
生产集群节点建议不再使用 Docker 作为 Kubernetes runtime。
推荐：
1 | |
不建议：
1 | |
cri-dockerd 可以用，但会多一层兼容链路。新建生产集群没有必要绕路。
3.3 严格生产级与“四套环境共用一个集群”存在天然冲突
你希望 dev / test / staging / prod 共用一个集群。这个可以做，但要实话实说：
- 严格生产环境最理想是 prod 独立集群。
- dev / test 的不稳定变更不应影响 prod。
- 共用集群会共享 API Server、etcd、CNI、Ingress、存储、监控等基础面。
- 一旦集群级组件异常，四套环境会一起受影响。
因此本方案采用两阶段策略：
1 | |
阶段 1 必须配套：
- namespace 隔离。
- RBAC 隔离。
- NetworkPolicy 默认拒绝。
- ResourceQuota / LimitRange。
- 独立 Ingress 域名。
- 独立 secret。
- 独立 Argo CD Application。
- prod workload 优先级更高。
- prod 禁止使用 latest 镜像。
- prod 禁止开发者直接 kubectl apply。
4. 物理与虚拟化架构
4.1 物理主机规划
| ESXi 主机 | 角色 | 建议承载 |
|---|---|---|
| esxi-01 | 物理宿主机 | k8s-cp-01、k8s-infra-01、k8s-app-01、后续 k8s-data-01 |
| esxi-02 | 物理宿主机 | k8s-cp-02、k8s-infra-02、k8s-app-02、后续 k8s-data-02 |
| esxi-03 | 物理宿主机 | k8s-cp-03、k8s-infra-03、k8s-app-03、后续 k8s-data-03 |
必须配置：
- control-plane VM 反亲和：3 个 control-plane 分散到 3 台 ESXi。
- infra worker VM 反亲和：Ingress / Harbor / 监控副本尽量分散。
- app worker VM 按业务副本反亲和。
- 如果启用 DRS，应避免所有关键 VM 被迁移到同一台 ESXi。
- 不建议长期依赖 VMware snapshot 作为备份。
4.2 VM 规格建议
control-plane + etcd VM
| 项 | 建议 |
|---|---|
| 数量 | 3 |
| vCPU | 6~8 |
| 内存 | 16~24 GB |
| 系统盘 | 100 GB SSD |
| containerd 盘 | 100~200 GB SSD，挂载 /var/lib/containerd |
| etcd 盘 | 100~200 GB SSD/NVMe，挂载 /var/lib/etcd |
| 网络 | 1 个 VMXNET3 vNIC，接入 K8s Node VLAN |
control-plane 节点必须 taint，禁止普通业务 Pod 调度：
1 | |
infra worker VM
| 项 | 建议 |
|---|---|
| 数量 | 3 |
| vCPU | 8~12 |
| 内存 | 32~48 GB |
| 系统盘 | 100 GB SSD |
| containerd 盘 | 300~500 GB SSD/NVMe |
| 数据盘 | 按 Harbor、监控、日志需求单独挂载 |
| 角色 | Ingress、Harbor、Argo CD、监控、日志、链路追踪、cert-manager 等 |
app worker VM
| 项 | 建议 |
|---|---|
| 数量 | 3 起步，建议后续 6 |
| vCPU | 8~16 |
| 内存 | 32~64 GB |
| 系统盘 | 100 GB SSD |
| containerd 盘 | 300~500 GB SSD/NVMe |
| 角色 | Java 后端、前端、SSR、AI/RAG 服务 |
data worker VM，第二阶段
| 项 | 建议 |
|---|---|
| 数量 | 3 起步 |
| vCPU | 8~16 |
| 内存 | 64 GB 起 |
| 系统盘 | 100 GB SSD |
| containerd 盘 | 300 GB SSD |
| 数据盘 | 独立 VMDK，优先 NVMe/SSD，避免和系统盘混用 |
| 角色 | PostgreSQL、Redis、Nacos、MinIO、对象存储、向量库等 |
5. 网络架构
5.1 是否需要重新规划网段？
建议重新规划。
当前 192.168.9.0/24 已经被物理机器、vCenter、ESXi 等使用。Kubernetes 节点、Ingress、MetalLB、存储、备份如果继续堆在这个网段，后期会出现：
- 地址管理混乱。
- MetalLB IP 池和现有设备冲突。
- 防火墙规则难以收敛。
- DNS 记录难维护。
- VPN / 路由排错困难。
推荐将 192.168.9.0/24 保留为管理网，不再继续塞业务入口。
5.2 VLAN / 子网建议
如果交换机、OpenWrt、ESXi vSwitch / vDS 支持 VLAN，建议规划如下：
| 网络 | VLAN | CIDR | 用途 |
|---|---|---|---|
| 管理网 | 9 | 192.168.9.0/24 |
ESXi、VCSA、路由器、管理跳板机 |
| K8s Node 网 | 20 | 192.168.20.0/24 |
K8s VM 节点、API VIP、MetalLB、Ingress 内网入口 |
| 存储网 | 30 | 192.168.30.0/24 |
后续 vSAN / Ceph / Longhorn / NFS / iSCSI |
| 备份网 | 40 | 192.168.40.0/24 |
Velero、MinIO、备份任务、离线备份 |
| DMZ / 公网入口 | 50 | 192.168.50.0/24 |
公网反代、WAF、边界网关，可选 |
如果短期不想上 VLAN，最低限度也建议：
1 | |
这要求 OpenWrt 或三层交换机能在两个网段之间路由。
5.3 K8s 地址规划
推荐：
| 类型 | 地址段 / 地址 | 说明 |
|---|---|---|
| Node 网段 | 192.168.20.0/24 |
K8s VM 所在网段 |
| API Server VIP | 192.168.20.10 |
Keepalived + HAProxy |
| MetalLB Pool | 192.168.20.100-192.168.20.149 |
LoadBalancer Service IP 池 |
| Ingress 内网 IP | 192.168.20.100 |
ingress-nginx LoadBalancer IP |
| Harbor IP | 192.168.20.101 |
如果 Harbor 暴露为 LoadBalancer |
| GitLab IP | 192.168.20.102 |
如果 GitLab 暴露为 LoadBalancer |
| Pod CIDR | 10.244.0.0/16 |
Cilium Pod 地址池 |
| Service CIDR | 10.96.0.0/12 |
Kubernetes Service 地址池 |
注意：
- Pod CIDR / Service CIDR 不能与现有内网、VPN、未来 WireGuard/OpenVPN 网段冲突。
- 如果未来 VPN 会使用
10.0.0.0/8的一部分，需要提前确认，避免后面重建集群。 - API VIP、MetalLB IP 池必须从 DHCP 地址池中排除。
5.4 API Server 高可用
采用：
1 | |
建议部署方式：
1 | |
请求链路：
1 | |
5.5 Service 与 Ingress 入口
内网服务暴露采用：
1 | |
典型访问链路：
1 | |
公网访问建议不要直接暴露整个 K8s 节点网段，而是：
1 | |
公网入口建议单独建：
- 独立 IngressClass：
nginx-public。 - 独立 LoadBalancer IP。
- 独立 NetworkPolicy。
- 独立证书策略。
- 可选 WAF / rate limit / IP allowlist。
6. DNS 与域名规划
6.1 不建议继续使用 .local
.local 与 mDNS / Bonjour 存在冲突，尤其 macOS、iOS、部分 Linux 桌面环境、打印机、NAS、智能家居设备会默认把 .local 当作多播 DNS 使用。
因此不建议继续使用：
1 | |
6.2 推荐域名方案
方案 A：拥有公网域名，最佳长期方案
如果你有自己的公网域名，例如：
1 | |
推荐使用 split-horizon DNS：
1 | |
优点：
- 可以申请公网可信证书。
- 不和特殊用途域名冲突。
- 内外网 DNS 分离清晰。
- 企业化程度最高。
方案 B：纯内网，推荐 home.arpa
如果只是内网自用，可以使用：
1 | |
示例：
1 | |
缺点：
- 不能申请公开可信 TLS 证书。
- 需要内网 CA。
- 外网访问要用公网域名另配。
方案 C：.internal
.internal 近年来被保留给私有用途，但家庭/小型内网生态兼容性不如 home.arpa 明确。你的场景如果偏家庭/实验室/内网，优先 home.arpa；如果更偏公司内部网络，且你明确要私有命名，可以评估 .internal。
本方案推荐：
1 | |
6.3 OpenWrt + AdGuard + dnsmasq 建议拓扑
推荐：
1 | |
最低可先配置一条泛域名：
1 | |
这样大部分服务只需要配置 Ingress host，不需要每个服务都改 DNS。
7. Kubernetes 核心组件设计
7.1 Kubernetes 版本
建议选择当前稳定维护分支中的一个版本，例如：
1 | |
由于 Rocky Linux 10 较新，第一版建议先在测试 VM 上验证：
- containerd。
- kubelet。
- Cilium。
- SELinux enforcing。
- firewalld rules。
- ingress-nginx。
- MetalLB。
生产版本策略：
- 固定 minor 版本。
- 固定 patch 版本。
- 禁止无计划自动升级 kubelet / kubeadm / kubectl。
- 每季度规划升级窗口。
- 先升级测试 namespace，再升级 staging，再滚动升级 worker，最后升级 control-plane。
7.2 容器运行时 containerd
节点统一使用：
1 | |
建议目录：
1 | |
镜像源：
- Harbor 作为内部私有仓库。
- Harbor 配置 Docker Hub / GHCR / Quay 等代理缓存。
- containerd 配置 registry mirror 指向 Harbor。
- 生产 namespace 只允许从 Harbor 拉镜像。
7.3 kubeadm 部署模式
使用 kubeadm 部署 stacked etcd 高可用集群：
1 | |
kubeadm 初始化时关键参数：
1 | |
api.k8s.egon.home.arpa 解析到：
1 | |
也就是 Keepalived VIP。
7.4 Cilium 网络
推荐 Cilium 配置方向：
1 | |
建议启用能力：
- L3/L4 NetworkPolicy。
- DNS-aware egress policy。
- Hubble flow visibility。
- Service map。
- 严格 egress 管控。
NetworkPolicy 默认策略：
1 | |
8. 环境与命名空间规划
8.1 Namespace 设计
建议：
1 | |
更严格的做法：
1 | |
例如：
1 | |
如果应用很多，不建议所有 prod 应用挤在一个 prod namespace。
8.2 Node Label / Taint 设计
示例：
1 | |
control-plane：
1 | |
data node：
1 | |
infra node 可按需设置：
1 | |
关键平台组件通过 toleration 调度到 infra node。
8.3 环境隔离
每个环境至少配置：
- ResourceQuota。
- LimitRange。
- NetworkPolicy。
- RBAC Role / RoleBinding。
- 独立 Secret。
- 独立 ConfigMap。
- 独立 Ingress host。
- 独立 Argo CD Project。
示例域名：
1 | |
prod 可以省略 prod 前缀，但内部资源命名仍建议保留 prod。
9. 存储架构
9.1 当前结论
当前没有 NAS、Ceph、vSAN 明确规划，因此不建议第一阶段把核心数据库直接迁入 Kubernetes。
第一阶段建议：
1 | |
Kubernetes 内部第一阶段只承载：
- 无状态 Java 服务。
- 前端 / SSR。
- AI/RAG 无状态 API。
- Nacos 客户端接入，Nacos 本体可暂时外部。
- Redis 可暂时外部。
- PostgreSQL 暂时外部。
- 监控、日志可以部署在集群内，但要有备份。
9.2 PVC 方案对比
| 方案 | 推荐程度 | 适用 | 问题 |
|---|---|---|---|
| vSphere CSI + vSAN/shared datastore | 强烈推荐，如果具备共享存储 | 生产 PVC、VM 生命周期一致 | 需要 vSAN 或共享存储基础 |
| Longhorn | 中小规模推荐 | 非核心 PVC、监控、日志、低中负载服务 | 对网络和磁盘稳定性敏感，高写入数据库需谨慎 |
| Rook Ceph | 生产能力强 | 对象、块、文件，多副本存储 | 运维复杂，对网络、磁盘、经验要求高 |
| NFS | 仅推荐非核心 | 备份、共享文件、低要求数据 | 单点、性能、锁、一致性风险 |
| Local PV | 特定场景 | 高性能单节点绑定工作负载 | 节点故障恢复复杂，不适合自动漂移 |
9.3 本方案推荐分阶段路线
阶段 1：保守生产
1 | |
阶段 2：建设共享存储
优先级：
1 | |
阶段 3：迁入有状态服务
迁入顺序建议：
1 | |
PostgreSQL 最后迁，因为它对存储、备份、恢复、延迟、IO 抖动最敏感。数据库不是不能上 K8s，是不能在存储没想清楚时上 K8s。这个坑很大，掉进去声音都带回声。
10. 镜像仓库与供应链安全
10.1 Harbor 部署建议
第一阶段建议 Harbor 部署在独立 VM，而不是直接部署在同一个 K8s 集群内。
原因：
- 集群拉镜像依赖 Harbor。
- 如果 Harbor 也只在集群内，集群恢复时可能出现“鸡生蛋，蛋生鸡”的问题。
- Harbor 需要可靠存储和备份。
推荐：
1 | |
Harbor 功能：
- 私有镜像仓库。
- Docker Hub 代理缓存。
- GHCR / Quay 代理缓存。
- 项目级权限。
- Trivy 漏洞扫描。
- 镜像保留策略。
- 镜像不可变 tag。
- robot account 给 CI/CD 使用。
10.2 镜像策略
生产要求：
- 禁止使用
latest。 - 生产镜像必须来自 Harbor。
- 镜像 tag 使用：
1 | |
示例：
1 | |
建议后续引入：
- Cosign 镜像签名。
- Kyverno 校验镜像仓库来源。
- Kyverno 校验禁止 privileged 容器。
- Trivy 扫描 critical/high 阈值阻断。
11. 安全架构
11.1 OS 安全
建议：
- SELinux 优先保持 enforcing。
- firewalld 开启，并按 zone 管理。
- 禁用 root SSH 登录。
- SSH 使用 key 登录。
- 所有节点时间同步。
- 所有节点开启 auditd。
- kubelet、containerd、crictl 版本固定。
- 生产节点禁止安装无关工具。
- 禁止在节点上直接 docker run。
11.2 firewalld 策略
不建议生产环境简单关闭 firewalld。
建议：
1 | |
需要在部署阶段整理端口白名单，包括：
- Kubernetes API Server 6443。
- etcd 2379/2380。
- kubelet 10250。
- HAProxy / Keepalived VRRP。
- Cilium VXLAN/Geneve 或 native routing 所需端口。
- Hubble relay / UI。
- MetalLB memberlist 7946 TCP/UDP。
- Ingress 80/443。
- Node exporter / Prometheus scrape。
11.3 Kubernetes 安全
必须配置：
- RBAC 最小权限。
- Pod Security Admission。
- namespace 默认 deny NetworkPolicy。
- Kyverno 策略。
- ResourceQuota 防止 dev/test 抢资源。
- LimitRange 避免 Pod 无限制。
- Secret 不进 Git 明文。
- kubeconfig 分角色管理。
- 禁止生产环境人工 kubectl apply。
- 禁止特权容器。
- 禁止 hostPath，除非平台组件明确需要。
- 禁止 hostNetwork，除非平台组件明确需要。
- 禁止容器 root 用户运行，例外需审批。
11.4 认证与权限
你当前暂无统一认证，第一阶段：
1 | |
第二阶段建议：
1 | |
对接：
- Kubernetes API。
- Argo CD。
- Grafana。
- Harbor。
- GitLab。
12. 证书架构
12.1 内网证书
推荐：
1 | |
流程：
- 生成内网 Root CA。
- 安装到 Mac、Windows、Linux、移动设备的受信任根证书。
- cert-manager 使用 CA Issuer 签发 Ingress TLS。
- 所有内网 HTTPS 服务统一走 cert-manager。
12.2 公网证书
公网不要使用 home.arpa。
公网建议使用你实际拥有的公网域名，例如：
1 | |
申请方式：
- Let’s Encrypt HTTP-01：适合公网 80/443 直通。
- Let’s Encrypt DNS-01：适合泛域名证书，推荐。
公网入口建议和内网入口分离：
1 | |
13. 可观测性架构
13.1 监控
推荐：
1 | |
监控对象：
- ESXi / vCenter，后续通过 exporter 或 Telegraf。
- Kubernetes API Server。
- etcd。
- kubelet。
- containerd。
- Cilium。
- CoreDNS。
- Ingress Controller。
- MetalLB。
- Harbor。
- GitLab Runner。
- Java 应用 JVM。
- PostgreSQL / Redis / Nacos。
- 节点磁盘、网络、CPU、内存。
核心告警：
- etcd leader 变更频繁。
- etcd fsync 延迟高。
- API Server 错误率升高。
- Node NotReady。
- Pod CrashLoopBackOff。
- 节点磁盘压力。
- containerd 镜像盘占用过高。
- Cilium agent 异常。
- Ingress 5xx 升高。
- JVM heap / GC 异常。
- PVC 容量不足。
13.2 日志
推荐：
1 | |
日志策略：
- 平台组件日志保留 7~15 天。
- 应用日志保留 15~30 天。
- prod 关键日志可归档到对象存储。
- Java 应用必须输出 JSON 日志。
- 所有日志包含 traceId、spanId、env、namespace、pod、container、app、version。
13.3 链路追踪
推荐：
1 | |
Java 服务建议统一接入：
- HTTP Server。
- HTTP Client。
- JDBC。
- Redis。
- Kafka/RabbitMQ。
- gRPC。
- Dubbo，如果使用。
日志和 trace 关联：
1 | |
13.4 网络可观测
Cilium Hubble 用于查看：
- Pod 到 Pod 的流量。
- DNS 查询。
- 被 NetworkPolicy 拒绝的流量。
- 服务依赖关系。
- L7 HTTP 访问流。
这对排查“服务怎么突然不通了”非常有用。没有 Hubble 的时候，网络问题经常像黑盒魔法；有 Hubble 至少能看见魔法师的手在哪里动。
14. 备份与灾备
14.1 RTO / RPO 目标
目标：
1 | |
但必须明确：
- etcd 本地快照只能解决误删和部分控制面问题。
- 如果快照只留在本机，本机或 datastore 损坏时仍然会丢。
- 严格生产必须至少复制到另一台机器或独立备份存储。
14.2 etcd 备份
建议：
1 | |
备份位置：
1 | |
必须定期演练：
- 单 control-plane 故障恢复。
- etcd member 替换。
- 从 snapshot 恢复测试集群。
14.3 Velero 备份
推荐使用：
1 | |
备份内容：
- Namespace。
- Deployment / StatefulSet / DaemonSet。
- Service / Ingress。
- ConfigMap / Secret。
- CRD。
- RBAC。
- PVC 数据，取决于 CSI snapshot 或文件系统备份能力。
建议：
1 | |
如果存储支持 CSI Snapshot，优先使用 CSI Snapshot。
如果不支持，可用 Velero FSB / Kopia / Restic 方式，但要接受性能和一致性限制。
15. 发布与 CI/CD 架构
15.1 推荐流水线
1 | |
15.2 GitOps 目录建议
1 | |
15.3 发布策略
滚动发布
适合大多数 Java 服务：
1 | |
蓝绿发布
适合：
- 前端。
- SSR。
- 关键后端。
- 需要快速回滚的服务。
使用：
1 | |
灰度发布
适合：
- 新接口。
- 新算法。
- AI/RAG 服务。
- 用户影响较大的变更。
使用：
1 | |
灰度指标：
- HTTP 5xx。
- P95/P99 latency。
- JVM error。
- business error code。
- AI 服务 token error / timeout。
16. 有状态服务迁移策略
16.1 Nacos
建议：
1 | |
16.2 Redis
建议：
1 | |
Redis 迁入前必须明确：
- 持久化策略。
- AOF/RDB。
- 备份方式。
- 故障切换演练。
- 客户端连接方式。
16.3 PostgreSQL
PostgreSQL 不建议第一阶段迁入。
如果后续迁入，建议：
1 | |
16.4 GitLab
GitLab 非常吃资源，也有 PostgreSQL、Redis、Gitaly、对象存储等依赖。
建议：
1 | |
16.5 Harbor
Harbor 推荐第一阶段独立 VM。
如果迁入 K8s：
- registry 存储放对象存储或可靠 PVC。
- PostgreSQL / Redis 高可用。
- 定期备份。
- 镜像保留策略。
- 镜像扫描数据库更新策略。
17. Ansible 自动化范围
第一阶段 Ansible 应覆盖：
1 | |
建议目录：
1 | |
18. 实施阶段规划
阶段 0：前置确认
必须确认：
- 交换机是否支持 VLAN trunk。
- OpenWrt 是否承担三层网关。
- ESXi 是否用 vSwitch 还是 vDS。
- ESXi 之间网络是 1G、10G，还是混合。
- 是否计划启用 vSAN。
- 是否有共享 datastore。
- 是否有独立备份存储。
- 公网域名是否已拥有。
- 公网 IP 入口是否走 OpenWrt。
阶段 1：网络与 DNS
- 规划 VLAN。
- 创建 K8s Node 网段。
- 创建 DNS：
egon.home.arpa。 - 创建 API VIP 记录。
- 创建 Ingress 泛域名记录。
- 预留 MetalLB 地址池。
阶段 2：VM 与 OS
- 创建 3 个 control-plane VM。
- 创建 3 个 infra worker VM。
- 创建 3 个 app worker VM。
- 安装 Rocky Linux 10。
- Ansible 初始化 OS。
- 配置 containerd。
阶段 3：Kubernetes 核心集群
- 部署 HAProxy + Keepalived。
- kubeadm 初始化第一个 control-plane。
- 加入其他 control-plane。
- 加入 worker。
- 安装 Cilium。
- 验证 Hubble。
- 验证 NetworkPolicy。
阶段 4：平台组件
- MetalLB。
- ingress-nginx。
- cert-manager。
- Harbor。
- Argo CD。
- kube-prometheus-stack。
- Loki + Alloy。
- Tempo + OTel Collector。
- Velero。
- Kyverno。
阶段 5：应用上云
顺序：
1 | |
阶段 6：有状态迁移
满足以下条件后再做：
- 存储方案稳定。
- 备份恢复演练通过。
- 监控告警完善。
- NetworkPolicy 完成。
- 发布流程稳定。
- 有回滚方案。
19. 风险与对策
| 风险 | 说明 | 对策 |
|---|---|---|
| 单集群承载四环境 | dev/test 可能影响 prod | namespace + RBAC + quota + networkpolicy，后续拆 prod 集群 |
| 无共享存储 | VM / PVC 高可用受限 | 优先外置数据库，后续 vSAN / Ceph / Longhorn |
| etcd 只本地备份 | 宿主机或 datastore 损坏会丢 | 快照必须复制到异机或 MinIO/NFS |
.local 冲突 |
mDNS/Bonjour 影响解析 | 迁移到 egon.home.arpa 或自有公网域名 |
| Harbor 在集群内自举问题 | 集群恢复时拉不到镜像 | 第一阶段 Harbor 独立 VM |
| 生产使用 Docker runtime | 多 cri-dockerd 兼容层 | 新集群直接 containerd |
| firewalld 关闭 | 节点暴露面过大 | 开启 firewalld，明确端口白名单 |
| SELinux 关闭 | OS 安全降低 | 尽量 enforcing，遇到问题逐项修复 |
| 1G 网络跑分布式存储 | 延迟和吞吐瓶颈 | 存储网尽量 10G；核心 DB 外置 |
| RAG/AI 服务资源波动 | CPU/内存/GPU/IO 不稳定 | 独立 node pool、quota、HPA/VPA、限流 |
20. 第一版推荐落地配置
20.1 节点
1 | |
20.2 VIP / LB
1 | |
20.3 CIDR
1 | |
20.4 组件部署顺序
1 | |
21. 待确认事项
下一版安装手册和 Ansible 脚本前，需要确认：
- 交换机型号，是否支持 VLAN trunk。
- ESXi 物理网口是 1G 还是 10G。
- 是否启用 vSphere Distributed Switch。
- 是否有 vSAN 许可与启用计划。
- 三台 ESXi 是否有共享 datastore。
- 是否有独立备份机器或备份盘。
- 是否拥有公网域名。
- 公网 IP 的入口设备是 OpenWrt 还是其他路由器。
- 未来 VPN 网段，避免和 Pod/Service CIDR 冲突。
- GitLab 是否必须部署在 K8s 内，还是可以先独立 VM。
- Harbor 是否接受第一阶段独立 VM。
- PostgreSQL 当前是否已有外部高可用方案。
22. 参考资料
- Kubernetes Container Runtimes: https://kubernetes.io/docs/setup/production-environment/container-runtimes/
- Kubernetes kubeadm HA: https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/
- Kubernetes cgroup driver: https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/
- Kubernetes releases: https://kubernetes.io/releases/
- Cilium: https://cilium.io/
- MetalLB: https://metallb.io/
- RFC 6762 Multicast DNS: https://datatracker.ietf.org/doc/html/rfc6762
- RFC 8375 home.arpa: https://datatracker.ietf.org/doc/html/rfc8375
- Harbor vulnerability scanning: https://goharbor.io/docs/edge/administration/vulnerability-scanning/
- Velero: https://velero.io/
- cert-manager SelfSigned / CA: https://cert-manager.io/docs/configuration/selfsigned/
- Grafana Tempo: https://grafana.com/docs/tempo/latest/
vSphere 8 + Rocky Linux 10 内网生产级 Kubernetes 集群架构设计
https://allendericdalexander.github.io/2026/06/21/devops/management/k8s-vsphere-rocky10-production-architecture/