AKS 的網路拓撲和連線能力考量

設計考量

• AKS 支援兩種網路模型：kubenet 和 Azure 容器網路介面 (CNI)。
  • CNI 需要針對 IP 位址進行額外的規劃。
  • 只有 CNI 支援 Windows 伺服器節點和網路原則集區。
  • AKS 會自動設定 kubenet 的 UDR。
  • kubenet 最多僅支援 400 個節點。
  • 確認目前每個 CNI 外掛程式所支援的功能清單。
• IP 位址和虛擬網路子網路的大小必須經過謹慎規劃，才能支援對叢集的縮放調整。 例如，您可以新增更多節點。
• 虛擬節點可以用來進行快速叢集縮放調整，但有一些已知的限制。
• AKS 叢集支援基本和標準 Azure Load Balancer SKU。
• 您可以使用公用或內部負載平衡器來公開 AKS 服務。 內部負載平衡器可以設定在與 Kubernetes 節點相同的子網路內，或在專用子網路中。
• Azure 原則和 AKS 的 Azure 原則附加元件可以控制和限制在 AKS 叢集中建立的物件，例如拒絕使用公用負載平衡器建立服務。
• AKS 使用 CoreDNS 來為叢集中執行的 Pod 提供名稱解析。
  • CoreDNS 會直接解析叢集內部網域。
  • 其他網域將轉送至 Azure 虛擬網路中所設定的 DNS 伺服器，這會是預設的 Azure DNS 解析器，或是在虛擬網路層級中設定的任何自訂 DNS 伺服器。
• 輸出 (向外) 網路流量可透過 Azure 防火牆或網路虛擬裝置叢集傳送。
  • 根據預設，AKS 叢集具有不受限制的輸出網際網路存取。
  • 輸出連線有兩種部署模型：LoadBalancer或 UserDefinedRouting (UDR)。 使用 UDR 時，叢集中沒有針對輸出流量建立的公用 IP 位址。 在將 AKS 叢集部署至具有禁止建立公共 IP 位址原則的 Corp 訂閱時，這點尤其重要。 如需詳細資訊，請參閱企業規模登陸區域的參考實作中所包含的原則。
  • 從 AKS 叢集輸出的向外流量可以藉由在 AKS 子網路中設定 UDR，透過 Azure 防火牆或網路虛擬裝置叢集來傳送。
  • 如果使用輸出模式 loadBalancer，必須小心管理輸出埠，因為可能會無意間用完所有可用的輸出埠。
• 根據預設，AKS 叢集中的所有 Pod 都可以無限制地傳送及接收流量。 Kubernetes 網路原則可以用來改善安全性，並篩選 AKS 叢集中 Pod 之間的網路流量。 AKS 中有兩個網路原則模型可供使用。 Microsoft 完全支援 Azure 網路原則，而我們也建議使用 Calico 作為具有更多功能的開放原始碼網路安全性解決方案。
• 服務網格提供流量管理、復原、原則、安全性、強式身分識別以及可檢視性等功能。 如需詳細資訊，請參閱選取準則。
• Azure 流量管理員和 Azure Front Door 等全域負載平衡機制會藉由將流量路由傳送到多個叢集上 (可能位於不同 Azure 區域) 來提高復原能力。
• AKS 會在部署叢集的子網路上設定網路安全性群組 (NSG)。 請勿手動編輯此 NSG，但您可以設定在 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 解析是由部署在連線訂閱中的集中式 DNS 伺服器所提供，可以是在中樞虛擬網路中，也可以是在連接到 Azure 虛擬 WAN 的共用服務虛擬網路中。 這些伺服器會使用 Azure DNS (IP 位址 168.63.129.16) 來有條件地解析 Azure 特定且公共的名稱，並使用企業的 DNS 伺服器來解析私人名稱。 不過，這些集中式 DNS 伺服器無法解析 AKS API FQDN，直到它們與位 AKS 叢集所建立的 DNS 私人區域連線為止。 由於區域名稱前面會加上隨機的 GUID，因此每個 AKS 都會有唯一的 DNS 私人區域。 因此，針對每個新的 AKS 叢集，其對應的私人 DNS 區域應連線至中央 DNS 伺服器所在的虛擬網路。

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

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

1. 系統管理員將會解析 Kubernetes API 的 FQDN。 內部部署 DNS 伺服器會將要求轉送到授權伺服器：Azure 中的 DNS 解析器。 這些伺服器會將要求轉送到 Azure DNS 伺服器 (168.63.129.16)，並從 Azure 私人 DNS 區域取得 IP 位址。
2. 在解析 IP 位址之後，Kubernetes API 的流量會從內部部署路由傳送至 VPN 或 Azure 中的 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 路由。
• 如果需要 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 為基礎的應用程式可以設為需穿過連線訂閱中的 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 伺服器 (定義為 AKS 虛擬網路中的自訂 DNS 伺服器)，來解析 Azure 平台即服務 (PaaS) 的 FQDN。
2. 解析後的 IP 會是私人端點的私人 IP 位址，可直接從 AKS Pod 存取。

AKS Pod 和私人端點之間的流量預設上不會通過中樞虛擬網路 (或是安全虛擬中樞，如果使用的是虛擬 WAN 的話) 中的 Azure 防火牆，即使 AKS 叢集設為以 Azure 防火牆篩選輸出。 這是因為私人端點會在部署 AKS 的應用程式虛擬網路的子網路中建立 /32 路由。

設計建議

• 如果您的安全性原則要求 Kubernetes API 具有私人 IP 位址 (而不是公用 IP 位址)，請 部署私人 AKS 叢集。
  • 在建立私人叢集時，請使用自訂的私人 DNS 區域，而不是讓建立流程使用系統私人 DNS 區域。
• 除非您有可指派給 AKS 叢集的有限 IP 位址範圍，否則請使用 Azure 容器網路介面 (CNI) 作為網路模型。
  • 請遵循使用 CNI 進行 IP 位址規劃的相關文件。
  • 若要使用 Windows 伺服器節點集區和虛擬節點來驗證最終限制，請參閱 Windows AKS 支援常見問題。
• 除非您在集中式訂閱中使用了 Azure 防火牆或 WAF，否則請使用 Azure DDoS 保護標準來保護用於 AKS 叢集的虛擬網路。
• 使用與 Azure 虛擬 WAN、中樞和輪輻架構、Azure DNS 區域和您自己的 DNS 基礎結構的整體網路設定相關聯的 DNS 設定。
• 使用 Private Link 來保護網路連線，並使用以私人 IP 為基礎的連線來連線到其他支援 Private Link 的受控 Azure 服務，例如 Azure 儲存體、Azure Container Registry、Azure SQL Database 和 Azure Key Vault。
• 使用輸入控制器來提供先進的 HTTP 路由和安全性，並為應用程式提供單一端點。
• 所有設定為使用輸入連線的 Web 應用程式都應該使用 TLS 加密，且不允許透過未加密的 HTTP 存取。 如果訂閱中包含了包含原則的企業規模登陸區域參考實作中所建議的原則，則此原則已強制執行。
• 若要節省 AKS 叢集的計算和儲存資源，您可選擇性地使用叢集外輸入控制器。
  • 使用 Azure 應用程式閘道輸入控制器 (AGIC) 附加元件，此為 Microsoft 管理的 Azure 服務。
  • 使用 AGIC 時，請為每個 AKS 叢集部署專用的 Azure 應用程式閘道，且不要讓多個 AKS 叢集共用相同的應用程式閘道。
  • 如果沒有資源或作業條件約束，或 AGIC 未提供必要的功能，請使用叢集內輸入控制器解決方案，例如 NGINX、Traefik 或任何其他 Kubernetes 支援的解決方案。
• 針對面向網際網路且安全性關鍵、面向內部的 Web 應用程式，請搭配輸入控制器使用 Web 應用程式防火牆。
  • Azure 應用程式閘道和 Azure Front Door 都整合了 Azure Web 應用程式防火牆來保護 Web 應用程式。
• 如果您的安全性原則要求檢查 AKS 叢集中產生的所有輸出網際網路流量，請使用 Azure 防火牆，或部署在受控中樞虛擬網路中的協力廠商網路虛擬裝置 (NVA) 來保護輸出網路流量。 如需詳細資訊，請參閱限制輸出流量。 AKS 輸出類型 UDR 需要將路由表與 AKS 節點子網路產生關連，因此目前無法使用 Azure 虛擬 WAN 或 Azure 路由伺服器所支援的動態路由插入。
• 針對非私人叢集，請使用經授權的 IP 範圍。
• 請使用 Azure Load Balancer 標準層，而不是基本層。