Configurer la synchronisation à partir de plusieurs sources de référence

Cette page explique comment configurer plusieurs sources de référence racines et à l'échelle d'un espace de noms en créant des objets RootSync et RepoSync.

Le fait de disposer d'une source de référence racine vous permet de synchroniser les configurations à l'échelle d'un cluster et à l'échelle d'un espace de noms. Une source racine fiable peut utiliser des identifiants de niveau administrateur pour appliquer des règles sur les espaces de noms d'application et remplacer les modifications locales qui dérivent de l'état que vous avez déclaré dans vos configurations. Un administrateur central régit généralement les sources racines de vérité.

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 provenant de la source de référence, vous pouvez ajouter une couche supplémentaire de détection des dérives en ajoutant un webhook d'admission à une source de référence à l'échelle d'un espace de noms. Pour savoir comment procéder, consultez Éviter les écarts de configuration.

Avant de commencer

Créez ou assurez-vous d'avoir accès à une source fiable non structurée pouvant contenir les configurations avec lesquelles Config Sync se synchronise. Config Sync est compatible avec les dépôts Git, les charts Helm et les images OCI comme source de référence. Les sources de référence à l'échelle d'un espace de noms doivent utiliser le format non structuré.
Créez ou assurez-vous d'avoir accès à un cluster qui se trouve sur une plate-forme et une version compatibles de l'édition Google Kubernetes Engine (GKE) Enterprise, et qui répond aux exigences pour Config Sync.

Limites

NamespaceSelectors (y compris les annotations pointant vers des sélecteurs) ne fonctionne que dans une source de référence 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 nommé root-sync. C'est pourquoi vous ne pouvez nommer aucun de vos objets RootSync root-sync.

Choisir la méthode de configuration appropriée

Choisissez l'une des deux méthodes de configuration des sources:

Contrôlez les sources dans une source de référence racine. Cette méthode centralise toute la configuration d'une source fiable dans une autre source de référence, ce qui permet à un administrateur central de contrôler totalement la configuration.
Contrôlez les sources avec l'API Kubernetes. Utilisez cette méthode si vous souhaitez déléguer le contrôle de votre source de référence à différents propriétaires.

Contrôlez les sources dans une source de référence racine

Contrôlez les sources racine dans une source de référence racine

Config Sync prend en charge la synchronisation à partir de plusieurs sources de référence. 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 : ajoutez unstructured pour utiliser un dépôt non structuré ou hierarchy pour utiliser un dépôt hiérarchique. Ces valeurs sont sensibles à la casse. Ce champ est facultatif et la valeur par défaut est hierarchy. Nous vous recommandons d'ajouter la valeur unstructured, car ce format vous permet d'organiser vos configurations de la manière la plus adaptée à vos besoins.
- ROOT_REPOSITORY : ajoutez l'URL du dépôt Git à utiliser comme dépôt racine. Vous pouvez saisir des URL à l'aide du protocole HTTPS ou SSH. Par exemple, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilise le protocole HTTPS. Ce champ est obligatoire.
- ROOT_REVISION: ajoutez la révision Git (tag ou hachage) à partir de laquelle la synchronisation doit être effectuée. Ce champ est facultatif et la valeur par défaut est HEAD. À partir de la version 1.17.0 de Config Sync, vous pouvez également spécifier un nom de branche dans le champ revision. Lorsque vous utilisez un hachage dans la version 1.17.0 ou ultérieure, il doit s'agir d'un hachage complet et non d'une version abrégée.
- ROOT_BRANCH: ajoutez la branche du dépôt à partir de laquelle la synchronisation doit être effectuée. Ce champ est facultatif et la valeur par défaut est master. À partir de la version 1.17.0 de Config Sync, il est recommandé d'utiliser le champ revision pour spécifier un nom de branche pour plus de simplicité. Si les champs revision et branch sont tous les deux spécifiés, revision est prioritaire sur branch.
- ROOT_DIRECTORY : ajoutez le chemin d'accès dans le dépôt Git au répertoire racine contenant la configuration que vous souhaitez synchroniser. Ce champ est facultatif et le paramètre par défaut est le répertoire racine (/) du dépôt.
- ROOT_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :
  - none : n'utiliser aucune authentification
  - ssh : utiliser une paire de clés SSH
  - cookiefile : utiliser un cookiefile
  - token : utiliser un jeton
  - gcpserviceaccount : utilisez un compte de service Google pour accéder à Cloud Source Repositories.
  - gcenode : utilisez un compte de service Google pour accéder à Cloud Source Repositories. Ne sélectionnez cette option que si Workload Identity n'est pas activé dans votre cluster.
  Pour en savoir plus sur ces types d'authentification, consultez la page Accorder à Config Sync un accès en lecture seule à Git.
  
  Ce champ est obligatoire.
- ROOT_EMAIL : si vous avez ajouté gcpserviceaccount comme ROOT_AUTH_TYPE, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple, acm@PROJECT_ID.iam.gserviceaccount.com.
- ROOT_SECRET_NAME : ajoutez le nom de votre secret. Si ce champ est défini, vous devez ajouter la clé publique du secret au fournisseur Git. Ce champ est facultatif.
- ROOT_NO_SSL_VERIFY : pour désactiver la validation du certificat SSL, définissez ce champ sur true. La valeur par défaut est false.
- ROOT_CA_CERT_SECRET_NAME: ajoutez le nom de votre secret. Si ce champ est défini, votre fournisseur Git doit utiliser un certificat émis par cette autorité de certification. Le secret doit contenir le certificat CA sous une clé nommée cert. Ce champ est facultatif.
  
  Pour en savoir plus sur la configuration de l'objet Secret du certificat CA, consultez 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
```
Remplacez les éléments suivants :
- ROOT_SYNC_NAME : ajoutez le nom de votre objet RootSync.
- ROOT_FORMAT : ajoutez unstructured pour utiliser un dépôt non structuré ou hierarchy pour utiliser un dépôt hiérarchique. Ces valeurs sont sensibles à la casse. Ce champ est facultatif et la valeur par défaut est hierarchy. Nous vous recommandons d'ajouter la valeur unstructured, car ce format vous permet d'organiser vos configurations de la manière la plus adaptée à vos besoins.
- ROOT_IMAGE : URL de l'image OCI à utiliser comme dépôt racine, par exemple LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. Par défaut, l'image est extraite du tag latest, mais vous pouvez récupérer les images par TAG ou DIGEST à la place. Spécifiez TAG ou DIGEST dans PACKAGE_NAME :
  - Pour extraire par TAG : LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
  - Pour extraire par DIGEST : LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
Attention :Config Sync nécessite que la couche OCI soit compressée dans tar ou tar+gzip. Les autres formats (par exemple, tar+bz2) ne seront pas reconnus par Config Sync. Si vous passez d'un dépôt valide à une image OCI dans un format non compatible, les ressources gérées sont éliminées sans erreur.
- ROOT_DIRECTORY : ajoutez le chemin d'accès dans le dépôt au répertoire racine contenant la configuration que vous souhaitez synchroniser. Ce champ est facultatif et le paramètre par défaut est le répertoire racine (/) du dépôt.
- ROOT_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :
  - none : n'utiliser aucune authentification
  - gcenode: utilisez le compte de service par défaut de Compute Engine pour accéder à une image dans Artifact Registry. Ne sélectionnez cette option que si Workload Identity n'est pas activé dans votre cluster.
  - gcpserviceaccount : utilisez un compte de service Google pour accéder à une image.
  Ce champ est obligatoire.
- ROOT_EMAIL : si vous avez ajouté gcpserviceaccount comme ROOT_AUTH_TYPE, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple, acm@PROJECT_ID.iam.gserviceaccount.com.
Pour obtenir une explication des champs et une liste complète des champs que vous pouvez ajouter au champ spec, consultez la section Champs RootSync.

Ce fichier manifeste crée un objet RootSync qui utilise une image OCI comme source.
Helm
```
# root-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: ROOT_SYNC_NAME
  namespace: config-management-system
spec:
  sourceType: helm
  sourceFormat: ROOT_FORMAT
  helm:
    repo: ROOT_HELM_REPOSITORY
    chart: HELM_CHART_NAME
    version: HELM_CHART_VERSION
    releaseName: HELM_RELEASE_NAME
    namespace: HELM_RELEASE_NAMESPACE
    values:
      foo:
        bar: VALUE_1
      baz:
      - qux: VALUE_2
        xyz: VALUE_3
    includeCRDs: HELM_INCLUDE_CRDS
    auth: ROOT_AUTH_TYPE
      gcpServiceAccountEmail: ROOT_EMAIL
      secretRef:
        name: ROOT_SECRET_NAME
```
Remplacez les éléments suivants :
- ROOT_SYNC_NAME : ajoutez le nom de votre objet RootSync.
- ROOT_FORMAT : ajoutez unstructured pour utiliser un dépôt non structuré ou hierarchy pour utiliser un dépôt hiérarchique. Ces valeurs sont sensibles à la casse. Ce champ est facultatif et la valeur par défaut est hierarchy. Nous vous recommandons d'ajouter la valeur unstructured, car ce format vous permet d'organiser vos configurations de la manière la plus adaptée à vos besoins.
- ROOT_HELM_REPOSITORY: URL du dépôt Helm à utiliser comme dépôt racine. Vous pouvez saisir des URL à l'aide du protocole HTTPS ou SSH. Par exemple, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilise le protocole HTTPS. Ce champ est obligatoire.
- HELM_CHART_NAME: ajoutez le nom de votre chart Helm. Ce champ est obligatoire.
- HELM_CHART_VERSION: version de votre graphique. Ce champ est facultatif. Si aucune valeur n'est spécifiée, la dernière version est utilisée.
- HELM_RELEASE_NAME: nom de la version de Helm. Ce champ est facultatif.
- HELM_RELEASE_NAMESPACE: espace de noms cible d'une version. Il ne définit un espace de noms que pour les ressources dont le modèle contient namespace: {{ .Release.Namespace }}. Ce champ est facultatif. Si aucune valeur n'est spécifiée, l'espace de noms par défaut config-management-system est utilisé.
- HELM_INCLUDE_CRDS: définissez cet attribut sur true si vous souhaitez que le modèle Helm génère également un objet CustomResourceDefinition. Ce champ est facultatif. Si aucune valeur n'est spécifiée, la valeur par défaut est false, et aucun objet CRD n'est généré.
- VALUE: valeurs à utiliser à la place des valeurs par défaut qui accompagnent le graphique Helm. Mettez en forme ce champ de la même manière que le fichier helm chart's values.yaml. Ce champ est facultatif.
- ROOT_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :
  - none : n'utiliser aucune authentification
  - token: utilisez un nom d'utilisateur et un mot de passe pour accéder à un dépôt Helm privé.
  - gcenode: utilisez le compte de service par défaut de Compute Engine pour accéder à une image dans Artifact Registry. Ne sélectionnez cette option que si Workload Identity n'est pas activé dans votre cluster.
  - gcpserviceaccount : utilisez un compte de service Google pour accéder à une image.
  Ce champ est obligatoire.
- ROOT_EMAIL : si vous avez ajouté gcpserviceaccount comme ROOT_AUTH_TYPE, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple, acm@PROJECT_ID.iam.gserviceaccount.com.
- ROOT_SECRET_NAME: ajoutez le nom du secret si token est la valeur ROOT_AUTH_TYPE. Ce champ est facultatif.
Pour obtenir une explication des champs et une liste complète des champs que vous pouvez ajouter au champ spec, consultez la section Champs RootSync.

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

Validez les modifications dans la source de référence 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 racine. 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 les objets à l'échelle d'un espace de noms dans une source de référence racine

Les sources de référence à l'échelle d'un espace de noms peuvent être gérées par une source racine de référence. É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 de sources à l'échelle d'un espace de noms.

Pour utiliser cette méthode, effectuez les tâches suivantes :

Dans la source de référence 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 référence 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 hachage) à partir de laquelle la synchronisation doit être effectuée. Ce champ est facultatif et la valeur par défaut est HEAD. À partir de la version 1.17.0 de Config Sync, vous pouvez également spécifier un nom de branche dans le champ revision. Lorsque vous utilisez un hachage dans la version 1.17.0 ou ultérieure, il doit s'agir d'un hachage complet et non d'une version abrégée.
- 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 est master. À partir de la version 1.17.0 de Config Sync, il est recommandé d'utiliser le champ revision pour spécifier un nom de branche pour plus de simplicité. Si les champs revision et branch sont tous les deux spécifiés, revision est prioritaire sur branch.
- NAMESPACE_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :
  - none : n'utiliser aucune authentification
  - ssh : utiliser une paire de clés SSH
  - cookiefile : utiliser un cookiefile
  - token : utiliser un jeton
  - gcpserviceaccount : utiliser un compte de service Google pour accéder à un dépôt dans Cloud Source Repositories
  - gcenode : 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 comme NAMESPACE_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 sur true. La valeur par défaut est false.
- 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. Le secret doit contenir le certificat CA sous une clé nommée cert. Ce champ est facultatif.
  
  Pour en savoir plus sur la configuration de l'objet Secret du certificat CA, consultez 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
```
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 exemple LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. Par défaut, l'image est extraite du tag latest, mais vous pouvez récupérer les images par TAG ou DIGEST à la place. Spécifiez TAG ou DIGEST dans PACKAGE_NAME:
  - Pour extraire par TAG : LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
  - Pour extraire par DIGEST : LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
  Attention :Config Sync nécessite que la couche OCI soit compressée dans tar ou tar+gzip. Les autres formats (par exemple, tar+bz2) ne seront pas reconnus par Config Sync. Si vous passez d'un dépôt valide à une image OCI dans un format non compatible, les ressources gérées sont éliminées sans erreur.
- NAMESPACE_DIRECTORY: ajoutez le chemin d'accès de la source au répertoire racine qui contient la configuration avec laquelle vous souhaitez synchroniser. Ce champ est facultatif et la valeur 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 authentification
  - gcenode: utilisez le compte de service par défaut de Compute Engine 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 comme ROOT_AUTH_TYPE, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple, acm@PROJECT_ID.iam.gserviceaccount.com.
Pour obtenir une explication des champs et une liste complète des champs que vous pouvez ajouter au champ spec, consultez la section Champs RootSync.
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
```
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 graphique. Ce champ est facultatif. Si aucune valeur n'est spécifiée, la dernière version est utilisée.
- HELM_RELEASE_NAME: nom de la version de Helm. Ce champ est facultatif.
- HELM_RELEASE_NAMESPACE: espace de noms cible d'une version. Il ne définit un espace de noms que pour les ressources dont le modèle contient namespace: {{ .Release.Namespace }}. Ce champ est facultatif. Si aucune valeur n'est spécifiée, l'espace de noms par défaut config-management-system est utilisé.
- HELM_INCLUDE_CRDS: définissez cet attribut sur true si vous souhaitez que le modèle Helm génère également un objet CustomResourceDefinition. Ce champ est facultatif. Si aucune valeur n'est spécifiée, la valeur par défaut est false, et aucun objet CRD n'est généré.
- VALUE: valeurs à utiliser à la place des valeurs par défaut qui accompagnent le graphique Helm. Mettez en forme ce champ de la même manière que le fichier value.yaml du graphique Helm. Ce champ est facultatif.
- ROOT_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :
  - none : n'utiliser aucune authentification
  - token: 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 par défaut de Compute Engine 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 comme ROOT_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 du secret si token est la valeur ROOT_AUTH_TYPE. Ce champ est facultatif.
Pour obtenir une explication des champs et une liste complète des champs que vous pouvez ajouter au champ spec, consultez la section Champs RootSync.
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. Consultez Accorder l'accès à Git pour découvrir comment créer cette liaison.
Dans la source racine, déclarez une configuration RoleBinding qui autorise le compte de service SERVICE_ACCOUNT_NAME à gérer les objets de l'espace de noms. Config Sync crée automatiquement le compte de service SERVICE_ACCOUNT_NAME lorsque la configuration RepoSync est synchronisée avec le cluster.

Un élément RoleBinding peut faire référence à un objet Role dans le même espace de noms. Un RoleBinding peut également référencer un ClusterRole et lier ce ClusterRole à l'espace de noms de RoleBinding. Bien que vous deviez respecter le principe du moindre privilège en accordant des autorisations précises à un Role défini par l'utilisateur, vous pouvez définir un ClusterRole ou utiliser des rôles visibles par l'utilisateur, et référencer le même ClusterRole dans plusieurs RoleBindings sur différents espaces de noms.

Remarque :Un RoleBinding qui fait référence à un ClusterRole ne vous donne accès qu'à l'espace de noms du RoleBinding, mais pas à l'ensemble du cluster.
ClusterRoles par défaut
Vous pouvez déclarer un RoleBinding en faisant référence à un ClusterRole par défaut, par exemple admin ou edit. Pour en savoir plus, consultez la section Rôles visibles par l'utilisateur.
```
# 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: ajoute le nom du compte de service du rapprochement. Si le nom de RepoSync est repo-sync, SERVICE_ACCOUNT_NAME est ns-reconciler-NAMESPACE. Sinon, il est défini sur ns-reconciler-NAMESPACE-REPO_SYNC_NAME-REPO_SYNC_NAME_LENGTH. Par exemple, si le nom de votre objet RepoSync est prod, SERVICE_ACCOUNT_NAME est ns-reconciler-NAMESPACE-prod-4. L'entier 4 est utilisé, car prod 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 une ClusterRole ou une Role en accordant une liste d'autorisations à chaque ressource gérée par l'objet RepoSync. Cela permet d'accorder des autorisations précises. Pour en savoir plus, consultez la section Faire référence aux ressources.

Par exemple, l'élément ClusterRole ou Role suivant accorde les autorisations nécessaires pour gérer les objets Deployment et ServiceAccount.
```
# 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 une RoleBinding qui fait référence à ClusterRole ou Role, créez l'objet suivant. Le RoleBinding accorde des autorisations supplémentaires afin de permettre à Config Sync de gérer les ressources à l'échelle d'un espace de noms pour une RepoSync donnée.
```
# 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éfinissez ClusterRole ou Role.
- NAMESPACE : ajoutez le nom de votre espace de noms.
- SERVICE_ACCOUNT_NAME: ajoute le nom du compte de service du rapprochement. Si le nom de RepoSync est repo-sync, SERVICE_ACCOUNT_NAME est ns-reconciler-NAMESPACE. Sinon, il est défini sur ns-reconciler-NAMESPACE-REPO_SYNC_NAME-REPO_SYNC_NAME_LENGTH. Par exemple, si le nom de votre objet RepoSync est prod, SERVICE_ACCOUNT_NAME est ns-reconciler-NAMESPACE-prod-4. L'entier 4 est utilisé, car prod contient quatre caractères.
- RECONCILER_ROLE: ajoutez le nom de ClusterRole ou Role.

Validez les modifications dans la source de référence 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 dans repo-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 l'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 les sources à l'échelle d'un espace de noms dans une source à l'échelle d'un espace de noms

Config Sync permet 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 au sein du même espace de noms.

Pour utiliser cette méthode, effectuez les tâches suivantes :

Dans la source de référence à l'échelle d'un 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 hachage) à partir de laquelle la synchronisation doit être effectuée. Ce champ est facultatif et la valeur par défaut est HEAD. À partir de la version 1.17.0 de Config Sync, vous pouvez également spécifier un nom de branche dans le champ revision. Lorsque vous utilisez un hachage dans la version 1.17.0 ou ultérieure, il doit s'agir d'un hachage complet et non d'une version abrégée.
- 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 est master. À partir de la version 1.17.0 de Config Sync, il est recommandé d'utiliser le champ revision pour spécifier un nom de branche pour plus de simplicité. Si les champs revision et branch sont tous les deux spécifiés, revision est prioritaire sur branch.
- NAMESPACE_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :
  - none : n'utiliser aucune authentification
  - ssh : utiliser une paire de clés SSH
  - cookiefile : utiliser un cookiefile
  - token : utiliser un jeton
  - gcpserviceaccount : utiliser un compte de service Google pour accéder à un dépôt dans Cloud Source Repositories
  - gcenode : 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 comme NAMESPACE_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 sur true. La valeur par défaut est false.
- 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. Le secret doit contenir le certificat CA sous une clé nommée cert. Ce champ est facultatif.
  
  Pour en savoir plus sur la configuration de l'objet Secret du certificat CA, consultez 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
```
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 exemple LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. Par défaut, l'image est extraite du tag latest, mais vous pouvez récupérer les images par TAG ou DIGEST à la place. Spécifiez TAG ou DIGEST dans PACKAGE_NAME:
  - Pour extraire par TAG : LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
  - Pour extraire par DIGEST : LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
  Attention :Config Sync nécessite que la couche OCI soit compressée dans tar ou tar+gzip. Les autres formats (par exemple, tar+bz2) ne seront pas reconnus par Config Sync. Si vous passez d'un dépôt valide à une image OCI dans un format non compatible, les ressources gérées sont éliminées sans erreur.
- NAMESPACE_DIRECTORY: ajoutez le chemin d'accès de la source au répertoire racine qui contient la configuration avec laquelle vous souhaitez synchroniser. Ce champ est facultatif et la valeur 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 authentification
  - gcenode: utilisez le compte de service par défaut de Compute Engine 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 comme ROOT_AUTH_TYPE, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple, acm@PROJECT_ID.iam.gserviceaccount.com.
Pour obtenir une explication des champs et une liste complète des champs que vous pouvez ajouter au champ spec, consultez la section Champs RootSync.
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
```
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 graphique. Ce champ est facultatif. Si aucune valeur n'est spécifiée, la dernière version est utilisée.
- HELM_RELEASE_NAME: nom de la version de Helm. Ce champ est facultatif.
- HELM_RELEASE_NAMESPACE: espace de noms cible d'une version. Il ne définit un espace de noms que pour les ressources dont le modèle contient namespace: {{ .Release.Namespace }}. Ce champ est facultatif. Si aucune valeur n'est spécifiée, l'espace de noms par défaut config-management-system est utilisé.
- HELM_INCLUDE_CRDS: définissez cet attribut sur true si vous souhaitez que le modèle Helm génère également un objet CustomResourceDefinition. Ce champ est facultatif. Si aucune valeur n'est spécifiée, la valeur par défaut est false, et aucun objet CRD n'est généré.
- VALUE: valeurs à utiliser à la place des valeurs par défaut qui accompagnent le graphique Helm. Mettez en forme ce champ de la même manière que le fichier value.yaml du graphique Helm. Ce champ est facultatif.
- ROOT_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :
  - none : n'utiliser aucune authentification
  - token: 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 par défaut de Compute Engine 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 comme ROOT_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 du secret si token est la valeur ROOT_AUTH_TYPE. Ce champ est facultatif.
Pour obtenir une explication des champs et une liste complète des champs que vous pouvez ajouter au champ spec, consultez la section Champs RootSync.
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. Consultez Accorder l'accès à Git pour découvrir comment créer cette liaison.
Dans la source racine, déclarez une configuration RoleBinding qui autorise le compte de service SERVICE_ACCOUNT_NAME à gérer les objets de l'espace de noms. Config Sync crée automatiquement le compte de service SERVICE_ACCOUNT_NAME lorsque la configuration RepoSync est synchronisée avec le cluster.

Un élément RoleBinding peut faire référence à un objet Role dans le même espace de noms. Un RoleBinding peut également référencer un ClusterRole et lier ce ClusterRole à l'espace de noms de RoleBinding. Bien que vous deviez respecter le principe du moindre privilège en accordant des autorisations précises à un Role défini par l'utilisateur, vous pouvez définir un ClusterRole ou utiliser des rôles visibles par l'utilisateur, et référencer le même ClusterRole dans plusieurs RoleBindings sur différents espaces de noms.

Remarque :Un RoleBinding qui fait référence à un ClusterRole ne vous donne accès qu'à l'espace de noms du RoleBinding, mais pas à l'ensemble du cluster.
ClusterRoles par défaut
Vous pouvez déclarer un RoleBinding en faisant référence à un ClusterRole par défaut, par exemple admin ou edit. Pour en savoir plus, consultez la section Rôles visibles par l'utilisateur.
```
# 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: ajoute le nom du compte de service du rapprochement. Si le nom de RepoSync est repo-sync, SERVICE_ACCOUNT_NAME est ns-reconciler-NAMESPACE. Sinon, il est défini sur ns-reconciler-NAMESPACE-REPO_SYNC_NAME-REPO_SYNC_NAME_LENGTH. Par exemple, si le nom de votre objet RepoSync est prod, SERVICE_ACCOUNT_NAME est ns-reconciler-NAMESPACE-prod-4. L'entier 4 est utilisé, car prod 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 une ClusterRole ou une Role en accordant une liste d'autorisations à chaque ressource gérée par l'objet RepoSync. Cela permet d'accorder des autorisations précises. Pour en savoir plus, consultez la section Faire référence aux ressources.

Par exemple, l'élément ClusterRole ou Role suivant accorde les autorisations nécessaires pour gérer les objets Deployment et ServiceAccount.
```
# 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 une RoleBinding qui fait référence à ClusterRole ou Role, créez l'objet suivant. Le RoleBinding accorde des autorisations supplémentaires afin de permettre à Config Sync de gérer les ressources à l'échelle d'un espace de noms pour une RepoSync donnée.
```
# 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éfinissez ClusterRole ou Role.
- NAMESPACE : ajoutez le nom de votre espace de noms.
- SERVICE_ACCOUNT_NAME: ajoute le nom du compte de service du rapprochement. Si le nom de RepoSync est repo-sync, SERVICE_ACCOUNT_NAME est ns-reconciler-NAMESPACE. Sinon, il est défini sur ns-reconciler-NAMESPACE-REPO_SYNC_NAME-REPO_SYNC_NAME_LENGTH. Par exemple, si le nom de votre objet RepoSync est prod, SERVICE_ACCOUNT_NAME est ns-reconciler-NAMESPACE-prod-4. L'entier 4 est utilisé, car prod contient quatre caractères.
- RECONCILER_ROLE: ajoutez le nom de ClusterRole ou Role.

Validez les modifications dans la source de référence 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 dans repo-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 référence à l'échelle de l'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ôlez une source de référence 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 déclare uniquement l'espace de noms dans la source racine de référence et délègue la déclaration de l'objet RepoSync à l'opérateur d'application.

Contrôle de plusieurs sources racines de vérité

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 : ajoutez unstructured pour utiliser un dépôt non structuré ou hierarchy pour utiliser un dépôt hiérarchique. Ces valeurs sont sensibles à la casse. Ce champ est facultatif et la valeur par défaut est hierarchy. Nous vous recommandons d'ajouter la valeur unstructured, car ce format vous permet d'organiser vos configurations de la manière la plus adaptée à vos besoins.
- ROOT_REPOSITORY : ajoutez l'URL du dépôt Git à utiliser comme dépôt racine. Vous pouvez saisir des URL à l'aide du protocole HTTPS ou SSH. Par exemple, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilise le protocole HTTPS. Ce champ est obligatoire.
- ROOT_REVISION: ajoutez la révision Git (tag ou hachage) à partir de laquelle la synchronisation doit être effectuée. Ce champ est facultatif et la valeur par défaut est HEAD. À partir de la version 1.17.0 de Config Sync, vous pouvez également spécifier un nom de branche dans le champ revision. Lorsque vous utilisez un hachage dans la version 1.17.0 ou ultérieure, il doit s'agir d'un hachage complet et non d'une version abrégée.
- ROOT_BRANCH: ajoutez la branche du dépôt à partir de laquelle la synchronisation doit être effectuée. Ce champ est facultatif et la valeur par défaut est master. À partir de la version 1.17.0 de Config Sync, il est recommandé d'utiliser le champ revision pour spécifier un nom de branche pour plus de simplicité. Si les champs revision et branch sont tous les deux spécifiés, revision est prioritaire sur branch.
- ROOT_DIRECTORY : ajoutez le chemin d'accès dans le dépôt Git au répertoire racine contenant la configuration que vous souhaitez synchroniser. Ce champ est facultatif et le paramètre par défaut est le répertoire racine (/) du dépôt.
- ROOT_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :
  - none : n'utiliser aucune authentification
  - ssh : utiliser une paire de clés SSH
  - cookiefile : utiliser un cookiefile
  - token : utiliser un jeton
  - gcpserviceaccount : utilisez un compte de service Google pour accéder à Cloud Source Repositories.
  - gcenode : utilisez un compte de service Google pour accéder à Cloud Source Repositories. Ne sélectionnez cette option que si Workload Identity n'est pas activé dans votre cluster.
  Pour en savoir plus sur ces types d'authentification, consultez la page Accorder à Config Sync un accès en lecture seule à Git.
  
  Ce champ est obligatoire.
- ROOT_EMAIL : si vous avez ajouté gcpserviceaccount comme ROOT_AUTH_TYPE, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple, acm@PROJECT_ID.iam.gserviceaccount.com.
- ROOT_SECRET_NAME : ajoutez le nom de votre secret. Si ce champ est défini, vous devez ajouter la clé publique du secret au fournisseur Git. Ce champ est facultatif.
- ROOT_NO_SSL_VERIFY : pour désactiver la validation du certificat SSL, définissez ce champ sur true. La valeur par défaut est false.
- ROOT_CA_CERT_SECRET_NAME: ajoutez le nom de votre secret. Si ce champ est défini, votre fournisseur Git doit utiliser un certificat émis par cette autorité de certification. Le secret doit contenir le certificat CA sous une clé nommée cert. Ce champ est facultatif.
  
  Pour en savoir plus sur la configuration de l'objet Secret du certificat CA, consultez 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
```
Remplacez les éléments suivants :
- ROOT_SYNC_NAME : ajoutez le nom de votre objet RootSync.
- ROOT_FORMAT : ajoutez unstructured pour utiliser un dépôt non structuré ou hierarchy pour utiliser un dépôt hiérarchique. Ces valeurs sont sensibles à la casse. Ce champ est facultatif et la valeur par défaut est hierarchy. Nous vous recommandons d'ajouter la valeur unstructured, car ce format vous permet d'organiser vos configurations de la manière la plus adaptée à vos besoins.
- ROOT_IMAGE : URL de l'image OCI à utiliser comme dépôt racine, par exemple LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. Par défaut, l'image est extraite du tag latest, mais vous pouvez récupérer les images par TAG ou DIGEST à la place. Spécifiez TAG ou DIGEST dans PACKAGE_NAME :
  - Pour extraire par TAG : LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
  - Pour extraire par DIGEST : LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
Attention :Config Sync nécessite que la couche OCI soit compressée dans tar ou tar+gzip. Les autres formats (par exemple, tar+bz2) ne seront pas reconnus par Config Sync. Si vous passez d'un dépôt valide à une image OCI dans un format non compatible, les ressources gérées sont éliminées sans erreur.
- ROOT_DIRECTORY : ajoutez le chemin d'accès dans le dépôt au répertoire racine contenant la configuration que vous souhaitez synchroniser. Ce champ est facultatif et le paramètre par défaut est le répertoire racine (/) du dépôt.
- ROOT_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :
  - none : n'utiliser aucune authentification
  - gcenode: utilisez le compte de service par défaut de Compute Engine pour accéder à une image dans Artifact Registry. Ne sélectionnez cette option que si Workload Identity n'est pas activé dans votre cluster.
  - gcpserviceaccount : utilisez un compte de service Google pour accéder à une image.
  Ce champ est obligatoire.
- ROOT_EMAIL : si vous avez ajouté gcpserviceaccount comme ROOT_AUTH_TYPE, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple, acm@PROJECT_ID.iam.gserviceaccount.com.
Pour obtenir une explication des champs et une liste complète des champs que vous pouvez ajouter au champ spec, consultez la section Champs RootSync.

Ce fichier manifeste crée un objet RootSync qui utilise une image OCI comme source.
Helm
```
# root-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: ROOT_SYNC_NAME
  namespace: config-management-system
spec:
  sourceType: helm
  sourceFormat: ROOT_FORMAT
  helm:
    repo: ROOT_HELM_REPOSITORY
    chart: HELM_CHART_NAME
    version: HELM_CHART_VERSION
    releaseName: HELM_RELEASE_NAME
    namespace: HELM_RELEASE_NAMESPACE
    values:
      foo:
        bar: VALUE_1
      baz:
      - qux: VALUE_2
        xyz: VALUE_3
    includeCRDs: HELM_INCLUDE_CRDS
    auth: ROOT_AUTH_TYPE
      gcpServiceAccountEmail: ROOT_EMAIL
      secretRef:
        name: ROOT_SECRET_NAME
```
Remplacez les éléments suivants :
- ROOT_SYNC_NAME : ajoutez le nom de votre objet RootSync.
- ROOT_FORMAT : ajoutez unstructured pour utiliser un dépôt non structuré ou hierarchy pour utiliser un dépôt hiérarchique. Ces valeurs sont sensibles à la casse. Ce champ est facultatif et la valeur par défaut est hierarchy. Nous vous recommandons d'ajouter la valeur unstructured, car ce format vous permet d'organiser vos configurations de la manière la plus adaptée à vos besoins.
- ROOT_HELM_REPOSITORY: URL du dépôt Helm à utiliser comme dépôt racine. Vous pouvez saisir des URL à l'aide du protocole HTTPS ou SSH. Par exemple, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilise le protocole HTTPS. Ce champ est obligatoire.
- HELM_CHART_NAME: ajoutez le nom de votre chart Helm. Ce champ est obligatoire.
- HELM_CHART_VERSION: version de votre graphique. Ce champ est facultatif. Si aucune valeur n'est spécifiée, la dernière version est utilisée.
- HELM_RELEASE_NAME: nom de la version de Helm. Ce champ est facultatif.
- HELM_RELEASE_NAMESPACE: espace de noms cible d'une version. Il ne définit un espace de noms que pour les ressources dont le modèle contient namespace: {{ .Release.Namespace }}. Ce champ est facultatif. Si aucune valeur n'est spécifiée, l'espace de noms par défaut config-management-system est utilisé.
- HELM_INCLUDE_CRDS: définissez cet attribut sur true si vous souhaitez que le modèle Helm génère également un objet CustomResourceDefinition. Ce champ est facultatif. Si aucune valeur n'est spécifiée, la valeur par défaut est false, et aucun objet CRD n'est généré.
- VALUE: valeurs à utiliser à la place des valeurs par défaut qui accompagnent le graphique Helm. Mettez en forme ce champ de la même manière que le fichier helm chart's values.yaml. Ce champ est facultatif.
- ROOT_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :
  - none : n'utiliser aucune authentification
  - token: utilisez un nom d'utilisateur et un mot de passe pour accéder à un dépôt Helm privé.
  - gcenode: utilisez le compte de service par défaut de Compute Engine pour accéder à une image dans Artifact Registry. Ne sélectionnez cette option que si Workload Identity n'est pas activé dans votre cluster.
  - gcpserviceaccount : utilisez un compte de service Google pour accéder à une image.
  Ce champ est obligatoire.
- ROOT_EMAIL : si vous avez ajouté gcpserviceaccount comme ROOT_AUTH_TYPE, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple, acm@PROJECT_ID.iam.gserviceaccount.com.
- ROOT_SECRET_NAME: ajoutez le nom du secret si token est la valeur ROOT_AUTH_TYPE. Ce champ est facultatif.
Pour obtenir une explication des champs et une liste complète des champs que vous pouvez ajouter au champ spec, consultez la section Champs RootSync.

Ce fichier manifeste crée un objet RootSync qui utilise Helm comme source.
Appliquez les modifications :
```
kubectl apply -f root-sync.yaml
```
Vous pouvez répéter les étapes ci-dessus si vous devez configurer plusieurs sources racines de référence.

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 référence 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 référence racine, déclarez un RoleBinding pour accorder des 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éé à la source racine de référence.
- USERNAME : ajoutez le nom d'utilisateur de l'opérateur d'application.
- OPERATOR_ROLE: en tant qu'administrateur central, vous pouvez définir OPERATOR_ROLE pour appliquer les types de configurations pouvant être synchronisés à partir de la source à l'échelle d'un espace 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 ClusterRole ou Role défini par l'utilisateur déclaré dans la source de référence racine. Ce rôle permet des autorisations précises.

Validez les modifications dans la source de référence 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 à l'échelle d'un espace de noms en effectuant les tâches suivantes:

Déclarez une configuration RoleBinding qui accorde au compte de service SERVICE_ACCOUNT_NAME provisionné automatiquement l'autorisation de gérer les objets de l'espace de noms. Config Sync crée automatiquement le compte de service SERVICE_ACCOUNT_NAME lorsque la configuration RepoSync 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éé à la source racine de référence.
- SERVICE_ACCOUNT_NAME : ajoutez le nom du compte de service du rapprochement. Si le nom RepoSync est repo-sync, SERVICE_ACCOUNT_NAME est ns-reconciler-NAMESPACE. Sinon, il est défini sur ns-reconciler-NAMESPACE-REPO_SYNC_NAME.
- RECONCILER_ROLE: en tant qu'opérateur d'application, vous pouvez définir RECONCILER_ROLE pour appliquer les types de configuration pouvant être synchronisés à partir de la source à l'échelle d'un espace 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 que OPERATOR_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 dans root-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 hachage) à partir de laquelle la synchronisation doit être effectuée. Ce champ est facultatif et la valeur par défaut est HEAD. À partir de la version 1.17.0 de Config Sync, vous pouvez également spécifier un nom de branche dans le champ revision. Lorsque vous utilisez un hachage dans la version 1.17.0 ou ultérieure, il doit s'agir d'un hachage complet et non d'une version abrégée.
- 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 est master. À partir de la version 1.17.0 de Config Sync, il est recommandé d'utiliser le champ revision pour spécifier un nom de branche pour plus de simplicité. Si les champs revision et branch sont tous les deux spécifiés, revision est prioritaire sur branch.
- NAMESPACE_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :
  - none : n'utiliser aucune authentification
  - ssh : utiliser une paire de clés SSH
  - cookiefile : utiliser un cookiefile
  - token : utiliser un jeton
  - gcpserviceaccount : utiliser un compte de service Google pour accéder à un dépôt dans Cloud Source Repositories
  - gcenode : 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 comme NAMESPACE_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 sur true. La valeur par défaut est false.
- 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. Le secret doit contenir le certificat CA sous une clé nommée cert. Ce champ est facultatif.
  
  Pour en savoir plus sur la configuration de l'objet Secret du certificat CA, consultez 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
```
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 exemple LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. Par défaut, l'image est extraite du tag latest, mais vous pouvez récupérer les images par TAG ou DIGEST à la place. Spécifiez TAG ou DIGEST dans PACKAGE_NAME:
  - Pour extraire par TAG : LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
  - Pour extraire par DIGEST : LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
  Attention :Config Sync nécessite que la couche OCI soit compressée dans tar ou tar+gzip. Les autres formats (par exemple, tar+bz2) ne seront pas reconnus par Config Sync. Si vous passez d'un dépôt valide à une image OCI dans un format non compatible, les ressources gérées sont éliminées sans erreur.
- NAMESPACE_DIRECTORY: ajoutez le chemin d'accès de la source au répertoire racine qui contient la configuration avec laquelle vous souhaitez synchroniser. Ce champ est facultatif et la valeur 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 authentification
  - gcenode: utilisez le compte de service par défaut de Compute Engine 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 comme ROOT_AUTH_TYPE, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple, acm@PROJECT_ID.iam.gserviceaccount.com.
Pour obtenir une explication des champs et une liste complète des champs que vous pouvez ajouter au champ spec, consultez la section Champs RootSync.
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
```
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 graphique. Ce champ est facultatif. Si aucune valeur n'est spécifiée, la dernière version est utilisée.
- HELM_RELEASE_NAME: nom de la version de Helm. Ce champ est facultatif.
- HELM_RELEASE_NAMESPACE: espace de noms cible d'une version. Il ne définit un espace de noms que pour les ressources dont le modèle contient namespace: {{ .Release.Namespace }}. Ce champ est facultatif. Si aucune valeur n'est spécifiée, l'espace de noms par défaut config-management-system est utilisé.
- HELM_INCLUDE_CRDS: définissez cet attribut sur true si vous souhaitez que le modèle Helm génère également un objet CustomResourceDefinition. Ce champ est facultatif. Si aucune valeur n'est spécifiée, la valeur par défaut est false, et aucun objet CRD n'est généré.
- VALUE: valeurs à utiliser à la place des valeurs par défaut qui accompagnent le graphique Helm. Mettez en forme ce champ de la même manière que le fichier value.yaml du graphique Helm. Ce champ est facultatif.
- ROOT_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :
  - none : n'utiliser aucune authentification
  - token: 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 par défaut de Compute Engine 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 comme ROOT_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 du secret si token est la valeur ROOT_AUTH_TYPE. Ce champ est facultatif.
Pour obtenir une explication des champs et une liste complète des champs que vous pouvez ajouter au champ spec, consultez la section Champs RootSync.
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 de l'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 référence à l'échelle d'un espace de noms .

Vérifier l'état de synchronisation de la source fiable

Vous pouvez utiliser la commande nomos status pour inspecter l'état de synchronisation de la source fiable:

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 fiable vers 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 NAMESPACE par l'espace de noms dans lequel vous avez créé votre source de référence à 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 référence

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 référence dans une source de référence racine, un administrateur central peut suivre les deux étapes suivantes pour supprimer une source de référence:

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 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, annulez la gestion des ressources en suivant les instructions de dépannage. Si vous n'avez pas activé le webhook, aucune action supplémentaire n'est requise pour conserver vos ressources.
Supprimez l'objet RootSync ou RepoSync de la source fiable.

Méthode de l'API Kubernetes

Si vous avez utilisé la méthode Contrôler les sources de vérité à l'échelle de l'espace de noms avec l'API Kubernetes, les opérateurs d'application peuvent suivre les étapes ci-dessous pour supprimer une source de vérité à l'échelle d'un 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 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, annulez la gestion des ressources en suivant les instructions de dépannage. Si vous n'avez pas activé le webhook, aucune action supplémentaire n'est requise 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. Par exemple, root-sync.yaml.

Étapes suivantes

Découvrez comment éviter les dérives de configuration dans les sources de référence à l'échelle de l'espace de noms.
Découvrez comment surveiller vos objets RootSync et RepoSync.
Découvrez comment diviser une source de données en plusieurs sources.

Configurer la synchronisation à partir de plusieurs sources de référence

Avant de commencer

Limites

Choisir la méthode de configuration appropriée

Contrôlez les sources dans une source de référence racine

Contrôlez les sources racine dans une source de référence racine

Git

OCI

Helm

Contrôler les objets à l'échelle d'un espace de noms dans une source de référence racine

Git

OCI

Helm

ClusterRoles par défaut

Rôles définis par l'utilisateur

Contrôler les sources à l'échelle d'un espace de noms dans une source à l'échelle d'un espace de noms

Git

OCI

Helm

ClusterRoles par défaut

Rôles définis par l'utilisateur

Contrôlez une source de référence avec l'API Kubernetes

Contrôle de plusieurs sources racines de vérité

Git

OCI

Helm

Contrôler les sources de vérité à l'échelle de l'espace de noms

Tâches administratives centrales

Tâches de l'opérateur d'application

Git

OCI

Helm

Vérifier l'état de synchronisation de la source fiable

Vérifier l'installation de RootSync

Vérifier l'installation de RepoSync

Supprimer une source de référence

Méthode de contrôle centralisé

Méthode de l'API Kubernetes

Étapes suivantes