Versione 1.9. 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.10, consulta la pagina relativa all'upgrade di Anthos su Bare Metal nella documentazione della versione 1.10.

Versioni supportate disponibili: 1.14 | 1.13 | 1.12

Cluster Anthos su problemi noti di 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.

Installazione

Creazione del cluster non riuscita quando si utilizzano proxy 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, l'impostazione predefinita per i cluster Anthos su Bare Metal versione 1.9).
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 l'utilizzo di un proxy (spec.proxy.url è specificato nel file di configurazione del cluster). Anche se la creazione del cluster non va a buon fine, questa impostazione viene propagata quando tenti di creare un cluster. Puoi vedere questa impostazione proxy come una variabile di ambiente HTTPS_PROXY o nella tua configurazione containerd (/etc/systemd/system/containerd.service.d/09-proxy.conf).

Come soluzione alternativa a questo problema, aggiungi i CIDR dei servizi (clusterNetwork.services.cidrBlocks) alla variabile di ambiente NO_PROXY su tutte le macchine dei nodi.

`containerRuntime` non specificato per impostazione predefinita

Nei cluster Anthos su Bare Metal 1.9.0, il valore predefinito di containerRuntime è stato aggiornato da docker a containerd nel file di configurazione del cluster generato. Se il campo containerRuntime non viene impostato o viene rimosso dal file di configurazione del cluster, containerRuntime viene impostato su docker quando crei i cluster. Il valore containerRuntime dovrebbe essere containerd per impostazione predefinita, a meno che non sia impostato esplicitamente su docker. Questo problema si applica solo alle release 1.9.0 e 1.9.1.

Per determinare quale runtime del container viene utilizzato dal cluster, segui i passaggi in Recuperare le informazioni del cluster. Verifica il valore di containerRuntime nella sezione cluster.spec.nodeConfig.

L'unico modo per modificare il runtime del container è eseguire l'upgrade dei cluster. Per scoprire di più, consulta Modificare il runtime del container.

Questo problema è stato risolto nei cluster Anthos sulla versione 1.9.2 di Bare Metal.

Incompatibilità del gruppo di controllo v2

Gruppo di controllo v2 (cgroup v2) non è ufficialmente supportato nei cluster Anthos su Bare Metal 1.9. La presenza di /sys/fs/cgroup/cgroup.controllers indica che il tuo sistema utilizza cgroup v2.

I controlli preliminari indicano che cgroup v2 non è in uso sulla macchina del cluster.

Messaggi di errore innocui durante l'installazione

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.

Controlli preliminari e autorizzazione rifiutati

Durante l'installazione, potresti visualizzare errori relativi a /bin/sh: /tmp/disks_check.sh: Permission denied. Questi messaggi di errore sono causati perché /tmp è montato con l'opzione noexec. Affinché bmctl funzioni, devi rimuovere l'opzione noexec dal punto di montaggio /tmp.

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.

Installazione su vSphere

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

Esegui il comando seguente su ciascun nodo per controllare i valori correnti di questi flag. ethtool -k NET_INTFC |grep segm ... tx-udp_tnl-segmentation: on tx-udp_tnl-csum-segmentation: on ... Sostituisci NET_INTFC con l'interfaccia di rete associata all'indirizzo IP del nodo.

A volte in RHEL 8.4, ethtool mostra che queste segnalazioni sono disattivate mentre non lo sono. Per attivare esplicitamente questi flag, disattivali e disattivali con i comandi seguenti.

ethtool -K ens192 tx-udp_tnl-segmentation on
ethtool -K ens192 tx-udp_tnl-csum-segmentation on

ethtool -K ens192 tx-udp_tnl-segmentation off
ethtool -K ens192 tx-udp_tnl-csum-segmentation off

Questa modifica del flag non viene mantenuta tra i riavvii. Configura gli script di avvio per impostare esplicitamente questi flag all'avvio del sistema.

Upgrade e aggiornamenti

`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` non può creare, aggiornare o reimpostare i cluster utente con versione precedente

L'interfaccia a riga di comando bmctl non può creare, aggiornare o reimpostare un cluster utente con una versione secondaria secondaria, 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, quando utilizzi bmctl dovresti vedere i log simili ai seguenti:

[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

Per aggirare il problema, utilizza kubectl per creare, modificare o eliminare la risorsa personalizzata del cluster utente all'interno del cluster di amministrazione.

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

Upgrade bloccato alle ore `error during manifests operations`

In alcuni casi, gli upgrade del 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 questo problema ti riguarda e per risolverlo, procedi nel seguente modo:

Controlla i log anthos-cluster-operator e cerca errori simili alle seguenti:
```
controllers/Cluster "msg"="error during manifests operations" "error"="1 error occurred:
...
{RESOURCE_NAME} is invalid: metadata.resourceVersion: Invalid value: 0x0: must be specified for an update
```
Queste voci sono un sintomo di una risorsa aggiornata in modo errato, dove {RESOURCE_NAME} è il nome della risorsa con problemi.
Se trovi questi errori nei tuoi log, utilizza kubectl edit per rimuovere l'annotazione kubectl.kubernetes.io/last-applied-configuration dalla risorsa contenuta nel messaggio di log.
Salva e applica le modifiche alla risorsa.
Riprova a eseguire l'upgrade del cluster.

Upgrade non riusciti per i cluster della versione 1.8 in modalità di manutenzione

Il tentativo di eseguire l'upgrade di un cluster della versione 1.8.x alla versione 1.9.x non riesce se una macchina nodo è stata precedentemente impostata in modalità di manutenzione. Ciò è dovuto a un'annotazione che rimane su questi nodi.

Per determinare se hai riscontrato questo problema, procedi nel seguente modo:

Ottieni la versione del cluster di cui vuoi eseguire l'upgrade eseguendo questo comando:
```
kubectl --kubeconfig ADMIN_KUBECONFIG get cluster CLUSTER_NAME  \
    -n CLUSTER_NAMESPACE --output=jsonpath="{.spec.anthosBareMetalVersion}"
```
Se il valore della versione restituita è per la release secondaria 1.8, come 1.8.3, continua. In caso contrario, il problema non riguarda la tua situazione.
Controlla se il cluster ha nodi che sono stati precedentemente messi in modalità di manutenzione eseguendo il comando seguente:
```
kubectl --kubeconfig ADMIN_KUBECONFIG get BareMetalMachines -n CLUSTER_NAMESPACE  \
    --output=jsonpath="{.items[*].metadata.annotations}"
```
Se le annotazioni restituite contengono baremetal.cluster.gke.io/maintenance-mode-duration, questo problema noto ti riguarda.

Per sbloccare l'upgrade del cluster, esegui questo comando per ciascuna macchina nodo interessata in modo da rimuovere l'annotazione baremetal.cluster.gke.io/maintenance-mode-duration:

kubectl --kubeconfig ADMIN_KUBECONFIG  annotate BareMetalMachine -n CLUSTER_NAMESPACE \
    NODE_MACHINE_NAME baremetal.cluster.gke.io/maintenance-mode-duration-

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

Limitazione per l'upgrade delle patch del cluster utente

I cluster utente gestiti da un cluster di amministrazione devono trovarsi negli stessi cluster Anthos in versione Bare Metal o di livello inferiore e in una release secondaria. Ad esempio, un cluster di amministrazione della versione 1.9.0 (anthosBareMetalVersion: 1.9.0) che gestisce i cluster utente della versione 1.8.4 è accettabile.

Una limitazione di upgrade impedisce l'upgrade dei cluster utente a una nuova patch di sicurezza quando la patch viene rilasciata dopo la versione di release utilizzata dal cluster di amministrazione. Ad esempio, se il tuo cluster di amministrazione è alla versione 1.7.2, che è stata rilasciata il 2 giugno 2021, non puoi eseguire l'upgrade dei tuoi cluster utente alla versione 1.6.4, poiché è stata rilasciata il 13 agosto 2021.

Il svuotamento del nodo non può iniziare quando il nodo è fuori dalla sua portata

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 interrompersi. Questo è un evento raro. Per ridurre al minimo la probabilità che si verifichi questo problema, assicurati che i nodi funzionino correttamente prima di avviare un upgrade.

Operazione

Il backup del cluster non riesce quando viene utilizzato l'accesso non root.

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

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.

Nodi non ignorati se non utilizzi la procedura della modalità di manutenzione

Se utilizzi manualmente kubectl cordon su un nodo, i cluster Anthos su Bare Metal potrebbero annullare l'assegnazione del nodo prima che tu sia pronto nel tentativo di riconciliare lo stato previsto. Per i cluster Anthos su Bare Metal versione 1.12.0 e precedenti, utilizza la modalità di manutenzione per accoppiare e scaricare i nodi in modo sicuro. Nella versione 1.12.1 (anthosBareMetalVersion: 1.12.1) o successive, i cluster Anthos su Bare Metal non scordano i nodi in modo imprevisto quando utilizzi kubectl cordon.

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

Acquisire uno snapshot come utente di accesso non root

Se utilizzi containerd come runtime del container, l'esecuzione dello snapshot come utente non root richiede che /usr/local/bin debba essere nel PATH dell'utente. In caso contrario, l'operazione non andrà a buon fine 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 sudo può essere diverso dal profilo root e potrebbe non contenere /usr/local/bin.

Puoi correggere questo errore aggiornando secure_path in /etc/sudoers in modo da includere /usr/local/bin. In alternativa, crea un link simbolico per crictl in un'altra directory /bin.

Runtime VM Anthos

Il riavvio di un pod fa sì che le VM nel pod modifichino gli indirizzi IP o perdano completamente l'indirizzo IP. Se l'indirizzo IP di una VM cambia, ciò non influisce sulla connettività delle applicazioni VM esposte come servizio Kubernetes. In caso di perdita dell'indirizzo IP, devi eseguire dhclient dalla VM per acquisire un indirizzo IP per la VM.

Logging e monitoraggio

Log mancanti dopo un'interruzione della rete

In alcuni casi, quando il cluster si ripristina dopo un'interruzione di rete, potresti notare che i nuovi log non vengono visualizzati in Cloud Logging. Nei log potrebbero essere visualizzati anche più messaggi, come i seguenti: stackdriver-log-forwarder:

re-schedule retry=0x7fef2acbd8d0 239 in the next 51 seconds

Per riattivare l'inoltro dei log, riavvia il pod stackdriver-log-forwarder. Se il server di forwarding viene riavviato entro 4,5 ore dall'interruzione, i log presenti nel buffer vengono inoltrati a Cloud Logging. I log più vecchi di 4,5 ore vengono eliminati.

Metriche intermittenti durante l'esportazione

I cluster Anthos su release Bare Metal 1.9.x e 1.10.x potrebbero riscontrare interruzioni nella normale esportazione continua di metriche o metriche mancanti su alcuni nodi. Se questo problema interessa 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

Per risolvere questo problema, esegui l'upgrade dei cluster alla versione 1.10.3 o successiva.

Se non riesci a eseguire l'upgrade, segui questa procedura come soluzione alternativa:

Apri la risorsa stackdriver per la modifica:

kubectl -n kube-system edit stackdriver stackdriver

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

Salva le modifiche e chiudi l'editor di testo.
Per verificare che le modifiche siano state applicate, esegui il comando seguente:
```
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.
Per impedire il ripristino delle seguenti modifiche, fai lo scale down di stackdriver-operator:
```
kubectl -n kube-system scale deploy stackdriver-operator --replicas=0
```

Apri gke-metrics-agent-conf per la modifica:

kubectl -n kube-system edit configmap gke-metrics-agent-conf

Modifica la configurazione per cambiare tutte le istanze di probe_interval: 0.1s in probe_interval: 13s:

 183     processors:
 184       disk_buffer/metrics:
 185         backend_endpoint: https://monitoring.googleapis.com:443
 186         buffer_dir: /metrics-data/nsq-metrics-metrics
 187         probe_interval: 13s
 188         retention_size_mib: 6144
 189       disk_buffer/self:
 190         backend_endpoint: https://monitoring.googleapis.com:443
 191         buffer_dir: /metrics-data/nsq-metrics-self
 192         probe_interval: 13s
 193         retention_size_mib: 200
 194       disk_buffer/uptime:
 195         backend_endpoint: https://monitoring.googleapis.com:443
 196         buffer_dir: /metrics-data/nsq-metrics-uptime
 197         probe_interval: 13s
 198         retention_size_mib: 200

Salva le modifiche e chiudi l'editor di testo.

Riavvia il set di daemon gke-metrics-agent:

kubectl -n kube-system rollout restart daemonset gke-metrics-agent

Sicurezza

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

Se utilizzi containerd come runtime dei container e il sistema operativo ha abilitato SELinux, VOLUME potrebbe essere non scrivibile nel Dockerfile dell'applicazione. 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 che crea problemi:

ausearch -m avc

Se hai riscontrato questo problema, viene visualizzato un errore denied simile al 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="ad9bc6cf14bfca03d7bb8de23c725a86cb9f50945664cb338dfe6ac19ed0036c"
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

Per risolvere il problema, apporta una delle modifiche indicate di seguito:

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

Rotazione CA del cluster (funzionalità di anteprima)

La CA/certificato del cluster verrà ruotata durante l'upgrade. Il supporto per la rotazione on demand è una funzionalità di anteprima.

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.

Dopo aver eseguito una rotazione dell'autorità di certificazione (CA) del cluster utente su un cluster, tutti i flussi di autenticazione utente non riescono. Questi errori si verificano perché la risorsa personalizzata ClientConfig utilizzata nei flussi di autenticazione non viene aggiornata con i nuovi dati della CA durante la rotazione delle CA. Se hai eseguito una rotazione di CA del cluster sul tuo cluster, controlla se il campo certificateAuthorityData in ClientConfig default dello spazio dei nomi kube-public contiene la CA del cluster meno recente.

Per risolvere manualmente il problema, aggiorna il campo certificateAuthorityData con l'attuale CA del cluster.

Errori SELinux durante la creazione dei pod

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

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

journalctl -u kubelet

Se SELinux causa il fallimento della creazione del pod, la risposta del 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 cerca nei log di controllo gli errori di autorizzazione della cache di accesso (AVC). avc: denied nella seguente risposta di esempio conferma che gli errori di creazione del 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 con SELinux è un bug del kernel trovato nelle seguenti immagini Linux:

Versioni di Red Hat Enterprise Linux (RHEL) precedenti alla 8.3
Versioni di CentOS precedenti alla 8.3

Il riavvio del computer consente di risolvere il problema.

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

Networking

Più gateway predefiniti interrompono la connettività agli endpoint esterni

La presenza di più gateway predefiniti in un nodo può causare interruzioni della connettività da un pod a endpoint esterni, come google.com.

Per determinare se questo problema ti riguarda, esegui questo comando sul nodo:

ip route show

Più istanze di default nella risposta indicano che sei interessato.

Per risolvere questo problema, assicurati che l'interfaccia gateway predefinita utilizzata per l'IP del nodo Kubernetes sia la prima nell'elenco.

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.

La modifica del firewall cancellerà le catene di criteri Cilium iptable

Quando esegui 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 iptables Cilium fa sì che il pod sul nodo perda la connettività di rete al di fuori del nodo.

Le modifiche a firewalld che rimuoveranno le catene 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)

Puoi risolvere il problema di connettività riavviando 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.

Indirizzi `egressSourceIP` duplicati

Quando utilizzi l'anteprima della funzionalità gateway NAT in uscita, è possibile impostare le regole di selezione del traffico che specificano un indirizzo egressSourceIP già in uso per un altro oggetto EgressNATPolicy. Questo potrebbe causare conflitti di routing del traffico in uscita. Coordina il tuo team di sviluppo per determinare quali indirizzi IP mobili possono essere utilizzati prima di specificare l'indirizzo egressSourceIP nella risorsa personalizzata EgressNATPolicy.

Errori di connettività dei pod a causa di timeout dei I/O e filtri 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 subiscono errori a causa di timeout delle comunicazioni fuori nodo.

Gli errori di connettività osservati che comunicano agli indirizzi IP del servizio Kubernetes sono un sintomo di questo problema. Di seguito sono riportati alcuni esempi di tipi di errori che potrebbero essere visualizzati:

Se tutti i pod di un determinato nodo non comunicano con gli indirizzi IP del servizio, il pod istiod potrebbe segnalare un errore simile al seguente:

 {"severity":"Error","timestamp":"2021-11-12T17:19:28.907001378Z",
    "message":"watch error in cluster Kubernetes: failed to list *v1.Node:
    Get \"https://172.26.0.1:443/api/v1/nodes?resourceVersion=5  34239\":
    dial tcp 172.26.0.1:443: i/o timeout"}

Per il set di daemon localpv eseguito su ogni nodo, il log potrebbe mostrare un timeout come il seguente:

 I1112 17:24:33.191654       1 main.go:128] Could not get node information
(remaining retries: 2): Get
https://172.26.0.1:443/api/v1/nodes/NODE_NAME:
dial tcp 172.26.0.1:443: i/o timeout

Il filtro del percorso inverso è impostato con file rp_filter nella cartella di configurazione IPv4 (net/ipv4/conf/all). Il comando sysctl archivia le impostazioni di filtro del percorso inverso in un file di configurazione della sicurezza di rete, ad esempio /etc/sysctl.d/60-gce-network-security.conf. Il comando sysctl può sostituire l'impostazione di filtro del percorso inverso.

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. Verrà avviato un nuovo pod anetd al suo posto:

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

Sostituisci ANETD_XYZ con il nome del pod anetd.

Per impostare net.ipv4.conf.all.rp_filter manualmente, esegui questo comando:

sysctl -w net.ipv4.conf.all.rp_filter = 0

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 è presente alcuna convalida per gli indirizzi IP sovrapposti tra cluster diversi durante l'aggiornamento. La convalida si applica solo al momento della creazione del cluster/nodo.

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.

Limiti degli endpoint per i sistemi operativi

Su RHEL e CentOS, è previsto un limite a livello di cluster di 100.000 endpoint. Questo numero è la somma di tutti i pod a cui si fa riferimento in un 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.

Reimposta/eliminazione

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.

servizio containerizzato

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