构建高可用云原生架构:从云基础组件到 K8s 控制平面的全景指南(含架构图详解)

在当今的云原生时代,无论是后端开发者、运维工程师还是架构师,每天都会被各种眼花缭乱的技术名词包围:ECS、SLB、mTLS、Service Mesh、Kube-OVN、声明式 API……

这些概念看似分散在各个领域,但实际上它们共同拼图成了现代高可用、高并发应用的基础设施骨架。本文将通过一张张架构图,带你从底层的云服务器,一路漫游到 Kubernetes 的控制平面大脑。

第一层:云上的"砖块"与"门卫"——ECS 与 SLB

所有云上架构的起点,都离不开计算与流量分发。在阿里云等公有云体系中,最基础的黄金组合就是 ECS(弹性计算服务,即虚拟机)与 SLB(负载均衡)。

经典组合架构全景图

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
            公网用户
               │
               ▼
      ┌─── [EIP / SLB] ───┐     ← 接入层:流量分发、健康检查、SSL 卸载
      │                  │
      ▼                  ▼
┌─[ECS-A]-┐        ┌─[ECS-B]-┐   ← 计算层:多台 ECS 跨可用区部署
│ Web/微服务        │ Web/微服务
└────────┘        └────────┘
      ▲                  ▲
      │    [ESS 弹性伸缩]      ← 根据 CPU/QPS 自动增减 ECS 数量
      └────────┬────────┘
               ▼
      ┌──── [RDS / Redis] ────┐   ← 数据层:主备架构 + 读写分离
      └───────────────────────┘

图解:一次请求的完整生命周期

  1. 公网入口:用户请求首先打到 SLB 绑定的 EIP(弹性公网 IP)上。EIP 绑定到 SLB 而非单台 ECS,是为了保证后端实例可以自由扩缩、故障切换,而公网入口地址保持不变。
  2. 流量分发:SLB 根据监听器规则(四层 TCP 或七层 HTTP)和负载均衡算法(加权轮询、最小连接数等),选择一台健康的后端 ECS。
  3. 业务处理:ECS 处理业务逻辑,期间可能访问 RDS 读数据、Redis 读缓存。
  4. 健康检查:SLB 周期性探测后端 ECS,一旦某可用区节点异常,自动将其从负载均衡池剔除,流量转给健康节点——这就是高可用的本质。
  5. 弹性伸缩:当 ESS 监测到 ECS CPU 超过阈值(如 70%),分钟级扩容新实例并自动挂载到 SLB 后端;流量低谷时自动缩容释放,成本随流量曲线动态匹配。

SLB 产品家族选型表

类型 协议层 核心能力 单实例性能 典型场景
ALB(应用型) 七层 HTTP/HTTPS/QUIC 基于域名/路径/Header/Cookie 的内容路由 最高 100 万 QPS Web 应用、API 网关、灰度发布、K8s Ingress
NLB(网络型) 四层 TCP/UDP/TCPSSL 超高性能、自动弹性、全端口监听 最高 1 亿并发连接 IoT/MQTT、游戏、音视频、高并发 TCP
CLB(传统型) 四层 + 基础七层 老牌产品,仅基础转发 100 万并发 / 5 万 QPS 存量系统沿用(新业务不推荐)
GWLB(网关型) 三层 IP 通过 Geneve 隧道做透明流量牵引 — 防火墙、IDS/IPS 安全设备集群

实战场景:电商"双 11"零点流量洪峰——NLB 自动弹性扩容承接千万级并发连接;ESS 监测到 CPU 超标后分钟级扩容几十台 ECS 并自动挂到 NLB 后端;RDS 通过只读实例扛住读流量;高峰过后自动缩容。这就是"接入层 + 计算层 + 数据层"黄金组合的价值。

第二层:走进 K8s 网络——Subnet、EIP、mTLS 与 Service Mesh

当业务复杂到一定程度,传统 ECS 架构往往让位于 Kubernetes 容器化架构。在 K8s 多租户安全网络中,四个核心概念构成一条完整链路:

四概念协作关系图

1
2
3
4
5
6
7
8
9
10
11
公网用户
   │
   ▼  [EIP]  ── 公网入口,NAT 映射到 K8s 集群(解决"外部怎么进来",L3)
   │
   ▼  [Kube-OVN Subnet] ── 决定 Pod 的 IP 段与租户边界(解决"Pod 在哪",L2/L3)
   │
   ▼  [Istio sidecar / Service Mesh] ── L7 路由 + 灰度 + 遥测(解决"流量怎么治理",L4–L7)
   │
   ▼  [mTLS] ── 服务间加密与身份认证(解决"如何可信通信",L4)
   │
   ▼  目标 Pod

1. Subnet(子网)——Pod 的"门牌号规划"

子网是通过 CIDR 划分出的独立 IP 地址段(如 10.16.0.0/16 可容纳 6 万多个地址)。在 Kube-OVN 中,每个 Subnet 对应一个 OVN Logical Switch,Namespace 可绑定到 Subnet,其下所有 Pod 自动从该段分配 IP:

1
2
3
4
5
6
7
8
9
10
11
12
apiVersion: kubeovn.io/v1
kind: Subnet
metadata:
  name: production
spec:
  protocol: IPv4
  cidrBlock: 10.16.0.0/16
  gateway: 10.16.0.1
  excludeIps:
  - 10.16.0.1..10.16.0.10     # 预留给网关等设备的地址
  namespaces:
  - prod-ns                    # 绑定到该 Namespace,Pod 自动使用此网段

典型用法:生产、测试、财务系统分别绑定三个 Subnet,用 ACL 在子网边界做访问控制;给 KubeVirt 虚拟机预留静态 IP 段,保证热迁移时 IP 不变。

2. EIP(弹性公网 IP)——可漂移的"大门牌"

EIP 是独立持有的公网 IP 资源,位于云厂商公网网关上,通过 NAT 映射到被绑定的资源。它的核心价值在于解耦:把 EIP 从集群 A 的 SLB 解绑、绑到集群 B 的 SLB,秒级完成灾备切换,DNS 不变、用户无感。

在 Kube-OVN 多租户场景下,还有 VpcEip 和 VpcNatGateway CRD,让每个租户 VPC 拥有独立的 EIP 和 SNAT/DNAT 规则。

3. mTLS(双向 TLS)——服务间的"双向验明正身"

传统 TLS 只有客户端验证服务器;mTLS 要求双方都出示证书并互相验证。握手流程:

1
2
3
ClientHello → ServerHello + 服务器证书 + CertificateRequest
→ 客户端验证服务器证书 → 客户端提交自己的证书
→ 服务器验证客户端证书 → 双方协商对称密钥 → 加密通信

在 Istio 零信任体系中,每个 Service Account 都会获得一张内含 SPIFFE 身份的短期证书(如 spiffe://cluster.local/ns/default/sa/my-service),默认 24 小时自动轮换。通过以下 CRD 即可强制整个命名空间走 mTLS:

1
2
3
4
5
6
7
8
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT   # 明文流量直接被拒绝

4. Service Mesh(服务网格)——流量治理的"总调度台"

Mesh 通过在 Pod 旁注入 Envoy 代理,把路由、重试、加密、遥测从业务代码中剥离。最经典的玩法是声明式灰度发布:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts: [reviews]
  http:
  - match:
    - headers: {end-user: {exact: beta-tester}}
    route:
    - destination: {host: reviews, subset: v2}   # 内测用户全量走新版本
  - route:
    - destination: {host: reviews, subset: v1}
      weight: 95
    - destination: {host: reviews, subset: v2}
      weight: 5                                   # 其他用户 5% 灰度

实战场景:大促前将新推荐算法从 1% 逐步放量到 100%,只需修改 weight 字段;同时通过遥测面板观察新版本 P99 延迟,异常立即回滚 weight 为 0,全程零业务代码改动。

第三层:理清网络栈的"三剑客"——kube-proxy、CNI 与 Istio

三者分层数据路径图

一个跨节点 HTTP 请求的完整旅程,三条链路在同一份数据包上依次叠加:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
┌─────────────────── Pod A 所在节点 ───────────────────┐
│                                                      │
│  Pod A 发出请求 → 目标是 Service 的 ClusterIP          │
│        │                                             │
│        ▼                                             │
│  ① kube-proxy 编程的 iptables 规则                    │
│     把 ClusterIP DNAT 为某个具体 Pod B 的 IP           │
│        │                                             │
│        ▼                                             │
│  ② Istio 注入的 iptables 规则把出向流量                │
│     劫持到本 Pod 的 Envoy sidecar,                   │
│     Envoy 做 L7 路由 + mTLS 加密后发出                 │
│        │                                             │
└────────┼─────────────────────────────────────────────┘
         ▼
  ③ CNI(Kube-OVN)建立的 Geneve 隧道跨越物理网络
         │
┌─────────▼───────── Pod B 所在节点 ───────────────────┐
│        │                                             │
│  OVS/OVN 流表解封包,送入 Pod B 网络命名空间            │
│        │                                             │
│        ▼                                             │
│  再次被 Istio 规则劫持到 Pod B 的 Envoy,              │
│  解密后最终到达业务容器                                 │
└──────────────────────────────────────────────────────┘

多维对比总览

维度 kube-proxy CNI(Kube-OVN) Istio
所在层级 L4(TCP/UDP) L2/L3 组网为主 L4–L7 应用层
核心职责 Service 虚拟 IP → Pod 转发 Pod 网卡创建、IPAM、跨节点隧道、子网/VPC 流量管理、mTLS、可观测性、熔断
实现机制 iptables / IPVS / nftables OVS 流表 + Geneve 隧道 iptables/eBPF 劫持到 Envoy
典型 API Service、EndpointSlice Subnet、VPC、VpcNatGateway VirtualService、DestinationRule
有无代理 无(纯内核规则) 无(流表+隧道) 有(Envoy / ztunnel)

三个高频混淆点

  1. “Istio 替代 kube-proxy?” —— 不替代,是叠加。即便装了 Istio,kube-proxy 的 ClusterIP 转发规则依然生效。
  2. “Istio-CNI 是网络插件吗?” —— 不是。它只负责写流量劫持规则,Pod IP 分配仍由真正的网络 CNI 完成。
  3. “Kube-OVN 能替代 Istio 吗?” —— 不能。它能做 L3/L4 的 NetworkPolicy,但做不了 HTTP 路由、金丝雀、分布式追踪。

配置冲突提醒:Kube-OVN 安装时必须通过 --service-cluster-ip-range 显式感知 Service CIDR,否则其规则可能与 kube-proxy 冲突,导致 Service 无法访问。

第四层:所有一切背后的"大脑"——Kubernetes-like 控制平面

控制平面与数据平面分离架构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
┌───────────────── 控制平面(决策层)──────────────────┐
│                                                    │
│   用户提交 YAML(声明式 API)                          │
│        │                                           │
│        ▼                                           │
│   ┌──────────────┐    持久化     ┌──────────┐       │
│   │ API Server   │◄───────────►│   etcd   │       │
│   │(认证/鉴权/准入)│              │(唯一事实来源)│   │
│   └──────────────┘              └──────────┘       │
│        ▲              ▲                            │
│        │              │        Watch 资源变化        │
│   ┌────┴─────┐  ┌─────┴──────────┐                  │
│   │Scheduler │  │Controller Mgr  │                 │
│   │(计算最佳节点)│ │(各类调谐循环)  │                 │
│   └──────────┘  └────────────────┘                 │
└────────────────────┬───────────────────────────────┘
                     │ Watch API(数据平面主动感知)
┌────────────────────▼──── 数据平面(执行层)───────────┐
│   ┌──────────┐  ┌────────────┐  ┌──────────┐       │
│   │ kubelet  │  │ kube-proxy │  │ 容器运行时 │       │
│   │(Pod 生命周期)│ │(Service 转发)│ │(containerd)│ │
│   └──────────┘  └────────────┘  └──────────┘       │
└────────────────────────────────────────────────────┘

这套架构的底层逻辑是两大设计模式:

  • 声明式 API:用户声明"我要 3 个 nginx:1.25 副本",而非"启动 3 个容器"。
  • 调谐循环:控制器持续执行 Watch → Diff → Act → 更新 status。它是水平触发(周期性检查整体状态,宕机恢复后可重新收敛)且幂等(同一函数执行多次结果一致)的,因此天然具备故障自愈与漂移纠正能力。

该范式在五大场景中的落地

场景 代表系统 Desired State Actual State 控制器做的事
云资源管理 Crossplane YAML 声明的 Bucket/RDS 云厂商上的真实资源 调用云 API 创建资源,发现控制台手改后自动纠正
服务网格 Istio VirtualService 路由规则 各 Pod 中 Envoy 的实际配置 istiod 把 CRD 转换为 Envoy 配置并下发
GitOps ArgoCD Git 仓库中的 YAML 集群实际运行的资源 持续 Diff,发现漂移即同步/告警,回滚 = git revert
多集群管理 Karmada 用户提交的资源 + PropagationPolicy 各成员集群中的资源 按策略分发到上百个集群,支持 Push/Pull 两种模式
虚拟机管理 KubeVirt VirtualMachine CRD 节点上 libvirt/QEMU 运行的 VM VM 与 Pod 同一控制平面管理,支持热迁移、快照

结语:一张总图看懂全局

把四层知识串联起来,就是现代云上应用的完整骨架:

1
2
3
4
5
6
7
8
9
10
11
      [声明式控制平面]  ← ArgoCD/Crossplane/Istiod/Karmada 统一调度
             │
   ┌─────────┼─────────┐
   ▼         ▼         ▼
[EIP 入口] [SLB 分发] [Mesh 治理]  ← 南北向流量入口 + 东西向流量治理
   │         │         │
   ▼         ▼         ▼
[ECS/K8s Node 承载计算]  [Subnet 规划网络]  [mTLS 加密通信]
   │
   ▼
[Pod / 容器运行实际业务]

掌握各概念的分层定位——ECS 提供计算、SLB 提供入口、Subnet 规划地址、EIP 解耦公网、CNI 打通 Pod、kube-proxy 转发 Service、Mesh 治理东西向、控制平面声明一切——你就能在面对"该用 Kube-OVN 还是 Istio"、“该自建 VM 还是上 K8s”、"如何做流量灰度"这类问题时,迅速判断出归属与最佳组合。希望这篇带图详解的扫盲指南,能成为你探索云原生深水区的一张全景地图。