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 :
- 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é.
Comme
kubectl
n'est pas installé par défaut par Google Cloud CLI, installez-le :gcloud components install kubectl
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.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é
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.
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 estCREATING
, votre instance Config Controller est toujours en cours de création et vous devez continuer à attendre. Si vous voyezERROR
, 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.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 :
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)"
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 :
PROJECT_ID
: ID de votre projet.ROLE
: ensemble de rôles prédéfinis ou de rôles personnalisés répondant à vos besoins. Vous pouvez également utiliserroles/owner
pour les environnements hors production. Pour en savoir plus sur les autorisations IAM de Config Controller, consultez la page Autorisations IAM pour Config Controller.
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 :
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.
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
: ajoutezunstructured
pour utiliser un dépôt non structuré ouhierarchy
pour utiliser un dépôt hiérarchique. Ces valeurs sont sensibles à la casse. Ce champ est facultatif et la valeur par défaut esthierarchy
. Nous vous recommandons d'ajouter la valeurunstructured
, 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 estHEAD
. À partir de la version 1.17.0 de Config Sync, vous pouvez également spécifier un nom de branche dans le champrevision
. 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 estmaster
. À partir de la version 1.17.0 de Config Sync, il est recommandé d'utiliser le champrevision
afin de spécifier un nom de branche pour plus de simplicité. Si les champsrevision
etbranch
sont spécifiés,revision
est prioritaire surbranch
.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 authentificationssh
: utiliser une paire de clés SSHcookiefile
: utiliser uncookiefile
token
: utiliser un jetongcpserviceaccount
: 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
commeROOT_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 surtrue
. La valeur par défaut estfalse
.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éecert
. 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
: ajoutezunstructured
pour utiliser un dépôt non structuré ouhierarchy
pour utiliser un dépôt hiérarchique. Ces valeurs sont sensibles à la casse. Ce champ est facultatif et la valeur par défaut esthierarchy
. Nous vous recommandons d'ajouter la valeurunstructured
, 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 exempleLOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME
. Par défaut, l'image est extraite du taglatest
, mais vous pouvez récupérer les images parTAG
ouDIGEST
à la place. SpécifiezTAG
ouDIGEST
dansPACKAGE_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
- Pour extraire par
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 authentificationgcenode
: 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
commeROOT_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éecert
. 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
: ajoutezunstructured
pour utiliser un dépôt non structuré ouhierarchy
pour utiliser un dépôt hiérarchique. Ces valeurs sont sensibles à la casse. Ce champ est facultatif et la valeur par défaut esthierarchy
. Nous vous recommandons d'ajouter la valeurunstructured
, 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 contiennentnamespace: {{ .Release.Namespace }}
. Ce champ est facultatif. Si aucune valeur n'est spécifiée, l'espace de noms par défautconfig-management-system
est utilisé.HELM_INCLUDE_CRDS
: définissez cette valeur surtrue
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 estfalse
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 authentificationtoken
: 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
commeROOT_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 sitoken
est leROOT_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éecert
. 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.Pour créer la configuration Config Sync, créez un objet RootSync en appliquant le fichier manifeste :
kubectl apply -f root-sync.yaml
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
- Découvrez les bonnes pratiques pour l'évolutivité de Config Controller.
- Résoudre les problèmes liés à Config Controller.
- Accédez à l'assistance.
- Découvrez comment synchroniser des configurations et des règles avec Config Sync.
- Découvrez comment appliquer des règles avec Policy Controller.
- Apprenez-en davantage sur les ressources de Config Connector.