Fehlerbehebung bei Config Controller
Auf dieser Seite erfahren Sie, wie Sie Probleme mit Config Controller beheben.
Fehlerbehebung bei der Config Controller-Installation
Kein Netzwerk mit dem Namen Standard
Beim Erstellen Ihres Config Controller-Clusters erhalten Sie möglicherweise eine Fehlermeldung, dass das Standardnetzwerk nicht verfügbar ist:
Error 400: Project \"PROJECT_ID\" has no network named \"default\"., badRequest\n\n on main.tf line 35, in resource \"google_container_cluster\" \"acp_cluster\"
Dieser Fehler tritt auf, wenn Sie kein vorhandenes Netzwerk mit dem Flag --network
angegeben haben und Ihr Standardnetzwerk in Google Cloud entweder gelöscht oder deaktiviert sind. Standardmäßig erstellt Config Controller den GKE-Cluster, der Ihren Config Controller-Cluster im Standardnetzwerk unterstützt.
Wenn Sie den Cluster in einem vorhandenen Netzwerk erstellen möchten, fügen Sie beim Erstellen Ihres Config Controller-Clusters das Flag --network=NETWORK
hinzu. Ersetzen Sie NETWORK
durch den Namen eines vorhandenen Netzwerks.
Wenn Sie den Config Controller-Cluster im Standardnetzwerk erstellen möchten, erstellen Sie das Standardnetzwerk mit dem folgenden Befehl neu:
gcloud compute networks create default --subnet-mode=auto
Damit dieser Befehl funktioniert, ist die Aktivierung von automatischen Subnetzen mit dem Flag --subnet-mode=auto
erforderlich.
Nachdem Sie Ihr Standardnetzwerk neu erstellt haben, können Sie das Flag --network
weglassen, wenn Sie Ihren Config Controller-Cluster erstellen.
Ungültiger Wert für MasterIpv4CidrBlock
Config Controller-Erstellung verwendet das Standard-Subnetz von 172.16.0.128/28
für das IPv4-CIDR der Steuerebene.
Wenn ein Konflikt im IPv4-CIDR-Block auftritt, schlägt die Erstellung des Config Controllers mit folgendem Fehler fehl:
Cloud SSA\n\nError: Error waiting for creating GKE cluster: Invalid value for field PrivateClusterConfig.MasterIpv4CidrBlock: 172.16.0.128/28 conflicts with an existing subnet in one of the peered VPCs.
Wenn dieser Fehler angezeigt wird, wählen Sie ein anderes privates IPv4-CIDR aus und verwenden es mit dem Flag --master-ipv4-cidr-block
im Befehl gcloud anthos config controller create
.
Führen Sie die folgenden Schritte aus, um bereits verwendete IPv4-CIDR-Blöcke zu finden:
Suchen Sie den Namen des Peerings:
gcloud compute networks peerings list --network=NETWORK
Ersetzen Sie
NETWORK
durch den Namen des Netzwerks, das Sie abrufen möchten.Die Ausgabe sieht in etwa so aus:
NAME NETWORK PEER_PROJECT PEER_NETWORK PEER_MTU IMPORT_CUSTOM_ROUTES EXPORT_CUSTOM_ROUTES STATE STATE_DETAILS gke-n210ce17a4dd120e16b6-7ebf-959a-peer default gke-prod-us-central1-59d2 gke-n210ce17a4dd120e16b6-7ebf-0c27-net False False ACTIVE [2021-06-08T13:22:07.596-07:00]: Connected.
Rufen Sie die vom Peering verwendete IPv4-CIDR auf:
gcloud compute networks peerings list-routes PEERING_NAME \ --direction=INCOMING \ --network=NETWORK \ --region=REGION
Dabei gilt:
PEERING_NAME
: Name des Peerings, das Sie suchen möchten.NETWORK
: Name des Netzwerks, das Sie suchen möchten.REGION
: Name der Region, in der sich Ihr Config Controller-Cluster befindet.
Fehlerbehebung bei Config Controller-Komponenten
Da auf Ihrem Config Controller-Cluster Policy Controller, Config Sync und Config Connector vorinstalliert sind, können bei diesen Komponenten Probleme auftreten. Mehr zur Fehlerbehebung bei diesen Komponenten finden Sie auf den folgenden Seiten:
- Fehlerbehebung bei Policy Controller
- Probleme mit Config Sync beheben
- Fehlerbehebung für Config Connector
In den folgenden Abschnitten finden Sie Hinweise zu einigen der häufigsten Probleme, die bei der Verwendung von Config Controller mit diesen Komponenten auftreten können.
Synchronisierungsfehler
Die Konfigurationen in Ihrer "Source of Truth" (z. B. ein Git-Repository oder ein OCI-Image) werden mit Config Sync mit Ihrem Config Controller-Cluster synchronisiert. Suchen Sie mit dem Befehl nomos status
nach Fehlern in diesem Synchronisierungsprozess:
nomos status --contexts $(kubectl config current-context)
Fehler bei Config Connector-Ressourcen beheben
Unveränderliche Felder und Ressourcen
Einige Felder in den zugrunde liegenden Google Cloud-Ressourcen sind unveränderlich, z. B. Projekt-IDs oder der Name Ihres VPC-Netzwerks. Config Connector blockiert Bearbeitungen an solchen Feldern und kann keine Änderungen vornehmen. Wenn Sie eines dieser unveränderlichen Felder bearbeiten möchten, müssen Sie die ursprüngliche Ressource (über Git) löschen, bevor Sie es noch einmal mit Ihren bevorzugten Werten hinzufügen.
Festhängende Ressourcen
Manchmal können Ressourcen nicht korrekt gelöscht werden (wie von nomos
status
gemeldet). Sie können dieses Problem beheben, indem Sie die Finalizer für die Ressource entfernen und die Ressource dann manuell löschen.
Führen Sie beispielsweise den folgenden Befehl aus, um ein hängendes IAMPolicyMember zu löschen:
kubectl patch IAMPolicyMember logging-sa-iam-permissions \
-p '{"metadata":{"finalizers":[]}}' --type=merge -n config-control
kubectl delete IAMPolicyMember logging-sa-iam-permissions -n config-control