Perché i pod ibm-cloud-provider-ip per il gateway di ingresso Istio sono bloccati in pending?

Virtual Private Cloud Infrastruttura classica

Solo cluster multizona

Quando si esegue kubectl get pod -n ibm-system, il pod ibm-cloud-provider-ip che fornisce l'indirizzo IP esterno per il gateway di ingresso Istio è bloccato nello stato pending.

Inoltre, quando esegui kubectl describe pod <pod_name> -n ibm-system per il pod ibm-cloud-provider-ip, noti un errore di conflitto di pianificazione nella sezione degli eventi del pod dell'output.

Per identificare il pod ibm-cloud-provider-ip per il gateway, puoi eseguire kubectl get service -n istio-system per trovare il servizio del programma di bilanciamento del carico del tuo gateway, prendere nota del suo EXTERNAL - IP e cercare l'indirizzo IP nel nome del pod ibm-cloud-provider-ip.

Quando viene creato un servizio del programma di bilanciamento del carico istio-ingressgateway, viene creato un pod ibm-cloud-provider-ip per fornire un indirizzo IP esterno al programma di bilanciamento del carico.

Questi pod ibm-cloud-provider-ip hanno una regola di affinità nodo in modo che vengano creati nella stessa zona della sottorete da cui deriva l'indirizzo IP. Tuttavia, quando l'impostazione ExternalTrafficPolicy per il servizio del programma di bilanciamento del carico istio-ingressgateway è impostata su Local, il pod ibm-cloud-provider-ip ha anche una regola di affinità pod da distribuire alla stessa zona del pod del programma di bilanciamento del carico del gateway. Se l'indirizzo IP e il programma di bilanciamento del carico del gateway esistono in zone differenti nel tuo cluster, il pod ibm-cloud-provider-ip non può essere distribuito correttamente.

Per verificare che i pod ibm-cloud-provider-ip e istio-ingressgateway non esistano nella stessa zona:

1. Identifica il NODE a cui è distribuito il tuo pod istio-ingressgateway.

   kubectl get pod -n istio-system -o wide
   

2. Ottieni l'indirizzo IP esterno del servizio di bilanciamento del carico del gateway.

   kubectl get service -n istio-system
   

3. Identifica il NODE a cui è distribuito il pod ibm-cloud-provider-ip per il programma di bilanciamento del carico. Sostituisci <IP-with-hyphens> con l'indirizzo IP che hai individuato nel passaggio precedente. Nell'indirizzo IP, utilizzare i trattini (-) invece dei punti (.). Ad esempio, 169.12.345.67 diventa 169-12-345-67.

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

4. Elenca le zone in cui si trovano i nodi di lavoro. Confronta i nodi di lavoro che hai trovato nei passi 1 e 3 per determinare se i pod sono distribuiti ai nodi di lavoro in zone differenti.

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

   Output di esempio

   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
   

Per risolvere questo problema, puoi spostare il pod istio-ingressgateway nella zona in cui esiste il pod ibm-cloud-provider-ip o viceversa.

• Spostamento del pod istio-ingressgateway: il programma di bilanciamento del carico del gateway conserva lo stesso indirizzo IP esterno dopo lo spostamento. Tuttavia, nelle versioni 1.9 e precedenti del componente aggiuntivo, le modifiche apportate potrebbero essere sovrascritte quando le etichette di zona per i gateway vengono popolate automaticamente durante gli aggiornamenti della patch Istio.
• Spostamento del pod ibm-cloud-provider-ip: il gateway non conserva lo stesso indirizzo IP esterno dopo lo spostamento e gli viene assegnato un nuovo indirizzo IP. Tuttavia, nessuna modifica viene sovrascritta durante gli aggiornamenti dei componenti aggiuntivi.