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

經典基礎架構

您可透過在服務組態檔案中將 externalTrafficPolicy 變更為 Local 來已啟用的輸入 ALB 的來源 IP 保留服務。不過，沒有任何資料流量到達您應用程式的後端服務。

當您啟用 Ingress ALB 服務的來源 IP 保留時，會保留用戶端要求的來源 IP 位址。服務只會將資料流量轉遞至相同工作者節點上的應用程式 Pod，以確保要求封包的 IP 位址未變更。

通常，Ingress ALB 服務 Pod 會部署到與應用程式 Pod 相同的工作節點上。但是，在某些情況下，服務 Pod 和應用程式 Pod 可能無法排程在同一個 Worker 節點上。如果您在 Worker 節點上使用 Kubernetes 污點，則會阻止任何沒有污點容忍度的 Pod 在有污點的 Worker 節點上執行。來源 IP 保留可能無法運作，這取決於您使用的污點類型：

邊緣節點污點：您將 dedicated=edge 標籤新增到群集中每個公用 VLAN 上的兩個或更多工作站節點，以確保 Ingress pod 只能部署到這些工作站節點。然後，您也可以為邊緣節點加上污點，以防止在邊緣節點上執行任何其他工作負載。不過，您未將邊緣節點親緣性規則及容忍新增至應用程式部署。您的應用程式 Pod 無法排定於與服務 Pod 相同的有污點節點，而且沒有任何資料流量會到達您應用程式的後端服務。
自訂污點：您已在數個節點上使用自訂污點，因此只會將具有該污點容忍的應用程式 Pod 部署至那些節點。您在應用程式和 Ingress 服務的部署中加入了親和性規則和容忍度，因此它們的 Pod 只能部署到這些節點。但是，在 ibm-system 命名空間中自動建立的 ibm-cloud-provider-ip keepalived pod 可確保 ALB pod 和應用程式 pod 總是排程到相同的 Worker 節點上。這些 keepalived Pod 沒有您所使用之自訂污點的容忍。它們無法排定於應用程式 Pod 執行所在的相同有污點節點，而且沒有任何資料流量會到達您應用程式的後端服務。

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

邊緣節點污點：若要確保您的 ALB 和應用程式 Pod 部署到有污點的邊緣節點，請在應用程式部署中加入邊緣節點親和性規則和容忍度。 Ingress ALB pod 預設有這些親和性規則和容忍度。
自訂污點：移除 keepalived Pod 沒有其容忍的自訂污點。相反地，您可以將工作者節點標示為邊緣節點，然後為這些邊緣節點加上污點。

如果您完成了前面的步驟，但 keepalived pod 仍未排程，請收集有關 keepalived pod 的更多資訊：

取得 keepalived Pod。
```
kubectl get pods -n ibm-system
```

在輸出中，尋找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>

描述每個 keepalived pod 並檢視「活動」部份。處理任何列出的錯誤或警告訊息。
```
kubectl describe pod ibm-cloud-provider-ip-169-61-XX-XX-55967b5b8c-7zv9t -n ibm-system
```