Prévenir les écarts de configuration

Config Sync vous permet d'éviter les écarts de configuration afin que les ressources du cluster restent alignées sur votre source de vérité centrale. Par défaut, l'autoréparation intégrée dans Config Sync détecte et annule automatiquement les dérives, avec un impact minimal sur les performances du cluster.

Lorsque votre environnement nécessite de bloquer les modifications incompatibles avant que le cluster ne les applique, vous pouvez activer le webhook d'admission Config Sync pour éviter les écarts. Étant donné que ce webhook augmente la surcharge de mémoire et peut provoquer des erreurs de mémoire insuffisante (OOM), utilisez l'autoréparation intégrée pour la plupart des cas d'utilisation.

Pourquoi la protection contre les dérives n'est pas recommandée

Le webhook d'admission nécessite que Config Sync charge le schéma OpenAPI Kubernetes pour valider les requêtes. Dans les clusters comportant de nombreuses ressources ou CustomResourceDefinitions, ce traitement de schéma peut dépasser les limites de mémoire, ce qui entraîne des défaillances de composants. Dans la plupart des cas d'utilisation, l'autoréparation intégrée dans Config Sync offre une protection contre les dérives sans les risques de stabilité du webhook. Vous ne pouvez pas désactiver l'autoréparation intégrée.

Lorsqu'elle est activée, la protection contre les dérives protège les objets RootSync par défaut. Vous pouvez configurer la fonctionnalité pour protéger les objets RepoSync. Pour utiliser la prévention de dérive, vous devez activer les API RootSync et RepoSync. Pour en savoir plus, consultez Champs RootSync et RepoSync.

Remarque : L'autoréparation et la prévention de la dérive utilisent toutes deux l'application côté serveur, ce qui signifie qu'elles empêchent ou annulent uniquement les modifications apportées aux champs explicitement spécifiés dans la source de vérité. Config Sync permet aux champs non spécifiés de dériver, car de nombreux contrôleurs Kubernetes mettent à jour les champs de métadonnées et de spécifications au moment de l'exécution, et pas seulement les champs d'état.

Avant de commencer

Si vous avez déjà installé la Google Cloud CLI, assurez-vous de disposer de 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 la gcloud CLI. Vous ne pouvez pas activer la protection contre les dérives dans la console Google Cloud .

Pour activer la prévention de la dérive, procédez comme suit :

1. 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
   

2. 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 à l'aide de la commande gcloud container fleet memberships list.
   • MANIFEST_NAME : nom de votre fichier manifeste de spécification d'application, généralement apply-spec.yaml.
   • PROJECT_ID : ID de votre projet.

3. 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
   

4. Validez une nouvelle modification dans la source de vérité à synchroniser afin que le déploiement root-reconciler puisse ajouter des webhooks à 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".

5. 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 du 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 prévention de dérive, procédez comme suit :

1. 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
   

2. 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 à l'aide de la commande gcloud container fleet memberships list.
   • MANIFEST_NAME : nom de votre 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.

Attention : Accorder une autorisation de lecture ou de mise à jour des objets ValidatingWebhookConfiguration à une source de vérité à l'échelle d'un espace de noms signifie que les propriétaires de celle-ci peuvent modifier les configurations du webhook d'admission Config Sync dans le cluster.

1. 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"]
   

2. 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.

3. 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
   
   

4. 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
   

Étapes suivantes

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