Questo documento descrive i problemi noti della versione 1.8 dei cluster Anthos su VMware (GKE on-prem).
Risorsa personalizzata ClientConfig
gkectl update
annulla eventuali modifiche manuali apportate alla risorsa personalizzata ClientConfig. Ti consigliamo vivamente di effettuare il backup della risorsa ClientConfig dopo ogni modifica manuale.
Convalida gkectl check-config non riuscita: impossibile trovare le partizioni F5 BIG-IP
- Sintomi
La convalida non va a buon fine perché non è possibile trovare le partizioni BIG-IP F5, anche se esistono.
- Cause potenziali
Un problema con l'API F5 BIG-IP può causare errori di convalida.
- Risoluzione
Riprova a eseguire
gkectl check-config
.
Malfunzionamento dei carichi di lavoro con budget PodDisruption
L'upgrade dei cluster può causare interruzioni o tempi di inattività per i carichi di lavoro che utilizzano PodDisruptionBudgets (PDB).
I nodi non completano il processo di upgrade
Se hai configurato PodDisruptionBudget
oggetti che non sono in grado di consentire ulteriori interruzioni, gli upgrade dei nodi potrebbero non eseguire l'upgrade alla versione del piano di controllo dopo diversi tentativi. Per evitare questo errore, ti consigliamo di fare lo scale up di Deployment
o HorizontalPodAutoscaler
per consentire lo svuotamento del nodo rispettando la configurazione di PodDisruptionBudget
.
Per visualizzare tutti gli oggetti PodDisruptionBudget
che non consentono interruzioni:
kubectl get poddisruptionbudget --all-namespaces -o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}'
L'installazione del cluster utente non è riuscita a causa del problema relativo alle elezioni leader nel programma cert-manager/ca-injector
Potresti notare un errore di installazione dovuto all'errore cert-manager-cainjector
nel looploop, quando l'apiserver/etcd è lento:
# These are logs from `cert-manager-cainjector`, from the command
# `kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system cert-manager-cainjector-xxx`
I0923 16:19:27.911174 1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election: timed out waiting for the condition
E0923 16:19:27.911110 1 leaderelection.go:321] error retrieving resource lock kube-system/cert-manager-cainjector-leader-election-core: Get "https://10.96.0.1:443/api/v1/namespaces/kube-system/configmaps/cert-manager-cainjector-leader-election-core": context deadline exceeded
I0923 16:19:27.911593 1 leaderelection.go:278] failed to renew lease kube-system/cert-manager-cainjector-leader-election-core: timed out waiting for the condition
E0923 16:19:27.911629 1 start.go:163] cert-manager/ca-injector "msg"="error running core-only manager" "error"="leader election lost"
Esegui i comandi indicati per mitigare il problema.
Innanzitutto, scala la monitoring-operator
in modo che non annulli le modifiche al deployment di cert-manager
.
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system scale deployment monitoring-operator --replicas=0
In secondo luogo, modifica il deployment di cert-manager-cainjector
per disabilitare le elezioni dei leader, perché è in esecuzione una sola replica. Non è necessaria per una singola replica.
# Add a command line flag for cainjector: `--leader-elect=false`
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG edit -n kube-system deployment cert-manager-cainjector
Lo snippet yaml pertinente per il deployment cert-manager-cainjector
dovrebbe avere il seguente aspetto:
...
apiVersion: apps/v1
kind: Deployment
metadata:
name: cert-manager-cainjector
namespace: kube-system
...
spec:
...
template:
...
spec:
...
containers:
- name: cert-manager
image: "gcr.io/gke-on-prem-staging/cert-manager-cainjector:v1.0.3-gke.0"
args:
...
- --leader-elect=false
...
Mantieni monitoring-operator
repliche a 0 come mitigazione fino al termine dell'installazione. In caso contrario, la modifica verrà annullata.
Al termine dell'installazione e quando il cluster è operativo, attiva monitoring-operator
per le operazioni del secondo giorno:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system scale deployment monitoring-operator --replicas=1
Dopo ogni upgrade, le modifiche verranno annullate. Ripeti la stessa procedura per ridurre il problema finché il problema non sarà risolto in una versione futura.
Potrebbe essere necessario rinnovare i certificati prima di eseguire l'upgrade di un cluster di amministrazione
Prima di iniziare il processo di upgrade dei cluster di amministrazione, devi assicurarti che i certificati del tuo cluster di amministrazione siano attualmente validi e, in caso contrario, rinnovarli.
Procedura di rinnovo del certificato del cluster di amministrazione
Prima di iniziare, assicurati che OpenSSL sia installato sulla workstation dell'amministratore.
Imposta la variabile
KUBECONFIG
:KUBECONFIG=ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG
Sostituisci ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG con il percorso assoluto del file kubeconfig del cluster di amministrazione.
Recupera l'indirizzo IP e le chiavi SSH per il nodo master dell'amministratore:
kubectl --kubeconfig "${KUBECONFIG}" get secrets -n kube-system sshkeys \ -o jsonpath='{.data.vsphere_tmp}' | base64 -d > \ ~/.ssh/admin-cluster.key && chmod 600 ~/.ssh/admin-cluster.key export MASTER_NODE_IP=$(kubectl --kubeconfig "${KUBECONFIG}" get nodes -o \ jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' \ --selector='node-role.kubernetes.io/master')
Controlla se i certificati sono scaduti:
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" \ "sudo kubeadm alpha certs check-expiration"
Se i certificati sono scaduti, devi rinnovarli prima di eseguire l'upgrade del cluster di amministrazione.
Effettua il backup di vecchi certificati:
Questo passaggio è facoltativo, ma consigliato.
# ssh into admin master ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" # on admin master sudo tar -czvf backup.tar.gz /etc/kubernetes logout # on worker node sudo scp -i ~/.ssh/admin-cluster.key \ ubuntu@"${MASTER_NODE_IP}":/home/ubuntu/backup.tar.gz .
Rinnova i certificati con kubeadm:
# ssh into admin master ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" # on admin master sudo kubeadm alpha certs renew all
Riavvia il nodo master amministrativo:
# on admin master cd /etc/kubernetes sudo mkdir tempdir sudo mv manifests/*.yaml tempdir/ sleep 5 echo "remove pods" # ensure kubelet detect those change remove those pods # wait until the result of this command is empty sudo docker ps | grep kube-apiserver # ensure kubelet start those pods again echo "start pods again" sudo mv tempdir/*.yaml manifests/ sleep 30 # ensure kubelet start those pods again # should show some results sudo docker ps | grep -e kube-apiserver -e kube-controller-manager -e kube-scheduler -e etcd # clean up sudo rm -rf tempdir logout
Poiché il file kubeconfig del cluster di amministrazione scade anche se i certificati amministrativi scadono, devi eseguirne il backup prima della scadenza.
Esegui il backup del file kubeconfig del cluster di amministrazione:
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}"
"sudo cat /etc/kubernetes/admin.conf" > new_admin.conf vi "${KUBECONFIG}"Sostituisci
client-certificate-data
eclient-key-data
in kubeconfig conclient-certificate-data
eclient-key-data
nel filenew_admin.conf
che hai creato.
Devi convalidare i certificati rinnovati e il certificato di kube-apiserver.
Controlla la scadenza dei certificati:
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}"
"sudo kubeadm alpha certs check-expiration"Controlla il certificato di kube-apiserver:
# Get the IP address of kube-apiserver cat $KUBECONFIG | grep server # Get the current kube-apiserver certificate openssl s_client -showcerts -connect
:
| sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'
> current-kube-apiserver.crt # check expiration date of this cert openssl x509 -in current-kube-apiserver.crt -noout -enddate
Lo script /etc/cron.Daily/aide occupa tutto lo spazio in /run, causando un arresto anomalo nei pod
A partire dai cluster Anthos su VMware 1.7.2, le immagini del sistema operativo Ubuntu sono protette con CIS L1 Server Benchmark.
.
Di conseguenza, lo script cron /etc/cron.daily/aide
è stato installato in modo che venga pianificato un controllo dell'assistenza per assicurare che la regola del server CIS L1 sia"1.4.2 Assicurati che l'integrità del file system sia verificata regolarmente".
Lo script utilizza /run/aide
come directory temporanea per salvare i relativi cron log e nel tempo potrebbe utilizzare tutto lo spazio in /run
. Per una soluzione, consulta lo script/etc/cron.Daily/aide utilizza tutto lo spazio in /run.
Se vedi uno o più pod che si arrestano in modo anomalo su un nodo, esegui df -h /run
sul nodo. Se l'output dei comandi mostra un utilizzo del 100% dello spazio, probabilmente stai riscontrando questo problema.
Questo problema è stato risolto nella versione 1.8.1. Per le versioni 1.7.2 e 1.8.0, puoi risolvere questo problema manualmente con una delle due soluzioni seguenti:
- Rimuovi periodicamente i file di log in
/run/aide/cron.daily.old*
(opzione consigliata). - Segui i passaggi descritti nello /etc/cron.Daily/aide script tutto lo spazio in /run. Nota: questa soluzione potrebbe influire sullo stato di conformità del nodo.
Upgrade di un bilanciatore del carico Seesaw con versione 1.8.0
Se utilizzi gkectl upgrade loadbalancer
per tentare di aggiornare alcuni parametri del bilanciatore del carico Seesaw nella versione 1.8.0, non funzionerà in modalità DHCP o IPAM. Se la configurazione include questa configurazione, non eseguire l'upgrade alla versione 1.8.0, ma a quella 1.8.1 o successive.
Impossibile accedere alla workstation dell'amministratore a causa di un problema di scadenza della password
Potresti riscontrare questo problema se utilizzi una delle seguenti versioni di cluster Anthos su VMware.
- 1.7.2-gke.2
- 1.7.3-gke.2
- 1.8.0-gke.21
- 1.8.0-gke.24
- 1.8.0-gke.25
- 1.8.1-gke.7
- 1.8.2-gke.8
Potresti ricevere il messaggio di errore seguente quando tenti di accedere tramite SSH alle VM Anthos, tra cui la workstation dell'amministratore, i nodi del cluster e i nodi Seesaw:
WARNING: Your password has expired.
Questo errore si verifica perché la password dell'utente ubuntu nelle VM è scaduta. Prima di accedere alle VM devi reimpostare manualmente la data di scadenza della password dell'utente.
Prevenzione dell'errore di scadenza della password
Se stai eseguendo le versioni interessate elencate sopra e la password utente non è ancora scaduta, dovresti posticipare la scadenza prima di visualizzare l'errore SSH.
Esegui il comando seguente su ogni VM Anthos:
sudo chage -M 99999 ubuntu
Attenuazione dell'errore di scadenza della password
Se la password utente è già scaduta e non puoi accedere alle VM per estendere la scadenza, esegui i seguenti passaggi di mitigazione per ogni componente.
Workstation di amministrazione
Utilizza una VM temporanea per eseguire i passaggi seguenti. Puoi creare una workstation amministrativa utilizzando la versione 1.7.1-gke.4 da utilizzare come VM temporanea.
Assicurati che la VM temporanea e la workstation amministrativa siano in stato di spegnimento.
Collega il disco di avvio della workstation amministrativa alla VM temporanea. Il disco di avvio è quello con l'etichetta "Disco rigido 1".
Monta il disco di avvio all'interno della VM eseguendo questi comandi. Sostituisci il tuo identificatore del disco di avvio per
dev/sdc1
.sudo mkdir -p /mnt/boot-disk sudo mount /dev/sdc1 /mnt/boot-disk
Imposta la data di scadenza dell'utente ubuntu su un valore grande, ad esempio
99999
giorni.sudo chroot /mnt/boot-disk chage -M 99999 ubuntu
Arresta la VM temporanea.
Accendi la workstation amministrativa. Ora dovresti essere in grado di utilizzare SSH come al solito.
Come pulizia, elimina la VM temporanea.
VM del piano di controllo del cluster di amministrazione
Segui le istruzioni per ricreare la VM del piano di controllo del cluster di amministrazione.
VM del componente aggiuntivo del cluster di amministrazione
Esegui il comando seguente dalla workstation di amministrazione per ricreare la VM:
kubectl --kubeconfig=ADMIN_CLUSTER_KUBECONFIG patch machinedeployment gke-admin-node --type=json -p="[{'op': 'add', 'path': '/spec/template/spec/metadata/annotations', 'value': {"kubectl.kubernetes.io/restartedAt": "version1"}}]"
Dopo aver eseguito questo comando, attendi che le VM dei componenti aggiuntivi del cluster di amministrazione completino le attività ricreative e siano pronte prima di continuare con i passaggi successivi.
VM del piano di controllo del cluster utente
Esegui il comando seguente dalla workstation di amministrazione per ricreare le VM:
usermaster=`kubectl --kubeconfig=ADMIN_CLUSTER_KUBECONFIG get machinedeployments -l set=user-master -o name` && kubectl --kubeconfig=ADMIN_CLUSTER_KUBECONFIG patch $usermaster --type=json -p="[{'op': 'add', 'path': '/spec/template/spec/metadata/annotations', 'value': {"kubectl.kubernetes.io/restartedAt": "version1"}}]"
Dopo aver eseguito questo comando, attendi che le VM del piano di controllo del cluster utente terminino le attività ricreative e siano pronte prima di continuare con i passaggi successivi.
VM worker cluster di utenti
Esegui il comando seguente dalla workstation amministrativa per ricreare le VM.
for md in `kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG get machinedeployments -l set=node -o name`; do kubectl patch --kubeconfig=USER_CLUSTER_KUBECONFIG $md --type=json -p="[{'op': 'add', 'path': '/spec/template/spec/metadata/annotations', 'value': {"kubectl.kubernetes.io/restartedAt": "version1"}}]"; done
VM Seesaw
Esegui i comandi seguenti dalla workstation di amministrazione per ricreare le VM di Seesaw. È previsto un periodo di inattività. Se l'alta disponibilità è abilitata per il bilanciatore del carico, il tempo massimo di inattività è di due secondi.
gkectl upgrade loadbalancer --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG --admin-cluster --no-diff gkectl upgrade loadbalancer --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG --no-diff
Riavvio o upgrade di vCenter per le versioni precedenti alla 7.0U2
Se il vCenter, per le versioni precedenti alla 7.0U2, viene riavviato dopo un upgrade o in caso contrario,
il nome della rete nelle informazioni della VM vCenter non è corretto e lo stato del computer è Unavailable
. Questo comporta la riparazione automatica dei nodi per la creazione di nuovi nodi.
Bug govmomi correlato: https://github.com/vmware/govmomi/issues/2552
Questa soluzione è fornita dall'assistenza VMware:
1. The issue is fixed in vCenter versions 7.0U2 and above. 2. For lower versions: Right-click the host, and then select Connection > Disconnect. Next, reconnect, which forces an update of the VM's portgroup.
Panico gkectl create-config admin
e gkectl create-config cluster
Nelle versioni 1.8.0-1.8.3, il comando gkectl create-config admin/cluster
esegue il panico con il messaggio panic: invalid version: "latest"
.
Come soluzione alternativa, utilizza gkectl create-config admin/cluster --gke-on-prem-version=DESIRED_CLUSTER_VERSION
. Sostituisci DESIRED_CLUSTER_VERSION
con la versione desiderata, ad esempio 1.8.2-gke.8.
Creazione/upgrade del timeout del cluster di amministrazione
Questo problema riguarda 1.8.0-1.8.3.
La creazione del cluster di amministrazione o l'upgrade del cluster di amministrazione potrebbero scadere con il seguente errore:
Error getting kubeconfig: error running remote command 'sudo cat /etc/kubernetes/admin.conf': error: Process exited with status 1, stderr: 'cat: /etc/kubernetes/admin.conf: No such file or directory
Inoltre, il log in nodes/ADMIN_MASTER_NODE/files/var/log/startup.log
nello snapshot del cluster esterno termina con questo messaggio:
[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
Questo errore si verifica quando la rete è lenta tra la VM del piano di controllo dell'amministratore e il Container Registry. Assicurati di controllare la configurazione della rete o del proxy per ridurre la latenza e aumentare la larghezza di banda.
Connessione SSH chiusa da host remoto
Per i cluster Anthos su VMware 1.7.2 e versioni successive, le immagini del sistema operativo Ubuntu sono protette con CIS L1 Server Benchmark.
Per soddisfare la regola CIS "5.2.16 Assicurati che l'intervallo di inattività di SSH sia configurato", /etc/ssh/sshd_config
ha le seguenti impostazioni:
ClientAliveInterval 300 ClientAliveCountMax 0
Lo scopo di queste impostazioni è terminare una sessione client dopo 5 minuti di inattività. Tuttavia, il valore ClientAliveCountMax 0
provoca
comportamenti imprevisti. Quando utilizzi la sessione SSH sulla workstation amministrativa o un nodo cluster, la connessione SSH potrebbe essere disconnessa anche se il client SSH non è inattivo, ad esempio durante l'esecuzione di un comando dispendioso in termini di tempo, ed è possibile che il comando venga terminato con il seguente messaggio:
Connection to [IP] closed by remote host. Connection to [IP] closed.
In alternativa, puoi:
Utilizza
nohup
per impedire che il comando venga interrotto alla disconnessione di SSH,nohup gkectl upgrade admin --config admin-cluster.yaml --kubeconfig kubeconfig
Aggiorna
sshd_config
per utilizzare un valoreClientAliveCountMax
diverso da zero. La regola CIS consiglia di utilizzare un valore inferiore a 3.sudo sed -i 's/ClientAliveCountMax 0/ClientAliveCountMax 1/g' /etc/ssh/sshd_config sudo systemctl restart sshd
Assicurati di ricollegare la sessione SSH.
Conflitto con cert-manager
in caso di upgrade alla versione 1.8.2 o successive
Se hai installato un'installazione di cert-manager
con i cluster Anthos su VMware, potresti riscontrare un errore quando tenti di eseguire l'upgrade alle versioni 1.8.2 o successive. Questo è il risultato di un conflitto tra la tua versione di cert-manager
, che potrebbe essere installata nello spazio dei nomi cert-manager
e la versione monitoring-operator
.
Se tenti di installare un'altra copia di cert-manager
dopo aver eseguito l'upgrade ai cluster Anthos su VMware versione 1.8.2 o successive, l'installazione potrebbe non riuscire a causa di un conflitto con quello esistente gestito da monitoring-operator
.
L'emittente del cluster metrics-ca
, che utilizza i componenti del piano di controllo e dell'osservabilità per la creazione e la rotazione di secret dei certificati, richiede l'archiviazione di un secret del certificato metrics-ca
nello spazio dei nomi delle risorse del cluster. Questo spazio dei nomi è kube-system
per l'installazione dell'operatore di monitoraggio ed è probabile che sia cert-manager
per l'installazione.
Se si è verificato un errore di installazione, segui questi passaggi per eseguire correttamente l'upgrade alla versione 1.8.2 o successiva:
Disinstalla la tua versione di
cert-manager
.Esegui l'upgrade.
Se vuoi ripristinare la tua installazione di cert-manager, procedi nel seguente modo:
Scala il deployment
monitoring-operator
a 0. Per il cluster di amministrazione, esegui questo comando:kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system scale deployment monitoring-operator --replicas=0
Per un cluster utente, esegui questo comando:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME scale deployment monitoring-operator --replicas=0
Scala i deployment
cert-manager
gestiti damonitoring-operator
a 0. Per il cluster di amministrazione, esegui questo comando:kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system scale deployment cert-manager --replicas=0 kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system scale deployment cert-manager-cainjector --replicas=0 kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system scale deployment cert-manager-webhook --replicas=0
Per un cluster utente, esegui questo comando:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system scale deployment cert-manager --replicas=0 kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system scale deployment cert-manager-cainjector --replicas=0 kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-system scale deployment cert-manager-webhook --replicas=0
Reinstalla
cert-manager
.Copia il certificato
metrics-ca
cert-manager.io/v1 e le risorse dell'emittentemetrics-pki.cluster.local
dakube-system
allo spazio dei nomi delle risorse cluster del certificato cert. Questo spazio dei nomi potrebbe esserecert-manager
se utilizzi la release up-manager di upstream, ad esempio v1.0.3, ma dipende dalla tua installazione.
Falsi positivi in analisi delle vulnerabilità di docker, containerd e runc
Il docker, containerd e runc nelle immagini di sistema operativo Ubuntu fornite con cluster Anthos su VMware sono bloccati su versioni speciali con il protocollo Ubuntu PPA. Ciò garantisce che tutte le modifiche al runtime del container vengano qualificate dai cluster Anthos su VMware prima di ogni release.
Tuttavia, le versioni speciali sono sconosciute a Ubuntu CVE Tracker, che viene usato come feed delle vulnerabilità da vari strumenti di scansione CVE. Pertanto, vedrai falsi positivi nei risultati dell'analisi delle vulnerabilità con container, containerd e runc.
Ad esempio, potresti vedere i seguenti falsi positivi nei risultati della scansione di CVE. Questi CVE sono già stati corretti nelle ultime versioni di patch dei cluster Anthos su VMware.
Consulta le note di rilascio per conoscere le correzioni CVE.
canonical è a conoscenza del problema e la correzione viene monitorata all'indirizzo https://github.com/canonical/sec-cvescan/issues/73.
Problema relativo a picchi di memoria e CPU /etc/cron.daily/aide
A partire dai cluster Anthos su VMware versione 1.7.2, le immagini del sistema operativo Ubuntu sono protette con CIS L1 Server Benchmark.
Di conseguenza, lo script cron /etc/cron.daily/aide
è stato installato in modo che venga pianificato un controllo aide
per assicurare che venga applicata la regola del server CIS L1 "1.4.2 Assicurarsi che l'integrità del file system sia verificata regolarmente".
Il cron job viene eseguito ogni giorno alle 06:00 UTC. A seconda del numero di file nel file system, potresti riscontrare picchi di utilizzo di CPU e memoria in quel periodo causato da questo processo aide
.
Se i picchi interessano il carico di lavoro, puoi disabilitare il cron job giornaliero.
`sudo chmod -x /etc/cron.daily/aide`.
Cisco ACI non funziona con il ritorno a server diretto (DSR)
Seesaw funziona in modalità DSR e per impostazione predefinita non funziona in Cisco ACI a causa dell'apprendimento IP del piano dati. Una possibile soluzione alternativa è disattivare l'apprendimento IP aggiungendo l'indirizzo IP di Seesaw come IP virtuale L4-L7 in Cisco Application Policy Infrastructure Controller (APIC).
Puoi configurare l'opzione IP virtuale L4-L7 andando su Tenant > Application Profiles > Application EPG o uSeg EPG. Se non disattivi l'apprendimento IP, l'endpoint IP si bloccherà tra le diverse posizioni nell'API Cisco.
Un token di connessione dell'account di servizio troppo lungo può danneggiare i log del bilanciatore del carico Seesaw
Se il token di connessione dell'account di servizio di monitoraggio del logging è superiore a 512 kB, è possibile che vengano interrotti i log del bilanciatore del carico Seesaw. Per risolvere il problema, esegui l'upgrade alla versione 1.9 o successive.
Problemi di connettività tra pod a causa di daemon anetd
nel deadlock software
I cluster con enableDataplaneV2
impostato su true
possono riscontrare problemi di connettività tra i pod a causa di daemon anetd
(in esecuzione come daemonset) che entrano in un deadlock software. In questo stato, i daemon anetd
vedranno i nodi inattivi (precedentemente eliminati) come peer e non vedranno i nuovi nodi aggiunti come nuovi peer.
Se hai riscontrato questo problema, completa i seguenti passaggi per riavviare i daemon anetd
al fine di aggiornare i nodi peer e ripristinare la connettività.
Trova tutti i daemon
anetd
nel cluster:kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG -n kube-system get pods -o wide | grep anetd
Controlla se al momento
anetd
daemon stanno visualizzando peer inattivi:kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG -n kube-system exec -it ANETD_XYZ -- cilium-health status
Sostituisci ANETD_XYZ con il nome di un pod
anetd
.Riavvia tutti i pod interessati:
kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG -n kube-system delete pod ANETD_XYZ