AKS 网络深入探究：Kubenet、Azure-CNI 和 Azure-CNI（overlay）

Kubernetes 网络使您能够配置 Kubernetes 网络内的通信。部署 AKS 集群时，有三种网络模型需要考虑：

• Kubenet 网络

KubeNet 是 AKS 中的基础网络插件。它可以被形象地比喻成大城市的地铁系统。地铁可能无法直接连接所有可能的地点（例如您的服务），但它能够到达主要区域。然后，对于更具体的连接，您需要乘坐公交车或出租车（类似于网络覆盖或路由）。

使用 KubeNet，每个 AKS 集群都会分配到自己的虚拟网络 (VNet)，每个节点（虚拟机）都会从该 VNet 获取一个 IP 地址。然后，Pod 会从单独的子网中分配 IP 地址，而该子网可能无法在您的 VNet 中路由。

KubeNet 的实际用例可能是需要简单易用的 AKS 设置，并且不需要 Pod 拥有单独网络标识的中小型组织。

• Azure 容器网络接口 (CNI) 网络

另一方面，Azure CNI 的运行方式类似于一个庞大的高速公路网络，每个容器 (Pod) 都有自己的 IP 地址，可以从外部网络访问。这就像城市中的每个家庭都有自己独特的地址，无需任何中间传输——您可以直接驾车前往目的地。

在 Azure CNI 中，每个节点和 Pod 都从 VNet 子网获取一个 IP 地址。这为每个 Pod 赋予了其自己的网络身份，这对于网络策略的创建和实施非常有益。

Azure CNI 的一个典型用例可能是具有复杂网络需求的大型企业。例如，运行多层应用程序的组织需要严格的网络隔离，并为每个服务设置单独的网络身份。

• ​​Azure 容器网络接口 (CNI) - Overlay 网络

传统的 Azure 容器网络接口 (CNI) 会为每个 Pod 分配一个 VNet IP 地址。它会从每个节点上预先预留的 IP 地址集合或为 Pod 预留的单独子网中分配此 IP 地址。这种方法需要规划 IP 地址，并且可能导致地址耗尽，从而随着应用程序需求的增长，扩展集群变得困难。

使用 Azure CNI Overlay，集群节点将部署到 Azure 虚拟网络 (VNet) 子网中。Pod 将从逻辑上与托管节点的 VNet 不同的私有 CIDR 中分配 IP 地址。集群内的 Pod 和节点流量使用 Overlay 网络。网络地址转换 (NAT) 使用节点的 IP 地址访问集群外部的资源。此解决方案节省了大量 VNet IP 地址，并使您能够将集群扩展至更大的规模。另一个优势是，您可以在不同的 AKS 集群中重用私有 CIDR，从而扩展 Azure Kubernetes 服务 (AKS) 中容器化应用程序可用的 IP 空间。

那么，我们应该为生产环境中的 AKS（Azure Kubernetes 服务）部署选择哪种网络选项呢？让我们来一探究竟。

默认情况下，AKS 集群使用 kubenet，并且 Azure 会为您创建虚拟网络和子网。

无论您使用哪种网络模型，都可以通过以下方式之一进行部署：

• 创建 AKS 集群时，Azure 平台可以自动创建和配置虚拟网络资源。虚拟网络和子网将在资源组中自动为您创建，并且该资源组也会由我们自己的订阅中的 Azure 资源提供程序自动创建。默认情况下，AKS 将节点资源组命名为 MC_resourcegroupname_clustername_location。
• 我们可以手动创建和配置虚拟网络资源，并在创建 AKS 集群时连接到这些资源。我们可以在创建 AKS 时配置 Vnet 和子网。
• 如果我们让 Azure 在创建集群时为集群创建网络资源，Azure 将在托管集群资源组中创建一个虚拟网络，该资源组包含与 AKS 托管集群关联的虚拟机和网络元素。

以下是 Azure 平台在未指定 Vnet 的情况下创建的默认网络资源的详细信息。

• 此虚拟网络的网络范围为 10.224.0.0/12
• 然后，在该 Vnet 中，我们将为节点创建子网，其范围为 10.224.0.0/16

Azure 创建的默认 Vnet 和子网

在详细讨论网络模型之前，让我们先了解一些有关 AKS 网络基础知识的知识。

AKS 网络基础知识

节点池 CIDR

系统节点和用户节点所在的网络。在 Azure Kubernetes 服务 (AKS) 中，相同配置的节点会被分组到节点池中。这些节点池中的节点从 VNET 的子网获取 IP 地址。所有节点池必须位于同一虚拟网络中。

对于默认 VNET，所有模型的节点池 CIDR 均为 10.224.0.0/16。

对于 Kubenet 模型，如果我们使用 Azure 自动创建的默认 VNET 和子网，节点将从系统资源组（“MC_*”组）中的 Azure 虚拟网络子网获取 IP 地址。但如果我们使用自己的 VNET 和子网，则集群节点的 IP 地址将从虚拟网络中指定的子网分配。--vnet-subnet-id 子网将为集群节点提供 IP 地址。

az aks create \
-g $RG \
-n kubenet-cluster \
--network-plugin kubenet \
--vnet-subnet-id $KUBENET_SUBNET_ID \

在 Azure CNI 和 CNI-overlay 模型中，集群节点的 IP 地址是从虚拟网络内的指定子网分配的。添加节点池时，请使用 --vnet-subnet-id 引用节点子网。

az aks nodepool add — cluster-name $clusterName -g $resourceGroup -n newnodepool \
— max-pods 250 \
— node-count 2 \
— vnet-subnet-id $nodeSubnetId
- pod-subnet-id $podSubnetId

服务 CIDR

服务 CIDR 用于将 AKS 集群中的内部服务分配给 IP 地址。此虚拟网络上或连接到此虚拟网络的任何网络元素都不应使用此范围。但是，我们可以为多个 AKS 集群重复使用相同的服务 CIDR。请使用 --service-cidr 引用服务 CIDR 范围。

az aks create \
-g $RG \
-n kubenet-cluster \
--network-plugin kubenet \
--vnet-subnet-id $KUBENET_SUBNET_ID \
--pod-cidr "10.100.0.0/16" \
--service-cidr "10.200.0.0/16"

我们可以使用任何满足以下要求的私有地址范围：

• 不得位于集群的虚拟网络 IP 地址范围内
• 不得与集群虚拟网络对等的任何其他虚拟网络重叠
• 不得与任何本地 IP 重叠
• 不得位于 169.254.0.0/16、172.30.0.0/16、172.31.0.0/16 或 192.0.2.0/24 范围内

Pod CIDR

Pod CIDR 是 Pod 获取其 IP 地址的地址池，通常与节点地址池不同。

对于 kubenet，Pod 会从逻辑上与节点 Azure 虚拟网络子网不同的地址空间接收 IP 地址。Pod 之间无法直接通信。用户定义路由 (UDR) 和 IP 转发用于跨节点 Pod 之间的连接。

使用 Azure CNI，每个 Pod 都会在 IP 子网中接收 IP 地址，并且可以直接与其他 Pod 和服务通信。与 kubenet 不同，发往同一虚拟网络中端点的流量不会被 NAT 到节点的主 IP 地址。虚拟网络内部流量的源地址是 Pod IP。虚拟网络外部的流量仍然会被 NAT 到节点的主 IP 地址。

传统 CNI 的一个缺点是，随着 AKS 集群规模的扩大，Pod IP 地址会耗尽，导致需要在更大的子网中重建整个集群。

Azure CNI 中新增的动态 IP 分配功能解决了这个问题，它通过从独立于 AKS 集群所在子网的子网分配 Pod IP 地址。--pod-subnet-id 用于指定将动态分配给 Pod 的 IP 地址所在的子网。

az aks nodepool add --cluster-name $clusterName -g $resourceGroup -n newnodepool \
--max-pods 250 \
--node-count 2 \
--vnet-subnet-id \
--pod-subnet-id

网络模型

Kubenet

Kubenet 是一个非常基础、简单的网络插件，仅适用于 Linux 系统。它本身并不实现跨节点网络或网络策略等更高级的功能。

1. 节点从 Azure 虚拟网络子网接收 IP 地址。
2. Pod 从逻辑上与节点 Azure 虚拟网络子网不同的地址空间接收 IP 地址。
3. 然后配置网络地址转换 (NAT)，以便 Pod 可以访问 Azure 虚拟网络上的资源。
4. 流量的源 IP 地址将转换为节点的主 IP 地址。
5. 这种方法减少了您需要在网络空间中为 Pod 预留的 IP 地址数量。

Azure CNI

• Pod 和集群节点的 IP 地址将从虚拟网络中的指定子网分配。
• 每个节点都配置了一个主 IP 地址。默认情况下，Azure CNI 会预先配置 30 个额外的 IP 地址，这些地址将分配给在该节点上调度的 Pod。
• 我们的集群可以与您指定的 IP 地址范围一样大。
• 配置了 Azure CNI 网络的集群需要额外规划。虚拟网络及其子网的大小必须能够容纳您计划运行的 Pod 数量以及集群的节点数量。
• 对于与其他 Azure 服务（例如虚拟机）的互通，来自由 Azure CNI 支持的 AKS 的数据包的源地址是 Pod 的 IP 地址。因此，它增加了网络的透明度。
• 我们无需管理用户定义的 Pod 连接路由。

Azure CNI overlay

• 使用 Azure CNI 覆盖，集群节点将部署到 Azure 虚拟网络 (VNet) 子网中，而 Pod 将从逻辑上与托管节点的 VNet 不同的私有 CIDR 中分配 IP 地址。
• 在覆盖网络中，只有 Kubernetes 集群节点会从子网中分配 IP。
• 在 Azure 网络堆栈中，会为 Pod 的私有 CIDR 空间创建一个单独的路由域，从而创建一个覆盖网络，用于 Pod 之间的直接通信。
• 与集群外部端点（例如本地和对等 VNet）的通信，通过网络地址转换 (NAB) 使用节点 IP 进行。Azure CNI 将流量的源 IP（Pod 的覆盖 IP）转换为虚拟机的主 IP 地址，从而使 Azure 网络堆栈能够将流量路由到目标。
• 集群外部的端点无法直接连接到 Pod。您必须将 Pod 的应用程序发布为 Kubernetes 负载均衡器服务，才能使其在 VNet 上可访问。
• 该解决方案节省了大量的 VNet IP 地址，并使您能够无缝地将集群扩展到非常大的规模。 

 Kubenet 的优势与局限性在于：

• 减少了在网络空间中为 Pod 预留的 IP 地址数量。
• 在设计、管理等方面比 Azure CNI 更简单。
• kubenet 的设计需要额外的跃点，这会略微增加 Pod 通信的延迟。
• 使用 kubenet 需要路由表和用户自定义路由，这会增加操作的复杂性。
• 不支持 Azure 网络策略

在以下情况下使用 kubenet：

• 您的 IP 地址空间有限。
• 大多数 Pod 通信都在集群内部进行。
• 您不需要高级 AKS 功能，例如虚拟节点或 Azure 网络策略。

Azure CNI 的优势与局限性在于：

• 它允许资源的控制和管理分离。
• Pod 获得完整的虚拟网络连接，并且可以通过其私有 IP 地址从连接的网络直接访问。
• 需要更多 IP 地址空间。
• 不同的团队可以管理和保护资源，这有利于安全。来自 Pod 的流量不经过 NAT，与其他资源建立通信的 Pod 可以被识别。使用 Kubenet，数据包的来源始终是节点 IP 地址。
• 此模型需要更多规划，并且通常会导致 IP 地址耗尽，或者随着应用程序需求的增长，需要在更大的子网中重建集群。
• 虚拟节点 (vKubelet) 仅适用于 Azure CNI
• Windows 节点仅适用于 Azure CNI

在以下情况下使用 Azure CNI：

• 您拥有可用的 IP 地址空间。
• 集群外部的资源需要直接访问 Pod。
• 大多数 Pod 通信都是与集群外部的资源进行的。
• 您不想管理用户定义的 Pod 连接路由。
• 您需要 AKS 高级功能，例如虚拟节点或 Azure 网络策略。

Azure CNI Overlay 的优势和局限性在于：

• 此解决方案可节省大量 VNet IP 地址，并使您能够无缝地将集群扩展到非常大的规模。
• 另一个优势是，Pod 私有 CIDR 可以在不同的 AKS 集群中重复使用，从而真正扩展了 AKS 中容器化应用程序可用的 IP 空间。
• 支持 Azure 网络策略。
• 不支持 AKS 高级功能，例如虚拟节点。
• Overlay 只能在新集群中启用。现有（已部署）集群无法配置为使用 Overlay。

在以下情况下使用overlay：

• 您希望扩展到大量 Pod，但 VNet 中的 IP 地址空间有限。
• 大多数 Pod 通信都在集群内部进行。
• 您不需要高级 AKS 功能，例如虚拟节点