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 der Config Controller-Instanz wird möglicherweise eine Fehlermeldung angezeigt, 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. Config Controller erstellt standardmäßig den Cluster der Google Kubernetes Engine (GKE) Enterprise-Version, 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 der 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 Ihr 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 beim Erstellen der Config Controller-Instanz weglassen.

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

    Ersetzen Sie Folgendes:

    • PEERING_NAME: Name des Peerings, das Sie suchen möchten.
    • NETWORK: Name des Netzwerks, das Sie suchen möchten.
    • REGION: der Name der Region, in der sich Ihre Config Controller-Instanz befindet

Probleme beim Ausführen von Config Controller beheben

Knotenpool-IP-Adressen aufgebraucht

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. Für diesen Bereich sind maximal 16 Knoten verfügbar.

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.

Dashboard-Informationen fehlen

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

Verwenden Sie die folgenden Befehle, um diese Berechtigungen zu gewähren:

# 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 Ihre Config Controller-Instanz erstellt haben
  • PROJECT_NUMBER: Ihre Google Cloud-Projektnummer

Fehler bei Komponenten beheben

Da auf Ihrer Config Controller-Instanz Policy Controller, Config Sync und Config Connector vorinstalliert sind, können Probleme mit diesen Komponenten 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