本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。
使用 EC2 虚拟私有云实现高性能网络
运行 Kubernetes 最受欢迎的平台之一是亚马逊网络服务弹性计算云（AWS EC2）。凭借十多年的 IaaS 交付经验，并随着时间的推移扩展到包含一套丰富的易于使用的 API 服务，EC2 赢得了全球开发者的关注和忠诚度。
然而，在网络方面，EC2 存在一些限制，这些限制会阻碍性能，并使将 Kubernetes 集群部署到生产环境变得不必要地复杂。Romana v2.0 的预览版，一个用于云原生应用程序的网络和安全自动化解决方案，包含了解决在 EC2 中运行 Kubernetes 时一些众所周知的网络问题的功能。
传统 VPC 网络性能瓶颈
Kubernetes pod 网络独立于 Amazon 虚拟私有云（VPC）实例网络；因此，离实例 pod 流量需要一条通往目标 pod 的路由。幸运的是，VPC 支持设置这些路由。当使用 kubenet 插件构建集群网络时，每当添加新节点时，AWS 云提供商都会自动向在该节点上运行的 pod 添加 VPC 路由。
使用 kubenet 设置路由提供了原生 VPC 网络性能和可见性。然而，由于 kubenet 不支持更高级的网络功能，如用于 pod 流量隔离的网络策略，许多用户选择在后端运行容器网络接口（CNI）提供商。
在 Romana v2.0 之前，所有 CNI 网络提供商在跨可用区（AZ）使用时都需要一个覆盖网络，这使得希望部署高可用集群的 CNI 用户无法获得原生 VPC 网络的性能。
即使不需要高级网络的用户也会遇到限制，因为 VPC 路由表最多支持 50 个条目，这将集群大小限制为 50 个节点（如果某些 VPC 路由用于其他目的，则更少）。在 Romana v2.0 之前，用户还需要运行一个覆盖网络来绕过此限制。
无论您是对流量隔离的高级网络感兴趣，还是运行大型生产高可用集群（或两者兼而有之），您都无法获得原生 VPC 网络的性能和可见性。
多段网络上的 Kubernetes
避免 VPC 路由耗尽的方法是少量使用它们，让它们转发多个实例的 pod 流量。从网络角度来看，这意味着 VPC 路由需要转发到一个路由器，然后路由器可以将流量转发到最终的目标实例。
Romana 是一种 CNI 网络提供商，它在主机上配置路由以转发 pod 网络流量，无需覆盖网络。由于节点间路由安装在主机上，因此根本不需要 VPC 路由。然而，当 VPC 分割成子网以实现跨区域的高可用部署时，VPC 路由是必需的。
幸运的是，主机上的节点间路由允许它们充当网络路由器，并像处理来自本地 pod 的流量一样转发来自另一个区域的入站流量。这使得任何由 Romana 配置的 Kubernetes 节点都能够接受来自其他区域的入站 pod 流量，并将其转发到子网上的正确目标节点。
由于这种本地路由功能，可以聚合到子网上其他实例上 pod 的顶级路由，从而将所需的路由总数减少到每个子网仅一个。为了避免使用单个实例转发所有流量，可以使用更多路由将流量分散到多个实例，直到达到可用路由的最大数量（即与 kubenet 等效）。
最终结果是，您现在可以构建任何大小的跨可用区集群，而无需覆盖网络。Romana 集群还支持网络策略，通过网络隔离提高安全性。
使其全部工作
虽然子网上的聚合路由和节点转发的组合消除了覆盖网络并避免了 VPC 50 条路由限制，但它对 CNI 提供商施加了某些要求。例如，主机应该只配置到本地子网上同一区域中其他节点的节点间路由。到所有其他主机的流量必须使用主机上的默认路由，然后使用（聚合的）VPC 路由将流量转发到区域外。此外：在添加新主机时，为了保持聚合的 VPC 路由，CNI 插件需要使用在新主机上可访问的 pod 的 IP 地址。
Romana 的最新版本还解决了关于 VPC 路由如何安装的问题；转发流量的节点发生故障时会发生什么；如何检测转发节点故障；以及路由如何更新和集群如何恢复。
Romana v2.0 包含一个新的 AWS 路由配置功能来设置 VPC 路由。这是一组新的网络广播功能的一部分，这些功能可以自动化 L3 网络中的路由配置。Romana v2.0 包括拓扑感知的 IP 地址管理 (IPAM)，它能够实现 VPC 路由聚合以保持在本文所述的 50 条路由限制内，以及新的健康检查，用于在路由实例发生故障时更新 VPC 路由。对于较小的集群，Romana 像 kubenet 一样配置 VPC 路由，为每个实例设置一条路由，充分利用每个可用的 VPC 路由。
无处不在的原生 VPC 网络
使用 Romana v2.0 时，原生 VPC 网络现在可用于任何大小的集群，无论是否带网络策略，以及用于跨多个区域部署的高可用生产环境。
