Problemi noti di Cluster Anthos su VMware

Questa pagina elenca tutti i problemi noti dei cluster Anthos su VMware. Per filtrare i problemi noti in base a una versione del prodotto o a una categoria, seleziona i filtri desiderati dai seguenti menu a discesa.

Seleziona la versione di Cluster Anthos su VMware:

Seleziona la categoria del problema:

In alternativa, cerca il tuo problema:

Categoria Versioni identificate Problema e soluzione alternativa
Networking, operazione 1.10, 1.11, 1.12, 1.13, 1.14

Componenti di Anthos Network Gateway eliminati o in attesa a causa di una classe di priorità mancante

I pod del gateway di rete in kube-system potrebbero mostrare lo stato Pending o Evicted, come mostrato nel seguente output di esempio condensato:


$ kubectl -n kube-system get pods | grep ang-node
ang-node-bjkkc     2/2     Running     0     5d2h
ang-node-mw8cq     0/2     Evicted     0     6m5s
ang-node-zsmq7     0/2     Pending     0     7h

Questi errori indicano eventi di eliminazione o l'impossibilità di pianificare i pod a causa delle risorse del nodo. Poiché i pod del gateway di rete Anthos non hanno prioritàClasse, hanno la stessa priorità predefinita di altri carichi di lavoro. Quando i nodi sono limitati dalle risorse, potrebbero essere rimossi i pod del gateway di rete. Questo comportamento è particolarmente negativo per il DaemonSet ang-node, poiché questi pod devono essere pianificati su un nodo specifico e non possono essere migrati.


Soluzione:

Esegui l'upgrade alla versione 1.15 o successive.

Come soluzione a breve termine, puoi assegnare manualmente una PrioritàClasse ai componenti del gateway Anthos di rete. Il controller Cluster Anthos su VMware sovrascrive queste modifiche manuali durante un processo di riconciliazione, ad esempio durante un upgrade del cluster.

  • Assegna la priorità Priority system-cluster-critical ai deployment dei controller di cluster ang-controller-manager e autoscaler.
  • Assegna la priorità Priority di system-node-critical al DaemonSet di nodi ang-daemon.
Upgrade e aggiornamenti 1.12, 1.13, 1.14, 1.15

L'upgrade del cluster di amministrazione non riesce dopo la registrazione del cluster con gcloud

Dopo aver utilizzato gcloud per registrare un cluster di amministrazione con una sezione gkeConnect non vuota, potresti riscontrare il seguente errore durante il tentativo di eseguire l'upgrade del cluster:


failed to register cluster: failed to apply Hub Mem\
bership: Membership API request failed: rpc error: code = InvalidArgument desc = InvalidFieldError for field endpoint.o\
n_prem_cluster.admin_cluster: field cannot be updated

Puoi eliminare lo spazio dei nomi gke-connect


kubectl delete ns gke-connect --kubeconfig=ADMIN_KUBECONFIG
e riprendere l'upgrade del cluster di amministrazione.
Operazione 1.13.0-1.13.8, 1.14.0-1.14.5, 1.15.0-1.15.1

gkectl diagnose snapshot --log-since non limita il periodo di tempo per i comandi journalctl in esecuzione sui nodi del cluster

Ciò non influisce sulla funzionalità di acquisizione di uno snapshot del cluster, poiché lo snapshot include ancora tutti i log raccolti per impostazione predefinita eseguendo journalctl sui nodi del cluster. Pertanto, non vengono perse le informazioni di debug.
Installazione, upgrade e aggiornamenti 1.9+, 1.10+, 1.11+, 1.12+

gkectl prepare windows non riusciti

gkectl prepare windows non installa Docker su Cluster Anthos su VMware versioni precedenti alla 1.13 perché MicrosoftDockerProvider è deprecato.


Soluzione:

L'idea generale per risolvere il problema è eseguire l'upgrade ad Cluster Anthos su VMware 1.13 e utilizzare gkectl 1.13 per creare un modello di VM Windows, quindi creare pool di nodi Windows. Esistono due opzioni per accedere ai cluster Anthos su VMware 1.13 dalla versione attuale, come mostrato di seguito.

Nota: sono disponibili opzioni per risolvere il problema nella tua versione attuale senza dover eseguire l'upgrade alla versione 1.13, ma richiederà ulteriori passaggi manuali. Se vuoi prendere in considerazione questa opzione, contatta il nostro team di assistenza.


Opzione 1: upgrade blu/verde

Puoi creare un nuovo cluster utilizzando la versione 1 di Cluster Anthos su VMware con pool di nodi Windows, ed eseguire la migrazione dei carichi di lavoro al nuovo cluster, quindi eliminare il cluster attuale. Ti consigliamo di utilizzare la versione secondaria di Anthos di ultima generazione.

Nota: richiedono risorse aggiuntive per il provisioning del nuovo cluster, ma riducono i tempi di inattività e le interruzioni per i carichi di lavoro esistenti.


Opzione 2: elimina i pool di nodi Windows e aggiungili di nuovo quando esegui l'upgrade ai cluster Anthos su VMware 1.13

Nota: per questa opzione, i carichi di lavoro di Windows non potranno essere eseguiti fino all'upgrade del cluster alla versione 1.13 e all'aggiunta dei pool di nodi Windows.

  1. Elimina i pool di nodi Windows esistenti rimuovendo la configurazione dei pool di nodi di Windows dal file user-cluster.yaml, quindi esegui il comando: 
    
gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
  2. Esegui l'upgrade dei cluster utente + amministratore solo a Linux alla versione 1.12 seguendo la guida dell'utente per l'upgrade per la versione secondaria di destinazione corrispondente.
  3. (Assicurati di eseguire questo passaggio prima di eseguire l'upgrade alla 1.13) Assicurati che enableWindowsDataplaneV2: true sia configurato in OnPremUserCluster CR, altrimenti il cluster continuerà a utilizzare Docker per i pool di nodi di Windows, che non sarà compatibile con il modello di VM di Windows 1.13 appena creato, in cui non è installato Docker. Se non viene configurato o se viene impostato su falso, aggiorna il cluster per impostarlo su vero in user-cluster.yaml, quindi esegui: 
    
gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
  4. Esegui l'upgrade alla versione 1.13 per i cluster di amministrazione e utente solo Linux, seguendo la guida all'upgrade degli utenti.
  5. Prepara il modello di VM Windows utilizzando 1.13 gkectl: 
    
gkectl prepare windows --base-vm-template BASE_WINDOWS_VM_TEMPLATE_NAME --bundle-path 1.13_BUNDLE_PATH --kubeconfig=ADMIN_KUBECONFIG
  6. Aggiungi di nuovo la configurazione del pool di nodi Windows a user-cluster.yaml con il campo OSImage impostato sul modello della VM Windows appena creato.
  7. Aggiorna il cluster per aggiungere pool di nodi Windows 
    
gkectl update cluster --kubeconfig=ADMIN_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE
Installazione, upgrade e aggiornamenti 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

La configurazione di RootDistanceMaxSec non è attiva per ubuntu nodi

Il valore predefinito di 5 secondi per RootDistanceMaxSec verrà utilizzato sui nodi, anziché 20 secondi, che dovrebbe essere la configurazione prevista. Se controlli il log di avvio del nodo mediante SSH nella VM, che si trova all'indirizzo "/var/log/startup.log", troverai il seguente errore:


+ has_systemd_unit systemd-timesyncd
/opt/bin/master.sh: line 635: has_systemd_unit: command not found

L'uso di RootDistanceMaxSec a 5 secondi potrebbe far sì che l'orologio di sistema non sia sincronizzato con il server NTP quando la deviazione dell'orologio è maggiore di 5 secondi.


Soluzione:

Accedi ai nodi tramite SSH e configura RootDistanceMaxSec:


mkdir -p /etc/systemd/timesyncd.conf.d
cat > /etc/systemd/timesyncd.conf.d/90-gke.conf <<EOF
[Time]
RootDistanceMaxSec=20
EOF
systemctl restart systemd-timesyncd
Upgrade e aggiornamenti 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

gkectl update admin non riuscito a causa di un campo osImageType vuoto

Quando utilizzi la versione 1.13 gkectl per aggiornare un cluster di amministrazione versione 1.12, potresti visualizzare il seguente errore:


Failed to update the admin cluster: updating OS image type in admin cluster
is not supported in "1.12.x-gke.x"

Quando utilizzi gkectl update admin per i cluster versione 1.13 o 1.14, potresti vedere il seguente messaggio nella risposta:


Exit with error:
Failed to update the cluster: the update contains multiple changes. Please
update only one feature at a time

Se controlli il log gkectl, potresti notare che le varie modifiche includono l'impostazione di osImageType da una stringa vuota a ubuntu_containerd.

Questi errori di aggiornamento sono dovuti al backfill improprio del campo osImageType nella configurazione del cluster di amministrazione, dalla sua introduzione nella versione 1.9.


Soluzione:

Esegui l'upgrade a una versione di Cluster Anthos su VMware con la correzione. Se non è possibile eseguire l'upgrade, contatta l'assistenza clienti Google Cloud per risolvere il problema.
Installazione, sicurezza 1.13, 1.14, 1.15

SNI non funziona su cluster utente con Controlplane V2

La possibilità di fornire un certificato di gestione aggiuntivo per il server API di Kubernetes di un cluster utente con authentication.sni non funziona se è abilitato il piano di controllo V2 ( enableControlplaneV2: true).


Soluzione:

Finché non è disponibile una patch di Cluster Anthos su VMware con la correzione, se devi utilizzare SNI, disabilita Controlplane V2 (enableControlplaneV2: false).
Installazione 1.0-1.11, 1.12, 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

$ nel nome utente del registro privato causa un errore di avvio della macchina del piano di controllo amministrativo

L'avvio del computer del piano di controllo amministratore non riesce quando il nome utente del registro privato contiene $. Quando controlli /var/log/startup.log sul computer del piano di controllo amministratore, viene visualizzato il seguente errore: 


++ REGISTRY_CA_CERT=xxx
++ REGISTRY_SERVER=xxx
/etc/startup/startup.conf: line 7: anthos: unbound variable

Soluzione:

Utilizza un nome utente di registro privato senza $ oppure utilizza una versione di Cluster Anthos su VMware con la correzione.
Upgrade e aggiornamenti 1.12.0-1.12.4

Avviso di falsi positivi sulle modifiche non supportate durante l'aggiornamento del cluster di amministrazione

Quando aggiorni i cluster di amministrazione, nel log vengono visualizzati i seguenti avvisi con falsi positivi e puoi ignorarli. 


    console.go:47] detected unsupported changes: &v1alpha1.OnPremAdminCluster{
      ...
      - 		CARotation:        &v1alpha1.CARotationConfig{Generated: &v1alpha1.CARotationGenerated{CAVersion: 1}},
      + 		CARotation:        nil,
      ...
    }
Upgrade e aggiornamenti 1.13.0-1.13.9, 1.14.0-1.14.5, 1.15.0-1.15.1

Aggiornamento del cluster utente non riuscito dopo la rotazione della chiave di firma KSA

Dopo aver rotato le chiavi di firma KSA e aver successivamente aggiornato un cluster utente, gkectl update potrebbe non riuscire con il seguente messaggio di errore: 


Failed to apply OnPremUserCluster 'USER_CLUSTER_NAME-gke-onprem-mgmt/USER_CLUSTER_NAME':
admission webhook "vonpremusercluster.onprem.cluster.gke.io" denied the request:
requests must not decrement *v1alpha1.KSASigningKeyRotationConfig Version, old version: 2, new version: 1"


Soluzione:

Ripristina la versione 1 della versione della chiave di firma KSA, ma conserva i dati più recenti della chiave:
  1. Controlla il secret nel cluster di amministrazione sotto lo spazio dei nomi USER_CLUSTER_NAME e prendi il nome del secret ksa-signing-key: 
    
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secrets | grep ksa-signing-key
  2. Copia il secret di ksa-signing-key e nomina il secret copiato come service-account-cert: 
    
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME get secret KSA-KEY-SECRET-NAME -oyaml | \
sed 's/ name: .*/ name: service-account-cert/' | \
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME apply -f -
  3. Elimina il secret ksa-signing-key precedente: 
    
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME delete secret KSA-KEY-SECRET-NAME
  4. Aggiorna il campo data.data nella mappa di configurazione ksa-signing-key-rotation-stage a '{"tokenVersion":1,"privateKeyVersion":1,"publicKeyVersions":[1]}': 
    
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME \
edit configmap ksa-signing-key-rotation-stage
  5. Disabilita il webhook di convalida per modificare le informazioni sulla versione nella risorsa personalizzata OnPremUserCluster: 
    
kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
webhooks:
- name: vonpremnodepool.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    resources:
    - onpremnodepools
- name: vonpremusercluster.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    resources:
    - onpremuserclusters
'
  6. Aggiorna il campo spec.ksaSigningKeyRotation.generated.ksaSigningKeyRotation in 1 nella risorsa personalizzata OnPremUserCluster: 
    
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
edit onpremusercluster USER_CLUSTER_NAME
  7. Attendi che il cluster utente di destinazione sia pronto. Puoi controllare lo stato: 
    
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=USER_CLUSTER_NAME-gke-onprem-mgmt \
get onpremusercluster
  8. Ripristina il webhook di convalida per il cluster utente: 
    
kubectl --kubeconfig=ADMIN_KUBECONFIG patch validatingwebhookconfiguration onprem-user-cluster-controller -p '
webhooks:
- name: vonpremnodepool.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    - UPDATE
    resources:
    - onpremnodepools
- name: vonpremusercluster.onprem.cluster.gke.io
  rules:
  - apiGroups:
    - onprem.cluster.gke.io
    apiVersions:
    - v1alpha1
    operations:
    - CREATE
    - UPDATE
    resources:
    - onpremuserclusters
'
  9. Evita un'altra rotazione della chiave di firma KSA finché non viene eseguito l'upgrade del cluster alla versione con la correzione.
Operazione 1.13.1+, 1.14, 1.15

I server virtuali F5 BIG-IP non vengono puliti quando Terraform elimina i cluster utente.

Quando utilizzi Terraform per eliminare un cluster utente con un bilanciatore del carico BIG-IP F5, i server virtuali BIG-IP di F5 non vengono rimossi dopo l'eliminazione del cluster.


Soluzione:

Per rimuovere le risorse F5, segui i passaggi per ripulire una partizione F5 del cluster utente
Installazione, upgrade e aggiornamenti 1.13.8, 1.14.4

Tipo di cluster che esegue il pull delle immagini container da docker.io

Se crei un cluster di amministrazione versione 1.13.8 o 1.14.4 o esegui l'upgrade di un cluster di amministrazione alla versione 1.13.8 o 1.14.4, il tipo di cluster estrae le seguenti immagini container da docker.io:

  • docker.io/kindest/kindnetd
  • docker.io/kindest/local-path-provisioner
  • docker.io/kindest/local-path-helper

    • Se docker.io non è accessibile dalla workstation di amministrazione, la creazione o l'upgrade del cluster di amministrazione non riesce a visualizzare il cluster di tipo. L'esecuzione del seguente comando sulla workstation di amministrazione mostra i container corrispondenti in attesa con ErrImagePull:

    
docker exec gkectl-control-plane kubectl get pods -A

    La risposta contiene voci come le seguenti:

    
...
kube-system         kindnet-xlhmr                             0/1
    ErrImagePull  0    3m12s
...
local-path-storage  local-path-provisioner-86666ffff6-zzqtp   0/1
    Pending       0    3m12s
...

    Queste immagini container devono essere precaricate nell'immagine container del cluster. Tuttavia, il tipo v0.18.0 presenta un problema con le immagini container precaricate, che causa il loro estrazione da Internet per errore.


    Soluzione:

    Esegui i comandi seguenti sulla workstation di amministrazione, mentre il cluster di amministrazione è in attesa di creazione o upgrade:

    
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/kindnetd:v20230330-48f316cd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af docker.io/kindest/kindnetd:v20230330-48f316cd
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/kindnetd:v20230330-48f316cd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af docker.io/kindest/kindnetd@sha256:c19d6362a6a928139820761475a38c24c0cf84d507b9ddf414a078cf627497af

docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-helper:v20230330-48f316cd@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270 docker.io/kindest/local-path-helper:v20230330-48f316cd
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-helper:v20230330-48f316cd@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270 docker.io/kindest/local-path-helper@sha256:135203f2441f916fb13dad1561d27f60a6f11f50ec288b01a7d2ee9947c36270

docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-provisioner:v0.0.23-kind.0@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501 docker.io/kindest/local-path-provisioner:v0.0.23-kind.0
docker exec gkectl-control-plane ctr -n k8s.io images tag docker.io/kindest/local-path-provisioner:v0.0.23-kind.0@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501 docker.io/kindest/local-path-provisioner@sha256:f2d0a02831ff3a03cf51343226670d5060623b43a4cfc4808bd0875b2c4b9501
    Operazione 1.13.0-1.13.7, 1.14.0-1.14.4, 1.15.0

    Failover su cluster utente e piano di amministrazione HA Controlplane V2 quando la rete filtra le richieste GARP duplicate

    Se le VM del tuo cluster sono collegate con uno switch che filtra le richieste GARP (Gratisus ARP) duplicate, le elezioni di leader leader potrebbero avere una race condition, il che fa sì che alcuni nodi abbiano voci di tabella ARP errate.

    I nodi interessati possono ping il VIP del piano di controllo, ma le connessioni TCP al VIP del piano di controllo scadranno.


    Soluzione:

    Esegui il comando seguente su ciascun nodo del piano di controllo del cluster interessato: 
    
    iptables -I FORWARD -i ens192 --destination CONTROL_PLANE_VIP -j DROP
    Upgrade e aggiornamenti 1.13.0-1.13.7, 1.14.0-1.14.4, 1.15.0

    È necessario riavviare vsphere-csi-controller dopo la rotazione del certificato vCenter

    vsphere-csi-controller deve aggiornare il secret di vCenter dopo la rotazione del certificato di vCenter. Tuttavia, il sistema attuale non riavvia correttamente i pod di vsphere-csi-controller, causando un arresto anomalo di vsphere-csi-controller dopo la rotazione.

    Soluzione:

    Per i cluster creati alla 1.13 e a versioni successive, segui le istruzioni riportate di seguito per riavviare vsphere-csi-controller 

    
kubectl --kubeconfig=ADMIN_KUBECONFIG rollout restart deployment vsphere-csi-controller -n kube-system
    Installazione 1.10.3-1.10.7, 1.11, 1.12, 1.13.0-1.13.1

    La creazione del cluster di amministrazione non restituisce errori relativi alla registrazione del cluster

    Anche se la registrazione del cluster non riesce durante la creazione del cluster di amministrazione, il comando gkectl create admin non restituisce un errore e potrebbe riuscire. In altre parole, la creazione del cluster di amministrazione poteva essere "riuscita" senza essere registrata in un parco risorse.

    Per identificare il sintomo, puoi cercare i seguenti messaggi di errore nel log di "gkectl create admin", 
    
Failed to register admin cluster

    Puoi anche verificare se riesci a trovare il cluster tra i cluster registrati su Cloud Console.

    Soluzione:

    Per i cluster creati alla versione 1.12 e successive, segui le istruzioni per ritentare la registrazione del cluster di amministrazione dopo la creazione del cluster. Per i cluster creati nelle versioni precedenti,

    1. Aggiungi una coppia chiave-valore falsa, ad esempio "foo: bar", al file della chiave SA di Connect-register
    2. Esegui gkectl update admin per registrare di nuovo il cluster di amministrazione.

    Upgrade e aggiornamenti 1.10, 1.11, 1.12, 1.13.0-1.13.1

    La nuova registrazione del cluster di amministrazione potrebbe essere ignorata durante l'upgrade del cluster di amministrazione

    Durante l'upgrade del cluster di amministrazione, se l'upgrade dei nodi del piano di controllo utente scade, il cluster di amministrazione non verrà registrato nuovamente con la versione aggiornata dell'agente di connessione.


    Soluzione:

    Controlla se il cluster viene visualizzato tra i cluster registrati. Come passaggio facoltativo, accedi al cluster dopo aver configurato l'autenticazione. Se il cluster è ancora registrato, puoi ignorare le seguenti istruzioni per riprovare a eseguire la registrazione. Per i cluster aggiornati alle versioni 1.12 e successive, segui le istruzioni per tentativi di registrare nuovamente il cluster di amministrazione dopo la creazione del cluster. Per i cluster di cui è stato eseguito l'upgrade a versioni precedenti,
    1. Aggiungi una coppia chiave-valore falsa, ad esempio "foo: bar", al file della chiave SA di Connect-register
    2. Esegui gkectl update admin per registrare di nuovo il cluster di amministrazione.

    Configurazione 1,15,0

    Messaggio di errore falso su vCenter.dataDisk

    Per un cluster di amministrazione ad alta disponibilità, gkectl prepare mostra questo messaggio di errore falso:

    
vCenter.dataDisk must be present in the AdminCluster spec

    Soluzione:

    Puoi ignorare questo messaggio di errore.
    VMware 1,15,0

    Creazione del pool di nodi non riuscita a causa di regole di affinità ridondanti per un host VM

    Durante la creazione di un pool di nodi che utilizza l'affinità Host di VM, una race condition potrebbe causare la creazione di più regole di affinità Host di VM con lo stesso nome. La creazione del pool di nodi potrebbe non riuscire.


    Soluzione:

    Rimuovi le vecchie regole ridondanti in modo che possa essere eseguita la creazione del pool di nodi. Queste regole sono denominate [USER_CLUSTER_NAME]-[HASH].
    Operazione 1,15,0

    gkectl repair admin-master potrebbe non riuscire a causa di failed to delete the admin master node object and reboot the admin master VM

    Il comando gkectl repair admin-master potrebbe non riuscire a causa di una race condition con il seguente errore. 

    
Failed to repair: failed to delete the admin master node object and reboot the admin master VM


    Soluzione:

    Questo comando è idempotente. Può essere eseguito di nuovo in sicurezza finché il comando non ha esito positivo.
    Upgrade e aggiornamenti 1,15,0

    I pod rimangono in stato Creazione non riuscita per aggiornamento o aggiornamento di un nodo del piano di controllo

    Dopo aver ricreato o aggiornato un nodo del piano di controllo, alcuni pod potrebbero rimanere nello stato Failed a causa di un errore del predicato NodeAffinity. Questi pod in errore non influiscono sulle normali operazioni o sull'integrità del cluster.


    Soluzione:

    Puoi ignorare i pod in errore o eliminarli manualmente.
    Sicurezza, configurazione 1,15

    OnPremUserCluster non è pronto a causa delle credenziali di registro private

    Se utilizzi credenziali precompilate e un registro privato, ma non hai configurato credenziali preparate per il tuo registro privato, OnPremUserCluster potrebbe non essere pronto e potrebbe essere visualizzato il seguente messaggio di errore: 

    
failed to check secret reference for private registry …


    Soluzione:

    Prepara le credenziali del Registro di sistema privato per il cluster utente secondo le istruzioni in Configurare le credenziali preparate.

    Upgrade e aggiornamenti 1,15,0

    gkectl upgrade admin non riesce con StorageClass standard sets the parameter diskformat which is invalid for CSI Migration

    Durante il gkectl upgrade admin, il controllo preflight dello spazio di archiviazione per la migrazione CSI verifica che gli oggetti StorageClass non includano parametri ignorati dopo la migrazione. Ad esempio, se è presente un valore StorageClass con il parametro diskformat, gkectl upgrade admin segnala quest'ultimo e segnala un errore nella convalida preflight. I cluster di amministrazione creati in Anthos 1.10 e in precedenza hanno un oggetto StorageClass con diskformat: thin, che non supererà questa convalida, ma questo oggetto StorageClass funziona ancora dopo la migrazione CSI. Questi errori dovrebbero invece essere interpretati come avvisi.

    Per ulteriori informazioni, controlla la sezione del parametro StorageClass in Migrazione dei volumi vSphere in-trere a plug-in di archiviazione container vSphere.


    Soluzione:

    Dopo aver confermato che il cluster ha un oggetto StorageClass con parametri ignorati dopo la migrazione CSI, esegui gkectl upgrade admin con il flag --skip-validation-cluster-health.
    Archiviazione 1,15

    I volumi vSphere di cui è stata eseguita la migrazione con il file system Windows non possono essere utilizzati con il driver CSI vSphere

    In determinate condizioni, i dischi possono essere collegati in sola lettura ai nodi Windows. Di conseguenza, il volume corrispondente è di sola lettura all'interno di un pod. Questo problema ha maggiori probabilità di verificarsi quando un nuovo set di nodi sostituisce un vecchio set di nodi (ad esempio l'upgrade del cluster o l'aggiornamento del pool di nodi). I carichi di lavoro stateful che in precedenza funzionavano correttamente potrebbero non essere in grado di scrivere nei loro volumi sul nuovo set di nodi.


    Soluzione:

    1. Recupera l'UID del pod che non è in grado di scrivere nel relativo volume: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pod \
    POD_NAME --namespace POD_NAMESPACE \
    -o=jsonpath='{.metadata.uid}{"\n"}'
    2. Utilizza PersistentVolumeClaim per ottenere il nome del PersistentVolume: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pvc \
    PVC_NAME --namespace POD_NAMESPACE \
    -o jsonpath='{.spec.volumeName}{"\n"}'
    3. Determina il nome del nodo in cui è in esecuzione il pod: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIGget pods \
    --namespace POD_NAMESPACE \
    -o jsonpath='{.spec.nodeName}{"\n"}'
    4. Ottenere l'accesso di PowerShell al nodo, tramite SSH o l'interfaccia web di vSphere.
    5. Imposta le variabili di ambiente: 
      
PS C:\Users\administrator> pvname=PV_NAME
PS C:\Users\administrator> podid=POD_UID
    6. Identifica il numero del disco per il disco associato al PersistentVolume: 
      
PS C:\Users\administrator> disknum=(Get-Partition -Volume (Get-Volume -UniqueId ("\\?\"+(Get-Item (Get-Item
"C:\var\lib\kubelet\pods\$podid\volumes\kubernetes.io~csi\$pvname\mount").Target).Target))).DiskNumber
    7. Verifica che il disco sia readonly: 
      
PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
      Il risultato dovrebbe essere True.
    8. Imposta readonly su false. 
      
PS C:\Users\administrator> Set-Disk -Number $disknum -IsReadonly $false
PS C:\Users\administrator> (Get-Disk -Number $disknum).IsReadonly
    9. Elimina il pod in modo che venga riavviato: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete pod POD_NAME \
    --namespace POD_NAMESPACE
    10. Il pod deve essere pianificato sullo stesso nodo. Tuttavia, nel caso in cui il pod viene pianificato su un nuovo nodo, potrebbe essere necessario ripetere i passaggi precedenti sul nuovo nodo.

    Upgrade e aggiornamenti 1.12, 1.13.0-1.13.7, 1.14.0-1.14.4

    vsphere-csi-secret non viene aggiornato dopo la data gkectl update credentials vsphere --admin-cluster

    Se aggiorni le credenziali di vSphere per un cluster di amministrazione dopo l'aggiornamento delle credenziali del cluster, potresti trovare vsphere-csi-secret nello spazio dei nomi kube-system nel cluster di amministrazione che utilizza ancora le vecchie credenziali.


    Soluzione:

    1. Ottieni il nome del secret vsphere-csi-secret: 
      
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets | grep vsphere-csi-secret
    2. Aggiorna i dati del secret vsphere-csi-secret che hai ricevuto nel passaggio precedente: 
      
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system patch secret CSI_SECRET_NAME -p \
  "{\"data\":{\"config\":\"$( \
    kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system get secrets CSI_SECRET_NAME -ojsonpath='{.data.config}' \
      | base64 -d \
      | sed -e '/user/c user = \"VSPHERE_USERNAME_TO_BE_UPDATED\"' \
      | sed -e '/password/c password = \"VSPHERE_PASSWORD_TO_BE_UPDATED\"' \
      | base64 -w 0 \
    )\"}}"
    3. Riavvia vsphere-csi-controller: 
      
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout restart deployment vsphere-csi-controller
    4. Puoi monitorare lo stato dell'implementazione con: 
      
kubectl --kubeconfig=ADMIN_KUBECONFIG -n=kube-system rollout status deployment vsphere-csi-controller
      Dopo l'implementazione del deployment, il controller dovrebbe usare il comando vsphere-csi-secret aggiornato.
    Upgrade e aggiornamenti 1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

    audit-proxy arresto anomalo durante l'abilitazione di Cloud Audit Logs con gkectl update cluster

    audit-proxy potrebbe arrestarsi in modo anomalo a causa di --cluster-name vuoto. Questo comportamento è causato da un bug nella logica di aggiornamento, in cui il nome del cluster non viene propagato al pod / proxy container manifest.


    Soluzione:

    Per un cluster utente del piano di controllo v2 con enableControlplaneV2: true, connettiti alla macchina del piano di controllo dell'utente utilizzando SSH e aggiorna /etc/kubernetes/manifests/audit-proxy.yaml con --cluster_name=USER_CLUSTER_NAME.

    Per un cluster utente del piano di controllo v1, modifica il container audit-proxy nello StatefulSet kube-apiserver per aggiungere --cluster_name=USER_CLUSTER_NAME:

    
kubectl edit statefulset kube-apiserver -n USER_CLUSTER_NAME --kubeconfig=ADMIN_CLUSTER_KUBECONFIG
    Upgrade e aggiornamenti 1.11, 1.12, 1.13.0-1.13.5, 1.14.0-1.14.1

    Un ulteriore deployment del piano di controllo subito dopo gkectl upgrade cluster

    Subito dopo il giorno gkectl upgrade cluster, potrebbe essere eseguito nuovamente il deployment dei pod del piano di controllo. Lo stato del cluster da gkectl list clusters è cambiato da RUNNING a RECONCILING. Le richieste al cluster utente potrebbero scadere.

    Questo comportamento è dovuto alla rotazione automatica del certificato del piano di controllo dopo il giorno gkectl upgrade cluster.

    Questo problema si verifica solo per i cluster utente che NON utilizzano il piano di controllo (v2).


    Soluzione:

    Attendi che lo stato del cluster torni di nuovo a RUNNING in gkectl list clusters oppure esegui l'upgrade alle versioni con correzione 1.13.6+, 1.14.2+ o 1.15+.
    Upgrade e aggiornamenti 1,12,7

    È stata rimossa la versione errata 1.12.7-gke.19

    Cluster Anthos su VMware 1.12.7-gke.19 è una release scadente e non dovresti usarlo. Gli artefatti sono stati rimossi dal bucket Cloud Storage.

    Soluzione:

    Usa invece la release 1.12.7-gke.20.
    Upgrade e aggiornamenti 1.12.0+, 1.13.0-1.13.7, 1.14.0-1.14.3

    gke-connect-agent continua a utilizzare l'immagine precedente dopo l'aggiornamento delle credenziali

    Se aggiorni le credenziali del Registro di sistema utilizzando uno dei seguenti metodi:

    • gkectl update credentials componentaccess se non utilizzi il registro privato
    • gkectl update credentials privateregistry se utilizzi il registro privato

    potresti notare che gke-connect-agent continua a utilizzare l'immagine meno recente o che i pod gke-connect-agent non possono essere recuperati a causa di ImagePullBackOff.

    Questo problema verrà risolto nelle versioni di Cluster Anthos su VMware 1.13.8, 1.14.4 e successive.


    Soluzione:

    Opzione 1: esegui nuovamente il deployment di gke-connect-agent:

    1. Elimina lo spazio dei nomi gke-connect: 
      
kubectl --kubeconfig=KUBECONFIG delete namespace gke-connect
    2. Esegui nuovamente il deployment di gke-connect-agent con la chiave dell'account di servizio di registrazione originale (non è necessario aggiornare la chiave):

      Per il cluster di amministrazione: 
      
gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG_FILE --admin-cluster
      Per il cluster utente: 
      
gkectl update credentials register --kubeconfig=ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG_FILE

    Opzione 2: puoi modificare manualmente i dati del secret pull dell'immagine regcred utilizzato dal deployment di gke-connect-agent:

    
kubectl --kubeconfig=KUBECONFIG -n=gke-connect patch secrets regcred -p "{\"data\":{\".dockerconfigjson\":\"$(kubectl --kubeconfig=KUBECONFIG -n=kube-system get secrets private-registry-creds -ojsonpath='{.data.\.dockerconfigjson}')\"}}"

    Opzione 3: puoi aggiungere il secret di pull dell'immagine predefinito per il tuo cluster nel deployment gke-connect-agent mediante:

    1. Copia il secret predefinito nello spazio dei nomi gke-connect: 
      
kubectl --kubeconfig=KUBECONFIG -n=kube-system get secret private-registry-creds -oyaml | sed 's/ namespace: .*/ namespace: gke-connect/' | kubectl --kubeconfig=KUBECONFIG -n=gke-connect apply -f -
    2. Ottieni il nome del deployment gke-connect-agent: 
      
kubectl --kubeconfig=KUBECONFIG -n=gke-connect get deployment | grep gke-connect-agent
    3. Aggiungi il secret predefinito al deployment di gke-connect-agent: 
      
kubectl --kubeconfig=KUBECONFIG -n=gke-connect patch deployment DEPLOYMENT_NAME -p '{"spec":{"template":{"spec":{"imagePullSecrets": [{"name": "private-registry-creds"}, {"name": "regcred"}]}}}}'
    Installazione 1.13, 1.14

    Controllo manuale della configurazione del bilanciatore del carico manuale non riuscito

    Quando convalidi la configurazione prima di creare un cluster con il bilanciatore del carico manuale eseguendo gkectl check-config, il comando avrà esito negativo con i seguenti messaggi di errore.

    
 - Validation Category: Manual LB    Running validation check for "Network
configuration"...panic: runtime error: invalid memory address or nil pointer
dereference

    Soluzione:

    Opzione 1: puoi utilizzare la versione 1.13.7 e 1.14.4 della patch che includerà la correzione.

    Opzione 2: puoi anche eseguire lo stesso comando per convalidare la configurazione, ma saltare la convalida del bilanciatore del carico.

    
gkectl check-config --skip-validation-load-balancer
    Operazione 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13 e 1.14

    eccetera

    I cluster che eseguono etcd 3.4.13 o versioni precedenti potrebbero riscontrare la fame di orologi e risorse non operative, il che può causare i seguenti problemi:

    • Pianificazione dei pod interrotta
    • Impossibile registrare i nodi
    • kubelet non osserva le modifiche ai pod

    Questi problemi possono rendere il cluster non funzionale.

    Questo problema è stato risolto nei cluster Anthos su VMware release 1.12.7, 1.13.6, 1.14.3 e versioni successive. Queste release più recenti utilizzano la versione 3.4.21 di etcd. Tutte le versioni precedenti di Cluster Anthos su VMware sono interessate da questo problema.

    Soluzione

    Se non puoi eseguire l'upgrade immediatamente, puoi ridurre il rischio di errori del cluster riducendo il numero di nodi nel cluster. Rimuovi i nodi finché la metrica etcd_network_client_grpc_sent_bytes_total non è inferiore a 300 MBps.

    Per visualizzare questa metrica in Metrics Explorer:

    1. Vai a Metrics Explorer nella console Google Cloud:

      Vai a Metrics Explorer

    2. Seleziona la scheda Configurazione.
    3. Espandi la sezione Seleziona una metrica, inserisci Kubernetes Container nella barra dei filtri e utilizza i sottomenu per selezionare la metrica:
      1. Nel menu Risorse attive, seleziona Container Kubernetes.
      2. Nel menu Categorie di metriche attive, seleziona Anthos.
      3. Nel menu Metriche attive, seleziona etcd_network_client_grpc_sent_bytes_total.
      4. Fai clic su Applica.
    Upgrade e aggiornamenti 1.10, 1.11, 1.12, 1.13 e 1.14

    Il servizio Anthos Identity può causare latenze del piano di controllo

    Al riavvio o all'upgrade del cluster, il servizio Anthos Identity può essere sovraccarico dal traffico costituito da token JWT scaduti inoltrati dal servizio kube-apiserver ad Anthos Identity Service tramite il webhook di autenticazione. Anche se il servizio Anthos Identity non si arresta in modo anomalo, non risponde più e non soddisfa più richieste. Questo problema alla fine porta a maggiori latenze del piano di controllo.

    Questo problema è stato risolto nelle seguenti release di Cluster Anthos su VMware:

    • 1,12,6+
    • 1,13,6+
    • 1,14,2+

    Per verificare se il problema ti riguarda, procedi nel seguente modo:

    1. Verifica se l'endpoint del servizio Anthos Identity può essere raggiunto esternamente: 
      
curl -s -o /dev/null -w "%{http_code}" \
    -X POST https://CLUSTER_ENDPOINT/api/v1/namespaces/anthos-identity-service/services/https:ais:https/proxy/authenticate -d '{}'

      Sostituisci CLUSTER_ENDPOINT con il VIP e la porta del bilanciatore del carico del piano di controllo per il cluster (ad esempio 172.16.20.50:443).

      Se questo problema ti riguarda, il comando restituisce un codice di stato 400. Se la richiesta scade, riavvia il pod ais ed esegui nuovamente il comando curl per vedere se il problema si risolve. Se ricevi un codice di stato 000, il problema è stato risolto. Se ricevi ancora un codice di stato 400, il server HTTP Anthos Identity Service non si avvia. In questo caso, continua.

    2. Controlla i log del servizio Anthos Identity e di kube-apiserver:
      1. Controlla il log del servizio Anthos Identity: 
        
kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
    --kubeconfig KUBECONFIG

        Se il log contiene una voce simile alla seguente, significa che hai riscontrato questo problema:

        
I0811 22:32:03.583448      32 authentication_plugin.cc:295] Stopping OIDC authentication for ???. Unable to verify the OIDC ID token: JWT verification failed: The JWT does not appear to be from this identity provider. To match this provider, the 'aud' claim must contain one of the following audiences:
      2. Controlla i log kube-apiserver per i tuoi cluster:

        Nei comandi seguenti, KUBE_APISERVER_POD è il nome del pod kube-apiserver nel cluster specificato.

        Cluster di amministrazione:

        
kubectl --kubeconfig ADMIN_KUBECONFIG logs \
    -n kube-system KUBE_APISERVER_POD kube-apiserver

        Cluster utente:

        
kubectl --kubeconfig ADMIN_KUBECONFIG logs \
    -n USER_CLUSTER_NAME KUBE_APISERVER_POD kube-apiserver

        Se i log di kube-apiserver contengono voci come le seguenti, il problema ti riguarda:

        
E0811 22:30:22.656085       1 webhook.go:127] Failed to make webhook authenticator request: error trying to reach service: net/http: TLS handshake timeout
E0811 22:30:22.656266       1 authentication.go:63] "Unable to authenticate the request" err="[invalid bearer token, error trying to reach service: net/http: TLS handshake timeout]"

    Soluzione

    Se non puoi eseguire l'upgrade dei tuoi cluster immediatamente per ottenere la correzione, puoi identificare e riavviare i pod offensivi come soluzione alternativa:

    1. Aumenta il livello di livello di dettaglio del servizio Anthos Identity a 9: 
      
kubectl patch deployment ais -n anthos-identity-service --type=json \
    -p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", \
    "value":"--vmodule=cloud/identity/hybrid/charon/*=9"}]' \
    --kubeconfig KUBECONFIG
    2. Controlla nel log del servizio Anthos Identity il contesto del token non valido: 
      
kubectl logs -f -l k8s-app=ais -n anthos-identity-service \
    --kubeconfig KUBECONFIG
    3. Per ottenere il payload del token associato a ogni contesto di token non valido, analizza ogni secret dell'account di servizio correlato con il seguente comando: 
      
kubectl -n kube-system get secret SA_SECRET \
    --kubeconfig KUBECONFIG \
    -o jsonpath='{.data.token}' | base64 --decode
    4. Per decodificare il token e visualizzare il nome e lo spazio dei nomi del pod di origine, copia il token nel debugger su jwt.io.
    5. Riavvia i pod identificati dai token.
    Operazione 1.8, 1.9, 1.10

    Il problema di aumento dell'utilizzo della memoria dei pod di manutenzione etcd

    Sono interessati i pod di manutenzione etcd che utilizzano l'immagine etcddefrag:gke_master_etcddefrag_20210211.00_p0. Il container "etcddefrag" apre una nuova connessione al server etcd durante ogni ciclo di fresca e le vecchie connessioni non vengono pulite.


    Soluzione:

    Opzione 1: esegui l'upgrade all'ultima versione della patch dalla 1.8 alla 1.11, che contiene la correzione.

    Opzione 2: se utilizzi una versione patch precedente alle 1.9.6 e 1.10.3, devi fare lo scale down del pod etcd-maintenance per cluster di amministratori e utenti:

    
kubectl scale --replicas 0 deployment/gke-master-etcd-maintenance -n USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
kubectl scale --replicas 0 deployment/gke-master-etcd-maintenance -n kube-system --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    Operazione 1.9, 1.10, 1.11, 1.12, 1.13

    Mancano i controlli di integrità dei pod del piano di controllo del cluster utente

    Sia il controller di integrità del cluster sia il comando gkectl diagnose cluster eseguono una serie di controlli di integrità, tra cui i controlli di integrità dei pod negli spazi dei nomi. Tuttavia, iniziano a ignorare i pod del piano di controllo dell'utente per errore. Se utilizzi la modalità v2 del piano di controllo, questo non influirà sul cluster.


    Soluzione:

    Ciò non influirà sulla gestione dei carichi di lavoro o del cluster. Se vuoi controllare l'integrità dei pod del piano di controllo, puoi eseguire i comandi seguenti:

    
kubectl get pods -owide -n USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    Upgrade e aggiornamenti 1.6+, 1.7+

    Gli upgrade dei cluster di amministrazione 1.6 e 1.7 possono essere interessati dal reindirizzamento k8s.gcr.io -> registry.k8s.io

    Kubernetes ha reindirizzato il traffico da k8s.gcr.io a registry.k8s.io il 20/03/2023. Nei cluster Anthos su VMware 1.6.xe 1.7.x, gli upgrade del cluster di amministrazione utilizzano l'immagine container k8s.gcr.io/pause:3.2. Se utilizzi un proxy per la workstation di amministrazione e il proxy non consente registry.k8s.io e l'immagine container k8s.gcr.io/pause:3.2 non viene memorizzata nella cache locale, gli upgrade del cluster di amministrazione non riusciranno quando esegui il pull dell'immagine container.


    Soluzione:

    Aggiungi registry.k8s.io alla lista consentita del proxy per la workstation di amministrazione.
    Networking 1.10, 1.11, 1.12.0-1.12.6, 1.13.0-1.13.6, 1.14.0-1.14.2

    Errore di convalida Seesaw alla creazione del bilanciatore del carico

    gkectl create loadbalancer non riesce con il seguente messaggio di errore:

    
- Validation Category: Seesaw LB - [FAILURE] Seesaw validation: xxx cluster lb health check failed: LB"xxx.xxx.xxx.xxx" is not healthy: Get "http://xxx.xxx.xxx.xxx:xxx/healthz": dial tcpxxx.xxx.xxx.xxx:xxx: connect: no route to host

    Ciò è dovuto al file di gruppo di alta qualità già esistente. Inoltre, il controllo preflight tenta di convalidare un bilanciatore del carico dondolo inesistente.

    Soluzione:

    Rimuovi il file del gruppo di alta qualità esistente per questo cluster. Il nome del file è seesaw-for-gke-admin.yaml per il cluster di amministrazione e seesaw-for-{CLUSTER_NAME}.yaml per un cluster utente.
    Networking 1,14

    Timeout dell'applicazione causati da errori di inserimento della tabella di connessione

    I cluster Anthos su VMware versione 1.14 sono soggetti a errori di inserimento della tabella di connessione alla rete netfilter (conntrack) quando si utilizzano immagini di sistema operativo Ubuntu o COS. Gli errori di inserzione generano timeout casuali dell'applicazione e possono verificarsi anche quando la tabella di monitoraggio ha spazio per nuove voci. Gli errori sono causati da modifiche nel kernel 5.15 e versioni successive che limitano gli inserimenti di tabelle in base alla lunghezza della catena.

    Per scoprire se hai riscontrato questo problema, puoi controllare le statistiche del sistema di monitoraggio delle connessioni nel kernel su ciascun nodo con il seguente comando:

    
sudo conntrack -S

    La risposta ha il seguente aspetto:

    
cpu=0       found=0 invalid=4 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=1       found=0 invalid=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=2       found=0 invalid=16 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=3       found=0 invalid=13 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=4       found=0 invalid=9 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0
cpu=5       found=0 invalid=1 insert=0 insert_failed=0 drop=0 early_drop=0 error=519 search_restart=0 clash_resolve=126 chaintoolong=0
...

    Se il valore chaintoolong nella risposta è un numero diverso da zero, questo problema ti riguarda.

    Soluzione

    La mitigazione a breve termine consiste nell'aumentare le dimensioni sia della tabella hash netfiler (nf_conntrack_buckets) che della tabella di monitoraggio delle connessioni netfilter (nf_conntrack_max). Utilizza i seguenti comandi su ciascun nodo del cluster per aumentare le dimensioni delle tabelle:

    
sysctl -w net.netfilter.nf_conntrack_buckets=TABLE_SIZE
sysctl -w net.netfilter.nf_conntrack_max=TABLE_SIZE

    Sostituisci TABLE_SIZE con una nuova dimensione in byte. Il valore predefinito della dimensione della tabella è 262144. Ti suggeriamo di impostare un valore pari a 65.536 volte il numero di core sul nodo. Ad esempio, se il nodo ha otto core, imposta la dimensione della tabella su 524288.
    Networking 1.13.0-1.13.2

    calico-typha o loop di arresti anomali dell'operatore anetd sui nodi Windows con Controlplane v2

    Con Controlplane v2 o un nuovo modello di installazione, calico-typha o anetd-operator potrebbero essere pianificati sui nodi Windows e andare nel ciclo di arresto anomalo.

    Il motivo è che i due deployment tollerano tutte le incompatibilità, compresa l'incompatibilità dei nodi Windows.


    Soluzione:

    Esegui l'upgrade alla versione 1.13.3+ o esegui i comandi seguenti per modificare il deployment di "calico-typha" o "anetd-operator":

    
    # If dataplane v2 is not used.
    kubectl edit deployment -n kube-system calico-typha --kubeconfig USER_CLUSTER_KUBECONFIG
    # If dataplane v2 is used.
    kubectl edit deployment -n kube-system anetd-operator --kubeconfig USER_CLUSTER_KUBECONFIG

    Rimuovi i seguenti spec.template.spec.tolerations:

    
    - effect: NoSchedule
      operator: Exists
    - effect: NoExecute
      operator: Exists

    Aggiungi la seguente tolleranza:

    
    - key: node-role.kubernetes.io/master
      operator: Exists
    Configurazione 1.14.0-1.14.2

    Impossibile caricare il file delle credenziali del Registro di sistema privato del cluster utente

    Potresti non essere in grado di creare un cluster utente se specifichi la sezione privateRegistry con credenziale fileRef. Il preflight potrebbe non riuscire con il seguente messaggio: 

    
[FAILURE] Docker registry access: Failed to login.


    Soluzione:

    • Se non avevi intenzione di specificare il campo o se vuoi utilizzare la stessa credenziale di registro privata del cluster di amministrazione, puoi semplicemente rimuovere o commentare la sezione privateRegistry nel file di configurazione del cluster utente.
    • Se vuoi utilizzare una specifica credenziale di registro privata per il tuo cluster utente, puoi specificare temporaneamente la sezione privateRegistry in questo modo: 
      
privateRegistry:
  address: PRIVATE_REGISTRY_ADDRESS
  credentials:
    username: PRIVATE_REGISTRY_USERNAME
    password: PRIVATE_REGISTRY_PASSWORD
  caCertPath: PRIVATE_REGISTRY_CACERT_PATH
      NOTA: questa è solo una correzione temporanea e questi campi sono già deprecati. Ti consigliamo di utilizzare il file delle credenziali quando esegui l'upgrade alla versione 1.14.3+.

    Suite operativa 1,10+

    Anthos Service Mesh e altri mesh di servizi non compatibili con Dataplane v2

    Dataplane V2 assume il bilanciamento del carico e crea un socket kernel anziché un DNAT basato su pacchetto. Ciò significa che Anthos Service Mesh non può eseguire l'ispezione dei pacchetti poiché il pod viene ignorato e non utilizza mai le tabelle IPTable.

    Questo si manifesta in modalità gratuita kube-proxy a causa della perdita di connettività o del routing errato del traffico per i servizi con Anthos Service Mesh, in quanto il sidecar non può eseguire l'ispezione dei pacchetti.

    Questo problema è presente in tutte le versioni di Anthos clusters on bare metal 1.10, ma alcune versioni più recenti di 1.10 (1.10.2+) hanno una soluzione alternativa.


    Soluzione:

    Esegui l'upgrade alla versione 1.11 per avere la compatibilità completa oppure, se esegui la versione 1.10.2 o successiva, esegui questo comando:

    
    kubectl edit cm -n kube-system cilium-config --kubeconfig USER_CLUSTER_KUBECONFIG

    Aggiungi bpf-lb-sock-hostns-only: true alla mappa di configurazione, quindi riavvia il daemonset anetd:

    
      kubectl rollout restart ds anetd -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG

    Archiviazione 1.12 e versioni successive, 1.13.3

    kube-controller-manager potrebbe scollegare forzatamente i volumi permanenti dopo 6 minuti

    kube-controller-manager potrebbe scadere dopo aver scollegato PV/PVC dopo 6 minuti e scollegarlo con forza. I log dettagliati di kube-controller-manager mostrano eventi simili ai seguenti:

    
$ cat kubectl_logs_kube-controller-manager-xxxx | grep "DetachVolume started" | grep expired

kubectl_logs_kube-controller-manager-gke-admin-master-4mgvr_--container_kube-controller-manager_--kubeconfig_kubeconfig_--request-timeout_30s_--namespace_kube-system_--timestamps:2023-01-05T16:29:25.883577880Z W0105 16:29:25.883446       1 reconciler.go:224] attacherDetacher.DetachVolume started for volume "pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16" (UniqueName: "kubernetes.io/csi/csi.vsphere.vmware.com^126f913b-4029-4055-91f7-beee75d5d34a") on node "sandbox-corp-ant-antho-0223092-03-u-tm04-ml5m8-7d66645cf-t5q8f"
This volume is not safe to detach, but maxWaitForUnmountDuration 6m0s expired, force detaching

    Per verificare il problema, accedi al nodo ed esegui i seguenti comandi:

    
# See all the mounting points with disks
lsblk -f

# See some ext4 errors
sudo dmesg -T

    Nel log kubelet vengono visualizzati errori come i seguenti:

    
Error: GetDeviceMountRefs check failed for volume "pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16" (UniqueName: "kubernetes.io/csi/csi.vsphere.vmware.com^126f913b-4029-4055-91f7-beee75d5d34a") on node "sandbox-corp-ant-antho-0223092-03-u-tm04-ml5m8-7d66645cf-t5q8f" :
the device mount path "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16/globalmount" is still mounted by other references [/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-8bb4780b-ba8e-45f4-a95b-19397a66ce16/globalmount

    Soluzione:

    Connettiti al nodo interessato utilizzando SSH e riavvia il nodo.
    Upgrade e aggiornamenti 1.12 e versioni successive, 1.13 e versioni successive, 1.14 e versioni successive

    L'upgrade del cluster viene bloccato se viene utilizzato un driver CSI di terze parti

    Potresti non essere in grado di eseguire l'upgrade di un cluster se utilizzi un driver CSI di terze parti. Il comando gkectl cluster diagnose potrebbe restituire il seguente errore: 

    
"virtual disk "kubernetes.io/csi/csi.netapp.io^pvc-27a1625f-29e3-4e4f-9cd1-a45237cc472c" IS NOT attached to machine "cluster-pool-855f694cc-cjk5c" but IS listed in the Node.Status"


    Soluzione:

    Esegui l'upgrade utilizzando l'opzione --skip-validation-all.
    Operazione 1.10+, 1.11+, 1.12+, 1.13+, 1.14+

    gkectl repair admin-master crea la VM master di amministrazione senza eseguire l'upgrade della relativa versione hardware della VM

    Il nodo master di amministrazione creato tramite gkectl repair admin-master può utilizzare una versione hardware VM inferiore rispetto al previsto. Quando si verifica il problema, vedrai l'errore nel report gkectl diagnose cluster. 

    
CSIPrerequisites [VM Hardware]: The current VM hardware versions are lower than vmx-15 which is unexpected. Please contact Anthos support to resolve this issue.


    Soluzione:

    Arresta il nodo master di amministrazione, segui https://kb.vmware.com/s/article/1003746 per eseguire l'upgrade del nodo alla versione prevista descritta nel messaggio di errore, quindi avvia il nodo.
    Sistema operativo 1.10+, 1.11+, 1.12+, 1.13+, 1.14+, 1.15+

    La VM rilascia il lease DHCP all'arresto o al riavvio in modo imprevisto, il che potrebbe comportare modifiche dell'IP

    Nella versione 244 del sistema, systemd-networkd prevede una modifica del comportamento predefinito per la configurazione KeepConfiguration. Prima di questa modifica, le VM non inviavano un messaggio di rilascio del lease DHCP al server DHCP all'arresto o al riavvio. Dopo la modifica, le VM inviano questo messaggio e restituiscono gli IP al server DHCP. Di conseguenza, l'IP rilasciato può essere riassegnato a una VM diversa e/o a un IP diverso può essere assegnato alla VM, con conseguente conflitto di IP (a livello di Kubernetes, non a livello di vSphere) e/o una modifica dell'IP sulle VM, che può interrompere i cluster in vari modi.

    Ad esempio, potresti notare i seguenti sintomi.

    • La UI di vCenter mostra che nessuna VM utilizza lo stesso IP, ma kubectl get nodes -o wide restituisce nodi con IP duplicati. 
      
NAME   STATUS    AGE  VERSION          INTERNAL-IP    EXTERNAL-IP    OS-IMAGE            KERNEL-VERSION    CONTAINER-RUNTIME
node1  Ready     28h  v1.22.8-gke.204  10.180.85.130  10.180.85.130  Ubuntu 20.04.4 LTS  5.4.0-1049-gkeop  containerd://1.5.13
node2  NotReady  71d  v1.22.8-gke.204  10.180.85.130  10.180.85.130  Ubuntu 20.04.4 LTS  5.4.0-1049-gkeop  containerd://1.5.13
    • Impossibile avviare nuovi nodi a causa di un errore di calico-node 
      
2023-01-19T22:07:08.817410035Z 2023-01-19 22:07:08.817 [WARNING][9] startup/startup.go 1135: Calico node 'node1' is already using the IPv4 address 10.180.85.130.
2023-01-19T22:07:08.817514332Z 2023-01-19 22:07:08.817 [INFO][9] startup/startup.go 354: Clearing out-of-date IPv4 address from this node IP="10.180.85.130/24"
2023-01-19T22:07:08.825614667Z 2023-01-19 22:07:08.825 [WARNING][9] startup/startup.go 1347: Terminating
2023-01-19T22:07:08.828218856Z Calico node failed to start


    Soluzione:

    Esegui il deployment del seguente DaemonSet sul cluster per annullare la modifica del comportamento predefinito di systemd-networkd. Le VM che eseguono questo DaemonSet non rilasciano gli IP al server DHCP all'arresto/avvio. Gli IP verranno liberati automaticamente dal server DHCP alla scadenza dei lease. 

    
      apiVersion: apps/v1
      kind: DaemonSet
      metadata:
        name: set-dhcp-on-stop
      spec:
        selector:
          matchLabels:
            name: set-dhcp-on-stop
        template:
          metadata:
            labels:
              name: set-dhcp-on-stop
          spec:
            hostIPC: true
            hostPID: true
            hostNetwork: true
            containers:
            - name: set-dhcp-on-stop
              image: ubuntu
              tty: true
              command:
              - /bin/bash
              - -c
              - |
                set -x
                date
                while true; do
                  export CONFIG=/host/run/systemd/network/10-netplan-ens192.network;
                  grep KeepConfiguration=dhcp-on-stop "${CONFIG}" > /dev/null
                  if (( $? != 0 )) ; then
                    echo "Setting KeepConfiguration=dhcp-on-stop"
                    sed -i '/\[Network\]/a KeepConfiguration=dhcp-on-stop' "${CONFIG}"
                    cat "${CONFIG}"
                    chroot /host systemctl restart systemd-networkd
                  else
                    echo "KeepConfiguration=dhcp-on-stop has already been set"
                  fi;
                  sleep 3600
                done
              volumeMounts:
              - name: host
                mountPath: /host
              resources:
                requests:
                  memory: "10Mi"
                  cpu: "5m"
              securityContext:
                privileged: true
            volumes:
            - name: host
              hostPath:
                path: /
            tolerations:
            - operator: Exists
              effect: NoExecute
            - operator: Exists
              effect: NoSchedule

    Operazioni, upgrade e aggiornamenti 1.12.0+, 1.13.0+, 1.14.0+

    Chiave dell'account di servizio dell'accesso ai componenti cancellata dopo l'upgrade del cluster di amministrazione da 1.11.x

    Questo problema interesserà solo i cluster di amministrazione aggiornati dalla 1.11.x e non i cluster di amministrazione appena creati dopo la 1.12.

    Dopo l'upgrade di un cluster 1.11.x a 1.12.x, il campo component-access-sa-key nel secret admin-cluster-creds verrà cancellato per essere vuoto. Per verificarlo, esegui questo comando: 

    
kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds -o yaml | grep 'component-access-sa-key'
    Se noti che l'output è vuoto, significa che la chiave è stata cancellata.

    Dopo l'eliminazione della chiave dell'account di servizio del componente, l'installazione di nuovi cluster utente o l'upgrade dei cluster utente esistenti non andranno a buon fine. Di seguito sono riportati alcuni messaggi di errore che potrebbero essere visualizzati:

    • Errore di preflight di convalida lenta con messaggio di errore: "Failed to create the test VMs: failed to get service account key: service account is not configured."
    • Preparazione in data gkectl prepare non riuscita con messaggio di errore: "Failed to prepare OS images: dialing: unexpected end of JSON input"
    • Se esegui l'upgrade di un cluster utente 1.13 utilizzando Google Cloud Console o l'interfaccia a riga della gcloud CLI, quando esegui gkectl update admin --enable-preview-user-cluster-central-upgrade per eseguire il deployment del controller della piattaforma di upgrade, il comando non riesce e viene visualizzato il messaggio: "failed to download bundle to disk: dialing: unexpected end of JSON input" (puoi visualizzare questo messaggio nel campo status nell'output di kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get onprembundle -oyaml).


    Soluzione:

    Aggiungi di nuovo la chiave dell'account di servizio di accesso ai componenti nel secret manualmente eseguendo il comando seguente: 

    
kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get secret admin-cluster-creds -ojson | jq --arg casa "$(cat COMPONENT_ACESS_SERVICE_ACOOUNT_KEY_PATH | base64 -w 0)" '.data["component-access-sa-key"]=$casa' | kubectl --kubeconfig ADMIN_KUBECONFIG apply -f -
    Operazione 1.13.0+, 1.14.0+

    Il gestore della scalabilità automatica dei cluster non funziona quando è abilitato il piano di controllo V2

    Per i cluster utente creati con Controlplane V2 o un nuovo modello di installazione, i pool di nodi per i quali è stata abilitata la scalabilità automatica utilizzano sempre i rispettivi autoscaling.minReplicas nel cluster utente. Il log del pod del gestore della scalabilità automatica dei cluster mostra anche che non sono integri. 

    
  > kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG -n kube-system \
  logs $CLUSTER_AUTOSCALER_POD --container_cluster-autoscaler
 TIMESTAMP  1 gkeonprem_provider.go:73] error getting onpremusercluster ready status: Expected to get a onpremusercluster with id foo-user-cluster-gke-onprem-mgmt/foo-user-cluster
 TIMESTAMP 1 static_autoscaler.go:298] Failed to get node infos for groups: Expected to get a onpremusercluster with id foo-user-cluster-gke-onprem-mgmt/foo-user-cluster
    Il pod del gestore della scalabilità automatica dei cluster è reperibile eseguendo i comandi seguenti. 
    
  > kubectl --kubeconfig $USER_CLUSTER_KUBECONFIG -n kube-system \
   get pods | grep cluster-autoscaler
cluster-autoscaler-5857c74586-txx2c                          4648017n    48076Ki    30s


    Soluzione:

    Disabilita la scalabilità automatica in tutti i pool di nodi con "cluster di aggiornamento gkectl" fino all'upgrade a una versione con correzione
    Installazione 1.12.0-1.12.4, 1.13.0-1.13.3, 1.14.0

    CIDR non consentito nel file di blocco IP

    Quando gli utenti utilizzano il CIDR nel file di blocco IP, la convalida della configurazione non andrà a buon fine con il seguente errore: 

    
- Validation Category: Config Check
    - [FAILURE] Config: AddressBlock for admin cluster spec is invalid: invalid IP:
172.16.20.12/30


    Soluzione:

    Includi singoli IP nel file di blocco IP fino a quando non esegui l'upgrade a una versione con la correzione: 1.12.5, 1.13.4, 1.14.1+.
    Upgrade e aggiornamenti 1.14.0-1.14.1

    L'aggiornamento del tipo di immagine del sistema operativo in admin-cluster.yaml non prevede la ricreazione delle macchine del piano di controllo dell'utente

    Quando aggiorna il tipo di immagine del sistema operativo del piano di controllo in admin-cluster.yaml e se il cluster utente corrispondente è stato creato tramite Controlplane V2, le macchine del piano di controllo utente potrebbero non terminare la loro creazione al termine del comando gkectl.


    Soluzione:

    Al termine dell'aggiornamento, continua ad attendere che le macchine del piano di controllo utente completino la ricreazione monitorando i tipi di immagine del sistema operativo del nodo utilizzando kubectl --kubeconfig USER_KUBECONFIG get nodes -owide. ad esempio, se esegui l'aggiornamento da Ubuntu a COS, dobbiamo attendere che tutte le macchine del piano di controllo passino completamente da Ubuntu a COS anche dopo il completamento del comando di aggiornamento.

    Operazione 1,14,0

    Creazione o eliminazione di pod a causa di un problema con il token di autenticazione dell'account di servizio CNI di Calico

    Un problema con Calico nei cluster Anthos su VMware 1.14.0 comporta la mancata riuscita della creazione e dell'eliminazione del pod con il seguente messaggio di errore nell'output di kubectl describe pods:

    
  error getting ClusterInformation: connection is unauthorized: Unauthorized

    Questo problema si verifica solo 24 ore dopo la creazione o l'upgrade del cluster alla versione 1.14 con Calico.

    I cluster di amministrazione utilizzano sempre Calico, mentre per il cluster utente è presente il campo di configurazione "enableDataPlaneV2" in user-cluster.yaml. Se questo campo è impostato su "false" o non è specificato, significa che stai utilizzando Calico nel cluster utente.

    Il container install-cni dei nodi crea un kubeconfig con un token valido per 24 ore. Questo token deve essere rinnovato periodicamente dal pod calico-node. Il pod calico-node non può rinnovare il token perché non ha accesso alla directory che contiene il file kubeconfig sul nodo.


    Soluzione:

    Per mitigare il problema, applica la seguente patch al DaemonSet calico-node nel cluster di amministrazione e dell'utente:

    
  kubectl -n kube-system get daemonset calico-node \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG -o json \
    | jq '.spec.template.spec.containers[0].volumeMounts += [{"name":"cni-net-dir","mountPath":"/host/etc/cni/net.d"}]' \
    | kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f -

  kubectl -n kube-system get daemonset calico-node \
    --kubeconfig USER_CLUSTER_KUBECONFIG -o json \
    | jq '.spec.template.spec.containers[0].volumeMounts += [{"name":"cni-net-dir","mountPath":"/host/etc/cni/net.d"}]' \
    | kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f -
    Sostituisci quanto segue:
    • ADMIN_CLUSTER_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.
    • USER_CLUSTER_CONFIG_FILE: il percorso del file di configurazione del cluster utente.
    Installazione 1.12.0-1.12.4, 1.13.0-1.13.3, 1.14.0

    Convalida del blocco IP non riuscita quando si utilizza il CIDR

    La creazione del cluster non riesce nonostante l'utente abbia la configurazione corretta. L'utente vede la creazione non riuscita perché il cluster non dispone di indirizzi IP sufficienti.


    Soluzione:

    Separa i CIDR in diversi blocchi CIDR più piccoli, come 10.0.0.0/30 che diventa 10.0.0.0/31, 10.0.0.2/31. Finché sono presenti CIDR N+1, dove N è il numero di nodi nel cluster, dovrebbe essere sufficiente.

    Operazione, upgrade e aggiornamenti 1.11.0 - 1.11.1, 1.10.0 - 1.10.4, 1.9.0 - 1.9.6

    Il backup del cluster di amministrazione non include le chiavi di crittografia e la configurazione dei secret sempre attivi

    Quando la funzionalità di crittografia dei secret sempre attivi è abilitata insieme al backup del cluster, il backup del cluster di amministrazione non include le chiavi di crittografia e la configurazione richieste dalla funzionalità di crittografia dei secret sempre attiva. Di conseguenza, la riparazione del master di amministrazione con questo backup utilizzando gkectl repair admin-master --restore-from-backup causa il seguente errore: 

    
Validating admin master VM xxx ...
Waiting for kube-apiserver to be accessible via LB VIP (timeout "8m0s")...  ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master
Waiting for kube-apiserver to be accessible via LB VIP (timeout "13m0s")...  ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master
Waiting for kube-apiserver to be accessible via LB VIP (timeout "18m0s")...  ERROR
Failed to access kube-apiserver via LB VIP. Trying to fix the problem by rebooting the admin master

    Operazione, upgrade e aggiornamenti 1,10+

    Ricreazione della VM master di amministrazione con un nuovo disco di avvio (ad es. gkectl repair admin-master) avrà esito negativo se la funzionalità di crittografia dei secret sempre attiva è abilitata utilizzando il comando "gkectl update".

    Se la funzionalità di crittografia dei secret sempre attivi non è abilitata durante la creazione del cluster, ma è abilitata in un secondo momento utilizzando l'operazione gkectl update, gkectl repair admin-master non riesce a riparare il nodo del piano di controllo del cluster di amministrazione. È consigliabile abilitare la funzionalità di crittografia dei secret sempre attiva al momento della creazione del cluster. Al momento non sono presenti mitigazioni.

    Upgrade e aggiornamenti 1,1

    L'upgrade del primo cluster utente da 1.9 a 1.10 ricrea i nodi in altri cluster utente

    L'upgrade del primo cluster utente da 1.9 a 1.10 potrebbe ricreare i nodi in altri cluster utente nello stesso cluster di amministrazione. L'attività viene svolta in modo continuativo.

    L'elemento disk_label è stato rimosso da MachineTemplate.spec.template.spec.providerSpec.machineVariables e questo ha attivato in modo imprevisto un aggiornamento su tutti gli elementi MachineDeployment.


    Soluzione:
    Upgrade e aggiornamenti 1,10,0

    Docker si riavvia spesso dopo l'upgrade del cluster

    L'upgrade del cluster utente alla versione 1.10.0 potrebbe causare il riavvio frequente di docker.

    Puoi rilevare questo problema eseguendo kubectl describe node NODE_NAME --kubeconfig USER_CLUSTER_KUBECONFIG

    Una condizione nodo mostrerà se il docker si riavvia spesso. Di seguito è riportato un esempio di output:

    
Normal   FrequentDockerRestart    41m (x2 over 141m)     systemd-monitor  Node condition FrequentDockerRestart is now: True, reason: FrequentDockerRestart

    Per comprendere la causa principale, devi eseguire l'ssh al nodo che presenta il sintomo ed eseguire comandi come sudo journalctl --utc -u docker o sudo journalctl -x


    Soluzione:
    Upgrade e aggiornamenti 1.11, 1.12

    I componenti GMP di cui è stato eseguito il deployment autonomamente non vengono conservati dopo l'upgrade alla versione 1.12

    Se utilizzi un cluster Anthos su VMware versione 1.12 e hai configurato manualmente i componenti Prometheus gestiti da Google (GMP) nello spazio dei nomi gmp-system per il tuo cluster, i componenti non vengono conservati quando esegui l'upgrade alla versione 1.12.x.

    Dalla versione 1.12, i componenti GMP nello spazio dei nomi gmp-system e nei CRD vengono gestiti dall'oggetto stackdriver e il flag enableGMPForApplications è impostato su false per impostazione predefinita. Se esegui il deployment dei componenti GMP manualmente nello spazio dei nomi prima dell'upgrade alla versione 1.12, le risorse verranno eliminate da stackdriver.


    Soluzione:
    Operazione 1.11, 1.12, 1.13.0 - 1.13.1

    Oggetti ClusterAPI mancanti nello scenario system dello cluster

    Nello scenario system, lo snapshot del cluster non include risorse nello spazio dei nomi default.

    Tuttavia, alcune risorse Kubernetes, come gli oggetti API Cluster, si trovano in questo spazio dei nomi e contengono informazioni di debug utili. che devono essere inclusi nello snapshot del cluster.


    Soluzione:

    Puoi eseguire manualmente i comandi seguenti per raccogliere le informazioni di debug.

    
export KUBECONFIG=USER_CLUSTER_KUBECONFIG
kubectl get clusters.cluster.k8s.io -o yaml
kubectl get controlplanes.cluster.k8s.io -o yaml
kubectl get machineclasses.cluster.k8s.io -o yaml
kubectl get machinedeployments.cluster.k8s.io -o yaml
kubectl get machines.cluster.k8s.io -o yaml
kubectl get machinesets.cluster.k8s.io -o yaml
kubectl get services -o yaml
kubectl describe clusters.cluster.k8s.io
kubectl describe controlplanes.cluster.k8s.io
kubectl describe machineclasses.cluster.k8s.io
kubectl describe machinedeployments.cluster.k8s.io
kubectl describe machines.cluster.k8s.io
kubectl describe machinesets.cluster.k8s.io
kubectl describe services
    dove:

    USER_CLUSTER_KUBECONFIG è il file kubeconfig del cluster utente.
    Upgrade e aggiornamenti 1.11.0-1.11.4, 1.12.0-1.12.3, 1.13.0-1.13.1

    Eliminazione del cluster utente bloccata durante lo svuotamento del nodo per la configurazione vSAN

    Durante l'eliminazione, l'aggiornamento o l'upgrade di un cluster utente, lo svuotamento del nodo potrebbe essere bloccato nei seguenti scenari:

    • Il cluster di amministrazione utilizza il driver CSI vSphere su vSAN dalla versione 1.12.x e
    • Non sono presenti oggetti PVC/PV creati dai plug-in vSphere in-tree nel cluster di amministrazione e dell'utente.

    Per identificare i sintomi, esegui questo comando:

    
kubectl logs clusterapi-controllers-POD_NAME_SUFFIX  --kubeconfig ADMIN_KUBECONFIG -n USER_CLUSTER_NAMESPACE

    Di seguito è riportato un messaggio di errore di esempio del comando riportato sopra:

    
E0920 20:27:43.086567 1 machine_controller.go:250] Error deleting machine object [MACHINE]; Failed to delete machine [MACHINE]: failed to detach disks from VM "[MACHINE]": failed to convert disk path "kubevols" to UUID path: failed to convert full path "ds:///vmfs/volumes/vsan:[UUID]/kubevols": ServerFaultCode: A general system error occurred: Invalid fault

    kubevols è la directory predefinita per il driver vSphere in-tree. In assenza di oggetti PVC/PV creati, potresti riscontrare un bug che impedisce lo svuotamento dei nodi nel trovare kubevols, dato che l'implementazione attuale presuppone che kubevols esista sempre.


    Soluzione:

    Crea la directory kubevols nel datastore in cui viene creato il nodo. Questo valore viene definito nel campo vCenter.datastore nei file user-cluster.yaml o admin-cluster.yaml.
    Configurazione 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, 1.14

    Cluster Autoscaler clusterrolebinding e clusterrole vengono eliminati dopo l'eliminazione di un cluster utente.

    All'eliminazione del cluster utente, vengono eliminati anche i valori clusterrole e clusterrolebinding corrispondenti per il gestore della scalabilità automatica dei cluster. e influisce su tutti gli altri cluster utente sullo stesso cluster di amministrazione con il gestore della scalabilità automatica dei cluster abilitato. Il motivo è che lo stesso clusterrole e lo stesso clusterrolebinding vengono utilizzati per tutti i pod del gestore della scalabilità automatica dei cluster all'interno dello stesso cluster di amministrazione.

    I sintomi sono i seguenti:

    • cluster-autoscaler log
      • 
kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-autoscaler
      dove ADMIN_CLUSTER_KUBECONFIG è il file kubeconfig del cluster di amministrazione. Di seguito è riportato un esempio di messaggi di errore che potresti visualizzare: 
      
2023-03-26T10:45:44.866600973Z W0326 10:45:44.866463       1 reflector.go:424] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope
2023-03-26T10:45:44.866646815Z E0326 10:45:44.866494       1 reflector.go:140] k8s.io/client-go/dynamic/dynamicinformer/informer.go:91: Failed to watch *unstructured.Unstructured: failed to list *unstructured.Unstructured: onpremuserclusters.onprem.cluster.gke.io is forbidden: User "..." cannot list resource "onpremuserclusters" in API group "onprem.cluster.gke.io" at the cluster scope

    Soluzione:

    Configurazione 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13

    Il cluster di amministrazione cluster-health-controller e vsphere-metrics-exporter non funzionano dopo l'eliminazione del cluster utente

    Al momento dell'eliminazione del cluster utente, viene eliminato anche il corrispondente clusterrole, con il risultato che l'esportatore di metriche vSphere e di riparazione automatica non funziona

    I sintomi sono i seguenti:

    • cluster-health-controller log
      • 
kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
cluster-health-controller
      dove ADMIN_CLUSTER_KUBECONFIG è il file kubeconfig del cluster di amministrazione. Di seguito è riportato un esempio di messaggi di errore che potresti visualizzare: 
      
error retrieving resource lock default/onprem-cluster-health-leader-election: configmaps "onprem-cluster-health-leader-election" is forbidden: User "system:serviceaccount:kube-system:cluster-health-controller" cannot get resource "configmaps" in API group "" in the namespace "default": RBAC: clusterrole.rbac.authorization.k8s.io "cluster-health-controller-role" not found
    • vsphere-metrics-exporter log
      • 
kubectl logs --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n kube-system \
vsphere-metrics-exporter
      dove ADMIN_CLUSTER_KUBECONFIG è il file kubeconfig del cluster di amministrazione. Di seguito è riportato un esempio di messaggi di errore che potresti visualizzare: 
      
vsphere-metrics-exporter/cmd/vsphere-metrics-exporter/main.go:68: Failed to watch *v1alpha1.Cluster: failed to list *v1alpha1.Cluster: clusters.cluster.k8s.io is forbidden: User "system:serviceaccount:kube-system:vsphere-metrics-exporter" cannot list resource "clusters" in API group "cluster.k8s.io" in the namespace "default"

    Soluzione:

    Configurazione 1.12.1-1.12.3, 1.13.0-1.13.2

    gkectl check-config non riesce in fase di convalida dell'immagine del sistema operativo

    Un problema noto che potrebbe causare un errore di gkectl check-config senza eseguire gkectl prepare. Non è chiaro perché consigliamo di eseguire il comando prima di eseguire gkectl prepare

    Il sintomo è che il comando gkectl check-config avrà esito negativo con il seguente messaggio di errore:

    
Validator result: {Status:FAILURE Reason:os images [OS_IMAGE_NAME] don't exist, please run `gkectl prepare` to upload os images. UnhealthyResources:[]}

    Soluzione:

    Opzione 1: esegui gkectl prepare per caricare le immagini del sistema operativo mancanti.

    Opzione 2: utilizza gkectl check-config --skip-validation-os-images per saltare la convalida delle immagini del sistema operativo.
    Upgrade e aggiornamenti 1.11, 1.12, 1.13

    gkectl update admin/cluster non riesce ad aggiornare i gruppi anti affinità

    Un problema noto che potrebbe non riuscire in gkectl update admin/cluster durante l'aggiornamento di anti affinity groups.

    Il sintomo è che il comando gkectl update avrà esito negativo con il seguente messaggio di errore:

    
Waiting for machines to be re-deployed...  ERROR
Exit with error:
Failed to update the cluster: timed out waiting for the condition

    Soluzione:
    Installazione, upgrade e aggiornamenti 1.13.0-1.13.8, 1.14.0-1.14.4, 1.15.0

    La registrazione dei nodi non riesce se il nome host configurato contiene un punto

    La registrazione del nodo non riesce durante la creazione del cluster, l'upgrade, l'aggiornamento e la riparazione automatica dei nodi, quando ipMode.type è static e il nome host configurato nel file del blocco IP contiene uno o più punti. In questo caso, le richieste di firma del certificato (CSR) per un nodo non vengono approvate automaticamente.

    Per visualizzare gli CSR in attesa per un nodo, esegui il comando seguente:

    
kubectl get csr -A -o wide

    Controlla i seguenti log per verificare se sono presenti messaggi di errore:

    • Visualizza i log nel cluster di amministrazione per il container clusterapi-controller-manager nel pod clusterapi-controllers: 
      
kubectl logs clusterapi-controllers-POD_NAME \
    -c clusterapi-controller-manager -n kube-system \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    • Per visualizzare gli stessi log nel cluster utente, esegui questo comando: 
      
kubectl logs clusterapi-controllers-POD_NAME \
    -c clusterapi-controller-manager -n USER_CLUSTER_NAME \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG
      Dove:
      • ADMIN_CLUSTER_KUBECONFIG è il file kubeconfig del cluster di amministrazione.
      • USER_CLUSTER_NAME è il nome del cluster utente.
      Ecco un esempio di messaggi di errore che potresti visualizzare: "msg"="failed to validate token id" "error"="failed to find machine for node node-worker-vm-1" "validate"="csr-5jpx9"
    • Visualizza i log kubelet sul nodo problematico: 
      
journalctl --u kubelet
      Ecco un esempio di messaggi di errore che potresti visualizzare: "Error getting node" err="node \"node-worker-vm-1\" not found"

    Se specifichi un nome di dominio nel campo del nome host di un file di blocco IP, qualsiasi carattere successivo al primo periodo verrà ignorato. Ad esempio, se specifichi il nome host come bob-vm-1.bank.plc, il nome host della VM e il nome del nodo verranno impostati su bob-vm-1.

    Quando la verifica dell'ID nodo è abilitata, l'approvatore CSR confronta il nome del nodo con il nome host nella specifica della macchina e non riesce a riconciliare il nome. L'approvatore rifiuta il CSR e il nodo non esegue il bootstrap.


    Soluzione:

    Cluster utente

    Disabilita la verifica dell'ID nodo completando i seguenti passaggi:

    1. Aggiungi i seguenti campi al file di configurazione del cluster utente: 
      
disableNodeIDVerification: true
disableNodeIDVerificationCSRSigning: true
    2. Salva il file e aggiorna il cluster utente eseguendo questo comando: 
      
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE
      Sostituisci quanto segue:
      • ADMIN_CLUSTER_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.
      • USER_CLUSTER_CONFIG_FILE: il percorso del file di configurazione del cluster utente.

    Cluster di amministrazione

    1. Apri la risorsa personalizzata OnPremAdminCluster per la modifica: 
      
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    edit onpremadmincluster -n kube-system
    2. Aggiungi la seguente annotazione alla risorsa personalizzata: 
      
features.onprem.cluster.gke.io/disable-node-id-verification: enabled
    3. Modifica il manifest kube-controller-manager nel piano di controllo del cluster di amministrazione:
      1. Accedi tramite SSH al nodo del piano di controllo del cluster di amministrazione.
      2. Apri il manifest kube-controller-manager per la modifica: 
        
sudo vi /etc/kubernetes/manifests/kube-controller-manager.yaml
      3. Trova l'elenco controllers: 
        
--controllers=*,bootstrapsigner,tokencleaner,-csrapproving,-csrsigning
      4. Aggiorna questa sezione come mostrato di seguito: 
        
--controllers=*,bootstrapsigner,tokencleaner
    4. Apri il controller API del cluster di deployment per la modifica: 
      
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    edit deployment clusterapi-controllers -n kube-system
    5. Modifica i valori di node-id-verification-enabled e node-id-verification-csr-signing-enabled in false: 
      
--node-id-verification-enabled=false
--node-id-verification-csr-signing-enabled=false
    Installazione, upgrade e aggiornamenti 1.11.0-1.11.4

    Errore di avvio della macchina del piano di controllo dell'amministratore a causa di un bundle di certificato del registry privato

    La creazione o l'upgrade del cluster di amministrazione è bloccata al seguente log per sempre e, in seguito, scadrà:

    
Waiting for Machine gke-admin-master-xxxx to become ready...

    Il log del controller API Cluster nell' istantanea cluster esterno include il log seguente:

    
Invalid value 'XXXX' specified for property startup-data

    Di seguito è riportato un percorso file di esempio per il log del controller API Cluster:

    
kubectlCommands/kubectl_logs_clusterapi-controllers-c4fbb45f-6q6g6_--container_vsphere-controller-manager_--kubeconfig_.home.ubuntu..kube.kind-config-gkectl_--request-timeout_30s_--namespace_kube-system_--timestamps
    
    VMware has a 64k vApp property size limit. In the identified versions,
    the data passed via vApp property is close to the limit. When the private
    registry certificate contains a certificate bundle, it may cause the final
    data to exceed the 64k limit.
    
    
    Workaround:
    
    
    Only include the required certificates in the private registry
    certificate file configured in privateRegistry.caCertPath in
    the admin cluster config file.
    
    
    Or upgrade to a version with the fix when available.
    Networking 1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0

    NetworkGatewayNodes: stato non integro a causa di un conflitto di aggiornamento di stato in contemporanea

    In networkgatewaygroups.status.nodes, alcuni nodi cambiano tra NotHealthy e Up.

    I log per il pod ang-daemon in esecuzione su quel nodo rivelano errori ripetuti: 

    
2022-09-16T21:50:59.696Z ERROR ANGd Failed to report status {"angNode": "kube-system/my-node", "error": "updating Node CR status: sending Node CR update: Operation cannot be fulfilled on networkgatewaynodes.networking.gke.io \"my-node\": the object has been modified; please apply your changes to the latest version and try again"}

    Lo stato NotHealthy impedisce al controller di assegnare ulteriori IP mobili al nodo. Ciò può comportare un carico maggiore su altri nodi o la mancanza di ridondanza per l'alta disponibilità.

    In caso contrario, l'attività del piano dati non è interessata.

    La contesa sull'oggetto networkgatewaygroup determina la non riuscita di alcuni aggiornamenti di stato a causa di un errore nella gestione dei nuovi tentativi. Se troppi aggiornamenti di stato non riescono, ang-controller-manager vede il nodo come superato il limite di tempo del battito cardiaco e contrassegna il nodo NotHealthy.

    L'errore nella gestione dei nuovi tentativi è stato risolto nelle versioni successive.


    Soluzione:

    Esegui l'upgrade a una versione corretta, se disponibile.
    Upgrade e aggiornamenti 1.12.0-1.12.2, 1.13.0

    La condizione di blocco blocca l'eliminazione degli oggetti della macchina durante e un aggiornamento o un upgrade

    Un problema noto che causava il blocco dell'upgrade o dell'aggiornamento del cluster in attesa dell'eliminazione del vecchio oggetto macchina. Questo perché il finalizzatore non può essere rimosso dall'oggetto macchina. Questa operazione influisce su qualsiasi operazione di aggiornamento in sequenza per i pool di nodi.

    Il sintomo è che il comando gkectl vada in timeout con il seguente messaggio di errore:

    
E0821 18:28:02.546121   61942 console.go:87] Exit with error:
E0821 18:28:02.546184   61942 console.go:87] error: timed out waiting for the condition, message: Node pool "pool-1" is not ready: ready condition is not true: CreateOrUpdateNodePool: 1/3 replicas are updated
Check the status of OnPremUserCluster 'cluster-1-gke-onprem-mgmt/cluster-1' and the logs of pod 'kube-system/onprem-user-cluster-controller' for more detailed debugging information.

    Nei log dei pod clusterapi-controller, gli errori sono i seguenti:

    
$ kubectl logs clusterapi-controllers-[POD_NAME_SUFFIX] -n cluster-1
    -c vsphere-controller-manager --kubeconfig [ADMIN_KUBECONFIG]
    | grep "Error removing finalizer from machine object"
[...]
E0821 23:19:45.114993       1 machine_controller.go:269] Error removing finalizer from machine object cluster-1-pool-7cbc496597-t5d5p; Operation cannot be fulfilled on machines.cluster.k8s.io "cluster-1-pool-7cbc496597-t5d5p": the object has been modified; please apply your changes to the latest version and try again

    L'errore si ripete per la stessa macchina per diversi minuti, anche per le esecuzioni riuscite anche senza questo bug. Nella maggior parte dei casi può verificarsi rapidamente, ma in rari casi può rimanere bloccato in questa condizione per diverse ore.

    Il problema è che la VM sottostante è già stata eliminata in vCenter, ma non è possibile rimuovere l'oggetto macchina corrispondente, che si blocca nella rimozione del finalizzatore a causa di aggiornamenti molto frequenti da altri controller. Questo può causare il timeout del comando gkectl, ma il controller continua a riconciliare il cluster in modo che il processo di upgrade o aggiornamento venga completato.


    Soluzione:

    Abbiamo preparato diverse opzioni di mitigazione per questo problema, che dipendono dal tuo ambiente e dai tuoi requisiti.

    • Opzione 1: attendi il completamento dell'upgrade autonomamente.

      In base all'analisi e alla riproduzione nel tuo ambiente, l'upgrade può terminare da solo senza alcun intervento manuale. L'avvertenza di questa opzione è che non è possibile sapere quanto tempo sarà necessario per la rimozione del finalizzatore da parte di ogni oggetto della macchina. Se la riconciliazione del controller del set di macchine è troppo rapida e il controller della macchina non ha mai la possibilità di rimuovere il finalizzatore tra le riconciliazioni, può passare immediatamente in caso di fortuna.

      La buona notizia è che questa opzione non ha bisogno di alcuna azione da parte tua e i carichi di lavoro non subiranno interruzioni. Ha solo bisogno di più tempo per il completamento dell'upgrade.
    • Opzione 2: applica l'annotazione della riparazione automatica a tutti i vecchi oggetti della macchina.



      Lo svantaggio è che i pod sulle macchine verranno eliminati direttamente anziché rimossi, il che significa che non rispetteranno la configurazione dei PDB, il che potrebbe causare tempi di inattività per i tuoi carichi di lavoro.

      Il comando per ottenere tutti i nomi di macchine: 
      
kubectl --kubeconfig CLUSTER_KUBECONFIG get machines
      Il comando per applicare l'annotazione della riparazione automatica per ogni macchina: 
      
kubectl annotate --kubeconfig CLUSTER_KUBECONFIG \
    machine MACHINE_NAME \
    onprem.cluster.gke.io/repair-machine=true

    Se riscontri questo problema e l'upgrade o l'aggiornamento non è ancora in grado di essere completato dopo un lungo periodo di tempo, contatta il nostro team di assistenza per risolvere il problema.
    Installazione, upgrade e aggiornamenti 1.10.2, 1.11, 1.12, 1.13

    gkectl prepara l'errore di preflight della convalida delle immagini del sistema operativo

    Comando gkectl prepare non riuscito con:

    
- Validation Category: OS Images
    - [FAILURE] Admin cluster OS images exist: os images [os_image_name] don't exist, please run `gkectl prepare` to upload os images.

    I controlli preflight di gkectl prepare hanno incluso una convalida errata.


    Soluzione:

    Esegui lo stesso comando con un flag aggiuntivo --skip-validation-os-images.
    Installazione 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13

    L'URL vCenter con prefisso https:// o http:// potrebbe causare un errore di avvio del cluster

    Creazione del cluster di amministrazione non riuscita con:

    
Exit with error:
Failed to create root cluster: unable to apply admin base bundle to external cluster: error: timed out waiting for the condition, message:
Failed to apply external bundle components: failed to apply bundle objects from admin-vsphere-credentials-secret 1.x.y-gke.z to cluster external: Secret "vsphere-dynamic-credentials" is invalid:
[data[https://xxx.xxx.xxx.username]: Invalid value: "https://xxx.xxx.xxx.username": a valid config key must consist of alphanumeric characters, '-', '_' or '.'
(e.g. 'key.name', or 'KEY_NAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+'), data[https://xxx.xxx.xxx.password]:
Invalid value: "https://xxx.xxx.xxx.password": a valid config key must consist of alphanumeric characters, '-', '_' or '.'
(e.g. 'key.name', or 'KEY_NAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+')]

    L'URL viene utilizzato come parte di una chiave segreta, che non supporta "/" o ":".


    Soluzione:

    Rimuovi il prefisso https:// o http:// dal campo vCenter.Address nel cluster di amministrazione o nel file YAML della configurazione del cluster utente.
    Installazione, upgrade e aggiornamenti 1.10, 1.11, 1.12, 1.13

    Panico da gkectl prepare su util.CheckFileExists

    gkectl prepare può farti prendere dal panico con il seguente stack:

    
panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0xde0dfa]

goroutine 1 [running]:
gke-internal.googlesource.com/syllogi/cluster-management/pkg/util.CheckFileExists(0xc001602210, 0x2b, 0xc001602210, 0x2b) pkg/util/util.go:226 +0x9a
gke-internal.googlesource.com/syllogi/cluster-management/gkectl/pkg/config/util.SetCertsForPrivateRegistry(0xc000053d70, 0x10, 0xc000f06f00, 0x4b4, 0x1, 0xc00015b400)gkectl/pkg/config/util/utils.go:75 +0x85
...

    Il problema è che gkectl prepare ha creato una directory del certificato di registro privato con un'autorizzazione errata.


    Soluzione:

    Per risolvere questo problema, esegui i comandi seguenti sulla workstation di amministrazione:

    
sudo mkdir -p /etc/docker/certs.d/PRIVATE_REGISTRY_ADDRESS
sudo chmod 0755 /etc/docker/certs.d/PRIVATE_REGISTRY_ADDRESS
    Upgrade e aggiornamenti 1.10, 1.11, 1.12, 1.13

    gkectl repair admin-master e l'upgrade amministrativo ripristinabile non funzionano insieme

    Dopo un tentativo non riuscito di upgrade del cluster di amministrazione, non eseguire gkectl repair admin-master. In caso contrario, i tentativi di upgrade da parte dell'amministratore successivi potrebbero non riuscire a risolvere problemi quali l'arresto dell'amministratore master o la VM inaccessibile.


    Soluzione:

    Se hai già riscontrato questo scenario di errore, contatta l'assistenza.
    Upgrade e aggiornamenti 1.10, 1.11

    L'upgrade del cluster di amministrazione ripristinato può causare la mancanza del modello di VM del piano di controllo dell'amministratore

    Se la macchina del piano di controllo amministratore non viene ricreata dopo un tentativo di upgrade del cluster di amministrazione ripristinato, il modello VM del piano di controllo amministratore viene eliminato. Il modello di VM del piano di controllo è il modello del master di amministrazione utilizzato per recuperare la macchina del piano di controllo con gkectl repair admin-master.


    Soluzione:

    Il modello di VM del piano di controllo amministratore verrà rigenerato durante il successivo upgrade del cluster di amministrazione.
    Sistema operativo 1.12, 1.13

    cgroup v2 potrebbe influire sui carichi di lavoro

    Nella versione 1.12.0, cgroup v2 (unificato) è abilitato per impostazione predefinita per i nodi di Container Optimized OS (COS). Questo potrebbe causare instabilità dei carichi di lavoro in un cluster COS.


    Soluzione:

    Siamo tornati a cgroup v1 (ibrido) nella versione 1.12.1. Se utilizzi i nodi COS, ti consigliamo di eseguire l'upgrade alla versione 1.12.1 non appena viene rilasciato.
    Identità 1.10, 1.11, 1.12, 1.13

    Risorsa personalizzata ClientConfig

    gkectl update ripristina eventuali modifiche manuali apportate alla risorsa personalizzata ClientConfig.


    Soluzione:

    Ti consigliamo vivamente di eseguire il backup della risorsa ClientConfig dopo ogni modifica manuale.
    Installazione 1.10, 1.11, 1.12, 1.13

    Convalida di gkectl check-config non riuscita: impossibile trovare le partizioni BIG-IP di F5

    La convalida non va a buon fine perché non è possibile trovare le partizioni F5 BIG-IP, anche se esistono.

    Un problema con l'API F5 BIG-IP può causare la mancata riuscita della convalida.


    Soluzione:

    Prova a eseguire di nuovo gkectl check-config.
    Installazione 1,12

    Installazione del cluster utente non riuscita a causa di un problema di elezioni leader del gestore di certificati/di iniettore CA

    Potresti riscontrare un errore di installazione dovuto a cert-manager-cainjector in loop dell'arresto anomalo, quando l'apiserver/etcd è lenta:

    
# 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"

    Soluzione:
    Sicurezza, upgrade e aggiornamenti 1.10, 1.11, 1.12, 1.13

    Potrebbe essere necessario il rinnovo dei certificati prima dell'upgrade di un cluster di amministrazione

    Prima di iniziare il processo di upgrade del cluster di amministrazione, devi assicurarti che i certificati del cluster di amministrazione siano attualmente validi e rinnovarli in caso contrario.

    Se hai iniziato il processo di upgrade e hai riscontrato un errore con la scadenza del certificato, contatta l'Assistenza Google.

    Nota: queste indicazioni sono riservate al rinnovo dei certificati del cluster di amministrazione.

    Soluzione:
    VMware 1.10, 1.11, 1.12, 1.13

    Riavvio o upgrade di vCenter per le versioni precedenti a 7.0U2

    Se vCenter, per le versioni precedenti a 7.0U2, viene riavviato, dopo un upgrade o in altro modo, il nome della rete nelle informazioni sulle VM di vCenter non è corretto e la macchina è in stato Unavailable. In questo modo, i nodi vengono riparati automaticamente per crearne di nuovi.

    Bug di govmomi correlato.


    Soluzione:

    Questa soluzione alternativa è fornita dal supporto VMware:

    1. Il problema è stato risolto nelle versioni vCenter 7.0U2 e successive.
    2. Per le versioni precedenti, fai clic con il tasto destro del mouse sull'host, quindi seleziona Connessione > Disconnetti. Quindi, esegui di nuovo la connessione, il che forza un aggiornamento del gruppo di porte della VM.
    Sistema operativo 1.10, 1.11, 1.12, 1.13

    Connessione SSH chiusa dall'host remoto

    Per i cluster Anthos su VMware versione 1.7.2 e successive, le immagini del sistema operativo Ubuntu sono protette da Benchmark del server CIS L1.

    Per soddisfare la regola CIS "5.2.16 Assicurati che l'intervallo di timeout per inattività 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 causa un comportamento imprevisto. Quando utilizzi la sessione SSH sulla workstation di amministrazione o su un nodo cluster, la connessione SSH potrebbe essere disconnessa anche se il client SSH non è inattivo, ad esempio quando viene eseguito un comando dispendioso in termini di tempo, e il comando potrebbe essere interrotto con il seguente messaggio:

    
Connection to [IP] closed by remote host.
Connection to [IP] closed.

    Soluzione:

    Puoi:

    • Utilizza nohup per impedire l'interruzione del comando sulla disconnessione 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 riconnettere la tua sessione SSH.
    Installazione 1.10, 1.11, 1.12, 1.13

    Installazione di cert-manager in conflitto

    Nelle release 1.13, monitoring-operator installerà cert-manager nello spazio dei nomi cert-manager. Se per determinati motivi, devi installare il tuo gestore di certificati, segui queste istruzioni per evitare conflitti:

    Devi applicare questa soluzione una sola volta per ogni cluster e le modifiche verranno mantenute in base all'upgrade del cluster.

    Nota: un sintomo comune di installazione del proprio gestore di certificati è che la versione o l'immagine di cert-manager (ad esempio v1.7.2) potrebbe tornare alla versione precedente. Questo è dovuto al fatto che monitoring-operator tenta di riconciliare il cert-manager e di annullare la versione durante il processo.

    Soluzione:

    Evitare conflitti durante l'upgrade

    1. Disinstalla la tua versione di cert-manager. Se hai definito le tue risorse, puoi eseguire il backup .
    2. Esegui l'upgrade.
    3. Segui queste istruzioni per ripristinare il tuo cert-manager.

    Ripristinare un gestore di certificati personalizzato nei cluster utente

    • Scala il deployment di monitoring-operator a 0: 
      
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: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager --replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager-cainjector\
    --replicas=0
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager-webhook --replicas=0
    • Reinstalla la tua versione di cert-manager. Ripristina le risorse personalizzate, se disponibili.
    • Puoi saltare questo passaggio se utilizzi l' installazione predefinita del gestore di certificati o hai la certezza che il tuo gestore di certificati sia installato nello spazio dei nomi cert-manager. In caso contrario, copia il certificato metrics-ca cert-manager.io/v1 e le risorse dell'emittente metrics-pki.cluster.local da cert-manager nello spazio dei nomi delle risorse del cluster del gestore di certificati installato. 
      
relevant_fields='
{
  apiVersion: .apiVersion,
  kind: .kind,
  metadata: {
    name: .metadata.name,
    namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
  },
  spec: .spec
}
'
f1=$(mktemp)
f2=$(mktemp)
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    get issuer -n cert-manager metrics-pki.cluster.local -o json \
    | jq "${relevant_fields}" > $f1
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    get certificate -n cert-manager metrics-ca -o json \
    | jq "${relevant_fields}" > $f2
kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f1
kubectl apply --kubeconfig USER_CLUSTER_KUBECONFIG -f $f2

    Ripristinare un gestore certificati specifico nei cluster di amministrazione

    In generale, non è necessario reinstallare cert-manager nei cluster di amministrazione perché questi ultimi eseguono solo i cluster Anthos sui carichi di lavoro del piano di controllo VMware. Nei rari casi in cui sia necessario installare un proprio gestore di certificati nei cluster di amministrazione, seguire le istruzioni riportate di seguito per evitare conflitti. Tieni presente che se sei un cliente Apigee e hai bisogno solo del gestore di certificati per Apigee, non è necessario eseguire i comandi del cluster di amministrazione.

    • Scala il deployment monitoring-operator a 0. 
      
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n kube-system scale deployment monitoring-operator --replicas=0
    • Scala i deployment cert-manager gestiti da monitoring-operator a 0. 
      
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager \
    --replicas=0

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
     -n cert-manager scale deployment cert-manager-cainjector \
     --replicas=0

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    -n cert-manager scale deployment cert-manager-webhook \
    --replicas=0
    • Reinstalla la tua versione di cert-manager. Ripristina le risorse personalizzate, se disponibili.
    • Puoi saltare questo passaggio se utilizzi l' installazione predefinita del gestore di certificati o hai la certezza che il tuo gestore di certificati sia installato nello spazio dei nomi cert-manager. In caso contrario, copia il certificato metrics-ca cert-manager.io/v1 e le risorse dell'emittente metrics-pki.cluster.local da cert-manager nello spazio dei nomi delle risorse del cluster del gestore di certificati installato. 
      
relevant_fields='
{
  apiVersion: .apiVersion,
  kind: .kind,
  metadata: {
    name: .metadata.name,
    namespace: "YOUR_INSTALLED_CERT_MANAGER_NAMESPACE"
  },
  spec: .spec
}
'
f3=$(mktemp)
f4=$(mktemp)
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \n
    get issuer -n cert-manager metrics-pki.cluster.local -o json \
    | jq "${relevant_fields}" > $f3
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    get certificate -n cert-manager metrics-ca -o json \
    | jq "${relevant_fields}" > $f4
kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f3
kubectl apply --kubeconfig ADMIN_CLUSTER_KUBECONFIG -f $f4
    Sistema operativo 1.10, 1.11, 1.12, 1.13

    Falsi positivi nell'analisi delle vulnerabilità docker, containerd ed runc

    Il Docker, il containerd e il runc nelle immagini del sistema operativo Ubuntu forniti con Cluster Anthos su VMware sono bloccati su versioni speciali utilizzando Ubuntu PPA. Ciò garantisce che le eventuali modifiche al runtime dei container siano qualificate dai cluster Anthos su VMware prima di ogni release.

    Tuttavia, le versioni speciali sono sconosciute per il tracker CVE di Ubuntu, che viene utilizzato come feed di vulnerabilità da vari strumenti di scansione CVE. Pertanto, vedrai falsi positivi nei risultati dell'analisi delle vulnerabilità di Docker, containerd ed runc.

    Ad esempio, potresti vedere i seguenti falsi positivi nei risultati della scansione di CVE. Queste CVE sono già state risolte nelle ultime versioni delle patch di Cluster Anthos su VMware.

    Fai riferimento alle note di rilascio] per eventuali correzioni CVE.


    Soluzione:

    Canonical è a conoscenza di questo problema e la correzione viene tracciata all'indirizzo https://github.com/canonical/sec-cvescan/issues/73.
    Upgrade e aggiornamenti 1.10, 1.11, 1.12, 1.13

    La connessione di rete tra amministratore e cluster utente potrebbe non essere disponibile per un breve periodo di tempo durante l'upgrade del cluster non ad alta disponibilità

    Se stai eseguendo l'upgrade dei cluster non ad alta disponibilità dalla versione 1.9 alla 1.10, potresti notare che kubectl exec, kubectl log e il webhook nei cluster utente potrebbero non essere disponibili per un breve periodo di tempo. Il tempo di inattività può arrivare a un minuto al massimo. Questo accade perché la richiesta in entrata (kubectl exec, kubectl log and webhook) viene gestita da kube-apiserver per il cluster utente. L'utente kube-apiserver è un Statefulset. In un cluster non ad alta disponibilità, c'è solo una replica per lo StatefulSet. Pertanto, durante l'upgrade, è possibile che il vecchio kube-apiserver non sia disponibile mentre il nuovo kube-apiserver non è ancora pronto.


    Soluzione:

    Questo tempo di inattività si verifica solo durante il processo di upgrade. Se vuoi ridurre i tempi di inattività durante l'upgrade, ti consigliamo di passare ai cluster ad alta disponibilità.
    Installazione, upgrade e aggiornamenti 1.10, 1.11, 1.12, 1.13

    Controllo di idoneità per Konnectivity non riuscito nella diagnostica del cluster ad alta disponibilità dopo la creazione o l'upgrade del cluster

    Se crei o esegui l'upgrade di un cluster ad alta disponibilità e noti che il controllo di idoneità della konnectivity non è riuscito nella diagnostica del cluster, nella maggior parte dei casi non influisce sulla funzionalità dei cluster Anthos su VMware (kubectl exec, kubectl log e webhook). Questo accade perché a volte una o due repliche di knectivity potrebbero essere non pronte per un periodo di tempo a causa di risorse di rete instabili o di altri problemi.


    Soluzione:

    La konnectivity ripristinerà da sola. Attendi da 30 minuti a 1 ora ed esegui di nuovo la diagnostica del cluster.
    Sistema operativo 1.7, 1.8, 1.9, 1.10, 1.11

    /etc/cron.daily/aide problema di picco di CPU e memoria

    A partire dai cluster Anthos su VMware versione 1.7.2, le immagini del sistema operativo Ubuntu sono protette da Benchmark del server CSI L1.

    Di conseguenza, lo script cron /etc/cron.daily/aide è stato installato in modo da pianificare un controllo aide, per garantire che venga rispettata la regola del server CIS L1 "1.4.2 Assicurati che l'integrità del file system sia controllata regolarmente".

    Il cron job viene eseguito ogni giorno alle 06:25 UTC. A seconda del numero di file nel file system, potresti riscontrare picchi di utilizzo della CPU e della memoria in questo periodo causati da questo processo aide.


    Soluzione:

    Se i picchi interessano il tuo carico di lavoro, puoi disabilitare il cron job giornaliero:

    
sudo chmod -x /etc/cron.daily/aide
    Networking 1.10, 1.11, 1.12, 1.13

    I bilanciatori del carico e le regole firewall distribuiti con stateful NSX-T interagiscono in modo imprevedibile

    Quando esegui il deployment dei cluster Anthos su VMware versione 1.9 o successiva, quando il deployment ha il bilanciatore del carico in bundle Seesaw in un ambiente che utilizza regole firewall stateful NSX-T, stackdriver-operator potrebbe non riuscire a creare gke-metrics-agent-conf ConfigMap e causare gke-connect-agent pod in un loop di arresto anomalo.

    Il problema sottostante è che le regole del firewall distribuito NSX-T stateful interrompono la connessione da un client al server API del cluster utente tramite il bilanciatore del carico di Seesaw perché Seesaw utilizza flussi di connessione asimmetrici. I problemi di integrazione con le regole firewall distribuite di NSX-T interessano tutti i cluster Anthos su release VMware che utilizzano Seesaw. Potresti riscontrare problemi di connessione simili sulle tue applicazioni quando creano oggetti Kubernetes di grandi dimensioni e con dimensioni superiori a 32.000.


    Soluzione:

    Segui queste istruzioni per disabilitare le regole firewall distribuite NSX-T o per utilizzare le regole firewall distribuite stateless per le VM di Seesaw.

    Se i tuoi cluster utilizzano un bilanciatore del carico manuale, segui queste istruzioni per configurare il bilanciatore del carico in modo da reimpostare le connessioni client quando rileva un errore del nodo di backend. Senza questa configurazione, i client del server API Kubernetes potrebbero non rispondere più per diversi minuti quando un'istanza di server non è disponibile.
    Logging e monitoraggio 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

    Monitoraggio imprevisto della fatturazione

    Per i cluster Anthos sulla versione 1.10 di VMware più recenti, alcuni clienti hanno riscontrato una fatturazione inaspettatamente elevata per Metrics volume nella pagina Fatturazione. Questo problema riguarda solo le seguenti circostanze:

    • Monitoraggio applicazioni abilitato (enableStackdriverForApplications=true)
    • Managed Service per Prometheus non è abilitato (enableGMPForApplications)
    • I pod dell'applicazione hanno l'annotazione prometheus.io/scrap=true. (Anche l'installazione di Anthos Service Mesh può aggiungere questa annotazione).

    Per verificare se hai riscontrato questo problema, elenca le metriche definite dall'utente. Se visualizzi la fatturazione per le metriche indesiderate, questo problema si applica a te.


    Soluzione

    Se hai riscontrato questo problema, ti consigliamo di eseguire l'upgrade dei tuoi cluster alla versione 1.12 e di passare alla nuova soluzione per il monitoraggio delle applicazioni managed-service-for-prometheus che consenta di risolvere il problema:

  • Flag separati per controllare la raccolta dei log delle applicazioni rispetto alle metriche delle applicazioni
  • Google Cloud Managed Service per Prometheus in bundle

    • Se non riesci a eseguire l'upgrade alla versione 1.12, procedi nel seguente modo:

    1. Trova i pod e i servizi di origine a cui sono associati i costi fatturati indesiderati 
      
kubectl --kubeconfig KUBECONFIG \
  get pods -A -o yaml | grep 'prometheus.io/scrape: "true"'
kubectl --kubeconfig KUBECONFIG get \
  services -A -o yaml | grep 'prometheus.io/scrape: "true"'
    2. Rimuovi l'annotazione prometheus.io/scrap=true dal pod o servizio. Se l'annotazione viene aggiunta da Anthos Service Mesh, valuta la possibilità di configurare Anthos Service Mesh senza l'opzione Prometheus o di disattivare la funzionalità di unione di metriche Istio.
    Installazione 1.11, 1.12, 1.13

    Il programma di installazione non riesce durante la creazione del disco dati vSphere

    Il programma di installazione di Cluster Anthos su VMware può non riuscire se i ruoli personalizzati sono associati al livello di autorizzazioni errato.

    Quando l'associazione dei ruoli non è corretta, la creazione di un disco dati vSphere con govc si blocca e il disco viene creato con una dimensione uguale a 0. Per risolvere il problema, devi associare il ruolo personalizzato a livello di vSphere vCenter (root).


    Soluzione:

    Se vuoi associare il ruolo personalizzato a livello di DC (o inferiore a quello principale), devi anche associare il ruolo di sola lettura all'utente a livello di vCenter principale.

    Per maggiori informazioni sulla creazione dei ruoli, vedi Privilegi di account utente vCenter.
    Logging e monitoraggio 1.9.0-1.9.4, 1.10.0-1.10.1

    Traffico di rete elevato verso monitoraggio.googleapis.com

    Potresti notare un traffico di rete elevato verso monitoring.googleapis.com, anche in un nuovo cluster privo di carichi di lavoro utente.

    Questo problema riguarda le versioni 1.10.0-1.10.1 e 1.9.0-1.9.4. Questo problema è stato risolto nelle versioni 1.10.2 e 1.9.5.


    Soluzione:
    Logging e monitoraggio 1.10, 1.11

    gke-metrics-agent presenta spesso errori CrashLoopBackOff

    Per i cluster Anthos su VMware versione 1.10 e successive, "gke-metrics-agent" DaemonSet presenta frequenti errori CrashLoopBackOff quando "enableStackdriverForApplications" è impostato su "true" nell'oggetto "stackdriver".


    Soluzione:

    Per mitigare questo problema, disattiva la raccolta delle metriche delle applicazioni eseguendo i comandi seguenti. Questi comandi non disabilitano la raccolta di log delle applicazioni.

    1. Per evitare che le seguenti modifiche vengano annullate, fare lo scale down di stackdriver-operator: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system scale deploy stackdriver-operator \
    --replicas=0
      Sostituisci USER_CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster utente.
    2. Apri il ConfigMap di gke-metrics-agent-conf per la modifica: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit configmap gke-metrics-agent-conf
    3. Sotto services.pipelines, commenta l'intera sezione metrics/app-metrics: 
      
services:
  pipelines:
    #metrics/app-metrics:
    #  exporters:
    #  - googlecloud/app-metrics
    #  processors:
    #  - resource
    #  - metric_to_resource
    #  - infer_resource
    #  - disk_buffer/app-metrics
    #  receivers:
    #  - prometheus/app-metrics
    metrics/metrics:
      exporters:
      - googlecloud/metrics
      processors:
      - resource
      - metric_to_resource
      - infer_resource
      - disk_buffer/metrics
      receivers:
      - prometheus/metrics
    4. Chiudi la sessione di modifica.
    5. Riavvia il DaemonSet gke-metrics-agent: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system rollout restart daemonset gke-metrics-agent
    Logging e monitoraggio 1.11, 1.12, 1.13

    Sostituisci le metriche deprecate nella dashboard

    Se nelle dashboard OOTB vengono utilizzate metriche deprecate, vedrai alcuni grafici vuoti. Per trovare le metriche deprecate nelle dashboard di Monitoring, esegui i comandi seguenti:

    
gcloud monitoring dashboards list > all-dashboard.json

# find deprecated metrics
cat all-dashboard.json | grep -E \
  'kube_daemonset_updated_number_scheduled\
    |kube_node_status_allocatable_cpu_cores\
    |kube_node_status_allocatable_pods\
    |kube_node_status_capacity_cpu_cores'

    È necessario eseguire la migrazione delle seguenti metriche deprecate alle relative sostituzioni.

    DeprecatoSostituzione
    kube_daemonset_updated_number_scheduled kube_daemonset_status_updated_number_scheduled
    kube_node_status_allocatable_cpu_cores
    kube_node_status_allocatable_memory_bytes
    kube_node_status_allocatable_pods    		 kube_node_status_allocatable
    kube_node_status_capacity_cpu_cores
    kube_node_status_capacity_memory_bytes
    kube_node_status_capacity_pods    		 kube_node_status_capacity
    kube_hpa_status_current_replicas kube_horizontalpodautoscaler_status_current_replicas

    Soluzione:

    Per sostituire le metriche obsolete

    1. Elimina "Stato dei nodi on-prem di GKE" nella dashboard di Google Cloud Monitoring. Reinstalla "Stato dei nodi GKE On-Prem" seguendo queste istruzioni.
    2. Elimina "Utilizzo dei nodi on-prem di GKE" nella dashboard di Google Cloud Monitoring. Reinstalla "Utilizzo dei nodi on-prem di GKE" seguendo queste istruzioni.
    3. Elimina "GKE vSphere vSphere vm Health" nella dashboard di Google Cloud Monitoring. Reinstalla "GKE vSphere vm health" seguendo queste istruzioni.

      4. Questo ritiro è dovuto all'upgrade dell'agente kube-state-metrics dalla v1.9 alla v2.4, necessario per Kubernetes 1.22. Puoi sostituire tutte le metriche kube-state-metrics ritirate, che hanno il prefisso kube_, nelle dashboard personalizzate o nei criteri di avviso.
    Logging e monitoraggio 1.10, 1.11, 1.12, 1.13

    Dati relativi alle metriche sconosciuti in Cloud Monitoring

    Per i cluster Anthos su VMware 1.10 e versioni successive, i dati per i cluster in Cloud Monitoring possono contenere voci di metriche di riepilogo non pertinenti, come ad esempio:

    
Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile

    Altri tipi di metriche che potrebbero avere metriche di riepilogo non pertinenti includono

    :
    • apiserver_admission_step_admission_duration_seconds_summary
    • go_gc_duration_seconds
    • scheduler_scheduling_duration_seconds
    • gkeconnect_http_request_duration_seconds_summary
    • alertmanager_nflog_snapshot_duration_seconds_summary

    Sebbene queste metriche del tipo di riepilogo siano nell'elenco delle metriche, al momento non sono supportate da gke-metrics-agent.
    Logging e monitoraggio 1.10, 1.11, 1.12, 1.13

    Metriche mancanti su alcuni nodi

    Su alcuni nodi potrebbero mancare le seguenti metriche, ma non tutte:

    • kubernetes.io/anthos/container_memory_working_set_bytes
    • kubernetes.io/anthos/container_cpu_usage_seconds_total
    • kubernetes.io/anthos/container_network_receive_bytes_total

    Soluzione:

    Per risolvere il problema, procedi come descritto di seguito come soluzione alternativa. Per [versioni 1.9.5 e versioni successive, 1.10.2 e versioni successive, 1.11.0]: aumenta la CPU per gke-metrics-agent seguendo i passaggi 1 - 4

    1. Apri la risorsa stackdriver per la modifica: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit stackdriver stackdriver
    2. Per aumentare la richiesta di CPU per gke-metrics-agent da 10m a 50m, il limite di CPU da 100m a 200m aggiunge la seguente sezione resourceAttrOverride al manifest stackdriver : 
      
spec:
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 10m
        memory: 200Mi
      La risorsa modificata dovrebbe essere simile alla seguente: 
      
spec:
  anthosDistribution: on-prem
  clusterLocation: us-west1-a
  clusterName: my-cluster
  enableStackdriverForApplications: true
  gcpServiceAccountSecretName: ...
  optimizedMetrics: true
  portable: true
  projectID: my-project-191923
  proxyConfigSecretName: ...
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 200m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi
    3. Salva le modifiche e chiudi l'editor di testo.
    4. Per verificare che le modifiche siano state applicate, esegui questo comando: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system get daemonset gke-metrics-agent -o yaml \
    | grep "cpu: 50m"
      Il comando trova cpu: 50m se le modifiche sono state applicate.
    Logging e monitoraggio 1.11.0-1.11.2, 1.12.0

    Metriche scheduler e controller-manager mancanti nel cluster di amministrazione

    Se il tuo cluster di amministrazione è interessato da questo problema, le metriche di scheduler e gestore del controller non sono presenti. Ad esempio, queste due metriche mancano

    
# scheduler metric example
scheduler_pending_pods
# controller-manager metric example
replicaset_controller_rate_limiter_use

    Soluzione:

    Esegui l'upgrade alla v1.11.3+, v1.12.1+ o v1.13+.
    1.11.0-1.11.2, 1.12.0

    Metriche dello scheduler e del gestore del controller mancanti nel cluster utente

    Se il tuo cluster utente è interessato da questo problema, le metriche di scheduler e gestore del controller non sono presenti. Ad esempio, le due metriche mancano:

    
# scheduler metric example
scheduler_pending_pods
# controller-manager metric example
replicaset_controller_rate_limiter_use

    Soluzione:

    Questo problema è stato risolto nei cluster Anthos su VMware versione 1.13.0 e successive. Esegui l'upgrade del cluster a una versione con la correzione.
    Installazione, upgrade e aggiornamenti 1.10, 1.11, 1.12, 1.13

    Mancata registrazione del cluster di amministrazione durante la creazione

    Se crei un cluster di amministrazione per la versione 1.9.xo 1.10.0 e se il cluster di amministrazione non viene registrato con la specifica gkeConnect fornita durante la creazione, viene visualizzato l'errore seguente.

    
Failed to create root cluster: failed to register admin cluster: failed to register cluster: failed to apply Hub Membership: Membership API request failed: rpc error:  ode = PermissionDenied desc = Permission 'gkehub.memberships.get' denied on PROJECT_PATH

    Potrai comunque utilizzare questo cluster di amministrazione, ma riceverai il seguente errore se in seguito tenti di eseguire l'upgrade del cluster di amministrazione alla versione 1.10.y.

    
failed to migrate to first admin trust chain: failed to parse current version "": invalid version: "" failed to migrate to first admin trust chain: failed to parse current version "": invalid version: ""

    Soluzione:
    Identità 1.10, 1.11, 1.12, 1.13

    L'utilizzo del servizio Anthos Identity può causare il riavvio imprevedibile dell'agente Connect

    Se utilizzi la funzionalità Anthos Identity Service per gestire Anthos Identity Service ClientConfig, l' agente Connect potrebbe riavviarsi inaspettatamente.


    Soluzione:

    Se hai riscontrato questo problema in un cluster esistente, puoi eseguire una delle seguenti operazioni:

    • Disattiva Anthos Identity Service (AIS). Se disabiliti AIS, il programma binario AIS di cui è stato eseguito il deployment non verrà rimosso e non verrà rimosso ClientConfig di AIS. Per disabilitare AIS, esegui questo comando: 
      
gcloud beta container hub identity-service disable \
    --project PROJECT_NAME
      Sostituisci PROJECT_NAME con il nome del progetto host del parco risorse del cluster.
    • Aggiorna il cluster alla versione 1.9.3 o successiva oppure alla versione 1.10.1 o successiva, in modo da eseguire l'upgrade della versione di Connect Agent.
    Networking 1.10, 1.11, 1.12, 1.13

    Cisco ACI non funziona con il reso diretto da server (DSR)

    Seesaw viene eseguito in modalità DSR e, per impostazione predefinita, non funziona in Cisco ACI a causa dell'apprendimento IP del piano dati.


    Soluzione:

    Una possibile soluzione alternativa è disabilitare l'apprendimento IP aggiungendo l'indirizzo IP di Seesaw come IP virtuale L4-L7 in Cisco Application Policy Infrastructure Controller (APIC).

    Per configurare l'opzione IP virtuale L4-L7, vai a Tenant > Profili di applicazione > EPG di applicazioni o EPG uSeg. Se non disattivi l'apprendimento IP, l'endpoint IP si sposterà tra diverse posizioni nel tessuto dell'API Cisco.
    VMware 1.10, 1.11, 1.12, 1.13

    Problemi con l'aggiornamento 3 di vSphere 7.0

    VMWare ha identificato di recente problemi critici con le seguenti release dell'aggiornamento 3 di vSphere 7.0:

    • vSphere ESXi 7.0 aggiornamento 3 (build 18644231)
    • vSphere ESXi 7.0 aggiornamento 3a (build 18825058)
    • Aggiornamento 3b vSphere ESXi 7.0 (build 18905247)
    • vSphere vCenter 7.0 aggiornamento 3b (build 18901211)

    Soluzione:

    Da allora, VMware ha rimosso queste release. Devi eseguire l'upgrade di ESXi e dei server vCenter a una versione più recente.
    Sistema operativo 1.10, 1.11, 1.12, 1.13

    Errore nel montaggio del volume emptyDir come exec nel pod in esecuzione sui nodi COS

    Per i pod in esecuzione su nodi che utilizzano immagini Container-Optimized OS (COS), non puoi montare il volume emptyDir come exec. Si monta come noexec e verrà visualizzato il seguente errore: exec user process caused: permission denied. Ad esempio, visualizzerai questo messaggio di errore se esegui il deployment del seguente pod di test:

    
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: test
  name: test
spec:
  containers:
  - args:
    - sleep
    - "5000"
    image: gcr.io/google-containers/busybox:latest
    name: test
    volumeMounts:
      - name: test-volume
        mountPath: /test-volume
    resources:
      limits:
        cpu: 200m
        memory: 512Mi
  dnsPolicy: ClusterFirst
  restartPolicy: Always
  volumes:
    - emptyDir: {}
      name: test-volume

    Nel pod di test, se esegui mount | grep test-volume, viene visualizzata un'opzione noexec:

    
/dev/sda1 on /test-volume type ext4 (rw,nosuid,nodev,noexec,relatime,commit=30)

    Soluzione:
    Upgrade e aggiornamenti 1.10, 1.11, 1.12, 1.13

    L'aggiornamento della replica del pool di nodi del cluster non funziona dopo la disabilitazione della scalabilità automatica sul pool di nodi

    Le repliche del pool di nodi non vengono aggiornate dopo l'abilitazione e la disabilitazione della scalabilità automatica in un pool di nodi.


    Soluzione:

    Rimozione delle annotazioni cluster.x-k8s.io/cluster-api-autoscaler-node-group-max-size e cluster.x-k8s.io/cluster-api-autoscaler-node-group-min-size dal deployment delle macchine del pool di nodi corrispondente.
    Logging e monitoraggio 1.11, 1.12, 1.13

    Le dashboard di monitoraggio di Windows mostrano i dati dei cluster Linux

    Dalla versione 1.11, nelle dashboard di monitoraggio pronte all'uso, la dashboard dello stato dei pod Windows e la dashboard dello stato dei nodi Windows mostrano anche i dati dei cluster Linux. Questo avviene perché le metriche relative a nodi Windows e pod sono esposte anche sui cluster Linux.
    Logging e monitoraggio 1.10, 1.11, 1.12

    stackdriver-log-forwarder in CrashLoopBackOff costante

    Per i cluster Anthos su VMware versione 1.10, 1.11 e 1.12, stackdriver-log-forwarder DaemonSet potrebbe avere CrashLoopBackOff errori in caso di log con buffer rotti sul disco.


    Soluzione:

    Per mitigare il problema, dovremo ripulire i log presenti nel buffer sul nodo.

    1. Per prevenire il comportamento imprevisto, fare lo scale down stackdriver-log-forwarder: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n kube-system patch daemonset stackdriver-log-forwarder -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
      Sostituisci USER_CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster utente.
    2. Esegui il deployment del DaemonSet di pulizia per pulire i blocchi rotti: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    -n kube-system -f - << EOF
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit-cleanup
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: fluent-bit-cleanup
  template:
    metadata:
      labels:
        app: fluent-bit-cleanup
    spec:
      containers:
      - name: fluent-bit-cleanup
        image: debian:10-slim
        command: ["bash", "-c"]
        args:
        - |
          rm -rf /var/log/fluent-bit-buffers/
          echo "Fluent Bit local buffer is cleaned up."
          sleep 3600
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        securityContext:
          privileged: true
      tolerations:
      - key: "CriticalAddonsOnly"
        operator: "Exists"
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      - key: node-role.gke.io/observability
        effect: NoSchedule
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
EOF
    3. Per assicurarti che il DaemonSet di pulizia abbia pulito tutti i blocchi, puoi eseguire i seguenti comandi. L'output dei due comandi deve essere uguale al numero di nodo nel cluster: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  logs -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l
    4. Elimina il DaemonSet di pulizia: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system delete ds fluent-bit-cleanup
    5. Riprendi stackdriver-log-forwarder: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system patch daemonset stackdriver-log-forwarder --type json -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
    Logging e monitoraggio 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

    stackdriver-log-forwarder non invia log a Cloud Logging

    Se non vedi i log in Cloud Logging dai tuoi cluster e riscontri il seguente errore nei tuoi log: 

    
2023-06-02T10:53:40.444017427Z [2023/06/02 10:53:40] [error] [input chunk] chunk 1-1685703077.747168499.flb would exceed total limit size in plugin stackdriver.0
2023-06-02T10:53:40.444028047Z [2023/06/02 10:53:40] [error] [input chunk] no available chunk
    È probabile che la frequenza di input dei log superi il limite dell'agente di logging, di conseguenza stackdriver-log-forwarder non invierà i log. Questo problema si verifica in tutte le versioni di Cluster Anthos su VMware.

    Soluzione alternativa:

    Per mitigare questo problema, devi aumentare il limite delle risorse sull'agente Logging.

    1. Apri la risorsa stackdriver per la modifica: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system edit stackdriver stackdriver
    2. Per aumentare la richiesta di CPU per stackdriver-log-forwarder, aggiungi la seguente sezione resourceAttrOverride al manifest stackdriver : 
      
spec:
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder:
      limits:
        cpu: 1200m
        memory: 600Mi
      requests:
        cpu: 600m
        memory: 600Mi
      La risorsa modificata dovrebbe essere simile alla seguente: 
      
spec:
  anthosDistribution: on-prem
  clusterLocation: us-west1-a
  clusterName: my-cluster
  enableStackdriverForApplications: true
  gcpServiceAccountSecretName: ...
  optimizedMetrics: true
  portable: true
  projectID: my-project-191923
  proxyConfigSecretName: ...
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder:
      limits:
        cpu: 1200m
        memory: 600Mi
      requests:
        cpu: 600m
        memory: 600Mi
    3. Salva le modifiche e chiudi l'editor di testo.
    4. Per verificare che le modifiche siano state applicate, esegui questo comando: 
      
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    --namespace kube-system get daemonset stackdriver-log-forwarder -o yaml \
    | grep "cpu: 1200m"
      Il comando trova cpu: 1200m se le modifiche sono state applicate.
    Sicurezza 1,13

    Il servizio Kubelet non sarà temporaneamente disponibile dopo NodeReady

    C'è un breve periodo in cui il nodo è pronto, ma il certificato server kubelet non è pronto. kubectl exec e kubectl logs non sono disponibili in queste decine di secondi. Questo perché è necessario del tempo che il nuovo approvatore del certificato del server visualizzi gli IP validi aggiornati del nodo.

    Questo problema riguarda solo il certificato server kubelet, non influisce sulla pianificazione dei pod.
    Upgrade e aggiornamenti 1,12

    L'upgrade parziale del cluster di amministrazione non blocca l'upgrade del cluster utente successivo

    Upgrade del cluster utente non riuscito con:

    
.LBKind in body is required (Check the status of OnPremUserCluster 'cl-stg-gdl-gke-onprem-mgmt/cl-stg-gdl' and the logs of pod 'kube-system/onprem-user-cluster-controller' for more detailed debugging information.

    L'upgrade del cluster di amministrazione non è stato completato e la versione dello stato è ancora 1.10. L'upgrade del cluster utente alla versione 1.12 non verrà bloccato da alcun controllo preflight e non andrà a buon fine a causa di un problema di disallineamento della versione.


    Soluzione:

    Completa prima l'upgrade del cluster di amministrazione alla versione 1.11, quindi esegui l'upgrade del cluster utente alla versione 1.12.
    Archiviazione 1.10.0-1.10.5, 1.11.0-1.11.2, 1.12.0

    Datastore segnala in modo errato spazio libero insufficiente

    Comando gkectl diagnose cluster non riuscito con: 

    
Checking VSphere Datastore FreeSpace...FAILURE
    Reason: vCenter datastore: [DATASTORE_NAME] insufficient FreeSpace, requires at least [NUMBER] GB

    La convalida dello spazio libero del datastore non deve essere utilizzata per i pool di nodi del cluster esistenti ed è stata aggiunta per errore a gkectl diagnose cluster.


    Soluzione:

    Puoi ignorare il messaggio di errore o saltare la convalida utilizzando --skip-validation-infra.
    Operazione, networking 1.11, 1.12.0-1.12.1

    Mancata aggiunta del nuovo cluster utente quando il cluster di amministrazione utilizza il bilanciatore del carico MetalLB

    Potresti non essere in grado di aggiungere un nuovo cluster utente se il tuo cluster di amministrazione è impostato con una configurazione del bilanciatore del carico MetalLB.

    Il processo di eliminazione dei cluster utente potrebbe bloccarsi per qualche motivo, con il conseguente invalidamento del ConfigMap di MatalLB. Non sarà possibile aggiungere un nuovo cluster utente in questo stato.


    Soluzione:

    Puoi forzare l'eliminazione del cluster utente.
    Installazione, sistema operativo 1.10, 1.11, 1.12, 1.13

    Errore durante l'utilizzo Container-Optimized OS per il cluster utente

    Se osImageType utilizza cos per il cluster di amministrazione e quando gkectl check-config viene eseguito dopo la creazione del cluster di amministrazione e prima della creazione del cluster utente, avrà esito negativo: 

    
Failed to create the test VMs: VM failed to get IP addresses on the network.

    La VM di test creata per il cluster utente check-config per impostazione predefinita utilizza la stessa osImageType del cluster di amministrazione e al momento VM di test non è ancora compatibile con COS.


    Soluzione:

    Per evitare il controllo preflight lento che crea la VM di test, utilizza gkectl check-config --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG --fast.
    Logging e monitoraggio 1.12.0-1.12.1

    Grafana nel cluster di amministrazione non è in grado di raggiungere i cluster utente

    Questo problema riguarda i clienti che utilizzano Grafana nel cluster di amministrazione per monitorare i cluster utente nei cluster Anthos su VMware versioni 1.12.0 e 1.12.1. Proviene da una mancata corrispondenza dei certificati pushprox-client nei cluster utente e dalla lista consentita nel server pushprox nel cluster di amministrazione. Il sintomo è pushprox-client nei cluster utente che stampano i log degli errori come segue:

    
level=error ts=2022-08-02T13:34:49.41999813Z caller=client.go:166 msg="Error reading request:" err="invalid method \"RBAC:\""

    Soluzione:
    Altro 1,11,3

    gkectl repair admin-master non fornisce il modello di VM da utilizzare per il recupero

    Comando gkectl repair admin-master non riuscito con: 

    
Failed to repair: failed to select the template: no VM templates is available for repairing the admin master (check if the admin cluster version >= 1.4.0 or contact support

    gkectl repair admin-master non è in grado di recuperare il modello di VM da utilizzare per riparare la VM del piano di controllo amministratore se il nome della VM del piano di controllo amministratore termina con i caratteri t, m, p o l.


    Soluzione:

    Esegui di nuovo il comando con --skip-validation.
    Logging e monitoraggio 1.11, 1.12, 1.13, 1.14, 1.15

    Errore di audit logging di Cloud dovuto a un'autorizzazione negata

    Audit logging di Cloud Cloud richiede una configurazione di autorizzazioni speciale che attualmente viene eseguita automaticamente solo per i cluster utente tramite GKE Hub. È consigliabile avere almeno un cluster utente che utilizzi lo stesso ID progetto e account di servizio con il cluster di amministrazione per l'audit logging di Cloud, in modo che il cluster di amministrazione disponga dell'autorizzazione necessaria per l'audit logging di Cloud.

    Tuttavia, nei casi in cui il cluster di amministrazione utilizza un ID progetto o un account di servizio diverso con qualsiasi cluster utente, gli audit log del cluster di amministrazione non verranno inseriti nel cloud. Il sintomo è una serie di errori Permission Denied nel pod audit-proxy del cluster di amministrazione.


    Soluzione:
    Operazione, sicurezza 1.11

    gkectl diagnose controllo dei certificati non riuscito

    Se la tua postazione di lavoro non ha accesso ai nodi worker del cluster utente, si verificherà i seguenti errori durante l'esecuzione di gkectl diagnose:

    
Checking user cluster certificates...FAILURE
    Reason: 3 user cluster certificates error(s).
    Unhealthy Resources:
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out

    Se la tua stazione di lavoro non ha accesso ai nodi worker del cluster di amministrazione o ai nodi worker del cluster di amministrazione, durante l'esecuzione di gkectl diagnose si verificheranno i seguenti errori:

    
Checking admin cluster certificates...FAILURE
    Reason: 3 admin cluster certificates error(s).
    Unhealthy Resources:
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out
    Node kubelet CA and certificate on node xxx: failed to verify kubelet certificate on node xxx: dial tcp xxx.xxx.xxx.xxx:10250: connect: connection timed out

    Soluzione:

    Se puoi ignorare questi messaggi, puoi ignorarli.
    Sistema operativo 1.8, 1.9, 1.10, 1.11, 1.12, 1.13

    /var/log/audit/ esauriscono lo spazio su disco nella workstation di amministrazione

    /var/log/audit/ contiene audit log. Puoi controllare l'utilizzo del disco eseguendo sudo du -h -d 1 /var/log/audit.

    Alcuni comandi gkectl sulla workstation di amministrazione, ad esempio gkectl diagnose snapshot, contribuiscono all'utilizzo dello spazio su disco.

    A partire da Anthos v1.8, l'immagine Ubuntu è protetta con CIS Level 2 Benchmark. E una delle regole di conformità, "4.1.2.2 Assicurati che gli audit log non vengano eliminati automaticamente", assicura che l'impostazione controllata max_log_file_action = keep_logs. In questo modo tutte le regole di controllo vengono mantenute sul disco.


    Soluzione:
    Networking 1.10, 1.11.0-1.11.3, 1.12.0-1.12.2, 1.13.0

    NetworkGatewayGroup conflitti di indirizzi IP in conflitto con gli indirizzi dei nodi

    Gli utenti non sono in grado di creare o aggiornare NetworkGatewayGroup oggetti a causa del seguente errore di convalida del webhook:

    
[1] admission webhook "vnetworkgatewaygroup.kb.io" denied the request: NetworkGatewayGroup.networking.gke.io "default" is invalid: [Spec.FloatingIPs: Invalid value: "10.0.0.100": IP address conflicts with node address with name: "my-node-name"

    Nelle versioni interessate, il kubelet può eseguire l'associazione errata a un indirizzo IP mobile assegnato al nodo e segnalarlo come indirizzo di nodo in node.status.addresses. Il webhook di convalida controlla gli indirizzi IP mobili di NetworkGatewayGroup rispetto a tutti i node.status.addresses nel cluster e considera questo un conflitto.


    Soluzione:

    Nello stesso cluster in cui la creazione o l'aggiornamento di NetworkGatewayGroup oggetti non va a buon fine, disattiva temporaneamente il webhook di convalida ANG e invia la modifica:

    1. Salva la configurazione del webhook in modo da ripristinarla alla fine: 
      
kubectl -n kube-system get validatingwebhookconfiguration \
    ang-validating-webhook-configuration -o yaml > webhook-config.yaml
    2. Modifica la configurazione del webhook: 
      
kubectl -n kube-system edit validatingwebhookconfiguration \
    ang-validating-webhook-configuration
    3. Rimuovi l'elemento vnetworkgatewaygroup.kb.io dall'elenco di configurazione del webhook e chiudi per applicare le modifiche.
    4. Crea o modifica l'oggetto NetworkGatewayGroup.
    5. Applica di nuovo la configurazione del webhook originale: 
      
kubectl -n kube-system apply -f webhook-config.yaml
    Installazione, upgrade e aggiornamenti 1.10.0-1.10.2

    Creazione o upgrade del timeout del cluster di amministrazione

    Durante un tentativo di upgrade del cluster di amministrazione, la VM del piano di controllo dell'amministratore potrebbe bloccarsi durante la creazione. La VM del piano di controllo dell'amministratore entra in un ciclo di attesa infinito durante l'avvio e nel file /var/log/cloud-init-output.log vedrai il seguente errore di loop infinito:

    
+ echo 'waiting network configuration is applied'
waiting network configuration is applied
++ get-public-ip
+++ ip addr show dev ens192 scope global
+++ head -n 1
+++ grep -v 192.168.231.1
+++ grep -Eo 'inet ([0-9]{1,3}\.){3}[0-9]{1,3}'
+++ awk '{print $2}'
++ echo
+ '[' -n '' ']'
+ sleep 1
+ echo 'waiting network configuration is applied'
waiting network configuration is applied
++ get-public-ip
+++ ip addr show dev ens192 scope global
+++ grep -Eo 'inet ([0-9]{1,3}\.){3}[0-9]{1,3}'
+++ awk '{print $2}'
+++ grep -v 192.168.231.1
+++ head -n 1
++ echo
+ '[' -n '' ']'
+ sleep 1

    Infatti, quando Cluster Anthos su VMware tenta di ottenere l'indirizzo IP del nodo nello script di avvio, utilizza grep -v ADMIN_CONTROL_PLANE_VIP per ignorare il VIP del piano di controllo del cluster di amministrazione, che può essere assegnato anche al NIC. Tuttavia, il comando ignora anche qualsiasi indirizzo IP con un prefisso del VIP del piano di controllo, causando il blocco dello script di avvio.

    Ad esempio, supponiamo che il VIP del piano di controllo del cluster di amministrazione sia 192.168.1.25. Se l'indirizzo IP della VM del piano di controllo del cluster di amministrazione ha lo stesso prefisso, ad esempio 192.168.1.254, la VM del piano di controllo verrà bloccata durante la creazione. Questo problema può essere percepito anche se l'indirizzo di trasmissione ha lo stesso prefisso del VIP del piano di controllo, ad esempio 192.168.1.255.


    Soluzione:

    • Se il motivo del timeout della creazione del cluster di amministrazione è dovuto all'indirizzo IP di trasmissione, esegui il comando seguente sulla VM del piano di controllo del cluster di amministrazione: 
      
ip addr add ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
      L'operazione creerà una riga senza un indirizzo di trasmissione e sbloccherà il processo di avvio. Una volta sbloccato lo script di avvio, rimuovi questa riga aggiunta eseguendo il comando seguente: 
      
ip addr del ${ADMIN_CONTROL_PLANE_NODE_IP}/32 dev ens192
    • Tuttavia, se il motivo del timeout della creazione del cluster di amministrazione è dovuto all'indirizzo IP della VM del piano di controllo, non puoi sbloccare lo script di avvio. Passa a un altro indirizzo IP e ricrea o esegui l'upgrade alla versione 1.10.3 o successiva.
    Sistema operativo, upgrade e aggiornamenti 1.10.0-1.10.2

    Lo stato del cluster di amministrazione che utilizza l'immagine COS andrà perso dopo l'upgrade del cluster di amministrazione o la riparazione del master di amministrazione

    DataDisk non può essere montato correttamente sul nodo master del cluster di amministrazione quando si utilizza l'immagine COS e lo stato del cluster di amministrazione utilizzando l'immagine COS andrà perso dopo l'upgrade del cluster di amministrazione o la riparazione del master di amministrazione. (il cluster di amministrazione che utilizza l'immagine COS è una funzionalità in anteprima)


    Soluzione:

    Ricrea cluster di amministrazione con osImageType impostato su ubuntu_containerd

    Dopo aver creato il cluster di amministrazione con osImageType impostato su cos, prendi la chiave SSH del cluster di amministrazione e SSH nel nodo master di amministrazione. Il risultato df -h contiene /dev/sdb1 98G 209M 93G 1% /opt/data. E il risultato lsblk contiene -sdb1 8:17 0 100G 0 part /opt/data
    Sistema operativo 1,1

    ricerca DNS non risolta dal sistema non riuscita su .local dominio

    Nei cluster Anthos su VMware versione 1.10.0, le risoluzioni dei nomi su Ubuntu vengono instradate all'ascolto risolto a livello di sistema locale su 127.0.0.53 per impostazione predefinita. Il motivo è che nell'immagine 20.04 Ubuntu utilizzata nella versione 1.10.0, /etc/resolv.conf è collegato in modo simbolico a /run/systemd/resolve/stub-resolv.conf, che rimanda allo stub DNS localhost 127.0.0.53.

    Di conseguenza, la risoluzione dei nomi DNS localhost rifiuta di controllare i server DNS a monte (specificati in /run/systemd/resolve/resolv.conf) per i nomi con un suffisso .local, a meno che non siano specificati come domini di ricerca.

    In questo modo, le ricerche di nomi .local non andranno a buon fine. Ad esempio, durante l'avvio del nodo, kubelet non riesce a estrarre immagini da un registro privato con un suffisso .local. La specifica di un indirizzo vCenter con un suffisso .local non funzionerà su una workstation di amministrazione.


    Soluzione:

    Puoi evitare questo problema per i nodi del cluster se specifichi il campo searchDomainsForDNS nel file di configurazione del cluster di amministrazione e nel file di configurazione del cluster utente per includere i domini.

    Attualmente gkectl update non supporta ancora l'aggiornamento del campo searchDomainsForDNS.

    Pertanto, se non hai configurato questo campo prima della creazione del cluster, devi connetterti ai nodi mediante SSH e bypassare lo stub locale risolto dal sistema modificando il collegamento simbolico di /etc/resolv.conf da /run/systemd/resolve/stub-resolv.conf (che contiene lo stub locale 127.0.0.53) a /run/systemd/resolve/resolv.conf (che rimanda al DNS effettivo a monte): 

    
sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

    Per quanto riguarda la workstation di amministrazione, gkeadm non supporta la specifica dei domini di ricerca, quindi deve essere risolto con questo passaggio manuale.

    Questa soluzione per non viene preservata nelle repliche delle VM. Devi riapplicare questa soluzione alternativa ogni volta che vengono ricreate le VM.
    Installazione, sistema operativo 1,1

    L'IP del bridge Docker utilizza 172.17.0.1/16 invece di 169.254.123.1/24

    Cluster Anthos su VMware specifica una subnet dedicata per l'indirizzo IP del bridge Docker che utilizza --bip=169.254.123.1/24, in modo che non prenoti la subnet 172.17.0.1/16 predefinita. Tuttavia, nella versione 1.10.0, è presente un bug nell'immagine del sistema operativo Ubuntu che ha causato l'esclusione della configurazione Docker personalizzata.

    Di conseguenza, Docker sceglie l'impostazione predefinita 172.17.0.1/16 come subnet per l'indirizzo IP del bridge. Ciò potrebbe causare un conflitto di indirizzi IP se hai già un carico di lavoro in esecuzione entro quell'intervallo di indirizzi IP.


    Soluzione:

    Per risolvere il problema, devi rinominare il seguente file di configurazione di sistema per dockerd, quindi riavviare il servizio:

    
sudo mv /etc/systemd/system/docker.service.d/50-cloudimg-settings.cfg \
    /etc/systemd/system/docker.service.d/50-cloudimg-settings.conf

sudo systemctl daemon-reload

sudo systemctl restart docker

    Verifica che Docker scelga l'indirizzo IP del bridge corretto:

    
ip a | grep docker0

    Questa soluzione non viene preservata tra le varie repliche delle VM. Devi applicare nuovamente questa soluzione alternativa ogni volta che vengono ricreate le VM.
    Upgrade e aggiornamenti 1.11

    L'upgrade a 1.11 è bloccato dall'idoneità a stackdriver

    Nei cluster Anthos su VMware versione 1.11.0, sono state apportate modifiche alla definizione delle risorse personalizzate relative al logging e al monitoraggio:

    • Nome del gruppo di risorse personalizzate stackdriver modificato da addons.sigs.k8s.io a addons.gke.io;
    • Nome del gruppo di risorse personalizzate monitoring e metricsserver cambiato da addons.k8s.io a addons.gke.io;
    • Le specifiche delle risorse di cui sopra iniziano a essere confrontate con lo schema. In particolare, le specifiche di resourceAttrOverride e storageSizeOverride nella risorsa personalizzata stackdriver devono avere un tipo di stringa nei valori delle richieste e dei limiti di CPU, memoria e dimensioni di archiviazione.

    Le modifiche ai nomi dei gruppi vengono apportate per rispettare gli aggiornamenti CustomResourceDefinition in Kubernetes 1.22.

    Non devi fare nulla se non hai a disposizione una logica aggiuntiva che applica o modifica le risorse personalizzate interessate. Il processo di upgrade dei cluster Anthos su VMware si occuperà della migrazione delle risorse interessate e manterrà le specifiche esistenti dopo la modifica del nome del gruppo.

    Tuttavia, se esegui una logica che applica o modifica le risorse interessate, è necessaria un'attenzione particolare. Innanzitutto, devono fare riferimento al nuovo nome del gruppo nel file manifest, Ecco alcuni esempi:

    
apiVersion: addons.gke.io/v1alpha1  ## instead of `addons.sigs.k8s.io/v1alpha1`
kind: Stackdriver

    In secondo luogo, assicurati che i valori delle specifiche resourceAttrOverride e storageSizeOverride siano di tipo stringa. Ecco alcuni esempi:

    
spec:
  resourceAttrOverride:
    stackdriver-log-forwarder/stackdriver-log-forwarder
      limits:
        cpu: 1000m # or "1"
        # cpu: 1 # integer value like this would not work
        memory: 3000Mi

    In caso contrario, le applicazioni e le modifiche non avranno effetto e potrebbero determinare uno stato imprevisto nei log e nel monitoraggio dei componenti. Possibili sintomi:

    • Log degli errori di riconciliazione in onprem-user-cluster-controller, ad esempio: 
      
potential reconciliation error: Apply bundle components failed, requeue after 10s, error: failed to apply addon components: failed to apply bundle objects from stackdriver-operator-addon 1.11.2-gke.53 to cluster my-cluster: failed to create typed live object: .spec.resourceAttrOverride.stackdriver-log-forwarder/stackdriver-log-forwarder.limits.cpu: expected string, got &value.valueUnstructured{Value:1}
    • Errore in kubectl edit stackdriver stackdriver, ad esempio: 
      
Error from server (NotFound): stackdrivers.addons.gke.io "stackdriver" not found

    Se riscontri gli errori sopra riportati, significa che prima dell'upgrade era già presente un tipo non supportato nella specifica CR di stackdriver. Per risolvere il problema, puoi modificare manualmente la RP di Driver con il nome del gruppo precedente kubectl edit stackdrivers.addons.sigs.k8s.io stackdriver e procedere nel seguente modo:

    1. modifica le richieste e i limiti delle risorse in tipo stringa;
    2. Rimuovi l'eventuale annotazione addons.gke.io/migrated-and-deprecated: true, se presente.
    Quindi, riavvia o riavvia la procedura di upgrade.

    Sistema operativo 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, 1.14, 1.15

    Le VM COS non mostrano IP quando le VM vengono spostate attraverso un arresto non grazioso dell'host

    Ogni volta che si verifica un errore in un server ESXi e la funzione vCenter HA è stata abilitata per il server, tutte le VM nel server ESXi difettose attivano il meccanismo vMotion e vengono spostate in un altro server ESXi normale. Le VM COS sottoposte a migrazione perderanno i loro indirizzi IP.

    Soluzione:

    Riavvia la VM
    Se hai bisogno di ulteriore aiuto, contatta l'Assistenza Google.