標準：關於網路負載平衡器 (NLB)

網路負載平衡器只能在傳統群集中建立。 若要平衡 VPC 叢集裡的負載，請參閱使用 VPC 的負載平衡器公開應用程式。

當您建立標準叢集時，Red Hat® OpenShift® on IBM Cloud® 會自動佈建 1 個可攜式公用子網路及 1 個可攜式專用子網路。

  • 可攜式公用子網路提供 5 個可用的 IP 位址。預設 公用 Ingress ALB 使用 1 個可攜式公用 IP 位址。 藉由建立公用網路負載平衡器服務或 NLB，即可使用其餘 4 個可攜式公用 IP 位址，將單一應用程式公開至網際網路。
  • 可攜式專用子網路提供 5 個可用的 IP 位址。預設專用 Ingress ALB 使用 1 個可攜式專用 IP 位址。 藉由建立專用負載平衡器服務或 NLB，即可使用其餘 4 個可攜式專用 IP 位址，將單一應用程式公開至專用網路。

若要使應用程式可同時透過可攜式公用 IP 位址和可攜式專用 IP 位址進行存取，必須一併建立公用 NLB 和專用 NLB。 可攜式公用和私有 IP 位址是靜態浮動 IP，不會在移除 Worker 節點時改變。 如果 NLB IP 位址所在的工作站節點被移除，持續監控 IP 的 Keepalive 守護程式會自動將 IP 移至另一個工作站節點。 您可以將任何埠指派給 NLB。 NLB 服務是作為應用程式送入要求的外部進入點。 要從網際網路存取 NLB，您可以使用 NLB 的公用 IP 位址和指定的連接埠，格式為 <IP_address>:<port>。 您也可以使用子網域登錄 NLB IP 位址，來建立 NLB 的 DNS 項目。

當您使用 NLB 服務公開應用程式時，也會透過服務的 NodePort 自動讓您的應用程式可供使用。 叢集內每個工作者節點的每個公用及專用 IP 位址上都可以存取 NodePort。 若要在使用 NLB 時封鎖流向 NodePort 的資料流量，請參閱控制網路負載平衡器 (NLB) 或 NodePort 服務的入埠資料流量。

雖然在 Kubernetes 社群版本中已正式發行 Kubernetes SCTP 通訊協定，但在 IBM Cloud Kubernetes Service 叢集裡不支援建立使用此通訊協定的負載平衡器。

1.0 版和 2.0 版 NLB 中基本負載平衡和 DSR 負載平衡的比較

建立 NLB 時，可以選擇 1.0 版 NLB（執行基本負載平衡）或 2.0 版 NLB（執行直接伺服器傳回 (DSR) 負載平衡）。

1.0 與 2.0 NLB 版本有何相似之處？
1.0 和 2.0 版 NLB 都是在 Linux 核心空間中存在的第 4 層負載平衡器。 這兩個版本都在叢集內執行，並使用工作者節點資源。 因此，NLB 的可用容量一律為您自己的叢集所專用。 此外，兩個版本的 NLB 都不會終止連線。 相反地，它們會將連線轉遞至應用程式 Pod。
1.0 和 2.0 NLB 版本有何不同？
當用戶端將要求傳送至您的應用程式時，NLB 會將要求封包遞送至應用程式 Pod 所在的工作者節點 IP 位址。 1.0 版 NLB 會使用網址轉換 (NAT)，將要求封包的來源 IP 位址重寫為負載平衡器 Pod 所在之工作者節點的 IP。 當工作者節點傳回應用程式回應封包時，會使用 NLB 所在的工作者節點 IP。 然後，NLB 必須將回應封包傳送至用戶端。 若要防止 IP 位址重寫，您可以啟用來源 IP 保留。 不過，來源 IP 保留需要負載平衡器 Pod 和應用程式 Pod 在相同的工作者節點上執行，以便要求不需要轉遞至另一個工作者節點。 您必須將節點親緣性及容忍新增至應用程式 Pod。 如需使用 1.0 版 NLB 進行基本負載平衡的相關資訊，請參閱 NLB 1.0 的元件和架構。

相對於 1.0 版 NLB，2.0 版 NLB 在轉遞要求至其他工作者節點上的應用程式 Pod 時，不會使用 NAT。 NLB 2.0 遞送用戶端要求時，會使用 IP-over-IP (IPIP) 將原始要求封包封裝到另一個封包中。 此封裝 IPIP 封包具有負載平衡器 Pod 所在之工作者節點的來源 IP，如此可讓原始要求封包保留用戶端 IP 作為其來源 IP 位址。 然後，工作者節點會使用直接伺服器傳回 (DSR)，將應用程式回應封包傳送至用戶端 IP。 回應封包會跳過 NLB，並直接傳送至用戶端，因而可減少 NLB 必須處理的資料流量。 如需有關使用 2.0 NLB 版本的 DSR 負載平衡的詳細資訊，請參閱 NLB 的元件與架構 2.0。

NLB 1.0 的元件和架構

TCP/UDP 網路負載平衡器 (NLB) 1.0 使用 Iptables（Linux 核心特性）在應用程式的各 Pod 中對要求進行負載平衡。

單一區域叢集裡的資料傳輸流

下圖顯示 NLB 1.0 如何將通訊從網際網路導向至單一區域叢集裡的應用程式。

使用 NLB 1.0在單一區域叢集裡公開應用程式。
使用 NLB 1.0在單專區叢集中公開應用程式

  1. 應用程式的要求使用 NLB 的公用 IP 位址及工作者節點上的已指派埠。 請注意，如果您為 NLB 建立 DNS 子網域，則使用者可以改為透過 NLB 的子網域來存取您的應用程式。 DNS 系統服務會將子網域解析為 NLB 的可攜式公用 IP 位址。

  2. NLB 會接收要求，並將它透過專用網路轉遞至應用程式 Pod 的專用 IP 位址。 請求套件的來源 IP 位址會變更為 NLB Pod 執行所在 Worker 節點的公用 IP 位址。 如果叢集裡已部署多個應用程式實例，則 NLB 會在應用程式 Pod 之間遞送要求。

  3. 應用程式傳回回應封包時，會使用已轉遞用戶端要求之 NLB 所在的工作者節點的 IP 位址。 然後，NLB 會將回應封包傳送至用戶端。

多區域叢集裡的資料傳輸流

下圖顯示網路負載平衡器 (NLB) 1.0 如何將通訊從網際網路導向至多區域叢集裡的應用程式。

使用 NLB 1.0在多區域群集中對應用程式進行負載平衡
使用 NLB 1.0在多區域群集中對應用程式進行負載平衡

  1. 應用程式的要求使用 NLB 的 DNS 子網域。 您也可以使用工作者節點上的公用 IP 位址及埠，來存取每個區域中的 NLB。 請注意，依預設，每個 NLB 1.0 都只會設定在某個區域中。 若要達到高可用性，必須在您具有應用程式實例的每個區域中部署 NLB 1.0。

  2. DNS 系統服務會將子網域解析為其中一個 NLB 的可攜式公用 IP 位址，以及它在工作者節點上的已指派埠。 各種區域中的 NLB 會以循環式週期處理要求。

  3. NLB 會接收要求，並將它透過專用網路轉遞至應用程式 Pod 的專用 IP 位址。 請求套件的來源 IP 位址會變更為 NLB Pod 執行所在 Worker 節點的公用 IP 位址。 每個 NLB 都會將要求遞送至其專屬區域中的應用程式實例，以及遞送至其他區域中的應用程式實例。 此外，如果將多個應用程式實例部署至一個區域，則 NLB 會在區域的應用程式 Pod 之間遞送要求。

  4. 應用程式傳回回應封包時，會使用已轉遞用戶端要求之 NLB 所在的工作者節點的 IP 位址。 然後，NLB 會將回應封包傳送至用戶端。

NLB 的元件與架構 2.0

NLB 2.0 是使用 Linux 核心的「IP 虛擬伺服器 (IPVS)」的第 4 層負載平衡器。 NLB 2.0 支援 TCP 和 UDP、在多個工作者節點的前面執行，並使用 IP over IP (IPIP) 通道作業，將到達單一 NLB IP 位址的資料流量分散到那些工作者節點。

單一區域叢集裡的資料傳輸流

下圖顯示 NLB 2.0 如何將通訊從網際網路導向至單一區域叢集裡的應用程式。

使用2.0版 NLB 在Red Hat OpenShift on IBM Cloud中公開應用程式
使用2.0版 NLB 在Red Hat OpenShift on IBM Cloud中公開應用程式

  1. 應用程式的用戶端要求會使用 NLB 的公用 IP 位址及工作者節點上的已指派埠。 在此範例中，NLB 的虛擬 IP 位址為 169.61.23.130，執行於具有專用 IP 位址 10.73.13.25 的工作者節點上。 請注意，如果您為 NLB 建立 DNS 子網域，則使用者可以改為透過 NLB 的子網域來存取您的應用程式。 DNS 系統服務會將子網域解析為 NLB 的可攜式公用 IP 位址。

  2. NLB 會在 IPIP 封包（標示為 "IPIP"）內封裝用戶端要求封包（在映像檔中標示為 "CR"）。 用戶端要求封包會將用戶端 IP 保留為其來源 IP 位址。 IPIP 封裝封包會使用工作者節點 10.73.14.25 IP 作為其來源 IP 位址。

  3. NLB 會將 IPIP 封包遞送至應用程式 Pod 所在且具有專用 IP 位址 10.73.13.26 的工作者節點。 如果叢集裡已部署多個應用程式實例，則 NLB 會在應用程式 Pod 部署所在的工作者節點之間遞送要求。

  4. 工作者節點 10.73.14.26 會解壓縮 IPIP 封裝封包，然後解壓縮用戶端要求封包。 用戶端要求封包會轉遞至該工作者節點上的應用程式 Pod。

  5. 然後，工作者節點 10.73.14.26 會使用來自原始要求封包的來源 IP 位址（用戶端 IP），將應用程式 Pod 的回應封包直接傳回給用戶端。

多區域叢集裡的資料傳輸流

下圖顯示每個區域中的 2.0 版 NLB 如何將網際網路中的資料流量導向至多區域叢集裡的應用程式。

使用 NLB 2.0 在Red Hat OpenShift on IBM Cloud中公開應用程式
使用 NLB 2.0在Red Hat OpenShift on IBM Cloud中公開應用程式

  1. 應用程式的要求使用 NLB 的 DNS 子網域。 您也可以使用工作者節點上的公用 IP 位址及埠，來存取每個區域中的 NLB。 請注意，依預設，每個 NLB 2.0 都只會設定在某個區域中。 若要達到高可用性，必須在您具有應用程式實例的每個區域中部署 NLB 2.0。

  2. DNS 系統服務會將子網域解析為其中一個 NLB 的可攜式公用 IP 位址，以及它在工作者節點上的已指派埠。 在此範例中，NLB 的虛擬 IP 位址為 169.61.23.130，執行於具有專用 IP 位址 10.73.13.25 的工作者節點上。 各種區域中的 NLB 會以循環式週期處理要求。

  3. NLB 會在 IPIP 封包（標示為 "IPIP"）內封裝用戶端要求封包（在映像檔中標示為 "CR"）。 用戶端要求封包會將用戶端 IP 保留為其來源 IP 位址。 IPIP 封裝封包會使用工作者節點 10.73.14.25 IP 作為其來源 IP 位址。

  4. NLB 會將 IPIP 封包遞送至應用程式 Pod 所在且具有專用 IP 位址 10.73.13.26 的工作者節點。 請注意，每個 NLB 都會將要求遞送至其專屬區域中的應用程式實例，以及遞送至其他區域中的應用程式實例。 此外，如果將多個應用程式實例部署至一個區域，則 NLB 會在區域的應用程式 Pod 之間遞送要求。

  5. 工作者節點 10.73.14.26 會解壓縮 IPIP 封裝封包，然後解壓縮用戶端要求封包。 用戶端要求封包會轉遞至該工作者節點上的應用程式 Pod。

  6. 然後，工作者節點 10.73.14.26 會使用來自原始要求封包的來源 IP 位址（用戶端 IP），將應用程式 Pod 的回應封包直接傳回給用戶端。