为什么 Istio 入口网关的 ibm-cloud-provider-ip pod 卡在 pending 中?

虚拟私有云 经典基础架构

仅多专区集群

运行 kubectl get pod -n ibm-system 时，为 Istio 入口网关提供外部 IP 地址的 ibm-cloud-provider-ip pod 将陷入 pending 状态。

此外，针对 ibm-cloud-provider-ip pod 运行 kubectl describe pod <pod_name> -n ibm-system 时，您会在输出的 pod 的事件部分中注意到调度冲突错误。

要标识网关的 ibm-cloud-provider-ip pod，您可以运行 kubectl get service -n istio-system 以查找网关的负载均衡器服务，记下其 EXTERNAL-IP，并在 ibm-cloud-provider-ip pod 名称中查找 IP 地址。

创建 istio-ingressgateway 负载均衡器服务时，将创建 ibm-cloud-provider-ip pod 以向负载均衡器提供外部 IP 地址。

这些 ibm-cloud-provider-ip pod 具有节点亲缘关系规则，以便在派生 IP 地址的子网所在的专区中创建这些 pod。 但是，当 istio-ingressgateway 负载均衡器服务的 ExternalTrafficPolicy 设置设置为 Local 时，ibm-cloud-provider-ip pod 还具有要部署到与网关负载均衡器 pod 相同的区域的 pod 亲缘关系规则。 如果 IP 地址和网关负载均衡器存在于集群中的不同专区中，那么 ibm-cloud-provider-ip pod 无法正确部署。

要验证 ibm-cloud-provider-ip 和 istio-ingressgateway pod 是否不存在于同一区域中，请执行以下操作:

1. 标识 istio-ingressgateway pod 部署到的 NODE。

   kubectl get pod -n istio-system -o wide
   

2. 获取网关负载均衡器服务的外部IP地址。

   kubectl get service -n istio-system
   

3. 标识要将负载均衡器的 ibm-cloud-provider-ip pod 部署到的 NODE。 请将 <IP-with-hyphens> 替换为在上一步骤中找到的IP地址。 在 IP 地址中，使用连字符 (-) 代替句点 (.)。例如，169.12.345.67 变为 169-12-345-67。

   kubectl get pod -n ibm-system -o wide -l ibm-cloud-provider-ip=<IP-with-hyphens>
   

4. 列出工作程序节点所在的区域。 比较在步骤 1 和 3 中找到的工作程序节点，以确定是否将 pod 部署到不同区域中的工作程序节点。

   kubectl get node --no-headers -L ibm-cloud.kubernetes.io/zone
   

   示例输出

   10.176.48.106   Ready   <none>   529d    v1.32+IKS   dal10
   10.176.48.107   Ready   <none>   196d    v1.32+IKS   dal10
   10.184.58.23    Ready   <none>   2y38d   v1.32+IKS   dal12
   10.184.58.42    Ready   <none>   529d    v1.32+IKS   dal12
   

要解决此问题，您可以将 istio-ingressgateway pod 移至 ibm-cloud-provider-ip pod 所在的区域，反之亦然。

• 移动 istio-ingressgateway pod: 网关的负载均衡器在移动后保留相同的外部 IP 地址。 但是，在附加组件的 V 1.9 和更低版本中，当在 Istio 补丁更新期间自动填充网关的区域标签时，可能会覆盖您所做的更改。
• 移动 ibm-cloud-provider-ip pod: 网关 在移动后不会 保留相同的外部 IP 地址，并且会为其分配新的 IP 地址。 但是，在附加组件更新期间不会覆盖任何更改。