Résoudre les problèmes liés à Config Controller

Cette page explique comment résoudre les problèmes liés à Config Controller.

Troubleshoot installation

Aucun réseau nommé par défaut

Lorsque vous créez votre instance Config Controller, vous pouvez recevoir un message d'erreur indiquant que le réseau par défaut n'est pas disponible:

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\"

Cette erreur se produit si vous n'avez pas spécifié de réseau existant avec l'option --network et que votre réseau par défaut dans Google Cloud est supprimé ou désactivé. Par défaut, Config Controller crée le cluster de l'édition Google Kubernetes Engine (GKE) Enterprise qui sauvegarde votre instance Config Controller sur le réseau par défaut.

Si vous souhaitez créer l'instance dans un réseau existant, ajoutez l'option --network=NETWORK lorsque vous créez votre instance Config Controller. Remplacez NETWORK par le nom d'un réseau existant.

Si vous souhaitez créer l'instance Config Controller dans le réseau par défaut, recréez votre réseau par défaut à l'aide de la commande suivante:

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

Pour que cette commande fonctionne, vous devez activer les sous-réseaux automatiques avec l'option --subnet-mode=auto.

Après avoir recréé votre réseau par défaut, vous pouvez omettre l'option --network lorsque vous créez votre instance Config Controller.

Valeur incorrecte pour MasterIpv4CidrBlock

Pour créer Config Controller, nous utilisons un sous-réseau par défaut de 172.16.0.128/28 pour le bloc CIDR IPv4 du plan de contrôle. En cas de conflit dans le bloc CIDR IPv4, la création de Config Controller échoue et l'erreur suivante s'affiche:

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.

Si cette erreur s'affiche, sélectionnez un autre bloc CIDR IPv4 privé et utilisez-le à l'aide de l'option --master-ipv4-cidr-block dans la commande gcloud anthos config controller create.

Pour rechercher les blocs CIDR IPv4 déjà utilisés, procédez comme suit :

  1. Recherchez le nom de l'appairage :

    gcloud compute networks peerings list --network=NETWORK

    Remplacez NETWORK par le nom du réseau que vous souhaitez rechercher.

    Le résultat ressemble à ce qui suit :

    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. Affichez le bloc CIDR IPv4 utilisé par l'appairage :

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

    Remplacez les éléments suivants :

    • PEERING_NAME : nom de l'appairage que vous souhaitez rechercher.
    • NETWORK : nom du réseau que vous souhaitez consulter.
    • REGION: nom de la région dans laquelle se trouve votre instance Config Controller.

Résoudre les problèmes liés à l'exécution de Config Controller

Exécution à partir des adresses IP du pool de nœuds

Si le message d'erreur suivant s'affiche, vos pools de nœuds ne disposent peut-être pas d'adresses IP suffisantes:

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

Ce problème peut se produire si vous omettez l'option --cluster-ipv4-cidr-block. Si vous omettez cette option, Config Controller utilise par défaut la plage CIDR des pods /20. Cette plage vous donne un maximum de 16 nœuds.

Si vous avez besoin de plus de nœuds, supprimez votre instance Config Controller, car vous ne pourrez plus modifier le bloc CIDR après sa création. Lorsque vous recréez l'instance Config Controller, utilisez le paramètre facultatif --cluster-ipv4-cidr-block et spécifiez CIDR range or netmask size.

Informations manquantes dans le tableau de bord

Si vous ne voyez pas d'informations sur Config Controller dans le tableau de bord de la console Google Cloud, il est possible que le compte de service par défaut utilisé par Config Controller ne dispose pas des autorisations d'observabilité Google Cloud dont il a besoin.

Pour accorder ces autorisations, exécutez les commandes suivantes:

# 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"

Remplacez les éléments suivants :

  • PROJECT_ID: ID du projet dans lequel vous avez créé votre instance Config Controller
  • PROJECT_NUMBER: numéro de votre projet Google Cloud

Résoudre les problèmes liés aux composants

Étant donné que Policy Controller, Config Sync et Config Connector sont préinstallés sur votre instance Config Controller, vous pouvez rencontrer des problèmes avec ces composants. Pour savoir comment résoudre les problèmes liés à ces composants, consultez les pages suivantes:

Les sections suivantes fournissent des conseils sur certains des problèmes les plus courants que vous pouvez rencontrer lorsque vous utilisez Config Controller avec ces composants.

Erreurs de synchronisation

Les configurations de votre source de référence (par exemple, un dépôt Git ou une image OCI) sont synchronisées avec votre instance Config Controller à l'aide de Config Sync. Recherchez les erreurs éventuelles dans ce processus de synchronisation à l'aide de la commande nomos status:

nomos status  --contexts $(kubectl config current-context)

Résoudre les problèmes liés aux ressources Config Connector

Champs et ressources immuables

Certains champs des ressources Google Cloud sous-jacentes sont immuables, tels que les ID des projets ou le nom de votre réseau VPC. Config Connector bloque les modifications de ces champs et ne peut pas appliquer les modifications. Si vous souhaitez modifier l'un de ces champs immuables, vous devez supprimer la ressource d'origine (via Git) avant de l'ajouter à nouveau avec les valeurs de votre choix.

Ressources bloquées

Parfois, la suppression des ressources peut échouer (signalée par nomos status). Pour résoudre ce problème, supprimez les finalisateurs de la ressource, puis supprimez-la manuellement.

Par exemple, pour supprimer un IAMPolicyMember bloqué, exécutez la commande suivante:

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

Étapes suivantes