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:

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 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.
   

2. 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