Déclarer des dépendances entre les objets de ressources

Ce guide vous explique comment fonctionnent les dépendances dans Config Sync et comment spécifier vos propres dépendances.

Config Sync détecte automatiquement les dépendances implicites entre des objets spécifiques lors de leur synchronisation avec le cluster. Par exemple, les objets Namespace sont toujours appliqués avant les objets qu'ils contiennent, et un objet CustomResourceDefinition (CRD) est toujours appliqué avant l'application d'une ressource personnalisée de ce type. De même, l'ordre de suppression est inversé pour ces dépendances implicites : les objets Namespace sont supprimés après les objets qu'ils contiennent, et les objets CRD sont supprimés après les ressources personnalisées de ce type.

Vous pouvez également définir des dépendances explicites à l'aide de l'annotation depends-on. Par exemple, vous pouvez souhaiter que votre StatefulSet MySQL démarre avant le déploiement de WordPress, afin que votre base de données soit appliquée et prête avant le démarrage de WordPress.

Conditions requises

  • Les API RootSync et RepoSync doivent être activées. Si vous avez installé manuellement Config Sync à l'aide de kubectl, et que vous n'avez pas activé les API RootSync et RepoSync, vous devez migrer votre objet ConfigManagement.

  • Les dépendances doivent se trouver dans la même source de vérité que leurs dépendances, et être gérées par le même objet RootSync ou RepoSync.

Appliquer au groupe

Lors de la synchronisation des ressources dans le cluster, Config Sync divise les ressources ayant des dépendances directes ou indirectes en différents groupes d'applications. Un groupe d'applications ne contient que des ressources sans dépendance directe ou indirecte. Le groupe d'applications dans lequel les ressources n'ont pas de dépendances sera appliqué en premier.

Activation et rapprochement

Lorsqu'un objet est activé (appliqué ou éliminé), il peut s'écouler un certain temps avant qu'il ne soit rapproché par son contrôleur. Par exemple, lorsqu'un déploiement est appliqué, les pods sous-jacents peuvent ne pas être prêts immédiatement. Une fois les pods sous-jacents prêts, le déploiement est rapproché. Pour différents types d'objets, Config Sync contrôle plusieurs types de conditions pour vérifier si un objet est rapproché. Pour en savoir plus, consultez la page sigs.k8s.io/cli-utils.

Avec l'annotation depends-on, Config Sync applique non seulement des objets dans l'ordre souhaité, mais il vérifie également que l'objet de la dépendance est rapproché avant d'appliquer l'objet dépendant.

Si l'objet dépendance ne se rapproche pas dans le délai d'expiration de rapprochement par défaut de 5 minutes, Config Sync n'appliquera l'objet dépendant qu'à la prochaine période de synchronisation. Vous pouvez ignorer le délai avant expiration du rapprochement par défaut en définissant l'option spec.override.reconcileTimeout.

Ajouter l'annotation depends-on à un objet

Pour spécifier une dépendance, ajoutez l'annotation config.kubernetes.io/depends-on à l'objet dépendant avec une valeur faisant référence aux objets de la dépendance.

Dans l'exemple WordPress, l'annotation du déploiement WordPress ressemble à ce qui suit :

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: wordpress
  namespace: default
  labels:
    app: wordpress
  annotations:
    config.kubernetes.io/depends-on: apps/namespaces/default/StatefulSet/wordpress-mysql

Lorsque Config Sync applique les objets, il applique d'abord la dépendance, l'objet StatefulSet wordpress-mysql. Lorsque la dépendance a été rapprochée, Config Sync applique le dépendance, le déploiement wordpress.

Références d'objets

Les références d'objets utilisent la syntaxe suivante :

  • Pour les objets d'espaces de noms :

    GROUP/namespaces/NAMESPACE/KIND/NAME
    
  • Pour les objets à l'échelle d'un cluster :

    GROUP/KIND/NAME
    

    Remplacez les éléments suivants :

    • GROUP : groupe de l'objet de dépendance.
    • NAMESPACE : espace de noms de l'objet de dépendance à l'échelle de l'espace de noms.
    • KIND : genre de l'objet de dépendance. Ce champ est sensible à la casse. Par exemple, utilisez "Pod" au lieu de "pod".
    • NAME : nom de l'objet de dépendance.

Pour les objets du groupe principal, une chaîne vide est utilisée (par exemple, /namespaces/test/Pod/pod-a).

Utilisez , pour séparer plusieurs références d'objets (par exemple /namespaces/test/Pod/pod-a,/namespaces/test/Pod/pod-b).