Versione 1.8. Questa versione è supportata come descritto nel criterio di supporto per le versioni di Anthos, che offre le patch e gli aggiornamenti più recenti per vulnerabilità di sicurezza, esposizioni e problemi che interessano i cluster Anthos su VMware (GKE on-prem). Per ulteriori informazioni, leggi le note di rilascio. Questa non è la versione più recente.

Versioni disponibili: 1.11 1.10 1.9 Versioni precedenti

Problemi noti

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 e client-key-data in kubeconfig con client-certificate-data e client-key-data nel file new_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 valore ClientAliveCountMax 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 da monitoring-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'emittente metrics-pki.cluster.local da kube-system allo spazio dei nomi delle risorse cluster del certificato cert. Questo spazio dei nomi potrebbe essere cert-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