Probleme bei der Installation des privaten Anthos-Modus

Auf dieser Seite wird beschrieben, wie Sie Probleme beheben, die bei der Installation oder dem Upgrade des privaten Anthos-Modus auftreten können.

Voraussetzungen für die Fehlerbehebung

Der private Anthos-Modus erfordert eine Anmeldung bei einer Administrator-Workstation, damit Sie mit der Fehlerbehebung beginnen können. Führen Sie den folgenden Befehl aus, um sich bei Ihrer Administrator-Workstation anzumelden:

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

Hinweis: Der genaue SSH-Befehl kann je nach Umgebung variieren.

Cluster erstellen

In diesem Abschnitt wird beschrieben, wie Sie Probleme beim Erstellen von Clustern im privaten Anthos-Modus beheben.

Fehler beim Erstellen des Administratorclusters

In diesem Abschnitt werden häufige Konfigurationen von Administratorclustern und Preflight-Fehler sowie Vorschläge zur Behebung aufgelistet.

Konfigurationsfehler

Häufige Probleme bei der Konfiguration des Administratorclusters sind eine fehlende Annotation in der Konfiguration, eine fehlende Authentifizierungskonfiguration für die Registry und ein Fehler bei der Erstellung des Bootstrap-Clusters.

Fehlende Annotation in der Konfiguration

Wenn Ihre Konfigurationsdatei während der Erstellung von Knotenpoolressourcen keine Annotation enthält, wird möglicherweise der folgende Fehler angezeigt:

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

Zur Behebung dieses Problems fügen Sie der Konfigurationsdatei des Administratorclusters eine Annotation hinzu und legen die Annotation auf true fest:

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

Ein Beispiel für eine angewendete Annotation in einer Konfigurationsdatei für einen Administratorcluster finden Sie unter Administratorcluster und Knotenpool.

Fehlende Authentifizierungskonfiguration für die Registry

Wenn die Authentifizierungskonfiguration fehlt, kann der Fehler no auth config found for the registry auftreten.

Prüfen Sie, ob der in der Datei admin.yaml angegebene pullCredentialConfigPath eine Authentifizierungskonfiguration für den Endpunkt enthält. Wenn der Endpunkt beispielsweise https://10.200.0.2 und pullCredentialConfigPath gleich /root/.docker/config.json ist, hat die Datei config.json den folgenden Authentifizierungseintrag:

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

Wenn der Authentifizierungseintrag für die Registry nicht vorhanden ist, aktualisieren Sie die Datei config.json. Melden Sie sich dazu in der Registry an:

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

Fehler beim Erstellen des Bootstrap-Clusters

Beim Erstellen des Clusters kann der folgende Fehler auftreten:

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)

Wenn der Fehler "error creating bootstrap cluster" angezeigt wird, prüfen Sie, ob alle Images in die private Registry hochgeladen wurden:

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

Ein Beispielbefehl sieht so aus:

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

Preflight-Fehler

Wenn Sie Ihren Administratorcluster im privaten Anthos-Modus erstellen, müssen Sie möglicherweise ein Fehlschlagen der Clustererstellung mit Preflight-Fehlern oder eine hängengebliebene Clustererstellung beheben oder eine allgemeine Fehlerbehebung durchführen.

Fehlschlagen der Clustererstellung mit Preflight-Fehlern

Wenn die Preflight-Prüfung fehlgeschlagen ist, wird möglicherweise die folgende Fehlermeldung angezeigt:

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

Der private Anthos-Modus erfasst entsprechende Fehlerlogs im Verzeichnis actl-workspace/admin/log/preflight-<timestamp>/, z. B. actl-workspace/admin/log/preflight-20210907-205726/.

Prüfen Sie Folgendes, um das Problem zu beheben:

• Alle fehlgeschlagenen Knotenlogs in der Datei, die mit der IP-Adresse des Knotens benannt ist
• Netzwerkbezogene Logs in der Datei node-network

Prüfen Sie anhand der Logdaten, ob offensichtliche Fehler wie nicht erfüllte Mindestanforderungen für Maschinen oder in Konflikt stehende Ports vorliegen. Aktualisieren Sie die Maschinen und versuchen Sie es noch einmal.

Hängen gebliebene Clustererstellung

Wenn die Clustererstellung lange dauert, z. B. mehr als 30 Minuten für einen Cluster mit drei Knoten, prüfen Sie den lokalen Bootstrap-Cluster, um festzustellen, ob beim Abrufen des Images Fehler auftreten:

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

Wenn Pods den Status ImagePullErr haben, achten Sie darauf, dass diese Images in die Registry hochgeladen werden:

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

Ein Beispielbefehl sieht so aus:

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

Wenn ein bestimmter Clustererstellungsjob den Status Error hat, prüfen Sie die Logs des entsprechenden Pods:

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

Prüfen Sie die Logs, um festzustellen, ob Fehler manuell auf der Maschine behoben werden können. Sie können zusätzliche Fehler von der Maschine selbst erhalten, wenn Sie sich mit SSH bei der Maschine anmelden und journalctl --no-pager -l ausführen. Prüfen Sie mit dem folgenden Befehl, ob wichtige Dienste funktionieren:

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

Allgemeine Probleme

Um eine allgemeine Fehlerbehebung für einen Knoten durchzuführen, stellen Sie mit SSH eine Verbindung zum Knoten her und führen Sie den folgenden Befehl aus:

journalctl --no-pager -l

Prüfen Sie die Logs auf Fehler.

Fehler bei der Clustererstellung

Stellen Sie eine SSH-Verbindung zur Maschine der Steuerungsebene her und sehen Sie sich die Pods im Cluster an:

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

Netzwerkprobleme

In diesem Abschnitt werden die häufigsten netzwerkbezogenen Probleme im privaten Anthos-Modus erläutert und es wird beschrieben, wie Sie diese beheben können.

• Verwenden Sie ip route, um die Verbindung zwischen den einzelnen Knoten anzuzeigen und netzwerkbezogene Fehler zu prüfen.

• Wenn die VIP der Steuerungsebene nicht erreichbar ist, stellen Sie mit SSH eine Verbindung zu einem Knoten der Steuerungsebene her und führen Sie Folgendes aus:

  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}'`
  

  Dieses Problem kann auftreten, wenn die Images keepalived und haproxy nicht in eine private Registry geladen werden.

• (Nur verwenden, nachdem der Administratorcluster erfolgreich erstellt wurde.) Wenn Dienst-IP-Adressen nicht erreichbar sind, suchen Sie in den Logs nach metallb-Pods:

  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
  

• Wenn alle Pods bei der Containererstellung hängen bleiben, führen Sie einen der folgenden Schritte aus:

  • Prüfen Sie die anetd-Operator-Bereitstellung und die anetd-DaemonSet-Logs.

  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
  

  • Wenn kein Standardgateway definiert ist, funktionieren die IP-Tabellen möglicherweise nicht ordnungsgemäß, sodass der anetd-Operator möglicherweise nicht den kube-api-Server erreicht.

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

• Starten Sie den Knoten neu, um zu sehen, ob das Problem behoben wurde.

Häufige Fehler

kubectl-Befehle funktionieren nicht

Wenn Sie nicht das kubectl-Befehlszeilentool konfiguriert haben, um eine Verbindung zu einem Remote-Kubernetes API-Server herzustellen, wird die folgende Fehlermeldung angezeigt:

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

Stellen Sie sicher, dass eine kubeconfig-Datei festgelegt ist. Dazu legen Sie entweder die KUBECONFIG-Umgebungsvariable fest oder führen die Befehle mit dem Flag --kubeconfig aus.
Wenn Sie die Administrator-kubeconfig-Datei festlegen möchten, haben Sie folgende Möglichkeiten:

• Legen Sie die Umgebungsvariable auf die Administrator-kubeconfig-Datei fest:

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

• Verwenden Sie die kubeconfig-Befehlszeilenoption:

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

Weitere Informationen finden Sie unter Clusterzugriff mit kubeconfig-Dateien organisieren.

Fehler beim Erstellen des Nutzerclusters

Verwenden Sie auf Ihrer Workstation den folgenden Befehl, um auf den Administratorcluster zuzugreifen und sich clusterbezogene Pods anzusehen:

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

Ersetzen Sie CLUSTER_NAME durch den Namen Ihres Clusters.

Wenn der Nutzercluster weiterhin fehlschlägt, löschen Sie einen Nutzercluster und wenden Sie die folgende Konfiguration noch einmal an:

# 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

Anthos Management Center erstellen

Unzureichende Ressourcen im Administratorcluster

Die benutzerdefinierte AdminOperator-Ressource konfiguriert die Installation von Anthos Management Center. Prüfen Sie in den Google Kubernetes Engine-Ereignissen und -Logs der benutzerdefinierten Ressource und des Controllers, ob im Controller bei der Installation des Management Centers Probleme aufgetreten sind:

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

Fehler beim Abrufen des Images

Das Starten von Pods im Cluster kann zu Problemen führen, die verhindern, dass der AdminOperator Erfolg meldet.

# 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 on Bare Metal

Weitere Informationen zum Beheben von Problemen im Zusammenhang mit einem Upgrade in Anthos on Bare Metal finden Sie unter Fehlgeschlagenes Upgrade in Anthos on Bare Metal wiederherstellen.

Hinweis: Bei Clustern im privaten Anthos-Modus müssen Sie den Befehl bmctl durch actl ersetzen, wenn Sie die für Anthos on Bare Metal aufgelisteten Korrekturen anwenden. Verwenden Sie z. B. actl clusters baremetal upgrade statt bmctl upgrade cluster.

Anthos-Verwaltungszentrum

Mit folgendem Befehl können Sie die Version der installierten Komponente prüfen:

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

Hier ein Beispiel für die Ausgabe:

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 einer bereitgestellten Umgebung mit dem privaten Anthos-Modus gibt status.version im AdminOperator-Objekt die Releaseversion des privaten Anthos-Modus an.

Beispiel: 1.8.0-gke.0. status.components zeigt den Versionsstatus der einzelnen Komponenten an. Hier werden die beobachtete Version und die Versionseinschränkung für jede bereitgestellte Komponente aufgeführt.

Sowohl status.version als auch status.components müssen immer verfügbar sein, andernfalls ist die Installation beschädigt. spec.updateConfigOverride ist optional. Es ist nur vorhanden, wenn Infrastrukturbetreiber das Feld zur manuellen Aktualisierung einer bestimmten Komponente festlegen. Wenn das Feld nicht angegeben wird, werden alle Komponenten in der gleichen Version wie AdminOperator ausgeführt.

Pakete im Updatecenter prüfen

Nur im Updatecenter angebotene Pakete werden im Management Center bereitgestellt.

Wenn Sie beispielsweise den Administratorcluster mit dem Release 1.8.0-gke.0 installieren und später ein Upgrade auf 1.8.1-gke.0 durchführen, enthält das Updatecenter zwei Gruppen von Paketen. Wenn Sie die Ressource UpdateItem für eine aktiv verwendete Komponente löschen, kann die Installation des privaten Anthos-Modus beschädigt werden.

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

Hier ein Beispiel für die Ausgabe:

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

Weitere Informationen

• Weitere Informationen zu bekannten Problemen mit dem privaten Anthos-Modus