Fehlerbehebung bei Config Controller

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

Troubleshoot installation

Kein Netzwerk mit dem Namen Standard

Beim Erstellen Ihres Config Controller-Instanz 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 Enterprise-Cluster (Google Kubernetes Engine), der Ihre Config Controller-Instanz im Standardnetzwerk unterstützt.

Wenn Sie die Instanz in einem vorhandenen Netzwerk erstellen möchten, fügen Sie beim Erstellen Ihrer Config Controller-Instanz das Flag --network=NETWORK hinzu. Ersetzen Sie NETWORK durch den Namen eines vorhandenen Netzwerks.

Wenn Sie die Config Controller-Instanz 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 Ihre Config Controller-Instanz 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 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=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 Ihre Config Controller-Instanz befindet.

Probleme beim Ausführen von Config Controller beheben

Keine Knotenpool-IP-Adressen mehr

Wenn die folgende Fehlermeldung angezeigt wird, haben Ihre Knotenpools möglicherweise nicht genügend IP-Adressen:

Can't scale up because instances in managed instance groups hosting node pools ran out of IPs

Dieses Problem kann auftreten, wenn Sie das Flag --cluster-ipv4-cidr-block weglassen. Wenn Sie dieses Flag weglassen, verwendet Config Controller standardmäßig den Pod-CIDR-Bereich /20. In diesem Bereich stehen maximal 16 Knoten zur Verfügung.

Wenn Sie mehr Knoten benötigen, löschen Sie Ihre Config Controller-Instanz, da Sie den CIDR-Block nach dem Erstellen nicht mehr ändern können. Verwenden Sie beim Neuerstellen der Config Controller-Instanz den optionalen Parameter --cluster-ipv4-cidr-block und geben Sie CIDR range or netmask size an.

Fehlende Dashboard-Informationen

Wenn Sie im Dashboard der Google Cloud Console keine Details für Config Controller sehen, hat das von Config Controller verwendete Standarddienstkonto möglicherweise nicht die erforderlichen Google Cloud-Beobachtbarkeitsberechtigungen.

Verwenden Sie zum Erteilen dieser Berechtigungen die folgenden Befehle:

# Cloud Monitoring metrics permissions
gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/monitoring.metricWriter \
    --condition=None \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/stackdriver.resourceMetadata.writer \
    --condition=None \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/opsconfigmonitoring.resourceMetadata.writer \
    --condition=None \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com"

# Cloud Logging permissions
gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/logging.logWriter \
    --condition=None \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com"

# Cloud Trace permissions\
gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/cloudtrace.agent \
    --condition=None \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com"

Ersetzen Sie Folgendes:

  • PROJECT_ID: die ID des Projekts, in dem Sie die Config Controller-Instanz erstellt haben
  • PROJECT_NUMBER: Ihre Google Cloud-Projektnummer.

Fehlerbehebung bei Komponenten

Da auf Ihrer Config Controller-Instanz 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:

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 Ihrer Config Controller-Instanz 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

Nächste Schritte