Kubernetes 网络选项 ¶
介绍 ¶
Kubernetes 具有一个网络模型，其中 Pod 和服务有自己的 IP 地址。由于 Pod 和服务在具有自己的 IP 地址和网络的服务器上运行，因此 Kubernetes 网络模型是一个与底层服务器和网络分离的抽象层。下面列出的许多选项可用于实现和管理此抽象层。
支持的网络选项 ¶
下表列出了不同网络提供商在 kOps 版本中的支持状态。
从 kOps 1.26 开始，默认网络提供商为 Cilium。在此之前，默认网络提供商为 Kubenet。
| 网络提供商 | 实验性 | 稳定 | 已弃用 | 已移除 |
|---|---|---|---|---|
| AWS VPC | 1.9 | 1.21 | - | - |
| Calico | 1.6 | 1.11 | - | - |
| Canal | 1.12 | - | 1.27 | Kubernetes 1.28 |
| Cilium | 1.9 | 1.15 | - | - |
| Cilium ENI | 1.18 | 1.26 | - | - |
| Flannel udp | 1.5.2 | - | 1.27 | Kubernetes 1.28 |
| Flannel vxlan | 1.8.0 | - | 1.27 | Kubernetes 1.28 |
| Kopeio | 1.5 | - | - | - |
| Kube-router | 1.6.2 | - | 1.27 | Kubernetes 1.28 |
| Kubenet | 1.5 | 1.5 | - | - |
| Lyft VPC | 1.11 | - | 1.22 | 1.23 |
| Romana | 1.8 | - | 1.18 | 1.19 |
| Weave | 1.5 | - | 1.23 | Kubernetes 1.23 |
为集群创建指定网络选项 ¶
您可以通过 --networking 命令行开关指定网络提供商。但是，这只会提供提供商的默认配置。通常，您会经常修改集群规范中的 spec.networking 部分来进一步配置提供商。
Kubenet ¶
"kubenet" 选项使控制平面能够为每个节点分配一个 /24 CIDR，这些 CIDR 来自节点网络。然后在云提供商网络的路由表中配置每个节点的路由。
在 AWS 上使用 kubenet 网络时，一个重要的限制是 AWS 路由表不能超过 50 个条目，这为每个集群的节点数量设置了 50 个节点的限制。AWS 支持有时会将限制提高到 100 个，但他们的文档指出超过 50 个路由表的路由表可能会降低性能。
由于 kubernetes 会修改 AWS 路由表，这意味着实际上 kubernetes 需要拥有路由表，因此它需要自己的子网。理论上，可以与其他基础设施（但不是第二个集群！）共享路由表，但这并不推荐。某些 cni 网络解决方案声称可以解决这些问题。
运行 --topology private 的用户将无法选择 kubenet 网络，因为 kubenet 需要一个路由表。这些高级用户通常在多个可用区中运行，并且由于 NAT 网关是单 AZ，因此需要多个路由表才能使用每个 NAT 网关。
Kubenet 很简单，但是，它不应用于预期随着时间的推移会逐渐增加流量和/或工作负载的生产集群。这些集群最终会“超出”kubenet 网络提供商的范围。
CNI ¶
容器网络接口 提供了规范和库，用于编写插件以配置 Linux 容器中的网络接口。Kubernetes 内置支持 CNI 网络组件。
目前，kOps 中内置了多个 CNI 提供商。
kOps 使集群运营商能够轻松地选择这些选项之一。提供商的清单包含在 kOps 中，您只需使用 --networking <provider-name>。在运行 kops cluster create 时，将提供商名称替换为提供商文档中列出的名称（来自上面的列表）。例如，对于默认的 Calico 安装，请执行以下操作。
kops create cluster --networking calico
稍后，当您运行 kops get cluster -oyaml 时，您将在 spec.networking 下看到您选择的选项配置。
高级 ¶
kOps 尽力在 kOps 集群规范中公开尽可能多的配置选项，以用于其支持的上游 CNI 选项。但是，由于上游 CNI 选项一直在不断变化，因此并非所有选项都可用，或者您可能希望使用 kOps 不支持的 CNI 选项。可能还存在 kOps 维护人员未考虑到的操作给定 CNI 的边缘情况。允许 kOps 管理 CNI 安装对于绝大多数生产集群来说已经足够了；但是，如果您的情况并非如此，那么 kOps 提供了一个逃生舱，让您可以更好地控制 CNI 安装。
在 kops create cluster 上使用标志 --networking cni 或 spec.networking: cni {} 时，kOps 根本不会安装任何 CNI，而是期望您安装它。
如果您尝试在此模式下创建新集群，则主节点将处于 not ready 状态。然后，您可以按照 vanilla kubernetes 安装说明 部署任何 CNI DaemonSet。一旦 CNI DaemonSet 部署完成，主节点应该进入 ready 状态，其余节点应该很快加入集群。
重要注意事项 ¶
对于某些 CNI 实现，kOps 不仅仅是使用相关的 CNI pod 启动一个 DaemonSet。例如，在安装 Calico 时，kOps 会为 Calico 安装客户端证书，以启用与 etcd 连接的 mTLS。如果您只是将 spec.networking 的 Calico 选项替换为 spec.networking: cni {}，就会导致停机。
如果您确实决定手动负责维护 CNI，则应熟悉安装 CNI 的 kOps 代码库部分（示例），以确保您正在复制 kOps 为您的 CNI 选项应用的任何其他操作。您应该密切关注上游 CNI 的版本和 kOps 的版本，以确保您可以应用上游 CNI 或 kOps 维护人员发布的任何更新或修复。
此外，您还应该牢记，kOps 维护人员会在各种支持的 CNI 选项上运行 e2e 测试，kOps 更新必须通过这些测试才能发布。如果您接管了集群 CNI 的维护工作，则应在更新之前在测试集群中测试潜在的 kOps、Kubernetes 和 CNI 更新。
验证 CNI 安装 ¶
您会注意到，kube-dns 和类似的依赖于 pod 网络的 pod 无法正常启动，直到您部署 CNI 提供商。
以下是一些确认 CNI 安装良好的步骤项目。
- CNS 提供商在没有错误的情况下启动。
kube-dnsdaemonset 启动。- 节点上的日志将显示有关 pod 创建和删除的消息。
K8s slack 上的 sig-networking 和 sig-cluster-lifecycle 频道始终是针对 Kubernetes 特定 CNI 挑战的良好起点。
在网络提供商之间切换 ¶
从 kubenet 提供商切换到 CNI 提供商被认为是安全的。只需更新配置并滚动集群即可。
也可以在 CNI 提供商之间切换，但这通常会导致重大更改。kOps 也不会清理先前 CNI 遗留的任何资源，包括 CNI 守护进程集。