Cette page explique comment configurer plusieurs sources de vérité à l'échelle de la racine et de l'espace de noms en créant des objets RootSync et RepoSync.
Disposer d'une source de vérité racine vous permet de synchroniser les configurations appliquées au niveau du cluster et au niveau de l'espace de noms. Une source de vérité racine peut utiliser des identifiants de niveau administrateur pour appliquer des règles sur les espaces de noms de l'application et remplacer les modifications locales qui dépassent l'état que vous avez déclaré dans vos configurations. Un administrateur central régit généralement les sources de vérité racine.
Les sources de vérité à l'échelle d'un espace de noms sont facultatives et peuvent contenir des configurations à l'échelle d'un espace de noms synchronisées avec un espace de noms particulier sur plusieurs clusters. Vous pouvez déléguer la configuration et le contrôle d'une source de vérité à l'échelle d'un espace de noms à des utilisateurs non administrateurs. Bien que Config Sync détecte automatiquement les modifications de la source de vérité, vous pouvez ajouter une couche de détection de dérive supplémentaire en ajoutant un webhook d'admission à une source de vérité à l'échelle de l'espace de noms. Pour en savoir plus, consultez la section Éviter les dérives de configuration.
Avant de commencer
- Créez une source de vérité non structurée pouvant contenir les configurations avec lesquelles Config Sync se synchronise, ou assurez-vous d'y avoir accès. Config Sync est compatible avec les dépôts Git, les charts Helm et les images OCI en tant que source de vérité. Les sources de vérité à l'échelle d'un espace de noms doivent utiliser le format non structuré.
- Créez un cluster situé sur une plate-forme et une version compatibles de l'édition Google Kubernetes Engine (GKE) Enterprise, ou assurez-vous d'y avoir accès, et qui répond à la configuration requise pour Config Sync.
Limites
NamespaceSelectors
(y compris les annotations pointant vers des sélecteurs) ne fonctionnent que dans une source de vérité racine.- Si vous avez installé Config Sync à l'aide de la console Google Cloud ou de Google Cloud CLI, Config Sync a créé automatiquement un objet RootSync appelé
root-sync
. Par conséquent, vous ne pouvez pas nommer vos objets RootSyncroot-sync
.
Choisir la méthode de configuration appropriée
Choisissez l'une des deux méthodes de configuration des sources :
Contrôler les sources dans une source de vérité racine Cette méthode centralise la configuration d'une source de vérité dans une autre source de vérité, permettant ainsi à un administrateur central de contrôler entièrement la configuration.
Contrôler les sources avec l'API Kubernetes Utilisez cette méthode si vous souhaitez déléguer le contrôle de votre source de vérité à différents propriétaires.
Contrôler les sources dans une source de vérité racine
Contrôler les sources racines dans une source de vérité racine
Config Sync accepte la synchronisation à partir de plusieurs sources de vérité. L'administrateur central peut utiliser une source de vérité racine pour gérer toutes les autres sources. Étant donné que Config Sync gère les objets RootSync, cette méthode empêche toute modification locale des configurations RootSync dans le cluster.
Pour utiliser cette méthode, effectuez les tâches suivantes :
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 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 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 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.Effectuez un commit des modifications dans la source de vérité racine :
git add . git commit -m 'Setting up a new root source of truth.' git push
Vous pouvez répéter les étapes ci-dessus si vous devez configurer plusieurs sources racines. Vous pouvez également stocker les configurations de plusieurs objets RootSync dans une source de vérité racine synchronisée par un autre objet RootSync, afin de gérer plusieurs objets RootSync de manière centralisée en mode GitOps.
Contrôler des objets à l'échelle d'un espace de noms dans une source de vérité racine
Les sources de vérité à l'échelle d'un espace de noms peuvent être gérées par une source de vérité racine. Étant donné que les sources à l'échelle d'un espace de noms sont gérées par Config Sync, cette méthode empêche toute modification locale des définitions sources à l'échelle de l'espace de noms.
Pour utiliser cette méthode, effectuez les tâches suivantes :
Dans la source de vérité racine, déclarez une configuration
namespace
:# ROOT_SOURCE/namespaces/NAMESPACE/namespace.yaml apiVersion: v1 kind: Namespace metadata: name: NAMESPACE
Remplacez
NAMESPACE
par le nom de votre espace de noms.Dans la source de vérité racine, créez l'un des objets
RepoSync
suivants dans le même espace de noms. Utilisez le fichier manifeste correspondant au type de source pour vos configurations :Git
#ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml apiVersion: configsync.gke.io/v1beta1 kind: RepoSync metadata: name: REPO_SYNC_NAME namespace: NAMESPACE spec: sourceType: git # Since this is for a namespace repository, the format is unstructured sourceFormat: unstructured git: repo: NAMESPACE_REPOSITORY revision: NAMESPACE_REVISION branch: NAMESPACE_BRANCH dir: "NAMESPACE_DIRECTORY" auth: NAMESPACE_AUTH_TYPE gcpServiceAccountEmail: NAMESPACE_EMAIL secretRef: name: NAMESPACE_SECRET_NAME noSSLVerify: NAMESPACE_NO_SSL_VERIFY caCertSecretRef: name: NAMESPACE_CA_CERT_SECRET_NAME
Remplacez les éléments suivants :
REPO_SYNC_NAME
: ajoutez le nom de votre objet RepoSync. Le nom doit être unique dans l'espace de noms.NAMESPACE
: ajoutez le nom de votre espace de noms.NAMESPACE_REPOSITORY
: ajoutez l'URL du dépôt Git à utiliser comme dépôt de l'espace de noms. 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. Si vous ne saisissez pas de protocole, l'URL est traitée comme une URL HTTPS. Ce champ est obligatoire.NAMESPACE_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.NAMESPACE_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
.NAMESPACE_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
: utiliser un compte de service Google pour accéder à un dépôt dans Cloud Source Repositoriesgcenode
: utiliser un compte de service Google pour accéder à un dépôt dans 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.
NAMESPACE_EMAIL
: si vous avez ajoutégcpserviceaccount
commeNAMESPACE_AUTH_TYPE
, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple,acm@PROJECT_ID.iam.gserviceaccount.com
.NAMESPACE_SECRET_NAME
: ajoutez le nom que vous souhaitez donner à votre Secret. Ce champ est facultatif.NAMESPACE_NO_SSL_VERIFY
: pour désactiver la validation du certificat SSL, définissez ce champ surtrue
. La valeur par défaut estfalse
.NAMESPACE_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 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 RepoSync.OCI
# ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml apiVersion: configsync.gke.io/v1beta1 kind: RepoSync metadata: name: REPO_SYNC_NAME namespace: NAMESPACE spec: sourceType: oci # Since this is for a namespace repository, the format is unstructured sourceFormat: unstructured oci: image: NAMESPACE_IMAGE dir: NAMESPACE_DIRECTORY auth: NAMESPACE_AUTH_TYPE gcpServiceAccountEmail: NAMESPACE_EMAIL caCertSecretRef: name: NAMESPACE_CA_CERT_SECRET_NAME
Remplacez les éléments suivants :
REPO_SYNC_NAME
: ajoutez le nom de votre objet RepoSync. Le nom doit être unique dans l'espace de noms.NAMESPACE
: ajoutez le nom de votre espace de noms.NAMESPACE_IMAGE
: URL de l'image OCI à utiliser comme source d'espace de noms, 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
NAMESPACE_DIRECTORY
: ajoutez le chemin d'accès dans la source 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 (/
) de la source.NAMESPACE_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.
NAMESPACE_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
.NAMESPACE_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 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.Helm
# ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml apiVersion: configsync.gke.io/v1beta1 kind: RepoSync metadata: name: REPO_SYNC_NAME namespace: NAMESPACE spec: sourceType: helm # Since this is for a namespace repository, the format is unstructured sourceFormat: unstructured helm: repo: NAMESPACE_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: NAMESPACE_AUTH_TYPE gcpServiceAccountEmail: NAMESPACE_EMAIL secretRef: name: NAMESPACE_SECRET_NAME caCertSecretRef: name: NAMESPACE_CA_CERT_SECRET_NAME
Remplacez les éléments suivants :
REPO_SYNC_NAME
: ajoutez le nom de votre objet RepoSync. Le nom doit être unique dans l'espace de noms.NAMESPACE
: ajoutez le nom de votre espace de noms.NAMESPACE_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.
NAMESPACE_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
.NAMESPACE_SECRET_NAME
: ajoutez le nom de votre secret sitoken
est leROOT_AUTH_TYPE
. Ce champ est facultatif.NAMESPACE_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 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.Si vous utilisez
gcpserviceaccount
comme type d'authentification et que Workload Identity n'est pas activé, vous devez créer une liaison de stratégie IAM entre le compte de service Kubernetes pour chaque espace de noms et le compte de service Google. Pour savoir comment créer cette liaison, consultez la section Accorder l'accès à Git.Dans la source racine, déclarez une configuration
RoleBinding
qui accorde au compte de serviceSERVICE_ACCOUNT_NAME
l'autorisation de gérer des objets dans l'espace de noms. Config Sync crée automatiquement le compte de serviceSERVICE_ACCOUNT_NAME
lorsque la configuration RepoSync est synchronisée avec le cluster.Un
RoleBinding
peut faire référence à uneRole
dans le même espace de noms. UnRoleBinding
peut également référencer unClusterRole
et lier ceClusterRole
à l'espace de noms deRoleBinding
. Bien que vous deviez respecter le principe du moindre privilège en accordant des autorisations précises à une ressourceRole
définie par l'utilisateur, vous pouvez définir unClusterRole
ou utiliser des rôles d'utilisateur, et référencer le mêmeClusterRole
dans plusieursRoleBindings
dans différents espaces de noms.Objets ClusterRole par défaut
Vous pouvez déclarer un
RoleBinding
en faisant référence à unClusterRole
par défaut, par exempleadmin
ouedit
. Pour en savoir plus, consultez la section Rôles pour les utilisateurs.# ROOT_REPO/namespaces/NAMESPACE/sync-rolebinding.yaml kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: syncs-repo namespace: NAMESPACE subjects: - kind: ServiceAccount name: SERVICE_ACCOUNT_NAME namespace: config-management-system roleRef: kind: ClusterRole name: CLUSTERROLE_NAME apiGroup: rbac.authorization.k8s.io
Remplacez les éléments suivants :
NAMESPACE
: ajoutez le nom de votre espace de noms.SERVICE_ACCOUNT_NAME
: ajoutez le nom du compte de service du rapprochement. Si le nom RepoSync estrepo-sync
,SERVICE_ACCOUNT_NAME
estns-reconciler-NAMESPACE
. Sinon, il est défini surns-reconciler-NAMESPACE-REPO_SYNC_NAME-REPO_SYNC_NAME_LENGTH
. Par exemple, si le nom de votre objet RepoSync estprod
, le champSERVICE_ACCOUNT_NAME
seraitns-reconciler-NAMESPACE-prod-4
. L'entier4
est utilisé, carprod
contient quatre caractères.CLUSTERROLE_NAME
: ajoutez le nom du ClusterRole par défaut.
Rôles définis par l'utilisateur
Vous pouvez déclarer un objet
ClusterRole
ouRole
en accordant une liste d'autorisations à chaque ressource gérée par l'objetRepoSync
. Cela permet des autorisations précises. Pour en savoir plus, consultez la section Référencer des ressources.Par exemple, l'élément
ClusterRole
ouRole
suivant accorde des autorisations pour gérer les objetsDeployment
etServiceAccount
.# ROOT_REPO/namespaces/NAMESPACE/sync-role.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ROLE_KIND metadata: namespace: NAMESPACE # only set this field for a 'Role' name: RECONCILER_ROLE rules: # Update 'apiGroups' and 'resources' to reference actual resources managed by 'RepoSync'. - apiGroups: ["apps"] resources: ["deployments"] verbs: ["*"] - apiGroups: [""] resources: ["serviceaccounts"] verbs: ["*"]
Pour déclarer un
RoleBinding
faisant référence àClusterRole
ouRole
, créez l'objet suivant. Le rôleRoleBinding
accorde des autorisations supplémentaires pour permettre à Config Sync de gérer les ressources à l'échelle de l'espace de noms pour une ressourceRepoSync
.# ROOT_REPO/namespaces/NAMESPACE/sync-rolebinding.yaml kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: syncs-repo namespace: NAMESPACE subjects: - kind: ServiceAccount name: SERVICE_ACCOUNT_NAME namespace: config-management-system roleRef: kind: ROLE_KIND name: RECONCILER_ROLE apiGroup: rbac.authorization.k8s.io
Remplacez les éléments suivants :
ROLE_KIND
: définissezClusterRole
ouRole
.NAMESPACE
: ajoutez le nom de votre espace de noms.SERVICE_ACCOUNT_NAME
: ajoutez le nom du compte de service du rapprochement. Si le nom RepoSync estrepo-sync
,SERVICE_ACCOUNT_NAME
estns-reconciler-NAMESPACE
. Sinon, il est défini surns-reconciler-NAMESPACE-REPO_SYNC_NAME-REPO_SYNC_NAME_LENGTH
. Par exemple, si le nom de votre objet RepoSync estprod
, le champSERVICE_ACCOUNT_NAME
seraitns-reconciler-NAMESPACE-prod-4
. L'entier4
est utilisé, carprod
contient quatre caractères.RECONCILER_ROLE
: ajoutez le nom de l'objetClusterRole
ouRole
.
Effectuez un commit des modifications dans la source de vérité racine :
git add . git commit -m 'Setting up a new namespace-scoped source of truth.' git push
Si nécessaire, créez un secret basé sur la méthode d'authentification de votre choix. Si vous avez utilisé
none
comme type d'authentification, vous pouvez ignorer cette étape.Le Secret doit répondre aux exigences suivantes :
- Créez le Secret dans le même espace de noms que l'objet RepoSync.
- Le nom du Secret doit correspondre au nom
spec.git.secretRef
que vous avez défini dansrepo-sync.yaml
. - Vous devez ajouter la clé publique du Secret au fournisseur Git.
Pour vérifier la configuration, utilisez
kubectl get
sur l'un des objets de la source d'espaces de noms. Exemple :kubectl get rolebindings -n NAMESPACE
Vous pouvez répéter les étapes ci-dessus si vous devez configurer plusieurs sources à l'échelle d'un espace de noms.
Contrôler les sources à l'échelle d'un espace de noms dans une source à l'échelle d'un espace de noms
Config Sync accepte la synchronisation à partir de plusieurs sources de vérité à l'échelle d'un espace de noms par espace de noms. Les sources de vérité à l'échelle d'un espace de noms peuvent être gérées dans une source de vérité à l'échelle d'un espace de noms dans le même espace de noms.
Pour utiliser cette méthode, effectuez les tâches suivantes :
Dans la source de vérité à l'échelle de l'espace de noms, créez l'un des objets
RepoSync
suivants dans le même espace de noms. Utilisez le fichier manifeste correspondant au type de source pour vos configurations :Git
#ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml apiVersion: configsync.gke.io/v1beta1 kind: RepoSync metadata: name: REPO_SYNC_NAME namespace: NAMESPACE spec: sourceType: git # Since this is for a namespace repository, the format is unstructured sourceFormat: unstructured git: repo: NAMESPACE_REPOSITORY revision: NAMESPACE_REVISION branch: NAMESPACE_BRANCH dir: "NAMESPACE_DIRECTORY" auth: NAMESPACE_AUTH_TYPE gcpServiceAccountEmail: NAMESPACE_EMAIL secretRef: name: NAMESPACE_SECRET_NAME noSSLVerify: NAMESPACE_NO_SSL_VERIFY caCertSecretRef: name: NAMESPACE_CA_CERT_SECRET_NAME
Remplacez les éléments suivants :
REPO_SYNC_NAME
: ajoutez le nom de votre objet RepoSync. Le nom doit être unique dans l'espace de noms.NAMESPACE
: ajoutez le nom de votre espace de noms.NAMESPACE_REPOSITORY
: ajoutez l'URL du dépôt Git à utiliser comme dépôt de l'espace de noms. 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. Si vous ne saisissez pas de protocole, l'URL est traitée comme une URL HTTPS. Ce champ est obligatoire.NAMESPACE_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.NAMESPACE_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
.NAMESPACE_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
: utiliser un compte de service Google pour accéder à un dépôt dans Cloud Source Repositoriesgcenode
: utiliser un compte de service Google pour accéder à un dépôt dans 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.
NAMESPACE_EMAIL
: si vous avez ajoutégcpserviceaccount
commeNAMESPACE_AUTH_TYPE
, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple,acm@PROJECT_ID.iam.gserviceaccount.com
.NAMESPACE_SECRET_NAME
: ajoutez le nom que vous souhaitez donner à votre Secret. Ce champ est facultatif.NAMESPACE_NO_SSL_VERIFY
: pour désactiver la validation du certificat SSL, définissez ce champ surtrue
. La valeur par défaut estfalse
.NAMESPACE_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 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 RepoSync.OCI
# ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml apiVersion: configsync.gke.io/v1beta1 kind: RepoSync metadata: name: REPO_SYNC_NAME namespace: NAMESPACE spec: sourceType: oci # Since this is for a namespace repository, the format is unstructured sourceFormat: unstructured oci: image: NAMESPACE_IMAGE dir: NAMESPACE_DIRECTORY auth: NAMESPACE_AUTH_TYPE gcpServiceAccountEmail: NAMESPACE_EMAIL caCertSecretRef: name: NAMESPACE_CA_CERT_SECRET_NAME
Remplacez les éléments suivants :
REPO_SYNC_NAME
: ajoutez le nom de votre objet RepoSync. Le nom doit être unique dans l'espace de noms.NAMESPACE
: ajoutez le nom de votre espace de noms.NAMESPACE_IMAGE
: URL de l'image OCI à utiliser comme source d'espace de noms, 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
NAMESPACE_DIRECTORY
: ajoutez le chemin d'accès dans la source 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 (/
) de la source.NAMESPACE_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.
NAMESPACE_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
.NAMESPACE_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 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.Helm
# ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml apiVersion: configsync.gke.io/v1beta1 kind: RepoSync metadata: name: REPO_SYNC_NAME namespace: NAMESPACE spec: sourceType: helm # Since this is for a namespace repository, the format is unstructured sourceFormat: unstructured helm: repo: NAMESPACE_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: NAMESPACE_AUTH_TYPE gcpServiceAccountEmail: NAMESPACE_EMAIL secretRef: name: NAMESPACE_SECRET_NAME caCertSecretRef: name: NAMESPACE_CA_CERT_SECRET_NAME
Remplacez les éléments suivants :
REPO_SYNC_NAME
: ajoutez le nom de votre objet RepoSync. Le nom doit être unique dans l'espace de noms.NAMESPACE
: ajoutez le nom de votre espace de noms.NAMESPACE_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.
NAMESPACE_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
.NAMESPACE_SECRET_NAME
: ajoutez le nom de votre secret sitoken
est leROOT_AUTH_TYPE
. Ce champ est facultatif.NAMESPACE_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 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.Si vous utilisez
gcpserviceaccount
comme type d'authentification et que Workload Identity n'est pas activé, vous devez créer une liaison de stratégie IAM entre le compte de service Kubernetes pour chaque espace de noms et le compte de service Google. Pour savoir comment créer cette liaison, consultez la section Accorder l'accès à Git.Dans la source racine, déclarez une configuration
RoleBinding
qui accorde au compte de serviceSERVICE_ACCOUNT_NAME
l'autorisation de gérer des objets dans l'espace de noms. Config Sync crée automatiquement le compte de serviceSERVICE_ACCOUNT_NAME
lorsque la configuration RepoSync est synchronisée avec le cluster.Un
RoleBinding
peut faire référence à uneRole
dans le même espace de noms. UnRoleBinding
peut également référencer unClusterRole
et lier ceClusterRole
à l'espace de noms deRoleBinding
. Bien que vous deviez respecter le principe du moindre privilège en accordant des autorisations précises à une ressourceRole
définie par l'utilisateur, vous pouvez définir unClusterRole
ou utiliser des rôles d'utilisateur, et référencer le mêmeClusterRole
dans plusieursRoleBindings
dans différents espaces de noms.Objets ClusterRole par défaut
Vous pouvez déclarer un
RoleBinding
en faisant référence à unClusterRole
par défaut, par exempleadmin
ouedit
. Pour en savoir plus, consultez la section Rôles pour les utilisateurs.# ROOT_REPO/namespaces/NAMESPACE/sync-rolebinding.yaml kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: syncs-repo namespace: NAMESPACE subjects: - kind: ServiceAccount name: SERVICE_ACCOUNT_NAME namespace: config-management-system roleRef: kind: ClusterRole name: CLUSTERROLE_NAME apiGroup: rbac.authorization.k8s.io
Remplacez les éléments suivants :
NAMESPACE
: ajoutez le nom de votre espace de noms.SERVICE_ACCOUNT_NAME
: ajoutez le nom du compte de service du rapprochement. Si le nom RepoSync estrepo-sync
,SERVICE_ACCOUNT_NAME
estns-reconciler-NAMESPACE
. Sinon, il est défini surns-reconciler-NAMESPACE-REPO_SYNC_NAME-REPO_SYNC_NAME_LENGTH
. Par exemple, si le nom de votre objet RepoSync estprod
, le champSERVICE_ACCOUNT_NAME
seraitns-reconciler-NAMESPACE-prod-4
. L'entier4
est utilisé, carprod
contient quatre caractères.CLUSTERROLE_NAME
: ajoutez le nom du ClusterRole par défaut.
Rôles définis par l'utilisateur
Vous pouvez déclarer un objet
ClusterRole
ouRole
en accordant une liste d'autorisations à chaque ressource gérée par l'objetRepoSync
. Cela permet des autorisations précises. Pour en savoir plus, consultez la section Référencer des ressources.Par exemple, l'élément
ClusterRole
ouRole
suivant accorde des autorisations pour gérer les objetsDeployment
etServiceAccount
.# ROOT_REPO/namespaces/NAMESPACE/sync-role.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ROLE_KIND metadata: namespace: NAMESPACE # only set this field for a 'Role' name: RECONCILER_ROLE rules: # Update 'apiGroups' and 'resources' to reference actual resources managed by 'RepoSync'. - apiGroups: ["apps"] resources: ["deployments"] verbs: ["*"] - apiGroups: [""] resources: ["serviceaccounts"] verbs: ["*"]
Pour déclarer un
RoleBinding
faisant référence àClusterRole
ouRole
, créez l'objet suivant. Le rôleRoleBinding
accorde des autorisations supplémentaires pour permettre à Config Sync de gérer les ressources à l'échelle de l'espace de noms pour une ressourceRepoSync
.# ROOT_REPO/namespaces/NAMESPACE/sync-rolebinding.yaml kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: syncs-repo namespace: NAMESPACE subjects: - kind: ServiceAccount name: SERVICE_ACCOUNT_NAME namespace: config-management-system roleRef: kind: ROLE_KIND name: RECONCILER_ROLE apiGroup: rbac.authorization.k8s.io
Remplacez les éléments suivants :
ROLE_KIND
: définissezClusterRole
ouRole
.NAMESPACE
: ajoutez le nom de votre espace de noms.SERVICE_ACCOUNT_NAME
: ajoutez le nom du compte de service du rapprochement. Si le nom RepoSync estrepo-sync
,SERVICE_ACCOUNT_NAME
estns-reconciler-NAMESPACE
. Sinon, il est défini surns-reconciler-NAMESPACE-REPO_SYNC_NAME-REPO_SYNC_NAME_LENGTH
. Par exemple, si le nom de votre objet RepoSync estprod
, le champSERVICE_ACCOUNT_NAME
seraitns-reconciler-NAMESPACE-prod-4
. L'entier4
est utilisé, carprod
contient quatre caractères.RECONCILER_ROLE
: ajoutez le nom de l'objetClusterRole
ouRole
.
Effectuez un commit des modifications dans la source de vérité racine :
git add . git commit -m 'Setting up a new namespace-scoped source of truth.' git push
Si nécessaire, créez un secret basé sur la méthode d'authentification de votre choix. Si vous avez utilisé
none
comme type d'authentification, vous pouvez ignorer cette étape.Le Secret doit répondre aux exigences suivantes :
- Créez le Secret dans le même espace de noms que l'objet RepoSync.
- Le nom du Secret doit correspondre au nom
spec.git.secretRef
que vous avez défini dansrepo-sync.yaml
. - Vous devez ajouter la clé publique du Secret au fournisseur Git.
Pour vérifier la configuration, utilisez
kubectl get
sur l'un des objets de la source de vérité à l'échelle d'un espace de noms. Exemple :kubectl get rolebindings -n NAMESPACE
Vous pouvez répéter les étapes ci-dessus si vous devez configurer plusieurs sources à l'échelle d'un espace de noms.
Contrôler une source de vérité avec l'API Kubernetes
Dans cette méthode, l'administrateur central délègue la déclaration des autres objets RootSync
à d'autres administrateurs. Pour les objets RepoSync
, l'administrateur central ne déclare que l'espace de noms dans la source de vérité racine et délègue la déclaration de l'objet RepoSync
à l'opérateur d'application.
Contrôler plusieurs sources de vérité racines
Les autres administrateurs peuvent contrôler une source de vérité racine en effectuant les tâches suivantes :
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 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 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 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.Appliquez les modifications :
kubectl apply -f root-sync.yaml
Vous pouvez répéter les étapes ci-dessus si vous devez configurer plusieurs sources de vérité.
Contrôler les sources de vérité à l'échelle de l'espace de noms
Tâches administratives centrales
L'administrateur central effectue les tâches suivantes :
Dans la source de vérité racine, déclarez une configuration
namespace
pour les sources à l'échelle d'un espace de noms.# ROOT_REPO/namespaces/NAMESPACE/namespace.yaml apiVersion: v1 kind: Namespace metadata: name: NAMESPACE
Remplacez
NAMESPACE
par le nom de votre espace de noms.Dans la source de vérité racine, déclarez un
RoleBinding
pour accorder les autorisations aux opérateurs d'application. Utilisez la prévention de l'élévation RBAC pour vous assurer que l'opérateur d'application ne pourra pas appliquer ultérieurement une liaison de rôle avec des autorisations non accordées par cette liaison de rôle.Pour déclarer l'objet RoleBinding, créez le fichier manifeste suivant :
# ROOT_REPO/namespaces/NAMESPACE/operator-rolebinding.yaml kind: RoleBinding # Add RBAC escalation prevention apiVersion: rbac.authorization.k8s.io/v1 metadata: name: operator namespace: NAMESPACE subjects: - kind: User name: USERNAME apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: OPERATOR_ROLE apiGroup: rbac.authorization.k8s.io
Remplacez les éléments suivants :
NAMESPACE
: ajoutez l'espace de noms que vous avez créé dans la source de vérité racine.USERNAME
: ajoutez le nom d'utilisateur de l'opérateur d'application.OPERATOR_ROLE
: en tant qu'administrateur central, vous pouvez définirOPERATOR_ROLE
pour appliquer les types de configuration pouvant être synchronisés à partir de la source d'espaces de noms. Vous pouvez choisir l'un des rôles suivants :Un ClusterRole par défaut :
admin
edit
Pour en savoir plus, consultez la section Rôles pour les utilisateurs.
Un objet ClusterRole ou Role défini par l'utilisateur déclaré dans la source de vérité racine. Ce rôle permet des autorisations précises.
Effectuez un commit des modifications dans la source de vérité racine :
git add . git commit -m 'Setting up new namespace-scoped source of truth.' git push
Tâches de l'opérateur d'application
L'opérateur d'application peut contrôler les sources de portée d'espace de noms en effectuant les tâches suivantes :
Déclarez une configuration
RoleBinding
qui accorde au compte de serviceSERVICE_ACCOUNT_NAME
provisionné automatiquement l'autorisation de gérer les objets de l'espace de noms. Config Sync crée automatiquement le compte de serviceSERVICE_ACCOUNT_NAME
lorsque la configurationRepoSync
est synchronisée avec le cluster.Pour déclarer l'objet RoleBinding, créez le fichier manifeste suivant :
# sync-rolebinding.yaml kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: syncs-repo namespace: NAMESPACE subjects: - kind: ServiceAccount name: SERVICE_ACCOUNT_NAME namespace: config-management-system roleRef: kind: ClusterRole name: RECONCILER_ROLE apiGroup: rbac.authorization.k8s.io
Remplacez les éléments suivants :
NAMESPACE
: ajoutez l'espace de noms que vous avez créé dans la source de vérité racine.SERVICE_ACCOUNT_NAME
: ajoutez le nom du compte de service du rapprochement. Si le nom RepoSync estrepo-sync
,SERVICE_ACCOUNT_NAME
estns-reconciler-NAMESPACE
. Sinon, il est défini surns-reconciler-NAMESPACE-REPO_SYNC_NAME
.RECONCILER_ROLE
: en tant qu'opérateur d'application, vous pouvez définirRECONCILER_ROLE
pour appliquer les types de configuration pouvant être synchronisés à partir de la source d'espaces de noms. Vous ne pouvez restreindre davantage l'ensemble d'autorisations que l'administrateur central vous a accordées. Par conséquent, ce rôle ne peut pas être plus permissif queOPERATOR_ROLE
que l'administrateur central a déclaré dans la section précédente.
Appliquez la configuration RoleBinding :
kubectl apply -f sync-rolebinding.yaml
Si nécessaire, créez un secret basé sur la méthode d'authentification de votre choix. Si vous avez utilisé
none
comme type d'authentification, vous pouvez ignorer cette étape.Le Secret doit répondre aux exigences suivantes :
- Créez le Secret dans le même espace de noms que l'objet RepoSync.
- Le nom du Secret doit correspondre au nom
spec.git.secretRef
que vous avez défini dansroot-sync.yaml
. - Vous devez ajouter la clé publique du Secret au fournisseur Git.
Déclarez une configuration
RepoSync
:Git
#ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml apiVersion: configsync.gke.io/v1beta1 kind: RepoSync metadata: name: REPO_SYNC_NAME namespace: NAMESPACE spec: sourceType: git # Since this is for a namespace repository, the format is unstructured sourceFormat: unstructured git: repo: NAMESPACE_REPOSITORY revision: NAMESPACE_REVISION branch: NAMESPACE_BRANCH dir: "NAMESPACE_DIRECTORY" auth: NAMESPACE_AUTH_TYPE gcpServiceAccountEmail: NAMESPACE_EMAIL secretRef: name: NAMESPACE_SECRET_NAME noSSLVerify: NAMESPACE_NO_SSL_VERIFY caCertSecretRef: name: NAMESPACE_CA_CERT_SECRET_NAME
Remplacez les éléments suivants :
REPO_SYNC_NAME
: ajoutez le nom de votre objet RepoSync. Le nom doit être unique dans l'espace de noms.NAMESPACE
: ajoutez le nom de votre espace de noms.NAMESPACE_REPOSITORY
: ajoutez l'URL du dépôt Git à utiliser comme dépôt de l'espace de noms. 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. Si vous ne saisissez pas de protocole, l'URL est traitée comme une URL HTTPS. Ce champ est obligatoire.NAMESPACE_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.NAMESPACE_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
.NAMESPACE_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
: utiliser un compte de service Google pour accéder à un dépôt dans Cloud Source Repositoriesgcenode
: utiliser un compte de service Google pour accéder à un dépôt dans 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.
NAMESPACE_EMAIL
: si vous avez ajoutégcpserviceaccount
commeNAMESPACE_AUTH_TYPE
, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple,acm@PROJECT_ID.iam.gserviceaccount.com
.NAMESPACE_SECRET_NAME
: ajoutez le nom que vous souhaitez donner à votre Secret. Ce champ est facultatif.NAMESPACE_NO_SSL_VERIFY
: pour désactiver la validation du certificat SSL, définissez ce champ surtrue
. La valeur par défaut estfalse
.NAMESPACE_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 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 RepoSync.OCI
# ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml apiVersion: configsync.gke.io/v1beta1 kind: RepoSync metadata: name: REPO_SYNC_NAME namespace: NAMESPACE spec: sourceType: oci # Since this is for a namespace repository, the format is unstructured sourceFormat: unstructured oci: image: NAMESPACE_IMAGE dir: NAMESPACE_DIRECTORY auth: NAMESPACE_AUTH_TYPE gcpServiceAccountEmail: NAMESPACE_EMAIL caCertSecretRef: name: NAMESPACE_CA_CERT_SECRET_NAME
Remplacez les éléments suivants :
REPO_SYNC_NAME
: ajoutez le nom de votre objet RepoSync. Le nom doit être unique dans l'espace de noms.NAMESPACE
: ajoutez le nom de votre espace de noms.NAMESPACE_IMAGE
: URL de l'image OCI à utiliser comme source d'espace de noms, 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
NAMESPACE_DIRECTORY
: ajoutez le chemin d'accès dans la source 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 (/
) de la source.NAMESPACE_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.
NAMESPACE_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
.NAMESPACE_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 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.Helm
# ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml apiVersion: configsync.gke.io/v1beta1 kind: RepoSync metadata: name: REPO_SYNC_NAME namespace: NAMESPACE spec: sourceType: helm # Since this is for a namespace repository, the format is unstructured sourceFormat: unstructured helm: repo: NAMESPACE_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: NAMESPACE_AUTH_TYPE gcpServiceAccountEmail: NAMESPACE_EMAIL secretRef: name: NAMESPACE_SECRET_NAME caCertSecretRef: name: NAMESPACE_CA_CERT_SECRET_NAME
Remplacez les éléments suivants :
REPO_SYNC_NAME
: ajoutez le nom de votre objet RepoSync. Le nom doit être unique dans l'espace de noms.NAMESPACE
: ajoutez le nom de votre espace de noms.NAMESPACE_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.
NAMESPACE_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
.NAMESPACE_SECRET_NAME
: ajoutez le nom de votre secret sitoken
est leROOT_AUTH_TYPE
. Ce champ est facultatif.NAMESPACE_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 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.Appliquez la configuration
RepoSync
:kubectl apply -f repo-sync.yaml
Pour vérifier la configuration, utilisez
kubectl get
sur l'un des objets de la source à l'échelle d'un espace de noms. Exemple :kubectl get rolebindings -n NAMESPACE
Vous pouvez répéter les étapes ci-dessus si vous devez configurer plusieurs sources de vérité à l'échelle d'un espace de noms.
Vérifier l'état de synchronisation de la source de vérité
Vous pouvez utiliser la commande nomos status
pour inspecter l'état de synchronisation de la source de vérité :
nomos status
Un résultat semblable aux lignes suivantes doit s'afficher :
my_managed_cluster-1
--------------------
<root> git@github.com:foo-corp/acme/admin@main
SYNCED f52a11e4
--------------------
bookstore git@github.com:foo-corp/acme/bookstore@v1
SYNCED 34d1a8c8
Dans cet exemple de résultat, la source à l'échelle d'un espace de noms, dans le cas présent un dépôt Git, est configurée pour un espace de noms nommé bookstore
.
Vérifier l'installation de RootSync
Lorsque vous créez un objet RootSync, Config Sync crée un rapprochement avec le préfixe root-reconciler
. Un rapprochement est un pod qui est déployé en tant que déploiement.
Il synchronise les fichiers manifestes d'une source de vérité avec un cluster.
Vous pouvez vérifier que l'objet RootSync fonctionne correctement en vérifiant l'état du déploiement du rapprochement racine :
kubectl get -n config-management-system deployment \
-l configsync.gke.io/sync-name=ROOT_SYNC_NAME
Remplacez ROOT_SYNC_NAME
par le nom de RootSync.
Un résultat semblable aux lignes suivantes doit s'afficher :
NAME READY UP-TO-DATE AVAILABLE AGE
root-reconciler 1/1 1 1 3h42m
Pour découvrir d'autres moyens d'explorer l'état de votre objet RootSync, consultez la page Surveiller les objets RootSync et RepoSync.
Vérifier l'installation de RepoSync
Lorsque vous créez un objet RepoSync, Config Sync crée un rapprochement avec le préfixe ns-reconciler-NAMESPACE
, où NAMESPACE
est l'espace de noms dans lequel vous avez créé votre objet RepoSync.
Vous pouvez vérifier que l'objet RepoSync fonctionne correctement en vérifiant l'état du déploiement du rapprochement de l'espace de noms :
kubectl get -n config-management-system deployment \
-l configsync.gke.io/sync-name=REPO_SYNC_NAME \
-l configsync.gke.io/sync-namespace=NAMESPACE
Remplacez REPO_SYNC_NAME
par le nom de RepoSync et remplacez NAMESPACE
par l'espace de noms dans lequel vous avez créé votre source de vérité à l'échelle de l'espace de noms.
Pour analyser plus en détail l'état de votre objet RepoSync, consultez la section Explorer les objets RootSync et RepoSync.
Supprimer une source de vérité
Sélectionnez l'onglet Méthode de contrôle centralisé ou Méthode de l'API Kubernetes pour afficher les instructions correspondantes.
Méthode de contrôle centralisé
Si vous avez utilisé la méthode Contrôler les sources de vérité dans une source de vérité racine, un administrateur central peut suivre les deux étapes suivantes pour supprimer une source de vérité :
Décidez si vous souhaitez supprimer ou conserver les ressources gérées via vos objets RootSync et RepoSync.
Pour supprimer toutes les ressources gérées par vos objets RootSync ou RepoSync, synchronisez votre objet RootSync ou RepoSync avec une source vide. Par exemple, un dépôt GitHub sans configuration. Si votre objet RootSync ou RepoSync contient un autre objet RootSync ou RepoSync, l'objet RootSync ou le RepoSync interne doit d'abord être synchronisé avec un dépôt Git vide.
Si vous avez activé le webhook et que vous souhaitez conserver vos ressources, désactivez la protection contre les dérives pour les ressources abandonnées. Si vous n'avez pas activé le webhook, vous n'avez pas besoin d'effectuer des étapes supplémentaires pour conserver vos ressources.
Supprimez l'objet RootSync ou RepoSync de la source de vérité.
Méthode de l'API Kubernetes
Si vous avez utilisé la méthode Contrôler les sources de vérité à l'échelle d'un espace de noms avec l'API Kubernetes, les opérateurs d'application peuvent procéder comme suit pour supprimer une source de vérité à l'échelle de l'espace de noms :
Décidez si vous souhaitez supprimer ou conserver les ressources gérées via vos objets RootSync et RepoSync.
Pour supprimer toutes les ressources gérées par vos objets RootSync ou RepoSync, synchronisez votre objet RootSync ou RepoSync avec une source vide. Par exemple, un dépôt GitHub sans configuration. Si votre objet RootSync ou RepoSync contient un autre objet RootSync ou RepoSync, l'objet RootSync ou le RepoSync interne doit d'abord être synchronisé avec un dépôt Git vide.
Si vous avez activé le webhook et que vous souhaitez conserver vos ressources, désactivez la protection contre les dérives pour les ressources abandonnées. Si vous n'avez pas activé le webhook, vous n'avez pas besoin d'effectuer des étapes supplémentaires pour conserver vos ressources.
Supprimez l'objet RootSync ou RepoSync en exécutant la commande suivante :
kubectl delete -f FILE_NAME
Remplacez
FILE_NAME
par le nom de votre fichier de configuration RootSync ou RepoSync. Exemple :root-sync.yaml
Étapes suivantes
- Découvrez comment empêcher les dérives de configuration dans les sources de vérité à l'échelle de l'espace de noms.
- Découvrez comment surveiller vos objets RootSync et RepoSync.
- Découvrez comment scinder une source de vérité en plusieurs sources de vérités.