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"

Lors de la création de 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 Cloudest supprimé ou désactivé. Par défaut, Config Controller crée le cluster Google Kubernetes Engine (GKE) Enterprise qui s'appuie sur votre instance Config Controller dans 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'indicateur --subnet-mode=auto.

Une fois que vous avez recréé votre réseau par défaut, vous pouvez omettre l'indicateur --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 avec l'erreur suivante :

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 lors de l'exécution de Config Controller

Plus d'adresses IP de pool de nœuds

Si le message d'erreur suivant s'affiche, il est possible que vos pools de nœuds ne disposent pas suffisamment d'adresses IP :

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'indicateur --cluster-ipv4-cidr-block. Lorsque vous omettez cet indicateur, le contrôleur de configuration utilise par défaut la plage CIDR du pod /20. Cette plage vous permet de disposer d'un maximum de 16 nœuds.

Si vous avez besoin de plus de nœuds, supprimez votre instance Config Controller, car vous ne pouvez pas 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 aucun détail de Config Controller dans le tableau de bord de la Google Cloud console, le compte de service par défaut utilisé par Config Controller peut ne pas disposer des autorisations Google Cloud Observability 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: votre numéro de projet Google Cloud

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

Étant donné que votre instance Config Controller est préinstallée avec Policy Controller, Config Sync et Config Connector, 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 vérité (par exemple, un dépôt Git ou une image OCI) sont synchronisées sur votre instance Config Controller avec Config Sync. Recherchez les erreurs 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 Google Cloud ressources sous-jacentes sont immuables, tels que les ID de projet 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 d'abord 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 (comme indiqué par nomos status). Pour résoudre ce problème, supprimez les finaliseurs de la ressource, puis supprimez la ressource manuellement.

Par exemple, pour supprimer un membre 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