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 tirer parti des outils et des 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 le Guide de 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 Google Cloud CLI, qui fournit la Google Cloud CLI utilisée dans ces instructions. Si vous utilisez Cloud Shell, Google Cloud CLI est déjà installé.

  2. Comme kubectl n'est pas installé par défaut par Google Cloud CLI, 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 davantage d'options de personnalisation. Sélectionnez un cluster Autopilot si vous souhaitez une installation plus rapide, un autoscaling horizontal et vertical des pods, et des 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 de Config Controller qui s'appuie 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-west1
      • us-west2
      • us-west3
      • us-west4
      • us-south1
      • northamerica-northeast1
      • northamerica-northeast2
      • southamerica-west1
      • southamerica-east1
      • europe-north1
      • europe-west1
      • europe-west3
      • europe-west4
      • europe-west6
      • europe-west9
      • europe-west10
      • europe-west-12
      • europe-central2
      • europe-southwest1
      • australia-southeast1
      • australia-southeast2
      • asia-east1
      • asia-east2
      • asia-northeast1
      • asia-northeast2
      • asia-northeast3
      • asia-southeast1
      • asia-southeast2
      • asia-south1
      • asia-south2
      • africa-south1
      • me-west1
      • me-central1

      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 pendant 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, affichez la liste des instances Config Controller :

    gcloud anthos config controller list --location=LOCATION

    La valeur RUNNING doit s'afficher dans la colonne "État". Si l'état est CREATING, votre instance Config Controller est toujours en cours de création et vous devez continuer à attendre. Si vous voyez ERROR, vous avez rencontré un problème que vous ne pouvez pas résoudre vous-même. En cas de besoin, contactez l'assistance Google Cloud.

  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, consultez la page Acquérir une ressource existante.

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

  • Après avoir configuré Config Sync, dans la section suivante, synchronisez votre instance Config Controller avec les configurations (y compris les contraintes Policy Controller et ressources Config Connector) qui sont stockées dans une source fiable.

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 pas à gérer de paramètres pour l'installation de Config Connector. Cependant, vous devez autoriser Config Controller à 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 que 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 remplace 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 de configurations stockées dans une source fiable, vous devez configurer Config Sync.

Si vous souhaitez utiliser Config Sync pour créer des ressources Config Connector, assurez-vous que vous avez également autorisé Config Controller à 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 procéder ainsi, 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 correspondant 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 valeur de 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 forme 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 afin de spécifier un nom de branche pour plus de simplicité. Si les champs revision et branch sont spécifiés, revision est prioritaire 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 de votre secret. Si ce champ est défini, votre fournisseur Git doit utiliser un certificat émis par cette autorité de certification (CA). Le secret doit contenir le certificat de l'autorité de certification sous une clé nommée cert. Ce champ est facultatif.

      Pour en savoir plus sur la configuration de l'objet Secret du certificat CA, consultez la page Configurer l'opérateur ConfigManagement pour 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
    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_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.

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

    Pour en savoir plus sur la configuration de l'objet Secret du certificat CA, consultez la page Configurer l'opérateur ConfigManagement pour 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 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
    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_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 chart. 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 dont les modèles contiennent namespace: {{ .Release.Namespace }}. 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 cette valeur sur true si vous souhaitez que le modèle Helm génère également un objet CustomResourceDefinition. Ce champ est facultatif. Si aucune valeur n'est spécifiée, la valeur par défaut est false et aucun objet CRD n'est généré.
    • VALUE : valeurs à utiliser à la place des valeurs par défaut qui accompagnent le chart Helm. Mettez en forme ce champ de la même manière que le fichier values.yaml du chart Helm. Ce champ est facultatif.

    • ROOT_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :

      • none : n'utiliser aucune authentification
      • token : utilisez 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 est le ROOT_AUTH_TYPE. Ce champ est facultatif.

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

    Pour en savoir plus sur la configuration de l'objet Secret du certificat CA, consultez la page Configurer l'opérateur ConfigManagement pour 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 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 découvrir 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 d'arrêter d'utiliser une instance Config Controller, nettoyez toutes les ressources Config Connector créées avant de supprimer le cluster Config Controller lui-même.

Supprimez votre instance Config Controller sans d'abord supprimer les ressources provisionnées laisse les ressources dans un état abandonné. Les ressources existent toujours dans Google Cloud (et entraînent des frais de facturation), mais 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