Alauda Container Platform
  • 简体中文

    • 概览

    目录

    理解网络服务发现与负载均衡流量管理与路由网络安全可观测性核心网络层与组件GatewayAPIGateway API 用于 IngressGateway API 概念Service、Ingress、Gateway API 之间的比较针对 L4 (TCP/UDP) 流量LoadBalancer Service（推荐）Gateway API TCP/UDP Routes建议针对 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)

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

    可观测性

    职责：提供丰富的网络数据，用于理解和诊断分布式系统。

    实现方式：

    • 指标

      • 流量速率、错误率、延迟数据
      • 与监控系统（如 Prometheus）集成

    • 日志

      • 所有请求的访问日志
      • 用于故障排查和审计

    • 追踪

      • 跟踪跨多个微服务的请求路径
      • 分析性能瓶颈和依赖关系
      • 服务网格支持分布式追踪

    了解更多请参见 Networking Observability。

    核心网络层与组件

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

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

    GatewayAPI

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

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

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

    Gateway API 用于 Ingress

    使用 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 各层链接自定义资源，实现适当位置的细粒度定制。

    其他显著功能包括：

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

    更多 Gateway API 详细说明，请参阅 gateway-api 文档。

    Service、Ingress、Gateway API 之间的比较

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

    针对 L4 (TCP/UDP) 流量

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

    LoadBalancer Service（推荐）

    实现方式：内核空间转发

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

    优点：

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

    Gateway API TCP/UDP Routes

    实现方式：用户空间代理

    • 由 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. 跨命名空间路由

      • 路由可引用不同命名空间的服务（需 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 请求至 https://www.example.com。 客户端工作在第 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（应用）

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