Alauda Container Platform
  • 简体中文

    • 概览

    目录

    理解网络服务发现与负载均衡流量管理与路由网络安全核心网络层和组件GatewayAPI用于 Ingress 的 Gateway APIGateway API 概念Service、Ingress、Gateway API 之间的比较针对 L4 (TCP/UDP) 流量LoadBalancer Service（推荐）Gateway API TCP/UDP 路由建议针对 L7 (HTTP/HTTPS) 流量IngressGatewayAPI（推荐）网络流量流程

    理解网络

    在云原生环境中，网络的核心作用是充当中枢神经系统和循环系统。它是实现弹性、韧性和可观测性等关键应用特性的基础保障。

    云原生网络的职责可以分为几个关键领域：

    服务发现与负载均衡

    职责：自动发现正在运行的微服务实例，并智能地分配流量。

    实现方式：

    • 服务发现

      • Pod 向中央注册表（如 etcd）注册
      • 服务查询注册表以查找可用实例
      • Kubernetes 的 CoreDNS 通过服务名称提供内置发现功能

    • 负载均衡

      • Kubernetes Service 资源获得虚拟 IP（VIP）
      • 作为后端 Pod（Endpoints）的内置负载均衡器
      • 均匀分配请求到各实例

    流量管理与路由

    职责：通过细粒度规则控制流量，实现高级部署模式。

    实现方式：

    • Ingress

      • 集群对外 HTTP/HTTPS 流量的“入口”
      • 基于主机名和路径的路由
      • SSL 终止

    • 服务网格（Istio、Linkerd）

      • 金丝雀发布：将一定比例流量导向新版本
      • 故障注入：模拟服务故障以测试韧性
      • 超时、重试与断路器：提升容错能力
      • 流量镜像：复制生产流量到测试环境

    网络安全

    职责：执行“零信任”安全模型，确保服务间通信授权。

    实现方式：

    • 网络策略

      • 类似防火墙的 Pod 通信规则
      • 定义哪些 Pod 可以相互通信
      • 例如：“只有前端 Pod 可以访问后端数据库 Pod”

    • 双向 TLS (mTLS)

      • 加密并认证所有服务间通信
      • 确保数据安全和身份验证
      • 服务网格中广泛使用

    核心网络层和组件

    容器网络是为云原生应用设计的综合网络解决方案，确保集群内东西向通信的无缝连接和跨外部网络的南北向高效流量管理，同时提供必要的网络功能。其核心组件包括：

    • 用于集群内东西向流量管理的容器网络接口（CNI）。
    • 管理 HTTPS 入口流量的 Ingress Gateway 控制器 ALB（已弃用）、NGINX Ingress 控制器或 Envoy Gateway（推荐）。
    • 处理 LoadBalancer 类型 Service 的 MetalLB。
    • 另外，提供强大的网络安全和加密功能，确保通信安全。

    GatewayAPI

    Gateway API 是一个官方 Kubernetes 项目，专注于 Kubernetes 中的 L4 和 L7 路由。该项目代表了 Kubernetes Ingress、负载均衡和服务网格 API 的下一代。从一开始，它就被设计为通用、表达力强且面向角色的。

    整体资源模型聚焦于 3 个不同的角色及其对应管理的资源：

    该 API 中大部分配置集中在路由层。这些特定协议的资源（如 HTTPRoute、GRPCRoute 等）为 Ingress 和 Mesh 提供了高级路由能力。

    用于 Ingress 的 Gateway API

    使用 Gateway API 管理入口流量时，Gateway 资源定义了一个访问点，流量可以跨多个上下文路由——例如，从集群外部到集群内部（南北向流量）。

    每个 Gateway 关联一个 GatewayClass，描述将处理该 Gateway 流量的实际网关控制器类型；然后，单独的路由资源（如 HTTPRoute）与 Gateway 资源关联。将这些不同关注点分离为独立资源是 Gateway API 面向角色特性的关键部分，同时也允许多种类型的网关控制器（由 GatewayClass 资源表示）。

    Gateway API 概念

    以下设计目标驱动了 Gateway API 的概念，展示了 Gateway 如何改进当前如 Ingress 的标准。

    • 面向角色 —— Gateway 由 API 资源组成，模拟使用和配置 Kubernetes 服务网络的组织角色。
    • 可移植 —— 这不是改进，而是应保持不变。正如 Ingress 是一个具有多种实现的通用规范，Gateway API 也被设计为由多种实现支持的可移植规范。
    • 表达力强 —— Gateway API 资源支持核心功能，如基于头部的匹配、流量权重分配等，这些功能在 Ingress 中只能通过自定义注解实现。
    • 可扩展 —— Gateway API 允许在 API 各层链接自定义资源，使得在 API 结构中适当位置实现细粒度定制成为可能。

    其他显著功能包括：

    • GatewayClasses —— GatewayClasses 规范了负载均衡实现的类型，使用户能够明确了解 Kubernetes 资源模型支持的能力。
    • 共享网关和跨命名空间支持 —— 允许独立的 Route 资源附加到同一 Gateway，实现负载均衡器和 VIP 的共享。这样团队（甚至跨命名空间）可以安全共享基础设施，无需直接协调。
    • 类型化路由和类型化后端 —— Gateway API 支持类型化的 Route 资源和多种后端类型，灵活支持多种协议（如 HTTP 和 gRPC）及多种后端目标（如 Kubernetes Service、存储桶或函数）。

    有关 Gateway API 的详细描述，请参阅 gateway-api 文档。

    Service、Ingress、Gateway API 之间的比较

    Alauda 容器平台支持 Kubernetes 生态中多种入口流量规范。 本文档对它们（Service、Ingress、Gateway API）进行比较，帮助用户做出正确选择。

    针对 L4 (TCP/UDP) 流量

    LoadBalancer 类型的 Service 和 Gateway API（TCP/UDP 路由）均可对外暴露第 4 层流量，但它们在实现方式和性能特性上存在显著差异。

    LoadBalancer Service（推荐）

    实现方式：内核空间转发

    • 流量转发由 Linux 内核（iptables/IPVS/eBPF）直接处理
    • 开销极小，性能接近原生

    优点：

    • 高性能，低延迟
    • 较低的 CPU 和内存开销
    • 技术成熟且经过实战验证

    Gateway API TCP/UDP 路由

    实现方式：用户空间代理

    • 由 Envoy Gateway（或其他网关控制器）实现
    • 流量需从内核空间切换到用户空间再返回
    • 应用层额外处理开销

    缺点：

    • 性能较内核空间方案下降
    • 资源消耗（CPU/内存）较高
    • 用户空间上下文切换带来额外延迟

    建议

    我们建议使用 LoadBalancer 类型的 Service 进行 L4 流量路由，因其性能更优且资源开销更低。

    目前，我们通过 MetalLB 支持 LoadBalancer 类型的服务。

    针对 L7 (HTTP/HTTPS) 流量

    Ingress、GatewayAPI 等均可对外暴露第 7 层流量，但它们的能力存在差异。

    Ingress

    Ingress 是 Kubernetes 社区采用的标准规范，推荐作为默认使用方案。 Ingress 由平台管理员管理的 ALB 实例处理。

    GatewayAPI（推荐）

    Gateway API 是 Kubernetes 下一代路由标准，旨在解决 Ingress 的局限，提供更强大、灵活且标准化的流量管理能力。与 Ingress 相比，Gateway API 具有以下优势：

    1. 面向角色设计

      • 关注点清晰分离：基础设施管理员（GatewayClass、Gateway）与应用开发人员（Routes）
      • Ingress 将基础设施和应用关注点混合在单一资源中

    2. 表达力强的路由能力

      • 丰富的匹配规则：HTTP 头部、查询参数、方法等
      • Ingress 仅限于主机和路径匹配
      • 内置支持流量拆分、镜像和高级策略

    3. 协议支持

      • 原生支持 HTTP、HTTPS、TCP、UDP、gRPC 和 TLS 透传
      • Ingress 主要关注 HTTP/HTTPS

    4. 可扩展性

      • 通过 CRD 实现类型安全的扩展点（如 HTTPRoute 过滤器、策略附件）
      • Ingress 依赖大量厂商特定注解，导致可移植性差

    5. 跨命名空间路由

      • 路由可引用不同命名空间的 Service（需 ReferenceGrant）
      • Ingress 通常限制于同命名空间引用

    6. 单个 Gateway 支持多个监听器

      • 一个 Gateway 可处理多个端口、协议和主机名
      • Ingress 通常每个配置需要一个资源

    7. 可移植性和标准化

      • 厂商中立的 API，配备一致性测试
      • 减少锁定，提升实现间互操作性
      • Ingress 实现能力和注解差异较大

    8. 附加与选择模型

      • 路由通过 parentRefs 明确附加到 Gateway 监听器
      • 关系更清晰，便于排查
      • Ingress 使用 IngressClass，灵活性较低

    目前，我们通过 Envoygateway 支持 GatewayApi。有关从 Ingress 迁移到 GatewayApi，请参阅 迁移指南。

    网络流量流程

    以下示例展示了流量通过 Alauda 容器平台集群的网络流程。

    External Client (Browser / curl) https://www.example.com
   │
   ▼
DNS Resolution (https://www.example.com) → IP (e.g. 34.23.88.11)
   │
   ▼
External Load Balancer [L4]
   │
   ▼
Envoy Gateway / Ingress NGINX Controller [L7]
   │
   ▼
Kubernetes Service (ClusterIP) [L4]
   │
   ▼
Pod (Application)

    流程说明：

    1. 客户端（浏览器 / curl）

      用户向 https://www.example.com 发送 HTTPS 请求。 客户端工作在第 7 层，发起 DNS 查询。

    2. DNS 解析

      DNS 将域名解析为公网 IP 地址（例如 34.23.88.11）。

    3. [L4] 外部负载均衡器

      工作在第 4 层（TCP/UDP）。 将入站连接转发到集群内的后端节点。 例如：AWS NLB、GCP TCP LB、MetalLB。

    4. [L7] Envoy Gateway / Ingress 控制器

      工作在第 7 层（应用层）。 负责：

      • TLS 终止

      • 基于主机名和路径的路由

      • 策略和认证

      将流量路由到匹配的 Kubernetes Service。

    5. [L4] Kubernetes Service（ClusterIP）

      作为集群内的第 4 层内部负载均衡器。 根据选择器将请求分发到后端 Pod。

    6. Pod（应用）

      应用运行的最终目的地，处理请求。 响应沿相反路径返回客户端。