Azure Kubernetes Service （AKS） 網絡連接與安全性的最佳實踐

當你在 Azure Kubernetes Service （AKS） 中建立和管理叢集時，你為節點和應用程式提供網路連線。 這些網路資源包括 IP 位址範圍、負載平衡器和輸入控制器。

此最佳做法文章著重於叢集操作員的網路連線能力和安全性。 在本文中，您將學會如何：

選擇適當的網路模型

最佳做法指導方針

大多數情況下使用 Azure CNI Overlay。 如果工作負載需要從連接網路直接存取 Pod IP，請使用帶有 Azure CNI Pod 子網的平面網路。

虛擬網路會提供存取您應用程式的基本連線能力給 AKS 節點和客戶。 將 AKS 叢集部署到虛擬網路有兩種不同的方式：

• 重疊網路：Azure CNI 重疊會從個別的 Pod CIDR 指派 Pod IP 位址。 離開叢集的流量會被轉換成節點的 IP 位址，而 pod 不會直接透過連接網路的私有 IP 位址存取。
• 平面網路：Azure CNI Pod Subnet 或舊版 Azure CNI Node Subnet 會從虛擬網路位址空間指派 Pod IP 位址。 Pod 可以透過其私人 IP 位址從連線的網路進行存取。

欲了解更多選擇網路模式的資訊，請參閱 AKS 的 Plan pod 網路。

Azure CNI 網路功能概觀

Azure CNI 提供 IP 位址管理（IPAM）及 Pod 與節點的連接功能。 IPAM 選項與網路資料平面是分開的。 例如，您可以使用由 Cilium 支援的 Azure CNI，搭配 Azure CNI Overlay 或平面網路選項。

下圖顯示兩個 AKS 節點，分別透過網路橋接器連接到共享的 Azure 虛擬網路。

Azure CNI 網路允許資源的控制與管理分離。 從安全性觀點來看，您通常會想讓不同小組來管理及保護這些資源。 連接特性取決於網路模型。 Overlay Pod 會透過節點 IP 位址連線至虛擬網路及內部部署資源。 扁平網路 pod 可透過其私有 IP 位址直接與連接的資源通訊。

當你使用 Azure CNI 網路時，虛擬網路資源會與 AKS 叢集分開一個資源群組。 您可以將存取和管理這些資源的權限委派給 AKS 服務主體。 AKS 叢集使用的叢集身分識別在虛擬網路內的子網路上至少必須包含 Network Contributor 權限。

如果您想要定義自訂角色，而不使用內建的網路參與者角色，則需要下列權限：

在預設情況下，AKS 使用受控識別作為其叢集的識別。 不過，您可以改用服務主體。

• 若要了解更多關於 AKS 服務主體委派的資訊，請參閱委派存取權給其他 Azure 資源。
• 如需受控識別的詳細資訊，請參閱使用受控識別。

根據網路模型規劃地址範圍。 請記住下列準則：

• 使用 Azure CNI Overlay 時，請依節點需求設定節點子網的大小，並為 Pod 使用個別的私有 CIDR。 每個節點從 pod CIDR 接收一個 /24 位址空間。
• 在扁平式網路中，請為節點和 Pod 規劃虛擬網路中子網路的大小。 Azure CNI Pod Subnet 使用分開的節點子網和 Pod 子網，而舊版 Azure CNI Node Subnet 則讓節點和 Pod 共用同一個子網。
• 要避免使用與現有網路資源重疊的 IP 位址範圍。
  • 在 Azure 中，必須允許與本地或對等網路的連線。
• 要處理擴展事件或叢集升級，你需要在指定的子網中提供額外的 IP 位址。
  • 如果你使用 Windows Server 容器，這個額外的位址空間尤其重要，因為這些節點池需要升級才能套用最新的安全修補程式。 欲了解更多關於 Windows Server 節點的資訊，請參閱 在 AKS 中升級節點池。

要計算所需的 IP 位址空間，請參閱 AKS 叢集的 IP 位址規劃。

在建立 Azure CNI 網路叢集時，你可以指定叢集的其他位址範圍，例如 DNS 服務 IP 和服務位址範圍。 一般來說，請確保這些位址範圍彼此不重疊，也不與叢集相關的任何網路重疊，包括虛擬網路、子網路、本地網路和對等網路。

有關網路模型、限制與位址大小的詳細資訊，請參閱 Azure CNI 網路概覽。

分配輸入流量

最佳做法指導方針

若要將 HTTP 或 HTTPS 流量分散至應用程式，請使用輸入資源和控制器。 與 Azure 負載平衡器相比，入口控制器提供額外功能，且可作為原生 Kubernetes 資源來管理。

雖然 Azure 負載平衡器可以將客戶流量分配到你的 AKS 叢集中的應用程式，但它在理解這些流量方面有限。 負載平衡器資源會在第 4 層上運作，並根據通訊協定或連接埠分散流量。

大部分使用 HTTP 或 HTTPS 的 Web 應用程式，應當使用於第 7 層所運作的 Kuberenetes 輸入資源和控制器。 輸入可以根據應用程式的 URL 將流量分散到應用程式，並處理 TLS/SSL 終止。 Ingress 也會減少您公開和映射的 IP 位址數量。

使用負載平衡器時，每個應用程式通常需要指派一個公用 IP 位址，並將其對應至 AKS 叢集中的服務。 若使用輸入資源，單一 IP 位址可以將流量分散到多個應用程式。

圖示顯示一個接收外部流量的公共 IP 位址，以及一個入口控制器將這些流量分配給 AKS 叢集中的多個服務。

Ingress 有兩個組成部分：Ingress 資源 和 Ingress 控制器。

輸入資源

入口資源是kind: Ingress的 YAML 清單。 它定義了主機、憑證以及將流量路由到 AKS 叢集中運行服務的規則。

以下範例 YAML 資訊清單使用應用程式路由附加元件的受管理 NGINX Ingress 類別。 它會將流量 myapp.com 分配到兩個服務之一： blogservice 或 storeservice，並根據客戶所存取的網址，導向其中一項服務。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ingress
spec:
  ingressClassName: webapprouting.kubernetes.azure.com
  tls:
  - hosts:
    - myapp.com
    secretName: myapp-secret
  rules:
  - host: myapp.com
    http:
      paths:
      - path: /blog
        pathType: Prefix
        backend:
          service:
            name: blogservice
            port:
              number: 80
      - path: /store
        pathType: Prefix
        backend:
          service:
            name: storeservice
            port:
              number: 80

欄位 ingressClassName 會選擇入口類別，並且必須與叢集中入口控制器上設定的類別相匹配。 該值 webapprouting.kubernetes.azure.com 選擇由應用程式路由外掛所提供的受管理 NGINX 入口控制器。 如果你用的是其他實作，請用你入口控制器的類別名稱來取代它。

入口控制器

叢集託管的 入口控制器 作為工作負載運行於 AKS 節點，並監控收到的請求。 接著，傳入流量會根據與該控制器關聯的 Ingress 資源中所定義的規則進行分配。 雖然最常見的輸入控制器為以 NGINX 為基礎，但 AKS 不會限制您至特定的控制器。 你可以使用 Application Gateway for Containers、 Contour、 HAProxy、 Traefik 等。

你必須將由叢集託管的 Ingress 控制器排定在 Linux 節點上。 在你的 YAML 清單或 Helm 圖表部署中，使用節點選擇器表示該資源應該能在 Linux 節點上執行。 如需詳細資訊，請參閱 使用在 AKS 內已排程的節點選取器來控制 Pod。

使用應用程式路由附加元件的 Ingress

應用程式路由外掛為 AKS 提供受管理的入口實作。 對於新的長期運作部署，如果 Application Routing Gateway API 實作符合你的需求，請使用它。 Gateway API 是 Kubernetes 入口與第 7 層流量管理的長期標準。

受管理的 NGINX 實作提供以下特性：

• 根據 Kubernetes NGINX 輸入控制器，輕鬆設定受控 NGINX 輸入控制器。
• 與 Azure DNS 整合用於公有與私有區域管理。
• 使用儲存在 Azure Key Vault 中的憑證進行 SSL 終止。

欲了解更多資訊，請參閱 「以應用路由閘道 API 配置輸入 」及 「以應用程式路由外掛配置 NGINX 入口」。

使用 Web 應用程式防火牆 (WAF) 來保護流量

最佳做法指導方針

若要掃描進來流量以偵測潛在攻擊，請使用網頁應用程式防火牆（WAF），例如 Barracuda WAF for Azure 或 Azure Web 應用程式防火牆 on Application Gateway for Containers。 容器應用閘道可路由 HTTP、HTTPS、gRPC、WebSocket 及 AI 推論流量，並支援 TLS 終止。

叢集託管的入口控制器作為 Kubernetes 工作負載運行於你的 AKS 叢集中，並將流量分配給服務和應用程式。 它會消耗節點部分資源，如 CPU、記憶體和網路頻寬。 在較大的環境中，你可能想考慮以下幾點：

• 卸載一些流量路由或 TLS 終止至 AKS 叢集外部的網路資源。
• 掃描傳入的流量以查看是否有潛在攻擊。

此圖說明外部流量經過 Azure 應用程式閘道 for Containers。 當配置 WAF 保護時，WAF 規則會在容器應用閘道轉發允許流量至 AKS 叢集服務前過濾請求。

為了增加安全層，網頁應用防火牆（WAF）會過濾進來的流量。 受管理與自訂規則可防範跨站腳本與 SQL 注入等攻擊。 容器應用閘道是一項支援 Azure WAF 的第 7 層負載平衡與流量管理服務。

僅部署容器應用閘道（Application Gateway for Containers）並非能啟用 WAF 保護。 您必須建立 WAF 政策並完成以下兩項設定，WAF 才會檢查流量：

• 建立一個 Azure SecurityPolicy 子資源，參考 WAF 政策。
• 套用參照相同 WAF 原則，並以 Gateway 或 HTTPRoute 資源作為保護目標的 Kubernetes WebApplicationFirewallPolicy 自訂資源。

完成兩個設定後，先確認自訂資源狀態和 WAF 日誌，再決定是否依賴政策來保護。 欲了解更多資訊，請參閱容器應用閘道上的 Azure Web 應用程式防火牆。

由於其他第三方解決方案也會執行這些功能，因此，您可以在指定產品中繼續使用現有的投資或專長。

負載平衡器或入口資源會持續在 AKS 叢集中運行，並優化流量分配。 適用於容器的 Azure 應用程式閘道可透過資源定義做為輸入控制器集中管理。 開始時，請 建立容器應用閘道，然後分別設定 WAF 保護。

使用網路原則控制流量

最佳做法指導方針

使用網路原則來允許或拒絕 Pod 的流量。 根據預設，叢集中的 Pod 之間允許所有流量。 為了提升安全性，請定義限制 Pod 通訊的規則。

在 AKS 中，網路政策是 Kubernetes 提供的一項功能，可以控制 Pod 之間的流量流動。 可以根據指派的標籤、命名空間或流量連接埠等設定來允許或拒絕至 Pod 的流量。 網路原則是控制 Pod 流量的雲端原生方式。 由於 Pod 是在 AKS 叢集中動態建立的，因此可以自動套用所需的網路原則。

要在 AKS 中使用網路政策，請選擇支援你節點作業系統和網路資料平面的網路政策引擎。 你可以在叢集建立時啟用政策引擎，或是在現有支援的叢集上啟用。

對於 Linux 節點集區，請使用由 Cilium 提供支援的 Azure CNI 及其內建的 Cilium 網路原則強制執行功能。 Cilium 不支援 Windows 節點池。 對於 Windows 工作負載，請使用 Calico。

使用 YAML 資訊清單將網路策略創建為 Kubernetes 資源。 原則會套用至已定義的 Pod，其中包含以輸入或輸出規則來定義流量流程。

下列範例將網路原則套用至具有 app: backend 標籤的 Pod。 入口規則僅允許來自具有 app: frontend 標籤的 Pod 的流量。

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend

要開始使用原則，請參考 在 Azure Kubernetes Service (AKS) 中使用網路原則來保護 pod 間流量。

用 LocalDNS 優化 DNS 解析

最佳做法指導方針

使用 LocalDNS 提升 DNS 效能與可靠性，並減輕集中式 CoreDNS Pods 的負載。 LocalDNS 已在 AKS Automatic 中預先設定。 在 AKS 標準中，啟用並設定每個節點池的 LocalDNS。

LocalDNS 會在每個節點部署 DNS 代理作為 systemd 服務，以本地處理 DNS 查詢。 預設情況下，Pod 會將所有 DNS 查詢傳送至集中式 CoreDNS Pod。 在大規模情況下，集中這些查詢可能會造成瓶頸，而本地解析則能減少網路跳數與延遲。

LocalDNS 也會消除 DNS 流量的 conntrack 資料表項目，防止 conntrack 資料表耗盡和競用情況發生，而可能造成連線中斷。 從本地快取到 CoreDNS 的連接升級至 TCP，以實現連接重新平衡和更快的紀錄清理。

對於需要高 DNS 可用性的工作負載，LocalDNS 支援在上游 DNS 無法使用時，在一段可設定期間內提供過期快取的回覆。 這種盡力而為的能力可以幫助在短暫 DNS 中斷時維持 pod 連線與服務可靠性，但並不保證會有過時的紀錄可用。

在 AKS Standard 中，在現有節點集區上啟用 LocalDNS 會將其節點重新建立映像。 規劃部署時，請將這項干擾納入考量。

欲了解更多 LocalDNS 架構與功能，請參閱 AKS 中的 DNS 解析。 關於設定說明，請參見 「設定 LocalDNS」。

安全連接節點

最佳做法指導方針

請勿對您的 AKS 節點公開遠端連線能力。 例行 Linux 節點故障排除時，請使用 kubectl debug Kubernetes API。 當你需要 SSH 存取時，可以透過私人網路或 Azure Bastion 連接。

你可以透過使用 Azure 管理工具或 Kubernetes API 伺服器完成大部分 AKS 操作。 AKS 節點不會連線至公用網路，而只會於私人網路上提供。 對於 Linux 節點，請透過 kubectl debug Kubernetes API 啟動一個特權除錯容器。 這種方式不需要直接透過 SSH 連線到節點。

如果 Kubernetes API 存取不適合或你需要 SSH，請使用連接網路節點的私有 IP 位址。 Azure Bastion 可以提供私密連線，且不會暴露節點上的公共 IP 位址。 對於 Windows 節點，請使用主機程序容器或透過 Linux 代理節點連接。 如果代理節點無法使用，Azure Bastion 是個替代方案。 欲了解更多資訊，請參閱 「連接至 AKS 叢集節點」以進行維護或故障排除。

圖示中顯示一個管理虛擬網路，包含一個堡壘主機，該主機透過安全對等連結路由連線至 AKS 叢集虛擬網路。

如果你使用 Bastion 主機或跳板盒，請將其放在獨立且安全對等的管理虛擬網路中。 透過使用 Azure ExpressRoute 或 VPN 閘道器來保護管理網路，連接本地網路並控制網路安全群組的存取。

下一步

本文著重於網路連線和安全性。 欲了解更多 Kubernetes 基礎網路資訊，請參閱 Azure Kubernetes Service (AKS) 中的應用程式網路概念