共用方式為

在 Azure Kubernetes Service (AKS) 中使用公用標準負載平衡器

  • 發行項

Azure Load Balancer 會在支援輸入和輸出案例的開放系統互相連線 (OSI) 模型本身的第 4 層上運作。 這會將抵達負載平衡器前端的輸入流量分送給後端集區執行個體。

公用負載平衡器與 AKS 整合有兩個用途：

  1. 若要藉由將私人 IP 位址轉譯為其輸出集區的公用 IP 位址部分，為 AKS 虛擬網路內的叢集節點提供輸出連接。
  2. 透過型別 LoadBalancer 的 Kube 服務提供應用程式存取權，可讓您輕鬆擴充應用程式並建立高可用性服務。

只允許在私人 IP 位置上使用內部（或私人）負載平衡器作為前端。 內部負載平衡器可用來對虛擬網路內的流量進行負載平衡。 在混合情節中，從內部部署網路也可以存取負載平衡器前端。

本文涵蓋 AKS 公用負載平衡器整合。 如需內部負載平衡器整合，請參閱使用 AKS 內部負載平衡器。

開始之前

  • Azure Load Balancer 有兩種 SKU -「基本」和「標準」。 建立 AKS 叢集時，預設使用標準 SKU。 「標準」SKU 可以存取新增的功能，例如較大的後端集區、多個節點集區，可用性區域，且預設是安全的。 這是 AKS 的建議負載平衡器 SKU。 如需基本和標準 SKU 的詳細資訊，請參閱 Azure Load Balancer SKU 比較。
  • 如需型別 LoadBalancer Kube 服務支援的註釋的完整清單，請參閱 LoadBalancer 註釋。
  • 本文假設您的 AKS 叢集使用的是「標準」SKU Azure Load Balancer。 如需 AKS 叢集，可以使用 Azure CLI、Azure PowerShell 或 Azure 入口網站，建立一個 AKS 叢集。
  • AKS 管理代理程式節點的生命週期和作業。 不支援修改與代理程式節點相關聯的 IaaS 資源。 例如不支援負載平衡器資源群組的手動變更。

重要

若要使用自己的網路閘道、防火牆或 Proxy 提供輸出連接，可以跳過負載平衡器輸出集區和個別前端 IP 的建立，並使用 輸出型別作為 UserDefinedRouting（UDR）。 輸出類型會定義叢集的輸出方法，且其預設類型為 LoadBalancer。

使用公用標準負載平衡器

建立輸出型別 LoadBalancer（預設）的 AKS 叢集後，叢集即準備好使用負載平衡器來公開服務。

建立 public-svc.yaml 服務資訊清單將建立型別 LoadBalancer 的公用服務。

apiVersion: v1
kind: Service
metadata:
  name: public-svc
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: public-app

指定負載平衡器 IP 位址

若負載平衡器要與特定 IP 位址搭配使用，有以下兩種方式：

重要

將 LoadBalancerIP 屬性新增至負載平衡器 YAML 資訊清單即將淘汰下列上游 Kube。 雖然目前的使用量將維持不變，且現有服務繼續運作，不需修改，但我們仍強烈建議設定服務註釋。

  • 設定服務註釋：讓 IPv4 位址使用 service.beta.kubernetes.io/azure-load-balancer-ipv4，讓 IPv6 位址使用 service.beta.kubernetes.io/azure-load-balancer-ipv6。
  • 將 LoadBalancerIP 屬性新增到負載平衡器 YAML 資訊清單：將 Service.Spec.LoadBalancerIP 屬性新增到負載平衡器 YAML 資訊清單。 這個欄位已在上游 Kube 推出後淘汰，且不支援雙堆疊。 目前的使用量將維持不變，且現有服務繼續運作，不需修改。

部署服務資訊清單

使用 kubectl apply 部署公用服務資訊清單，並指定 YAML 資訊清單的名稱。

kubectl apply -f public-svc.yaml

Azure Load Balancer 是透過新的公用 IP 設定，會將新服務列於前端。 Azure Load Balancer 可以有多個前端 IP，所以部署的每個新服務都會取得可供唯一存取的專用新前端 IP。

確認您的服務已建立，並使用以下命令來設定負載平衡器。

kubectl get service public-svc

NAMESPACE     NAME          TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)         AGE
default       public-svc    LoadBalancer   10.0.39.110    203.0.113.187   80:32068/TCP    52s

您檢視服務詳細資料時，在負載平衡器上對於此服務建立的公用 IP 位址會顯示在 EXTERNAL-IP 資料行中。 IP 位址可能需要幾分鐘才能從<擱置>變為實際的公用 IP 位址。

如需服務的詳細資訊，請使用以下命令。

kubectl describe service public-svc

以下範例輸出是執行 kubectl describe service 後輸出的精簡版本。 LoadBalancer 輸入顯示服務公開的外部 IP 位址。 IP 顯示內部位址。

Name:                        public-svc
Namespace:                   default
Labels:                      <none>
Annotations:                 <none>
Selector:                    app=public-app
...
IP:                          10.0.39.110
...
LoadBalancer Ingress:        203.0.113.187
...
TargetPort:                  80/TCP
NodePort:                    32068/TCP
...
Session Affinity:            None
External Traffic Policy:     Cluster
...

設定公用標準負載平衡器

您可以在叢集建立期間或藉由更新叢集，為標準公用負載平衡器自訂不同的設定。 這些自訂選項讓您建立符合工作負載需求的負載平衡器。 使用標準負載平衡器，您可以：

  • 設定或擴充受控輸出 IP 的數目。
  • 自備自訂輸出 IP 或輸出 IP 前置。
  • 自訂配置到叢集上每個節點的輸出連接埠數目。
  • 設定閒置連接的逾時設定。

重要

一次只能使用一個輸出 IP 選項 (受控 IP、自備 IP 或 IP 首碼)。

變更輸入集區類型

您可以透過 AKS 節點的 IP 設定（Azure 虛擬機器擴展集型成員資格），或只靠其 IP 位址，在負載平衡器後端集區中參考 AKS 節點。 使用 IP 位址型後端池成員資格，可提升更新服務和佈建負載平衡器時的效率，尤其是在節點數量較多時。 現在支援使用 IP 型後端集區佈建新叢集，也支援轉換現有叢集。 結合 NAT 網路閘道或使用者定義的路由輸出型別時，佈建新的節點和服務效能更高。

有兩種不同的集區成員資格型別可供使用：

  • nodeIPConfiguration - 舊版虛擬機器擴展集 IP 設定型集區成員資格型別
  • nodeIP - IP 型成員資格型別

需求

  • AKS 叢集必須是 1.23 版或更新版本。
  • AKS 叢集必須使用標準負載平衡器和虛擬機器擴展集。

使用 IP 型輸入集區成員資格，建立新 AKS 叢集

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-backend-pool-type=nodeIP \
    --generate-ssh-keys

更新現有的 AKS 叢集，以使用 IP 型輸入集區成員資格

警告

這項作業將導致叢集中的傳入服務流量暫時中斷。 叢集越大（內含的節點越多），影響時間越長。

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-backend-pool-type=nodeIP

調整受控輸出公用 IP 的數目

Azure Load Balancer 提供虛擬網路的輸出和輸入連線能力。 輸出規則可以簡單地設定公用標準負載平衡器的輸出網路位址轉譯。

輸出規則依循的語法，與負載平衡和輸入 NAT 規則相同：

前端 IP + 參數 + 後端集區

輸出規則將後端集區識別的所有虛擬機器的輸出 NAT，設為轉譯成前端。 參數針對輸出 NAT 演算法提供更多控制。

輸出規則可與單一公用 IP 位址搭配使用，亦適用於擴充輸出 NAT，因為可以減輕設定負擔。 您可以使用多個 IP 位址，規劃大規模情節，也可以使用輸出規則，緩解 SNAT 容易耗盡的問題。 前端提供的每個 IP 位址，都為負載平衡器提供 64k 暫時性連接埠，當作 SNAT 連接埠使用。

使用標準 SKU 負載平衡器與受控輸出公用 IP（預設建立）時，可以使用 --load-balancer-managed-outbound-ip-count 參數，擴充受控輸出公用 IP 的數目。

請使用以下命令更新現有叢集。 您也可以將這個參數設為擁有多個受控輸出公用 IP。

重要

不建議使用 Azure 入口網站變更輸出規則。 您應透過 AKS 叢集變更，不要直接在 Load Balancer 資源上變更。

只要協調了叢集，就會移除直接在 Load Balancer 資源上所做的輸出規則變更（例如何時停止、啟動、升級或擴充）。

使用 Azure CLI，如範例所示。 在叢集停機期間使用 az aks CLI 命令所做的輸出規則變更是永久的。

如需詳細資訊，請參閱 Azure Load Balancer 輸出規則。

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-managed-outbound-ip-count 2

對於 myResourceGroup 中的 myAKSCluster 叢集，上述範例會將受控輸出公用 IP 的數目設定為「2」。

建立叢集時，附加 --load-balancer-managed-outbound-ip-count 參數並將其設為所需值，也可以設定受控輸出公用 IP 的初始數量。 受控輸出公用 IP 的預設數目為 1。

提供您自己的輸出公用 IP 或首碼

您使用「標準」SKU 負載平衡器時，AKS 叢集預設會自動在 AKS 管理的基礎結構資源群組中建立公用 IP，並將其指派給負載平衡器輸出集區。

AKS 建立的公用 IP 是 AKS 管理的資源，因此其生命週期亦由 AKS 管理，使用者不需要對公用 IP 資源直接執行操作。 或者，您也可以在叢集建立期間指派自己的自訂公用 IP 或公用 IP 首碼。 您也可以在現有叢集的負載平衡器屬性上更新您的自訂 IP。

使用自己公用 IP 或 IP 前置的需求：

  • 使用者必須建立並擁有自訂公用 IP 位址。 AKS 建立的管理公用 IP 位址，不能當作「自備自訂 IP」重複使用，因為可能導致管理衝突。
  • 您必須根據必要的公用 IP 權限清單，確定 AKS 叢集識別 (服務主體或受控識別) 擁有存取輸出 IP 的權限。
  • 請確認您符合設定輸出 IP 或輸出 IP 前置的必要條件和限制。

使用您自己的輸出公用 IP 更新叢集

使用 az network public-ip show 命令，列出公用 IP 的 ID。

az network public-ip show --resource-group myResourceGroup --name myPublicIP --query id -o tsv

上述命令會顯示 myResourceGroup 資源群組中的 myPublicIP 公用 IP 所用的識別碼。

請使用 az aks update 命令搭配 load-balancer-outbound-ips 參數，使用您的公用 IP 更新您的叢集。

下列範例會使用 load-balancer-outbound-ips 參數搭配前一個命令的識別碼。

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-outbound-ips <publicIpId1>,<publicIpId2>

使用您自己的輸出公用 IP 首碼更新叢集

您也可以使用輸出的公用 IP 首碼搭配您的「標準」SKU 負載平衡器。 下列範例使用 az network public-ip prefix show 命令列出公用 IP 首碼的識別碼。

az network public-ip prefix show --resource-group myResourceGroup --name myPublicIPPrefix --query id -o tsv

上述命令會顯示 myResourceGroup 資源群組中的 myPublicIPPrefix 公用 IP 首碼所用的識別碼。

下列範例會使用 load-balancer-outbound-ip-prefixes 參數搭配前一個命令的識別碼。

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-outbound-ip-prefixes <publicIpPrefixId1>,<publicIpPrefixId2>

使用您自己的公用 IP 或首碼建立叢集

建立叢集時，您可以在出口部分使用自己的 IP 位址或 IP 前置，以利處理各種情況，例如將出口端點新增到允許清單。 若要在叢集建立時，定義自己的公用 IP 和 IP 前置，可以附加與上一個命令相同的參數。

請使用 az aks create 命令與 load-balancer-outbound-ips 參數，建立新叢集與自己的公用 IP。

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-outbound-ips <publicIpId1>,<publicIpId2> \
    --generate-ssh-keys

請使用 az aks create 命令與 load-balancer-outbound-ip-prefixes 參數，建立新叢集與自己的公用 IP 前置。

az aks create \
    --resource-group myResourceGroup \
    --load-balancer-outbound-ip-prefixes <publicIpPrefixId1>,<publicIpPrefixId2> \
    --generate-ssh-keys

設定配置的輸出連接埠

重要

如果叢集上的應用程式可與一小部分目的地建立大量連接（例如連線到資料庫的前端應用程式執行個體 ），您可能會遇到 SNAT 連接埠容易耗盡的問題。 當應用程式用完輸出連接埠，以用來建立另一個應用程式或主機的連線時，就會發生 SNAT 連接埠耗盡。 如果您容易遇到 SNAT 連接埠耗盡的情況，強烈建議您在負載平衡器上增加配置的輸出連接埠和輸出前端 IP。

如需 SNAT 的詳細資訊，請參閱使用 SNAT 進行輸出連接。

根據預設，AKS 會將負載平衡器上的 AllocatedOutboundPorts 設定為 0，以在建立叢集時啟用根據後端集區大小啟用自動輸出連接埠指派。 例如，如果叢集有 50 個或更少的節點，則會對每個節點配置 1024 個連接埠。 叢集中的節點越來越多，每個節點可用的連接埠會越來越少。

重要

節點規模小於或等於 50（1-50）時，不論是否增加前端 IP，連接埠只能有 1024 個。

若要顯示 AKS 叢集負載平衡器的 AllocatedOutboundPorts 值，請使用 az network lb outbound-rule list。

NODE_RG=$(az aks show --resource-group myResourceGroup --name myAKSCluster --query nodeResourceGroup -o tsv)
az network lb outbound-rule list --resource-group $NODE_RG --lb-name kubernetes -o table

下列範例輸出顯示針對叢集啟用根據後端集區大小的自動輸出連接埠指派。

AllocatedOutboundPorts    EnableTcpReset    IdleTimeoutInMinutes    Name             Protocol    ProvisioningState    ResourceGroup
------------------------  ----------------  ----------------------  ---------------  ----------  -------------------  -------------
0                         True              30                      aksOutboundRule  All         Succeeded            MC_myResourceGroup_myAKSCluster_eastus

若要在建立或更新叢集時設定 AllocatedOutboundPorts 和輸出 IP 位址的特定值，請使用 load-balancer-outbound-ports 以及 load-balancer-managed-outbound-ip-count、load-balancer-outbound-ips 或 load-balancer-outbound-ip-prefixes。 為輸出連接埠或輸出 IP 位址設定特定值或增加現有值之前，必須先計算適當的輸出連接埠和 IP 位址數量。 針對此計算使用下列方程式四捨五入至最接近的整數：64,000 ports per IP / <outbound ports per node> * <number of outbound IPs> = <maximum number of nodes in the cluster>。

計算輸出連接埠和 IP 的數目，以及設定相關數值時，請記住以下資訊：

  • 每個節點的輸出連接埠數目是固定的，視設定值而定。
  • 輸出連接埠的值必須是 8 的倍數。
  • 新增更多 IP 並不會將更多連接埠新增到任何節點，但能為叢集中的更多節點提供容量。
  • 您必須考量在升級過程中新增的節點，包括透過 maxSurge 值指定的節點計數。

以下範例顯示設定值如何影響輸出連接埠和 IP 位址的數目：

  • 如果使用預設值，且叢集有 48 個節點，則每個節點有 1024 個可用連接埠。
  • 如果使用預設值，而且叢集會從 48 個節點擴充到 52 個節點，每個節點會從 1024 個可用連接埠更新為 512 個可用連接埠。
  • 若輸出連接埠的數目設為 1,000，輸出 IP 計數設為 2，則叢集最多支援 128 個節點：64,000 ports per IP / 1,000 ports per node * 2 IPs = 128 nodes。
  • 若輸出連接埠的數目設為 1,000，輸出 IP 計數設為 7，則叢集最多支援 448 個節點：64,000 ports per IP / 1,000 ports per node * 7 IPs = 448 nodes。
  • 若輸出連接埠的數目設為 4,000，輸出 IP 計數設為 2，則叢集最多支援 32 個節點：64,000 ports per IP / 4,000 ports per node * 2 IPs = 32 nodes。
  • 若輸出連接埠的數目設為 4,000，輸出 IP 計數設為 7，則叢集最多支援 112 個節點：64,000 ports per IP / 4,000 ports per node * 7 IPs = 112 nodes。

重要

計算輸出連接埠和 IP 數目之後，請確認您有額外的輸出連接埠容量，可在升級期間處理節點激增。 務必為升級和其他作業所需的額外節點, 配置足夠的連接埠。 AKS 預設為一個緩衝區節點以進行升級作業。 如果使用 maxSurge 值，請將每個節點的輸出連接埠乘以 maxSurge 值，以判斷所需的連接埠數目。 舉例而言，假設您算出每個節點需要 4000 個連接埠，叢集要有 7 個 IP 位址，最多要有 100 個節點，最大突波值是 2：

  • 2 個激增節點 * 每個節點 4000 個連接埠 = 升級期間節點激增所需的 8000 個連接埠。
  • 100 個節點 * 每個節點 4000 個連接埠 = 叢集所需的 400,000 個連接埠。
  • 7 個 IP * 每個 IP 64000 個連接埠 = 448,000 個連接埠可供叢集使用。

上述範例顯示叢集的容量超過 48,000 個連接埠，足以處理升級期間節點激增所需的 8000 個連接埠。

一旦計算並驗證這些值之後，您可以在建立或更新叢集時使用 load-balancer-outbound-ports 和 load-balancer-managed-outbound-ip-count、load-balancer-outbound-ips，或 load-balancer-outbound-ip-prefixes 來套用這些值。

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-managed-outbound-ip-count 7 \
    --load-balancer-outbound-ports 4000

設定負載平衡器閒置逾時

當 SNAT 連接埠資源耗盡時，輸出流程會失敗，直到現有的流程釋出 SNAT 連接埠為止。 流程關閉時，負載平衡器會回收 SNAT 連接埠，且 AKS 設定的負載平衡器會利用 30 分鐘閒置逾時時間，從閒置流程中回收 SNAT 連接埠。

您也可以使用傳輸 (例如 TCP keepalives 或 application-layer keepalives) 重新整理閒置流程，然後視需要重設此閒置逾時。 您可以遵循以下範例來設定此逾時。

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-idle-timeout 4

如果您會有許多短時間連接，不會有長時間連接（也就是可能長時間閒置的連接，例如使用 kubectl proxy 或 kubectl port-forward），不妨考慮使用 4 分鐘等低逾時值。 使用 TCP 存留時，在連線的一端加以啟用即已足夠。 例如，只在伺服器端啟用便足以重設流程的閒置計時器。 兩端都不需要啟動 TCP keepalives。 應用程式層也有類似概念，包括資料庫用戶端-伺服器組態。 請檢查伺服器端，了解應用程式的特定存留有哪些選項。

重要

AKS 預設會在閒置時啟用 TCP 重設。 建議您保留這個設定，並在情節中有效率的調控，以建立可預測的應用程式行為。

TCP RST 只會在已建立狀態的 TCP 連線期間傳送。 請在此處閱讀相關資訊。

若將 IdleTimeoutInMinutes 設為與預設值 30 分鐘不同的值，請將工作負載所需的輸出連接時間納入考量。 也請考慮在 AKS 以外使用「標準」SKU 負載平衡器的預設逾時值為 4 分鐘。 IdleTimeoutInMinutes 值，可以更精確反映您的特定 AKS 工作負載，有助於減少佔用不再使用的連線而造成的 SNAT 耗盡。

警告

修改 AllocatedOutboundPorts 和 IdleTimeoutInMinutes 的值，可能會大幅改變負載平衡器輸出規則的行為，因此不應輕易變更。 更新值之前，請先參閱 SNAT 疑難排解一節，並檢閱負載平衡器輸出規則和 Azure 中的輸出連接，以充分瞭解變更的影響。

將輸入流量限制在特定 IP 範圍內

下列資訊清單會使用 loadBalancerSourceRanges 指定輸入外部流量的新 IP 範圍。

apiVersion: v1
kind: Service
metadata:
  name: azure-vote-front
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: azure-vote-front
  loadBalancerSourceRanges:
  - MY_EXTERNAL_IP_RANGE

此範例會將規則更新為只允許來自 MY_EXTERNAL_IP_RANGE 範圍的輸入外部流量。 如果您將 MY_EXTERNAL_IP_RANGE 取代為內部子網路 IP 位址，則流量會限制為僅限叢集內部 IP。 如果流量受限於叢集內部 IP，Kube 叢集外部的用戶端將無法存取負載平衡器。

注意

  • 輸入的外部流量會從負載平衡器流向 AKS 叢集的虛擬網路。 虛擬網路擁有網路安全性群組 (NSG)，可允許來自負載平衡器的全部輸入流量。 此 NSG 會使用 LoadBalancer 類型的服務標籤，以允許來自負載平衡器的流量。
  • 使用 v1.25 版或更新版本的集群，如果有 Pod 需要存取服務的 LoadBalancer IP，則需要在 loadBalancerSourceRanges 新增 Pod CIDR。

在輸入連線上維護用戶端的 IP

Kubernetes 和 AKS 中 LoadBalancer 類型的服務，預設不會在 Pod 連線至保留用戶端的 IP 位址。 封包上傳遞至 Pod 的來源 IP，會是節點的私人 IP。 若要維護用戶端的 IP 位址，您必須在服務定義中將 service.spec.externalTrafficPolicy 設定為 local。 下列資訊清單顯示範例。

apiVersion: v1
kind: Service
metadata:
  name: azure-vote-front
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local
  ports:
  - port: 80
  selector:
    app: azure-vote-front

透過 Kube 註釋自訂

以下是型別 LoadBalancer Kube 服務支援的註釋，這些註釋只適用於輸入流程。

註釋 值 Description
service.beta.kubernetes.io/azure-load-balancer-internal true 或 false 指定負載平衡器是否應為內部。 如果未設定，預設是公用。
service.beta.kubernetes.io/azure-load-balancer-internal-subnet 子網路的名稱 指定應該繫結內部負載平衡器的子網路。 如果未設定，預設是雲端設定檔設定的子網路。
service.beta.kubernetes.io/azure-dns-label-name 公用 IP 上的 DNS 標籤名稱 指定公用服務的 DNS 標籤名稱。 如果將其設為空白字串，將不使用公用 IP 中的 DNS 項目。
service.beta.kubernetes.io/azure-shared-securityrule true 或 false 利用網路安全性群組中的 Azure 增強安全性規則，指定可能與他人共用的 Azure 安全性規則來公開服務以增加服務曝光。
service.beta.kubernetes.io/azure-load-balancer-resource-group 資源群組的名稱 指定負載平衡器公用 IP 的資源群組，這些 IP 不在與叢集基礎結構相同的資源群組 (節點資源群組) 中。
service.beta.kubernetes.io/azure-allowed-service-tags 允許的服務標籤清單 指定允許的服務標籤清單，以逗號分隔。
service.beta.kubernetes.io/azure-load-balancer-tcp-idle-timeout 以分鐘為單位的 TCP 閒置逾時 指定經過多少時間（以分鐘為單位），才判定負載平衡器上的 TCP 連接閒置逾時。 預設值和最小值是 4。 最大值是 30。 值必須是整數。
service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset true 或 false 指定負載平衡器是否應在閒置逾時時停用 TCP 重設功能。
service.beta.kubernetes.io/azure-load-balancer-ipv4 IPv4 位址 指定要指派給負載平衡器的 IPv4 位址。
service.beta.kubernetes.io/azure-load-balancer-ipv6 IPv6 位址 指定要指派給負載平衡器的 IPv6 位址。

自訂負載平衡器健全狀態探查

註釋 值 Description
service.beta.kubernetes.io/azure-load-balancer-health-probe-interval 健全狀態探查間隔
service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe 健全狀態探查的狀況不良回應最小值
service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path 健全狀態探查的要求路徑
service.beta.kubernetes.io/port_{port}_no_lb_rule true/false {port} 是服務連接埠號碼。 設為 true 時，不會產生這個連接埠的 lb 規則或健全狀態探查規則。 健康情況檢查服務不應公開在公用網際網路（例如 istio/envoy 健康情況檢查服務）
service.beta.kubernetes.io/port_{port}_no_probe_rule true/false {port} 是服務連接埠號碼。 設為 true 時，不會產生這個連接埠的健全狀態探查規則。
service.beta.kubernetes.io/port_{port}_health-probe_protocol 健全狀態探查通訊協定 {port} 是服務連接埠號碼。 服務連接埠 {port} 的健全狀態探查明確通訊協定將覆寫 port.appProtocol（如果設定的話）。
service.beta.kubernetes.io/port_{port}_health-probe_port 服務資訊清單中的連接埠號碼或連接埠名稱 {port} 是服務連接埠號碼。 服務連接埠 {port} 的健全狀態探查明確通訊協定將覆寫預設值（如果設定的話）。
service.beta.kubernetes.io/port_{port}_health-probe_interval 健全狀態探查間隔 {port} 是服務連接埠號碼。
service.beta.kubernetes.io/port_{port}_health-probe_num-of-probe 健全狀態探查的狀況不良回應最小值 {port} 是服務連接埠號碼。
service.beta.kubernetes.io/port_{port}_health-probe_request-path 健全狀態探查的要求路徑 {port} 是服務連接埠號碼。

如此處所述，Tcp、Http 和 Https 是負載平衡器服務支援的三種通訊協定。

目前健全狀態探查的預設通訊協定會因不同的傳輸通訊協定、應用程式通訊協定、註釋和外部流量原則而有所不同。

  1. 若是本機服務，會使用 HTTP 和 /healthz。 健全狀態探查將查詢 NodeHealthPort 而不是實際的後端服務
  2. 若是叢集 TCP 服務，會使用 TCP。
  3. 若是叢集 UDP 服務，不會進行健全狀態探查。

注意

本機服務若啟用了 PLS 整合和 PLS Proxy 通訊協定，預設 HTTP+/healthz 健全狀態探查將不會運作。 因此可以像叢集服務一樣自訂健全狀態探查，以支援這種情節。

我們自 v1.20 起已引進服務註釋 service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path 來判斷健全狀態探查行為。

  • 若叢集 < =1.23，只有在也設定了 service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path 時，才會將 spec.ports.appProtocol 當作探查通訊協定。
  • 若叢集 > 1.24，將把 spec.ports.appProtocol 當作探查通訊協定，/ 當作預設探查要求路徑（可使用 service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path 以變更為不同的要求路徑）。

請注意，使用 TCP 或 spec.ports.appProtocol 空白時，會忽略要求路徑。 更明確地說：

loadbalancer sku externalTrafficPolicy spec.ports.Protocol spec.ports.AppProtocol service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path 負載平衡器探查通訊協定 負載平衡器探查要求路徑
standard 本機 任意 任意 任意 HTTP /healthz
standard 叢集 udp 任意 任意 null null
standard 叢集 tcp （已忽略） tcp null
standard 叢集 tcp tcp （已忽略） tcp null
standard 叢集 tcp http/https TCP（<=1.23） 或 http/https（>=1.24） null（<=1.23） 或 /（>=1.24）
standard 叢集 tcp http/https /custom-path http/https /custom-path
standard 叢集 tcp 不支援的通訊協定 /custom-path tcp null
basic 本機 任意 任意 任意 HTTP /healthz
basic 叢集 tcp （已忽略） tcp null
basic 叢集 tcp tcp （已忽略） tcp null
basic 叢集 tcp HTTP TCP（<=1.23） 或 http/https（>=1.24） null（<=1.23） 或 /（>=1.24）
basic 叢集 tcp HTTP /custom-path HTTP /custom-path
basic 叢集 tcp 不支援的通訊協定 /custom-path tcp null

我們自 v1.21 起已引進服務註釋 service.beta.kubernetes.io/azure-load-balancer-health-probe-interval 和 load-balancer-health-probe-num-of-probe，並自訂健全狀態探查的設定。 若未設定 service.beta.kubernetes.io/azure-load-balancer-health-probe-interval，將套用預設值 5。 若未設定 load-balancer-health-probe-num-of-probe，將套用預設值 2。 總探查應少於 120 秒。

連接埠的自訂 Load Balancer 健全狀態探查

服務中不同的連接埠可能需要不同的健全狀態探查設定。 這可能是因為服務設計（例如控制多個連接埠的單一健康情況端點）或 Kube 功能（例如 MixedProtocolLBService）。

以下註釋可用於自訂每個服務連接埠的探查設定。

連接埠專用註釋 全域探查註釋 使用方式
service.beta.kubernetes.io/port_{port}_no_lb_rule N/A（全域沒有對等項目） 若設為 true，將不會產生 lb 規則和探查規則
service.beta.kubernetes.io/port_{port}_no_probe_rule N/A（全域沒有對等項目） 若設為 true，將不會產生探查規則
service.beta.kubernetes.io/port_{port}_health-probe_protocol N/A（全域沒有對等項目） 設定這個服務連接埠的健全狀態探查通訊協定（例如 Http、Https、Tcp）
service.beta.kubernetes.io/port_{port}_health-probe_port N/A（全域沒有對等項目） 設定這個服務連接埠的健全狀態探查（例如 15021）
service.beta.kubernetes.io/port_{port}_health-probe_request-path service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path 若是 Http 或 Https，請設定健全狀態探查要求路徑。 預設為 /
service.beta.kubernetes.io/port_{port}_health-probe_num-of-probe service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe 連續探查連接埠失敗幾數，才將其視為狀況不良。
service.beta.kubernetes.io/port_{port}_health-probe_interval service.beta.kubernetes.io/azure-load-balancer-health-probe-interval 探查嘗試間隔的時間長度

以下資訊清單中，httpsserver 連接埠的探測規則與 httpserver 的探測規則不同，因為 httpsserver 連接埠指定了註釋。

apiVersion: v1
kind: Service
metadata:
  name: appservice
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe: "5"
    service.beta.kubernetes.io/port_443_health-probe_num-of-probe: "4"
spec:
  type: LoadBalancer
  selector:
    app: server
  ports:
    - name: httpserver
      protocol: TCP
      port: 80
      targetPort: 30102
    - name: httpsserver
      protocol: TCP
      appProtocol: HTTPS
      port: 443
      targetPort: 30104

在這個資訊清單中，HTTP 連接埠使用不同的節點連接埠，在 /healthz 上的 10256 連接埠進行 HTTP 整備檢查（kube-proxy 的 healthz 端點）。

apiVersion: v1
kind: Service
metadata:
  name: istio
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
    service.beta.kubernetes.io/port_443_health-probe_protocol: "http"
    service.beta.kubernetes.io/port_443_health-probe_port: "10256"
    service.beta.kubernetes.io/port_443_health-probe_request-path: "/healthz"
spec:
  ports:
    - name: https
      protocol: TCP
      port: 443
      targetPort: 8443
      nodePort: 30104
      appProtocol: https
  selector:
    app: istio-ingressgateway
    gateway: istio-ingressgateway
    istio: ingressgateway
  type: LoadBalancer
  sessionAffinity: None
  externalTrafficPolicy: Local
  ipFamilies:
    - IPv4
  ipFamilyPolicy: SingleStack
  allocateLoadBalancerNodePorts: true
  internalTrafficPolicy: Cluster

在這個資訊清單中，HTTP 連接埠使用不同的健全狀態探查端點，在 /healthz/ready 上的 30000 連接埠進行 HTTP 整備檢查。

apiVersion: v1
kind: Service
metadata:
  name: istio
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
    service.beta.kubernetes.io/port_443_health-probe_protocol: "http"
    service.beta.kubernetes.io/port_443_health-probe_port: "30000"
    service.beta.kubernetes.io/port_443_health-probe_request-path: "/healthz/ready"
spec:
  ports:
    - name: https
      protocol: TCP
      port: 443
      targetPort: 8443
      appProtocol: https
  selector:
    app: istio-ingressgateway
    gateway: istio-ingressgateway
    istio: ingressgateway
  type: LoadBalancer
  sessionAffinity: None
  externalTrafficPolicy: Local
  ipFamilies:
    - IPv4
  ipFamilyPolicy: SingleStack
  allocateLoadBalancerNodePorts: true
  internalTrafficPolicy: Cluster

針對 SNAT 進行疑難排解

如果您對相同的目的地的 IP 位址和連接埠，啟動了多個輸出 TCP 或 UDP 連接，且觀察到失敗的輸出連接，或者支援人員告知您 SNAT 連接埠 (PAT 使用的預先配置暫時性連接埠) 即將耗盡，有幾個一般選項可緩解這個問題。 請檢閱這些選項並判斷哪一個最適合您的案例。 可能會有一或多個選項適合管理您的情節。 如需詳細資訊，請檢閱針對輸出連線進行疑難排解指南。

SNAT 耗盡的根本原因通常是輸出連線能力的建立、管理，或可設定計時器的預設值變更而形成的反向模式。 請仔細檢閱這一節。

步驟

  1. 檢查您的連線是否長時間保持閒置，並依賴預設閒置逾時來釋放該連接埠。 若是如此，您的案例可能需要減少預設逾時 30 分鐘。
  2. 調查您的應用程式如何建立輸出連線能力（例如程式碼檢閱或封包擷取）。
  3. 判斷此活動是否為預期的行為，或應用程式是否運作不正常。 使用 Azure 監視器中的計量和記錄來證實您的發現。 例如，針對 SNAT 連線計量，使用「失敗」類別。
  4. 評估是否遵循適當的模式。
  5. 評估是否應藉由更多輸出 IP 位址 + 更多配置的輸出連接埠，緩解 SNAT 連接埠耗盡的問題。

設計模式

盡可能重複使用連接和連接集區。 這些模式可避免資源耗盡問題，並產生可預測的行為。 您可以在許多開發程式庫和架構中找到這些模式的基元。

  • 不可部分完成的要求 (每個連接一個要求)，一般而言不是好的設計選擇。 這種反向模式會限制擴充、降低效能，減少可靠性。 相反地，應重複使用 HTTP/S 連線以減少連線數目和關聯的 SNAT 連接埠。 使用 TLS 會減少交握、負荷和密碼編譯作業成本，應用程式得以擴充並提升效能。
  • 如果您正在使用叢集/自訂 DNS，或 coreDNS 上的自訂上游伺服器，請記住，DNS 可以在用戶端未快取 DNS 解析程式結果時，在磁碟區導入許多個別流程。 請先自訂 coreDNS（不要使用自訂 DNS 伺服器），並定義良好的快取值。
  • UDP 流程（例如 DNS 查閱）會在閒置逾時期間配置 SNAT 連接埠。 閒置的逾時時間愈長，SNAT 連接埠上的壓力愈高。 使用較短的閒置逾時（例如 4 分鐘）。
  • 使用連接集區來塑造您的連線磁碟區。
  • 永遠不要以無訊息方式放棄 TCP 流程，並依賴 TCP 計時器來清除流程。 如果您未讓 TCP 明確關閉連接，系統仍會在中繼系統和端點中配置狀態，且不讓其他連接使用 SNAT 連接埠。 此模式可能會觸發應用程式失敗和 SNAT 耗盡的問題。
  • 在沒有從專業角度了解可能產生的影響時，請勿變更 作業系統層級 TCP 關閉相關的計時器值。 雖然 TCP 堆疊可復原，但連接端點的表現不如預期時，將連帶影響應用程式效能。 變更計時器的需求通常是基礎設計出現問題的信號。 請檢閱下列建議。

從基本 SKU 負載平衡器移至標準 SKU

若現有的叢集有基本 SKU 負載平衡器，移轉到標準 SKU 負載平衡器時需注意一些行為上的重要差異。

舉例而言，若叢集的型別是 load-balancer-sku，常見的做法是採取藍／綠部署以移轉叢集，而且只能在叢集建立時定義。 但基本 SKU 負載平衡器使用基本 SKU IP 位址，該位址與標準 SKU 負載平衡器不相容。 標準 SKU 負載平衡器需要標準 SKU IP 位址。 若要移轉叢集以升級負載平衡器 SKU，您要有新的 IP 位址和相容的 IP 位址 SKU。

如需深入瞭解移轉叢集的注意事項，請造訪我們移轉注意事項的相關文件。

限制

您建立和管理可支援「標準」SKU 負載平衡器的 AKS 叢集時，需遵守下列限制：

  • 必須至少有一個公用 IP 或 IP 首碼，才能允許來自 AKS 叢集的輸出流量。 需要公用 IP 或 IP 首碼，以維持控制平面和代理程式節點之間的連線能力，同時維持與舊版 AKS 的相容性。 可使用下列選項來指定「標準」SKU 負載平衡器的公用 IP 或 IP 首碼：
    • 提供您自己的公用 IP。
    • 提供您自己的公用 IP 首碼。
    • 指定一個 100 以內的數字，以允許 AKS 叢集在與 AKS 叢集相同的資源群組中建立相同數量的標準 SKU 公用 IP。 這個資源群組通常以 MC_ 開頭命名。 AKS 會將公用 IP 指派給「標準」SKU 負載平衡器。 如果未指定公用 IP、公用 IP 前置或 IP 數量，預設會在 AKS 叢集所在的同一個資源群組中自動建立一個公用 IP。 請務必允許公用位址，並避免建立任何禁止 IP 建立的 Azure 原則。
  • AKS 所建立的公用 IP 無法重複使用為自訂自備公用 IP 位址。 使用者必須建立和管理所有自訂 IP 位址。
  • 只有在建立 AKS 叢集時，才可以定義負載平衡器 SKU。 建立 AKS 叢集之後，就無法變更負載平衡器 SKU。
  • 在單一叢集中，只能使用一種類型的負載平衡器 SKU (基本或標準)。
  • 「標準」SKU 負載平衡器只支援「標準」SKU IP 位址。

下一步

如需深入了解 Kubernetes 服務，請參閱 Kubernetes 服務文件。

若要了解有關使用內部負載平衡器處理輸入流量的詳細資訊，請參閱 AKS 內​​部負載平衡器文件。