Pourquoi les pods ibm-cloud-provider-ip de la passerelle Istio ingress sont-ils bloqués à l'état pending ?

Cloud privé virtuel Infrastructure classique

Clusters multizones uniquement

Lorsque vous exécutez la commande kubectl get pod -n ibm-system, le pod ibm-cloud-provider-ip qui fournit l'adresse IP externe pour la passerelle Istio ingress est bloqué à l'état pending.

De plus, lorsque vous exécutez kubectl describe pod <pod_name> -n ibm-system pour le pod ibm-cloud-provider-ip, vous remarquez une erreur de conflit de planification dans la section des événements de la sortie.

Pour identifier le pod ibm-cloud-provider-ip pour votre passerelle, vous pouvez exécuter kubectl get service -n istio-system pour rechercher le service d'équilibrage de charge de votre passerelle, prenez note de son EXTERNAL-IP et recherchez l'adresse IP dans le nom de pod ibm-cloud-provider-ip.

Lorsqu'un service d'équilibreur de charge istio-ingressgateway est créé, un pod ibm-cloud-provider-ip est créé pour fournir une adresse IP externe à l'équilibreur de charge.

Ces pods ibm-cloud-provider-ip comportent une règle d'affinité de noeud leur permettant d'être créés dans la même zone que le sous-réseau à partir duquel l'adresse IP est dérivée. Toutefois, lorsque le paramètre ExternalTrafficPolicy du service d'équilibrage de charge istio-ingressgateway est défini sur Local, le pod ibm-cloud-provider-ip comporte également une règle d'affinité de pod à déployer dans la même zone que le pod de l'équilibreur de charge de la passerelle. Si l'adresse IP et l'équilibreur de charge de passerelle existent dans différentes zones de votre cluster, le pod ibm-cloud-provider-ip ne peut pas être déployé correctement.

Pour vérifier que les pods ibm-cloud-provider-ip et istio-ingressgateway n'existent pas dans la même zone :

  1. Identifiez le noeud NODE sur lequel le pod istio-ingressgateway est déployé.

    kubectl get pod -n istio-system -o wide

  2. Obtenez l'adresse EXTERNAL-IP du service d'équilibreur de charge de la passerelle.

    kubectl get service -n istio-system

  3. Identifiez le NODE sur lequel le pod ibm-cloud-provider-ip de l'équilibreur de charge est déployé. Remplacez <IP-with-hyphens> par l'adresse IP que vous avez trouvée à l'étape précédente. Dans l'adresse IP, utilisez les traits d'union (-) au lieu des points (.). Par exemple, 169.12.345.67 devient 169-12-345-67.

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

  4. Répertoriez les zones dans lesquelles se trouvent les noeuds worker. Comparez les noeuds worker que vous avez trouvés à l'étape 1 et 3 pour déterminer si les pods sont déployés sur des noeuds worker de différentes zones.

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

    Exemple de sortie

    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

Pour résoudre ce problème, vous pouvez transférer le pod istio-ingressgateway dans la zone où se trouve le pod ibm-cloud-provider-ip ou inversement.

  • Déplacement du pod istio-ingressgateway : l'équilibreur de charge de passerelle conserve la même adresse IP externe après son déplacement. Toutefois, dans la version 1.9 et antérieure du module complémentaire, les modifications apportées peuvent être écrasées lorsque les libellés de zone des passerelles sont automatiquement renseignés lors des mises à jour du correctif Istio.
  • Déplacement du pod ibm-cloud-provider-ip : la passerelle ne conserve pas la même adresse IP externe après son déplacement, et une nouvelle adresse IP lui est affectée. Cependant, aucune modification n'est écrasée au cours des mises à jour du plug-in.

Déplacement du pod istio-ingressgateway

Transférez le pod istio-ingressgateway dans la même zone que le pod ibm-cloud-provider-ip.

  1. Editez la ressource de mappe de configuration managed-istio-custom.
    kubectl edit cm managed-istio-custom -n ibm-operators
  2. Pour la passerelle que vous souhaitez déplacer, modifiez le paramètre istio-ingressgateway-zone-1|2|3 dans la zone où se trouve le pod ibm-cloud-provider-ip.
  3. Sauvegardez et fermez le fichier de configuration. Le pod istio-ingressgateway est transféré vers un noeud worker dans la même zone que le pod ibm-cloud-provider-ip et le pod ibm-cloud-provider-ip se déploie correctement.
  4. Pour vérifier que les pods existent maintenant dans la même zone, suivez les étapes de la section Pourquoi ?.

Déplacement du pod ibm-cloud-provider-ip

Transférez le pod ibm-cloud-provider-ip dans la même zone que le pod istio-ingressgateway.

  1. Editez la ressource de mappe de configuration managed-istio-custom.

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

  2. Notez le nom du paramètre istio-ingressgateway-zone-<1|2|3> pour la passerelle. Dans cet exemple de mappe de configuration, pour déplacer le pod ibm-cloud-provider-ip de la passerelle qui existe dans dal10, notez la clé appelée 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. Désactivez temporairement la passerelle en remplaçant le paramètre istio-ingressgateway-public-<1|2|3>-enabled correspondant par "false". Dans cet exemple de mappe de configuration (configmap), pour transférer le pod ibm-cloud-provider-ip de la passerelle qui se trouve dans dal10, affectez à istio-ingressgateway-public-1-enabled la valeur "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. Sauvegardez et fermez le fichier de configuration.

  5. Vérifiez que le pod de l'équilibreur de charge de la passerelle est supprimé. Sachez qu'un délai pouvant atteindre 30 minutes peut s'écouler avant l'application de la modification.

    kubectl get service -n istio-system -o wide

  6. Ouvrez la ressource de mappe de configuration managed-istio-custom.

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

  7. Réactivez la passerelle en remplaçant le paramètre istio-ingressgateway-public-<1|2|3>-enabled par "true".

  8. Sauvegardez et fermez le fichier de configuration. Un nouveau service d'équilibreur de charge pour la passerelle (pod istio-ingressgateway) est créé et un nouveau pod ibm-cloud-provider-ip pour cet équilibreur de charge est déployé sur un noeud worker dans la même zone que le pod istio-ingressgateway.

  9. Pour vérifier que les pods existent maintenant dans la même zone, suivez les étapes de la section Pourquoi ?.