总结思考下系统架构的知识

在前公司和前前公司都是做了 platform engineer，感觉这个做的和 sre，运维，devops 基本是一样的。

在中大型企业中，随着业务体量扩展和对高可用性、安全性要求的提高，私有云成为了基础设施建设的重要组成部分。以下是对私有云架构、Kubernetes 集群接入、网络与权限管理等方面的实战总结。

1. 多 Region / 多 AZ 架构设计

企业私有云通常部署于多个物理数据中心（DC），按地域划分为 Region（如 jpe 日本东部，jpw 日本西部），每个 Region 包含多个 AZ（Availability Zone，可用区），如 jpe1、jpe2。这种结构带来以下优势：

• 多 AZ 部署保障单 AZ 故障下业务连续性
• 跨 Region 容灾，提升稳定性与抗灾能力
• 可结合流量策略实现就近访问与性能优化

当某 AZ 发生异常时，通过上层负载均衡器将流量导向健康 AZ 实例，保证服务可用。

2. 负载均衡器的层级与职责划分

在私有云中，LB（Load Balancer）负责处理不同层次的流量转发，常见类型包括：

• GSLB（Global Server Load Balancer）：主要基于 DNS 实现跨 Region 的智能解析，依据地理位置、健康状况或权重将请求路由至合适的 Region，可以把这个简单理解为 dns 服务器。
• HW-SLB（Hardware Load Balancer）：如 F5、A10 等物理设备，负责 L4/L7 转发，处理高并发和稳定性关键业务流量。
• SLB（Software Load Balancer）：基于 Nginx、HAProxy、Envoy 等构建，部署灵活，适合微服务场景下的 L7 应用路由。

LB 一般配置 VIP（Virtual IP）供客户端访问，通过规则将请求导流至后端 Node 或 Pod。

3. 私有云网络架构与路由机制

私有云网络较为复杂，涵盖多个专业领域：

• Network Team：负责物理链路、子网划分、BGP 广播、跨 DC 路由反射等底层设计。
• DNS Team：负责 GSLB 策略及内外部域名管理。
• 应用团队（App/Platform） 则关注网络如何与服务集成，不需介入底层实现。

私有云构建网络的典型流程：

1. 使用 SDN 构建逻辑网络
2. 划分 subnet（子网）并分配给节点（如物理机、K8s Node）
3. 通过路由器进行子网之间的互联
4. 考虑 IP 地址池有限性，合理设计扁平化网络结构

4. Kubernetes 接入私有云流量路径

在 Kubernetes 中，外部流量通过 LB 进入集群后，由 Ingress 控制器进行 L7 路由。典型路径如下：

[Client] → [GSLB] → [HW-LB/SLB] → [Ingress Gateway (Istio/Nginx)] → [Service] → [Pod]

• LB 后端指向的是一组 K8s Node（或指定 Ingress Controller 的 Pod）
• Ingress Controller 根据规则（域名、路径、Header）转发流量
• Pod 内服务实现最终业务处理逻辑

5. 对比负载均衡器，api 网关和 k8s ingress

在 k8s 集群中 ingress 负责将集群外的流量（从负载均衡器过来的）代理给 svc，ingress 虽然是 k8s 自己的概念，但最开始的入口流量是经过 k8s 集群外的负责均衡器（LB）的，比如 nginx。这里有个理解难点是集群外部的 LB 和集群内部的 ingress 之间的关系，涉及了 “集群外部 LB” 和 “集群内部 Ingress Controller” 的分工：

• 集群外部 LB（Load Balancer） 只是负责把流量转发到集群内部的一个或多个节点（通常是 Master/Worker 节点的某个端口）。
• 集群内部的 Ingress Controller 负责在 K8s 集群内，依据 Ingress 规则把流量进一步路由到具体的 Service/Pod。

简单说就是 k8s 没法直接操作 LB，需要在外部 LB 配置一组后端 k8s node(如配置 nginx 的 upstream)，外部 LB 把 80/443 端口的流量转发到这些节点的 NodePort，K8s 会在这些节点上打开一个端口，比如 30080，在这些节点上通常跑着一个或者多个 Ingress Controller Pod（比如 nginx-ingress），这样从 LB 的流量就首先到了 Ingress Controller Pod，Ingress Controller Pod 内部根据 Ingress 规则，再反向代理到集群内部 Service，再到 Pod。

[用户] → [你自建的 LB] → [NodePort SVC on 各Node] → [Ingress Controller Pod] → [后端 Service/Pod]

上面是 nodeport 的情况，在 k8s lb svc 的情况下云平台（需要云平台支持）会自动创建一个云 LB（比如 ELB），并暴露 LB 的 VIP（仔细想想前公司基于 istio ingress 做的 instant domain 好像就是这么回事），云 LB 的后端自动指向指定的 Service（本质上依然是集群内的 Node 的某个端口，但细节都被云平台屏蔽了），不需要关注 NodePort 了。云 LB 会把流量均衡到集群内对应的 Ingress Controller Pod（通过 Service 实现），Ingress Controller Pod 按 Ingress 规则将流量路由到具体 Service，再到 Pod。

[用户] → [云LB] → [LoadBalancer SVC] → [Ingress Controller Pod] → [后端 Service/Pod]

云 LB 后端与 K8s 集群联动原理：

• 云平台通过 cloud-controller-manager，自动监听到你的 LoadBalancer Service 变化。
• cloud-controller-manager 调用云平台自己的 api 来分配一个云负载均衡器（比如 ELB）。
• LB 的后端节点自动是你的集群 Node，端口为 Service 映射的端口。
• Service 负责把 LB 进来的流量转发到 Ingress Controller Pod。
• 无需自己维护外部 LB 的配置和节点池。

负载均衡器，比如 nginx，主要做的就是将客户端来的流量给分发到上游（upstream）服务器中，还有 https 配置啥啥的一些其他功能。

api 网关主要就是将各个 service 中 api 所统一需要的功能，比如鉴权，限流，日志等给聚合到一起，放在一些 api 的最前面，这样能减少重复开发，且服务中的 api 也能保持为纯净的业务相关。比较常用的是 kong，但是 istio 这样的服务网格也能做到类似功能。

6. 权限控制与边界安全管理

私有云场景下对权限与安全有更严格要求，主要涵盖：

• 节点权限：统一通过跳板机、堡垒机、VPN 控制对物理节点的 SSH 访问
• K8s 访问权限：通过 RBAC 控制 namespace、资源、操作的访问权限
• API 安全边界：Ingress 层进行 JWT/mTLS 鉴权，实现服务访问隔离

7. 云流量出入口管理

在私有云或混合云场景下，出入口流量控制是基础设施安全的重要组成部分。

流量入口（Ingress）

入口流量通常要经过多层负载均衡器（LB）：

[Client] → [GSLB] → [HW-SLB/SLB] → [Ingress Gateway] → [Service / Pod]

• GSLB 提供跨 Region 域名解析
• HW/SLB 负责四层或七层路由
• Ingress Gateway（如 Istio Gateway、Nginx Ingress）根据域名/路径路由到具体服务

这种多层入口设计有利于实现统一鉴权、WAF 防护、策略路由和可观测性集成。

流量出口（Egress）

出站流量控制主要目的是 保护内网资源，防止数据泄露与恶意外联，常见方式包括：

NAT（Network Address Translation）网关：

• 所有节点出站流量会经过 NAT 实例统一转发
• 实际出网 IP 会替换为 NAT Gateway 的公网 IP
• 可隐藏真实服务器 IP，提高安全性

Proxy Server（HTTP/SOCKS Proxy）：

• 对于无法直接访问公网的集群（如离线数据中心），会部署中间代理服务器
• 应用通过配置环境变量（如 http_proxy）访问公网
• Proxy Server 通常具备日志审计、带宽控制等功能

Egress Gateway（如 Istio 提供的）：

• 精细化管理 Service → 外部目标的访问
• 可设定访问白名单、强制 TLS、访问审计等

前公司有个做法是在 aws private subnet 上再做一层 protect subnet，不知道这个是不是好的做法。

8. 混合云场景中的网络连通

在混合云架构中，需要解决公有云 ↔ 私有云的互通问题。由于访问控制单位通常为“虚拟网络（VPC 或等价物）”，以下是常见连接方式：

VPN Gateway（推荐方式）：

• 在私有云中部署 VPN Server（如 StrongSwan/OpenVPN）
• 公有云中配置 VPN 客户端或对应的 VPN Gateway
• 实现通过专线或加密通道进行网络打通
• 可配合防火墙与路由表实现精细化控制

专线连接（如 AWS Direct Connect / GCP Cloud Interconnect）：

• 更适合对延迟和稳定性要求高的业务
• 成本高，部署复杂，适合生产级连接

Bastion Host + Proxy：

• 对小规模场景，也可使用跳板机代理特定 API 流量
• 简单部署，适合调试/管理型访问

通过上述出入口策略设计，企业可在保障内网安全的前提下，实现公网访问与混合云架构的稳定联通。

9. 公有云与私有云的异同对比