Problemi noti di Anthos clusters on bare metal

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

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

tar -xzvf 

Soluzione

Verifica se il metadata.json è presente e se il valore di bmctlVersion è 1,9.x. Se metadata.json non è presente, esegui l'upgrade al cluster 1.10.x e utilizza bmctl 1.10.x per eseguire il backup/il ripristino.

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

Quando esegui il deployment di un cluster a doppio stack (un cluster con indirizzi IPv4 e IPv6), i pod ipam-controller-manager potrebbero arrestarsi in modo anomalo. Questo comportamento fa sì che i nodi passino da uno stato all'altro tra Ready e NotReady e potrebbe causare un errore di installazione del cluster. Questo problema può verificarsi quando il server API è sotto carico elevato.

Per verificare se questo problema ti riguarda, controlla se i pod ipam-controller-manager non funzionano con gli 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 dettagli per il nodo in stato NotReady:

kubectl describe node  | 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 i pod ipam-controller-manager:

kubectl -n kube-system rollout restart ds ipam-controller-manager

eccetera

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

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

Questi problemi possono rendere il cluster non funzionale.

Questo problema è stato risolto nei cluster Anthos sulle versioni bare metal 1.12.9, 1.13.6, 1.14.3 e successive. Queste release più recenti utilizzano la versione 3.4.21 di etcd. Tutte le versioni precedenti di Anthos clusters on bare metal sono interessate da questo problema.

Soluzione

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

Per visualizzare questa metrica in Metrics Explorer:

1. Vai a Metrics Explorer nella console Google Cloud:

   Vai a Metrics Explorer

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

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

Il 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 controllare.

Soluzione:

Se lo stato dell'oggetto SriovNetworkNodeState è "Non riuscito", aggiorna i cluster Anthos su Bare Metal versione 1.11.7 o successiva o 1.12.4 o successiva.

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

Al termine dell'upgrade, la condizione di alcuni nodi worker potrebbe essere impostata su false. Nella risorsa nodo, 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

Riavvia il pod anetd del nodo eliminandolo.

Più rotazioni del certificato provenienti dal gestore di certificati generano incoerenze

Dopo più rotazioni manuali o automatiche dei certificati, il pod webhook, ad esempio 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 nei seguenti casi:

• Se hai eseguito due rotazioni del certificato manuali con gestione dei certificati su un cluster più vecchio di 180 giorni e non hai mai riavviato l'operatore cluster anthos-cluster.
• Se hai eseguito un cert-manager manuale di rotazioni del certificato su un cluster più vecchio di 90 giorni e non hai mai riavviato l'operatore cluster anthos-cluster.

Soluzione

Riavvia il pod terminando l'operatore anthos-cluster.

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

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

Questo problema è stato risolto nella versione 1.14.1.

Soluzione:

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

1. Elenca le risorse del controllo preliminare:

   kubectl get preflightchecks --kubeconfig ADMIN_KUBECONFIG -A
          

   L'output ha 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 comandi seguenti:

   kubectl delete preflightchecks ci-87a021b9dcbb31c \
       -n cluster-ci-87a021b9dcbb31c \
       --kubeconfig ADMIN_KUBECONFIG
   kubectl delete preflightchecks ci-87a021b9dcbb31cd6jv6 \
       -n cluster-ci-87a021b9dcbb31c \
       --kubeconfig ADMIN_KUBECONFIG

Lo stato di BGPSession cambia continuamente a causa del numero elevato di route in entrata

I cluster Anthos su una rete avanzata bare metal non riescono a gestire correttamente le sessioni BGP quando i peer esterni pubblicizzano un numero elevato 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à fa sì che la sessione venga eliminata per inattività.

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

• Eliminazione e ricreazione continua di bgpsession.
• bgpsession.status.state non diventa mai Established
• Route che non pubblicizzano o vengono ripetutamente pubblicizzati e ritirate.

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

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

Per determinare se i problemi 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 stato "Non stabilito" e l'ultimo tempo del report conta continuamente fino a circa 10-12 secondi prima che venga reimpostato su zero.
• L'output di kubectl get bgpsessions indica che le sessioni interessate vengono ricreate ripetutamente:

  kubectl get bgpsessions -o jsonpath="{.items[*]['metadata.name', 'metadata.creationTimestamp']}"

• I messaggi di log indicano che le sessioni BGP inattive sono in fase di eliminazione:

  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.

Nei Anthos clusters on bare metal 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.

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

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

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

sudo conntrack -S

La risposta ha il seguente aspetto:

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

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

Soluzione

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

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

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

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 causa un errore nel ripristino dei backup dei cluster con le versioni identificate. Questo problema riguarda in modo specifico 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:

NetworkGatewayGroup si arresta in modo anomalo se non sono presenti indirizzi IP nell'interfaccia

NetworkGatewayGroup non riesce a creare daemon per i nodi che non dispongono di interfacce IPv4 e IPv6. In questo modo si verificano errori in funzionalità come Bilanciatore del carico BGP e NANA in uscita. Se controlli i log del pod ang-node in errore nello spazio dei nomi kube-system, vengono visualizzati errori simili al seguente esempio 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 di ens192. Gli 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 tuo nodo, ad esempio ens192.
• ADDRESS: indirizzo IP e subnet mask da applicare all'interfaccia.

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 tutte le altre operazioni.

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 fisse.

Per risolvere il problema, 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.

kubeadm join non riesce in cluster di grandi dimensioni a causa di una mancata corrispondenza del token

Quando installi Anthos clusters on bare metal con un numero elevato di nodi, potresti visualizzare un messaggio di errore kubeadmin join simile al seguente esempio:

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:

Questo problema è stato risolto nei cluster Anthos su Bare Metal versione 1.13.4 e successive.

Se devi utilizzare una versione interessata, per prima cosa crea un cluster con meno di 20 nodi, quindi ridimensiona il cluster per aggiungere altri nodi al termine dell'installazione.

Limite di CPU basso per metrics-server nei cluster perimetrali

Nei cluster Anthos su cluster Edge bare metal, i limiti di CPU bassi per metrics-server possono causare frequenti riavvii di metrics-server. La scalabilità automatica pod orizzontale (HPA) non funziona perché metrics-server è in stato non integro.

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

• Cluster Anthos su Bare Metal versione 1.x-1.12:

  kubectl get deployment metrics-server -n kube-system \
    -o yaml > metrics-server.yaml

• Cluster Anthos su Bare Metal versione 1.13 o versioni successive:

  kubectl get deployment metrics-server -n gke-managed-metrics-server \
    -o yaml > metrics-server.yaml

Soluzione:

Questo problema è stato risolto in Anthos clusters on bare metal versione 1.13.1 o successive. Per risolvere il problema, esegui l'upgrade dei cluster.

Una soluzione alternativa a breve termine fino a quando non potrai eseguire l'upgrade dei cluster è aumentare manualmente i limiti di CPU per metrics-server come segue:

1. Scale down metrics-server-operator:

   kubectl  scale deploy metrics-server-operator --replicas=0

2. Aggiorna la configurazione e aumenta i limiti di CPU:
   • Cluster Anthos su Bare Metal versione 1.x-1.12:

     kubectl -n kube-system edit deployment metrics-server

   • Cluster Anthos su Bare Metal 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><--- CPU,
   [...] Increase 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.

La connessione diretta NodePort al pod hostNetwork non funziona

La connessione a un pod abilitato con hostNetwork tramite il servizio NodePort non riesce quando il pod di backend si trova sullo stesso nodo della NodePort di destinazione. Questo problema riguarda i servizi LoadBalancer se utilizzati con pod hostNetworked. Con più backend, può 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 hostNetworked non vengano eseguiti sui nodi LoadBalancer.

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 non vanno a buon fine.

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.

Errori durante l'aggiornamento delle risorse utilizzando kubectl apply

Se aggiorni le 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 desiderate.

Ad esempio, potresti provare a modificare la risorsa personalizzata Stackdriver nel modo seguente 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. Abilitare le funzionalità o aggiornare la configurazione nel file YAML.
3. Applica di nuovo il file YAML aggiornato:

   
   kubectl apply -f stackdriver.yaml
   

Il passaggio finale per kubectl apply potrebbe essere legato a 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. Abilitare le funzionalità o aggiornare la configurazione nel file YAML.
3. Salva ed esci dall'editor

Approccio alternativo mediante kubectl patch:

1. Ottieni la definizione YAML esistente:

   kubectl get stackdriver -n kube-system stackdriver \
     -o yaml > stackdriver.yaml

2. Abilitare le funzionalità o aggiornare la configurazione nel file YAML.
3. Applica di nuovo il file YAML aggiornato:

   kubectl patch stackdriver stackdriver --type merge \
     -n kube-system --patch-file stackdriver.yaml

Pezzi di backlog danneggiati causano stackdriver-log-forwarder arresti anomali

stackdriver-log-forwarder si arresta in modo anomalo 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 di 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/ è in errore. Ogni file *.flb con un controllo di formato non riuscito deve essere rimosso.
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 ripulire tutti i blocchi di backlog, utilizza i seguenti script:
   1. Esegui il deployment di un DaemonSet per pulire tutti i dati sporchi 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 nel DaemonSet siano stati puliti tutti i nodi. L'output dei due comandi seguenti deve 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"}]'

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

In cluster multi-nic, il riavvio di Dataplane V2 (anetd) può impedire l'associazione delle macchine virtuali alle reti. Nei log dei pod anetd potrebbe essere riscontrato un errore simile al seguente:

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

Soluzione:

Puoi risolvere rapidamente il problema della VM. Per evitare la ricorrenza del problema, esegui l'upgrade ad Anthos clusters on bare metal 1.14.1 o versioni successive.

gke-metrics-agent non ha limite di memoria nei 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 Anthos su cluster di profili Edge bare metal. I cluster di profilo predefiniti non sono interessati.

Soluzione:

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

La creazione del cluster potrebbe non riuscire a causa delle condizioni della race

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

Il riconciliatore dei controlli preflight crea un elemento SecretForwarder per copiare il secret ssh-key predefinito nello spazio dei nomi di destinazione. In genere, il controllo preflight utilizza il riferimento del proprietario ed esegue la riconciliazione una volta completato il SecretForwarder. Tuttavia, in rari casi, il riferimento proprietario del SecretForwarder potrebbe perdere il riferimento al controllo preflight, provocando il blocco del controllo preflight. Di conseguenza, la creazione del cluster non riesce. Per continuare la riconciliazione per il controllo preflight basato su controller, elimina il pod operatore cluster o la risorsa controllo preflight. Quando elimini la risorsa preflight check, ne viene creata un'altra e continua la riconciliazione. In alternativa, puoi eseguire l'upgrade dei tuoi cluster esistenti, creati con una versione precedente, a una versione corretta.

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

Nella funzionalità multi-nic, se utilizzi il plug-in per la ricerca delle informazioni CNI e utilizzi l'operazione CNI DEL 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 dei pod inutilizzati eseguendo questo comando:

kubectl get ippools -A --kubeconfig KUBECONFIG_PATH

Soluzione:

Elimina manualmente gli indirizzi IP (IPpool) non utilizzati.

Rilevatore di problemi dei nodi non riuscito nel cluster utente 1.10.4

Il rilevatore di problemi sui nodi potrebbe non riuscire nei cluster utente Anthos on bare metal 1.10.x, quando i cluster Anthos su bare metal 1.11.0, 1.11.1 o 1.11.2 gestiscono i cluster utente 1.10.x. In caso di errore del rilevatore di problemi dei 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

Per risolvere il problema, esegui l'upgrade del cluster di amministrazione alla versione 1.11.3.

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

Nella versione 1.14, l'impostazione maxPodsPerNode non viene presa in considerazione per i cluster della modalità isola, quindi ai nodi viene assegnata una dimensione della maschera CIDR dei pod di 24 (256 indirizzi IP). Di conseguenza, il cluster potrebbe esaurire gli indirizzi IP dei pod prima del previsto. Ad esempio, se il cluster ha una dimensione della maschera CIDR dei pod di 22; a ogni nodo verrà assegnata una maschera CIDR dei pod di 24 e il cluster sarà in grado di supportare solo fino a 4 nodi. Il tuo cluster potrebbe anche riscontrare un'instabilità di rete in un periodo di tasso di abbandono elevato quando il valore di maxPodsPerNode è impostato su 129 o più e il sovraccarico nel CIDR del pod non è sufficiente per ogni nodo.

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

error="required IPv4 PodCIDR not available"

Soluzione

Per risolvere il problema, procedi nel seguente modo:

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 per uno per evitare tempi di inattività del cluster.

Errore di rollback dell'upgrade del cluster

Un rollback di upgrade potrebbe non riuscire per Anthos clusters on bare metal da 1.14.0 a 1.14.1. Se esegui l'upgrade di un cluster da 1.14.0 a 1.14.1 e quindi provi a eseguire il rollback a 1.14.0 utilizzando il comando bmctl restore cluster, potrebbe essere restituito un errore come il seguente esempio:

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, quindi 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 nuovamente il comando bmctl restore cluster.

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

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

Questo problema è stato risolto nella versione 1.12.1.

Soluzione:

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

Gli upgrade in loco da 1.13.0 a 1.14.x non vengono mai completati

Quando tenti di 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 viene mai completato.

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.

I cluster aggiornati a 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. Quando esegui l'upgrade dei cluster Anthos alla 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 i pod che non dovrebbero essere eseguiti sui nodi del piano di controllo potrebbero iniziare a farlo. Questi pod del carico di lavoro possono sovraccaricare i nodi del piano di controllo e portare all'instabilità del cluster.

Determinare se un problema ti riguarda

1. Trova i nodi del piano di controllo, utilizzando 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, usa il seguente comando:

   kubectl describe node NODE_NAME \
       --kubeconfig KUBECONFIG_PATH

   Se nessuna delle incompatibilità richieste è presente nell'elenco, significa che sei interessato.

Soluzione

Per ripristinare la funzione corretta, utilizza i passaggi seguenti per ciascun nodo del piano di controllo del cluster versione 1.14.0 interessato. Questi passaggi sono per l'incompatibilità di node-role.kubernetes.io/master:NoSchedule e i pod correlati. Se vuoi che i nodi del piano di controllo utilizzino l'incompatibilità PreferNoSchedule, regola i passaggi di conseguenza.

Creazione VM non riuscita a causa di errori di caricamento

La creazione di una nuova macchina virtuale (VM) con il comando "kubectl virt create vm" non riesce raramente durante il caricamento dell'immagine. Questo problema si applica sia alle VM Linux che a quelle Windows. L'errore è simile all'esempio seguente:

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

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

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 il deployment manuale dei componenti di raccolta gestita nello spazio dei nomi gmp-system dei tuoi cluster Anthos versione 1.11, le risorse associate non vengono conservate quando esegui l'upgrade alla versione 1.12.

A partire dalla versione 1.12.0 di Anthos clusters on bare metal, i componenti di Managed Service per Prometheus nello spazio dei nomi gmp-system e le relative definizioni di risorse personalizzate sono gestiti da stackdriver-operator con il campo enableGMPForApplications. Il valore del campo enableGMPForApplications è true, quindi se esegui manualmente il deployment dei componenti Managed Service per Prometheus nello spazio dei nomi prima dell'upgrade alla versione 1.12, le risorse vengono eliminate da stackdriver-operator.

Soluzione

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 tuo cluster aggiornato.

Non è possibile eseguire l'upgrade di alcuni cluster della versione 1.12 con il runtime del container Docker alla versione 1.13

Se in un cluster della versione 1.12 che utilizza il runtime del container Docker manca la seguente annotazione, non è possibile 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.

Molto probabilmente questo avviene con i cluster Docker alla versione 1.12 di cui è stato eseguito l'upgrade dalla versione 1.11, in quanto quest'ultimo non richiede l'annotazione per mantenere il runtime del container Docker. In questo caso, i cluster non hanno l'annotazione durante l'upgrade alla versione 1.13. Tieni presente che a partire dalla versione 1.13, containerd è l'unico runtime del container consentito.

Soluzione:

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

bmctl esci prima del completamento della creazione del cluster

La creazione del cluster potrebbe non riuscire per Anthos clusters on bare metal versione 1.11.0 (questo problema è stato risolto in Anthos clusters on bare metal release 1.11.1). In alcuni casi, il comando bmctl create cluster esce presto e scrive errori come il seguente nei log:

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

Soluzione

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

Errore di riconciliazione del runtime VM dei report di installazione

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

Questo errore è innocuo e puoi ignorarlo in tutta sicurezza.

Creazione del cluster non riuscita quando si utilizzano più NIC, containerd e proxy HTTPS

La creazione del cluster non riesce quando si ha la seguente combinazione di condizioni:

• Il cluster è configurato per utilizzare containerd come runtime del container (nodeConfig.containerRuntime impostato su containerd nel file di configurazione del cluster, impostazione predefinita per Anthos clusters on bare metal versione 1.12).

• Il cluster è configurato per fornire più interfacce di rete multi-NIC per i pod (clusterNetwork.multipleNetworkInterfaces impostato su true nel file di configurazione del cluster).

• Il cluster è configurato per utilizzare un proxy (spec.proxy.url è specificato nel file di configurazione del cluster). Anche se la creazione del cluster non va a buon fine, l'impostazione viene propagata quando si tenta di creare un cluster. Potresti vedere questa impostazione del proxy come variabile di ambiente HTTPS_PROXY o nella configurazione di containerd (/etc/systemd/system/containerd.service.d/09-proxy.conf).

Soluzione

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

Errore nei sistemi con l'impostazione umask restrittiva

La versione 1.10.0 di Anthos clusters on bare metal ha introdotto 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 potrebbe causare errori di installazione o upgrade sui sistemi con un'impostazione 0077 più restrittiva di umask.

Soluzione

Reimposta i nodi del piano di controllo e cambia l'impostazione di 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 sui computer del piano di controllo per l'installazione o l'upgrade.

• Rendi leggibili /etc/kubernetes e tutte le sue sottodirectory: chmod o+rx.
• Rendere tutti i file di proprietà di root sotto la directory (ricorrente) di tutto il mondo /etc/kubernetes (chmod o+r). Escludi i file di chiave privata (.key) da queste modifiche perché sono già stati creati con proprietà e autorizzazioni corrette.
• Rendi il mondo di /usr/local/etc/haproxy/haproxy.cfg leggibile.
• Rendi /usr/local/etc/bgpadvertiser/bgpadvertiser-cfg.yaml il mondo leggibile.

Incompatibilità gruppo di controllo v2

Il gruppo di controllo v2 (cgroup v2) non è supportato nelle versioni 1.13 e precedenti di Anthos clusters on bare metal. Tuttavia, la versione 1.14 supporta cgroup v2 come funzionalità di anteprima . La presenza di /sys/fs/cgroup/cgroup.controllers indica che il sistema utilizza cgroup v2.

Soluzione

Se il tuo sistema utilizza cgroup v2, esegui l'upgrade alla versione 1.14 di Anthos clusters on bare metal.

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 preliminare non verifica le credenziali dell'account di servizio Google Cloud o le relative autorizzazioni.

Credenziali predefinite dell'applicazione e bmctl

bmctl utilizza le credenziali predefinite dell'applicazione (ADC) per convalidare il valore di posizione dell'operazione del cluster in cluster spec quando non è impostato su global.

Soluzione

Affinché l'ADC funzioni, devi puntare la variabile di ambiente GOOGLE_APPLICATION_CREDENTIALS a un file delle credenziali dell'account di servizio oppure eseguire gcloud auth application-default login.

Servizio Docker

Sulle macchine dei nodi del cluster, se l'eseguibile Docker è presente nella variabile di ambiente PATH, ma il servizio Docker non è attivo, il controllo preflight non andrà a buon fine e segnalerà Docker service is not active.

Soluzione

Rimuovi Docker o abilita il servizio Docker.

Installazione su vSphere

Quando installi i cluster Anthos su Bare Metal sulle VM vSphere, devi impostare i flag tx-udp_tnl-segmentation e tx-udp_tnl-csum-segmentation su Off. Questi flag sono correlati all'offload della segmentazione hardware eseguito dal driver vSphere VMXNET3 e non funzionano con il tunnel GENEVE dei cluster Anthos su Bare Metal.

Soluzione

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

ethtool -k NET_INTFC |grep segm
...
tx-udp_tnl-segmentation: on
tx-udp_tnl-csum-segmentation: on
...

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

bmctl non può creare, aggiornare o reimpostare i cluster utente con versione inferiore

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 della versione 1.N-1.Y, anche se il cluster di amministrazione è anche alla versione 1.N.X.

Se riscontri questo problema, dovresti visualizzare i log simili a quanto segue 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 is not 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.

Gli upgrade dei cluster alla versione 1.12.1 possono bloccare

L'upgrade dei cluster alla versione 1.12.1 a volte viene eseguito in quanto 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ò non riuscire in più punti, anche durante la seconda fase dei controlli preflight.

Soluzione

Puoi controllare i log di upgrade per determinare se hai riscontrato questo problema. I log di 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

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).
...

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

systemctl restart kubelet

L'upgrade dei cluster alla versione 1.12.0 o successiva non riesce quando è abilitato Anthos VM Runtime

Nei cluster Anthos su Bare Metal versione 1.12.0, tutte le risorse relative ad Anthos VM Runtime vengono migrate allo spazio dei nomi vm-system per supportare meglio la release GA di Anthos VM Runtime. Se hai abilitato Anthos VM Runtime in un cluster 1.11.x o versioni precedenti, l'upgrade alla versione 1.12.0 o successiva non riesce se non disattivi prima Anthos VM Runtime. Se si verifica questo problema, l'operazione di upgrade segnala il seguente errore:

Failed to upgrade cluster: cluster is not 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

Per disabilitare il runtime VM di Anthos:

1. Modifica la risorsa personalizzata VMRuntime:

   kubectl edit vmruntime

2. Imposta enabled su false nelle specifiche:

   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, riattiva il runtime VM di Anthos.

Per saperne di più, consulta la pagina relativa all'utilizzo dei carichi di lavoro basati su VM.

Upgrade bloccato alle ore error during manifests operations

In alcune situazioni, gli upgrade dei cluster non vengono completati e l'interfaccia a riga di comando bmctl non risponde. Questo problema può essere causato da una risorsa aggiornata in modo errato. Per determinare se hai riscontrato questo problema 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

Soluzione

Se trovi questi errori nei log, procedi nel seguente modo:

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.

Gli upgrade sono bloccati per i cluster con funzionalità che utilizzano Anthos Network Gateway

Gli upgrade dei cluster da 1.10.x a 1.11.x non vanno a buon fine per i cluster che utilizzano il gateway NAT in uscita o il bilanciamento del carico in bundle con BGP. Entrambe le funzionalità utilizzano Anthos Network Gateway. Gli upgrade dei cluster si bloccano al messaggio della riga di comando Waiting for upgrade to complete... e gli errori dei log anthos-cluster-operator, come riportato di seguito:

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

Soluzione

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

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

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

Per ulteriori informazioni, incluse le istruzioni per la rimozione dei nodi dalla modalità di manutenzione, consulta la sezione Mettere i nodi in modalità di manutenzione.

Lo svuotamento del nodo non può iniziare quando il nodo non è raggiungibile

Il processo di svuotamento dei nodi non si avvia se il nodo è fuori dalla portata dei cluster Anthos su Bare Metal. Ad esempio, se un nodo passa alla modalità offline durante un processo di upgrade del cluster, l'upgrade potrebbe smettere di rispondere. Si tratta di un'eventualità rara.

Soluzione

Per ridurre al minimo la probabilità che si verifichi questo problema, assicurati che i nodi funzionino correttamente prima di avviare un upgrade.

containerd 1.5.13 richiede libseccomp 2.5 o versioni successive

La versione 1.12.1 di Anthos clusters on bare metal viene fornita con containerd versione 1.5.13 e questa versione di containerd richiede libseccomp 2.5 o versioni successive.

Se nel tuo sistema non è installata la versione 2.5 o successive di libseccomp, esegui l'aggiornamento prima dell'upgrade dei cluster esistenti alla versione 1.12.1. In caso contrario, potresti visualizzare errori nei pod cplb-update per i nodi del bilanciatore del carico, come i seguenti:

runc did not terminate successfully: runc: symbol lookup error: runc: undefined symbol: seccomp_notify_respond

Soluzione

Per installare la versione più recente di libseccomp in Ubuntu, esegui questo comando:

sudo apt-get install  libseccomp-dev

Per installare la versione più recente di libseccomp in CentOS o RHEL, esegui il comando seguente:

sudo dnf -y install libseccomp-devel

I nodi sono inaccessibili se non utilizzi la procedura della modalità di manutenzione

Se esegui Anthos clusters on bare metal versione 1.12.0 (anthosBareMetalVersion: 1.12.0) o versioni precedenti e utilizzi manualmente kubectl cordon su un nodo, Anthos clusters on bare metal potrebbe annullare l'esecuzione del nodo prima che sia tutto pronto per riconciliare lo stato previsto.

Soluzione

Per i cluster Anthos su Bare Metal versione 1.12.0 e precedenti, utilizza la modalità di manutenzione per cordonare e svuotare i nodi in sicurezza.

Nella versione 1.12.1 (anthosBareMetalVersion: 1.12.1) o successive, i cluster Anthos su Bare Metal non sostituiscono i nodi in modo imprevisto quando utilizzi kubectl cordon.

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

Se il tuo cluster di amministrazione utilizza la versione 1.11 e utilizza un mirror del Registro di sistema, non è possibile gestire i cluster utente che utilizzano una versione secondaria inferiore. Questo problema influisce sulle operazioni di reimpostazione, aggiornamento e upgrade sul cluster utente.

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

flag provided but not defined: -registry-mirror-host-to-endpoints

Secret kubeconfig sovrascritto

Quando viene eseguito sui cluster utente, il comando bmctl check cluster sovrascrive il cluster utente kubeconfig Secret con il cluster di amministrazione kubeconfig. La sovrascrittura del file causa errori nelle operazioni standard del cluster, come l'aggiornamento e l'upgrade, per i cluster utente interessati. Questo problema si applica ai cluster Anthos su Bare Metal versioni 1.11.1 e precedenti.

Per determinare se questo problema riguarda 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 Anthos clusters on bare metal sono i nomi dei cluster preceduti da cluster-. Ad esempio, se assegni al tuo cluster il nome test, lo spazio dei nomi predefinito è cluster-test.
• USER_CLUSTER_NAME: il nome del cluster utente da controllare.

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

user-cluster-kubeconfig  -o json  | \
    jq -r '.data.value' | base64 -d
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

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

1. Individua il file kubeconfig del cluster utente. Anthos clusters on bare metal 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 corretto kubeconfig:

   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 dettagli sui nodi per il cluster utente. Conferma che i nomi delle macchine sono corretti per il cluster.
3. Esegui il comando seguente 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

Acquisizione di uno snapshot come utente con accesso non root.

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

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

Soluzione

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

Anthos VM Runtime - Il riavvio di un pod fa sì che le VM nel pod modifichino gli indirizzi IP o perdano del tutto il proprio indirizzo IP.

Se l'indirizzo IP di una VM cambia, questo non influisce sulla connettività delle applicazioni VM esposte come servizio Kubernetes.

Soluzione

Se perdi l'indirizzo IP, devi eseguire dhclient dalla VM per acquisire un indirizzo IP per la VM.

stackdriver-log-forwarder ha [parser:cri] invalid time format log di avviso

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

[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:

Monitoraggio imprevisto della fatturazione

Per i cluster Anthos sulle versioni bare metal 1.10 e successive, alcuni clienti hanno riscontrato una fatturazione inaspettatamente elevata per Metrics volume nella pagina Fatturazione. Questo problema riguarda solo le seguenti circostanze:

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

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

Soluzione

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

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

1. Trova i pod e i servizi di origine a cui sono associati i costi fatturati indesiderati

   kubectl --kubeconfig KUBECONFIG \
     get pods -A -o yaml | grep 'prometheus.io/scrape: "true"'
   kubectl --kubeconfig KUBECONFIG get \
     services -A -o yaml | grep 'prometheus.io/scrape: "true"'

2. Rimuovi l'annotazione prometheus.io/scrap=true dal pod o servizio.

Le modifiche a metrics-server-config non vengono mantenute

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

Soluzione

Per 1.11.x, puoi creare uno script alla modifica del ConfigMap ed eseguirlo insieme ad aggiornamenti o upgrade al cluster. Per l'assistenza dalla 1.12 in poi, contatta l'assistenza.

Le metriche deprecate influiscono sulla dashboard di Cloud Monitoring

Diverse metriche Anthos sono state deprecate e, a partire dalla versione 1.11 di Anthos clusters on bare metal, non sono più raccolti dati per queste metriche deprecate. Se utilizzi queste metriche in uno qualsiasi dei criteri di avviso, non ci saranno dati per attivare la condizione di avviso.

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

Nei cluster Anthos su release Bare Metal 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 di node-cpu-usage-high.json è stato aggiornato per le versioni 1.11.0 e successive.

Soluzione

Per eseguire la migrazione alle metriche di sostituzione:

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

stackdriver-log-forwarder ha CrashloopBackOff errori

In alcune situazioni, l'agente Logging fluent-bit può bloccare blocchi di elaborazione danneggiati. Quando l'agente Logging non è in grado di aggirare 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:

Pulisci i blocchi di buffer per lo strumento di inoltro di Stackdriver.

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

1. Termina tutti i stackdriver-log-forwarder pod:

       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 vengano eliminati prima di andare al passaggio successivo.
2. Esegui il deployment del seguente DaemonSet per pulire 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 pulito 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 cluster.
4. Elimina il DaemonSet di pulizia:

   kubectl --kubeconfig KUBECONFIG -n \
       kube-system delete ds fluent-bit-cleanup

5. Riavvia i pod dello strumento di 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"}]'

Dati relativi alle metriche sconosciuti in Cloud Monitoring

I dati in Cloud Monitoring per i cluster versione 1.10.x possono contenere voci di metriche di riepilogo non pertinenti, ad esempio:

Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile

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

• apiserver_admission_step_admission_duration_seconds_summary
• go_gc_duration_seconds
• scheduler_scheduling_duration_seconds
• gkeconnect_http_request_duration_seconds_summary
• alertmanager_nflog_snapshot_duration_seconds_summary

Sebbene queste metriche del tipo di riepilogo siano nell'elenco delle metriche, al momento non sono supportate da gke-metrics-agent.

Interruzioni dell'esportazione delle metriche intermittenti

I cluster Anthos su Bare Metal potrebbero riscontrare interruzioni nella normale esportazione continua delle metriche o metriche mancanti su alcuni nodi. Se questo problema riguarda i tuoi cluster, potresti notare lacune nei dati per le seguenti metriche (come minimo):

• 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

Esegui l'upgrade dei tuoi 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 per la modifica:

   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.

Più gateway predefiniti interrompono la connettività agli endpoint esterni

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

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

ip route show

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

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

La versione 1.12.x di Anthos clusters on bare metal non ti impedisce di modificare manualmente le risorse personalizzate di networking nel tuo cluster utente. Anthos clusters on bare metal riconcilia le risorse personalizzate nei cluster utente con le risorse personalizzate nel tuo cluster di amministrazione durante gli upgrade del cluster. Questa riconciliazione sovrascrive qualsiasi modifica apportata direttamente alle risorse personalizzate di networking nel cluster utente. Le risorse personalizzate di networking devono essere modificate solo nel cluster di amministrazione, ma Anthos clusters on bare metal versione 1.12.x non applica questo requisito.

Le funzionalità di rete avanzate, come il bilanciamento del carico in bundle con BGP, il gateway NAT in uscita, il networking SR-IOV, il modalità piatta con BGP e il 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

Se hai modificato una delle risorse personalizzate precedentemente menzionate in un cluster utente, modifica le risorse personalizzate corrispondenti nel cluster di amministrazione in modo che corrispondano prima dell'upgrade. Questo passaggio garantisce che le modifiche alla configurazione vengano mantenute. I cluster Anthos su Bare Metal versioni 1.13.0 e successive impediscono la modifica diretta delle risorse personalizzate di networking sui cluster utente.

Errore NAT con troppe connessioni parallele

Per un determinato nodo nel tuo cluster, l'indirizzo IP del nodo fornisce la traduzione dell'indirizzo di rete (NAT) per i pacchetti instradati a un indirizzo esterno al cluster. Analogamente, quando i pacchetti in entrata entrano in un nodo di bilanciamento del carico configurato per l'utilizzo del bilanciamento del carico in bundle (spec.loadBalancer.mode: bundled), Network Address Translation (SNAT) di origine instrada i pacchetti all'indirizzo IP del nodo prima di essere inoltrati a un pod di backend.

L'intervallo di porte per NAT utilizzato dai cluster Anthos su Bare Metal è compreso tra 32768 e 65535. Questo intervallo limita il numero di connessioni in contemporanea a 32.767 per protocollo su quel nodo. Ogni connessione deve avere una voce nella tabella di monitoraggio. Se hai troppe connessioni di breve durata, la tabella di connessione esaurisce le porte per NAT. Un raccoglitore di rifiuti pulisce le voci inattive, ma la pulizia non è immediata.

Quando il numero di connessioni sul tuo nodo si avvicina a 32,767, inizierai a vedere i cali dei pacchetti per le connessioni che richiedono NAT.

Puoi identificare questo problema eseguendo il comando seguente sul pod anetd sul nodo problematico:

kubectl -n kube-system anetd-XXX -- hubble observe \
    --from-ip $IP --to-ip $IP -f

Dovresti visualizzare gli errori del seguente modulo:

No mapping for NAT masquerade DROPPED

Soluzione

Ridistribuisci il traffico ad altri nodi.

IP di origine client con bilanciamento del carico di livello 2 in bundle

L'impostazione del criterio del traffico esterno su Local può causare errori di routing, come No route to host per il bilanciamento del carico di livello 2 in bundle. Il criterio del traffico esterno è impostato su Cluster (externalTrafficPolicy: Cluster) per impostazione predefinita. Con questa impostazione, Kubernetes gestisce il traffico a livello di cluster. I servizi di tipo LoadBalancer o NodePort possono utilizzare externalTrafficPolicy: Local per conservare l'indirizzo IP di origine del client. Con questa impostazione, tuttavia, Kubernetes gestisce solo il traffico locale dei nodi.

Soluzione

Se vuoi conservare l'indirizzo IP di origine del client, potrebbe essere necessaria una configurazione aggiuntiva per garantire che gli IP dei servizi siano raggiungibili. Per i dettagli della configurazione, consulta Preservazione dell'indirizzo IP di origine del client in Configura il bilanciamento del carico in bundle.

La modifica di firewalld comporterà la cancellazione delle catene di criteri utilizzabili di Cilium

Quando esegui i cluster Anthos su Bare Metal con firewalld abilitato su CentOS o Red Had Enterprise Linux (RHEL), le modifiche a firewalld possono rimuovere le catene Cilium iptables sulla rete host. Le catene iptables vengono aggiunte dal pod anetd all'avvio. La perdita delle catene Cilium iptables fa sì che il pod sul nodo perda la connettività di rete all'esterno del nodo.

Le modifiche a firewalld che rimuoveranno le catene di iptables includono, a titolo esemplificativo:

• Riavvio di firewalld in corso, utilizzando systemctl
• Ricaricamento di firewalld con il client a riga di comando (firewall-cmd --reload)

Soluzione

Riavvia anetd sul nodo. Individua ed elimina il pod anetd con i comandi seguenti per riavviare anetd:

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

Sostituisci ANETD_XYZ con il nome del pod anetd.

egressSourceIP indirizzo duplicato

Quando utilizzi l'anteprima della funzionalità del gateway NAT in uscita, puoi impostare le regole di selezione del traffico che specificano un indirizzo egressSourceIP già in uso per un altro oggetto EgressNATPolicy. Ciò potrebbe causare conflitti di routing del traffico in uscita.

Soluzione

Collabora con il tuo team di sviluppo per determinare quali indirizzi IP mobili sono disponibili prima di specificare l'indirizzo egressSourceIP nella risorsa personalizzata EgressNATPolicy.

Errori di connettività dei pod e filtro del percorso inverso

Anthos clusters on bare metal 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.

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

Soluzione

Per ripristinare la connettività dei pod, imposta di nuovo net.ipv4.conf.all.rp_filter su 0 manualmente o riavvia il anetd pod per impostare di nuovo net.ipv4.conf.all.rp_filter su 0. Per riavviare il pod anetd, utilizza i comandi seguenti 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.

Indirizzi IP del cluster di avvio (tipo) e indirizzi IP del nodo del cluster che si sovrappongono

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

Soluzione

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

Incompatibilità con Ubuntu 18.04.6 sul kernel GA

I cluster Anthos su Bare Metal versioni 1.11.0 e 1.11.1 non sono compatibili con Ubuntu 18.04.6 sul kernel GA (da 4.15.0-144-generic a 4.15.0-176-generic). L'incompatibilità fa sì che l'agente di networking non sia in grado di configurare la rete del cluster con un errore "Il programma BPF è troppo grande" nei log di anetd. Potresti notare pod bloccati nello stato ContainerCreating con un errore networkPlugin cni failed to set up pod nel log eventi dei pod. Questo problema non riguarda i kernel HWE (Ubuntu Hardware Enablement)

Soluzione

Ti consigliamo di ottenere il kernel HWE e di eseguirne l'upgrade all'ultima versione HWE supportata per Ubuntu 18.04.

Creazione o upgrade del cluster non riuscito su CentOS

A dicembre 2020 la community di CentOS e Red Hat hanno annunciato il tramonto di CentOS. Il 31 gennaio 2022, CentOS 8 ha raggiunto la fine del suo ciclo di vita (EOL). A causa dell'EOL, yum repository hanno smesso di funzionare per CentOS, causando errori nella creazione dei cluster e nelle operazioni di upgrade dei cluster. Si applica a tutte le versioni supportate di CentOS e influisce su tutte le versioni di Anthos clusters on bare metal.

Soluzione

  sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-Linux-*

  sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' \
      /etc/yum.repos.d/CentOS-Linux-*
  

Limitazioni degli endpoint del sistema operativo

Su RHEL e CentOS, esiste un limite a livello di cluster di 100.000 endpoint. Servizio Kubernetes. Se 2 servizi fanno riferimento allo stesso insieme di pod, vengono conteggiati come 2 insiemi separati di endpoint. L'implementazione nftable sottostante su RHEL e CentOS causa questa limitazione; non è una limitazione intrinseca dei cluster Anthos su Bare Metal.

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

Se utilizzi containerd come runtime del container e SELinux è abilitato per il tuo sistema operativo, il 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 questo problema ti riguarda, esegui il comando seguente sul nodo che ospita il container problematico:

ausearch -m avc

Se si verifica 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

Per risolvere il problema, apporta una delle seguenti modifiche:

• Disattiva SELinux.
• Non usare la funzionalità VOLUME all'interno di Dockerfile.

Errori SELinux durante la creazione del pod

A volte la creazione dei pod non riesce quando SELinux impedisce al runtime del container di impostare le etichette sui supporti tmpfs. Questo errore è raro, ma può verificarsi quando SELinux è in modalità Enforcing e in alcuni kernel.

Per verificare che SELinux sia la causa di errori di creazione dei pod, utilizza il comando seguente per verificare la presenza di errori nei log di kubelet:

journalctl -u kubelet

Se SELinux non riesce a creare un pod, la risposta di comando contiene un errore simile al seguente:

error setting label on mount source '/var/lib/kubelet/pods/6d9466f7-d818-4658-b27c-3474bfd48c79/volumes/kubernetes.io~secret/localpv-token-bpw5x': failed to set file label on /var/lib/kubelet/pods/6d9466f7-d818-4658-b27c-3474bfd48c79/volumes/kubernetes.io~secret/localpv-token-bpw5x: permission denied

Per verificare che questo problema sia correlato all'applicazione di SELinux, esegui il comando seguente

ausearch -m avc

Questo comando ricerca negli audit log gli errori di autorizzazione della cache vettore di accesso (AVC). Il avc: denied nella seguente risposta di esempio conferma che gli errori di creazione dei pod sono correlati all'applicazione di SELinux.

type=AVC msg=audit(1627410995.808:9534): avc:  denied { associate } for pid=20660 comm="dockerd" name="/" dev="tmpfs" ino=186492 scontext=system_u:object_r: container_file_t:s0:c61,c201 tcontext=system_u: object_r:locale_t:s0 tclass=filesystem permissive=0

La causa principale di questo problema di creazione dei pod in SELinux è un bug del kernel trovato nelle seguenti immagini Linux:

• Release di Red Hat Enterprise Linux (RHEL) precedenti alla 8.3
• Rilasci CentOS precedenti alla 8.3

Soluzione

Il riavvio del computer consente di ripristinare il problema.

Per evitare errori di creazione di pod, utilizza RHEL 8.3 o versioni successive oppure CentOS 8.3 o versioni successive, perché tali versioni hanno corretto il bug del kernel.

Eliminazione dello spazio dei nomi

L'eliminazione di uno spazio dei nomi impedirà la creazione di nuove risorse al suo interno, inclusi i job per reimpostare le macchine.

Soluzione

Quando elimini un cluster utente, devi prima eliminare l'oggetto cluster prima di eliminare lo spazio dei nomi. In caso contrario, non è possibile creare i job per reimpostare le macchine e il processo di eliminazione ignorerà il passaggio di pulizia delle macchine.

servizio containerd

Il comando bmctl reset non elimina alcun file di configurazione o programmi binari containerd. Il servizio containerd systemd è in esecuzione. Il comando elimina i container che eseguono i pod pianificati per il nodo.

Il Rilevatore di problemi dei nodi non è abilitato per impostazione predefinita dopo gli upgrade dei cluster

Quando esegui l'upgrade dei cluster Anthos su Bare Metal, il Rilevatore di problemi dei nodi non è abilitato per impostazione predefinita. Questo problema è applicabile agli upgrade dalle versioni 1.10 alla 1.12.1 ed è stato risolto nella versione 1.12.2.

Soluzione:

Per abilitare il Rilevatore di problemi dei nodi:

1. Verifica se il servizio node-problem-detector systemd è in esecuzione sul nodo.
   1. Usa il comando SSH e connettiti al nodo.
   2. Verifica se il servizio node-problem-detector systemd è in esecuzione sul nodo:

      systemctl is-active node-problem-detector

      Se nel risultato del comando viene visualizzato inactive, il nodo-problem-detecter non è in esecuzione sul nodo.
2. Per abilitare il Rilevatore di problemi dei nodi, utilizza il comando kubectl edit e modifica il ConfigMap di node-problem-detector-config. Per ulteriori informazioni, consulta la pagina Rilevamento dei problemi dei nodi.

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 ai cluster Anthos su Bare Metal 1.9.x, 1.10.0 e 1.10.1 ed è stato risolto nella versione 1.10.2 e successive.

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

A anetd è presente un bug per cui i pacchetti vengono ignorati per i servizi LoadBalancer se i pod di backend sono in esecuzione sul nodo del piano di controllo e utilizzano il campo hostNetwork: true nelle specifiche 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 da pod hostNetwork:

1. Eseguili sui nodi worker (non sui nodi del piano di controllo).
2. Utilizza externalTrafficPolicy: local nelle specifiche del servizio e assicurati che i carichi di lavoro siano eseguiti su nodi del bilanciatore del carico.

Pod anphos-version-$version$ che non riesce a eseguire il pull dell'immagine

L'upgrade del cluster da 1.12.x a 1.13.x potrebbe notare un pod anthos-version-$version$ in errore con errore ImagePullBackOff. Ciò si verifica a causa dell'upgrade della race condition di anthos-cluster-operator e non dovrebbe influire sulla normale funzionalità del cluster.

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

Soluzione:

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

L'upgrade dei cluster 1.12 dalla versione 1.11 non può essere eseguito 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 alla versione 1.12.

Per determinare se ti riguarda, controlla i log del job di upgrade che contiene la stringa upgrade-first-no* nel cluster di amministrazione. Se ricevi il seguente messaggio di errore, significa che ciò ti riguarda.

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

Soluzione:

Per risolvere questo problema:

1. Esegui i comandi seguenti sulla tua 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. Tenta di nuovo l'upgrade del cluster.