Versione 1.6. Questa versione non è più supportata. Per ulteriori informazioni, consulta le norme relative all'assistenza per le versioni. Per informazioni su come eseguire l'upgrade alla versione 1.7, consulta la pagina relativa all'upgrade di Anthos su Bare Metal nella documentazione della versione 1.7.

Versioni supportate disponibili: 1.14 | 1.13 | 1.12

Cluster Anthos su problemi noti di Bare Metal

Installazione

Incompatibilità del gruppo di controllo v2

Gruppo di controllo v2 (cgruppo v2) non è compatibile con i cluster Anthos su Bare Metal 1.6. Kubernetes 1.18 non supporta cgroup v2. Inoltre, Docker offre solo un supporto sperimentale a partire dalla versione 20.10. systemd è passato a cgroup v2 per impostazione predefinita nella versione 247.2-2. La presenza di /sys/fs/cgroup/cgroup.controllers indica che il tuo sistema utilizza cgroup v2.

A partire dai cluster Anthos su Bare Metal 1.6.2, i controlli preliminari indicano che cgroup v2 non è in uso sulla macchina del cluster.

Messaggi di errore innocui durante l'installazione

Durante l'installazione del cluster ad alta disponibilità, potresti notare errori in etcdserver leader change. Questi messaggi di errore sono innocui e possono essere ignorati.

Quando utilizzi bmctl per l'installazione del cluster, potresti vedere un messaggio di log Log streamer failed to get BareMetalMachine alla fine di create-cluster.log. Questo messaggio di errore è innocuo e può essere ignorato.

Durante l'esame dei log di creazione dei cluster, potresti notare errori temporanei nella registrazione dei cluster o delle chiamate ai webhook. Questi errori possono essere ignorati in modo sicuro perché l'installazione tenterà nuovamente queste operazioni finché non andranno a buon fine.

Controlli preliminari e credenziali dell'account di servizio

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

Credenziali predefinite dell'applicazione e `bmctl`

bmctl utilizza le credenziali predefinite dell'applicazione (ADC) per convalidare il valore della località dell'operazione del cluster in cluster spec se non è impostato su global.

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 il file eseguibile Docker è presente nella variabile di ambiente PATH, ma il servizio Docker non è attivo, il controllo preliminare non avrà esito positivo e indicherà che Docker service is not active. Per correggere questo errore, rimuovi Docker o abilita il servizio Docker.

Upgrade e aggiornamenti

L'upgrade non è disponibile nei cluster Anthos sulle release Bare Metal 1.6.x.

`bmctl update cluster` non riesce se la directory `.manifests` risulta mancante

Se la directory .manifests viene rimossa prima di eseguire bmctl update cluster, il comando restituisce un errore simile al seguente:

Error updating cluster resources.: failed to get CRD file .manifests/1.9.0/cluster-operator/base/crd/bases/baremetal.cluster.gke.io_clusters.yaml: open .manifests/1.9.0/cluster-operator/base/crd/bases/baremetal.cluster.gke.io_clusters.yaml: no such file or directory

Puoi risolvere il problema eseguendo prima bmctl check cluster, in modo da ricreare la directory .manifests.

Questo problema si applica ai cluster Anthos su Bare Metal 1.10 e versioni precedenti ed è stato risolto nella versione 1.11 e successive.

`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. Per ulteriori informazioni, incluse le istruzioni per rimuovere i nodi dalla modalità di manutenzione, vedi Mettere i nodi in modalità di manutenzione.

Operazione

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. La sovrascrittura del file causa l'errore delle operazioni standard del cluster, come l'aggiornamento e l'upgrade, per i cluster utente interessati. Questo problema si applica ai cluster Anthos sulle versioni 1.11.1 e precedenti di Bare Metal.

Per determinare se un cluster utente è interessato dal problema, esegui il comando seguente:

kubectl --kubeconfig ADMIN_KUBECONFIG get secret -n cluster-USER_CLUSTER_NAME \
    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_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, il cluster utente specificato è interessato.

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-aed78cdeca81874
    user: ci-aed78cdeca81874-admin
  name: ci-aed78cdeca81874-admin@ci-aed78cdeca81874
current-context: ci-aed78cdeca81874-admin@ci-aed78cdeca81874
kind: Config
preferences: {}
users:
- name: ci-aed78cdeca81874-admin
  user:
    client-certificate-data: LS0tLS1CRU...UtLS0tLQo=
    client-key-data: LS0tLS1CRU...0tLS0tCg==

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

Individua il file kubeconfig del cluster utente.

Quando crei un cluster, Cluster Anthos su Bare Metal genera il file kubeconfig sulla workstation di amministrazione. Per impostazione predefinita, il file si trova nella directory bmctl-workspace/USER_CLUSTER_NAME.
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.
Esegui questo comando per eliminare il file kubeconfig danneggiato nel cluster di amministrazione:
```
kubectl delete secret -n USER_CLUSTER_NAMESPACE USER_CLUSTER_NAME-kubeconfig
```

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

Reimposta/eliminazione

Credenziali cluster utente

Il comando bmctl reset si basa sulla sezione delle credenziali di primo livello nel file di configurazione del cluster. Per i cluster utente dovrai aggiornare manualmente il file per aggiungere la sezione delle credenziali.

Punti di montaggio e `fstab`

Il ripristino non smonta i punti di montaggio sotto /mnt/anthos-system e /mnt/localpv-share/. Non rimuove inoltre le voci corrispondenti in /etc/fstab.

Eliminazione dello spazio dei nomi

L'eliminazione di uno spazio dei nomi impedirà la creazione di nuove risorse in quello spazio dei nomi, inclusi i job per reimpostare le macchine. Quando elimini un cluster utente, devi prima eliminare l'oggetto cluster prima di eliminare il relativo spazio dei nomi. In caso contrario, non sarà possibile creare i job di ripristino delle macchine e il processo di eliminazione salta il passaggio di pulizia della macchina.

Sicurezza

La CA/certificato del cluster verrà ruotata durante l'upgrade. Il supporto della rotazione on demand non è attualmente disponibile.

I cluster Anthos su Bare Metal ruotano automaticamente i certificati di gestione di kubelet. Ogni agente nodo kubelet può inviare una richiesta di firma del certificato (CSR) quando un certificato è prossimo alla scadenza. Un controller nei cluster di amministrazione convalida e approva la richiesta di firma del certificato.

Networking

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 del 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 dell'origine client. Con questa impostazione, tuttavia, Kubernetes gestisce solo il traffico locale dei nodi.

Se vuoi conservare l'indirizzo IP dell'origine client, potrebbe essere necessaria una configurazione aggiuntiva per assicurarti che gli IP dei servizi siano raggiungibili. Per informazioni dettagliate sulla configurazione, consulta Conservare l'indirizzo IP dell'origine client in Configurare il bilanciamento del carico in bundle.

Errori di connettività dei pod e filtro del percorso inverso

I cluster Anthos su Bare Metal configurano un 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 non andranno a buon fine a causa dei timeout per le comunicazioni fuori nodo.

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

Per ripristinare la connettività del pod, reimposta net.ipv4.conf.all.rp_filter manualmente su 0 o riavvia il pod anetd per ripristinare net.ipv4.conf.all.rp_filter su 0. Per riavviare il pod anetd, utilizza i comandi seguenti per individuare ed eliminare il pod anetd, al suo avvio 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 sovrapposti

192.168.122.0/24 e 10.96.0.0/27 sono i CIDR predefiniti del pod e del servizio utilizzati dal cluster bootstrap (tipo). I controlli preliminari non andranno a buon fine se si sovrappongono con gli indirizzi IP delle macchine dei nodi del cluster. Per evitare il conflitto, puoi trasmettere i flag --bootstrap-cluster-pod-cidr e --bootstrap-cluster-service-cidr a bmctl per specificare valori diversi.

Indirizzi IP sovrapposti tra cluster diversi

Non esiste un controllo preliminare per convalidare gli indirizzi IP sovrapposti tra cluster diversi.

Funzionalità `hostport` nei cluster Anthos su Bare Metal

La funzione hostport in ContainerPort non è attualmente supportata.

Sistema operativo

Creazione o upgrade del cluster non riuscito su CentOS

Nel 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). In seguito all'EOL, i repository yum hanno smesso di funzionare per CentOS, causando errori delle operazioni di creazione dei cluster e upgrade dei cluster. Si applica a tutte le versioni supportate di CentOS e influisce su tutte le versioni di cluster Anthos su Bare Metal.

Per risolvere il problema, esegui i comandi seguenti per fare in modo che CentOS utilizzi un feed di archivio:

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-*

Come soluzione a lungo termine, valuta la possibilità di eseguire la migrazione a un altro sistema operativo supportato, ad esempio Ubuntu o RHEL.

Limiti degli endpoint per i sistemi operativi

Su RHEL e CentOS, è previsto un limite a livello di cluster di 100.000 endpoint. Kubernetes Service. 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.

Configurazione

Specifiche del piano di controllo e del bilanciatore del carico

Le specifiche dei pool di nodi del piano di controllo e del bilanciatore del carico sono speciali. Queste specifiche dichiarano e controllano le risorse fondamentali del cluster. L'origine canonica per queste risorse è le rispettive sezioni nel file di configurazione del cluster:

spec.controlPlane.nodePoolSpec
spec.LoadBalancer.nodePoolSpec

Di conseguenza, non modificare direttamente le risorse del pool di nodi del piano di controllo e del bilanciatore del carico di primo livello. Modifica le sezioni associate nel file di configurazione del cluster.

Campi modificabili nella specifica del pool e dei nodi del cluster

Attualmente, solo i seguenti campi di specifiche per cluster e pool di nodi nel file di configurazione del cluster possono essere aggiornati dopo la creazione del cluster (sono campi modificabili):

Per l'oggetto Cluster (kind: Cluster), è possibile modificare i seguenti campi:
- spec.anthosBareMetalVersion
- spec.bypassPreflightCheck
- spec.controlPlane.nodePoolSpec.nodes
- spec.loadBalancer.nodePoolSpec.nodes
- spec.maintenanceBlocks
- spec.nodeAccess.loginUser
Per l'oggetto NodePool (kind: NodePool), è possibile modificare i seguenti campi:
- spec.nodes

Il nodo mostra lo stato `NotReady`

In determinate condizioni di carico, i cluster Anthos sui nodi 1.6.x Bare Metal potrebbero visualizzare uno stato NotReady a causa dell'integrità dello strumento di generazione di eventi del ciclo di vita dei pod (PLEG). Lo stato del nodo conterrà la seguente voce:

PLEG is not healthy: pleg was last seen active XXXmXXXs ago; threshold is 3m0s

Come faccio a sapere se il problema mi interessa?

Una causa probabile di questo problema è la versione binaria runc. Per verificare se hai installato la versione problematica, connettiti a una delle macchine dei cluster utilizzando SSH ed esegui:

/usr/bin/runc -v

Se l'output è 1.0.0-rc93, significa che hai installato la versione problematica.

Possibili soluzioni alternative

Per risolvere il problema, ti consigliamo di eseguire l'upgrade ai cluster Anthos su Bare Metal 1.7.0 o su una versione successiva.

Se l'upgrade non è un'opzione, puoi ripristinare una versione precedente del pacchetto containerd.io sulle macchine dei nodi problematiche. Per farlo, connettiti alla macchina nodo utilizzando SSH ed esegui:

Ubuntu

apt install containerd.io=1.4.3-1

CentOS/RHEL

dnf install containerd.io-1.3.9-3.1.el8.