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 facultative des dérives. 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 s'effectue 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.
Alors que l'autoréparation et les resynchronisations périodiques permettent de corriger les dérives, la protection contre les 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é, la modification est rejetée. La protection contre les dérives est désactivée par défaut. Lorsqu'elle est activée, la protection contre les dérives protège les objets RootSync
par défaut. Elle peut également être configurée pour protéger les objets RepoSync
.
Pour utiliser la protection contre les dérives, vous devez activer les API RootSync
et RepoSync
.
Activer la protection contre les dérives
Définissez le champ
preventDrift
du fichier de configuration surtrue
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 surtrue
, 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 aveckubectl
. Définissez le champspec.preventDrift
de l'objetConfigManagement
surtrue
, puis appliquez l'objetConfigManagement
.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 vers la source fiable à synchroniser afin que le déploiement
root-reconciler
puisse ajouter des webhooks dans l'objet Config Sync ValidatingWebhookConfiguration. Vous pouvez également supprimer le déploiementroot-reconcilier
pour déclencher un rapprochement. Le nouvel objet de déploiementroot-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
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 champ, 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 opération 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.
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
, par défaut, Config Sync ne modifie pas 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 les dérives est activée, cela peut entraîner le rejet de toutes les modifications apportées aux ressources précédemment gérées.
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 ses 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 supprime ensuite les objets gérés du cluster. Une fois la synchronisation terminée, vous pouvez supprimer l'objet
RootSync
ouRepoSync
. - Activez la propagation de la suppression sur l'objet
RootSync
ouRepoSync
avant de le supprimer. Config Sync supprime 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
, et il adopte les ressources sur le cluster correspondant à la source de vérité. Vous pouvez ensuite arrêter la gestion ou supprimer les ressources, attendre la synchronisation des modifications et supprimer à nouveau l'objet RootSync
ou RepoSync
.
Étapes suivantes
- Découvrez comment résoudre les problèmes liés au webhook.