Configurer Config Controller

Cette page vous explique comment configurer Config Controller.

Config Controller fournit un plan de contrôle géré, basé sur Kubernetes. En outre, Policy Controller, Config Sync et Config Connector sont préinstallés sur les instances Config Controller. Grâce à ces composants, vous pouvez exploiter les outils et les workflows de Kubernetes pour gérer les ressources Google Cloud et assurer la cohérence à l'aide d'un workflow GitOps. Pour en savoir plus, consultez la présentation de Config Controller.

Si vous créez une instance Config Controller pour la première fois, consultez la page Démarrage rapide: gérer les ressources avec Config Controller.

Limites

  • Les instances Config Controller étant entièrement gérées, vous ne pouvez pas les enregistrer auprès d'un parc.

Avant de commencer

Avant de configurer Config Controller, procédez comme suit:

  1. Installez et initialisez la CLI Google Cloud, qui fournit la Google Cloud CLI utilisée dans ces instructions. Si vous utilisez Cloud Shell, la Google Cloud CLI est déjà installée.
  2. Comme kubectl n'est pas installé par défaut par la CLI Google Cloud, installez-le:

    gcloud components install kubectl
    
  3. Définissez le projet Google Cloud dans lequel vous souhaitez héberger Config Controller:

    gcloud config set project PROJECT_ID
    

    Remplacez PROJECT_ID par le projet Google Cloud qui hébergera Config Controller.

  4. Activez les API dont vous avez besoin:

    gcloud services enable krmapihosting.googleapis.com \
        anthos.googleapis.com  \
        cloudresourcemanager.googleapis.com \
        serviceusage.googleapis.com
    

Créer une instance Config Controller

Vous pouvez créer une instance Config Controller reposant sur un cluster standard ou un cluster Autopilot. Les deux types de clusters sont privés.

Sélectionnez un cluster standard si vous souhaitez disposer de plus d'options de personnalisation. Sélectionnez un cluster Autopilot si vous souhaitez bénéficier d'une installation plus rapide, de l'autoscaling horizontal et vertical des pods, et de fonctionnalités de sécurité améliorées telles que Container-Optimized OS, les Nœuds GKE protégés, Workload Identity et le Démarrage sécurisé.

  1. Créez une instance Config Controller:

    Standard

    Créez une instance Config Controller reposant sur un cluster GKE standard privé:

    gcloud anthos config controller create CONFIG_CONTROLLER_NAME \
        --location=LOCATION
    

    Remplacez les éléments suivants :

    • CONFIG_CONTROLLER_NAME: nom que vous souhaitez attribuer à votre instance Config Controller.
    • LOCATION : ajoutez l'une des régions suivantes :

      • us-central1
      • us-east1
      • us-east4
      • us-east5
      • us-west2
      • northamerica-northeast1
      • northamerica-northeast2
      • europe-north1
      • europe-west1
      • europe-west3
      • europe-west6
      • australia-southeast1
      • australia-southeast2
      • asia-northeast1
      • asia-northeast2
      • asia-southeast1

      Il s'agit de la région dans laquelle votre instance Config Controller est créée. Aucune autre région n'est acceptée.

    Vous pouvez définir plusieurs paramètres facultatifs lorsque vous créez une instance Config Controller standard. Pour obtenir la liste complète des options, consultez la documentation gcloud anthos config controller create.

    Autopilot

    Pour créer une instance Config Controller reposant sur un cluster GKE Autopilot privé, exécutez la commande suivante:

    gcloud anthos config controller create CONFIG_CONTROLLER_NAME \
        --location=LOCATION \
        --full-management
    

    Remplacez les éléments suivants :

    • CONFIG_CONTROLLER_NAME : nom que vous souhaitez attribuer à votre contrôleur.
    • LOCATION : ajoutez l'une des régions suivantes :

      • us-central1
      • us-east1
      • us-east4
      • us-east5
      • us-west2
      • northamerica-northeast1
      • northamerica-northeast2
      • europe-north1
      • europe-west1
      • europe-west3
      • europe-west6
      • australia-southeast1
      • australia-southeast2
      • asia-northeast1
      • asia-northeast2
      • asia-southeast1

      Aucune autre région n'est acceptée.

    Cette opération peut prendre jusqu'à 15 minutes. Si vous souhaitez observer ce qui se passe lors de la création, vous pouvez afficher l'explorateur de journaux dans la console Google Cloud.

    Accéder à l'explorateur de journaux

    Si vous rencontrez des erreurs lors de la création, consultez la page Résoudre les problèmes liés à Config Controller pour obtenir des conseils sur la résolution des problèmes courants.

  2. Pour vérifier que vos instances Config Controller ont bien été créées, consultez la liste des instances Config Controller:

    gcloud anthos config controller list --location=LOCATION
    

    La valeur RUNNING doit s'afficher dans la colonne d'état. Si l'état est CREATING, votre instance Config Controller est toujours en cours de création et vous devez continuer à attendre. Si ERROR s'affiche, cela signifie que vous avez rencontré un problème que vous ne pouvez pas résoudre vous-même. Contactez l'assistance Google Cloud pour obtenir de l'aide.

  3. Pour communiquer avec le point de terminaison Config Controller, obtenez les identifiants et les informations de point de terminaison appropriés:

    gcloud anthos config controller get-credentials CONFIG_CONTROLLER_NAME \
        --location LOCATION
    

Utiliser votre instance Config Controller

Maintenant que vous avez créé une instance Config Controller, vous pouvez commencer à utiliser les composants installés et effectuer les tâches suivantes:

  • Utilisez Config Connector pour créer des ressources Google Cloud. Si vous souhaitez utiliser des ressources Google Cloud existantes avec Config Controller, découvrez comment acquérir une ressource existante.

  • Utilisez Policy Controller pour appliquer des contraintes qui garantissent la conformité réglementaire et les normes Kubernetes.

  • Après avoir configuré Config Sync, synchronisez votre instance Config Controller avec des configurations (y compris les contraintes Policy Controller et les ressources Config Connector) qui sont stockées dans une source de référence.

Pour obtenir un exemple guidé vous montrant comment effectuer ces tâches avec Config Controller, consultez la page Guide de démarrage rapide: gérer les ressources avec Config Controller.

Configurer votre instance Config Controller

Les sections suivantes expliquent comment configurer les composants de votre instance Config Controller.

Configurer Config Connector

Vous n'avez besoin de gérer aucun paramètre pour l'installation de Config Connector. Toutefois, vous devez accorder des autorisations à Config Controller pour gérer les ressources Google Cloud:

  1. Définissez une variable d'environnement pour l'adresse e-mail de votre compte de service:

    export SA_EMAIL="$(kubectl get ConfigConnectorContext -n config-control \
        -o jsonpath='{.items[0].spec.googleServiceAccount}' 2> /dev/null)"
    
  2. Créez la liaison de stratégie:

    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member "serviceAccount:${SA_EMAIL}" \
        --role "ROLE" \
        --project PROJECT_ID
    

    Remplacez les éléments suivants :

    Si l'opération précédente échoue, vérifiez si les contrôleurs sont prêts:

    kubectl wait pod --all --all-namespaces --for=condition=Ready
    

Une fois ces autorisations accordées, vous pouvez commencer à créer des ressources Google Cloud.

Configurer Policy Controller

La configuration de Policy Controller est facultative, mais vous pouvez modifier l'installation par défaut si nécessaire.

Pour configurer Policy Controller, modifiez les champs spec.policyController de l'objet ConfigManagement nommé config-management. Config Controller crée automatiquement cet objet ConfigManagement lors de l'installation. Lorsque vous modifiez l'objet ConfigManagement, ne définissez pas spec.policyController.enabled sur false. Config Controller ignore automatiquement cette modification. Pour la surveillance, vous devez également autoriser Policy Controller à envoyer des métriques.

Autorisez Policy Controller à envoyer des métriques en exécutant la commande suivante:

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:PROJECT_ID.svc.id.goog[gatekeeper-system/gatekeeper-admin]" \
  --role=roles/monitoring.metricWriter

Remplacez PROJECT_ID par l'ID de projet Google Cloud du cluster.

Configurer Config Sync

Si vous souhaitez que votre instance Config Controller se synchronise à partir des configurations stockées dans une source de référence, vous devez configurer Config Sync.

Si vous souhaitez utiliser Config Sync pour créer des ressources Config Connector, assurez-vous d'avoir également accordé à Config Controller l'autorisation de gérer les ressources.

Pour configurer Config Sync, créez et modifiez un objet RootSync:

  1. Pour effectuer la synchronisation à partir d'un dépôt externe (par exemple, GitHub), configurez Cloud NAT avec GKE. Vous devez effectuer cette opération, car les nœuds de cluster privé ne disposent pas d'un accès Internet sortant.

  2. Enregistrez l'un des fichiers manifestes suivants sous le nom root-sync.yaml. Utilisez la version du fichier manifeste qui correspond au type de source de vos configurations.

    Git

    # root-sync.yaml
    apiVersion: configsync.gke.io/v1beta1
    kind: RootSync
    metadata:
      name: ROOT_SYNC_NAME
      namespace: config-management-system
    spec:
      sourceType: git
      sourceFormat: ROOT_FORMAT
      git:
        repo: ROOT_REPOSITORY
        revision: ROOT_REVISION
        branch: ROOT_BRANCH
        dir: ROOT_DIRECTORY
        auth: ROOT_AUTH_TYPE
        gcpServiceAccountEmail: ROOT_EMAIL
        secretRef:
          name: ROOT_SECRET_NAME
        noSSLVerify: ROOT_NO_SSL_VERIFY
        caCertSecretRef:
          name: ROOT_CA_CERT_SECRET_NAME
    

    Remplacez les éléments suivants :

    • ROOT_SYNC_NAME : ajoutez le nom de votre objet RootSync.
    • ROOT_FORMAT : ajoutez unstructured pour utiliser un dépôt non structuré ou hierarchy pour utiliser un dépôt hiérarchique. Ces valeurs sont sensibles à la casse. Ce champ est facultatif et la valeur par défaut est hierarchy. Nous vous recommandons d'ajouter la valeur unstructured, car ce format vous permet d'organiser vos configurations de la manière la plus adaptée à vos besoins.
    • ROOT_REPOSITORY : ajoutez l'URL du dépôt Git à utiliser comme dépôt racine. Vous pouvez saisir des URL à l'aide du protocole HTTPS ou SSH. Par exemple, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilise le protocole HTTPS. Ce champ est obligatoire.
    • ROOT_REVISION: ajoutez la révision Git (tag ou hachage) à partir de laquelle la synchronisation doit être effectuée. Ce champ est facultatif et la valeur par défaut est HEAD. À partir de la version 1.17.0 de Config Sync, vous pouvez également spécifier un nom de branche dans le champ revision. Lorsque vous utilisez un hachage dans la version 1.17.0 ou ultérieure, il doit s'agir d'un hachage complet et non d'une version abrégée.
    • ROOT_BRANCH: ajoutez la branche du dépôt à partir de laquelle la synchronisation doit être effectuée. Ce champ est facultatif et la valeur par défaut est master. À partir de la version 1.17.0 de Config Sync, il est recommandé d'utiliser le champ revision pour spécifier un nom de branche par souci de simplicité. Si les champs revision et branch sont tous les deux spécifiés, revision prévaut sur branch.
    • ROOT_DIRECTORY : ajoutez le chemin d'accès dans le dépôt Git au répertoire racine contenant la configuration que vous souhaitez synchroniser. Ce champ est facultatif et le paramètre par défaut est le répertoire racine (/) du dépôt.
    • ROOT_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :

      • none : n'utiliser aucune authentification
      • ssh : utiliser une paire de clés SSH
      • cookiefile : utiliser un cookiefile
      • token : utiliser un jeton
      • gcpserviceaccount : utilisez un compte de service Google pour accéder à Cloud Source Repositories.
      • gcenode : utilisez un compte de service Google pour accéder à Cloud Source Repositories. Ne sélectionnez cette option que si Workload Identity n'est pas activé dans votre cluster.

      Pour en savoir plus sur ces types d'authentification, consultez la page Accorder à Config Sync un accès en lecture seule à Git.

      Ce champ est obligatoire.

    • ROOT_EMAIL : si vous avez ajouté gcpserviceaccount comme ROOT_AUTH_TYPE, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple, acm@PROJECT_ID.iam.gserviceaccount.com.

    • ROOT_SECRET_NAME : ajoutez le nom de votre secret. Si ce champ est défini, vous devez ajouter la clé publique du secret au fournisseur Git. Ce champ est facultatif.

    • ROOT_NO_SSL_VERIFY : pour désactiver la validation du certificat SSL, définissez ce champ sur true. La valeur par défaut est false.

    • ROOT_CA_CERT_SECRET_NAME: ajoutez le nom du secret. Si ce champ est défini, votre fournisseur Git doit utiliser un certificat émis par cette autorité de certification. Le secret doit contenir le certificat CA sous une clé nommée cert. Ce champ est facultatif.

      Pour savoir comment configurer l'objet Secret du certificat CA, consultez la page Configurer l'opérateur d'une autorité de certification.

    Pour obtenir une explication des champs et une liste complète des champs que vous pouvez ajouter au champ spec, consultez la section Champs RootSync.

    Ce fichier manifeste crée un objet RootSync qui utilise Git comme source.

    OCI

    # root-sync.yaml
    apiVersion: configsync.gke.io/v1beta1
    kind: RootSync
    metadata:
      name: ROOT_SYNC_NAME
      namespace: config-management-system
    spec:
      sourceType: oci
      sourceFormat: ROOT_FORMAT
      oci:
        image: ROOT_IMAGE
        dir: ROOT_DIRECTORY
        auth: ROOT_AUTH_TYPE
        gcpServiceAccountEmail: ROOT_EMAIL
    

    Remplacez les éléments suivants :

    • ROOT_SYNC_NAME : ajoutez le nom de votre objet RootSync.
    • ROOT_FORMAT : ajoutez unstructured pour utiliser un dépôt non structuré ou hierarchy pour utiliser un dépôt hiérarchique. Ces valeurs sont sensibles à la casse. Ce champ est facultatif et la valeur par défaut est hierarchy. Nous vous recommandons d'ajouter la valeur unstructured, car ce format vous permet d'organiser vos configurations de la manière la plus adaptée à vos besoins.
    • ROOT_IMAGE : URL de l'image OCI à utiliser comme dépôt racine, par exemple LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. Par défaut, l'image est extraite du tag latest, mais vous pouvez récupérer les images par TAG ou DIGEST à la place. Spécifiez TAG ou DIGEST dans PACKAGE_NAME :
      • Pour extraire par TAG : LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
      • Pour extraire par DIGEST : LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
    • ROOT_DIRECTORY : ajoutez le chemin d'accès dans le dépôt au répertoire racine contenant la configuration que vous souhaitez synchroniser. Ce champ est facultatif et le paramètre par défaut est le répertoire racine (/) du dépôt.
    • ROOT_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :

      • none : n'utiliser aucune authentification
      • gcenode: utilisez le compte de service Compute Engine par défaut pour accéder à une image dans Artifact Registry. Ne sélectionnez cette option que si Workload Identity n'est pas activé dans votre cluster.
      • gcpserviceaccount : utilisez un compte de service Google pour accéder à une image.

      Ce champ est obligatoire.

    • ROOT_EMAIL : si vous avez ajouté gcpserviceaccount comme ROOT_AUTH_TYPE, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple, acm@PROJECT_ID.iam.gserviceaccount.com.

    Pour obtenir une explication des champs et une liste complète des champs que vous pouvez ajouter au champ spec, consultez la section Champs RootSync.

    Ce fichier manifeste crée un objet RootSync qui utilise une image OCI comme source.

    Helm

    # root-sync.yaml
    apiVersion: configsync.gke.io/v1beta1
    kind: RootSync
    metadata:
      name: ROOT_SYNC_NAME
      namespace: config-management-system
    spec:
      sourceType: helm
      sourceFormat: ROOT_FORMAT
      helm:
        repo: ROOT_HELM_REPOSITORY
        chart: HELM_CHART_NAME
        version: HELM_CHART_VERSION
        releaseName: HELM_RELEASE_NAME
        namespace: HELM_RELEASE_NAMESPACE
        values:
          foo:
            bar: VALUE_1
          baz:
          - qux: VALUE_2
            xyz: VALUE_3
        includeCRDs: HELM_INCLUDE_CRDS
        auth: ROOT_AUTH_TYPE
          gcpServiceAccountEmail: ROOT_EMAIL
          secretRef:
            name: ROOT_SECRET_NAME
    

    Remplacez les éléments suivants :

    • ROOT_SYNC_NAME : ajoutez le nom de votre objet RootSync.
    • ROOT_FORMAT : ajoutez unstructured pour utiliser un dépôt non structuré ou hierarchy pour utiliser un dépôt hiérarchique. Ces valeurs sont sensibles à la casse. Ce champ est facultatif et la valeur par défaut est hierarchy. Nous vous recommandons d'ajouter la valeur unstructured, car ce format vous permet d'organiser vos configurations de la manière la plus adaptée à vos besoins.
    • ROOT_HELM_REPOSITORY: URL du dépôt Helm à utiliser comme dépôt racine. Vous pouvez saisir des URL à l'aide du protocole HTTPS ou SSH. Par exemple, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilise le protocole HTTPS. Ce champ est obligatoire.
    • HELM_CHART_NAME: ajoutez le nom de votre chart Helm. Ce champ est obligatoire.
    • HELM_CHART_VERSION: version de votre graphique. Ce champ est facultatif. Si aucune valeur n'est spécifiée, la dernière version est utilisée.
    • HELM_RELEASE_NAME: nom de la version de Helm. Ce champ est facultatif.
    • HELM_RELEASE_NAMESPACE: espace de noms cible d'une version. Il ne définit un espace de noms que pour les ressources contenant namespace: {{ .Release.Namespace }} dans leurs modèles. Ce champ est facultatif. Si aucune valeur n'est spécifiée, l'espace de noms par défaut config-management-system est utilisé.
    • HELM_INCLUDE_CRDS: définissez-le sur true si vous souhaitez que le modèle Helm génère également une CustomResourceDefinition. Ce champ est facultatif. Si aucune valeur n'est spécifiée, la valeur par défaut est false, et aucun CRD n'est généré.
    • VALUE: valeurs à utiliser à la place des valeurs par défaut qui accompagnent le graphique Helm. Mettez en forme ce champ de la même manière que le fichier values.yaml du graphique Helm. Ce champ est facultatif.
    • ROOT_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :

      • none : n'utiliser aucune authentification
      • token: utiliser un nom d'utilisateur et un mot de passe pour accéder à un dépôt Helm privé.
      • gcenode: utilisez le compte de service Compute Engine par défaut pour accéder à une image dans Artifact Registry. Ne sélectionnez cette option que si Workload Identity n'est pas activé dans votre cluster.
      • gcpserviceaccount : utilisez un compte de service Google pour accéder à une image.

      Ce champ est obligatoire.

    • ROOT_EMAIL : si vous avez ajouté gcpserviceaccount comme ROOT_AUTH_TYPE, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple, acm@PROJECT_ID.iam.gserviceaccount.com.

    • ROOT_SECRET_NAME: ajoutez le nom de votre secret si token correspond à ROOT_AUTH_TYPE. Ce champ est facultatif.

    Pour obtenir une explication des champs et une liste complète des champs que vous pouvez ajouter au champ spec, consultez la section Champs RootSync.

    Ce fichier manifeste crée un objet RootSync qui utilise Helm comme source.

  3. Pour créer la configuration Config Sync, créez un objet RootSync en appliquant le fichier manifeste:

    kubectl apply -f root-sync.yaml
    
  4. Pour vérifier que vos modifications ont été appliquées, affichez l'objet RootSync:

    kubectl describe rootsync ROOT_SYNC_NAME -n config-management-system
    

Mettre à niveau Config Controller

Étant donné que Config Controller est un service géré, Google le met à niveau automatiquement. Pour en savoir plus sur les nouvelles fonctionnalités et connaître les versions de Config Sync, Policy Controller et Config Connector utilisées par Config Controller, consultez les notes de version de Config Controller.

Supprimer votre instance Config Controller

Si vous décidez de ne plus utiliser une instance Config Controller, nettoyez toutes les ressources Config Connector créées avant de supprimer le cluster Config Controller lui-même.

Si vous supprimez votre instance Config Controller sans supprimer au préalable les ressources provisionnées, celles-ci sont à l'état abandonné. Les ressources existent toujours dans Google Cloud (et entraînent des frais de facturation), mais elles ne sont pas gérées à partir de la configuration déclarative.

Une fois toutes vos ressources supprimées, supprimez votre cluster Config Controller:

gcloud anthos config controller delete \
    --location=LOCATION CONFIG_CONTROLLER_NAME

Considérations relatives à la production

Lorsque vous passez à l'environnement de production, vous devez d'abord consulter les points essentiels à prendre en compte liés à la haute disponibilité pour Config Controller.

Étapes suivantes