Il est possible qu'une partie ou l'ensemble des informations de cette page ne s'appliquent pas au Cloud de confiance S3NS. Pour en savoir plus, consultez Différences par rapport à Google Cloud.

Cette page a été traduite par l'API Cloud Translation.

Prévenir les écarts de configuration

Config Sync réduit le risque d'"opérations cachées" grâce à l'autoréparation automatique, à la resynchronisation périodique et à la prévention de la dérive (facultative). Lorsque Config Sync détecte un écart entre le cluster et la source de vérité, celui-ci peut être autorisé et rapidement annulé ou complètement rejeté.

L'autoréparation surveille les ressources gérées, détecte la dérive de la source de vérité et l'annule. L'autoréparation est toujours activée.

La resynchronisation périodique synchronise automatiquement une heure après la dernière synchronisation réussie, même si aucune modification n'a été apportée à la source de vérité. La resynchronisation périodique est toujours activée.

Bien que l'autoréparation et les resynchronisations périodiques permettent de corriger les dérives, la prévention des dérives intercepte les requêtes de modification des objets gérés et vérifie si la modification doit être autorisée. Si la modification ne correspond pas à la source de vérité, elle est refusée. La prévention de la dérive est désactivée par défaut. Lorsqu'elle est activée, la prévention de la dérive protège les objets RootSync par défaut. Elle peut également être configurée pour protéger les objets RepoSync.

Pour utiliser la prévention de la dérive, vous devez activer les API RootSync et RepoSync.

Avant de commencer

Si vous avez déjà installé Google Cloud CLI, obtenez la dernière version en exécutant la commande gcloud components update.

Activer la protection contre les dérives

Vous pouvez activer la protection contre les dérives à l'aide de gcloud CLI. Vous ne pouvez pas activer la prévention de la dérive dans la console Cloud de Confiance .

Pour activer la protection contre les dérives, procédez comme suit :

Mettez à jour votre fichier manifeste applySpec pour définir le champ spec.configSync.preventDrift sur true :

applySpecVersion: 1
spec:
  configSync:
    enabled: true
    ... existing content ...
    preventDrift: true

Appliquez le fichier manifeste mis à jour :
```
gcloud beta container fleet config-management apply \
    --membership=MEMBERSHIP_NAME \
    --config=MANIFEST_NAME  \
    --project=PROJECT_ID
```
Remplacez les éléments suivants :
- MEMBERSHIP_NAME : nom d'appartenance de parc que vous avez choisi lors de l'enregistrement de votre cluster. Obtenez le nom avec la commande gcloud container fleet memberships list.
- MANIFEST_NAME : nom du fichier manifeste de spécification d'application, généralement apply-spec.yaml.
- PROJECT_ID : ID de votre projet.

Attendez que l'objet ValidateWebhookConfiguration Config Sync soit créé par Config Management Operator :

kubectl get validatingwebhookconfiguration admission-webhook.configsync.gke.io

Un résultat semblable aux lignes suivantes doit s'afficher :

NAME                                  WEBHOOKS   AGE
admission-webhook.configsync.gke.io   0          2m15s

Validez une nouvelle modification dans la source de vérité à synchroniser afin que le déploiement root-reconciler puisse ajouter des webhooks dans l'objet Config Sync "ValidatingWebhookConfiguration". Vous pouvez également supprimer le déploiement root-reconcilier pour déclencher un rapprochement. Le nouvel objet de déploiement root-reconciler mettra à jour l'objet Config Sync "ValidatingWebhookConfiguration".

Attendez que le serveur de webhook soit prêt. Le journal de déploiement du webhook d'admission Config Sync doit inclure serving webhook server. Cette opération peut prendre plusieurs minutes.

kubectl logs -n config-management-system -l app=admission-webhook --tail=-1 | grep "serving webhook server"

Un résultat semblable aux lignes suivantes doit s'afficher :

I1201 18:05:41.805531       1 deleg.go:130] controller-runtime/webhook "level"=0 "msg"="serving webhook server"  "host"="" "port"=10250
I1201 18:07:04.626199       1 deleg.go:130] controller-runtime/webhook "level"=0 "msg"="serving webhook server"  "host"="" "port"=10250

Désactiver la protection contre les dérives

Lorsque vous désactivez la protection contre les dérives, Config Sync supprime toutes les ressources de webhook d'admission Config Sync. Étant donné que l'objet ValidatingWebhookConfiguration Config Sync n'existe plus, les rapprochements Config Sync ne génèrent plus les configurations du webhook pour les ressources gérées.

Pour désactiver la protection contre les dérives, procédez comme suit :

Mettez à jour votre fichier manifeste applySpec pour définir le champ spec.configSync.preventDrift sur false :

applySpecVersion: 1
spec:
  configSync:
    enabled: false
    ... existing content ...
    preventDrift: false

Appliquez le fichier manifeste mis à jour :
```
gcloud beta container fleet config-management apply \
    --membership=MEMBERSHIP_NAME \
    --config=MANIFEST_NAME  \
    --project=PROJECT_ID
```
Remplacez les éléments suivants :
- MEMBERSHIP_NAME : nom d'appartenance de parc que vous avez choisi lors de l'enregistrement de votre cluster. Obtenez le nom avec la commande gcloud container fleet memberships list.
- MANIFEST_NAME : nom du fichier manifeste de spécification d'application, généralement apply-spec.yaml.
- PROJECT_ID : ID de votre projet.

Activer le webhook d'admission dans les sources à l'échelle d'un espace de noms

Les sources de vérité à l'échelle d'un espace de noms ne sont pas entièrement protégées par le webhook. Le rapprochement Config Sync pour chaque source d'espaces de noms ne dispose pas des autorisations nécessaires pour lire ou mettre à jour les objets ValidatingWebhookConfiguration au niveau du cluster.

Cette absence d'autorisation génère une erreur dans les journaux des rapprochements d'espaces de noms comme dans cet exemple :

Failed to update admission webhook: KNV2013: applying changes to
admission webhook: Insufficient permission. To fix, make sure the reconciler has
sufficient permissions.:
validatingwebhookconfigurations.admissionregistration.k8s.io "admission-
webhook.configsync.gke.io" is forbidden: User "system:serviceaccount:config-
management-system:ns-reconciler-NAMESPACE" cannot update resource
"validatingwebhookconfigurations" in API group "admissionregistration.k8s.io" at
the cluster scope

Vous pouvez ignorer cette erreur si vous ne souhaitez pas utiliser la protection de webhook pour votre source de vérité à l'échelle d'un espace de noms. Toutefois, si vous souhaitez utiliser le webhook, accordez l'autorisation au rapprochement pour chaque source de vérité à l'échelle d'un espace de noms après avoir configuré la synchronisation à partir de plusieurs sources de vérité. Vous n'aurez peut-être pas besoin d'effectuer ces étapes si un objet RoleBinding pour ns-reconciler-NAMESPACE existe déjà avec les autorisations cluster-admin ClusterRole.

Dans la source de vérité racine, déclarez une nouvelle configuration d'objet ClusterRole qui accorde une autorisation au webhook d'admission Config Sync. Cet objet ClusterRole n'a besoin d'être défini qu'une seule fois par cluster :

# ROOT_SOURCE/cluster-roles/webhook-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: admission-webhook-role
rules:
- apiGroups: ["admissionregistration.k8s.io"]
  resources: ["validatingwebhookconfigurations"]
  resourceNames: ["admission-webhook.configsync.gke.io"]
  verbs: ["get", "update"]

Pour chaque source à l'échelle d'un espace de noms pour laquelle l'autorisation de webhook d'admission doit être accordée, déclarez une configuration ClusterRoleBinding pour accorder l'accès au webhook d'admission :

# ROOT_SOURCE/NAMESPACE/sync-webhook-rolebinding.yaml
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: syncs-webhook
subjects:
- kind: ServiceAccount
  name: ns-reconciler-NAMESPACE
  namespace: config-management-system
roleRef:
  kind: ClusterRole
  name: admission-webhook-role
  apiGroup: rbac.authorization.k8s.io

Remplacez NAMESPACE par l'espace de noms dans lequel vous avez créé votre source à l'échelle d'un espace de noms.

Validez les modifications dans la source de vérité racine, par exemple en cas de synchronisation à partir d'un dépôt Git :
```
git add .
git commit -m 'Providing namespace repository the permission to update the admission webhook.'
git push
```
Pour vérifier, utilisez kubectl get pour vous assurer que les objets ClusterRole et ClusterRoleBinding ont été créés :
```
kubectl get clusterrole admission-webhook-role
kubectl get clusterrolebindings syncs-webhook
```

Désactiver la protection contre les dérives pour les ressources abandonnées

Lorsque vous supprimez un objet RootSync ou RepoSync, Config Sync ne modifie pas par défaut les ressources précédemment gérées par cet objet RootSync ou RepoSync. Cela peut laisser de côté plusieurs libellés et annotations que Config Sync utilise pour suivre ces objets de ressources. Si la protection contre la dérive est activée, toute modification apportée aux ressources précédemment gérées peut être refusée.

Si vous n'avez pas utilisé la propagation de suppression, les objets de ressources laissés de côté peuvent toujours conserver les libellés et les annotations ajoutés par Config Sync.

Si vous souhaitez conserver ces ressources gérées, annulez la gestion de ces ressources avant de supprimer les objets RootSync ou RepoSync en définissant l'annotation configmanagement.gke.io/managed sur disabled pour chaque ressource déclarée dans la source de vérité. Cela indique à Config Sync de supprimer ses libellés et annotations des ressources gérées, sans supprimer ces ressources. Une fois la synchronisation terminée, vous pouvez supprimer l'objet RootSync ou RepoSync.

Si vous souhaitez supprimer ces ressources gérées, vous disposez de deux options :

Supprimez les ressources gérées de la source de vérité. Config Sync supprimera ensuite les objets gérés du cluster. Une fois la synchronisation terminée, vous pouvez supprimer l'objet RootSync ou RepoSync.
Activez la propagation de la suppression sur l'objet RootSync ou RepoSync avant de le supprimer. Config Sync supprimera ensuite les objets gérés du cluster.

Si l'objet RootSync ou RepoSync est supprimé avant d'annuler la gestion ou de supprimer ses ressources gérées, vous pouvez recréer l'objet RootSync ou RepoSync. Il adoptera les ressources du cluster qui correspondent à la source de vérité. Vous pouvez ensuite annuler la gestion ou supprimer les ressources, attendre que les modifications soient synchronisées, puis supprimer à nouveau l'objet RootSync ou RepoSync.

Étapes suivantes

Découvrez comment résoudre les problèmes liés au webhook.