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

Versioni supportate disponibili: 1.14 | 1.13 | 1.12

Problemi noti di Cluster Anthos on bare metal

Installazione

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

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 Cluster Anthos on bare metal versione 1.8).
Il cluster è configurato per fornire più interfacce di rete, multi-NIC, per pod (spec.clusterNetwork.multipleNetworkInterfaces impostato su true nel file di configurazione del cluster).
Il cluster è configurato per l'utilizzo di un proxy (spec.proxy.url è specificato nel file di configurazione del cluster). Anche se la creazione del cluster non riesce, questa impostazione viene propagata quando tenti di creare un cluster. Potresti visualizzare questa impostazione proxy come variabile di ambiente HTTPS_PROXY o nella 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.

Incompatibilità del gruppo di controllo v2

Gruppo di controllo v2 (cgroup v2) non è compatibile con i cluster Anthos su Bare Metal 1.6. Kubernetes 1.18 non supporta cgroup v2. Inoltre, Docker offre solo 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.

I controlli preflight dimostrano che cgroup v2 non è in uso nella 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 nelle chiamate ai webhook. Questi errori possono essere ignorati, perché l'installazione riproverà queste operazioni finché non andranno a buon fine.

Controlli preflight e credenziali dell'account di servizio

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

Controlli preflight e autorizzazione negata

Durante l'installazione, potresti riscontrare errori in /bin/sh: /tmp/disks_check.sh: Permission denied. Questi messaggi di errore derivano dal montaggio di /tmp 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 nel cluster spec quando non è impostato su global.

Affinché 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.

Ubuntu 20.04 LTS e `bmctl`

Nei cluster Anthos su versioni Bare Metal precedenti alla 1.8.2, alcune distribuzioni Ubuntu 20.04 LTS con un kernel Linux più recente (incluse le immagini GCP Ubuntu 20.04 LTS sul kernel 5.8) hanno reso /proc/sys/net/netfilter/nf_conntrack_max di sola lettura negli spazi dei nomi di rete non init. Questo impedisce a bmctl di impostare le dimensioni massime della tabella di monitoraggio delle connessioni, impedendo l'avvio del cluster bootstrap. Un sintomo delle dimensioni errate della tabella è che il pod kube-proxy nel cluster bootstrap si arresta in modo anomalo come mostrato nel seguente log di errore di esempio:

kubectl logs -l k8s-app=kube-proxy -n kube-system --kubeconfig ./bmctl-workspace/.kindkubeconfig
I0624 19:05:08.009565       1 conntrack.go:100] Set sysctl 'net/netfilter/nf_conntrack_max' to 393216
F0624 19:05:08.009646       1 server.go:495] open /proc/sys/net/netfilter/nf_conntrack_max: permission denied

La soluzione alternativa consiste nell'impostare manualmente net/netfilter/nf_conntrack_max sul valore necessario nell'host: sudo sysctl net.netfilter.nf_conntrack_max=393216. Tieni presente che il valore necessario dipende dal numero di core per il nodo. Usa il comando kubectl logs riportato sopra per confermare il valore desiderato dei log kube-proxy.

Questo problema è stato risolto nei cluster Anthos su Bare Metal release 1.8.2 e successive.

Servizio Docker

Nelle 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 indicherà Docker service is not active. Per correggere questo errore, rimuovi Docker o abilita il servizio Docker.

Mirroring del registro e audit logging di Cloud

Nei cluster Anthos sulle versioni Bare Metal precedenti alla 1.8.2, nel pacchetto del mirroring del registro bmctl manca l'immagine gcr.io/anthos-baremetal-release/auditproxy:gke_master_auditproxy_20201115_RC00. Per abilitare la funzionalità Cloud Audit Logging quando utilizzi un mirroring del Registro di sistema, devi scaricare manualmente l'immagine mancante ed eseguirne il push al tuo server del Registro di sistema con i seguenti comandi:

docker pull gcr.io/anthos-baremetal-release/auditproxy:gke_master_auditproxy_20201115_RC00
docker tag gcr.io/anthos-baremetal-release/auditproxy:gke_master_auditproxy_20201115_RC00 REGISTRY_SERVER/anthos-baremetal-release/auditproxy:gke_master_auditproxy_20201115_RC00
docker push REGISTRY_SERVER/anthos-baremetal-release/auditproxy:gke_master_auditproxy_20201115_RC00

Containerd richiede `/usr/local/bin` in PATH

I cluster con il runtime containerd richiedono che /usr/local/bin si trovi nel percorso PATH dell'utente SSH per il comando kubeadm init per trovare il programma binario crictl. Se non è possibile trovare crictl, la creazione del cluster non riesce.

Se non hai eseguito l'accesso come utente root, sudo viene utilizzato per eseguire il comando kubeadm init. Il PATH sudo può essere diverso dal profilo root e potrebbe non contenere /usr/local/bin.

Correggi 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 di /bin.

A partire dalla 1.8.2, i cluster Anthos su Bare Metal aggiungono /usr/local/bin al percorso PATH durante l'esecuzione dei comandi. Tuttavia, l'esecuzione dello snapshot come utente non root conterrà comunque crictl: command not found (che può essere risolto con una soluzione alternativa descritta sopra).

Installazione su vSphere

Quando installi i 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 all'offload della segmentazione hardware effettuato dal driver vSphere VMXNET3 e non funzionano con il tunnel GENEVE dei cluster Anthos su Bare Metal.

Esegui questo comando su ciascun nodo per controllare i valori attuali per 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 questi flag sono disattivati mentre non lo sono. Per disattivare esplicitamente questi flag, attivali 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

Questo cambiamento di flag non viene mantenuto durante i riavvii. Configura gli script di avvio per impostare in modo esplicito questi flag all'avvio del sistema.

Preparazione dello flapping dei nodi

A volte i cluster potrebbero presentare un flapping dei nodi (lo stato dei nodi cambia velocemente da Ready a NotReady). Un comportamento non integro del pod del ciclo di vita dei pod (PLEG) provoca questo comportamento. Il PLEG è un modulo in kubelet,

Per verificare se un comportamento PLEG non integro sta causando questo comportamento, utilizza il seguente comando journalctl per verificare la presenza di voci di log PLEG:

journalctl -f | grep -i pleg

Le voci di log, come le seguenti, indicano che il PLEG non è integro:

...
skipping pod synchronization - PLEG is not healthy: pleg was last seen active
3m0.793469
...

Una condizione di corsa runc nota è la probabile causa del PLEG non integro. I processi runc bloccati sono un sintomo della condizione della gara. Utilizza il seguente comando per verificare lo stato del processo runc init:

ps aux | grep 'runc init'

Per risolvere questo problema:

Determina il runtime del cluster.

Prima di poter aggiornare la versione runc, devi determinare quale runtime del container viene utilizzato dal cluster. Il campo containerRuntime nel file di configurazione del cluster identifica il runtime del container utilizzato dal cluster. Se containerRuntime è impostato su containerd, il cluster utilizza il runtime containerd. Se il campo è impostato su docker o non è configurato, il cluster utilizza il runtime Docker.

Per ottenere il valore, apri il file di configurazione del cluster con il tuo editor preferito oppure, se hai accesso al cluster di amministrazione kubeconfig, esegui questo comando:
```
kubctl describe cluster CLUSTER_NAME -n CLUSTER_NAMESPACE | grep -i runtime
```
Sostituisci quanto segue:
- CLUSTER_NAME: il nome del cluster di cui eseguire il backup.
- CLUSTER_NAMESPACE: lo spazio dei nomi per il cluster. Per impostazione predefinita, gli spazi dei nomi dei cluster Anthos su Bare Metal sono il nome del cluster preceduto da cluster-.

Per installare containerd.io o docker-ce ed estrarre lo strumento a riga di comando runc più recente, esegui i comandi corrispondenti al tuo sistema operativo e al runtime del container su ogni nodo.

Ubuntu containerd

sudo apt update
sudo apt install containerd.io
# Back up current runc
cp /usr/local/sbin/runc ~/
sudo cp /usr/bin/runc /usr/local/sbin/runc
# runc version should be > 1.0.0-rc93
/usr/local/sbin/runc --version

Docker Ubuntu

sudo apt update
sudo apt install docker-ce
# Back up current runc
cp /usr/local/sbin/runc ~/
sudo cp /usr/bin/runc /usr/local/sbin/runc
# runc version should be > 1.0.0-rc93
/usr/local/sbin/runc --version

ContainerOS CentOS/RHEL

sudo dnf install containerd.io
# Back up current runc
cp /usr/local/sbin/runc ~/
sudo cp /usr/bin/runc /usr/local/sbin/runc
# runc version should be > 1.0.0-rc93
/usr/local/sbin/runc --version

Docker CentOS/RHEL

sudo dnf install docker-ce
# Back up current runc
cp /usr/local/sbin/runc ~/
sudo cp /usr/bin/runc /usr/local/sbin/runc
# runc version should be > 1.0.0-rc93
/usr/local/sbin/runc --version

Riavvia il nodo se ci sono processi runc init bloccati.

In alternativa, puoi rimuovere manualmente eventuali processi bloccati.

Upgrade e aggiornamenti

`bmctl update cluster` non riuscito se manca la directory `.manifests`

Se la directory .manifests viene rimossa prima dell'esecuzione di bmctl update cluster, il comando non riesce con 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.

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 si è verificato questo problema 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 problematica.
Se trovi questi errori nei 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 upgrade di un cluster alla versione 1.8.x alla versione 1.9.x ha esito negativo se una qualsiasi macchina del nodo è stata precedentemente messa in modalità di manutenzione. Ciò è dovuto all'annotazione che rimane presente su questi nodi.

Per determinare se si è verificato questo problema, segui questi passaggi:

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 riguarda 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 inseriti 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, significa che questo problema noto ti riguarda.

Per sbloccare l'upgrade del cluster, esegui questo comando per ogni macchina nodo interessata per 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 la rimozione dei nodi dalla modalità di manutenzione, consulta l'articolo su come mettere i nodi in modalità di manutenzione.

Gli upgrade dei cluster da 1.7.x non riescono per determinate configurazioni del bilanciatore del carico

L'upgrade dei cluster dalla versione 1.7.x alla versione 1.8.y potrebbe non riuscire per le seguenti configurazioni del bilanciatore del carico:

Bilanciatore del carico esterno configurato manualmente (loadBalancer.mode impostato su manual)
Bilanciamento del carico in bundle (loadBalancer.mode impostato su bundled) utilizzando un pool di nodi separato (vengono specificati loadBalancer.nodePoolSpec.nodes)

Un sintomo di questo errore è che il job cal-update su un nodo del piano di controllo ha esito negativo nell'attività Check apiserver health con messaggi di errore di connessione rifiutati.

Ecco un log di esempio per il job cal-update:

TASK [cal-update : Check apiserver health] *************************************
Thursday 20 January 2022  13:50:46 +0000 (0:00:00.033)       0:00:09.316 ******
FAILED - RETRYING: Check apiserver health (30 retries left).
FAILED - RETRYING: Check apiserver health (29 retries left).
FAILED - RETRYING: Check apiserver health (28 retries left).
FAILED - RETRYING: Check apiserver health (27 retries left).
FAILED - RETRYING: Check apiserver health (26 retries left).
...
FAILED - RETRYING: Check apiserver health (3 retries left).
FAILED - RETRYING: Check apiserver health (2 retries left).
FAILED - RETRYING: Check apiserver health (1 retries left).
[WARNING]: Consider using the get_url or uri module rather than running 'curl'.
If you need to use command because get_url or uri is insufficient you can add
'warn: false' to this command task or set 'command_warnings=False' in
ansible.cfg to get rid of this message.
fatal: [10.50.116.79]: FAILED! => {"attempts": 30, "changed": true, "cmd": "curl
-k https://127.0.0.1/healthz", "delta": "0:00:00.008949", "end": "2022-01-20
19:22:30.381875", "msg": "non-zero return code", "rc": 7, "start": "2022-01-20
19:22:30.372926", "stderr": "  % Total    % Received % Xferd  Average Speed
Time    Time     Time  Current\n                                 Dload  Upload
Total   Spent    Left  Speed\n\r  0     0    0     0    0     0      0      0 --
:--:-- --:--:-- --:--:--     0curl: (7) Failed to connect to 127.0.0.1 port 443:
Connection refused", "stderr_lines": ["  % Total    % Received % Xferd  Average
Speed   Time    Time     Time  Current", "                                 Dload
Upload   Total   Spent    Left  Speed", "", "  0     0    0     0    0     0
0      0 --:--:-- --:--:-- --:--:--     0curl: (7) Failed to connect to
127.0.0.1 port 443: Connection refused"], "stdout": "", "stdout_lines": []}

Come soluzione alternativa manuale, crea una porta in avanti dalla porta 443 (dove il controllo avviene) alla porta 6444 (dove apiserver è in ascolto) prima di eseguire l'upgrade. Per creare la porta in avanti, esegui il comando seguente su ciascun nodo del piano di controllo:

sudo iptables -t nat -I OUTPUT -p tcp -o lo --dport 443 -j REDIRECT --to-ports 6444

Il job cal-update viene eseguito quando si verifica una riconciliazione e controlla la porta 443, quindi devi mantenere questa porta in avanti per i cluster 1.8.x aggiornati.

Dopo aver eseguito l'upgrade alla versione 1.9.0 o successiva, rimuovi la porta eseguendo il comando seguente su ciascun nodo del piano di controllo:

sudo iptables -t nat -D OUTPUT -p tcp -o lo --dport 443 -j REDIRECT --to-ports 6444

Gli upgrade ai cluster di amministrazione, ibrido e autonomo 1.8.0 e 1.8.1 non vengono completati

A volte l'upgrade di cluster di amministrazione, ibridi o autonomi dalla versione 1.7.x alla versione 1.8.0 o 1.8.1 non viene completato. Questo errore di upgrade si applica ai cluster che hai aggiornato dopo la creazione del cluster.

Un'indicazione di questo problema di upgrade è l'output della console Waiting for upgrade to complete ... senza menzionare quale nodo è in fase di upgrade. Questo sintomo indica anche che è stato eseguito l'upgrade del cluster di amministrazione a Kubernetes versione 1.20.8-gke.1500, la versione di Kubernetes per Cluster Anthos on bare metal release 1.8.0 e 1.8.1.

Questo problema di upgrade è stato risolto per i cluster Anthos su Bare Metal release 1.8.2.

Per verificare se questo problema influisce sull'upgrade del cluster alla versione 1.8.0 o 1.8.1:

Crea il seguente script shell:

if [ $(kubectl get cluster <var>CLUSTER\_NAME -n <var>CLUSTER\_NAMESPACE
    --kubeconfig bmctl-workspace/.kindkubeconfig -o=jsonpath='{.metadata.generation}')
    -le $(kubectl get cluster CLUSTER_NAME -n CLUSTER_NAMESPACE
    --kubeconfig bmctl-workspace/.kindkubeconfig
    -o=jsonpath='{{.status.systemServiceConditions[?(@.type=="Reconciling")].observedGeneration}}') ];
    then echo "Bug Detected"; else echo "OK"; fi

Sostituisci quanto segue:

CLUSTER_NAME: il nome del cluster da controllare.
CLUSTER_NAMESPACE: lo spazio dei nomi per il cluster.

Esegui lo script mentre è in corso l'upgrade, ma una volta completati i controlli preliminari.

Quando il valore observedGeneration non è inferiore al valore generation, Bug Detected viene scritto nell'output della console. Questo output indica che l'upgrade del cluster è interessato.

Per sbloccare l'upgrade, esegui il comando seguente:

kubectl get --raw=/apis/baremetal.cluster.gke.io/v1/namespaces/CLUSTER_NAMESPACE/clusters/CLUSTER_NAME/status \
    --kubeconfig bmctl-workspace/.kindkubeconfig | \
    sed -e 's/\("systemServiceConditions":\[{[^{]*"type":"DashboardReady"}\),{[^{}]*}/\1/g' | \
    kubectl replace --raw=/apis/baremetal.cluster.gke.io/v1/namespaces/CLUSTER_NAMESPACE/clusters/CLUSTER_NAME/status \
    --kubeconfig bmctl-workspace/.kindkubeconfig -f-

Sostituisci quanto segue:

CLUSTER_NAME: il nome del cluster da controllare.
CLUSTER_NAMESPACE: lo spazio dei nomi per il cluster.

Upgrade a 1.8.3 o 1.8.4

L'upgrade dei cluster Anthos su Bare Metal alla versione 1.8.3 o 1.8.4 a volte non riesce con un errore di contesto nil. Se l'upgrade del cluster non va a buon fine e viene visualizzato un errore di contesto vuoto, completa i seguenti passaggi:

Imposta la variabile di ambiente GOOGLE_APPLICATION_CREDENTIALS in modo che rimandi al file della chiave dell'account di servizio.
```
export GOOGLE_APPLICATION_CREDENTIALS=KEY_PATH
```
Sostituisci KEY_PATH con il percorso del file JSON contenente la chiave dell'account di servizio.
Esegui di nuovo il comando bmctl upgrade cluster.

Limitazione per l'upgrade delle patch del cluster utente

I cluster utente gestiti da un cluster di amministrazione devono trovarsi negli stessi cluster Anthos su versione Bare Metal o versioni precedenti e all'interno di una release secondaria. Ad esempio, un cluster di amministrazione della versione 1.7.1 (anthosBareMetalVersion: 1.7.1) che gestisce i cluster utente della versione 1.6.2 è accettabile.

Un limite di upgrade ti impedisce di eseguire 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 cluster di amministrazione è la versione 1.7.2, rilasciata il 2 giugno 2021, non puoi eseguire l'upgrade dei cluster utente alla versione 1.6.4, perché è stata rilasciata il 13 agosto 2021.

Incompatibilità con Ubuntu 18.04 e 18.04.1

Per eseguire l'upgrade alla versione 1.8.1 o 1.8.2, le macchine nodo del cluster e la workstation che esegue bmctl devono avere una versione del kernel Linux 4.17.0 o successiva. In caso contrario, il controller di rete anetd non funzionerà. Il sintomo è che i pod con prefisso anet nello spazio dei nomi kube-system continueranno ad arrestarsi in modo anomalo con il seguente messaggio di errore: BPF NodePort services needs kernel 4.17.0 or newer.

Questo problema riguarda Ubuntu 18.04 e 18.04.1, dato che sono sulla versione kernel 4.15.

Questo problema è stato risolto nei cluster Anthos su Bare Metal 1.8.3.

Upgrade di cluster 1.7.x che utilizzano containerd

Gli upgrade dei cluster a 1.8.x sono bloccati per i cluster 1.7.x configurati per utilizzare la funzionalità di anteprima in container. L'anteprima containerd utilizza il driver del gruppo di controllo (cgroup) cgroupfs errato, anziché il driver systemd consigliato. Sono stati segnalati casi di instabilità del cluster quando i cluster che utilizzano il driver cgroupfs vengono sotto pressione. La funzionalità containerizzata di GA nella release 1.8.0 utilizza il driver systemd corretto.

Se disponi di cluster 1.7.x esistenti che utilizzano la funzionalità di runtime del container in anteprima, ti consigliamo di creare nuovi cluster 1.8.0 configurati per il containerd ed eseguire la migrazione di app e carichi di lavoro esistenti. Questo garantisce la massima stabilità del cluster quando utilizzi il runtime del container containerd.

Errori di upgrade di SELinux

L'upgrade dei cluster 1.7.1 configurati con il runtime del container containerizzato e l'esecuzione di SELinux su RHEL o CentOS non andranno a buon fine. Ti consigliamo di creare nuovi cluster 1.8.0 configurati per l'utilizzo di containerd ed eseguire la migrazione dei carichi di lavoro.

Impossibile avviare lo svuotamento del nodo 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 non rispondere più. Questo è un evento raro. Per ridurre al minimo la possibilità che si verifichi questo problema, assicurati che i nodi funzionino correttamente prima di iniziare un upgrade.

Operazione

secret kubeconfig sovrascritto

Il comando bmctl check cluster, quando viene eseguito su cluster utente, sovrascrive il secret kubeconfig del cluster utente 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 un cluster utente è interessato dal problema, esegui questo comando:

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, è interessato dal 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-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 una 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 i dettagli dei nodi per il cluster utente. Verifica che i nomi delle macchine siano 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 il comando seguente per salvare nuovamente 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/elimina

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 il ripristino delle macchine. Quando elimini un cluster utente, devi prima eliminare l'oggetto del cluster prima di eliminare il relativo spazio dei nomi. Altrimenti, i job per reimpostare le macchine non possono essere creati e il processo di eliminazione ignorerà il passaggio di pulizia della macchina.

servizio containerd

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

Sicurezza

Il certificato/CA del cluster verrà ruotato durante l'upgrade. Il supporto della rotazione on demand è una funzionalità di anteprima.

I cluster Anthos su Bare Metal ruotano automaticamente kubelet certificati di pubblicazione. Ogni agente nodo kubelet può inviare una richiesta di firma del certificato (CSR) quando un certificato sta per scadere. Un controller nei cluster di amministrazione convalida e approva il CSR.

Rotazione CA del cluster (funzionalità di anteprima)

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

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

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 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 mantenere 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 garantire che gli IP di servizio siano raggiungibili. Per i dettagli della configurazione, consulta Preservazione dell'indirizzo IP dell'origine client in Configurare il bilanciamento del carico in bundle.

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

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 Cilium iptables 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 della riga di comando (firewall-cmd --reload)

Puoi risolvere questo problema di connettività riavviando anetd sul nodo. Individua ed elimina il pod anetd con i seguenti comandi 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 regole di selezione del traffico che specificano un indirizzo egressSourceIP già in uso per un altro oggetto EgressNATPolicy. Ciò può causare conflitti di routing del traffico in uscita. Coordinati con il tuo team di sviluppo per determinare quali indirizzi IP mobili sono disponibili per l'utilizzo prima di specificare l'indirizzo egressSourceIP nella risorsa personalizzata EgressNATPolicy.

Errori di connettività dei pod a causa di timeout I/O e filtro del percorso inverso

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

Gli errori di connettività osservati che comunicano con gli indirizzi IP del servizio Kubernetes sono un sintomo di questo problema. Di seguito sono riportati alcuni esempi di tipi di errori che potresti vedere:

Se tutti i pod di un determinato nodo non riescono a comunicare con gli indirizzi IP del servizio, il pod istiod potrebbe segnalare un errore come il 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 quello 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 viene impostato con i file rp_filter nella cartella di configurazione IPv4 (net/ipv4/conf/all). Il comando sysctl archivia 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. Il comando sysctl può sostituire l'impostazione del filtro del percorso inverso.

Per ripristinare la connettività dei pod, reimposta net.ipv4.conf.all.rp_filter manualmente 0 o riavvia il pod anetd 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. Al suo posto viene 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.

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 cluster sovrapposti

192.168.122.0/24 e 10.96.0.0/27 sono i CIDR predefiniti di pod e servizi utilizzati dal cluster di bootstrap (tipo). I controlli preflight non avranno esito positivo se si sovrappongono agli indirizzi IP delle macchine dei nodi del cluster. Per evitare conflitti, puoi passare i flag --bootstrap-cluster-pod-cidr e --bootstrap-cluster-service-cidr a bmctl per specificare valori diversi.

Indirizzi IP sovrapposti tra cluster diversi

Non è prevista alcuna convalida per gli indirizzi IP sovrapposti in cluster diversi durante l'aggiornamento. La convalida si applica solo al momento della creazione del cluster/del pool di nodi.

Sistema operativo

Creazione o upgrade del cluster su CentOS non riuscito

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 ciclo di vita (EOL). A causa della EOL, yum repository ha smesso di funzionare per CentOS, il che determina la mancata creazione delle operazioni del cluster e le operazioni di upgrade del cluster. Si applica a tutte le versioni supportate di CentOS e influisce su tutte le versioni di Cluster Anthos on bare metal.

Come soluzione alternativa, esegui i comandi seguenti per fare in modo che CentOS utilizzi un feed di archiviazione:

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 del sistema operativo

Su RHEL e CentOS, esiste una limitazione a livello di cluster di 100.000 endpoint. Questo numero indica 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.

Configurazione

Specifiche del piano di controllo e del bilanciatore del carico

Le specifiche del piano di controllo e del pool di nodi del bilanciatore del carico sono speciali. Queste specifiche dichiarano e controllano le risorse cluster fondamentali. L'origine canonica per queste risorse è la rispettiva sezione 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 invece le sezioni associate nel file di configurazione del cluster.

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. L'indirizzo IP di una VM cambia, ma non influisce sulla connettività delle applicazioni VM esposte come servizio Kubernetes. Se l'indirizzo IP viene perso, devi eseguire dhclient dalla VM per acquisire un indirizzo IP per la VM.

SELinux

Errori SELinux durante la creazione del pod

A volte la creazione dei 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 kubelet:

journalctl -u kubelet

Se SELinux causa l'esito negativo della creazione del 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 il problema sia correlato all'applicazione forzata di SELinux, esegui questo comando:

ausearch -m avc

Questo comando cerca nei log di controllo gli errori di autorizzazione della cache vettoriale di accesso (AVC). La 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 con SELinux è un bug del kernel, che si trova nelle seguenti immagini Linux:

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

Riavviare la macchina aiuta a risolvere il problema.

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

Snapshot

Acquisizione di uno snapshot come utente di accesso non root

Per i cluster Anthos su Bare Metal versione 1.8.1 e precedenti, se non hai eseguito l'accesso come root, non puoi acquisire uno snapshot cluster con il comando bmctl. A partire dalla release 1.8.2, i cluster Anthos su Bare Metal rispetteranno nodeAccess.loginUser nella specifica del cluster. Se il cluster di amministrazione non è raggiungibile, puoi specificare l'utente che ha eseguito l'accesso con il flag --login-user.

Tieni presente che se utilizzi containerd come runtime del container, lo snapshot continua a non eseguire i comandi crictl. Per un metodo alternativo, consulta Containerd richiede /usr/local/bin in PATH. Le impostazioni PATH utilizzate per SUDO causano questo problema.

GKE Connect

Arresto anomalo del pod `gke-connect-agent` in loop

L'utilizzo intensivo del gateway GKE Connect può a volte causare gke-connect-agent problemi di memoria insufficiente per i pod. Sintomi di questi problemi di memoria:

Il pod gke-connect-agent mostra un numero elevato di riavvii o termina in stato di arresto anomalo.
Il gateway di connessione smette di funzionare.

Per risolvere questo problema di memoria insufficiente, modifica il deployment con prefisso gke-connect-agent nello spazio dei nomi gke-connect e aumenta il limite di memoria a 256 MiB o superiore.

kubectl patch deploy $(kubectl get deploy -l app=gke-connect-agent -n gke-connect -o jsonpath='{.items[0].metadata.name}') -n gke-connect --patch '{"spec":{"containers":[{"resources":{"limits":{"memory":"256Mi"}}}]}}'

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

Logging e monitoraggio

Riavvio bloccato di `stackdriver-log-forwarder` pod

Per i cluster Anthos su versioni Bare Metal precedenti alla 1.9, se un nodo viene arrestato forzatamente, il pod stackdriver-log-forwarder potrebbe rimanere bloccato in stato di riavvio. In questo caso, potresti visualizzare una voce di log simile alla seguente:

[error] [input:storage_backlog:storage_backlog.7] chunk validation failed, data might
be corrupted. Found 0 valid records, failed content starts right after byte 0.

Quando il pod stackdriver-log-forwarder è bloccato, la maggior parte dei log non può accedere a Cloud Logging e gli eventuali dati non cancellati vengono persi. Per risolvere questo problema, reimposta la pipeline di logging.

Per reimpostare la pipeline di logging:

Fai lo scale down dell'stackdriver-operator.

kubectl --kubeconfig=KUBECONFIG -n kube-system scale deploy \
    stackdriver-operator --replicas=0

Elimina il DaemonSet stackdriver-log-forwarder:
```
kubectl --kubeconfig KUBECONFIG -n kube-system delete daemonset \
    stackdriver-log-forwarder
```
Verifica che i pod stackdriver-log-forwarder siano stati eliminati prima di andare al passaggio successivo.

Esegui il deployment del seguente DaemonSet per pulire i dati danneggiati nei buffer di 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

Assicurati che nel DaemonSet siano stati puliti tutti i nodi.

L'output dei comandi seguenti deve corrispondere 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

Elimina il DaemonSet di pulizia:

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

Fai lo scale up dell'operatore e attendi che esegua nuovamente il deployment della pipeline di logging.

kubectl --kubeconfig=KUBECONFIG -n kube-system scale deploy \
    stackdriver-operator --replicas=1

Questo problema è stato risolto nei cluster Anthos su Bare Metal release 1.9.0 e successive.

Problemi noti di Cluster Anthos on bare metal

Installazione

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

Incompatibilità del gruppo di controllo v2

Messaggi di errore innocui durante l'installazione

Controlli preflight e credenziali dell'account di servizio

Controlli preflight e autorizzazione negata

Credenziali predefinite dell'applicazione e bmctl

Ubuntu 20.04 LTS e bmctl

Servizio Docker

Mirroring del registro e audit logging di Cloud

Containerd richiede /usr/local/bin in PATH

Installazione su vSphere

Preparazione dello flapping dei nodi

Ubuntu containerd

Docker Ubuntu

ContainerOS CentOS/RHEL

Docker CentOS/RHEL

Upgrade e aggiornamenti

bmctl update cluster non riuscito se manca la directory .manifests

Upgrade bloccato alle ore error during manifests operations

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

bmctl update non rimuove i blocchi di manutenzione

Gli upgrade dei cluster da 1.7.x non riescono per determinate configurazioni del bilanciatore del carico

Gli upgrade ai cluster di amministrazione, ibrido e autonomo 1.8.0 e 1.8.1 non vengono completati

Upgrade a 1.8.3 o 1.8.4

Limitazione per l'upgrade delle patch del cluster utente

Incompatibilità con Ubuntu 18.04 e 18.04.1

Upgrade di cluster 1.7.x che utilizzano containerd

Errori di upgrade di SELinux

Impossibile avviare lo svuotamento del nodo quando il nodo non è raggiungibile

Operazione

secret kubeconfig sovrascritto

Reimposta/elimina

Eliminazione dello spazio dei nomi

servizio containerd

Sicurezza

Rotazione CA del cluster (funzionalità di anteprima)

Networking

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

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

Indirizzi egressSourceIP duplicati

Errori di connettività dei pod a causa di timeout I/O e filtro del percorso inverso

Indirizzi IP del cluster di avvio (tipo) e indirizzi IP del cluster sovrapposti

Indirizzi IP sovrapposti tra cluster diversi

Sistema operativo

Creazione o upgrade del cluster su CentOS non riuscito

Limiti degli endpoint del sistema operativo

Configurazione

Specifiche del piano di controllo e del bilanciatore del carico

Runtime VM Anthos

SELinux

Errori SELinux durante la creazione del pod

Snapshot

Acquisizione di uno snapshot come utente di accesso non root

GKE Connect

Arresto anomalo del pod gke-connect-agent in loop

Logging e monitoraggio

Riavvio bloccato di stackdriver-log-forwarder pod

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

Credenziali predefinite dell'applicazione e `bmctl`

Ubuntu 20.04 LTS e `bmctl`

Containerd richiede `/usr/local/bin` in PATH

`bmctl update cluster` non riuscito se manca la directory `.manifests`

Upgrade bloccato alle ore `error during manifests operations`

`bmctl update` non rimuove i blocchi di manutenzione

Indirizzi `egressSourceIP` duplicati

Arresto anomalo del pod `gke-connect-agent` in loop

Riavvio bloccato di `stackdriver-log-forwarder` pod