Problemi di installazione in modalità privata di Anthos

In questa pagina viene descritto come risolvere i problemi che potrebbero verificarsi durante l'installazione o l'upgrade della modalità privata Anthos.

Risoluzione dei problemi relativi ai prerequisiti

Per avviare la risoluzione dei problemi, la modalità privata di Anthos richiede l'accesso a una workstation amministrativa. Per accedere alla workstation amministrativa, esegui questo comando:

ssh <USERNAME>@<WORKSTATION>
cd ./anthos-baremetal-private-mode
export PATH=$PWD/bin:$PATH

Nota: il comando SSH esatto potrebbe variare in base all'ambiente.

Crea cluster

Questa sezione spiega come risolvere i problemi di creazione dei cluster in modalità privata di Anthos.

Errore di creazione del cluster di amministrazione

Questa sezione elenca la configurazione comune dei cluster di amministrazione e gli errori di preflight e suggerimenti per risolverli.

Errori di configurazione

I problemi comuni di configurazione del cluster di amministrazione includono un'annotazione mancante nella configurazione, nessuna configurazione di autenticazione per il registro e un errore nella creazione del cluster di bootstrap.

Annotazione mancante nella configurazione

Se durante la creazione delle risorse del pool di nodi il file di configurazione non include un'annotazione, potresti visualizzare il seguente errore:

Cluster.baremetal.cluster.gke.io "admin" is invalid: [Spec.LoadBalancer.AddressPools: Forbidden: Field not allowed for admin clusters, Spec.GKEConnect: Required value: Field is required].

Per risolvere questo problema, aggiungi un'annotazione al file di configurazione del cluster di amministrazione e impostala su true:

annotations:
    baremetal.cluster.gke.io/private-mode: "true"

Vedi Cluster di amministrazione e pool di nodi per un esempio di annotazione applicata in un file di configurazione del cluster di amministrazione.

Configurazione di autenticazione mancante per il registro

Se manca la configurazione di autenticazione, potresti riscontrare l'errore no auth config found for the registry.

Assicurati che il pullCredentialConfigPath specificato nel file admin.yaml contenga la configurazione dell'autenticazione per l'endpoint. Ad esempio, se l'endpoint è https://10.200.0.2 e pullCredentialConfigPath è /root/.docker/config.json, il file config.json contiene la seguente voce di autenticazione:

{
        "auths": {
                "10.200.0.2": {
                        "auth": "<base64 encoded auth>"
                }
        }
}

Se la voce di autenticazione per il Registro di sistema non è presente, aggiorna il file config.json accedendo al Registro di sistema:

docker login <registry> -u <username> -p <password>

Creazione dell'errore del cluster di bootstrap

Potresti riscontrare il seguente errore durante la creazione del cluster:

failed: error creating bootstrap cluster: failed to pull kind image kindest/node:v0.11.1-gke.7-v1.20.9-gke.101 from registry mirror(s)

Se viene visualizzato l'errore di creazione del cluster di bootstrap, assicurati che tutte le immagini siano caricate nel registro privato:

actl images push --private-registry=<registry>

Un comando di esempio ha il seguente aspetto:

actl images push --private-registry=10.200.0.2/library

Errori preflight

Quando crei il cluster di amministrazione in modalità privata di Anthos, potrebbe essere necessario correggere un errore di creazione del cluster con errori preliminari, bloccare un cluster o eseguire alcuni passaggi generali per la risoluzione dei problemi.

Errore di creazione del cluster con errori preflight

Se la verifica preflight non è riuscita, potresti vedere il seguente messaggio di errore:

unable to create cluster: unable to create cluster: preflight check failed

La modalità privata di Anthos raccoglie i log degli errori corrispondenti nella directory actl-workspace/admin/log/preflight-<timestamp>/, ad esempio actl-workspace/admin/log/preflight-20210907-205726/.

Per risolvere il problema, controlla quanto segue:

• ogni log del nodo non riuscito nel file denominato indirizzo IP del nodo
• log relativi alla rete nel file node-network

In base ai dati dei log, verifica se sono presenti errori evidenti come requisiti minimi delle macchine non soddisfatti o porte in conflitto. Aggiorna i computer e riprova.

Creazione cluster bloccata

Se la creazione del cluster richiede più tempo, ad esempio più di 30 minuti per un cluster a tre nodi, controlla il cluster bootstrap locale per verificare se sono presenti errori durante il pull dell'immagine:

kubectl --kubeconfig actl-workspace/.kindkubeconfig get pods -A

Se i pod hanno lo stato ImagePullErr, assicurati che tali immagini siano caricate nel Registro di sistema:

actl images push --private-registry=<registry>

Un comando di esempio ha il seguente aspetto:

actl images push --private-registry=10.200.0.2/library

Se un job di creazione cluster specifico ha lo stato Error, controlla i log del pod corrispondente:

kubectl --kubeconfig actl-workspace/.kindkubeconfig get pods -n cluster-admin
kubectl --kubeconfig actl-workspace/.kindkubeconfig logs <pod-name> -n cluster-admin

Esamina i log per vedere se è possibile correggere manualmente eventuali errori sul computer. Puoi ottenere ulteriori errori dalla macchina utilizzando SSH per accedere al computer ed eseguire journalctl --no-pager -l. Per assicurarti che i servizi importanti funzionino, esegui il comando seguente:

service containerd status
service kubelet status

journalctl -u containerd
journalctl -u kubelet

# If needed sudo systemctl restart <service> to fix issues.
# sudo service <service> restart
# e.g.,
# sudo service containerd restart

Problemi generici

Per risolvere i problemi di un nodo in generale, utilizza SSH per la connessione a un nodo ed esegui il seguente comando:

journalctl --no-pager -l

Verifica se nei log sono presenti errori.

Errore di creazione del cluster

Utilizza SSH per connetterti alla macchina del piano di controllo e visualizzare i pod nel cluster:

sudo kubectl --kubeconfig /etc/kubernetes/admin.conf get po -A

Problemi di rete

Questa sezione spiega i problemi più comuni relativi alla rete in modalità privata di Anthos ed elenca i passaggi per risolverli.

• Per vedere la connessione tra ciascun nodo e controllare gli errori relativi alla rete, utilizza ip route.

• Quando il VIP del piano di controllo non è raggiungibile, utilizza SSH per connetterti a un nodo del piano di controllo ed esegui:

  journalctl -u containerd --no-pager -l
  # Check the logs of those pods as well.
  sudo kubectl --kubeconfig /etc/kubernetes/admin.conf -n kube-system get po | grep -E "haproxy|keepalived"
  sudo crictl logs `sudo crictl ps | grep anthos-baremetal-haproxy | awk '{print $1}'`
  sudo crictl logs `sudo crictl ps | grep anthos-baremetal-keepalived | awk '{print $1}'`
  

  Questo problema può verificarsi se le immagini keepalived e haproxy non vengono caricate in un registro privato.

• Da utilizzare solo dopo la creazione riuscita del cluster di amministrazione. Se gli IP di servizio non sono raggiungibili, controlla i log per i pod metallb:

  kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig logs -l app=metallb -l component=controller -n kube-system
  kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig logs -l app=metallb -l component=speaker -n kube-system
  

• Se tutti i pod sono bloccati nella creazione del contenitore, procedi in uno dei seguenti modi:

  • Controlla il deployment dell'operatore anetd e i log del daemonset anetd.

  kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig get pods -l name=cilium-operator -n kube-system
  kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig logs -l name=cilium-operator -n kube-system
  kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig get pods -l k8s-app=cilium -n kube-system
  kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig logs -l k8s-app=cilium -n kube-system
  

  • Se non è definito un gateway predefinito, iptables potrebbe non funzionare correttamente, quindi l'operatore anetd potrebbe non riuscire a raggiungere il server kube-api.

  ip route add default via <some-ip>
  iptables-save -t nat
  iptables-save -t filter
  

• Prova a riavviare il nodo per vedere se il problema si risolve.

Errori comuni

I comandi kubectl non funzionano

Se non hai configurato lo strumento a riga di comando kubectl per la connessione a un server API Kubernetes remoto, verrà visualizzato il seguente messaggio di errore:

$ kubectl ...
The connection to the server localhost:8080 was refused - did you specify the right host or port?

Assicurati di aver impostato un kubeconfig. A tale scopo, imposta la variabile di ambiente KUBECONFIG o esegui i comandi con il flag --kubeconfig.
Ad esempio, per impostare la console di amministrazione, procedi in uno dei seguenti modi:

• Imposta la variabile di ambiente sul criterio kubeconfig:

export KUBECONFIG=$HOME/anthos-baremetal-private-mode/actl-workspace/admin/admin-kubeconfig

• Utilizza l'opzione della riga di comando kubeconfig:

kubectl --kubeconfig=$HOME/anthos-baremetal-private-mode/actl-workspace/admin/admin-kubeconfig

Per ulteriori dettagli, consulta Organizzazione dell'accesso ai cluster utilizzando i file kubeconfig.

Errore durante la creazione del cluster utente

Sulla workstation, per accedere al cluster di amministrazione e visualizzare i pod correlati ai cluster utente, utilizza il comando seguente:

kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig get po -n cluster-CLUSTER_NAME

Sostituisci CLUSTER_NAME con il nome del tuo cluster.

Se il cluster utente continua a non riuscire, prova a eliminare un cluster utente e applica nuovamente la seguente configurazione:

# Delete user cluster
export ADMIN_KUBECONFIG=$(pwd)/actl-workspace/admin/admin-kubeconfig
export USER_CLUSTER_NAME=user-1
kubectl -n cluster-${USER_CLUSTER_NAME} delete Cluster $USER_CLUSTER_NAME --kubeconfig=${ADMIN_KUBECONFIG}

# Re-apply the user cluster YAML file
KUBECONFIG=${ADMIN_KUBECONFIG} kubectl apply -f user.yaml

# Wait until client config ready and stored in the path "$(pwd)/${USER_CLUSTER_NAME}-kubeconfig"
export USER_KUBECONFIG=$(pwd)/${USER_CLUSTER_NAME}-kubeconfig
waittime="5 minutes"
endtime=$(date -ud "$waittime" +%s)
while ! KUBECONFIG=${ADMIN_KUBECONFIG} actl clusters baremetal get-credentials -c "${USER_CLUSTER_NAME}" -o "${USER_KUBECONFIG}"; do
  if [[ $endtime -le $(date -u +%s) ]]; then
    echo "Client config not ready in $waittime, terminating"
    exit 1
  fi
  echo "client config not ready, sleeping 30s"
  sleep 30
done

# Check the user cluster status until all nodes are ready
KUBECONFIG=${USER_KUBECONFIG} kubectl get nodes

Creazione di Anthos Management Center

Risorse insufficienti sul cluster di amministrazione

La risorsa personalizzata AdminOperator configura l'installazione di Anthos Management Center. Per verificare se il controller ha riscontrato problemi durante l'installazione di Management Center, consulta gli eventi e i log di Google Kubernetes Engine di questa risorsa e del controller personalizzati:

kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig describe adminoperator admin-operator
kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig logs -n anthos-management-center-operator -l control-plane=admin-operator

Errori di pull delle immagini

L'avvio di pod nel cluster potrebbe causare problemi che impediscono a AdminOperator di segnalare l'esito positivo.

# Get all pods that aren't in a Running state or have succeeded.
kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig get pods --field-selector=status.phase!=Running,status.phase!=Succeeded -A

# Examine the pods of interest that are failing...
kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig describe pod --namespace [NAMESPACE] [POD_OF_INTEREST]

Upgrade

Anthos su Bare Metal

Per maggiori dettagli sulla risoluzione dei problemi relativi a un upgrade in Anthos su Bare Metal, consulta la pagina relativa al recupero di un upgrade non riuscito in Anthos su Bare Metal.

Nota: per i cluster in modalità privata di Anthos, è necessario sostituire il comando bmctl con actl quando si applicano correzioni elencate per Anthos su Bare Metal. Ad esempio, utilizza actl clusters baremetal upgrade invece di bmctl upgrade cluster.

Centro di gestione Anthos

Per verificare la versione del componente installata, utilizza:

kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig get adminoperator admin-operator -o yaml

Ecco un esempio di risultato:

apiVersion: managementcenter.anthos.cloud.google.com/v1
kind: AdminOperator
spec:
  updateConfigOverride:
    policies:
    - name: anthos-config-management
      versionConstraint: <=1.8.0-gke.0
status:
  components:
  - name: anthos-bare-metal
    version: 1.8.0-gke.0
    versionConstraint: <=1.8.0-gke.0
  - name: anthos-config-management
    version: 1.8.0-gke.0
    versionConstraint: <=1.8.0-gke.0
  - name: anthos-service-mesh
    version: 1.8.0-gke.0
    versionConstraint: <=1.8.0-gke.0
  version: 1.8.0-gke.0

In un ambiente Anthos in modalità privata di cui è stato eseguito il deployment, l'oggetto status.version nell'oggetto AdminOperator indica la versione della release in modalità privata di Anthos.

Ad esempio, 1.8.0-gke.0. status.components mostra lo stato della versione per ciascun componente. Nel file sono elencate la versione osservata e il vincolo di versione per ciascun componente di cui è stato eseguito il deployment.

Sia status.version sia status.components devono essere sempre disponibili, altrimenti l'installazione è danneggiata. Il valore spec.updateConfigOverride è facoltativo, È presente solo se gli operatori infrastrutturali impostano manualmente il campo per eseguire l'upgrade di un componente specifico. Se il campo viene omesso, tutti i componenti vengono eseguiti sulla stessa versione di AdminOperator.

Controllare i pacchetti nel Centro aggiornamenti

Solo i pacchetti offerti nel Centro aggiornamenti vengono sottoposti a deployment nel Centro gestione.

Ad esempio, se inizialmente installi il cluster di amministrazione con 1.8.0-gke.0 release e successivamente esegui l'upgrade a 1.8.1-gke.0, il Centro aggiornamenti contiene due gruppi di pacchetti. L'eliminazione della risorsa UpdateItem per un componente utilizzato attivamente potrebbe danneggiare l'installazione in modalità privata di Anthos.

kubectl --kubeconfig ./actl-workspace/admin/admin-kubeconfig get updateitems -n anthos-management-center

Ecco un esempio di risultato:

NAME                                  AGE
anthos-config-management-1.8.0-gke.0  13d
anthos-service-mesh-1.8.0-gke.0       13d

Passaggi successivi

• Ulteriori informazioni sui problemi noti della modalità privata di Anthos.