Google Distributed Cloud per problemi noti bare metal

Questa pagina elenca tutti i problemi noti di Google Distributed Cloud (solo software) per bare metal, precedentemente noto come Google Distributed Cloud. Per filtrare i problemi noti in base a una versione o categoria del prodotto, seleziona i filtri dai seguenti menu a discesa.

Seleziona la versione di Google Distributed Cloud:

Seleziona la categoria del problema:

In alternativa, cerca il problema:

Categoria Versioni identificate Problema e soluzione alternativa
Installazione, upgrade e aggiornamenti Da 1.28.0 a 1.28.600 e da 1.29.0 a 1.29.200

Errori del controllo preflight della macchina per le impostazioni check_inotify_max_user_instances e check_inotify_max_user_watches

Durante l'installazione o l'upgrade del cluster, i controlli preflight della macchina relativi alle impostazioni del kernel fs.inotify potrebbero non riuscire. Se si verifica questo problema, il log dei controlli preflight della macchina contiene un errore simile al seguente:

Minimum kernel setting required for fs.inotify.max_user_instances is 8192. Current fs.inotify.max_user_instances value is 128. Please run "echo "fs.inotify.max_user_instances=8192" | sudo tee --append /etc/sysctl.conf" to set the correct value.

Questo problema si verifica perché i valori fs.inotify max_user_instances e max_user_watches vengono letti in modo errato dal piano di controllo e dagli host di bootstrap, invece che dalle macchine nodo previste.

Soluzione:
Per aggirare il problema, modifica fs.inotify.max_user_instances e fs.inotify.max_user_watches sui valori consigliati su tutte le macchine del piano di controllo e di bootstrap:

echo fs.inotify.max_user_watches=524288 | sudo tee --append /etc/sysctl.conf
echo fs.inotify.max_user_instances=8192 | sudo tee --append /etc/sysctl.conf
sudo sysctl -p

Al termine dell'operazione di installazione o upgrade, questi valori possono essere ripristinati, se necessario.

Configurazione, Installazione, Upgrade e aggiornamenti, Networking, Sicurezza 1,15; 1,16; 1,28; 1,29

L'installazione e l'upgrade del cluster non riescono quando è richiesto ipam-controller-manager

L'installazione e l'upgrade del cluster non vanno a buon fine quando è richiesto ipam-controller-manager e il cluster è in esecuzione su Red Hat Enterprise Linux (RHEL) 8.9 o versioni successive (a seconda delle modifiche RHEL upstream) con SELinux in esecuzione in modalità di applicazione forzata. Ciò si applica in particolare quando la versione di container-selinux è successiva alla 2.225.0.

Il cluster richiede ipam-controller-manager in una delle seguenti situazioni:

  • Il cluster è configurato per il networking a doppio stack IPv4/IPv6
  • Il cluster è configurato con l'opzione clusterNetwork.flatIPv4 impostata su true
  • Il cluster è configurato con l'annotazione preview.baremetal.cluster.gke.io/multi-networking: enable

L'installazione e l'upgrade del cluster non vanno a buon fine quando ipam-controller-manager è installato.

Soluzione alternativa

Imposta il contesto predefinito per la directory /etc/kubernetes su ciascun nodo del piano di controllo in modo da digitare etc_t:

semanage fcontext /etc/kubernetes --add -t etc_t
semanage fcontext /etc/kubernetes/controller-manager.conf --add -t etc_t
restorecon -R /etc/kubernetes

Questi comandi ripristinano la modifica container-selinux nella directory /etc/kubernetes.

Dopo aver eseguito l'upgrade del cluster a una versione con la correzione, annulla la precedente modifica del contesto dei file su ciascun nodo del piano di controllo:

semanage fcontext /etc/kubernetes --delete -t etc_t
semanage fcontext /etc/kubernetes/controller-manager.conf --delete -t etc_t
restorecon -R /etc/kubernetes
Upgrade 1,28,0 - 1,28.500

L'upgrade del cluster non va a buon fine a causa dell'errore del controllo della connettività di Google Cloud

Quando utilizzi bmctl per eseguire l'upgrade di un cluster, l'upgrade potrebbe non riuscire e restituire un errore GCP reachability check failed anche se l'URL di destinazione è raggiungibile dalla workstation di amministrazione. Questo problema è causato da un bug nelle versioni da 1.28.0 a 1.28.500 di bmctl.

Soluzione:

Prima di eseguire il comando bmctl upgrade, imposta la variabile di ambiente GOOGLE_APPLICATION_CREDENTIALS in modo che punti a un file di chiave dell'account di servizio valido:

export GOOGLE_APPLICATION_CREDENTIALS=JSON_KEY_PATH
bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

L'impostazione delle credenziali predefinite dell'applicazione (ADC) in questo modo garantisce che bmctl disponga delle credenziali necessarie per accedere all'endpoint API di Google.

Configurazione, Installazione, Upgrade e aggiornamenti, Networking, Sicurezza 1,15; 1,16; 1,28; 1,29

L'installazione e l'upgrade del cluster non riescono quando è richiesto ipam-controller-manager

L'installazione e l'upgrade del cluster non vanno a buon fine quando è richiesto ipam-controller-manager e il cluster è in esecuzione su Red Hat Enterprise Linux (RHEL) 8.9 o versioni successive (a seconda delle modifiche RHEL upstream) con SELinux in esecuzione in modalità di applicazione forzata. Ciò si applica in particolare quando la versione di container-selinux è successiva alla 2.225.0.

Il cluster richiede ipam-controller-manager in una delle seguenti situazioni:

  • Il cluster è configurato per il networking a doppio stack IPv4/IPv6
  • Il cluster è configurato con l'opzione clusterNetwork.flatIPv4 impostata su true
  • Il cluster è configurato con l'annotazione preview.baremetal.cluster.gke.io/multi-networking: enable

L'installazione e l'upgrade del cluster non vanno a buon fine quando ipam-controller-manager è installato.

Soluzione alternativa

Imposta il contesto predefinito per la directory /etc/kubernetes su ciascun nodo del piano di controllo in modo da digitare etc_t:

semanage fcontext /etc/kubernetes --add -t etc_t
semanage fcontext /etc/kubernetes/controller-manager.conf --add -t etc_t
restorecon -R /etc/kubernetes

Questi comandi ripristinano la modifica container-selinux nella directory /etc/kubernetes.

Dopo aver eseguito l'upgrade del cluster a una versione con la correzione, annulla la precedente modifica del contesto dei file su ciascun nodo del piano di controllo:

semanage fcontext /etc/kubernetes --delete -t etc_t
semanage fcontext /etc/kubernetes/controller-manager.conf --delete -t etc_t
restorecon -R /etc/kubernetes
Upgrade 1,28,0 - 1,28.500

L'upgrade del cluster non va a buon fine a causa dell'errore del controllo della connettività di Google Cloud

Quando utilizzi bmctl per eseguire l'upgrade di un cluster, l'upgrade potrebbe non riuscire e restituire un errore GCP reachability check failed anche se l'URL di destinazione è raggiungibile dalla workstation di amministrazione. Questo problema è causato da un bug nelle versioni da 1.28.0 a 1.28.500 di bmctl.

Soluzione:

Prima di eseguire il comando bmctl upgrade, imposta la variabile di ambiente GOOGLE_APPLICATION_CREDENTIALS in modo che punti a un file di chiave dell'account di servizio valido:

export GOOGLE_APPLICATION_CREDENTIALS=JSON_KEY_PATH
bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

L'impostazione delle credenziali predefinite dell'applicazione (ADC) in questo modo garantisce che bmctl disponga delle credenziali necessarie per accedere all'endpoint API di Google.

Installazione 1,29

Problema di Autorizzazione binaria per un cluster con un pool di nodi del bilanciatore del carico separato

L'installazione di un cluster con un pool di nodi del bilanciatore del carico separato potrebbe non riuscire se abiliti il criterio di Autorizzazione binaria durante la creazione del cluster.

Questo problema si verifica perché la creazione del pod del servizio di identità GKE e di altri pod critici è bloccata dal webhook di Autorizzazione binaria.

Per determinare se hai riscontrato questo problema, completa i seguenti passaggi:

  1. Identifica i pod in stato di errore:
    kubectl get pods \
        -n anthos-identity-service \
        --kubeconfig CLUSTER_KUBECONFIG
    
  2. Descrivere il pod danneggiato.
  3. Cerca il seguente messaggio nell'output:
  4. admission webhook "binaryauthorization.googleapis.com" denied the
            request: failed to post request to endpoint: Post
    "https://binaryauthorization.googleapis.com/internal/projects/PROJECT_NUMBER/policy/locations/LOCATION/clusters/CLUSTER_NAME:admissionReview":
            oauth2/google: status code 400:
    {"error":"invalid_target","error_description":"The
            target service indicated by the \"audience\" parameters is invalid.
    This might either be because the pool or provider is disabled or deleted
    or because it doesn't exist."}
    

    Se viene visualizzato il messaggio precedente, significa che il problema è presente nel cluster.

Soluzione:

Per aggirare questo problema, procedi nel seguente modo:

  1. Annulla l'operazione di creazione del cluster.
  2. Rimuovi il blocco spec.binaryAuthorization dal file di configurazione del cluster.
  3. Crea il cluster con Autorizzazione binaria disabilitata.
  4. Al termine dell'installazione, abilita il criterio di Autorizzazione binaria per un cluster esistente.
Configurazione, installazione 1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16, 1,28 e 1,29

Punti di montaggio con SELinux abilitato che causano problemi

Se hai abilitato SELinux e monta i file system nelle directory correlate a Kubernetes, potresti riscontrare problemi come errori di creazione del cluster, file illeggibili o problemi di autorizzazione.

Per determinare se hai riscontrato questo problema, esegui questo comando:

ls -Z /var/lib/containerd
. Se vedi system_u:object_r:unlabeled_t:s0 dove ti aspetti di vedere un'altra etichetta, ad esempio system_u:object_r:container_var_lib_t:s0, è interessato.

Soluzione:

Se di recente hai montato file system nelle directory, assicurati che queste directory siano aggiornate con la configurazione SELinux.

Devi anche eseguire i comandi seguenti su ogni macchina prima di eseguire bmctl create cluster:

restorecon -R -v /var
restorecon -R -v /etc

Questa correzione una tantum persisterà dopo il riavvio, ma è obbligatoria ogni volta che viene aggiunto un nuovo nodo con gli stessi punti di montaggio. Per ulteriori informazioni, consulta la sezione Mounting File Systems nella documentazione di Red Hat.

Ripristino/eliminazione 1.29.0

La reimpostazione del cluster utente non riesce a eliminare lo spazio dei nomi

Durante l'esecuzione di bmctl reset cluster -c ${USER_CLUSTER}, al termine di tutti i job correlati, il comando non riesce a eliminare lo spazio dei nomi del cluster utente. Lo spazio dei nomi del cluster utente è bloccato nello stato Terminating. Alla fine, la reimpostazione del cluster scade e restituisce un errore.

Soluzione:

Per rimuovere lo spazio dei nomi e completare la reimpostazione del cluster utente, segui questi passaggi:

  1. Elimina il pod metrics-server dal cluster di amministrazione:
    kubectl delete pods -l k8s-app=metrics-server \
        -n gke-managed-metrics-server --kubeconfig ADMIN_KUBECONFIG_PATH
    
    In questo caso, il pod metrics-server impedisce la rimozione dello spazio dei nomi del cluster.
  2. Nel cluster di amministrazione, forza la rimozione del finalizzatore nello spazio dei nomi del cluster utente:
    kubectl get ns ${USER_CLUSTER_NAMESPACE} -ojson | \
        jq '.spec.finalizers = []' | \
        kubectl replace --raw "/api/v1/namespaces/${USER_CLUSTER_NAMESPACE}/finalize" -f -
    
    Una volta rimosso il finalizzatore, lo spazio dei nomi del cluster viene rimosso e la reimpostazione del cluster è stata completata.
Configurazione, installazione, sicurezza Da 1.16.0 a 1.16.7 e da 1.28.0 a 1.28.400

Nel deployment di Autorizzazione binaria manca un nodeSelector

Se hai abilitato Autorizzazione binaria per Google Distributed Cloud e utilizzi una versione da 1.16.0 a 1.16.7 o da 1.28.0 a 1.28.400, potresti riscontrare un problema relativo alla pianificazione dei pod per la funzionalità. In queste versioni, al deployment di Autorizzazione binaria manca un nodeSelector, quindi i pod per la funzionalità possono essere pianificati sui nodi worker anziché sui nodi del piano di controllo. Questo comportamento non causa errori, ma non è intenzionale.

Soluzione:

Per tutti i cluster interessati, completa questi passaggi:

  1. Apri il file del deployment di Autorizzazione binaria:
    kubectl edit -n binauthz-system deployment binauthz-module-deployment
  2. Aggiungi il seguente nodeSelector nel blocco spec.template.spec:
  3.       nodeSelector:
            node-role.kubernetes.io/control-plane: ""
    
  4. Salva le modifiche.

Una volta salvata la modifica, viene eseguito nuovamente il deployment dei pod solo nei nodi del piano di controllo. Questa correzione deve essere applicata dopo ogni upgrade.

Upgrade e aggiornamenti 1.28.0, 1.28.100, 1.28.200, 1.28.300

Errore durante l'upgrade di un cluster a 1.28.0-1.28.300

L'upgrade dei cluster creati prima della versione 1.11.0 alle versioni 1.28.0-1.28.300 potrebbe causare l'ingresso in uno stato di errore del pod del deployment del controller del controller del ciclo di vita durante l'upgrade. In questo caso, i log del pod di deployment del controller del ciclo di vita presentano un messaggio di errore simile al seguente:

"inventorymachines.baremetal.cluster.gke.io\" is invalid: status.storedVersions[0]: Invalid value: \"v1alpha1\": must appear in spec.versions

Soluzione:

Questo problema è stato risolto nella versione 1.28.400. Esegui l'upgrade alla versione 1.28.400 o successiva per risolvere il problema.

Se non riesci a eseguire l'upgrade, esegui questi comandi per risolvere il problema:

kubectl patch customresourcedefinitions/nodepoolclaims.baremetal.cluster.gke.io \
    --subresource status --type json \
    --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]'

kubectl patch customresourcedefinitions/machineclasses.baremetal.cluster.gke.io \
    --subresource status --type json \
    --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]'

kubectl patch customresourcedefinitions/inventorymachines.baremetal.cluster.gke.io \
    --subresource status --type json \
    --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]'
Logging e monitoraggio 1,13,7, 1,14, 1,15, 1,16 e 1,28

ID progetto errato visualizzato in Esplora log

A volte i log dei cluster o dei container sono contrassegnati con un ID progetto diverso in resource.labels.project_id di Esplora log.

Ciò può accadere quando il cluster è configurato per utilizzare l'osservabilità PROJECT_ONE, impostata nel campo clusterOperations.projectID nella configurazione del cluster. Tuttavia, cloudOperationsServiceAccountKeyPath nella configurazione ha una chiave dell'account di servizio del progetto PROJECT_TWO.

In questi casi, tutti i log vengono instradati a PROJECT_ONE, ma resource.labels.project_id ha l'etichetta PROJECT_TWO.

Soluzione:

Utilizza una delle seguenti opzioni per risolvere il problema:

  • Utilizza un account di servizio dello stesso progetto di destinazione.
  • Modifica project_id nel file JSON della chiave dell'account di servizio con il progetto attuale.
  • Modifica il project_id direttamente nel filtro dei log da Esplora log.
Networking 1.29.0

Riduzione delle prestazioni per i cluster che utilizzano il bilanciamento del carico in bundle con BGP

Per i cluster della versione 1.29.0 che utilizzano il bilanciamento del carico in bundle con BGP, le prestazioni del bilanciamento del carico possono peggiorare man mano che il numero totale di servizi di tipo LoadBalancer si avvicina a 2000. Con il peggioramento delle prestazioni, i servizi appena creati richiedono molto tempo per connettersi o non possono essere connessi da un client. I servizi esistenti continuano a funzionare, ma non gestiscono in modo efficace le modalità di errore, come la perdita di un nodo del bilanciatore del carico. Questi problemi dei servizi si verificano quando il deployment ang-controller-manager viene terminato per esaurimento della memoria.

Se il tuo cluster è interessato da questo problema, i servizi nel cluster sono irraggiungibili e non in stato integro e il deployment ang-controller-manager è in un CrashLoopBackOff. La risposta quando elenchi i deployment ang-controller-manager è simile alla seguente:

ang-controller-manager-79cdd97b88-9b2rd   0/1    CrashLoopBackOff   639 (59s ago)   2d10h   10.250.210.152   vm-bgplb-centos4-n1-02   <none>   <none>

ang-controller-manager-79cdd97b88-r6tcl   0/1   CrashLoopBackOff   620 (4m6s ago)   2d10h   10.250.202.2     vm-bgplb-centos4-n1-11   <none>   <none>

Soluzione alternativa

Come soluzione alternativa, puoi aumentare il limite di risorse di memoria del deployment ang-controller-manager di 100 MiB e rimuovere il limite di CPU:

kubectl edit deployment ang-controller-manager -n kube-system --kubeconfig ADMIN_KUBECONFIG

Dopo aver apportato le modifiche e aver chiuso l'editor, dovresti vedere il seguente output:

deployment.apps/ang-controller-manager edited

Per verificare che le modifiche siano state applicate, controlla il manifest di ang-controller-manager nel cluster:

kubectl get deployment ang-controller-manager \
   -n kube-system \
   -o custom-columns=NAME:.metadata.name,CPU_LIMITS:.spec.template.spec.containers[*].resources.limits.cpu,MEMORY_LIMITS:.spec.template.spec.containers[*].resources.limits.memory \
   --kubeconfig ADMIN_KUBECONFIG

La risposta dovrebbe essere simile alla seguente:

NAME                     CPU_LIMITS   MEMORY_LIMITS
ang-controller-manager   <none>       400Mi
Installazione, upgrade, backup e ripristino 1.28.0, 1.28.100

I problemi di connettività dell'endpoint gcr.io di Container Registry possono bloccare le operazioni del cluster

Più operazioni per i cluster di amministrazione creano un cluster di bootstrap. Prima di creare un cluster di bootstrap, bmctl esegue un controllo della connettività Google Cloud dalla workstation di amministrazione. Questo controllo potrebbe non riuscire a causa di problemi di connettività con l'endpoint di Container Registry, gcr.io e potresti visualizzare un messaggio di errore come il seguente:

        system checks failed for bootstrap machine: GCP reachability check failed: failed to reach url https://gcr.io: Get "https://cloud.google.com/artifact-registry/": net/http: request canceled (Client.Timeout exceeded while awaiting headers)
        

Soluzione alternativa

Per risolvere il problema, riprova a eseguire l'operazione con il flag --ignore-validation-errors.

Networking 1,15, 1,16

GKE Dataplane V2 non è compatibile con alcuni driver di archiviazione

I cluster Distributed Cloud utilizzano GKE Dataplane V2, che non è compatibile con alcuni provider di archiviazione. Potresti riscontrare problemi con volumi o pod NFS bloccati. Ciò è particolarmente probabile se hai carichi di lavoro che utilizzano volumi ReadWriteMany supportati da driver di archiviazione soggetti a questo problema:

  • Robin.io
  • Portworx (sharedv4 volumi di servizio)
  • csi-nfs

L'elenco non è esaustivo.

Soluzione alternativa

È disponibile una correzione per questo problema per le seguenti versioni di Ubuntu:

  • 20.04 LTS: usa un'immagine del kernel 5.4.0 successiva a linux-image-5.4.0-166-generic
  • 22.04 LTS: usa un'immagine del kernel 5.15.0 successiva a linux-image-5.15.0-88-generic o il kernel HWE 6.5.

Se non utilizzi una di queste versioni, contatta l'Assistenza Google.

Logging e monitoraggio 1,15, 1,16, 1,28

kube-state-metrics OOM in un cluster di grandi dimensioni

Potresti notare che kube-state-metrics o il pod gke-metrics-agent esistente sullo stesso nodo di kube-state-metrics ha esaurito la memoria (OOM).

Questo può accadere in cluster con più di 50 nodi o con molti oggetti Kubernetes.

Soluzione alternativa

Per risolvere il problema, aggiorna la definizione della risorsa personalizzata stackdriver per utilizzare la porta di funzionalità ksmNodePodMetricsOnly. Questa limitazione delle funzionalità garantisce l'esposizione solo di un numero limitato di metriche critiche.

Per utilizzare questa soluzione alternativa, completa i seguenti passaggi:

  1. Controlla la definizione di risorsa personalizzata stackdriver per le porte di funzionalità disponibili:
    kubectl -n kube-system get crd stackdrivers.addons.gke.io -o yaml | grep ksmNodePodMetricsOnly
            
  2. Aggiorna la definizione di risorsa personalizzata stackdriver per abilitare ksmNodePodMetricsOnly:
    kind:stackdriver
    spec:
      featureGates:
         ksmNodePodMetricsOnly: true
            
Installazione 1.28.0-1.28.200

Il controllo preflight non riesce su RHEL 9.2 a causa di iptables mancanti

Durante l'installazione di un cluster sul sistema operativo Red Hat Enterprise Linux (RHEL) 9.2, potrebbe verificarsi un errore a causa del pacchetto iptables mancante. L'errore si verifica durante i controlli preflight e attiva un messaggio di errore simile al seguente:

'check_package_availability_pass': "The following packages are not available: ['iptables']"
        

RHEL 9.2 è in Anteprima per Google Distributed Cloud versione 1.28.

Soluzione alternativa

Bypassa l'errore del controllo preflight impostando spec.bypassPreflightCheck su true sulla risorsa cluster.

Operazione 1,10, 1,11, 1,12, 1,13, 1,14, 1,15 e 1,16

Failover MetalLB lento su larga scala

Quando MetalLB gestisce un numero elevato di servizi (oltre 10.000), il failover può richiedere oltre un'ora. Questo accade perché MetalLB utilizza una coda di frequenza limitata che, se è scalata su larga scala, può impiegare un po' di tempo per raggiungere il servizio che deve eseguire il failover.

Soluzione alternativa

Esegui l'upgrade del cluster alla versione 1.28 o successiva. Se non puoi eseguire l'upgrade, la modifica manuale del servizio (ad esempio, l'aggiunta di un'annotazione) comporta un failover più rapido del servizio.

Operazione 1.16.0-1.16.6, 1.28.0-1.28.200

Se il proxy è abilitato, le variabili di ambiente devono essere impostate sulla workstation di amministrazione

bmctl check cluster può generare un errore a causa di errori del proxy se non hai definito le variabili di ambiente HTTPS_PROXY e NO_PROXY nella workstation di amministrazione. Il comando bmctl segnala un messaggio di errore relativo alla mancata chiamata di alcuni servizi Google, come nell'esempio seguente:

[2024-01-29 23:49:03+0000] error validating cluster config: 2 errors occurred:
        * GKERegister check failed: 2 errors occurred:
        * Get "https://gkehub.googleapis.com/v1beta1/projects/baremetal-runqi/locations/global/memberships/ci-ec1a14a903eb1fc": oauth2: cannot fetch token: Post "https://oauth2.googleapis.com/token": dial tcp 108.177.98.95:443: i/o timeout
        * Post "https://cloudresourcemanager.googleapis.com/v1/projects/baremetal-runqi:testIamPermissions?alt=json&prettyPrint=false": oauth2: cannot fetch token: Post "https://oauth2.googleapis.com/token": dial tcp 74.125.199.95:443: i/o timeout

Soluzione alternativa

Imposta manualmente HTTPS_PROXY e NO_PROXY sulla workstation di amministrazione.

Upgrade e aggiornamenti 1.28.0-gke.435

Gli upgrade alla versione 1.28.0-gke.435 potrebbero non riuscire se audit.log ha una proprietà errata

In alcuni casi, per il file /var/log/apiserver/audit.log nei nodi del piano di controllo la proprietà dei gruppi e degli utenti è impostata su root. Questa impostazione di proprietà dei file causa errori di upgrade per i nodi del piano di controllo durante l'upgrade di un cluster dalla versione 1.16.x alla versione 1.28.0-gke.435. Questo problema si applica solo ai cluster creati prima della versione 1.11 e in cui Cloud Audit Logs è disabilitato. Cloud Audit Logs è abilitato per impostazione predefinita per i cluster con versione 1.9 e successive.

Soluzione alternativa

Se non riesci a eseguire l'upgrade del cluster alla versione 1.28.100-gke.146, segui questi passaggi come soluzione alternativa per completare l'upgrade del cluster alla versione 1.28.0-gke.435:

  • Se Cloud Audit Logs è abilitato, rimuovi il file /var/log/apiserver/audit.log.
  • Se Cloud Audit Logs è disabilitato, modifica la proprietà di /var/log/apiserver/audit.log in modo che corrisponda alla directory principale, /var/log/apiserver.
Networking, upgrade e aggiornamenti 1.28.0-gke.435

MetalLB non assegna indirizzi IP ai servizi VIP

Google Distributed Cloud utilizza MetalLB per il bilanciamento del carico in bundle. Nella release 1.28.0-gke.435 di Google Distributed Cloud, viene eseguito l'upgrade del bundle MetalLB alla versione 0.13, che introduce il supporto CRD per IPAddressPools. Tuttavia, poiché ConfigMaps consente qualsiasi nome per un IPAddressPool, i nomi dei pool dovevano essere convertiti in un nome conforme a Kubernetes aggiungendo un hash alla fine del nome del IPAddressPool. Ad esempio, un elemento IPAddressPool con nome default viene convertito in un nome come default-qpvpd quando esegui l'upgrade del cluster alla versione 1.28.0-gke.435.

Poiché MetalLB richiede un nome specifico di un IPPool per la selezione, la conversione del nome impedisce a MetalLB di effettuare una selezione del pool e assegnare indirizzi IP. Di conseguenza, i servizi che utilizzano metallb.universe.tf/address-pool come annotazione per selezionare il pool di indirizzi per un indirizzo IP non ricevono più un indirizzo IP dal controller MetalLB.

Questo problema è stato risolto in Google Distributed Cloud versione 1.28.100-gke.146.

Soluzione alternativa

Se non riesci a eseguire l'upgrade del cluster alla versione 1.28.100-gke.146, attieniti alla seguente procedura:

  1. Ottieni il nome convertito di IPAddressPool:
    kubectl get IPAddressPools -n kube-system
    
  2. Aggiorna il servizio interessato per impostare l'annotazione metallb.universe.tf/address-pool sul nome convertito con l'hash.

    Ad esempio, se il nome IPAddressPool è stato convertito da default a un nome come default-qpvpd, modifica l'annotazione metallb.universe.tf/address-pool: default nel servizio in metallb.universe.tf/address-pool: default-qpvpd.

L'hash utilizzato nella conversione del nome è deterministico, quindi la soluzione alternativa è permanente.

Upgrade e aggiornamenti 1,14; 1,15; 1,16; 1,28; 1,29

Pod orfani dopo l'upgrade alla versione 1.14.x

Quando esegui l'upgrade dei cluster Google Distributed Cloud alla versione 1.14.x, alcune risorse della versione precedente non vengono eliminate. In particolare, potresti vedere un insieme di pod orfani come il seguente:

capi-webhook-system/capi-controller-manager-xxx
capi-webhook-system/capi-kubeadm-bootstrap-controller-manager-xxx

Questi oggetti orfani non influiscono direttamente sul funzionamento del cluster, ma come best practice, ti consigliamo di rimuoverli.

  • Esegui questi comandi per rimuovere gli oggetti orfani:
    kubectl delete ns capi-webhook-system
    kubectl delete validatingwebhookconfigurations capi-validating-webhook-configuration
    kubectl delete mutatingwebhookconfigurations capi-mutating-webhook-configuration
    

Questo problema è stato risolto in Google Distributed Cloud versione 1.15.0 e successive.

Installazione 1,14

Creazione del cluster bloccata sul job machine-init

Se provi a installare Google Distributed Cloud versione 1.14.x, potresti riscontrare un errore a causa dei job machine-init, simile all'output di esempio che segue:

"kubeadm join" task failed due to:
error execution phase control-plane-join/etcd: error creating local etcd static pod manifest file: etcdserver: re-configuration failed due to not enough started members

"kubeadm reset" task failed due to:
panic: runtime error: invalid memory address or nil pointer dereference

Soluzione:

Rimuovi il membro etcd obsoleto che causa l'errore del job machine-init. Completa i seguenti passaggi su un nodo del piano di controllo funzionante:

  1. Elenca i membri etcd esistenti:
    etcdctl --key=/etc/kubernetes/pki/etcd/peer.key \
      --cacert=/etc/kubernetes/pki/etcd/ca.crt \
      --cert=/etc/kubernetes/pki/etcd/peer.crt \
      member list
    
    Cerca i membri con lo stato unstarted, come mostrato nell'output di esempio che segue:
    5feb7ac839625038, started, vm-72fed95a, https://203.0.113.11:2380, https://203.0.113.11:2379, false
    99f09f145a74cb15, started, vm-8a5bc966, https://203.0.113.12:2380, https://203.0.113.12:2379, false
    bd1949bcb70e2cb5, unstarted, , https://203.0.113.10:2380, , false
    
  2. Rimuovi il membro etcd con errori:
    etcdctl --key=/etc/kubernetes/pki/etcd/peer.key \
      --cacert=/etc/kubernetes/pki/etcd/ca.crt \
      --cert=/etc/kubernetes/pki/etcd/peer.crt \
      member remove MEMBER_ID
    
    Sostituisci MEMBER_ID con l'ID del membro etcd con errori. Nell'output di esempio precedente, questo ID è bd1949bcb70e2cb5.

    Il seguente output di esempio mostra che il membro è stato rimosso:
    Member bd1949bcb70e2cb5 removed from cluster  9d70e2a69debf2f
    
Networking 1.28.0

In Cilium-operator mancano le autorizzazioni di nodo list e watch

In Cilium 1.13, le autorizzazioni ClusterRole cilium-operator non sono corrette. Autorizzazioni Nodo list e watch mancanti. cilium-operator non riesce ad avviare i garbage collection, causando i seguenti problemi:

  • Perdita di risorse Cilium.
  • Le identità inattive non vengono rimosse dalle mappe dei criteri di BP.
  • Le mappe di criteri potrebbero raggiungere il limite di 16.000.
    • Impossibile aggiungere nuove voci.
    • Applicazione NetworkPolicy non corretta.
  • Le identità potrebbero raggiungere il limite di 64.000.
    • Non è possibile creare nuovi pod.

Un operatore privo delle autorizzazioni per i nodi segnala il seguente messaggio di log di esempio:

2024-01-02T20:41:37.742276761Z level=error msg=k8sError error="github.com/cilium/cilium/operator/watchers/node.go:83: Failed to watch *v1.Node: failed to list *v1.Node: nodes is forbidden: User \"system:serviceaccount:kube-system:cilium-operator\" cannot list resource \"nodes\" in API group \"\" at the cluster scope" subsys=k8s

L'agente Cilium segnala un messaggio di errore quando non riesce a inserire una voce in una mappa dei criteri, come nell'esempio seguente:

level=error msg="Failed to add PolicyMap key" bpfMapKey="{6572100 0 0 0}" containerID= datapathPolicyRevision=0 desiredPolicyRevision=7 endpointID=1313 error="Unable to update element for Cilium_policy_01313 map with file descriptor 190: the map is full, please consider resizing it. argument list too long" identity=128 ipv4= ipv6= k8sPodName=/ port=0 subsys=endpoint

Soluzione:

Rimuovi le identità Cilium, quindi aggiungi le autorizzazioni ClusterRole mancanti all'operatore:

  1. Rimuovi gli oggetti CiliumIdentity esistenti:
    kubectl delete ciliumid –-all
    
  2. Modifica l'oggetto ClusterRole cilium-operator:
    kubectl edit clusterrole cilium-operator
    
  3. Aggiungi una sezione per nodes che includa le autorizzazioni mancanti, come mostrato nell'esempio seguente:
    - apiGroups:
      - ""
      resources:
      - nodes
      verbs:
      - get
      - list
      - watch
    
  4. Salva e chiudi l'editor. L'operatore rileva in modo dinamico la modifica delle autorizzazioni. Non è necessario riavviare manualmente l'operatore.
Upgrade e aggiornamenti 1.15.0-1.15.7, 1.16.0-1.16.3

Problema temporaneo riscontrato durante il controllo preflight

Una delle attività di controllo di integrità kubeadm eseguita durante il controllo preflight dell'upgrade potrebbe non riuscire con il seguente messaggio di errore:

[ERROR CreateJob]: could not delete Job \"upgrade-health-check\" in the namespace \"kube-system\": jobs.batch \"upgrade-health-check\" not found

Questo errore può essere ignorato. Se si verifica questo errore che blocca l'upgrade, esegui nuovamente il comando di upgrade.

Se noti questo errore quando esegui il preflight utilizzando il comando bmctl preflightcheck, non viene bloccato nulla da questo errore. Puoi eseguire di nuovo il controllo preflight per ottenere informazioni accurate preflight.


Soluzione:

Esegui di nuovo il comando di upgrade o, se riscontrato durante il giorno bmctl preflightcheck, esegui nuovamente il comando preflightcheck.

Operazione 1.14, 1.15.0-1.15.7, 1.16.0-1.16.3, 1.28.0

Il controllo di integrità della rete periodico non riesce quando un nodo viene sostituito o rimosso

Questo problema riguarda i cluster che eseguono controlli di integrità di rete periodici dopo che un nodo è stato sostituito o rimosso. Se il cluster viene sottoposto a controlli di integrità periodici, il controllo di integrità della rete periodico determina un errore in seguito alla sostituzione o alla rimozione di un nodo, perché il ConfigMap dell'inventario di rete non viene aggiornato una volta creato.


Soluzione:

La soluzione alternativa consigliata è eliminare il ConfigMap dell'inventario e il controllo di integrità periodico della rete. L'operatore del cluster li ricrea automaticamente con le informazioni più aggiornate.

Per i cluster 1.14.x, esegui questi comandi:

kubectl delete configmap \
    $(kubectl get cronjob CLUSTER_NAME-network -o=jsonpath='{.spec.jobTemplate.spec.template.spec.volumes[?(@name=="inventory-config-volume")].configMap.name}' \
    -n CLUSTER_NAMESPACE) \
    -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG
kubectl delete healthchecks.baremetal.cluster.gke.io \
    CLUSTER_NAME-network -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

Per i cluster 1.15.0 e versioni successive, esegui questi comandi:

kubectl delete configmap \
    $(kubectl get cronjob bm-system-network -o=jsonpath='{.spec.jobTemplate.spec.template.spec.volumes[?(@.name=="inventory-config-volume")]configMap.name}' \
    -n CLUSTER_NAMESPACE) \
    -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG
kubectl delete healthchecks.baremetal.cluster.gke.io \
    bm-system-network -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG
Networking 1,14, 1,15, 1.16.0-1.16.2

Il gateway di rete per GDC non può applicare la tua configurazione se il nome del dispositivo contiene un punto

Se hai un dispositivo di rete che include un punto (.) nel nome, ad esempio bond0.2, Network Gateway per GDC considera il punto come un percorso nella directory quando esegue sysctl per apportare modifiche. Quando Network Gateway for GDC verifica se è abilitato il rilevamento di indirizzi duplicati (DAD), il controllo potrebbe non riuscire e pertanto non verrà riconciliato.

Il comportamento è diverso tra le versioni del cluster:

  • 1.14 e 1.15: questo errore esiste solo quando utilizzi indirizzi IP mobili IPv6. Se non utilizzi indirizzi IP mobili IPv6, non noterai questo problema se i nomi dei tuoi dispositivi contengono un punto.
  • 1.16.0 - 1.16.2: questo errore esiste sempre quando i nomi dei dispositivi contengono un punto.

Soluzione:

Esegui l'upgrade del cluster alla versione 1.16.3 o successiva.

Come soluzione alternativa fino a quando non puoi eseguire l'upgrade dei cluster, rimuovi il punto (.) dal nome del dispositivo.

Upgrade e aggiornamenti, Networking, Sicurezza 1.16.0

Gli upgrade alla versione 1.16.0 non riescono quando seccomp è disabilitato

Se seccomp è disabilitato per il tuo cluster (spec.clusterSecurity.enableSeccomp impostato su false), gli upgrade alla versione 1.16.0 non andranno a buon fine.

Google Distributed Cloud versione 1.16 utilizza Kubernetes versione 1.27. In Kubernetes 1.27.0 e versioni successive, la funzionalità per impostare i profili seccomp è GA e non utilizza più una limitazione di funzionalità. Questa modifica a Kubernetes causa l'esito negativo degli upgrade alla versione 1.16.0 quando seccomp è disabilitato nella configurazione del cluster. Questo problema è stato risolto nella versione 1.16.1 e nei cluster successivi. Se il campo cluster.spec.clusterSecurity.enableSeccomp è impostato su false, puoi eseguire l'upgrade alla versione 1.16.1 o successive.

I cluster con spec.clusterSecurity.enableSeccomp non configurato o impostato su true non sono interessati.

Installazione, funzionamento 1.11, 1.12, 1.13, 1.14, 1.15.0-1.15.5, 1.16.0-1.16.1

I metadati containerd potrebbero danneggiarsi dopo il riavvio quando viene montato /var/lib/containerd

Se hai montato facoltativamente /var/lib/containerd, i metadati containerd potrebbero danneggiarsi dopo un riavvio. I metadati danneggiati potrebbero causare un errore dei pod, compresi quelli critici per il sistema.

Per verificare se questo problema ti riguarda, verifica se in /etc/fstab è definito un montaggio facoltativo per /var/lib/containerd/ e se è presente nofail nelle opzioni di montaggio.


Soluzione:

Rimuovi l'opzione di montaggio nofail in /etc/fstab o esegui l'upgrade del cluster alla versione 1.15.6 o successiva.

Operazione 1,13; 1,14; 1,15; 1,16; 1,28

Esegui la pulizia dei pod inattivi nel cluster

Potresti vedere i pod gestiti da un deployment (ReplicaSet) in stato Failed e con lo stato TaintToleration. Questi pod non utilizzano risorse cluster, ma devono essere eliminati.

Puoi utilizzare questo comando kubectl per elencare i pod di cui è possibile eseguire la pulizia:

kubectl get pods –A | grep TaintToleration

L'output di esempio seguente mostra un pod con lo stato TaintToleration:

kube-system    stackdriver-metadata-agent-[...]    0/1    TaintToleration    0

Soluzione:

Per ogni pod con i sintomi descritti, controlla il ReplicaSet a cui appartiene il pod. Se il ReplicaSet è soddisfatto, puoi eliminare i pod:

  1. Ottieni il ReplicaSet che gestisce il pod e trova il valore ownerRef.Kind:
    kubectl get pod POD_NAME -n NAMESPACE -o yaml
    
  2. Scarica il ReplicaSet e verifica che status.replicas sia uguale a spec.replicas:
    kubectl get replicaset REPLICA_NAME -n NAMESPACE -o yaml
    
  3. Se i nomi corrispondono, elimina il pod:
    kubectl delete pod POD_NAME -n NAMESPACE.
    
Upgrade 1.16.0

Gli eventi etcd possono bloccarsi quando viene eseguito l'upgrade alla versione 1.16.0

Quando esegui l'upgrade di un cluster esistente alla versione 1.16.0, gli errori dei pod relativi a etcd-events possono bloccare l'operazione. In particolare, il job del nodo di upgrade non va a buon fine per il passaggio TASK [etcd_events_install : Run etcdevents].

Se si verifica questo problema, vengono visualizzati errori dei pod come i seguenti:

  • Il pod kube-apiserver non si avvia con il seguente errore:
    connection error: desc = "transport: Error while dialing dial tcp 127.0.0.1:2382: connect: connection refused"
    
  • Il pod etcd-events non si avvia con il seguente errore:
    Error: error syncing endpoints with etcd: context deadline exceeded
    

Soluzione:

Se non riesci a eseguire l'upgrade del cluster a una versione con la correzione, utilizza la seguente soluzione alternativa temporanea per risolvere gli errori:

  1. Utilizza SSH per accedere al nodo del piano di controllo con gli errori segnalati.
  2. Modifica il file manifest etcd-events, /etc/kubernetes/manifests/etcd-events.yaml e rimuovi il flag initial-cluster-state=existing.
  3. Applica il manifest.
  4. L'upgrade dovrebbe continuare.
Networking 1.15.0-1.15.2

CoreDNS orderPolicy non riconosciuto

OrderPolicy non viene riconosciuto come parametro e non viene utilizzato. Google Distributed Cloud utilizza sempre Random.

Questo problema si verifica perché il modello CoreDNS non è stato aggiornato e, di conseguenza, orderPolicy viene ignorato.


Soluzione:

Aggiorna il modello CoreDNS e applica la correzione. Questa correzione persiste fino a un upgrade.

  1. Modifica il modello esistente:
    kubectl edit cm -n kube-system coredns-template
    
    Sostituisci i contenuti del modello con quanto segue:
    coredns-template: |-
      .:53 {
        errors
        health {
          lameduck 5s
        }
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
          pods insecure
          fallthrough in-addr.arpa ip6.arpa
        }
    {{- if .PrivateGoogleAccess }}
        import zones/private.Corefile
    {{- end }}
    {{- if .RestrictedGoogleAccess }}
        import zones/restricted.Corefile
    {{- end }}
        prometheus :9153
        forward . {{ .UpstreamNameservers }} {
          max_concurrent 1000
          {{- if ne .OrderPolicy "" }}
          policy {{ .OrderPolicy }}
          {{- end }}
        }
        cache 30
    {{- if .DefaultDomainQueryLogging }}
        log
    {{- end }}
        loop
        reload
        loadbalance
    }{{ range $i, $stubdomain := .StubDomains }}
    {{ $stubdomain.Domain }}:53 {
      errors
    {{- if $stubdomain.QueryLogging }}
      log
    {{- end }}
      cache 30
      forward . {{ $stubdomain.Nameservers }} {
        max_concurrent 1000
        {{- if ne $.OrderPolicy "" }}
        policy {{ $.OrderPolicy }}
        {{- end }}
      }
    }
    {{- end }}
    
Networking, operazione 1,10; 1,11; 1,12; 1,13; 1,14

Gateway di rete per i componenti GDC rimossi 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 ridotto:

$ 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 dei nodi. Poiché il gateway di rete per i pod GDC non ha PriorityClass, ha la stessa priorità predefinita degli altri carichi di lavoro. Quando i nodi sono vincolati alle risorse, i pod del gateway di rete potrebbero essere rimossi. Questo comportamento è particolarmente negativo per il DaemonSet ang-node, poiché i pod devono essere pianificati su un nodo specifico e non possono essere migrati.


Soluzione:

Esegui l'upgrade alla versione 1.15 o successiva.

Come soluzione a breve termine, puoi assegnare manualmente un PriorityClass al gateway di rete per i componenti GDC. Il controller Google Distributed Cloud sovrascrive queste modifiche manuali durante un processo di riconciliazione, ad esempio durante l'upgrade del cluster.

  • Assegna il valore PriorityClass system-cluster-critical ai deployment del controller del cluster ang-controller-manager e autoscaler.
  • Assegna il valore PriorityClass system-node-critical al nodo ang-daemon DaemonSet.
Installazione, upgrade e aggiornamenti 1.15.0, 1.15.1, 1.15.2

La creazione e gli upgrade del cluster non sono riusciti a causa della lunghezza del nome del cluster

La creazione dei cluster delle versioni 1.15.0, 1.15.1 o 1.15.2 o l'upgrade dei cluster alla versione 1.15.0, 1.15.1 o 1.15.2 non riesce quando il nome del cluster supera i 48 caratteri (versione 1.15.0) o i 45 caratteri (versione 1.15.1 o 2). Durante le operazioni di creazione e upgrade del cluster, Google Distributed Cloud crea una risorsa di controllo di integrità con un nome che incorpora il nome e la versione del cluster:

  • Per i cluster della versione 1.15.0, il nome della risorsa del controllo di integrità è CLUSTER_NAME-add-ons-CLUSTER_VER.
  • Per i cluster versione 1.15.1 o 1.15.2, il nome della risorsa del controllo di integrità è CLUSTER_NAME-kubernetes-CLUSTER_VER.

Per i nomi di cluster lunghi, il nome della risorsa per il controllo di integrità supera la limitazione di 63 caratteri di Kubernetes sulla lunghezza dei nomi delle etichette, il che impedisce la creazione della risorsa per il controllo di integrità. Senza un controllo di integrità riuscito, l'operazione del cluster non va a buon fine.

Per verificare se hai riscontrato questo problema, utilizza kubectl describe per controllare la risorsa con errore:

kubectl describe healthchecks.baremetal.cluster.gke.io \
    HEALTHCHECK_CR_NAME -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

Se questo problema ti riguarda, la risposta contiene un avviso relativo a un ReconcileError come il seguente:

...
Events:
  Type     Reason          Age                   From                    Message
  ----     ------          ----                  ----                    -------
  Warning  ReconcileError  77s (x15 over 2m39s)  healthcheck-controller  Reconcile error, retrying: 1 error occurred:
           * failed to create job for health check
db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1: Job.batch
"bm-system-db-uat-mfd7-fic-hybrid-cloud-u24d5f180362cffa4a743" is invalid: [metadata.labels: Invalid
value: "db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1": must be no more than 63
characters, spec.template.labels: Invalid value:
"db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1": must be no more than 63 characters]

Soluzione alternativa

Per sbloccare l'upgrade o la creazione del cluster, puoi ignorare il controllo di integrità. Utilizza il seguente comando per applicare una patch alla risorsa personalizzata per il controllo di integrità con stato superato: (status: {pass: true})

kubectl patch healthchecks.baremetal.cluster.gke.io \
    HEALTHCHECK_CR_NAME -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG --type=merge \
    --subresource status --patch 'status: {pass: true}'
Upgrade e aggiornamenti 1,14, 1,15

Non è possibile eseguire l'upgrade ai cluster delle versioni 1.14.0 e 1.14.1 con funzionalità di anteprima alla versione 1.15.x

Se nei cluster delle versioni 1.14.0 e 1.14.1 è abilitata una funzionalità di anteprima, l'upgrade alla versione 1.15.x viene bloccato. Questo si applica alle funzionalità di anteprima come la possibilità di creare un cluster senza kube-proxy, che è abilitata con la seguente annotazione nel file di configurazione del cluster:

preview.baremetal.cluster.gke.io/kube-proxy-free: "enable"

Se si verifica questo problema, durante l'upgrade del cluster viene visualizzato un errore simile al seguente:

[2023-06-20 23:37:47+0000] error judging if the cluster is managing itself:
error to parse the target cluster: error parsing cluster config: 1 error
occurred:

Cluster.baremetal.cluster.gke.io "$cluster-name" is invalid:
Annotations[preview.baremetal.cluster.gke.io/$preview-feature-name]:
Forbidden: preview.baremetal.cluster.gke.io/$preview-feature-name feature
isn't supported in 1.15.1 Anthos Bare Metal version

Questo problema è stato risolto nei cluster della versione 1.14.2 e successive.


Soluzione:

Se non riesci a eseguire l'upgrade dei cluster alla versione 1.14.2 o successiva prima di eseguire l'upgrade alla versione 1.15.x, puoi eseguire l'upgrade alla versione 1.15.x direttamente utilizzando un cluster di bootstrap:

bmctl upgrade cluster --use-bootstrap=true
Operazione 1,15

I cluster della versione 1.15 non accettano indirizzi IP mobili duplicati

Il gateway di rete per GDC non consente di creare nuove risorse personalizzate NetworkGatewayGroup contenenti indirizzi IP in spec.floatingIPs che sono già utilizzate nelle risorse personalizzate di NetworkGatewayGroup esistenti. Questa regola viene applicata da un webhook nei cluster Google Distributed Cloud versione 1.15.0 e successive. Gli indirizzi IP mobili duplicati preesistenti non causano errori. Il webhook impedisce solo la creazione di nuove risorse personalizzate NetworkGatewayGroups che contengono indirizzi IP duplicati.

Il messaggio di errore del webhook identifica l'indirizzo IP in conflitto e la risorsa personalizzata esistente che la sta già utilizzando:

IP address exists in other gateway with name default

La documentazione iniziale per le funzionalità di networking avanzate, ad esempio il gateway NAT in uscita, non prescrive la presenza di indirizzi IP duplicati. Inizialmente, il riconciliatore ha riconosciuto solo la risorsa NetworkGatewayGroup denominata default. Il gateway di rete per GDC ora riconosce tutte le risorse personalizzate NetworkGatewayGroup nello spazio dei nomi di sistema. Le risorse personalizzate NetworkGatewayGroup esistenti sono rispettate così come sono.


Soluzione:

Gli errori si verificano solo durante la creazione di una nuova risorsa personalizzata NetworkGatewayGroup.

Per risolvere l'errore:

  1. Utilizza il comando seguente per elencare NetworkGatewayGroups risorse personalizzate:
    kubectl get NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \
        -n kube-system -o yaml
    
  2. Apri le risorse personalizzate NetworkGatewayGroup esistenti e rimuovi gli indirizzi IP mobili in conflitto (spec.floatingIPs):
    kubectl edit NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \
        -n kube-system RESOURCE_NAME
    
  3. Per applicare le modifiche, chiudi e salva le risorse personalizzate modificate.
Runtime VM su GDC 1.13.7

Le VM potrebbero non avviarsi su cluster 1.13.7 che utilizzano un registro privato

Quando abiliti il runtime VM su GDC su un cluster della versione 1.13.7 nuovo o con upgrade eseguito che utilizza un registro privato, le VM che si connettono alla rete di nodi o che utilizzano una GPU potrebbero non avviarsi correttamente. Questo problema è dovuto al fatto che alcuni pod di sistema nello spazio dei nomi vm-system ricevono errori di pull delle immagini. Ad esempio, se la tua VM utilizza la rete di nodi, alcuni pod potrebbero segnalare errori di pull delle immagini come i seguenti:

macvtap-4x9zp              0/1   Init:ImagePullBackOff  0     70m

Questo problema è stato risolto nella versione 1.14.0 e nelle versioni successive dei cluster Google Distributed Cloud.

Soluzione alternativa

Se non puoi eseguire subito l'upgrade dei cluster, puoi eseguire il pull delle immagini manualmente. I seguenti comandi eseguono il pull dell'immagine del plug-in CNI di macvtap per la tua VM e ne eseguono il push nel registro privato:

docker pull \
    gcr.io/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21
docker tag \
    gcr.io/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21 \
    REG_HOST/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21
docker push \
    REG_HOST/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21

Sostituisci REG_HOST con il nome di dominio di un host di cui esegui il mirroring localmente.

Installazione 1,11, 1,12

Durante la creazione del cluster type, il pod gke-metric-agent non viene avviato

Durante la creazione del cluster nel cluster kind, il pod gke-metrics-agent non viene avviato a causa di un errore di pull dell'immagine come segue:

error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden"

Inoltre, nel log containerd del cluster di bootstrap, vedrai la seguente voce:

Sep 13 23:54:20 bmctl-control-plane containerd[198]: time="2022-09-13T23:54:20.378172743Z" level=info msg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" " Sep 13 23:54:21 bmctl-control-plane containerd[198]: time="2022-09-13T23:54:21.057247258Z" level=error msg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" failed" error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden"

Visualizzerai il seguente errore di tipo "Impossibile eseguire il pull" nel pod:

gcr.io/gke-on-prem-staging/gke-metrics-agent

Soluzione alternativa

Nonostante gli errori, il processo di creazione del cluster non viene bloccato perché lo scopo del pod gke-metrics-agent nel cluster in natura è facilitare la percentuale di successo della creazione del cluster nonché per il monitoraggio e il monitoraggio interni. Pertanto, puoi ignorare questo errore.

Soluzione alternativa

Nonostante gli errori, il processo di creazione del cluster non viene bloccato perché lo scopo del pod gke-metrics-agent nel cluster in natura è facilitare la percentuale di successo della creazione del cluster nonché per il monitoraggio e il monitoraggio interni. Pertanto, puoi ignorare questo errore.

Operazione, networking 1,12; 1,13; 1,14; 1,15; 1,16; 1,28

L'accesso a un endpoint di servizio IPv6 causa l'arresto anomalo del nodo LoadBalancer su CentOS o RHEL

Quando accedi a un servizio a doppio stack (un servizio che include endpoint IPv4 e IPv6) e utilizzi l'endpoint IPv6, il nodo LoadBalancer che gestisce il servizio potrebbe arrestarsi in modo anomalo. Questo problema riguarda i clienti che utilizzano servizi a doppio stack con CentOS o RHEL e una versione del kernel precedente a kernel-4.18.0-372.46.1.el8_6.

Se ritieni che questo problema ti riguardi, controlla la versione del kernel sul nodo LoadBalancer utilizzando il comando uname -a.


Soluzione:

Aggiorna il nodo LoadBalancer alla versione del kernel kernel-4.18.0-372.46.1.el8_6 o successiva. Questa versione del kernel è disponibile per impostazione predefinita in CentOS e RHEL 8.6 e versioni successive.

Networking 1,11, 1,12, 1,13 e 1.14.0

Problemi di connettività intermittenti dopo il riavvio del nodo

Dopo aver riavviato un nodo, potresti riscontrare problemi di connettività intermittenti per un servizio NodePort o LoadBalancer. Ad esempio, potresti riscontrare errori di handshake TLS intermittente o di reimpostazione della connessione. Questo problema è stato risolto per i cluster con versione 1.14.1 e successive.

Per verificare se questo problema ti riguarda, consulta le iptables regole di forwarding sui nodi in cui è in esecuzione il pod di backend per il servizio interessato:

sudo iptables -L FORWARD

Se vedi la regola KUBE-FORWARD prima della regola CILIUM_FORWARD in iptables, potresti essere interessato da questo problema. L'output di esempio seguente mostra un nodo in cui esiste il problema:

Chain FORWARD (policy ACCEPT)
target                  prot opt source   destination
KUBE-FORWARD            all  --  anywhere anywhere                /* kubernetes forwarding rules */
KUBE-SERVICES           all  --  anywhere anywhere    ctstate NEW /* kubernetes service portals */
KUBE-EXTERNAL-SERVICES  all  --  anywhere anywhere    ctstate NEW /* kubernetes externally-visible service portals */
CILIUM_FORWARD          all  --  anywhere anywhere                /* cilium-feeder: CILIUM_FORWARD */

Soluzione:

Riavvia il pod anetd sul nodo non configurato correttamente. Dopo aver riavviato il pod anetd, la regola di forwarding in iptables dovrebbe essere configurata correttamente.

L'output di esempio seguente mostra che ora la regola CILIUM_FORWARD è configurata correttamente prima della regola KUBE-FORWARD:

Chain FORWARD (policy ACCEPT)
target                  prot opt source   destination
CILIUM_FORWARD          all  --  anywhere anywhere                /* cilium-feeder: CILIUM_FORWARD */
KUBE-FORWARD            all  --  anywhere anywhere                /* kubernetes forwarding rules */
KUBE-SERVICES           all  --  anywhere anywhere    ctstate NEW /* kubernetes service portals */
KUBE-EXTERNAL-SERVICES  all  --  anywhere anywhere    ctstate NEW /* kubernetes externally-visible service portals */
Upgrade e aggiornamenti 1,9, 1,10

La funzionalità di anteprima non conserva le informazioni originali sul proprietario e sull'autorizzazione

La funzionalità di anteprima del cluster 1.9.x che utilizza bmctl 1.9.x non conserva le informazioni originali sul proprietario e sull'autorizzazione. Per verificare se questa funzionalità ti riguarda, estrai il file di cui hai eseguito il backup utilizzando questo comando:

tar -xzvf BACKUP_FILE

Soluzione alternativa

Verifica che sia presente metadata.json e che bmctlVersion sia 1.9.x. Se metadata.json non è presente, esegui l'upgrade al cluster 1.10.x e utilizza bmctl 1.10.x per il backup/ripristino.

Upgrade e creazioni 1.14.2

clientconfig-operator bloccato in stato di attesa con CreateContainerConfigError

Se hai eseguito l'upgrade o creato un cluster alla versione 1.14.2 con una configurazione OIDC/LDAP, potresti vedere il pod clientconfig-operator bloccato in stato di attesa. Con questo problema, sono presenti due pod clientconfig-operator, uno in esecuzione e l'altro in stato In attesa.

Questo problema si applica solo ai cluster della versione 1.14.2. Le versioni precedenti del cluster, come 1.14.0 e 1.14.1, non sono interessate. Questo problema è stato risolto nella versione 1.14.3 e in tutte le release successive, tra cui 1.15.0 e successive.


Soluzione:

Come soluzione alternativa, puoi applicare patch al deployment clientconfig-operator per aggiungere ulteriore contesto di sicurezza e assicurarti che il deployment sia pronto.

Utilizza il seguente comando per applicare la patch a clientconfig-operator nel cluster di destinazione:

kubectl patch deployment clientconfig-operator -n kube-system \
    -p '{"spec":{"template":{"spec":{"containers": [{"name":"oidcproxy","securityContext":{"runAsGroup":2038,"runAsUser":2038}}]}}}}' \
    --kubeconfig CLUSTER_KUBECONFIG

Sostituisci quanto segue:

  • CLUSTER_KUBECONFIG: il percorso del file kubeconfig per il cluster di destinazione.
Operazione 1,11; 1,12; 1,13; 1,14; 1,15

La rotazione dell'autorità di certificazione non riesce per i cluster senza bilanciamento del carico in bundle

Per i cluster senza bilanciamento del carico in bundle (spec.loadBalancer.mode impostato su manual), il comando bmctl update credentials certificate-authorities rotate potrebbe non rispondere e non riuscire più con il seguente errore: x509: certificate signed by unknown authority.

Se hai riscontrato questo problema, il comando bmctl potrebbe restituire il seguente messaggio prima di non rispondere:

Signing CA completed in 3/0 control-plane nodes

In questo caso, alla fine il comando ha esito negativo. La rotazione del log dell'autorità di certificazione per un cluster con tre piani di controllo può includere voci come le seguenti:

[2023-06-14 22:33:17+0000] waiting for all nodes to trust CA bundle OK
[2023-06-14 22:41:27+0000] waiting for first round of pod restart to complete OK
Signing CA completed in 0/0 control-plane nodes
Signing CA completed in 1/0 control-plane nodes
Signing CA completed in 2/0 control-plane nodes
Signing CA completed in 3/0 control-plane nodes
...
Unable to connect to the server: x509: certificate signed by unknown
authority (possibly because of "crypto/rsa: verification error" while
trying to verify candidate authority certificate "kubernetes")

Soluzione alternativa

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

Installazione, networking 1,11, 1,12, 1,13, 1.14.0-1.14.1

ipam-controller-manager di arresti anomali in cluster a doppio stack

Quando esegui il deployment di un cluster a doppio stack (un cluster con indirizzi sia IPv4 che IPv6), i pod di ipam-controller-manager potrebbero arrestarsi in modo anomalo. Questo comportamento causa il ciclo dei nodi tra gli stati Ready e NotReady e l'installazione del cluster potrebbe non riuscire. Questo problema può verificarsi quando il server API è sottoposto a un carico elevato.

Per capire se questo problema ti riguarda, controlla se i pod di ipam-controller-manager non funzionano con errori CrashLoopBackOff:

kubectl -n kube-system get pods | grep  ipam-controller-manager

L'output di esempio seguente mostra i pod in stato CrashLoopBackOff:

ipam-controller-manager-h7xb8   0/1  CrashLoopBackOff   3 (19s ago)   2m ipam-controller-manager-vzrrf   0/1  CrashLoopBackOff   3 (19s ago)   2m1s
ipam-controller-manager-z8bdw   0/1  CrashLoopBackOff   3 (31s ago)   2m2s

Visualizza i dettagli del nodo in stato NotReady:

kubectl describe node <node-name> | grep PodCIDRs

In un cluster con questo problema, a un nodo non sono assegnati PodCIDR, come mostrato nell'output di esempio seguente:

PodCIDRs:

In un cluster integro, a tutti i nodi devono essere assegnati PodCIDR a doppio stack, come mostrato nell'output di esempio seguente:

PodCIDRs:    192.168.6.0/24,222:333:444:555:5:4:7:0/120

Soluzione:

Riavvia ipam-controller-manager pod:

kubectl -n kube-system rollout restart ds ipam-controller-manager
Operazione 1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13 e 1.14

fame smartwatch etcd

I cluster che eseguono etcd versione 3.4.13 o precedenti potrebbero riscontrare l'indisponibilità degli smartwatch e smartwatch di risorse non operative, il che può causare i seguenti problemi:

  • La pianificazione dei pod è interrotta
  • Impossibile registrare i nodi
  • kubelet non osserva le modifiche ai pod

Questi problemi possono rendere il cluster non funzionante.

Questo problema è stato risolto in Google Distributed Cloud versione 1.12.9, 1.13.6, 1.14.3 e versioni successive. Queste release più recenti utilizzano la versione etcd 3.4.21. Tutte le versioni precedenti di Google Distributed Cloud sono interessate da questo problema.

Soluzione alternativa

Se non puoi eseguire l'upgrade immediatamente, puoi mitigare il rischio di errore del cluster riducendo il numero di nodi nel cluster. Rimuovi i nodi fino a quando la metrica etcd_network_client_grpc_sent_bytes_total è inferiore a 300 Mbps.

Per visualizzare questa metrica in Metrics Explorer:

  1. Vai a Metrics Explorer nella console Google Cloud:

    Vai a Esplora metriche

  2. Seleziona la scheda Configurazione.
  3. Espandi 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 metriche attive, seleziona Anthos.
    3. Nel menu Metriche attive, seleziona etcd_network_client_grpc_sent_bytes_total.
    4. Fai clic su Applica.
Networking 1.11.6, 1.12.3

Stato "Non riuscito " della modalità vfio-pci dell'operatore SR-IOV

L'elemento syncStatus dell'oggetto SriovNetworkNodeState può segnalare il valore "Non riuscito" per un nodo configurato. Per visualizzare lo stato di un nodo e determinare se il problema ti riguarda, esegui questo comando:

kubectl -n gke-operators get \
    sriovnetworknodestates.sriovnetwork.k8s.cni.cncf.io NODE_NAME \
    -o jsonpath='{.status.syncStatus}'

Sostituisci NODE_NAME con il nome del nodo da verificare.


Soluzione:

Se lo stato dell'oggetto SriovNetworkNodeState è "Non riuscito", esegui l'upgrade del cluster alla versione 1.11.7 o successiva oppure alla versione 1.12.4 o successiva.

Upgrade e aggiornamenti 1.10, 1.11, 1.12, 1.13, 1.14.0 e 1.14.1

Alcuni nodi worker non sono in stato Pronto dopo l'upgrade

Al termine dell'upgrade, la condizione Pronto per alcuni nodi worker potrebbe essere impostata su false. Nella risorsa Node, verrà visualizzato un errore accanto alla condizione Pronto, simile all'esempio seguente:

container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized

Quando accedi alla macchina bloccata, la configurazione CNI sulla macchina è vuota:

sudo ls /etc/cni/net.d/

Soluzione alternativa

Riavvia il pod anetd del nodo eliminandolo.

Upgrade e aggiornamenti, Sicurezza 1,1

La rotazione di più certificati da Gestore certificati causa incoerenze

Dopo più rotazioni manuali o automatiche dei certificati, il pod webhook, come anthos-cluster-operator, non viene aggiornato con i nuovi certificati emessi da cert-manager. Qualsiasi aggiornamento alla risorsa personalizzata del cluster non riesce e genera un errore simile al seguente:

Internal error occurred: failed calling
webhook "vcluster.kb.io": failed to call webhook: Post "https://webhook-service.kube-system.svc:443/validate-baremetal-cluster-gke-io-v1-cluster?timeout=10s": x509: certificate signed by unknown authority (possibly because of "x509:
invalid signature: parent certificate cannot sign this kind of certificate"
while trying to verify candidate authority certificate
"webhook-service.kube-system.svc")

Questo problema può verificarsi nelle seguenti circostanze:

  • Se hai eseguito due rotazioni manuali dei certificati emessi da gestore certificati su un cluster più vecchio di 180 giorni e non hai mai riavviato anthos-cluster-operator.
  • Se hai eseguito manualmente la rotazione di certificati emesso da cert-manager su un cluster più vecchio di 90 giorni o più e non hai mai riavviato anthos-cluster-operator.

Soluzione alternativa

Riavvia il pod terminando anthos-cluster-operator.

Upgrade e aggiornamenti 1.14.0

Pod del deploymenter del controller del ciclo di vita obsoleti creati durante l'upgrade del cluster utente

Nei cluster di amministrazione della versione 1.14.0, durante gli upgrade del cluster utente potrebbero essere creati uno o più pod del deploymenter del controller del ciclo di vita obsoleti. Questo problema si applica ai cluster utente inizialmente creati con versioni precedenti alla 1.12. I pod creati involontariamente non ostacolano le operazioni di upgrade, ma potrebbero trovarsi in uno stato imprevisto. Ti consigliamo di rimuovere i pod obsoleti.

Questo problema è stato risolto nella versione 1.14.1.

Soluzione:

Per rimuovere i pod del deploymenter del controller del ciclo di vita obsoleti:

  1. Elenca le risorse per i controlli preflight:
    kubectl get preflightchecks --kubeconfig ADMIN_KUBECONFIG -A
    

    L'output avrà il seguente aspetto:

    NAMESPACE                    NAME                      PASS   AGE
    cluster-ci-87a021b9dcbb31c   ci-87a021b9dcbb31c        true   20d
    cluster-ci-87a021b9dcbb31c   ci-87a021b9dcbb31cd6jv6   false  20d
    

    dove ci-87a021b9dcbb31c è il nome del cluster.

  2. Elimina le risorse il cui valore nella colonna PASS è true o false.

    Ad esempio, per eliminare le risorse nell'output di esempio precedente, utilizza i seguenti comandi:

    kubectl delete preflightchecks ci-87a021b9dcbb31c \
        -n cluster-ci-87a021b9dcbb31c \
        --kubeconfig ADMIN_KUBECONFIG 
    kubectl delete preflightchecks ci-87a021b9dcbb31cd6jv6 \
        -n cluster-ci-87a021b9dcbb31c \
        --kubeconfig ADMIN_KUBECONFIG
    
Networking 1,9, 1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16 e 1,28

Lo stato di BGPSession cambia costantemente a causa dell'elevato numero di route in entrata

Il networking avanzato di Google Distributed Cloud non riesce a gestire correttamente le sessioni BGP quando i peer esterni pubblicizzano un elevato numero di route (circa 100 o più). Con un numero elevato di route in entrata, il controller BGP locale del nodo impiega troppo tempo per riconciliare le sessioni BGP e non riesce ad aggiornare lo stato. La mancanza di aggiornamenti dello stato o di un controllo di integrità determina l'eliminazione della sessione perché non aggiornata.

I comportamenti indesiderati nelle sessioni BGP che potresti notare e indicare un problema includono quanto segue:

  • Eliminazione e ricreazione continue di bgpsession.
  • bgpsession.status.state non diventa mai Established
  • Route che non vengono pubblicizzate o vengono ripetutamente pubblicizzate e ritirate.

I problemi di bilanciamento del carico di BGP potrebbero essere evidenti con problemi di connettività ai servizi LoadBalancer.

Il problema FlatIP di BGP potrebbe essere evidente con problemi di connettività ai pod.

Per determinare se i problemi di BGP sono causati da peer remoti che pubblicizzano troppe route, utilizza i comandi seguenti per esaminare gli stati e l'output associati:

  • Utilizza kubectl get bgpsessions sul cluster interessato. L'output mostra bgpsessions con lo stato "Non stabilito" e l'ultima durata del report viene conteggiata continuamente fino a circa 10-12 secondi prima che venga visualizzato zero.
  • L'output di kubectl get bgpsessions mostra che le sessioni interessate vengono ricreate ripetutamente:
    kubectl get bgpsessions \
        -o jsonpath="{.items[*]['metadata.name', 'metadata.creationTimestamp']}"
    
  • I messaggi di log indicano che è in corso l'eliminazione di sessioni BGP inattive:
    kubectl logs ang-controller-manager-POD_NUMBER
    

    Sostituisci POD_NUMBER con il pod leader nel cluster.


Soluzione:

Riduci o elimina il numero di route annunciate dal peer remoto al cluster con un criterio di esportazione.

Nel cluster Google Distributed Cloud versione 1.14.2 e successive, puoi anche disabilitare la funzionalità che elabora le route ricevute utilizzando un AddOnConfiguration. Aggiungi l'argomento --disable-received-routes al container bgpd del daemonset ang-daemon.

Networking 1,14; 1,15; 1,16; 1,28

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

I cluster in esecuzione su un sistema operativo Ubuntu che utilizza kernel 5.15 o versioni successive sono soggetti a errori di inserimento delle tabelle di tracciamento delle connessioni netfilter (conntrack). Gli errori di inserimento possono verificarsi anche quando la tabella di connessione ha spazio per nuove voci. Gli errori sono causati da modifiche nel kernel 5.15 e versioni successive che limitano gli inserimenti delle tabelle in base alla lunghezza della catena.

Per verificare se questo problema ti riguarda, puoi controllare le statistiche del sistema di monitoraggio delle connessioni nel kernel con il seguente comando:

sudo conntrack -S

La risposta ha questo 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 un valore chaintoolong nella risposta è un numero diverso da zero, hai riscontrato questo problema.

Soluzione alternativa

La mitigazione a breve termine è l'aumento delle dimensioni sia della tabella hash netfiler (nf_conntrack_buckets) sia della tabella di monitoraggio delle connessioni netfilter (nf_conntrack_max). Usa i seguenti comandi su ciascun nodo 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 la nuova dimensione in byte. Il valore predefinito per le dimensioni della tabella è 262144. Ti suggeriamo di impostare un valore uguale a 65.536 volte il numero di core sul nodo. Ad esempio, se il nodo ha otto core, imposta le dimensioni della tabella su 524288.

Upgrade e aggiornamenti 1.11.3, 1.11.4, 1.11.5, 1.11.6, 1.11.7, 1.11.8, 1.12.4, 1.12.5, 1.12.6, 1.12.7, 1.12.8, 1.13.4, 1.13.4

Impossibile ripristinare i backup del cluster con bmctl per alcune versioni

Ti consigliamo di eseguire il backup dei cluster prima di eseguire l'upgrade, in modo da poter ripristinare la versione precedente se l'upgrade non va a buon fine. Un problema con il comando bmctl restore cluster impedisce il ripristino dei backup dei cluster con le versioni identificate. Questo problema è specifico per gli upgrade, in cui ripristini un backup di una versione precedente.

Se il cluster è interessato, il log bmctl restore cluster contiene il seguente errore:

Error: failed to extract image paths from profile: anthos version VERSION not supported

Soluzione:

Finché il problema non verrà risolto, ti consigliamo di seguire le istruzioni in Eseguire il backup e il ripristino dei cluster per eseguire il backup manuale dei cluster e ripristinarli manualmente, se necessario.
Networking 1,10, 1,11, 1,12, 1,13, 1.14.0-1.14.2

NetworkGatewayGroup si arresta in modo anomalo se non è presente alcun indirizzo IP nell'interfaccia

NetworkGatewayGroup non riesce a creare daemon per i nodi che non hanno interfacce sia IPv4 che IPv6. Questo fa sì che funzionalità come BGP LB e OutboundNAT non vadano a buon fine. Se controlli i log del pod ang-node in errore nello spazio dei nomi kube-system, vengono visualizzati errori simili all'esempio seguente quando manca un indirizzo IPv6:

ANGd.Setup    Failed to create ANG daemon    {"nodeName": "bm-node-1", "error":
"creating NDP client failed: ndp: address \"linklocal\" not found on interface \"ens192\""}

Nell'esempio precedente, non è presente alcun indirizzo IPv6 nell'interfaccia ens192. Errori ARP simili vengono visualizzati se nel nodo manca un indirizzo IPv4.

NetworkGatewayGroup tenta di stabilire una connessione ARP e una connessione NDP all'indirizzo IP locale del link. Se l'indirizzo IP non esiste (IPv4 per ARP, IPv6 per NDP), la connessione non riesce e il daemon non continua.

Questo problema è stato risolto nella versione 1.14.3.


Soluzione:

Connettiti al nodo tramite SSH e aggiungi un indirizzo IPv4 o IPv6 al link che contiene l'IP del nodo. Nell'esempio di voce di log precedente, questa interfaccia era ens192:

ip address add dev INTERFACE scope link ADDRESS

Sostituisci quanto segue:

  • INTERFACE: l'interfaccia del nodo, ad esempio ens192.
  • ADDRESS: l'indirizzo IP e la subnet mask da applicare all'interfaccia.
Ripristino/eliminazione 1,10, 1,11, 1,12, 1.13.0-1.13.2

anthos-cluster-operator loop di arresto anomalo durante la rimozione di un nodo del piano di controllo

Quando provi a rimuovere un nodo del piano di controllo rimuovendo l'indirizzo IP da Cluster.Spec, anthos-cluster-operator entra in uno stato di loop di arresto anomalo che blocca qualsiasi altra operazione.


Soluzione:

Il problema è stato risolto nelle versioni 1.13.3 e 1.14.0 e successive. Sono interessate tutte le altre versioni. Esegui l'upgrade a una delle versioni corrette

Come soluzione alternativa, esegui questo comando:

kubectl label baremetalmachine IP_ADDRESS \
    -n CLUSTER_NAMESPACE baremetal.cluster.gke.io/upgrade-apply-

Sostituisci quanto segue:

  • IP_ADDRESS: l'indirizzo IP del nodo in stato di loop di arresto anomalo.
  • CLUSTER_NAMESPACE: lo spazio dei nomi del cluster.
Installazione 1.13.1, 1.13.2 e 1.13.3

Errore di kubeadm join in cluster di grandi dimensioni a causa della mancata corrispondenza dei token

Quando installi cluster Google Distributed Cloud con un numero elevato di nodi, potresti visualizzare un messaggio di errore kubeadmin join simile all'esempio seguente:

TASK [kubeadm : kubeadm join --config /dev/stdin --ignore-preflight-errors=all] ***
fatal: [10.200.0.138]: FAILED! => {"changed": true, "cmd": "kubeadm join
--config /dev/stdin --ignore-preflight-errors=all", "delta": "0:05:00.140669", "end": "2022-11-01 21:53:15.195648", "msg": "non-zero return code", "rc": 1,
"start": "2022-11-01 21:48:15.054979", "stderr": "W1101 21:48:15.082440   99570 initconfiguration.go:119]
Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future.
Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\". Please update your configuration!\nerror
execution phase preflight: couldn't validate the identity of the API Server: could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"\n
To see the stack trace of this error execute with --v=5 or higher", "stderr_lines":
["W1101 21:48:15.082440   99570 initconfiguration.go:119] Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future.
Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\".
Please update your configuration!", "error execution phase preflight: couldn't validate the identity of the API Server:
could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"",
"To see the stack trace of this error execute with --v=5 or higher"], "stdout": "[preflight]
Running pre-flight checks", "stdout_lines": ["[preflight] Running pre-flight checks"]}

Soluzione:

Il problema è stato risolto in Google Distributed Cloud versione 1.13.4 e successive.

Se devi utilizzare una versione interessata, crea prima un cluster con meno di 20 nodi, quindi ridimensiona il cluster in modo da aggiungerne altri al termine dell'installazione.

Logging e monitoraggio 1,10, 1,11, 1,12 e 1.13.0

Limite di CPU basso per metrics-server nei cluster Edge

Nei cluster Google Distributed Cloud Edge, bassi limiti di CPU per metrics-server possono causare frequenti riavvii di metrics-server. La scalabilità automatica orizzontale dei pod (HPA) non funziona perché metrics-server non è integro.

Se il limite di CPU metrics-server è inferiore a 40m, i cluster potrebbero essere interessati. Per controllare i metrics-server limiti di CPU, esamina uno dei seguenti file:

  • Cluster Google Distributed Cloud versione 1.x-1.12:
    kubectl get deployment metrics-server -n kube-system \
        -o yaml > metrics-server.yaml
    
  • Cluster Google Distributed Cloud versione 1.13 o successive:
    kubectl get deployment metrics-server -n gke-managed-metrics-server \
        -o yaml > metrics-server.yaml
    

Soluzione:

Questo problema è stato risolto nei cluster Google Distributed Cloud versione 1.13.1 o successive. Per risolvere il problema, esegui l'upgrade dei cluster.

Una soluzione alternativa a breve termine prima di poter eseguire l'upgrade dei cluster è aumentare manualmente i limiti di CPU per metrics-server, come descritto di seguito:

  1. Scale down di metrics-server-operator:
    kubectl scale deploy metrics-server-operator --replicas=0
  2. Aggiorna la configurazione e aumenta i limiti di CPU:
    • Cluster Google Distributed Cloud versione 1.x-1.12:
      kubectl -n kube-system edit deployment metrics-server
    • Cluster Google Distributed Cloud versione 1.13:
      kubectl -n gke-managed-metrics-server edit deployment metrics-server

    Rimuovi la riga --config-dir=/etc/config e aumenta i limiti di CPU, come mostrato nell'esempio seguente:

    [...]
    - command:
    - /pod_nanny
    # - --config-dir=/etc/config # <--- Remove this line
    - --container=metrics-server
    - --cpu=50m # <--- Increase CPU, such as to 50m
    - --extra-cpu=0.5m
    - --memory=35Mi
    - --extra-memory=4Mi
    - --threshold=5
    - --deployment=metrics-server
    - --poll-period=30000
    - --estimator=exponential
    - --scale-down-delay=24h
    - --minClusterSize=5
    - --use-metrics=true
    [...]
    
  3. Salva e chiudi metrics-server per applicare le modifiche.
Networking 1,14, 1,15 e 1,16

La connessione diretta NodePort al pod hostNetwork non funziona

La connessione a un pod abilitato con hostNetwork utilizzando il servizio NodePort non riesce quando il pod di backend si trova sullo stesso nodo di NodePort di destinazione. Questo problema interessa i servizi LoadBalancer quando vengono utilizzati con pod hostNetwork. In presenza di più backend, potrebbe verificarsi un errore di connessione sporadico.

Questo problema è causato da un bug nel programma eBPF.


Soluzione:

Quando utilizzi un servizio Nodeport, non scegliere come target il nodo su cui viene eseguito il pod di backend. Quando utilizzi il servizio LoadBalancer, assicurati che i pod hostNetwork non vengano eseguiti su nodi LoadBalancer.

Upgrade e aggiornamenti 1.12.3, 1.13.0

I cluster di amministrazione 1.13.0 non possono gestire i cluster utente 1.12.3

I cluster di amministrazione che eseguono la versione 1.13.0 non possono gestire i cluster utente che eseguono la versione 1.12.3. Le operazioni su un cluster utente versione 1.12.3 hanno esito negativo.


Soluzione:

Esegui l'upgrade del cluster di amministrazione alla versione 1.13.1 o esegui l'upgrade del cluster utente alla stessa versione del cluster di amministrazione.

Upgrade e aggiornamenti 1,12

L'upgrade alla versione 1.13.x è bloccato per i cluster di amministrazione con pool di nodi worker

I cluster di amministrazione versione 1.13.0 e successive non possono contenere pool di nodi worker. Gli upgrade alla versione 1.13.0 o successive per i cluster di amministrazione con pool di nodi worker sono bloccati. Se l'upgrade del cluster di amministrazione è bloccato, puoi verificare se la causa sono i pool di nodi worker controllando il seguente errore nel file upgrade-cluster.log all'interno della cartella bmctl-workspace:

Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=NodePool" cluster-test-cluster-2023-06-06-140654/np1: admission webhook "vnodepool.kb.io" denied the request: Adding worker nodepool to Admin cluster is disallowed.

Soluzione:

Prima di eseguire l'upgrade, sposta tutti i pool di nodi worker nei cluster utente. Per istruzioni su come aggiungere e rimuovere i pool di nodi, consulta Gestire i pool di nodi in un cluster.

Upgrade e aggiornamenti 1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16 e 1,28

Errori durante l'aggiornamento delle risorse utilizzando kubectl apply

Se aggiorni risorse esistenti, come le risorse personalizzate ClientConfig o Stackdriver utilizzando kubectl apply, il controller potrebbe restituire un errore o ripristinare l'input e le modifiche pianificate.

Ad esempio, potresti provare a modificare la risorsa personalizzata Stackdriver come segue, recuperando prima la risorsa e poi applicando una versione aggiornata:

  1. Ottieni la definizione YAML esistente:
    kubectl get stackdriver -n kube-system stackdriver \
        -o yaml > stackdriver.yaml
    
  2. Abilita le funzionalità o aggiorna la configurazione nel file YAML.
  3. Applica nuovamente il file YAML aggiornato:
    kubectl apply -f stackdriver.yaml
    

Il passaggio finale per kubectl apply è quello in cui potresti riscontrare problemi.


Soluzione:

Non utilizzare kubectl apply per apportare modifiche alle risorse esistenti. Utilizza invece kubectl edit o kubectl patch come mostrato nei seguenti esempi:

  1. Modifica la risorsa personalizzata Stackdriver:
    kubectl edit stackdriver -n kube-system stackdriver
    
  2. Abilita le funzionalità o aggiorna la configurazione nel file YAML.
  3. Salva ed esci dall'editor

Approccio alternativo utilizzando kubectl patch:

  1. Ottieni la definizione YAML esistente:
    kubectl get stackdriver -n kube-system stackdriver \
        -o yaml > stackdriver.yaml
    
  2. Abilita le funzionalità o aggiorna la configurazione nel file YAML.
  3. Applica nuovamente il file YAML aggiornato:
    kubectl patch stackdriver stackdriver --type merge \
        -n kube-system --patch-file stackdriver.yaml
    
Logging e monitoraggio 1,12; 1,13; 1,14; 1,15; 1,16

I blocchi di backlog danneggiati causano un arresto anomalo di stackdriver-log-forwarder

L'arresto anomalo di stackdriver-log-forwarder in loop se tenta di elaborare un blocco di backlog danneggiato. Nei log dei container vengono mostrati i seguenti errori di esempio:

[2022/09/16 02:05:01] [error] [storage] format check failed: tail.1/1-1659339894.252926599.flb
[2022/09/16 02:05:01] [error] [engine] could not segregate backlog chunks

Quando si verifica questo arresto anomalo, non puoi visualizzare i log in Cloud Logging.


Soluzione:

Per risolvere questi errori, completa i seguenti passaggi:

  1. Identifica i blocchi del backlog danneggiati. Esamina i seguenti messaggi di errore di esempio:
    [2022/09/16 02:05:01] [error] [storage] format check failed: tail.1/1-1659339894.252926599.flb
    [2022/09/16 02:05:01] [error] [engine] could not segregate backlog chunks
    
    In questo esempio, il file tail.1/1-1659339894.252926599.flb archiviato in var/log/fluent-bit-buffers/tail.1/ è errato. Devi rimuovere ogni file *.flb con un controllo del formato non riuscito.
  2. Termina i pod in esecuzione per stackdriver-log-forwarder:
    kubectl --kubeconfig KUBECONFIG -n kube-system \
        patch daemonset stackdriver-log-forwarder \
        -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
    
    Sostituisci KUBECONFIG con il percorso del file kubeconfig del cluster utente.

    Verifica che i pod stackdriver-log-forwarder siano stati eliminati prima di andare al passaggio successivo.
  3. Connettiti al nodo tramite SSH dove è in esecuzione stackdriver-log-forwarder.
  4. Sul nodo, elimina tutti i file *.flb danneggiati in var/log/fluent-bit-buffers/tail.1/.

    Se sono presenti troppi file danneggiati e vuoi applicare uno script per pulire tutti i blocchi del backlog, utilizza i seguenti script:
    1. Esegui il deployment di un oggetto DaemonSet per pulire tutti i dati dirty nei buffer in fluent-bit:
      kubectl --kubeconfig KUBECONFIG -n kube-system apply -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
      
    2. Assicurati che il DaemonSet abbia ripulito tutti i nodi. L'output dei due comandi seguenti dovrebbe essere uguale al numero di nodi nel cluster:
      kubectl --kubeconfig KUBECONFIG logs \
          -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l
      kubectl --kubeconfig KUBECONFIG \
          -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l
      
    3. Elimina il DaemonSet di pulizia:
      kubectl --kubeconfig KUBECONFIG -n kube-system delete ds \
          fluent-bit-cleanup
      
    4. Riavvia i pod stackdriver-log-forwarder:
      kubectl --kubeconfig KUBECONFIG \
          -n kube-system patch daemonset stackdriver-log-forwarder --type json \
          -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
      
Networking, runtime VM su GDC 1.14.0

Il riavvio di Dataplane V2 (anetd) sui cluster può causare l'impossibilità di collegare le VM esistenti a una rete non pod

Nei cluster con più NIC, il riavvio di Dataplane V2 (anetd) può impedire alle macchine virtuali di collegarsi alle reti. Nei log dei pod anetd potrebbe essere osservato un errore simile al seguente:

could not find an allocator to allocate the IP of the multi-nic endpoint

Soluzione:

Come soluzione rapida, puoi riavviare la VM. Per evitare che il problema si ripeta, esegui l'upgrade del cluster alla versione 1.14.1 o successiva.

Operazione 1.13, 1.14.0 e 1.14.1

gke-metrics-agent non ha limiti di memoria sui cluster del profilo perimetrale

A seconda del carico di lavoro del cluster, gke-metrics-agent potrebbe utilizzare più di 4608 MiB di memoria. Questo problema riguarda solo i cluster di profili Google Distributed Cloud Edge. I cluster del profilo predefinito non sono interessati.


Soluzione:

Esegui l'upgrade del cluster alla versione 1.14.2 o successiva.

Installazione 1,12, 1,13

La creazione del cluster potrebbe non riuscire a causa di condizioni di gara

Quando crei cluster utilizzando kubectl, a causa delle condizioni di gara, il controllo preflight potrebbe non terminare. Di conseguenza, in alcuni casi la creazione del cluster potrebbe non riuscire.

Il riconciliatore dei controlli preflight crea un SecretForwarder per copiare il secret ssh-key predefinito nello spazio dei nomi di destinazione. In genere, il controllo preflight si avvale dei riferimenti del proprietario e delle riconciliazioni una volta completato SecretForwarder. Tuttavia, in rari casi, il riferimento del proprietario dell'oggetto SecretForwarder può perdere il riferimento al controllo preflight, causando il blocco del controllo preflight. Di conseguenza, la creazione del cluster non va a buon fine. Per continuare la riconciliazione per il controllo preflight basato su controller, elimina il pod dell'operatore del cluster o la risorsa preflight-check. Quando elimini la risorsa preflight-check, ne viene creata un'altra e la riconciliazione continua. In alternativa, puoi eseguire l'upgrade dei cluster esistenti (creati con una versione precedente) a una versione fissa.

Networking 1,9, 1,10, 1,11, 1,12, 1,13, 1,14 e 1,15

Gli indirizzi IP riservati non vengono rilasciati quando si utilizza il plug-in di località con la funzionalità multi-NIC

Nella funzionalità multi-Nic, se utilizzi il plug-in di localizzazione di CNI e l'operazione DEL CNI per eliminare un'interfaccia di rete per un pod, alcuni indirizzi IP riservati potrebbero non essere rilasciati correttamente. Questo accade quando l'operazione CNI DEL viene interrotta.

Puoi verificare le prenotazioni degli indirizzi IP inutilizzati dei pod eseguendo questo comando:

kubectl get ippools -A --kubeconfig KUBECONFIG_PATH

Soluzione:

Elimina manualmente gli indirizzi IP (ippool) che non vengono utilizzati.

Installazione 1.10; 1.11.0; 1.11.1; 1.11.2

Il rilevatore dei problemi del nodo non funziona nel cluster utente 1.10.4

Il rilevatore di problemi relativi ai nodi potrebbe non riuscire nei cluster utente versione 1.10.x, mentre i cluster di amministrazione versione 1.11.0, 1.11.1 o 1.11.2 gestiscono i cluster utente 1.10.x. Quando si verifica un errore del rilevatore di problemi con i nodi, il log viene aggiornato con il seguente messaggio di errore:

Error - NPD not supported for anthos baremetal version 1.10.4:
anthos version 1.10.4 not supported.

Soluzione alternativa

Esegui l'upgrade del cluster di amministrazione alla versione 1.11.3 per risolvere il problema.

Operazione 1,14

I nodi del cluster IPv4 in modalità isola 1.14 hanno una dimensione di maschera CIDR pod di 24

Nella release 1.14, l'impostazione maxPodsPerNode non viene presa in considerazione per i cluster in modalità Isola, pertanto ai nodi viene assegnata una dimensione di maschera CIDR pod di 24 (256 indirizzi IP).nQuesto potrebbe causare l'esaurimento degli indirizzi IP dei pod nel cluster prima del previsto. Ad esempio, se il cluster ha una dimensione della maschera CIDR dei pod pari a 22; a ogni nodo verrà assegnata una maschera CIDR pod di 24 e il cluster potrà supportare solo fino a quattro nodi. Il cluster potrebbe inoltre riscontrare instabilità della rete in un periodo di abbandono dei pod elevato quando maxPodsPerNode è impostato su 129 o su un valore superiore e l'overhead non è sufficiente nel CIDR dei pod per ciascun nodo.

Se il tuo cluster è interessato, il pod anetd segnala il seguente errore quando aggiungi un nuovo nodo al cluster e non è disponibile podCIDR:

error="required IPv4 PodCIDR not available"

Soluzione alternativa

Per risolvere il problema:

  1. Esegui l'upgrade alla versione 1.14.1 o a una versione successiva.
  2. Rimuovi i nodi worker e aggiungili di nuovo.
  3. Rimuovi i nodi del piano di controllo e aggiungili di nuovo, preferibilmente uno alla volta, per evitare tempi di inattività del cluster.
Upgrade e aggiornamenti 1.14.0, 1.14.1

Errore di rollback dell'upgrade del cluster

Il rollback di un upgrade potrebbe non riuscire per i cluster della versione 1.14.0 o 1.14.1. Se esegui l'upgrade di un cluster dalla versione 1.14.0 alla versione 1.14.1 e poi provi a eseguire il rollback alla versione 1.14.0 utilizzando il comando bmctl restore cluster, potrebbe essere restituito un errore come nell'esempio seguente:

I0119 22:11:49.705596  107905 client.go:48] Operation failed, retrying with backoff.
Cause: error updating "baremetal.cluster.gke.io/v1, Kind=HealthCheck" cluster-user-ci-f3a04dc1b0d2ac8/user-ci-f3a04dc1b0d2ac8-network: admission webhook "vhealthcheck.kb.io"
denied the request: HealthCheck.baremetal.cluster.gke.io "user-ci-f3a04dc1b0d2ac8-network" is invalid:
Spec: Invalid value: v1.HealthCheckSpec{ClusterName:(*string)(0xc0003096e0), AnthosBareMetalVersion:(*string)(0xc000309690),
Type:(*v1.CheckType)(0xc000309710), NodePoolNames:[]string(nil), NodeAddresses:[]string(nil), ConfigYAML:(*string)(nil),
CheckImageVersion:(*string)(nil), IntervalInSeconds:(*int64)(0xc0015c29f8)}: Field is immutable

Soluzione:

Elimina tutte le risorse healthchecks.baremetal.cluster.gke.io nello spazio dei nomi del cluster ed esegui nuovamente il comando bmctl restore cluster:

  1. Elenca tutte le healthchecks.baremetal.cluster.gke.io risorse:
    kubectl get healthchecks.baremetal.cluster.gke.io \
        --namespace=CLUSTER_NAMESPACE \
        --kubeconfig=ADMIN_KUBECONFIG
    

    Sostituisci quanto segue:

    • CLUSTER_NAMESPACE: lo spazio dei nomi per il cluster.
    • ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.
  2. Elimina tutte le healthchecks.baremetal.cluster.gke.io risorse elencate nel passaggio precedente:
    kubectl delete healthchecks.baremetal.cluster.gke.io \
        HEALTHCHECK_RESOURCE_NAME \
        --namespace=CLUSTER_NAMESPACE \
        --kubeconfig=ADMIN_KUBECONFIG
    
    Sostituisci HEALTHCHECK_RESOURCE_NAME con il nome delle risorse del controllo di integrità.
  3. Esegui di nuovo il comando bmctl restore cluster.
Networking 1.12.0

L'indirizzo IP esterno del servizio non funziona in modalità flat

In un cluster in cui flatIPv4 è impostato su true, i servizi di tipo LoadBalancer non sono accessibili dai loro indirizzi IP esterni.

Questo problema è stato risolto nella versione 1.12.1.


Soluzione:

In cilium-config ConfigMap, imposta enable-415 su "true", quindi riavvia i pod anetd.

Upgrade e aggiornamenti 1.13.0, 1.14

Gli upgrade sul posto dalla versione 1.13.0 alla versione 1.14.x non terminano mai

Quando provi a eseguire un upgrade in loco da 1.13.0 a 1.14.x utilizzando bmctl 1.14.0 e il flag --use-bootstrap=false, l'upgrade non termina mai.

Un errore con l'operatore preflight-check fa sì che il cluster non pianifichi mai i controlli richiesti, il che significa che il controllo preflight non termina mai.


Soluzione:

Esegui l'upgrade alla versione 1.13.1 prima di eseguire l'upgrade alla versione 1.14.x. Un upgrade in loco da 1.13.0 a 1.13.1 dovrebbe funzionare. In alternativa, esegui l'upgrade da 1.13.0 a 1.14.x senza il flag --use-bootstrap=false.

Upgrade e aggiornamenti, Sicurezza 1.13 e 1.14

I cluster aggiornati alla versione 1.14.0 perdono le incompatibilità principali

I nodi del piano di controllo richiedono una delle due incompatibilità specifiche per impedire la pianificazione dei pod dei carichi di lavoro al loro interno. Quando esegui l'upgrade dei cluster GKE dalla versione 1.13 alla versione 1.14.0, i nodi del piano di controllo perdono le seguenti incompatibilità obbligatorie:

  • node-role.kubernetes.io/master:NoSchedule
  • node-role.kubernetes.io/master:PreferNoSchedule

Questo problema non causa errori di upgrade, ma potrebbero iniziare i pod che non dovrebbero essere eseguiti sui nodi del piano di controllo. Questi pod dei carichi di lavoro possono sovraccaricare i nodi del piano di controllo e portare all'instabilità del cluster.

Determinare se il problema ti riguarda

  1. Per trovare i nodi del piano di controllo, utilizza il seguente comando:
    kubectl get node -l 'node-role.kubernetes.io/control-plane' \
        -o name --kubeconfig KUBECONFIG_PATH
    
  2. Per controllare l'elenco delle incompatibilità su un nodo, utilizza il seguente comando:
    kubectl describe node NODE_NAME \
        --kubeconfig KUBECONFIG_PATH
    

    Se nessuna delle incompatibilità richieste è elencata, significa che sei interessato.

Soluzione alternativa

Per ripristinare la funzione corretta, segui questi passaggi per ciascun nodo del piano di controllo del cluster della versione 1.14.0 interessato. Questi passaggi si riferiscono all'incompatibilità node-role.kubernetes.io/master:NoSchedule e ai pod correlati. Se prevedi che i nodi del piano di controllo utilizzino l'incompatibilità PreferNoSchedule, modifica i passaggi di conseguenza.

Operazione, runtime VM su GDC 1,11; 1,12; 1,13; 1,14; 1,15; 1,16; 1,28; 1,29

La creazione della VM non riesce a intermittenza con errori di caricamento

La creazione di una nuova macchina virtuale (VM) con il comando kubectl virt create vm ha esito negativo con minore frequenza durante il caricamento delle immagini. Il problema riguarda sia le VM Linux che le VM Windows. L'errore è simile al seguente esempio:

PVC default/heritage-linux-vm-boot-dv not found DataVolume default/heritage-linux-vm-boot-dv created
Waiting for PVC heritage-linux-vm-boot-dv upload pod to be ready... Pod now ready
Uploading data to https://10.200.0.51

 2.38 MiB / 570.75 MiB [>----------------------------------------------------------------------------------]   0.42% 0s

fail to upload image: unexpected return value 500,  ...

Soluzione alternativa

Riprova a utilizzare il comando kubectl virt create vm per creare la VM.

Upgrade e aggiornamenti, Logging e monitoraggio 1,11

I componenti della raccolta gestita nei cluster 1.11 non vengono conservati negli upgrade alla versione 1.12

I componenti della raccolta gestita fanno parte di Managed Service per Prometheus. Se hai eseguito manualmente il deployment dei componenti della raccolta gestita nello spazio dei nomi gmp-system dei tuoi cluster della versione 1.11, le risorse associate non vengono conservate quando esegui l'upgrade alla versione 1.12.

A partire dai cluster della versione 1.12.0, i componenti di Managed Service per Prometheus nello spazio dei nomi gmp-system e le relative definizioni delle risorse personalizzate vengono gestiti da stackdriver-operator con il campo enableGMPForApplications. Per impostazione predefinita, il campo enableGMPForApplications è true, quindi se esegui manualmente il deployment dei componenti Managed Service per Prometheus nello spazio dei nomi prima di eseguire l'upgrade alla versione 1.12, le risorse vengono eliminate da stackdriver-operator.

Soluzione alternativa

Per conservare le risorse di raccolta gestite manualmente:

  1. Esegui il backup di tutte le risorse personalizzate di PodMonitoring esistenti.
  2. Esegui l'upgrade del cluster alla versione 1.12 e abilita Managed Service per Prometheus.
  3. Esegui di nuovo il deployment delle risorse personalizzate di PodMonitoring sul cluster di cui è stato eseguito l'upgrade.
Upgrade e aggiornamenti 1,13

Alcuni cluster della versione 1.12 con il runtime del container Docker non possono eseguire l'upgrade alla versione 1.13

Se in un cluster della versione 1.12 che utilizza il runtime del container Docker manca la seguente annotazione, non può eseguire l'upgrade alla versione 1.13:

baremetal.cluster.gke.io/allow-docker-container-runtime:  "true"

Se questo problema ti riguarda, bmctl scrive il seguente errore nel file upgrade-cluster.log all'interno della cartella bmctl-workspace:

Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=Cluster": admission webhook
"vcluster.kb.io" denied the request: Spec.NodeConfig.ContainerRuntime: Forbidden: Starting with Anthos Bare Metal version 1.13 Docker container
runtime will not be supported. Before 1.13 please set the containerRuntime to containerd in your cluster resources.

Although highly discouraged, you can create a cluster with Docker node pools until 1.13 by passing the flag "--allow-docker-container-runtime" to bmctl
create cluster or add the annotation "baremetal.cluster.gke.io/allow-docker- container-runtime: true" to the cluster configuration file.

È più probabile che questo si verifichi con i cluster Docker della versione 1.12 di cui è stato eseguito l'upgrade dalla versione 1.11, poiché l'upgrade non richiede l'annotazione per mantenere il runtime dei container Docker. In questo caso, i cluster non dispongono dell'annotazione quando viene eseguito l'upgrade alla versione 1.13. Tieni presente che a partire dalla versione 1.13, containerd è l'unico runtime del container consentito.

Soluzione:

Se riscontri questo problema, aggiorna la risorsa del cluster con l'annotazione mancante. Puoi aggiungere l'annotazione mentre l'upgrade è in esecuzione o dopo l'annullamento e prima di riprovare.

Installazione 1,11

bmctl viene chiuso prima del completamento della creazione del cluster

La creazione del cluster potrebbe non riuscire per Google Distributed Cloud versione 1.11.0 (questo problema è stato risolto nella release 1.11.1 di Google Distributed Cloud). In alcuni casi, il comando bmctl create cluster si chiude in anticipo e scrive nei log errori simili ai seguenti:

Error creating cluster: error waiting for applied resources: provider cluster-api watching namespace USER_CLUSTER_NAME not found in the target cluster

Soluzione alternativa

L'operazione non riuscita produce artefatti, ma il cluster non è operativo. Se questo problema ti riguarda, segui questi passaggi per pulire gli artefatti e creare un cluster:

Installazione, runtime VM su GDC 1,11, 1,12

Report di installazione: errore di riconciliazione del runtime delle VM

L'operazione di creazione del cluster potrebbe segnalare un errore simile al seguente:

I0423 01:17:20.895640 3935589 logs.go:82]  "msg"="Cluster reconciling:" "message"="Internal error occurred: failed calling webhook \"vvmruntime.kb.io\": failed to call webhook: Post \"https://vmruntime-webhook-service.kube-system.svc:443/validate-vm-cluster-gke-io-v1vmruntime?timeout=10s\": dial tcp 10.95.5.151:443: connect: connection refused" "name"="xxx" "reason"="ReconciliationError"

Soluzione alternativa

Questo errore è benigno e puoi tranquillamente ignorarlo.

Installazione 1,10, 1,11 e 1,12

La creazione del cluster non riesce quando si utilizzano più NIC, containerd e proxy HTTPS

La creazione del cluster non va a buon fine quando si ha la seguente combinazione di condizioni:

  • Il cluster è configurato in modo da utilizzare containerd come runtime del container (nodeConfig.containerRuntime impostato su containerd nel file di configurazione del cluster, l'impostazione predefinita per Google Distributed Cloud versione 1.13 e successive).
  • Il cluster è configurato in modo da fornire più interfacce di rete, con più NIC, per i pod (clusterNetwork.multipleNetworkInterfaces impostato su true nel file di configurazione del cluster).
  • Il cluster è configurato per l'utilizzo di un proxy (spec.proxy.url è specificato nel file di configurazione del cluster). Anche se la creazione del cluster non riesce, questa impostazione viene propagata quando tenti di creare un cluster. Potresti visualizzare questa impostazione del proxy come una variabile di ambiente HTTPS_PROXY o nella configurazione di containerd (/etc/systemd/system/containerd.service.d/09-proxy.conf).

Soluzione alternativa

Aggiungi i CIDR del servizio (clusterNetwork.services.cidrBlocks) alla variabile di ambiente NO_PROXY su tutte le macchine nodo.

Installazione 1,10, 1,11 e 1,12

Errore sui sistemi con impostazione umask restrittiva

Con la release 1.10.0 di Google Distributed Cloud è stata introdotta una funzionalità del piano di controllo rootless che esegue tutti i componenti del piano di controllo come utente non root. L'esecuzione di tutti i componenti come utente non root può causare errori di installazione o upgrade su sistemi con un'impostazione umask più restrittiva di 0077.


Soluzione alternativa

Reimposta i nodi del piano di controllo e modifica l'impostazione umask in 0022 su tutte le macchine del piano di controllo. Dopo aver aggiornato le macchine, riprova a eseguire l'installazione.

In alternativa, puoi modificare le autorizzazioni della directory e dei file di /etc/kubernetes sulle macchine del piano di controllo per l'installazione o l'upgrade per procedere.

  • Rendi leggibili /etc/kubernetes e tutte le relative sottodirectory: chmod o+rx.
  • Rendi leggibili da tutto il mondo tutti i file di proprietà dell'utente root nella directory (in modo ricorsivo) /etc/kubernetes (chmod o+r). Escludi i file di chiavi privati (.key) da queste modifiche perché sono già stati creati con proprietà e autorizzazioni corrette.
  • Rendi /usr/local/etc/haproxy/haproxy.cfg leggibile.
  • Rendi /usr/local/etc/bgpadvertiser/bgpadvertiser-cfg.yaml leggibile.
Installazione 1,10; 1,11; 1,12; 1,13

Incompatibilità gruppo di controllo v2

Il gruppo di controllo v2 (cgroup v2) non è supportato nei cluster Google Distributed Cloud versioni 1.13 e precedenti di Google Distributed Cloud. Tuttavia, la versione 1.14 supporta cgroup v2 come funzionalità di anteprima . La presenza di /sys/fs/cgroup/cgroup.controllers indica che il tuo sistema utilizza cgroup v2.


Soluzione alternativa

Se il sistema utilizza cgroup v2, esegui l'upgrade del cluster alla versione 1.14.

Installazione 1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16, 1,28 e 1,29

Controlli preflight e credenziali dell'account di servizio

Per le installazioni attivate da cluster di amministrazione o ibridi (in altre parole, cluster non creati con bmctl, come i cluster utente), il controllo preflight non verifica le credenziali dell'account di servizio Google Cloud o le autorizzazioni associate.

Installazione 1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16, 1,28 e 1,29

Installazione su vSphere

Quando installi i cluster Google Distributed Cloud sulle VM vSphere, devi disattivare i flag tx-udp_tnl-segmentation e tx-udp_tnl-csum-segmentation. Questi flag sono relativi all'offload della segmentazione hardware eseguita dal driver vSphere VMXNET3 e non funzionano con il tunnel GENEVE dei cluster Google Distributed Cloud.


Soluzione alternativa

Esegui questo comando su ciascun nodo per verificare i valori attuali di questi flag:

ethtool -k NET_INTFC | grep segm

Sostituisci NET_INTFC con l'interfaccia di rete associata all'indirizzo IP del nodo.

La risposta deve contenere voci come le seguenti:

...
tx-udp_tnl-segmentation: on
tx-udp_tnl-csum-segmentation: on
...
A volte in RHEL 8.4, ethtool mostra che questi flag sono disattivati mentre non lo sono. Per impostare esplicitamente questi flag su Off, attivali e disattivali con i seguenti comandi:
ethtool -K ens192 tx-udp_tnl-segmentation on ethtool -K ens192 \
    tx-udp_tnl-csum-segmentation on
ethtool -K ens192 tx-udp_tnl-segmentation off ethtool -K ens192 \
    tx-udp_tnl-csum-segmentation off

Questa modifica del flag non viene applicata durante i riavvii. Configura gli script di avvio in modo da impostare esplicitamente questi flag all'avvio del sistema.

Upgrade e aggiornamenti 1,1

bmctl non può creare, aggiornare o reimpostare i cluster utente con versioni precedenti

L'interfaccia a riga di comando bmctl non può creare, aggiornare o reimpostare un cluster utente con una versione secondaria inferiore, indipendentemente dalla versione del cluster di amministrazione. Ad esempio, non puoi utilizzare bmctl con una versione di 1.N.X per reimpostare un cluster utente con versione 1.N-1.Y, anche se anche il cluster di amministrazione ha la versione 1.N.X.

Se hai riscontrato questo problema, dovresti vedere log simili ai seguenti quando utilizzi bmctl:

[2022-06-02 05:36:03-0500] error judging if the cluster is managing itself: error to parse the target cluster: error parsing cluster config: 1 error occurred:

*   cluster version 1.8.1 isn't supported in bmctl version 1.9.5, only cluster version 1.9.5 is supported

Soluzione:

Utilizza kubectl per creare, modificare o eliminare la risorsa personalizzata del cluster utente all'interno del cluster di amministrazione.

La possibilità di eseguire l'upgrade dei cluster utente non è interessata.

Upgrade e aggiornamenti 1,12

Gli upgrade del cluster alla versione 1.12.1 potrebbero bloccarsi

L'upgrade dei cluster alla versione 1.12.1 a volte si blocca perché il server API non è più disponibile. Questo problema riguarda tutti i tipi di cluster e tutti i sistemi operativi supportati. Quando si verifica questo problema, il comando bmctl upgrade cluster può avere esito negativo in più punti, anche durante la seconda fase dei controlli preflight.


Soluzione alternativa

Puoi controllare i log dell'upgrade per capire se questo problema ti riguarda. I log dell'upgrade si trovano in /baremetal/bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP per impostazione predefinita.

upgrade-cluster.log potrebbe contenere errori come i seguenti:

Failed to upgrade cluster: preflight checks failed: preflight check failed
Il log della macchina potrebbe contenere errori come i seguenti (errori ripetuti indicano che il problema ti riguarda):
FAILED - RETRYING: Query CNI health endpoint (30 retries left). FAILED - RETRYING: Query CNI health endpoint (29 retries left).
FAILED - RETRYING: Query CNI health endpoint (28 retries left). ...

Prima di ritentare di eseguire l'upgrade del cluster alla versione 1.12.1, HAProxy e KeepaLive devono essere in esecuzione su ciascun nodo del piano di controllo. Utilizza l' interfaccia a riga di comando crictl su ciascun nodo per verificare se i container haproxy e keepalived sono in esecuzione:

docker/crictl ps | grep haproxy docker/crictl ps | grep keepalived

Se HAProxy o KeepaLive non è in esecuzione su un nodo, riavvia kubelet sul nodo:

systemctl restart kubelet
Upgrade e aggiornamenti, runtime VM su GDC 1,11, 1,12

L'upgrade dei cluster alla versione 1.12.0 o successiva non riesce quando è abilitato il runtime VM su GDC

Nella versione 1.12.0 dei cluster Google Distributed Cloud, viene eseguita la migrazione di tutte le risorse relative al runtime VM su GDC nello spazio dei nomi vm-system per supportare meglio la release GA di VM Runtime su GDC. Se hai abilitato il runtime VM su GDC in un cluster della versione 1.11.x o precedente, l'upgrade alla versione 1.12.0 o successiva non riesce a meno che non disabiliti prima il runtime VM in GDC. Se si verifica questo problema, l'operazione di upgrade segnala il seguente errore:

Failed to upgrade cluster: cluster isn't upgradable with vmruntime enabled from
version 1.11.x to version 1.12.0: please disable VMruntime before upgrade to
1.12.0 and higher version

Soluzione alternativa

Per disabilitare il runtime VM su GDC:

  1. Modifica la risorsa personalizzata VMRuntime:
    kubectl edit vmruntime
    
  2. Imposta enabled su false nella specifica:
    apiVersion: vm.cluster.gke.io/v1
    kind: VMRuntime
    metadata:
      name: vmruntime
    spec:
      enabled: false
      ...
    
  3. Salva la risorsa personalizzata nell'editor.
  4. Una volta completato l'upgrade del cluster, riabilita il runtime VM su GDC.

Per maggiori informazioni, consulta Utilizzo dei carichi di lavoro basati su VM.

Upgrade e aggiornamenti 1,10, 1,11 e 1,12

L'upgrade è bloccato a error during manifests operations

In alcune situazioni, gli upgrade del cluster non vengono completati e l'interfaccia a riga di comando bmctl non risponde. Questo problema può essere causato da un aggiornamento errato della risorsa. Per determinare se il problema ti riguarda e per correggerlo, controlla i log di anthos-cluster-operator e cerca errori simili alle seguenti voci:

controllers/Cluster "msg"="error during manifests operations" "error"="1 error occurred: ... {RESOURCE_NAME} is invalid: metadata.resourceVersion: Invalid value: 0x0: must be specified for an update

Queste voci sono sintomo di una risorsa aggiornata in modo errato, dove {RESOURCE_NAME} è il nome della risorsa del problema.


Soluzione alternativa

Se trovi questi errori nei log, completa i seguenti passaggi:

  1. Utilizza kubectl edit per rimuovere l'annotazione kubectl.kubernetes.io/last-applied-configuration dalla risorsa contenuta nel messaggio di log.
  2. Salva e applica le modifiche alla risorsa.
  3. Riprova a eseguire l'upgrade del cluster.
Upgrade e aggiornamenti 1,10, 1,11 e 1,12

Gli upgrade sono bloccati per i cluster con funzionalità che utilizzano il gateway di rete per GDC

Gli upgrade dei cluster da 1.10.x a 1.11.x non riescono per i cluster che utilizzano il gateway NAT in uscita o il bilanciamento del carico in bundle con BGP. Entrambi queste funzionalità utilizzano Network Gateway per GDC. Gli upgrade del cluster si bloccano al messaggio della riga di comando Waiting for upgrade to complete... e agli errori dei log anthos-cluster-operator come i seguenti:

apply run failed ... MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field
is immutable...

Soluzione alternativa

Per sbloccare l'upgrade, esegui questi comandi sul cluster di cui stai eseguendo l'upgrade:

kubectl -n kube-system delete deployment \
    ang-controller-manager-autoscaler
kubectl -n kube-system delete deployment \
    ang-controller-manager
kubectl -n kube-system delete ds ang-node
Upgrade e aggiornamenti 1,10, 1,11, 1,12, 1,13, 1,14 e 1,15

bmctl update non rimuove i blocchi di manutenzione

Il comando bmctl update non può rimuovere o modificare la sezione maintenanceBlocks dalla configurazione delle risorse del cluster.


Soluzione alternativa

Per ulteriori informazioni, incluse le istruzioni per rimuovere i nodi dalla modalità di manutenzione, consulta Attivare la modalità di manutenzione dei nodi.

Operazione 1,10, 1,11 e 1,12

Nodi contrassegnati come non pianificabili se non utilizzi la procedura in modalità di manutenzione

Se esegui cluster della versione 1.12.0 (anthosBareMetalVersion: 1.12.0) o versioni precedenti e utilizzi manualmente kubectl cordon su un nodo, Google Distributed Cloud potrebbe annullare il contrassegno del nodo prima di tutto ciò di cui hai bisogno, nel tentativo di riconciliare lo stato previsto.


Soluzione alternativa

Per i cluster della versione 1.12.0 e precedenti, utilizza la modalità di manutenzione per contrassegnare e svuotare i nodi in modo sicuro.

Nella versione 1.12.1 (anthosBareMetalVersion: 1.12.1) o successive, Google Distributed Cloud non contrassegna inaspettatamente i nodi quando utilizzi kubectl cordon.

Operazione 1,11

I cluster di amministrazione della versione 11 che utilizzano un mirror del registro non possono gestire i cluster della versione 1.10

Se la versione del cluster di amministrazione è 1.11 e utilizza un mirror del registro, non può gestire i cluster utente che si trovano in una versione secondaria inferiore. Questo problema riguarda le operazioni di reimpostazione, aggiornamento ed upgrade sul cluster utente.

Per determinare se questo problema ti riguarda, controlla nei log le operazioni del cluster, come creazione, upgrade o reimpostazione. Questi log si trovano nella cartella bmctl-workspace/CLUSTER_NAME/ per impostazione predefinita. Se hai riscontrato questo problema, i log contengono il seguente messaggio di errore:

flag provided but not defined: -registry-mirror-host-to-endpoints
Operazione 1,10, 1,11

Secret kubeconfig sovrascritto

Il comando bmctl check cluster, se eseguito sui cluster utente, sovrascrive il secret kubeconfig del cluster utente con il cluster di amministrazione kubeconfig. Se sovrascrivi il file, le operazioni standard del cluster, come l'aggiornamento e l'upgrade, non vanno a buon fine per i cluster utente interessati. Questo problema si applica alle versioni 1.11.1 e precedenti del cluster Google Distributed Cloud.

Per determinare se questo problema interessa un cluster utente, esegui questo comando:

kubectl --kubeconfig ADMIN_KUBECONFIG \
    get secret -n USER_CLUSTER_NAMESPACE \
    USER_CLUSTER_NAME -kubeconfig \
    -o json  | jq -r '.data.value'  | base64 -d

Sostituisci quanto segue:

  • ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.
  • USER_CLUSTER_NAMESPACE: lo spazio dei nomi per il cluster. Per impostazione predefinita, gli spazi dei nomi dei cluster Google Distributed Cloud sono il nome del cluster preceduto da cluster-. Ad esempio, se assegni al cluster il nome test, lo spazio dei nomi predefinito è cluster-test.
  • USER_CLUSTER_NAME: il nome del cluster utente da verificare.

Se il nome del cluster nell'output (vedi contexts.context.cluster nel seguente output di esempio) è il nome del cluster di amministrazione, il cluster utente specificato è interessato.

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data:LS0tLS1CRU...UtLS0tLQo=
    server: https://10.200.0.6:443
  name: ci-aed78cdeca81874
contexts:
- context:
    cluster: ci-aed78cdeca81
    user: ci-aed78cdeca81-admin
  name: ci-aed78cdeca81-admin@ci-aed78cdeca81
current-context: ci-aed78cdeca81-admin@ci-aed78cdeca81
kind: Config
preferences: {}
users:
- name: ci-aed78cdeca81-admin
  user:
    client-certificate-data: LS0tLS1CRU...UtLS0tLQo=
    client-key-data: LS0tLS1CRU...0tLS0tCg==

Soluzione alternativa

I passaggi seguenti ripristinano la funzione in un cluster utente interessato (USER_CLUSTER_NAME):

  1. Individua il file kubeconfig del cluster utente. Google Distributed Cloud genera il file kubeconfig sulla workstation di amministrazione quando crei un cluster. Per impostazione predefinita, il file si trova nella directory bmctl-workspace/USER_CLUSTER_NAME.
  2. Verifica che kubeconfig sia il cluster utente kubeconfig corretto:
    kubectl get nodes \
        --kubeconfig PATH_TO_GENERATED_FILE
    
    Sostituisci PATH_TO_GENERATED_FILE con il percorso del file kubeconfig del cluster utente. La risposta restituisce i dettagli sui nodi per il cluster utente. Verifica che i nomi delle macchine siano corretti per il tuo cluster.
  3. Esegui questo comando per eliminare il file kubeconfig danneggiato nel cluster di amministrazione:
    kubectl delete secret \
        -n USER_CLUSTER_NAMESPACE \
        USER_CLUSTER_NAME-kubeconfig
    
  4. Esegui questo comando per salvare il secret kubeconfig corretto nel cluster di amministrazione:
    kubectl create secret generic \
        -n USER_CLUSTER_NAMESPACE \
        USER_CLUSTER_NAME-kubeconfig \
        --from-file=value=PATH_TO_GENERATED_FILE
    
Operazione 1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16, 1,28 e 1,29

Acquisizione di uno snapshot come utente di accesso non root

Se utilizzi containerd come runtime del container, l'esecuzione di snapshot come utente non root richiede che /usr/local/bin si trovi nel PATH dell'utente. In caso contrario, l'operazione non andrà a buon fine e verrà visualizzato un errore crictl: command not found.

Se non hai eseguito l'accesso come utente root, viene utilizzato sudo per eseguire i comandi degli snapshot. Il PATH sudo può essere diverso dal profilo principale e non può contenere /usr/local/bin.


Soluzione alternativa

Aggiorna secure_path in /etc/sudoers per includere /usr/local/bin. In alternativa, crea un link simbolico per crictl in un'altra directory /bin.

Logging e monitoraggio 1,1

stackdriver-log-forwarder ha [parser:cri] invalid time format log degli avvisi

Se l'analizzatore sintattico dell'interfaccia di runtime del container (CRI) utilizza un'espressione regolare errata per il tempo di analisi, i log per il pod stackdriver-log-forwarder contengono errori e avvisi come i seguenti:

[2022/03/04 17:47:54] [error] [parser] time string length is too long [2022/03/04 20:16:43] [ warn] [parser:cri] invalid time format %Y-%m-%dT%H:%M:%S.%L%z for '2022-03-04T20:16:43.680484387Z'

Soluzione:

Logging e monitoraggio 1,10, 1,11, 1,12, 1,13, 1,14 e 1,15

Fatturazione monitoraggio imprevista

Per le versioni dei cluster Google Distributed Cloud dalla 1.10 alla 1.15, alcuni clienti hanno riscontrato una fatturazione inaspettatamente elevata per Metrics volume nella pagina Fatturazione. Questo problema ti riguarda solo quando si applicano tutte le seguenti circostanze:

  • Il monitoraggio delle applicazioni è abilitato (enableStackdriverForApplications=true)
  • Managed Service per Prometheus non è abilitato (enableGMPForApplications)
  • I pod di applicazione hanno l'annotazione prometheus.io/scrap=true

Per confermare se questo problema ti riguarda, elenca le metriche definite dall'utente. Se visualizzi la fatturazione per metriche indesiderate, questo problema riguarda il tuo caso.


Soluzione alternativa

Se riscontri questo problema, ti consigliamo di eseguire l'upgrade dei cluster alla versione 1.12 e di passare alla nuova soluzione di monitoraggio delle applicazioni managed-service-for-prometheus che risolvono il problema:

  • Flag separati per controllare la raccolta dei log dell'applicazione rispetto alle metriche dell'applicazione
  • Google Cloud Managed Service in bundle per Prometheus
  • Se non puoi eseguire l'upgrade alla versione 1.12, segui questi passaggi:

    1. Trova i pod e i servizi di origine che hanno la fatturazione indesiderata:
      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 dal servizio.
    Logging e monitoraggio 1,11; 1,12; 1,13; 1,14; 1,15; 1,16; 1,28

    Le modifiche a metrics-server-config non vengono rese persistenti

    In casi estremi, un'elevata densità di pod può generare un overhead eccessivo di logging e monitoraggio, che può causare l'arresto e il riavvio di Metrics Server. Puoi modificare il ConfigMap metrics-server-config per allocare più risorse e mantenere in esecuzione Metrics Server. Tuttavia, a causa della riconciliazione, le modifiche apportate a metrics-server-config possono essere ripristinate al valore predefinito durante un'operazione di aggiornamento o upgrade del cluster. Il server delle metriche non viene subito interessato, ma al successivo riavvio riprende il ConfigMap ripristinato ed è di nuovo vulnerabile a un overhead eccessivo.


    Soluzione alternativa

    Per 1.11.x, puoi creare uno script per la modifica di ConfigMap ed eseguirla insieme ad aggiornamenti o upgrade al cluster. Per la versione 1.12 e versioni successive, contatta l'assistenza.

    Logging e monitoraggio 1,11, 1,12

    Le metriche deprecate influiscono sulla dashboard di Cloud Monitoring

    Diverse metriche di Google Distributed Cloud sono state deprecate e, a partire dalla release 1.11 di Google Distributed Cloud, i dati per queste metriche deprecate non vengono più raccolti. Se utilizzi queste metriche in uno dei criteri di avviso, non saranno disponibili dati per attivare la condizione di avviso.

    La seguente tabella elenca le singole metriche che sono state deprecate e la metrica che le sostituisce.

    Metriche deprecate Metrica sostitutiva
    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

    Nelle versioni dei cluster Google Distributed Cloud precedenti alla 1.11, il file di definizione dei criteri per l'avviso Anthos on baremetal node cpu usage exceeds 80 percent (critical) consigliato utilizza le metriche deprecate. Il file di definizione JSON node-cpu-usage-high.json viene aggiornato per le release 1.11.0 e successive.


    Soluzione alternativa

    Per eseguire la migrazione alle metriche sostitutive:

    1. Nella console Google Cloud, seleziona Monitoring o fai clic sul pulsante seguente:
      Vai a Monitoring
    2. Nel riquadro di navigazione, seleziona Dashboard ed elimina la dashboard dello stato del nodo del cluster Anthos.
    3. Fai clic sulla scheda Libreria di esempio e reinstalla la dashboard dello stato dei nodi cluster Anthos.
    4. Segui le istruzioni riportate in Creazione di criteri di avviso per creare un criterio utilizzando il file di definizione del criterio aggiornato node-cpu-usage-high.json.
    Logging e monitoraggio 1,10, 1,11

    stackdriver-log-forwarder ha CrashloopBackOff errori

    In alcune situazioni, l'agente di logging fluent-bit può bloccarsi durante l'elaborazione di blocchi danneggiati. Quando l'agente Logging non è in grado di bypassare i blocchi danneggiati, potresti notare che stackdriver-log-forwarder continua ad arrestarsi in modo anomalo con un errore CrashloopBackOff. Se riscontri questo problema, i log contengono voci come le seguenti

    [2022/03/09 02:18:44] [engine] caught signal (SIGSEGV) #0  0x5590aa24bdd5
    in  validate_insert_id() at plugins/out_stackdriver/stackdriver.c:1232
    #1  0x5590aa24c502      in  stackdriver_format() at plugins/out_stackdriver/stackdriver.c:1523
    #2  0x5590aa24e509      in  cb_stackdriver_flush() at plugins/out_stackdriver/stackdriver.c:2105
    #3  0x5590aa19c0de      in  output_pre_cb_flush() at include/fluent-bit/flb_output.h:490
    #4  0x5590aa6889a6      in  co_init() at lib/monkey/deps/flb_libco/amd64.c:117 #5  0xffffffffffffffff  in  ???() at ???:0
    

    Soluzione:

    Eseguire la pulizia dei blocchi del buffer per Stackdriver Log Forwarder.

    Nota: nei comandi seguenti, sostituisci KUBECONFIG con il percorso del file kubeconfig del cluster di amministrazione.

    1. Termina tutti i pod stackdriver-log-forwarder:
      kubectl --kubeconfig KUBECONFIG -n kube-system patch daemonset \
          stackdriver-log-forwarder -p \
          '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
      
      Verifica che i pod stackdriver-log-forwarder siano stati eliminati prima di andare al passaggio successivo.
    2. Esegui il deployment del seguente DaemonSet per ripulire eventuali dati danneggiati nei buffer fluent-bit:
      kubectl --kubeconfig KUBECONFIG -n kube-system apply -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. Utilizza i comandi seguenti per verificare che il DaemonSet abbia ripulito tutti i nodi:
      kubectl --kubeconfig KUBECONFIG logs \
          -n kube-system -l \
          app=fluent-bit-cleanup | grep "cleaned up" | wc -l
      kubectl --kubeconfig KUBECONFIG -n \
          kube-system get pods -l \
          app=fluent-bit-cleanup --no-headers | wc -l
      
      L'output dei due comandi deve essere uguale al numero di nodi nel tuo cluster.
    4. Elimina il DaemonSet di pulizia:
      kubectl --kubeconfig KUBECONFIG -n \
          kube-system delete ds fluent-bit-cleanup
      
    5. Riavvia i pod del forwarding dei log:
      kubectl --kubeconfig 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, 1,16 e 1,28

    Errore di metriche sconosciuto nel log gke-metrics-agent

    gke-metrics-agent è un daemonset che raccoglie metriche su ciascun nodo e le inoltra a Cloud Monitoring. Potrebbe generare log come i seguenti:

    Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile
    

    Errori simili possono verificarsi per altri tipi di metriche, inclusi, a titolo esemplificativo:

    • 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

    Questi log degli errori possono essere ignorati tranquillamente in quanto le metriche a cui fanno riferimento non sono supportate e non sono fondamentali per il monitoraggio.

    Logging e monitoraggio 1,10, 1,11

    Interruzioni intermittenti dell'esportazione delle metriche

    I cluster Google Distributed Cloud potrebbero riscontrare interruzioni nell'esportazione normale e continua delle metriche oppure metriche mancanti su alcuni nodi. Se questo problema riguarda i tuoi cluster, potresti notare (almeno) lacune nei dati per le seguenti metriche:

    • 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 alternativa

    Esegui l'upgrade dei cluster alla versione 1.11.1 o successiva.

    Se non riesci a eseguire l'upgrade, procedi nel seguente modo come soluzione alternativa:

    1. Apri la risorsa stackdriver da modificare:
      kubectl -n kube-system edit stackdriver stackdriver
      
    2. Per aumentare la richiesta di CPU per gke-metrics-agent da 10m a 50m, aggiungi la seguente sezione resourceAttrOverride al manifest stackdriver:
      spec:
        resourceAttrOverride:
          gke-metrics-agent/gke-metrics-agent:
            limits:
              cpu: 100m
              memory: 4608Mi
            requests:
              cpu: 50m
              memory: 200Mi
      
      La risorsa modificata dovrebbe essere simile alla seguente:
      spec:
        anthosDistribution: baremetal
        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: 100m
              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 -n kube-system get daemonset \
          gke-metrics-agent -o yaml | grep "cpu: 50m"
      
      Il comando trova cpu: 50m se le modifiche sono state applicate.
    Networking 1,1

    Più gateway predefiniti interrompono la connettività agli endpoint esterni

    Avere più gateway predefiniti in un nodo può causare l'interruzione della connettività dall'interno di un pod a endpoint esterni, come google.com.

    Per determinare se hai riscontrato questo problema, esegui questo comando sul nodo:

    ip route show
    

    Più istanze di default nella risposta indicano che il problema ti riguarda.

    Networking 1,12

    Le modifiche alle risorse personalizzate di networking sui cluster utente vengono sovrascritte

    I cluster Google Distributed Cloud versione 1.12.x non ti impediscono di modificare manualmente le risorse personalizzate di networking nel tuo cluster utente. Google Distributed Cloud riconcilia le risorse personalizzate nei cluster utente con quelle personalizzate nel tuo cluster di amministrazione durante gli upgrade del cluster. Questa riconciliazione sovrascrive eventuali modifiche apportate direttamente alle risorse personalizzate di networking nel cluster utente. Le risorse personalizzate di networking devono essere modificate solo nel cluster di amministrazione, ma i cluster della versione 1.12.x non applicano questo requisito.

    Le funzionalità di networking avanzate, come il bilanciamento del carico in bundle con BGP, il gateway NAT in uscita, il networking SR-IOV, la modalità flat con BGP e multi-NIC per i pod utilizzano le seguenti risorse personalizzate:

    • BGPLoadBalancer
    • BGPPeer
    • NetworkGatewayGroup
    • NetworkAttachmentDefinition
    • ClusterCIDRConfig
    • FlatIPMode

    Puoi modificare queste risorse personalizzate nel cluster di amministrazione e il passaggio di riconciliazione applica le modifiche ai cluster utente.


    Soluzione alternativa

    Se hai modificato una qualsiasi delle risorse personalizzate menzionate in precedenza su un cluster utente, modifica le risorse personalizzate corrispondenti sul cluster di amministrazione in modo che corrispondano prima di eseguire l'upgrade. Questo passaggio garantisce che le modifiche alla configurazione vengano mantenute. Le versioni 1.13.0 e successive dei cluster Google Distributed Cloud non ti consentono di modificare direttamente le risorse personalizzate di networking sui tuoi cluster utente.

    Networking 1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16 e 1,28

    Errori di connettività dei pod e filtro del percorso inverso

    Google Distributed Cloud configura il filtro del percorso inverso sui nodi per disabilitare la convalida dell'origine (net.ipv4.conf.all.rp_filter=0). Se l'impostazione rp_filter viene modificata in 1 o 2, i pod avranno esito negativo a causa di timeout delle comunicazioni fuori nodo.

    Il filtro del percorso inverso è impostato su rp_filter nella cartella di configurazione IPv4 (net/ipv4/conf/all). Questo valore può anche essere sostituito da sysctl, che archivia le impostazioni di filtro del percorso inverso in un file di configurazione della sicurezza di rete, come /etc/sysctl.d/60-gce-network-security.conf.


    Soluzione alternativa

    Puoi ripristinare la connettività dei pod eseguendo una delle seguenti soluzioni alternative:

    Imposta di nuovo il valore per net.ipv4.conf.all.rp_filter su 0 manualmente, quindi esegui sudo sysctl -p per applicare la modifica.

    Oppure

    Riavvia il pod anetd per reimpostare net.ipv4.conf.all.rp_filter su 0. Per riavviare il pod anetd, utilizza i seguenti comandi per individuare ed eliminare il pod anetd e al suo posto verrà avviato un nuovo pod anetd:

    kubectl get pods -n kube-system kubectl delete pods -n kube-system ANETD_XYZ
    

    Sostituisci ANETD_XYZ con il nome del pod anetd.

    Dopo aver eseguito una delle due soluzioni alternative, verifica che il valore net.ipv4.conf.all.rp_filter sia impostato su 0 eseguendo sysctl net.ipv4.conf.all.rp_filter su ciascun nodo.

    Networking 1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16, 1,28 e 1,29

    Indirizzi IP del cluster di bootstrap (kind) e indirizzi IP dei nodi cluster che si sovrappongono

    192.168.122.0/24 e 10.96.0.0/27 sono i CIDR predefiniti di pod e servizi utilizzati dal cluster di bootstrap (kind). I controlli preflight non andranno a buon fine se si sovrappongono agli indirizzi IP delle macchine dei nodi cluster.


    Soluzione alternativa

    Per evitare il conflitto, puoi passare i flag --bootstrap-cluster-pod-cidr e --bootstrap-cluster-service-cidr a bmctl per specificare valori diversi.

    Sistema operativo 1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16 e 1,28

    La creazione o l'upgrade del cluster non riesce su CentOS

    A dicembre 2020, la community di CentOS e Red Hat hanno annunciato il ritiro di CentOS. Il 31 gennaio 2022 CentOS 8 ha raggiunto la fine del ciclo di vita. A causa dell'EOL, yum repository hanno smesso di funzionare per CentOS, il che causa la mancata riuscita delle operazioni di creazione e upgrade del cluster. Questo vale per tutte le versioni supportate di CentOS e interessa tutte le versioni dei cluster Google Distributed Cloud.


    Soluzione alternativa

    Sicurezza 1,10, 1,11, 1,12, 1,13, 1,14, 1,15, 1,16 e 1,28

    Il container non può scrivere in VOLUME definito in Dockerfile con containerd e SELinux

    Se utilizzi containerd come runtime dei container e SELinux nel sistema operativo è abilitato, il valore VOLUME definito nel Dockerfile dell'applicazione potrebbe non essere scrivibile. Ad esempio, i container creati con il seguente Dockerfile non sono in grado di scrivere nella cartella /tmp.

    FROM ubuntu:20.04 RUN chmod -R 777 /tmp VOLUME /tmp
    

    Per verificare se hai riscontrato questo problema, esegui questo comando sul nodo che ospita il container problematico:

    ausearch -m avc
    

    Se hai riscontrato questo problema, viene visualizzato un errore denied come il seguente:

    time->Mon Apr  4 21:01:32 2022 type=PROCTITLE msg=audit(1649106092.768:10979): proctitle="bash" type=SYSCALL msg=audit(1649106092.768:10979): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=55eeba72b320 a2=241 a3=1b6 items=0 ppid=75712 pid=76042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm="bash" exe="/usr/bin/bash" subj=system_u:system_r:container_t:s0:c701,c935 key=(null) type=AVC msg=audit(1649106092.768:10979): avc:  denied { write } for  pid=76042 comm="bash" name="aca03d7bb8de23c725a86cb9f50945664cb338dfe6ac19ed0036c" dev="sda2" ino=369501097 scontext=system_u:system_r: container_t:s0:c701,c935 tcontext=system_u:object_r: container_ro_file_t:s0 tclass=dir permissive=0
    

    Soluzione alternativa

    Per risolvere il problema, apporta una delle seguenti modifiche:

    • Disattiva SELinux.
    • Non utilizzare la funzionalità VOLUME in Dockerfile.
    Upgrade e aggiornamenti 1,10, 1,11 e 1,12

    Il rilevatore di problemi con i nodi non viene abilitato per impostazione predefinita dopo gli upgrade del cluster

    Quando esegui l'upgrade dei cluster Google Distributed Cloud, il rilevatore di problemi dei nodi non è abilitato per impostazione predefinita. Questo problema riguarda gli upgrade dalla release 1.10 alla 1.12.1 ed è stato risolto nella release 1.12.2.


    Soluzione:

    Per abilitare il rilevatore di problemi dei nodi:

    1. Verifica che il servizio node-problem-detector systemd sia in esecuzione sul nodo.
      1. Utilizza il comando SSH e connettiti al nodo.
      2. Controlla se il servizio node-problem-detector systemd è in esecuzione sul nodo:
        systemctl is-active node-problem-detector
        
        Se il risultato del comando mostra inactive, significa che il rilevatore di problemi del nodo non è in esecuzione sul nodo.
    2. Per abilitare il rilevatore di problemi dei nodi, utilizza il comando kubectl edit e modifica il ConfigMap node-problem-detector-config. Per maggiori informazioni, consulta Rilevamento dei problemi dei nodi.
    Operazione 1,9, 1,10

    Il backup del cluster non riesce quando si utilizza un accesso non root

    Il comando bmctl backup cluster non riesce se nodeAccess.loginUser è impostato su un nome utente non root.]


    Soluzione:

    Questo problema si applica alle versioni 1.9.x, 1.10.0 e 1.10.1 ed è stato risolto nella versione 1.10.2 e successive.

    Networking 1,10, 1,11 e 1,12

    I servizi del bilanciatore del carico non funzionano con i container sulla rete host del piano di controllo

    In anetd esiste un bug per cui i pacchetti vengono eliminati per i servizi LoadBalancer se i pod di backend sono entrambi in esecuzione sul nodo del piano di controllo e utilizzano il campo hostNetwork: true nella specifica del container.

    Il bug non è presente nella versione 1.13 o successive.


    Soluzione:

    Le seguenti soluzioni alternative possono essere utili se utilizzi un servizio LoadBalancer supportato dai pod hostNetwork:

    1. Eseguile sui nodi worker (non sui nodi del piano di controllo).
    2. Utilizza externalTrafficPolicy: local nella specifica del servizio e assicurati che i tuoi carichi di lavoro vengano eseguiti sui nodi del bilanciatore del carico.
    Upgrade e aggiornamenti 1,12, 1,13

    Il pod anthos-version-$version$ orfano non riesce a eseguire il pull dell'immagine

    L'upgrade del cluster da 1.12.x a 1.13.x potrebbe osservare un pod anthos-version-$version$ non riuscito con errore ImagePullBackOff. Ciò accade perché viene eseguito l'upgrade della race condition di anthos-cluster-operator e non dovrebbe influire sulle normali funzionalità del cluster.

    Il bug non è presente dopo la versione 1.13 o successive.


    Soluzione:

    Elimina il job del programma di installazione dinamico della versione entro il giorno kubectl delete job anthos-version-$version$ -n kube-system

    Upgrade e aggiornamenti 1,13

    Non è possibile eseguire l'upgrade dei cluster 1.12 dalla versione 1.11 alla versione 1.13.0

    Non è possibile eseguire l'upgrade dei cluster della versione 1.12 dalla versione 1.11 alla versione 1.13.0. Questo problema di upgrade non si applica ai cluster creati con la versione 1.12.

    Per determinare se il problema ti riguarda, controlla i log del job di upgrade che contiene la stringa upgrade-first-no* nel cluster di amministrazione. Se viene visualizzato il seguente messaggio di errore, significa che sei interessato.

    TASK [kubeadm_upgrade_apply : Run kubeadm upgrade apply] *******
    ...
    [upgrade/config] FATAL: featureGates: Invalid value: map[string]bool{\"IPv6DualStack\":false}: IPv6DualStack isn't a valid feature name.
    ...
    

    Soluzione:

    Per aggirare il problema:

    1. Esegui i comandi seguenti sulla workstation di amministrazione:
      echo '[{ "op": "remove", "path": \
          "/spec/clusterConfiguration/featureGates" }]' \
          > remove-feature-gates.patch
      export KUBECONFIG=$ADMIN_KUBECONFIG
      kubectl get kubeadmconfig -A --no-headers | xargs -L1 bash -c \
          'kubectl patch kubeadmconfig $1 -n $0 --type json \
          --patch-file remove-feature-gates.patch'
      
    2. Riprova l'upgrade del cluster.
    Logging e Monitoring 1.16.2, 1.16.3

    Utilizzo elevato della CPU per stackdriver-operator

    Si è verificato un problema in stackdriver-operator che causa un consumo di tempo di CPU più elevato del normale. L'utilizzo normale della CPU è inferiore a 50 milliCPU (50m) per stackdriver-operator in stato inattivo. La causa è una mancata corrispondenza delle risorse dei certificati che stackdriver-operator applica con le aspettative di cert-manager. Questa mancata corrispondenza causa una race condition tra cert-manager e stackdriver-operator nell'aggiornamento di queste risorse.

    Questo problema potrebbe comportare una riduzione delle prestazioni sui cluster con disponibilità della CPU limitata.


    Soluzione:

    Finché non potrai eseguire l'upgrade a una versione che ha corretto il bug, utilizza la seguente soluzione alternativa:

    1. Per fare lo scale down temporaneo di stackdriver-operator a 0 repliche, applica una risorsa personalizzata AddonConfiguration:
      kubectl scale deploy stackdriver-operator --replicas=0
      
    2. Dopo aver eseguito l'upgrade a una versione che risolve il problema, esegui di nuovo il backup di stackdriver-operator:
      kubectl scale deploy stackdriver-operator --replicas=1
      
    Logging e Monitoring 1.16.0, 1.16.1

    Lo scraping delle metriche basate sulle annotazioni non funziona

    Nella release secondaria Google Distributed Cloud 1.16, il campo enableStackdriverForApplications nella specifica della risorsa personalizzata stackdriver è deprecato. Questo campo è sostituito da due campi, enableCloudLoggingForApplications e enableGMPForApplications, nella risorsa personalizzata Stackdriver.

    Ti consigliamo di utilizzare Google Cloud Managed Service per Prometheus per monitorare i carichi di lavoro. Utilizza il campo enableGMPForApplications per abilitare questa funzionalità.

    Se ti affidi alla raccolta di metriche attivata dalle annotazioni prometheus.io/scrape sui tuoi carichi di lavoro, puoi utilizzare il flag di gate delle funzionalità annotationBasedApplicationMetrics per mantenere il comportamento precedente. Tuttavia, esiste un problema che impedisce a annotationBasedApplicationMetrics di funzionare correttamente, impedendo la raccolta delle metriche dalle applicazioni in Cloud Monitoring.


    Soluzione:

    Per risolvere questo problema, esegui l'upgrade del cluster alla versione 1.16.2 o successiva.

    La raccolta delle metriche dei carichi di lavoro basata sulle annotazioni abilitata dalla porta delle funzionalità annotationBasedApplicationMetrics raccoglie le metriche per gli oggetti che hanno l'annotazione prometheus.io/scrape. Molti sistemi software con origini open source potrebbero utilizzare questa annotazione. Se continui a utilizzare questo metodo di raccolta delle metriche, tieni presente questa dipendenza, in modo da non essere sorpresi dagli addebiti delle metriche in Cloud Monitoring.

    Se hai bisogno di ulteriore aiuto, contatta l'assistenza clienti Google Cloud.