#概览

#理解网络

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

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

#服务发现与负载均衡

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

实现方式：

• 服务发现

  • 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（应用）

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