共用方式為

AKS 的網路拓撲和連線考慮

  • 發行項

設計考量

Azure Kubernetes Service （AKS） 為容器網路提供三種不同的網路模型：Kubenet、CNI 重疊和 CNI。 這些模型都有其獨特的一組功能和優點，為AKS中的容器網路提供彈性和延展性選項。

Kubenet

Kubenet 是基本的網路解決方案，可節省IP位址空間並提供簡單的設定。 它非常適合具有少於 400 個節點的小型 AKS 叢集，可接受手動管理和維護使用者定義的路由。 它適用於內部或外部負載平衡器足以從叢集外部連線 Pod 的案例。

Azure CNI

Azure CNI 是專為進階網路而設計的網路模型。 它提供Pod的完整虛擬網路連線能力，允許Pod對Pod和Pod和Pod對VM連線。 非常適合需要進階 AKS 功能，例如虛擬節點的案例。 它適用於有足夠的IP位址空間可供使用，且外部資源需要直接連線到Pod的案例。 Azure CNI 也支援 AKS 網路原則。

Azure CNI 重疊

Azure CNI 重疊旨在解決IP位址短缺問題，並簡化網路設定。 它適用於每個節點最多調整 1000 個節點和 250 個 Pod 的案例，而且可接受 Pod 連線的額外躍點。 AKS 輸出需求也可以符合 Azure CNI 重疊。

如需每個網路模型建議使用案例的摘要，請參閱 比較AKS中的網路模型。

此外，設計 AKS 叢集時，請務必仔細規劃虛擬網路子網的 IP 位址和大小，以支援調整。 虛擬節點可用於快速調整叢集，但有一些已知的限制。

AKS 叢集支援基本和標準 Azure Load Balancer SKU，而且服務可以公開公用或內部負載平衡器。 AKS 使用 CoreDNS 為叢集中執行的 Pod 提供名稱解析，而輸出（輸出）網路流量可以透過 Azure 防火牆 或網路虛擬設備叢集傳送。

根據預設，AKS 叢集中的所有 Pod 都可以無限制地傳送及接收流量。 不過，Kubernetes 網路原則可用來改善安全性，並篩選 AKS 叢集中 Pod 之間的網路流量。 AKS 提供兩種網路原則模型：Azure 網路原則和 Calico。

最後，AKS 會在部署叢集的子網上設定網路安全組 （NSG）。 不建議手動編輯此 NSG，但部署在 AKS 中的服務可能會影響它。

整體而言，選取適當的網路模型並仔細規劃網路資源，有助於優化 AKS 叢集的效能、安全性和成本。

私人叢集

AKS 叢集IP可見性可以是公用或私人。 私人叢集會 透過私人IP位址公開 Kubernetes API，但不會透過公用IP位址公開。 此私人IP位址會透過 私人端點在AKS虛擬網路中表示。 Kubernetes API 不應該透過其IP位址存取，而是透過其完整功能變數名稱 （FQDN） 來存取。 從 Kubernetes API FQDN 到其 IP 位址的解析通常會由 Azure 私用 DNS 區域執行。 此 DNS 區域可由 Azure 在 AKS 節點資源群組中建立，或者您可以指定 現有的 DNS 區域。

遵循企業級實證做法，Azure 工作負載的 DNS 解析是由部署在聯機訂用帳戶中、中樞虛擬網路或連線至 Azure 虛擬 WAN 的共用服務虛擬網路中部署的集中式 DNS 伺服器所提供。 這些伺服器會使用 Azure DNS（IP 位址 168.63.129.16）和使用公司 DNS 伺服器的私人名稱，有條件地解析 Azure 特定和公用名稱。 不過，這些集中式 DNS 伺服器將無法解析 AKS API FQDN，直到它們與針對 AKS 叢集建立的 DNS 私人區域連線為止。 每個 AKS 都有唯一的 DNS 私人區域，因為隨機 GUID 會加上區域名稱。 因此，針對每個新的 AKS 叢集，其對應的私人 DNS 區域應該連線到中央 DNS 伺服器所在的虛擬網路。

所有虛擬網路都應該設定為使用這些中央 DNS 伺服器進行名稱解析。 不過，如果 AKS 虛擬網路設定為使用中央 DNS 伺服器，而且這些 DNS 伺服器尚未連線到私人 DNS 區域，則 AKS 節點將無法解析 Kubernetes API 的 FQDN，而建立 AKS 叢集將會失敗。 AKS 虛擬網路應該設定為只在叢集建立之後使用中央 DNS 伺服器。

建立叢集之後，會在 DNS 私人區域與部署中央 DNS 伺服器的虛擬網路之間建立連線。 AKS 虛擬網路也已設定為使用連線訂用帳戶中的中央 DNS 伺服器，而 AKS Kubernetes API 的系統管理員存取權將會遵循此流程：

此圖顯示私人叢集的網路。

注意

本文中的影像會反映使用傳統中樞和輪輻聯機模型的設計。 企業級登陸區域可以選擇虛擬 WAN 連線模型，其中中央 DNS 伺服器會位於連線至虛擬 WAN 中樞的共用服務虛擬網路中。

  1. 系統管理員會解析 Kubernetes API 的 FQDN。 內部部署 DNS 伺服器會將要求轉送至授權伺服器：Azure 中的 DNS 解析程式。 這些伺服器會將要求轉送至 Azure DNS 伺服器 （168.63.129.16），這會從 Azure 私用 DNS 區域取得 IP 位址。
  2. 解析IP位址之後，Kubernetes API 的流量會根據連線模型，從內部部署路由傳送至 Azure 中的 VPN 或 ExpressRoute 閘道。
  3. 私人端點會在中樞虛擬網路中引進 /32 路由。 VPN 和 ExpressRoute 閘道會將流量直接傳送至部署在 AKS 虛擬網路中的 Kubernetes API 私人端點。

從應用程式使用者到叢集的流量

傳入（輸入）控制器可用來公開在 AKS 叢集中執行的應用程式。

  • 輸入控制器會以稍微複雜度增加的成本提供應用層級路由。
  • 輸入控制器可以納入 Web 應用程式防火牆 （WAF） 功能。
  • 輸入控制器可以執行叢集和叢集中：
    • 非叢集輸入控制器會將計算（例如 HTTP 流量路由或 TLS 終止）卸載至 AKS 外部的另一個服務，例如 Azure 應用程式閘道 輸入控制器 （AGIC） 附加元件。
    • 叢集內解決方案會取用 AKS 叢集資源進行計算（例如 HTTP 流量路由或 TLS 終止）。 叢集內輸入控制器可以提供較低的成本，但需要仔細的資源規劃和維護。
  • 基本的 HTTP 應用程式路由附加元件很容易使用，但有一些限制，如 HTTP 應用程式路由中所述。

輸入控制器可以使用公用或私人IP位址來公開應用程式和API。

  • 組態應與輸出篩選設計一致，以避免非對稱路由。 UDR 可能會導致非對稱式路由（可能），但不一定。 應用程式閘道 流量上可以 SNAT，這表示如果 UDR 只針對因特網流量設定 UDR，則傳回流量會回到 應用程式閘道 節點，而不是 UDR 路由。
  • 如果需要 TLS 終止，則必須考慮 TLS 憑證的管理。

應用程式流量可能來自內部部署或公用因特網。 下圖說明 Azure 應用程式閘道 設定為從內部部署和公用因特網反向 Proxy 連線叢集的範例。

顯示應用程式相關網路流量的圖表。

來自內部部署的流量會遵循上圖中編號藍色圖說文字的流程。

  1. 用戶端會使用部署在連線訂用帳戶或內部部署 DNS 伺服器中的 DNS 伺服器，解析指派給應用程式的 FQDN。
  2. 將應用程式 FQDN 解析為 IP 位址（應用程式閘道的私人 IP 位址）之後，流量會透過 VPN 或 ExpressRoute 閘道路由傳送。
  3. 閘道子網中的路由設定為將要求傳送至 Web 應用程式防火牆。
  4. Web 應用程式防火牆會將有效的要求傳送至 AKS 叢集中執行的工作負載。

此範例中的 Azure 應用程式閘道 可以部署在與 AKS 叢集相同的訂用帳戶中，因為其設定與 AKS 中部署的工作負載密切相關，因此是由相同的應用程式小組所管理。 從因特網存取遵循上圖中編號綠色圖說文字的流程。

  1. 來自公用因特網的用戶端會使用 Azure 流量管理員 解析應用程式的 DNS 名稱。 或者，也可以使用 Azure Front Door 等其他全域負載平衡技術。
  2. 應用程式公用 FQDN 將會由 流量管理員 解析為應用程式閘道的公用 IP 位址，用戶端會透過公用因特網存取。
  3. 應用程式閘道會存取 AKS 中部署的工作負載。

注意

這些流程僅適用於 Web 應用程式。 非 Web 應用程式不在本文的範圍之外，而且可以使用虛擬 WAN 連線模型，透過中樞虛擬網路中的 Azure 防火牆 或安全的虛擬中樞來公開。

或者，可以針對 Web 應用程式進行流量流程，以周遊連線訂用帳戶中的 Azure 防火牆，以及 AKS 虛擬網路中的 WAF。 這種方法的優點是提供更多保護，例如使用 Azure 防火牆 情報型篩選來卸除來自因特網中已知惡意IP位址的流量。 不過，也有一些缺點。 例如，遺失原始用戶端IP位址，以及在公開應用程式時防火牆與應用程式小組之間所需的額外協調。 這是因為 Azure 防火牆 中將需要目的地網路位址轉換 （DNAT） 規則。

從 AKS Pod 到後端服務的流量

在 AKS 叢集內執行的 Pod 可能需要存取後端服務，例如 Azure 儲存體、Azure SQL 資料庫或 Azure Cosmos DB NoSQL 資料庫。 虛擬網路服務端點 和 Private Link 可用來保護這些 Azure 受控服務的連線。

如果您使用 Azure 私人端點進行後端流量，可以使用 Azure 私用 DNS 區域來執行 Azure 服務的 DNS 解析。 由於整個環境的 DNS 解析程式位於中樞虛擬網路中（或使用虛擬 WAN 連線模型時共用服務虛擬網路），因此應該在連線訂用帳戶中建立這些私人區域。 若要建立解析私人服務 FQDN 所需的 A 記錄，您可以將私人 DNS 區域（在連線訂用帳戶中）與私人端點（在應用程式訂用帳戶中）產生關聯。 此作業需要這些訂用帳戶中的特定許可權。

您可以手動建立 A 記錄，但建立私人 DNS 區域與私人端點的關聯，會導致設定較不容易設定錯誤。

從 AKS Pod 到透過私人端點公開的 Azure PaaS 服務的後端聯機會遵循下列順序：

後端流量

  1. AKS Pod 會使用連線訂用帳戶中的中央 DNS 伺服器，解析 Azure 平臺即服務 （PaaS） 的 FQDN，這些伺服器定義為 AKS 虛擬網路中的自定義 DNS 伺服器。
  2. 解析的IP是私人端點的私人IP位址，可直接從AKS Pod存取。

AKS Pod 與每個預設私人端點之間的流量不會通過中樞虛擬網路中的 Azure 防火牆（如果使用虛擬 WAN 則為安全虛擬中樞），即使 AKS 叢集已設定為使用 Azure 防火牆 進行輸出篩選也一樣。 原因是私人端點會在部署 AKS 的應用程式虛擬網路子網中建立 /32 路由。

設計建議

  • 如果您的安全策略授權具有具有私人IP位址的 Kubernetes API（而不是公用IP位址）， 請部署私人 AKS 叢集。
    • 在建立私人叢集時使用自定義私人 DNS 區域，而不是讓建立程式使用 系統私人 DNS 區域。
  • 除非您有有限的IP位址範圍可指派給AKS叢集，否則請使用 Azure Container Networking Interface （CNI） 作為網路模型。
  • 除非您在集中式訂用帳戶中使用 Azure 防火牆 或 WAF，否則請使用 Azure DDoS 保護來保護 AKS 叢集所使用的虛擬網路。
  • 使用連結至整體網路設定的 DNS 組態，搭配 Azure 虛擬 WAN 或中樞和輪輻架構、Azure DNS 區域，以及您自己的 DNS 基礎結構。
  • 使用 Private Link 來保護網路連線，並使用私人 IP 型連線到支援 Private Link 的其他受控 Azure 服務，例如 Azure 儲存體、Azure Container Registry、Azure SQL 資料庫 和 Azure 金鑰保存庫。
  • 使用輸入控制器來提供進階 HTTP 路由和安全性，並為應用程式提供單一端點。
  • 設定為使用輸入的所有 Web 應用程式都應該使用 TLS 加密，不允許透過未加密的 HTTP 進行存取。 如果訂用帳戶包含企業規模登陸區域的參考實作的原則中包含建議的原則，則會強制執行此原則。
  • 或者，若要節省 AKS 叢集的計算和儲存資源，請使用非叢集輸入控制器。
    • 使用 Azure 應用程式閘道 輸入控制器 （AGIC） 附加元件，這是第一方受控 Azure 服務。
    • 使用 AGIC，為每個 AKS 叢集部署專用 Azure 應用程式閘道，且不會跨多個 AKS 叢集共用相同的 應用程式閘道。
    • 如果沒有資源或操作條件約束，或 AGIC 未提供必要功能，請使用 NGINX、Traefik 或任何其他 Kubernetes 支援的解決方案等叢集內輸入控制器解決方案。
  • 針對因特網面向和安全性關鍵且面向內部的 Web 應用程式，請使用具有輸入控制器的 Web 應用程式防火牆。
  • 如果您的安全策略授權檢查 AKS 叢集中產生的所有輸出因特網流量，請使用 Azure 防火牆 或部署在受控中樞虛擬網路中的第三方網路虛擬設備 （NVA） 來保護輸出網路流量。 如需詳細資訊，請參閱 限制輸出流量。 AKS 輸出類型 UDR 需要將路由表與 AKS 節點子網產生關聯，因此目前無法與 Azure 虛擬 WAN 或 Azure 路由伺服器支援的動態路由插入搭配使用。
  • 針對非私人叢集，請使用授權的IP範圍。
  • 使用標準層，而不是 Azure Load Balancer 的基本層。
  • 在 Azure 中設計 Kubernetes 叢集時，其中一個重要考慮是針對您的特定需求選取適當的網路模型。 Azure Kubernetes Service （AKS） 提供三種不同的網路模型：Kubenet、Azure CNI 和 Azure CNI 重迭。 若要做出明智的決策，請務必瞭解每個模型的功能和特性。

如需 AKS 中三個網路模型之間的功能比較;Kubenet、Azure CNI 和 Azure CNI 重疊，請參閱 比較 AKS 中的網路模型。