¿Por qué los pods ibm-cloud-provider-ip para la pasarela de entrada de Istio se atasca en pending?

Nube privada virtual Infraestructura clásica

Solo clústeres multizona

Cuando se ejecuta kubectl get pod -n ibm-system, el pod ibm-cloud-provider-ip que proporciona la dirección IP externa para la pasarela de Ingress de Istio se atasca en el estado pending.

Además, al ejecutar kubectl describe pod <pod_name> -n ibm-system para el pod ibm-cloud-provider-ip, se observa un error de conflicto de planificación en la sección de sucesos del pod de la salida.

Para identificar el pod ibm-cloud-provider-ip para la pasarela, puede ejecutar kubectl get service -n istio-system para encontrar el servicio de equilibrador de carga de la pasarela, anotar su EXTERNAL-IPy buscar la dirección IP en el nombre de pod ibm-cloud-provider-ip.

Cuando se crea un servicio de equilibrador de carga istio-ingressgateway, se crea un pod ibm-cloud-provider-ip para proporcionar una dirección IP externa al equilibrador de carga.

Estos pods ibm-cloud-provider-ip tienen una regla de afinidad de nodo para que se creen en la misma zona que la subred de la que se obtiene la dirección IP. Sin embargo, cuando el valor ExternalTrafficPolicy para el servicio de equilibrador de carga istio-ingressgateway se establece en Local, el pod ibm-cloud-provider-ip también tiene una regla de afinidad de pod que se debe desplegar en la misma zona que el pod del equilibrador de carga de pasarela. Si la dirección IP y el equilibrador de carga de pasarela existen en distintas zonas del clúster, el pod ibm-cloud-provider-ip no se puede desplegar correctamente.

Para verificar que los pods ibm-cloud-provider-ip y istio-ingressgateway no existen en la misma zona:

  1. Identifique el NODE en el que se ha desplegado el pod istio-ingressgateway.

    kubectl get pod -n istio-system -o wide

  2. Obtenga la dirección EXTERNAL-IP para el servicio de equilibrador de carga de la pasarela.

    kubectl get service -n istio-system

  3. Identifique el NODE en el que se despliega el pod ibm-cloud-provider-ip para el equilibrador de carga. Sustituya <IP-with-hyphens> por la dirección IP que ha encontrado en el paso anterior. En la dirección IP, utilice guiones (-) en lugar de puntos (.). Por ejemplo, 169.12.345.67 se convierte en 169-12-345-67.

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

  4. Liste las zonas en las que se encuentran los nodos trabajadores. Compare los nodos trabajadores que ha encontrado en el paso 1 y 3 para determinar si los pods se han desplegado en nodos trabajadores de distintas zonas.

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

    Salida de ejemplo

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

Para resolver este problema, puede mover el pod istio-ingressgateway a la zona en la que existe el pod ibm-cloud-provider-ip o viceversa.

  • Mover el pod istio-ingressgateway: el equilibrador de carga de la pasarela conserva la misma dirección IP externa una vez que se mueve. Sin embargo, en la versión 1.9 y anteriores del complemento, los cambios que realice podrían sobrescribirse cuando las etiquetas de zona para las pasarelas se rellenen automáticamente durante las actualizaciones de parches de Istio.
  • Mover el pod ibm-cloud-provider-ip: la pasarela no conserva la misma dirección IP externa una vez que se mueve y se le asigna una nueva dirección IP. Sin embargo, no se sobrescriben los cambios durante las actualizaciones del complemento.

Mover el pod istio-ingressgateway

Mueva el pod istio-ingressgateway a la misma zona que el pod ibm-cloud-provider-ip.

  1. Edite el recurso de mapa de configuración managed-istio-custom.
    kubectl edit cm managed-istio-custom -n ibm-operators
  2. Para la pasarela que desea mover, cambie el valor de istio-ingressgateway-zone-1|2|3 a la zona en la que existe el pod ibm-cloud-provider-ip.
  3. Guarde y cierre el archivo de configuración. El pod istio-ingressgateway se mueve a un nodo trabajador de la misma zona que el pod ibm-cloud-provider-ip y el pod ibm-cloud-provider-ip se despliega correctamente.
  4. Para verificar que los pods existen ahora en la misma zona, siga los pasos de la sección Por qué está ocurriendo.

Mover el pod ibm-cloud-provider-ip

Mueva el pod ibm-cloud-provider-ip a la misma zona que el pod istio-ingressgateway.

  1. Edite el recurso de mapa de configuración managed-istio-custom.

    kubectl edit cm managed-istio-custom -n ibm-operators

  2. Anote el nombre del valor istio-ingressgateway-zone-<1|2|3> para la pasarela. En este ejemplo de mapa de configuración, para mover el pod ibm-cloud-provider-ip para la pasarela que existe en dal10, tenga en cuenta la clave denominada istio-ingressgateway-zone-1.

    apiVersion: v1
data:
  istio-ingressgateway-zone-1: dal10
  istio-ingressgateway-zone-2: dal12
  istio-ingressgateway-public-1-enabled: "true"
  istio-ingressgateway-public-2-enabled: "true"
  istio-monitoring: "true"
kind: ConfigMap
...

  3. Inhabilite temporalmente la pasarela cambiando el valor istio-ingressgateway-public-<1|2|3>-enabled correspondiente a "false". En este mapa de configuración de ejemplo, para mover el pod ibm-cloud-provider-ip para la pasarela existente en dal10, cambie istio-ingressgateway-public-1-enabled a "false".

    apiVersion: v1
data:
  istio-ingressgateway-zone-1: dal10
  istio-ingressgateway-zone-2: dal12
  istio-ingressgateway-public-1-enabled: "false"
  istio-ingressgateway-public-2-enabled: "true"
  istio-monitoring: "true"
kind: ConfigMap
...

  4. Guarde y cierre el archivo de configuración.

  5. Verifique que se ha suprimido el pod del equilibrador de carga de la pasarela. Tenga en cuenta que los cambios pueden tardar hasta 30 minutos en completarse.

    kubectl get service -n istio-system -o wide

  6. Abra el recurso de mapa de configuración managed-istio-custom.

    kubectl edit cm managed-istio-custom -n ibm-operators

  7. Vuelva a habilitar la pasarela cambiando el valor istio-ingressgateway-public-<1|2|3>-enabled de nuevo a "true".

  8. Guarde y cierre el archivo de configuración. Se crea un nuevo servicio de equilibrador de carga para la pasarela (el pod istio-ingressgateway) y se despliega un nuevo pod ibm-cloud-provider-ip para ese equilibrador de carga en un nodo trabajador de la misma zona que el pod istio-ingressgateway.

  9. Para verificar que los pods existen ahora en la misma zona, siga los pasos de la sección Por qué está ocurriendo.