Résoudre les problèmes liés aux manettes

Cette page vous explique comment résoudre les problèmes liés aux combats de manettes. De tels combats consomment beaucoup de ressources et peuvent dégrader vos performances. Les combats entre contrôleurs sont également appelés conflits de ressources.

Config Sync surveille les objets qu'il applique sur le cluster et annule les modifications apportées aux valeurs déclarées dans la source de référence. Si ces modifications sont effectuées par un autre contrôleur, la ressource peut basculer entre les états souhaités par les contrôleurs concurrents. Un symptôme de ce comportement est que les champs metadata.generation et metadata.resourceVersion augmentent rapidement. De ce fait, si un objet géré est mis à jour plus de cinq fois par minute, Config Sync détecte le combat, consigne la dérive et signale l'erreur dans l'état de l'objet RootSync ou RepoSync.

Config Sync dispose d'une logique spéciale pour détecter les conflits entre plusieurs objets RootSync et RepoSync. Pour les objets RepoSync, si le rapprochement constate que l'objet est déjà géré par un autre, les mises à jour suivantes sont ignorées. Pour les objets RootSync, le rapprochement tente d'adopter un objet qu'il est configuré pour gérer, sauf s'il est géré par un autre objet RootSync. Cela empêche les rapprochements Config Sync de se battre entre eux et signale les erreurs dans l'état de tous les objets RootSync et RepoSync concernés.

Identifier les combats entre manettes

Si vous utilisez Config Sync version 1.15.0 ou ultérieure, vous pouvez examiner les erreurs de combat à l'aide de la commande nomos status ou en consultant le champ d'état dans l'objet RootSync ou RepoSync.

Si l'outil de ligne de commande nomos n'est pas installé, vous pouvez consulter les journaux du rapprochement RootSync en exécutant la commande suivante:

kubectl logs -n config-management-system \
    --selector "app=reconciler,configsync.gke.io/sync-name=root-sync" \
    --container reconciler

Pour filtrer sur des rapprochements RepoSync spécifiques, exécutez la commande suivante:

kubectl logs -n config-management-system \
    --selector "app=reconciler,configsync.gke.io/sync-namespace=NAMESPACE" \
    --container reconciler

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

Si vous voyez KNV2005 dans les résultats, cela signifie qu'il y a un combat entre manettes.

Le message d'erreur suivant est un exemple de type d'erreur pouvant s'afficher dans vos journaux:

KNV2005: detected excessive object updates, approximately 6 times per
minute. This may indicate Config Sync is fighting with another controller over
the object.

Enquêter sur les combats entre manettes

Pour en savoir plus sur un combat de contrôleur, observez les mises à jour du fichier YAML de la ressource en exécutant la commande suivante:

 kubectl get RESOURCE OBJECT_NAME \
     --namespace NAMESPACE \
     --watch -o yaml

Remplacez les éléments suivants :

  • RESOURCE: type de ressource faisant l'objet d'un conflit.
  • OBJECT_NAME: nom de l'objet faisant l'objet d'un combat.
  • NAMESPACE: espace de noms dans lequel se trouve la ressource faisant l'objet d'un combat.

Les résultats du journal spécifient la ressource, le nom de l'objet et l'espace de noms que vous devez ajouter.

Cette commande renvoie un flux de l'état de la ressource après l'application des mises à jour au serveur d'API. Utilisez un outil de comparaison de fichiers pour comparer le résultat.

Résolvez des combats entre manettes

Il existe plusieurs façons de résoudre les conflits de manettes. Choisissez l'option qui convient le mieux à votre configuration Config Sync:

  • Mettez à jour le fichier manifeste de la ressource dans la source pour qu'il corresponde à la valeur souhaitée par l'autre contrôleur.
  • Supprimez le champ en question de la source pour permettre à l'autre contrôleur de le gérer.
  • Désactivez ou désinstallez l'autre manette.
  • Supprimez la ressource de la source et gérez-la manuellement ou avec un contrôleur personnalisé qui tolère des modifications spécifiques ou une co-gestion.
  • Si vous êtes le propriétaire du contrôleur qui provoque des conflits de ressources et que le champ en cours de modification ne figure pas dans la source fiable, mettez à jour votre contrôleur pour qu'il effectue l'application des correctifs plutôt que de le mettre à jour. De cette façon, la modification sera autorisée par Config Sync et ne sera pas annulée.

Certaines ressources doivent également appartenir à d'autres contrôleurs (par exemple, certains opérateurs installent ou gèrent des objets CRD). Ces autres contrôleurs suppriment automatiquement toutes les métadonnées propres à Config Sync. Si un autre composant de votre cluster Kubernetes supprime les métadonnées Config Sync, arrêtez de gérer la ressource avec Config Sync. Pour savoir comment procéder, consultez la section Arrêter de gérer un objet géré.

Si vous ne souhaitez pas que Config Sync annule les modifications apportées aux objets gérés du cluster, vous pouvez également ajouter l'annotation client.lifecycle.config.k8s.io/mutation: ignore à l'objet dans lequel vous souhaitez que Config Sync ignore les mutations. Pour savoir comment procéder, consultez Ignorer les mutations d'objets.

Étapes suivantes