Auf dieser Seite werden bekannte Probleme mit dem privaten Anthos-Modus und Möglichkeiten zur Vermeidung oder Behebung dieser Probleme aufgelistet.
Ein Dienstkonto konnte nicht an die vordefinierte ClusterRole „anthos-platform-admin“ gebunden werden
Sie können ein Dienstkonto nicht an die voreingestellte ClusterRole anthos-platform-admin oder anthos-platform-admin-read-only binden. Einige Berechtigungen müssen vom Subjekt vom Controller dynamisch gewährt werden, der Controller unterstützt jedoch derzeit nur Nutzer und Gruppen.
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.
Weiterleitungsschleife beim Zugriff auf die Anthos Management Center Console
Wenn sich der Browser beim Zugriff auf die Management Center Console in einer Weiterleitungsschleife befindet, nachdem Sie Identitätsanbieter eingerichtet und sich beim Identitätsanbieter angemeldet haben, liegt möglicherweise ein Fehler in den OIDC-Einstellungen vor. Weitere Informationen finden Sie unter Authentifizierungskonfiguration zurücksetzen.
Dies ist in der Regel der Fall, wenn die Nutzername-Anforderung oder Gruppenanforderung nicht in den angeforderten OIDC-Bereichen vorhanden ist. Prüfen Sie das JWT des OIDC-Anbieters, um sicherzustellen, dass beim Einrichten von Identitätsanbietern der richtige Nutzername-Anforderung oder Gruppenanforderung verwendet wird.
Eindeutige Client-IDs beim Konfigurieren von OIDC
Das Problem von nicht eindeutigen Client-IDs kann nach einer erfolgreichen Authentifizierung beim OIDC-Anbieter in einer Weiterleitungsschleife auftreten. Prüfen Sie die Konfiguration des Identitätsanbieters, um festzustellen, ob andere Identitätsanbieter dieselbe Client-ID verwenden:
KUBECONFIG=${ADMIN_KUBECONFIG} kubectl get clientconfig -n kube-public default -oyaml
Wenn doppelte Client-IDs vorhanden sind, bitten Sie Ihren Identitätsanbieter, eine neue Client-ID zu erstellen.
Webseiten nach Ablauf des Autorisierungstokens manuell aktualisieren
Wenn eine Webseite mit Fehlern angezeigt wird und seit Ihrer letzten Anmeldung mindestens eine Stunde (oder je nach Ihren OIDC-Anbietereinstellungen) weniger als eine Stunde vergangen ist, klicken Sie auf die Schaltfläche "Aktualisieren" in Ihrem Browser, um die Webseite vollständig durch ein neues Autorisierungstoken zu aktualisieren. Möglicherweise werden Sie von Ihrem OIDC-Anbieter aufgefordert, sich noch einmal anzumelden.
Fehler beim Erstellen des Administratorclusters
Wenn Sie ein Problem beim Erstellen des Administratorclusters haben, bei dem der Pod kube-proxy im Cluster kind nicht gestartet wird, versuchen Sie, nf_conntrack_max auf der Administrator-Workstation manuell festzulegen. Beispiel:
sudo sysctl -w net.netfilter.nf_conntrack_max=131072