经典集群: 为何在使用污点节点时源 IP 保留失败?

经典基础设施

在为输入 ALB 启用源 IP 保护服务配置文件中将 externalTrafficPolicy 更改为 Local。但是，没有流量到达应用程序的后端服务。

为入口 ALB 服务启用源 IP 保留后，客户端请求的源 IP 地址将被保留。服务仅将流量转发至同一工作程序节点上的应用程序 pod，以确保请求包的 IP 地址不变。

通常，Ingress ALB 服务 pod 与应用程序 pod 部署在相同的工作节点上。不过，在某些情况下，服务 pod 和应用程序 pod 可能不会调度在同一个工作节点上。如果在工作节点上使用 Kubernetes 污点，则会阻止任何没有污点容忍度的 pod 在有污点的工作节点上运行。源 IP 保留可能不起作用，这取决于您使用的污点类型：

边缘节点污点：您将 dedicated=edge 标签添加到群集中每个公共 VLAN 上的两个或多个工作节点，以确保入口 pod 仅部署到这些工作节点。然后，您还污染了这些边缘节点，以防止其他任何工作负载在边缘节点上运行。但是，您未将边缘节点亲缘关系规则和容忍度添加到应用程序部署。因此，应用程序 pod 无法安排在服务 pod 所在的有污点节点上，所以没有任何流量到达应用程序的后端服务。
定制污点：您在多个节点上使用了定制污点，以便只有具有该污点容忍度的应用程序 pod 可以部署到这些节点。您在应用程序和 Ingress 服务的部署中添加了亲和规则和容忍度，这样它们的 pod 就只能部署到这些节点上。不过，在 ibm-system 命名空间中自动创建的 ibm-cloud-provider-ip keepalived pod 可确保 ALB pod 和应用程序 pod 始终调度到同一个工作节点上。这些 keepalived pod 没有您使用的定制污点的容忍度。因此，这些 pod 无法安排在运行应用程序 pod 的有污点节点上，所以没有任何流量到达应用程序的后端服务。

通过选择下列其中一个选项来解决此问题：

边缘节点污点：为确保 ALB 和应用程序 pod 部署到有污点的边缘节点，请在应用程序部署中添加边缘节点亲和性规则和容忍度。入口 ALB pod 默认具有这些亲和规则和容忍度。
定制污点：除去 keepalived pod 没有其容忍度的定制污点。可以改为将工作程序节点标注为边缘节点，然后污染这些边缘节点。

如果完成了前面的步骤，但 keepalived pod 仍未调度，请收集有关 keepalived pod 的更多信息：

获取 keepalived pod。
```
kubectl get pods -n ibm-system
```

在输出中，查找 ibm-cloud-provider-ipStatus** 为 ** 的 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
```