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

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.

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.

Creazione dell'area di lavoro Cloud Monitoring prima di visualizzare le dashboard

Devi creare un'area di lavoro di monitoraggio cloud tramite la console di Google Cloud prima di poter visualizzare i cluster Anthos sulle dashboard di monitoraggio Bare Metal.

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.

Ubuntu 20.04 LTS e `bmctl`

Sui 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 il avvio del cluster di 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 è impostare manualmente net/netfilter/nf_conntrack_max sul valore necessario nell'host: sudo sysctl net.netfilter.nf_conntrack_max=393216. Nota che il valore necessario dipende dal numero di core per il nodo. Usa il comando kubectl logs riportato sopra per confermare il valore desiderato di kube-proxy log.

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

Ubuntu 20.04.3+ LTS e HWE

Ubuntu 20.04.3 ha abilitato il kernel 5.11 nel suo pacchetto HWE (Hardware Enablement). I cluster Anthos sulla versione 1.7.x di Bare Metal non supportano questo kernel. Se vuoi utilizzare il kernel 5.11, scarica ed esegui l'upgrade ai cluster Anthos sulla versione 1.8.0 o successiva di Bare Metal.

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.

Il container richiede `/usr/local/bin` in PATH

I cluster con runtime containerizzato richiedono che /usr/local/bin si trovi nel PATH dell'utente SSH per il comando kubeadm init per trovare il programma binario crictl. Se non viene trovato 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 per includere /usr/local/bin. In alternativa, crea un link simbolico per crictl in un'altra directory /bin.

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

Preparazione del nodo di flapping

A volte i cluster possono presentare problemi di idoneità dei nodi (ad es. la modifica dello stato dei nodi tra Ready e NotReady). Un comportamento non integro del ciclo di vita dei pod (PLEG) provoca questo comportamento. Il PLEG è un modulo in kubelet

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

journalctl -f | grep -i pleg

Le voci di log come segue 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 problema dello stato PLEG non integro. I processi runc bloccati sono un sintomo della condizione della gara. Utilizza il comando seguente per controllare lo stato del processo runc init:

ps aux | grep 'runc init'

Per risolvere questo problema:

Esegui i comandi seguenti in ogni nodo per installare l'ultimo containerd.io ed estrarre lo strumento più recente dalla riga di comando runc:

Ubuntu

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

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

Riavvia il nodo se ci sono processi runc init bloccati.

In alternativa, puoi eseguire manualmente la pulizia di tutti i processi bloccati.

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.

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.

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

L'upgrade dei cluster alla versione 1.7.6 dalla versione 1.7.5 è bloccato

Non puoi eseguire l'upgrade di Anthos sui cluster bare metal versione 1.7.5 alla versione 1.7.6. Questo blocco non influisce su altre versioni dei cluster Anthos su Bare Metal. Ad esempio, puoi eseguire l'upgrade dei cluster dalla versione 1.7.4 alla versione 1.7.6. Se hai cluster della versione 1.7.5, per correggere le correzioni relative alla vulnerabilità di sicurezza nella versione 1.7.6 devi eseguire l'upgrade a una versione successiva non appena sarà disponibile.

Eseguire l'upgrade dalla versione 1.6.0

L'upgrade non è disponibile nella versione 1.6.0.

Upgrade da 1.7.0 a 1.7.x

Quando esegui l'upgrade da 1.7.0 a 1.7.x, il tuo cluster potrebbe bloccarsi sul piano di upgrade del nodo di controllo. Potresti vedere MACHINE-IP-machine-upgrade offerte di lavoro in esecuzione e errori. Questo problema riguarda i cluster 1.7.0 che hanno:

Docker preinstallato sui nodi del piano di controllo.
containerd selezionata come runtime.

Questo problema è causato dai cluster Anthos su Bare Metal che configurano in modo errato il cri-socket in Docker anziché containerd. Per risolvere questo problema, devi impostare le credenziali del pull immagine per Docker:

Accedi a Docker:
```
docker login gcr.io
```
Viene creato un file $HOME/.docker/config.json.
Elenca gli indirizzi IP di tutti i nodi del piano di controllo, separati da uno spazio:
```
IPs=(NODE_IP1 NODE_IP2 ...)
```
Copia la configurazione Docker nei nodi:
```
for ip in "${IPs[@]}"; do
  scp $HOME/.docker/config.json USER_NAME@{ip}:docker-config.json
```
Sostituisci USER_NAME con il nome utente configurato nel file di configurazione del cluster di amministrazione.

Imposta le credenziali del pull immagine per Docker:

ssh USER_NAME@${ip} "sudo mkdir -p /root/.docker && sudo cp docker-config.json /root/.docker/config.json"

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.8.1 (anthosBareMetalVersion: 1.8.1) che gestisce i cluster utente della versione 1.7.2 è accettabile, ma i cluster utente della versione 1.6.3 non sono presenti in una release secondaria.

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.8.2, che è stata rilasciata il 29 luglio 2021, non puoi eseguire l'upgrade dei tuoi cluster utente alla versione 1.7.3, perché è stata rilasciata il 16 agosto 2021.

Il driver del gruppo di controllo non è configurato correttamente a `cgroupfs`

Se riscontri problemi relativi al driver del gruppo di controllo (cgroup), questo potrebbe essere causato dai cluster Anthos su Bare Metal erroneamente configurati su cgroupfs anziché su systemd.

Per risolvere questo problema:

Accedi alle macchine aperte da /etc/containerd/config.toml.

In [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options], aggiungi SystemdCgroup = true:

...
   [plugins."io.containerd.grpc.v1.cri".containerd.runtimes]
     [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
       runtime_type = "io.containerd.runc.v2"
       runtime_engine = ""
       runtime_root = ""
       privileged_without_host_devices = false
       base_runtime_spec = ""
       [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
         SystemdCgroup = true
 [plugins."io.containerd.grpc.v1.cri".cni]
   bin_dir = "/opt/cni/bin"
   conf_dir = "/etc/cni/net.d"
   max_conf_num = 1
   conf_template = ""
...

Salva le modifiche e chiudi il file.
Apri /etc/systemd/system/kubelet.service.d/10-kubeadm.conf.

Alla fine del file, aggiungi --cgroup-driver=systemd --runtime-cgroups=/system.slice/containerd.service:

[Service]
Environment="HOME=/root"
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
# This is a file that "kubeadm init" and "kubeadm join" generates at runtime, populating the KUBELET_KUBEADM_ARGS variable dynamically
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably, the user should use
# the .NodeRegistration.KubeletExtraArgs object in the configuration files instead. KUBELET_EXTRA_ARGS should be sourced from this file.
EnvironmentFile=-/etc/default/kubelet
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS --cgroup-driver=systemd --runtime-cgroups=/system.slice/containerd.service

Salva le modifiche e riavvia il server.
Esegui l'esecuzione di systemd per controllare il driver del gruppo di controllo:
```
systemd-cgls
```
Verifica che ci sia una sezione kubepods.slice e che tutti i pod si trovino in questa sezione.

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

Supporto dei cluster utente

Non puoi reimpostare i cluster utente con il comando bmctl reset.

Punti di montaggio e `fstab`

Il ripristino non smonta i punti di montaggio sotto /mnt/localpv-share/ e non rimuove 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.

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.

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.

Logging e monitoraggio

I log dei nodi non vengono esportati in Cloud Logging

I log dei nodi provenienti dai nodi che contengono il punto (".") nel nome non vengono esportati in Cloud Logging. Per risolvere il problema, segui le istruzioni riportate di seguito per aggiungere un filtro alla risorsa stackdriver-log-forwarder-config al fine di consentire all'operatore di Stackdriver di riconoscere ed esportare questi log.

Fai lo scale down delle dimensioni dell'operatore Stackdriver, stackdriver-operator:

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

Modifica la mappa di configurazione dell'inoltro log, stackdriver-log-forwarder-config:

kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system edit configmap \
    stackdriver-log-forwarder-config

Aggiungi il seguente filtro alla fine della sezione input-systemd.conf della configmap:

   [FILTER]
       Name    lua
       Match_Regex   container-runtime|kubelet|node-problem-detector|node-journal
       script  replace_dot.lua
       call    replace

 replace_dot.lua: |
   function replace(tag, timestamp, record)
       new_record = record

       local local_resource_id_key = "logging.googleapis.com/local_resource_id"

       -- Locate the local_resource_id
       local local_resource_id = record[local_resource_id_key]

       local first = 1
       local new_local_resource_id = ""
       for s in string.gmatch(local_resource_id, "[^.]+") do
           new_local_resource_id = new_local_resource_id .. s
           if first == 1 then
               new_local_resource_id = new_local_resource_id .. "."
               first = 0
           else
               new_local_resource_id = new_local_resource_id .. "_"
           end
       end

       -- Remove the trailing underscore
       new_local_resource_id = new_local_resource_id:sub(1, -2)
       new_record[local_resource_id_key] = new_local_resource_id
       return 1, timestamp, new_record
   end

Elimina tutti i pod dello strumento di inoltro dei log:

kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system patch daemonset \
    stackdriver-log-forwarder -p \
    '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'

Verifica che i pod stackdriver-log-forwarder siano stati eliminati prima di andare al passaggio successivo.

Esegui il deployment di un daemonset per pulire tutti i dati non elaborati e non elaborati nei buffer in fluent-bit:

kubectl --kubeconfig ADMIN_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

Verifica che nel daemonset siano stati puliti tutti i nodi con i comandi seguenti.

kubectl --kubeconfig ADMIN_KUBECONFIG logs -n kube-system \
    -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l

kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system get pods \
    -l app=fluent-bit-cleanup --no-headers | wc -l

L'output dei due comandi deve essere uguale al numero del tuo nodo nel cluster

Elimina il daemonset di pulizia:

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

Riavvia i pod:

kubectl --kubeconfig ADMIN_KUBECONFIG -n kube-system patch \
    daemonset stackdriver-log-forwarder --type json \
    -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'

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.

La modifica di `firewalld` comporterà la cancellazione delle 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.

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

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

Snapshot

Acquisire uno snapshot come utente di accesso non root

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

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

GKE Connect

Arresto anomalo del pod `gke-connect-agent`

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

Il pod gke-connect-agent mostra un numero elevato di riavvii o finisce con lo stato di arresto anomalo del loop.
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.