Fehlerbehebung bei Config Controller

Auf dieser Seite erfahren Sie, wie Sie Probleme mit Config Controller beheben.

Standardnetzwerk nicht verfügbar

Beim Erstellen Ihres Config Controllers 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, weil Config Controller vom Standardnetzwerk in Google Cloud abhängt. Um dieses Problem zu beheben, sollten Sie ein neues Standardnetzwerk erstellen:

gcloud compute networks create default --subnet-mode=auto

Alternativ können Sie mit dem Flag --network im Befehl gcloud anthos config controller create ein anderes Netzwerk auswählen.

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 im IPv4-CIDR-Block ein Konflikt 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 config controller create.

Führen Sie die folgenden Schritte aus, um bereits verwendete IPv4-CIDR-Blöcke zu finden:

  1. 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 entsprechende Ausgabe sieht 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.
    
  2. Rufen Sie die vom Peering verwendete IPv4-CIDR auf:

    gcloud compute networks peerings list-routes PEERING_NAME \
        --direction=INCOMING \
        --network=NETWORK \
        --region=us-central1
    

    Dabei gilt:

    • PEERING_NAME: Name des Peerings, das Sie suchen möchten.
    • NETWORK: Name des Netzwerks, das Sie suchen möchten.

Synchronisierungsfehler

Die Konfigurationen in Ihrem Git-Repository werden mit Config Sync mit Ihrem Config Controller synchronisiert. Mit dem Befehl nomos status können Sie in diesem Synchronisierungsprozess nach Fehlern suchen:

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 zuerst die ursprüngliche Ressource (über Git) löschen, bevor Sie sie wieder mit den neuen bevorzugten Werten hinzufügen.

Festhängende Ressourcen

In einigen Fällen werden Ressourcen möglicherweise nicht richtig gelöscht (wie von nomos status gemeldet). Sie können dies 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 festhä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