標準叢集: 使用污染的節點時，為何來源 IP 保留會失敗?

經典基礎架構

在傳統群集中使用汙染節點時，來源 IP 保存會失敗，導致流量無法到達您的應用程式。

在經典群集中，您透過在服務的設定檔中將 externalTrafficPolicy 變更為 Local，來啟用 1.0 負載平衡器 服務的來源 IP 保留。 不過，沒有任何資料流量到達您應用程式的後端服務。

當您啟用負載平衡器服務的來源 IP 保留時，客戶端要求的來源 IP 位址會被保留。

服務只會將資料流量轉遞至相同工作者節點上的應用程式 Pod，以確保要求封包的 IP 位址未變更。 通常，負載平衡服務 pod 會部署到與應用程式 pod 部署到相同的 Worker 節點上。 不過，存在某些狀況，可能未在相同的工作者節點上排定服務 Pod 及應用程式 Pod。 如果您在 Worker 節點上使用 Kubernetes 污點，則會阻止任何沒有污點容忍度的 Pod 在有污點的 Worker 節點上執行。 來源 IP 保留可能無法根據您使用的污點類型來運作：

• 邊緣節點污點：您在群集中每個公用 VLAN 上的兩個或更多工作站節點上 新增了 dedicated=edge 標籤，以確保負載平衡器 pod 只能部署到這些工作站節點。 然後，您也可以為邊緣節點加上污點，以防止在邊緣節點上執行任何其他工作負載。 不過，您未將邊緣節點親緣性規則及容忍新增至應用程式部署。 您的應用程式 Pod 無法排定於與服務 Pod 相同的有污點節點，而且沒有任何資料流量會到達您應用程式的後端服務。

• 自訂污點：您已在數個節點上使用自訂污點，因此只會將具有該污點容忍的應用程式 Pod 部署至那些節點。 您在應用程式和負載平衡服務的部署中加入了親和性規則和容忍度，因此它們的 Pod 只能部署到這些節點。 但是，在 ibm-system 命名空間中自動建立的 ibm-cloud-provider-ip keepalived Pod 可確保負載平衡器和應用程式 Pod 始終被排程到相同的 Worker 節點上。 這些 keepalived Pod 沒有您所使用之自訂污點的容忍。 它們無法排定於應用程式 Pod 執行所在的相同有污點節點，而且沒有任何資料流量會到達您應用程式的後端服務。

選擇下列其中一個選項，以解決問題：

邊緣節點污點：若要確保您的負載平衡器及應用程式 Pod 部署至有污點的邊緣節點，請將邊緣節點親緣性規則及容忍新增至應用程式部署。 負載平衡器 Pod 預設有這些親和性規則和容忍度。

自訂污點：移除 keepalived Pod 沒有其容忍的自訂污點。 相反地，您可以將工作者節點標示為邊緣節點，然後為這些邊緣節點加上污點。

如果您完成前述其中一個選項，但 keepalived Pod 仍未排程，您可以取得 keepalived Pod 的更多資訊：

1. 取得 keepalived Pod。

   oc get pods -n ibm-system
   

2. 在輸出中，尋找ibm-cloud-provider-ip狀態**為 ** 的 Pending Pod。 範例：

   ibm-cloud-provider-ip-169-61-XX-XX-55967b5b8c-7zv9t     0/1       Pending   0          2m        <none>          <none>
   ibm-cloud-provider-ip-169-61-XX-XX-55967b5b8c-8ptvg     0/1       Pending   0          2m        <none>          <none>
   

3. 說明每個 keepalived Pod，並尋找事件區段。 請解決列出的所有錯誤或警告訊息。

   oc describe pod ibm-cloud-provider-ip-169-61-XX-XX-55967b5b8c-7zv9t -n ibm-system
   

4. 解決問題後，請檢查負載平衡器服務端點，確認流量是否到達您的應用程式。

   oc get svc -o wide