标题: AKS 网络深入探究：Kubenet、Azure-CNI 和 Azure-CNI（overlay） [打印本页] 作者: 小秦哥 时间: 2025-5-8 03:27 标题: 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 范围。
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 系统。它本身并不实现跨节点网络或网络策略等更高级的功能。
节点从 Azure 假造网络子网汲取 IP 地址。
Pod 从逻辑上与节点 Azure 假造网络子网差别的地址空间汲取 IP 地址。
然后配置网络地址转换 (NAT)，以便 Pod 可以访问 Azure 假造网络上的资源。
流量的源 IP 地址将转换为节点的主 IP 地址。
这种方法减少了您需要在网络空间中为 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 空间。
