Bekannte Probleme im privaten Anthos-Modus

Auf dieser Seite werden bekannte Probleme mit dem privaten Anthos-Modus und Möglichkeiten zur Vermeidung oder Behebung dieser Probleme aufgelistet.

Bei Erstellung des Administratorclusters wird dauerhaft `waiting for node update jobs` angezeigt

Das Erstellen eines Administratorclusters dauert in der Regel etwa 30 Minuten. Wenn der Cluster längere Zeit in der Phase „Warten auf Knotenaktualisierungsjobs“ verbleibt, können Sie den Vorgang mit Ctrl + C beenden. Diese Phase ist der letzte Schritt der Installation. Das Beenden dieses Vorgangs hat keine Auswirkungen auf die Installation.

Erstellung des Nutzerclusters hängt

Das Erstellen eines Nutzerclusters dauert in der Regel etwa zwischen 10 und 30 Minuten. Wenn der Cluster weiterhin nicht aktualisiert wird, können Sie mit den folgenden Befehlen den Fortschritt der Clustererstellung prüfen.

kubectl get pods -n cluster-USER_CLUSTER --kubeconfig=ADMIN_KUBECONFIG
kubectl get Cluster -n cluster-USER_CLUSTER -o yaml --kubeconfig=ADMIN_KUBECONFIG

Upgrade des Administratorclusters der mehrere Knoten der Steuerungsebene hat bleibt hängen

Das Upgrade des Administratorclusters kann beim Upgrade der Knoten der Steuerungsebene hängen bleiben. Der Upgradebefehl bleibt in Waiting for upgrade to complete... Upgrading <control plane node IP>.

Das Problem betrifft den Administratorcluster nur, wenn er mit den folgenden Bedingungen konfiguriert ist:

Die konfigurierte private Registry verwendet ein Zertifikat, das von einer privaten Zertifizierungsstelle signiert wurde.
Der Administratorcluster ist mit mehreren Knoten der Steuerungsebene konfiguriert. Wenn er beispielsweise für Hochverfügbarkeit konfiguriert ist.
Auf den Knoten der Steuerungsebene ist docker installiert.

Das Problem wird durch eine fehlerhafte Konfiguration verursacht, bei der versucht wird, die Registry-Zertifizierungsstellendatei an der falschen Stelle abzurufen. Zur Umgehung dieses Problems müssen Sie die Datei der Zertifizierungsstelle manuell auf jeden Knoten verteilen. Führen Sie auf der Administrator-Workstation zum Beispiel das folgende Skript aus:

#!/bin/bash

# Docker login to generate the $HOME/.docker/config.json file
docker login REGISTRY_HOST

# List the IP addresses for all the control plane nodes, separated by whitespace.
IPs=( NODE_IPS_SEPARATED_BY_SPACE )

for ip in "${IPs[@]}"; do
  # Copy the docker config over to the nodes.
  scp $HOME/.docker/config.json USER_NAME@${ip}:docker-config.json

  # Fix the image pull credentials issue
  ssh USER_NAME@${ip} "sudo mkdir -p /root/.docker && sudo cp docker-config.json /root/.docker/config.json"

  # Fix the cert issue, only needed for private registry with self-signed certs.
  ssh USER_NAME@${ip} "sudo mkdir -p /etc/docker/certs.d && sudo cp -r /etc/containerd/certs.d/REGISTRY_HOST /etc/docker/certs.d/"
done

Ersetzen Sie USER_NAME und REGISTRY_HOST durch die Werte, die in der Administratorclusterkonfiguration konfiguriert sind.

400 Autorisierungsfehler für den Zugriff auf private IP-Adressen

Wenn Sie nach der Einrichtung der OIDC-Authentifizierung (Open ID Connect) weiterhin eine IP-Adresse für den Zugriff auf das Management Center verwenden, werden Sie zur Authentifizierungsseite weitergeleitet und erhalten eine Fehlermeldung im Zusammenhang mit der Autorisierung für den Zugriff auf private IP-Adressen. Beispiel:

Fehlermeldung: Weitere Informationen erhalten Sie vom Administrator.

Führen Sie folgenden Befehl aus, um anstelle der IP auf den konfigurierten Domainnamen zuzugreifen:actl platform management-center describe um die gesamte Adresse abzurufen. Die Domain ist für den Weiterleitungsrückruf erforderlich. Ihre Domain kann auf die private Adresse verweisen.

500-HTTP-Fehlerantwort beim Erstellen des anfänglichen Plattformadministrators

Wenn Sie ein OIDC-Profil auf Cluster anwenden, erhalten Sie nach dem Klicken auf Senden möglicherweise eine 500-HTTP-Fehlerantwort, wenn der Nutzername oder das Gruppenpräfix Ihres Profils das Zeichen „/“ enthält.

Um das Problem zu beheben, löschen Sie dieses Zeichen und erstellen Sie ein neues Profil ohne das Zeichen „/“ im Nutzernamen und Gruppenpräfix. Versuchen Sie dann, das neue Profil auf Cluster anzuwenden.

RBAC: Zugriff verweigert

Wenn Sie RBAC: access denied sehen, nachdem Sie sich mit einem Plattformadministratorkonto angemeldet haben, ist möglicherweise ein Fehler in den OIDC-Einstellungen aufgetreten. Weitere Informationen finden Sie unter Authentifizierungskonfiguration zurücksetzen.

Images aus privater Registry bei Verwendung der Registry-Spiegelkonfiguration nutzen

Wenn der Cluster mit der Registry-Spiegelkonfiguration eingerichtet wurde, notieren Sie sich den Image-Pfad, wenn Sie ein Image direkt aus der privaten Registry verwenden.

Angenommen, der Administratorcluster wird mit folgender Spiegelkonfiguration erstellt:

registryMirrors:
- endpoint: https://10.200.0.2/v2/library

Ein Image wird von docker push 10.200.0.2/library/test-image:test-tag in die private Registry hochgeladen. Beim Erstellen eines Deployments oder Pods kann das Image 10.200.0.2/library/test-image:test-tag nicht direkt unverändert verwendet werden. Das liegt daran, dass die containerd-Konfiguration (/etc/containerd/config.toml) des Knotens so definiert ist, dass alle Image-Abrufe von 10.200.0.2/library gespiegelt werden. Damit versucht containerd, das Image aus 10.200.0.2/library/library/test-image:test-tag abzurufen. Um dieses Problem zu umgehen, führen Sie einen der folgenden Schritte aus:

Übertragen Sie das Image unter dem Endpunkt docker push 10.200.0.2/library/library/test-image:test-tag per Push.
Verwenden Sie den Image-Pfad 10.200.0.2/test-image:test-tag.

Verwaltungscenter kann nicht von 0.8 auf 0.9 aktualisiert werden, wenn OIDC festgelegt ist

Das Upgrade des Verwaltungscenters von 0.8 auf 0.9, wenn OIDC festgelegt ist, schlägt mit der folgenden Fehlermeldung fehl:

level=fatal msg="Unable to initialize options: unable to resolve management center cluster: The given \"management center\" cluster \"admin-admin@admin\" does not appear to be a valid management center cluster.  Did you choose the right cluster?\nunable to list DomainIDPMapping objects: the server could not find the requested resource"

Zur Umgehung dieses Problems erstellen Sie eine Datei mit der DomainIDPMapping-CRD.

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  annotations:
    controller-gen.kubebuilder.io/version: v0.4.0
  creationTimestamp: null
  name: domainidpmappings.managementcenter.anthos.cloud.google.com
spec:
  group: managementcenter.anthos.cloud.google.com
  names:
    kind: DomainIDPMapping
    listKind: DomainIDPMappingList
    plural: domainidpmappings
    singular: domainidpmapping
  scope: Cluster
  versions:
  - name: v1alpha1
    schema:
      openAPIV3Schema:
        description: DomainIDPMapping is the Schema for the domainidpmappings API
        properties:
          apiVersion:
            description: 'APIVersion defines the versioned schema of this representation
              of an object. Servers should convert recognized schemas to the latest
              internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources'
            type: string
          kind:
            description: 'Kind is a string value representing the REST resource this
              object represents. Servers may infer this from the endpoint the client
              submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds'
            type: string
          metadata:
            type: object
          spec:
            description: DomainIDPMappingSpec is the struct that contains the mapping
              from the domain to the authentication method name specified in the AIS
              ClientConfig.
            properties:
              authMethodName:
                description: AuthMethodName is the name of the authentication method
                  configured in the AIS ClientConfig.
                type: string
              domainName:
                description: DomainName is the domain used to serve the Anthos web
                  endpoints. The domain should not include the protocol such as http
                  or https. Wild cards are not supported in the domain name.
                type: string
            required:
            - authMethodName
            - domainName
            type: object
        type: object
    served: true
    storage: true
status:
  acceptedNames:
    kind: ""
    plural: ""
  conditions: []
  storedVersions: []

Wenden Sie die CRD an.

kubectl --kubeconfig=ADMIN_KUBECONFIG apply -f domainIDPMappingCRD.yaml

Löschen Sie den EnvoyFilter und den Namespace "oauth2-proxy".

kubectl --kubeconfig=ADMIN_KUBECONFIG delete envoyfilter istio-ingressgateway -n istio-system
kubectl --kubeconfig=ADMIN_KUBECONFIG delete namespace oauth2-proxy

Fehler beim Abrufen des Images für Pods mit dem Präfix "anthos-log-forwarder“

Wenn --private-registry bei der Installation des Clusters aktiviert ist, wird der von initContainer im anthos-log-forwarder-Pfad verwendete Image-Pfad nicht durch den in --private-registry angegebenen Pfad überschrieben. Dies geschieht nur im Administratorcluster.

Wenn Sie beispielsweise den folgenden Fehler im Administratorcluster beobachten:

kubectl -n kube-system get pods --selector=app=anthos-log-forwarder
anthos-log-forwarder-2n96b                           0/1     Init:ErrImagePull       0          16s
anthos-log-forwarder-8fxm8                           0/1     Init:ErrImagePull       0          16s
anthos-log-forwarder-bh7rb                           0/1     Init:ImagePullBackOff   0          16s

Nur der Administratorcluster mit festgelegtem --private-registry ist von diesem Problem betroffen. Das wird in der nächsten Version behoben.

Pod-Konnektivitätsfehler und Filterung für umgekehrte Pfade

Der private Modus von Anthos konfiguriert die Reverse-Pfadfilterung auf Knoten, um die Quellvalidierung (net.ipv4.conf.all.rp_filter=0) zu deaktivieren. Wenn die Einstellung rp_filter in 1 oder 2 geändert wird, schlagen Pods fehl, da außerhalb der Knoten das Kommunikationszeitlimit überschritten wird.

Die Filterung für umgekehrte Pfade wird mit rp_filter-Dateien im IPv4-Konfigurationsordner (net/ipv4/conf/all) festgelegt. Dieser Wert kann auch von sysctl überschrieben werden. Damit werden Einstellungen der Filterung für umgekehrte Pfade in einer Netzwerksicherheitskonfigurationsdatei gespeichert, z. B. /etc/sysctl.d/60-gce-network-security.conf.

Zur Wiederherstellung der Pod-Verbindung können Sie net.ipv4.conf.all.rp_filter entweder manuell auf 0 zurücksetzen oder den anetd-Pod neu starten, um net.ipv4.conf.all.rp_filter wieder auf 0 zurückzusetzen. Für einen Neustart des anetd-Pods verwenden Sie die folgenden Befehle, um den anetd-Pod zu ermitteln und zu löschen und einen neuen anetd-Pod an seiner Stelle zu starten:

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

Ersetzen Sie ANETD_XYZ durch den Namen des anetd-Pods.

Auf der Seite "Maschinen" werden nach dem Upgrade keine Maschinen aufgelistet

Starten Sie den anthos-cluster-operator-Pod neu.

kubectl --kubeconfig ADMIN_KUBECONFIG delete pods -l control-plane=anthos-cluster-operator -n kube-system

Nutzercluster können nach dem Upgrade nicht bearbeitet werden