本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
使用 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 網路現在可用於任何大小的叢集，無論是否帶網路策略，以及用於跨多個區域部署的高可用生產環境。
