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:
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
Starten Sie den anthos-cluster-operator
-Pod neu.
kubectl --kubeconfig ADMIN_KUBECONFIG delete pods -l control-plane=anthos-cluster-operator -n kube-system