Alauda Container Platform
  • 简体中文

    • 概览

    目录

    了解网络服务发现与负载均衡流量管理与路由网络安全可观测性核心网络层和组件GatewayAPIGateway API 用于 IngressGateway API 概念Service、Ingress 和 Gateway API 的比较对于 L4（TCP/UDP）流量LoadBalancer Service（推荐）Gateway API TCP/UDP Route建议对于 L7（HTTP/HTTPS）流量IngressGateway API（推荐）网络流量流向商标声明

    了解网络

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

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

    服务发现与负载均衡

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

    实现：

    • 服务发现

      • 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 等离线分析工具使用

    • 典型使用场景

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

    详细了解网络可观测性。

    核心网络层和组件

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

    • 用于管理集群内东西向流量的容器网络接口（CNI）。
    • 用于管理 HTTPS Ingress 流量的 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 提供高级路由功能。

    Gateway API 用于 Ingress

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

    每个 Gateway 都与一个 GatewayClass 相关联，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 结构中的适当位置能够进行细粒度定制。

    其他值得关注的功能包括：

    • GatewayClass - GatewayClass 规范化了负载均衡实现的类型。这些类让用户能够通过 Kubernetes 资源模型轻松、明确地了解可用的功能类型。
    • 共享 Gateway 和跨 Namespace 支持 - 通过允许独立的 Route 资源附加到同一个 Gateway，这些功能支持共享负载均衡器和虚拟 IP。这使团队（即使跨 Namespace）也能够安全地共享基础设施，而无需直接协调。
    • 类型化 Route 和类型化后端 - Gateway API 支持类型化的 Route 资源以及不同类型的后端。这使 API 能够灵活支持各种协议（如 HTTP 和 gRPC）以及各种后端目标（如 Kubernetes Service、存储桶或函数）。

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

    Service、Ingress 和 Gateway API 的比较

    支持 Kubernetes 生态系统中的多种 Ingress 流量规范。 请比较 Service、Ingress 和 Gateway API，以选择符合您的工作负载和运维要求的流量入口模式。

    对于 L4（TCP/UDP）流量

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

    LoadBalancer Service（推荐）

    实现方式：内核空间转发

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

    优势：

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

    Gateway API TCP/UDP Route

    实现方式：用户空间代理

    • 由 Envoy Gateway（或其他网关控制器）实现
    • 流量必须在内核空间与用户空间之间往返传递
    • 应用层会产生额外的处理开销

    劣势：

    • 与内核空间解决方案相比，性能有所下降
    • 更高的资源消耗（CPU/内存）
    • 用户空间上下文切换会带来额外延迟

    建议

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

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

    对于 L7（HTTP/HTTPS）流量

    Ingress 和 Gateway API 都可以将 L7 流量暴露到外部，但二者的功能有所不同。

    Ingress

    Ingress 是 Kubernetes Community 采用的标准规范，推荐默认使用。 Ingress 由平台管理员管理的 ALB 实例处理。

    Gateway API（推荐）

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

    1. 面向角色的设计

      • 关注点明确分离：基础设施管理员（GatewayClass、Gateway）与 Application developer（Routes）
      • Ingress 将基础设施和应用关注点混合在单个资源中

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

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

    3. 协议支持

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

    4. 可扩展性

      • 通过 CRD 提供类型安全的扩展点（例如 HTTPRoute 过滤器、策略附加）
      • Ingress 严重依赖供应商特定的注解，从而导致可移植性问题

    5. 跨 Namespace 路由

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

    6. 每个 Gateway 支持多个 Listener

      • 单个 Gateway 可以处理多个端口、协议和主机名
      • Ingress 通常要求每种配置使用一个资源

    7. 可移植性和标准化

      • 与供应商无关的 API，并提供一致性测试
      • 减少供应商锁定，并提高不同实现之间的互操作性
      • Ingress 实现的功能和注解存在较大差异

    8. 附加和选择模型

      • Route 通过 parentRefs 显式附加到 Gateway Listener
      • 关系更加清晰，也更易于排查问题
      • Ingress 使用灵活性较低的 IngressClass

    目前，我们通过 Envoy Gateway 支持 Gateway API。有关从 Ingress 迁移到 Gateway API 的信息，请参阅迁移指南

    网络流量流向

    通过 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 请求。 客户端在第 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 终止

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

      • 策略和身份验证

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

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

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

    6. Pod（原生应用）

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

    商标声明

    Envoy® 是 The Linux Foundation 的注册商标。

    NGINX® 是 F5, Inc. 在美国及其他国家/地区的注册商标。

    MetalLB™ 是 The Linux Foundation 的商标。

    CoreDNS™ 是 The Linux Foundation 的商标。

    Alauda 是一家独立供应商。本产品与 The Linux Foundation 或 F5, Inc. 不存在关联，也未获其认可或赞助。所有商标均归其各自所有者所有，此处仅用于标识目的。