Prévenir les écarts de configuration

Config Sync réduit le risque d'opérations "shadow" grâce à l'autoréparation automatique, à la resynchronisation périodique et à la prévention facultative des dérives. Lorsque Config Sync détecte une dérive entre le cluster et la source de référence, celle-ci peut être autorisée, puis annulée rapidement ou totalement rejetée.

L'auto-réparation surveille les ressources gérées, détecte les dérives depuis la source de référence et les annule. L'autoréparation est toujours activée.

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

Bien que l'autoréparation et les resynchronisations périodiques aident à corriger les dérives, la prévention de la dérive intercepte les requêtes de modification des objets gérés et valide si la modification doit être autorisée. Si la modification ne correspond pas à la source de référence, elle est refusée. La protection contre 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.

Activer la protection contre les dérives

  1. Dans le fichier de configuration, définissez le champ preventDrift sur true et appliquez le fichier de configuration:

    gcloud

    Activez la prévention de dérive à l'aide de gcloud CLI si vous avez installé Config Sync à l'aide de Google Cloud Console ou de gcloud CLI. Veillez à mettre à jour gcloud CLI vers la dernière version. Définissez le champ spec.configSync.preventDrift du fichier de configuration gcloud sur true, puis appliquez le fichier de configuration gcloud.

    kubectl

    Activez la protection contre les dérives en utilisant kubectl si vous avez installé manuellement Config Sync avec kubectl. Définissez le champ spec.preventDrift de l'objet ConfigManagement sur true, puis appliquez l'objet ConfigManagement.

  2. Attendez que l'objet Config Sync ValidateWebhookConfiguration soit créé par ConfigManagement 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

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

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

gcloud

Désactivez la prévention de dérive à l'aide de gcloud CLI si vous avez installé Config Sync à l'aide de Google Cloud Console ou de gcloud CLI. Veillez à mettre à jour gcloud CLI vers la dernière version. Définissez le champ spec.configSync.preventDrift du fichier de configuration gcloud sur false ou supprimez-le, puis appliquez le fichier de configuration gcloud.

kubectl

Désactivez la protection contre les dérives en utilisant kubectl si vous avez installé manuellement Config Sync avec kubectl. Définissez le champ spec.preventDrift de l'objet ConfigManagement sur false ou supprimez le champ, puis appliquez l'objet ConfigManagement.

Cette action supprime toutes les ressources du webhook d'admission Config Sync. Comme l'objet ValidatingWebhookConfiguration de Config Sync n'existe plus, les rapprochements Config Sync ne génèrent plus de configurations de webhook pour les ressources gérées.

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

Les sources de vérité à l'échelle de l'espace de noms ne sont pas entièrement protégées par le webhook. Le rapprochement de Config Sync pour chaque source d'espace de noms n'est pas autorisé à lire ni à 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 webhook pour votre source de référence à l'échelle de l'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 référence. Vous n'aurez peut-être pas besoin d'effectuer ces étapes si un RoleBinding pour le ns-reconciler-NAMESPACE existe déjà avec les autorisations ClusterRole cluster-admin.

  1. Dans la source de référence racine, déclarez une nouvelle configuration ClusterRole qui accorde l'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 référence 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

Désactiver la prévention de la dérive 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 plusieurs libellés et annotations que Config Sync utilise pour suivre ces objets de ressource. Si la protection contre la dérive est activée, toutes les modifications apportées aux ressources précédemment gérées peuvent être refusées.

Si vous n'avez pas utilisé la propagation par 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 sur chaque ressource gérée déclarée dans la source de référence. 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, deux options s'offrent à vous:

  • Supprimez les ressources gérées de la source fiable. Ensuite, Config Sync supprimera 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 pour qu'il adopte les ressources du cluster correspondant à la source fiable. Vous pouvez ensuite annuler la gestion ou supprimer les ressources, attendre la synchronisation des modifications et supprimer à nouveau l'objet RootSync ou RepoSync.

Étapes suivantes