Alauda Container Platform
  • 简体中文

    • 概览

    目录

    理解网络服务发现与负载均衡流量管理与路由网络安全可观测性核心网络层与组件GatewayAPI适用于 Ingress 的 Gateway APIGateway API 概念Service、Ingress、Gateway API 对比L4（TCP/UDP）流量LoadBalancer Service（推荐）Gateway API TCP/UDP Routes建议L7（HTTP/HTTPS）流量IngressGatewayAPI（推荐）网络流量流转

    理解网络

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

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

    服务发现与负载均衡

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

    实现：

    • 服务发现

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

    • 负载均衡

      • Kubernetes Service 资源获得虚拟 IP（VIP）
      • 作为内置负载均衡器将流量转发到后端 Pod（Endpoints）
      • 在各实例之间均匀分配请求

    流量管理与路由

    职责：通过细粒度规则控制流量，以支持高级发布模式。

    实现：

    • Ingress

      • 集群对外部 HTTP/HTTPS 流量的“入口门”
      • 基于 host/path 的路由
      • SSL 终止

    • Service Mesh（Istio、Linkerd）

      • 金丝雀发布：将一部分流量导向新版本
      • 故障注入：模拟服务故障以进行韧性测试
      • 超时、重试与熔断：提高故障容忍能力
      • 流量镜像：将生产流量复制到测试环境

    网络安全

    职责：为经过授权的服务通信强制执行“零信任”安全模型。

    实现：

    • Network Policies

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

    • Mutual TLS（mTLS）

      • 对所有服务间通信进行加密和身份认证
      • 确保数据安全和身份验证
      • 广泛用于 service mesh

    可观测性

    职责：清晰展现网络行为，帮助运维人员了解流量模式，并快速诊断连通性或性能问题。

    实现：

    • 持续可见性

      • 使用 NetObserv 收集集群范围的网络流日志
      • 使用 Kubernetes 元数据丰富流记录
      • 存储和查询数据以支持故障排查和审计

    • 按需排障

      • 使用 CLI 捕获流或数据包，进行短期分析
      • 支持在 TUI 模式下实时检查，或在后台执行抓取任务
      • 将结果导出到 Wireshark 等离线分析工具

    • 典型用例

      • 识别连接丢失、延迟热点和异常流量路径
      • 验证服务间通信并检测异常
      • 结合汇总后的流数据和原始数据包分析事件

    了解更多关于网络可观测性。

    核心网络层与组件

    容器网络是为云原生应用设计的一套完整网络解决方案，旨在确保集群内东西向通信的顺畅以及跨外部网络的高效南北向流量管理，同时提供必要的网络功能。它由以下核心组件组成：

    • 用于管理集群内东西向流量的 Container Network Interfaces（CNIs）。
    • 用于管理 HTTPS ingress 流量的 Ingress Gateway Controller ALB（已弃用）、NGINX Ingress Controller 或 Envoy Gateway（推荐）。
    • 用于处理 LoadBalancer 类型 Service 的 MetalLB。
    • 此外，它还提供强大的网络安全和加密功能，以确保通信安全。

    GatewayAPI

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

    整体资源模型聚焦于 3 类不同角色及其各自需要管理的资源：

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

    适用于 Ingress 的 Gateway API

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

    每个 Gateway 都关联一个 GatewayClass，用于描述将为该 Gateway 处理流量的实际网关控制器类型；随后，单独的路由资源（例如 HTTPRoute）会与 Gateway 资源关联。将这些不同职责拆分为独立资源，是 Gateway API 体现角色导向特性的关键部分，同时也支持多种网关控制器（由 GatewayClass 资源表示）。

    Gateway API 概念

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

    • 以角色为导向 - Gateway 由一组 API 资源组成，这些资源建模了使用和配置 Kubernetes 服务网络的组织角色。
    • 可移植 - 这并不是一种改进，而是应该保持不变的特性。正如 Ingress 是一个拥有众多实现的通用规范一样，Gateway API 也被设计为一种可由多种实现支持的可移植规范。
    • 富表达力 - Gateway API 资源支持诸如基于 header 的匹配、流量权重以及其他能力，而这些能力在 Ingress 中只能通过自定义注解实现。
    • 可扩展 - Gateway API 允许在 API 的各个层级关联自定义资源。这使得可以在 API 结构中的适当位置进行细粒度定制。

    其他一些值得注意的能力包括：

    • GatewayClasses - GatewayClasses 将负载均衡实现类型标准化。这些 class 让用户更容易且更明确地理解 Kubernetes 资源模型中可用的能力类型。
    • 共享 Gateway 和跨 Namespace 支持 - 通过允许独立的 Route 资源附加到同一个 Gateway，它们支持共享负载均衡器和 VIP。这使团队（即使跨 Namespace）也能在无需直接协调的情况下安全共享基础设施。
    • 类型化 Routes 和类型化 backends - Gateway API 支持类型化 Route 资源以及不同类型的 backends。这使 API 能够灵活支持各种协议（如 HTTP 和 gRPC）以及各种后端目标（如 Kubernetes Services、存储桶或函数）。

    关于 Gateway API 的更详细说明，请参考gateway-api 文档。

    Service、Ingress、Gateway API 对比

    Alauda Container Platform 支持 Kubernetes 生态中的多种 ingress 流量规范。
    本文对它们（Service、Ingress、Gateway API）进行对比，帮助用户做出正确选择。

    L4（TCP/UDP）流量

    LoadBalancer 类型的 Service 和 Gateway API（TCP/UDP Routes）都可以将四层流量暴露到外部。不过，它们在实现方式和性能特征上有显著差异。

    LoadBalancer Service（推荐）

    实现：内核态转发

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

    优势：

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

    Gateway API TCP/UDP Routes

    实现：用户态代理

    • 由 Envoy Gateway（或其他网关控制器）实现
    • 流量必须从内核态经过用户态再返回内核态
    • 在应用层带来额外的处理开销

    劣势：

    • 与内核态方案相比性能会下降
    • 资源消耗更高（CPU/内存）
    • 由于用户态上下文切换带来额外延迟

    建议

    我们建议将 LoadBalancer 类型的 Service 用于 L4 流量路由，因为它具有更优的性能和更低的资源开销。

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

    L7（HTTP/HTTPS）流量

    虽然 Ingress、GatewayAPI 都可以将 L7 流量暴露到外部，但它们的能力有所不同。

    Ingress

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

    GatewayAPI（推荐）

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

    1. 以角色为导向的设计

      • 职责清晰分离：基础设施管理员（GatewayClass、Gateway） vs. 应用开发人员（Routes）
      • Ingress 将基础设施和应用职责混合在单个资源中

    2. 更富表达力的路由能力

      • 丰富的匹配规则：HTTP headers、查询参数、方法等
      • Ingress 仅支持 host 和 path 匹配
      • 内置支持流量拆分、镜像和高级策略

    3. 协议支持

      • 原生支持 HTTP、HTTPS、TCP、UDP、gRPC 和 TLS passthrough
      • Ingress 主要聚焦于 HTTP/HTTPS

    4. 可扩展性

      • 通过 CRD 提供类型安全的扩展点（例如 HTTPRoute filters、policy attachments）
      • Ingress 高度依赖厂商特定注解，容易导致可移植性问题

    5. 跨 Namespace 路由

      • Route 可以引用不同 namespace 中的 Service（通过 ReferenceGrant）
      • Ingress 通常仅限于同 namespace 引用

    6. 每个 Gateway 支持多个 Listener

      • 单个 Gateway 可以处理多个端口、协议和 hostname
      • Ingress 通常每种配置都需要一个资源

    7. 可移植性和标准化

      • 供应商中立的 API，并提供一致性测试
      • 减少厂商锁定，提升不同实现之间的互操作性
      • Ingress 的实现能力和注解差异很大

    8. 附加与选择模型

      • Route 通过 parentRefs 明确附加到 Gateway listeners
      • 关系更清晰，也更易于排障
      • Ingress 使用 IngressClass，灵活性较低

    目前，我们通过Envoygateway支持 GatewayApi。关于从 ingress 迁移到 gatewayapi，请参考迁移指南

    网络流量流转

    以下示例展示了在 Alauda Container Platform 集群中的网络流量流转过程。

    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. 客户端（Browser / 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 Controller。

      工作在第 7 层（应用层）。
      处理以下内容：

      • TLS 终止

      • 基于 hostname 和 path 的路由

      • 策略和认证

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

    5. [L4] Kubernetes Service（ClusterIP）

      在集群内部充当四层负载均衡器。
      根据 selector 将请求分发到后端 Pod。

    6. Pod（Application）

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