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 流量的“入口网关”
      • 基于主机名/路径的路由
      • SSL 终止

    • Service Mesh（Istio、Linkerd）

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

    网络安全

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

    实现：

    • 网络策略

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

    • 双向 TLS（mTLS）

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

    可观测性

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

    实现：

    • 持续可见性

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

    • 按需故障排查

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

    • 典型用例

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

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

    核心网络层和组件

    容器网络是一套面向云原生应用的综合性网络解决方案，旨在确保集群内的东西向通信无缝进行，并高效管理跨外部网络的南北向流量，同时提供必要的网络功能。它由以下核心组件组成：

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

    GatewayAPI

    Gateway API 是 Kubernetes 的官方项目，专注于 Kubernetes 中的 L4 和 L7 路由。该项目代表了 Kubernetes Ingress、负载均衡和 Service Mesh 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 Service 网络的组织角色。
    • 可移植 - 这并不是一种改进，而是应当保持不变的特性。就像 Ingress 是一个具有众多实现的通用规范一样，Gateway API 也被设计为一个可移植的规范，并由多种实现支持。
    • 富表达力 - Gateway API 资源支持诸如基于请求头的匹配、流量加权以及其他功能；这些能力在 Ingress 中只能通过自定义注解实现。
    • 可扩展 - Gateway API 允许在 API 的不同层级关联自定义资源。这使得在 API 结构的合适位置进行细粒度定制成为可能。

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

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

    有关 Gateway API 的更详细说明，请参阅 gateway-api documentation。

    Service、Ingress、Gateway API 的比较

    支持 Kubernetes 生态中的多种入口流量规范。 比较 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）与应用开发人员（Routes）
      • Ingress 将基础设施和应用职责混杂在单一资源中

    2. 富表达力的路由能力

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

    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 可以处理多个端口、协议和主机名
      • Ingress 通常每种配置都需要一个资源

    7. 可移植性和标准化

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

    8. 附加与选择模型

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

    目前，我们通过 Envoygateway 支持 GatewayApi。关于从 ingress 迁移到 gatewayapi，请参阅 migration guide

    网络流量流向

    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. 客户端（浏览器 / curl）

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

    2. DNS 解析

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

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

      工作在 L4（TCP/UDP）。 它会将入站连接转发到集群中的后端节点。 示例：AWS NLB、GCP TCP LB、MetalLB。

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

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

      • TLS 终止

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

      • 策略和身份认证

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

    5. [L4] Kubernetes Service（虚拟 IP）

      作为集群内部的四层负载均衡器运行。 根据 selector 将请求分发到后端 Pod。

    6. Pod（原生应用）

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