Attribuer un cluster de bases de données à un nœud à l'aide de la planification

Sélectionnez une version de la documentation :

Dans l'opérateur Kubernetes AlloyDB Omni, la planification est un processus qui consiste à associer de nouveaux pods de base de données à des nœuds pour équilibrer la distribution des nœuds dans le cluster et optimiser les performances. Les pods et les nœuds sont mis en correspondance en fonction de plusieurs critères et ressources disponibles, tels que le processeur et la mémoire.

Pour en savoir plus sur la planification, consultez Planification, préemption et éviction dans la documentation Kubernetes.

Cette page explique comment spécifier des configurations de planification de tolérances, d'affinité de nœuds et de contraintes de répartition de la topologie pour les instances de pool de lecture et principales dans votre fichier manifeste Kubernetes.

Pour savoir comment définir des rejets sur les nœuds, consultez Rejets et tolérances dans la documentation Kubernetes.

Spécifier des tolérances

Pour planifier vos pods AlloyDB Omni sur des nœuds exempts d'autres pods d'application ou pour faire correspondre un rejet spécifique défini sur ces nœuds, appliquez une ou plusieurs tolérances aux nœuds comme suit :

  1. Modifiez le fichier manifeste du cluster de l'opérateur Kubernetes AlloyDB Omni pour inclure une section tolerations dans la section schedulingConfig de l'une des sections suivantes :
    • primarySpec pour les instances principales
    • spec pour les instances de pool de lecture
         tolerations:
      - key: "TAINT_KEY"
        operator: "OPERATOR_VALUE"
        value: "VALUE"
        effect: "TAINT_EFFECT"

    Remplacez les éléments suivants :

    • TAINT_KEY : nom unique existant de la clé de rejet, tel que le nom d'hôte d'un nœud ou une autre valeur déduite localement à laquelle s'applique la tolérance. La clé de taint est déjà définie sur un nœud. Un champ vide et OPERATOR_VALUE défini sur exists signifient que la tolérance doit correspondre à toutes les valeurs et à toutes les clés.
    • OPERATOR_VALUE : représente la relation d'une clé avec un ensemble de valeurs. Définissez le paramètre sur l'une des valeurs suivantes :
      • exists : Kubernetes correspond à n'importe quelle valeur si le rejet est défini, quelle que soit la valeur du rejet.
      • equal : Kubernetes ne planifie pas de pod sur un nœud si les valeurs sont différentes. L'opérateur nécessite la valeur de rejet true.
    • VALUE : valeur de rejet à laquelle correspond la tolérance. Si l'opérateur est "Existe", la valeur est vide. Sinon, il s'agit d'une chaîne standard. Exemple :true
    • TAINT_EFFECT : indique l'effet de rejet à faire correspondre. Un champ vide signifie que tous les effets de contamination doivent correspondre. Définissez le paramètre sur l'une des valeurs suivantes :
      • NoSchedule : Kubernetes ne planifie pas de nouveaux pods sur le nœud contaminé.
      • PreferNoSchedule : Kubernetes évite de placer de nouveaux pods sur le nœud rejeté, sauf si cela est nécessaire.
      • NoExecute : Kubernetes expulse les pods existants qui ne tolèrent pas le rejet.
  2. Appliquez à nouveau le fichier manifeste.

Définir l'affinité de nœuds

Le programmateur Kubernetes utilise l'affinité de nœuds comme ensemble de règles pour déterminer où placer un pod. L'affinité de nœud est une version plus flexible et plus expressive des sélecteurs de nœuds.

Pour spécifier les nœuds qui doivent être planifiés pour exécuter votre base de données, procédez comme suit :

  1. Modifiez le fichier manifeste du cluster de bases de données pour inclure la section nodeaffinity après la section tolerations dans la section schedulingConfig de primarySpec pour les instances principales ou de spec pour les instances de pool de lecture : 
          nodeaffinity:
         NODE_AFFINITY_TYPE:
         - weight: WAIT_VALUE
           preference:
             matchExpressions:
             - key: LABEL_KEY
               operator: OPERATOR_VALUE
               values:
               - LABEL_KEY_VALUE

    Remplacez les éléments suivants :

    • NODE_AFFINITY_TYPE : définissez le paramètre sur l'une des valeurs suivantes :
      • requiredDuringSchedulingIgnoredDuringExecution : Kubernetes planifie le pod en fonction des règles définies.
      • preferredDuringSchedulingIgnoredDuringExecution : le programmateur Kubernetes tente de trouver un nœud qui respecte la règle de programmation définie. Toutefois, si aucun nœud de ce type n'est disponible, Kubernetes planifie le pod sur un autre nœud du cluster.
    • WAIT_VALUE : indique la pondération de préférence pour les nœuds spécifiés. Plus la valeur est élevée, plus la préférence est forte. Les valeurs valides sont comprises entre 1 et 100.
    • LABEL_KEY : libellé du nœud pour la clé qui sert d'indicateur d'emplacement et facilite la répartition uniforme des pods dans le cluster. Exemple :disktype=ssd
    • OPERATOR_VALUE : représente la relation d'une clé avec un ensemble de valeurs. Définissez le paramètre sur l'une des valeurs suivantes :
      • In : le tableau des valeurs ne doit pas être vide.
      • NotIn : le tableau des valeurs ne doit pas être vide.
      • Exists : le tableau des valeurs doit être vide.
      • DoesNotExist : le tableau des valeurs doit être vide.
      • Gt : le tableau de valeurs doit comporter un seul élément, qui est interprété comme un entier.
      • Lt : le tableau de valeurs doit comporter un seul élément, qui est interprété comme un entier.
    • LABEL_KEY_VALUE : valeur de la clé de libellé. Définissez le paramètre sur un tableau de valeurs de chaîne comme suit :
      • Si l'opérateur est In ou NotIn, le tableau de valeurs ne doit pas être vide.
      • Si l'opérateur est Exists ou DoesNotExist, le tableau des valeurs doit être vide.
      • Si l'opérateur est Gt ou Lt, le tableau de valeurs doit comporter un seul élément, qui est interprété comme un entier.
  2. Appliquez à nouveau le fichier manifeste.

Définir des contraintes de répartition de la topologie

Le champ topologySpreadConstraints, situé dans spec de l'API Kubernetes Pod et, par conséquent, dans schedulingConfig des fichiers manifestes de cluster de bases de données AlloyDB Omni, contrôle la façon dont les pods sont répartis dans différents domaines de topologie tels que les zones, les nœuds ou les régions de votre cluster. Cela permet de favoriser la haute disponibilité et l'utilisation équilibrée des ressources en empêchant un trop grand nombre de pods de cluster de base de données AlloyDB Omni d'atterrir sur un point de défaillance unique.

Pour spécifier la façon dont votre cluster de bases de données AlloyDB Omni est réparti dans votre topologie de cluster, incluez la section topologySpreadConstraints dans le schedulingConfig de primarySpec pour les instances principales ou de spec pour les instances de pool de lecture :

schedulingconfig:
      # Other scheduling configs like tolerations, nodeaffinity
      topologySpreadConstraints:
        - maxSkew: MAXSKEW_VALUE
          topologyKey: "TOPOLOGY_KEY"
          whenUnsatisfiable: WHEN_UNSATISFIABLE_VALUE
          # labelSelector: <object> # optional
          # minDomains: <integer> # optional
          # matchLabelKeys: <list> # optional
          # nodeAffinityPolicy: [Honor|Ignore] # optional
          # nodeTaintsPolicy: [Honor|Ignore] # optional

Remplacez les éléments suivants :

  • MAXSKEW_VALUE : définit la différence maximale autorisée dans le nombre de pods correspondants entre deux domaines de topologie. Ce paramètre doit être supérieur à 0.
  • TOPOLOGY_KEY : clé des libellés de nœud qui définit un domaine de topologie, par exemple topology.kubernetes.io/zone pour les zones. Le planificateur tente d'équilibrer les pods sur ces domaines.
  • WHEN_UNSATISFIABLE_VALUE : indique comment le planificateur gère un pod si celui-ci ne respecte pas la contrainte de répartition. Définissez le paramètre sur l'une des valeurs suivantes :
    • DoNotSchedule : le programmateur ne planifie pas le pod sur un nœud si la contrainte de répartition n'est pas respectée. Il s'agit de la valeur par défaut.
    • ScheduleAnyway : le planificateur programme toujours le pod, mais il donne la priorité aux nœuds qui minimisent le déséquilibre.

Pour en savoir plus sur les contraintes de répartition de la topologie des pods, consultez la documentation officielle de Kubernetes.

Exemple

L'exemple suivant illustre la planification des pods dans les instances principales et de pool de lecture de l'opérateur Kubernetes AlloyDB Omni. Cette configuration de planification permet de s'assurer que l'instance principale du cluster de bases de données est planifiée sur les nœuds appropriés, tout en offrant une certaine flexibilité dans la sélection des nœuds. Cette flexibilité peut être utile pour équilibrer la charge, optimiser l'utilisation des ressources ou respecter des rôles et des caractéristiques de nœuds spécifiques.

    schedulingconfig:
      tolerations:
      - key: "node-role.kubernetes.io/control-plane"
        operator: "Exists"
        effect: "NoSchedule"
      nodeaffinity:
        preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 1
          preference:
            matchExpressions:
            - key: another-node-label-key
              operator: In
              values:
              - another-node-label-value
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: "topology.kubernetes.io/zone"
          whenUnsatisfiable: DoNotSchedule

L'exemple de tolérance permet de planifier le pod sur des nœuds marqués comme nœuds du plan de contrôle en raison des détails suivants :

  • La clé de taint node-role.kubernetes.io/control-plane indique que le nœud possède un nœud de plan de contrôle.
  • L'opérateur Exists signifie que la tolérance correspond à tout rejet ayant la clé de rejet spécifiée, quelle que soit la valeur.
  • L'effet NoSchedule signifie que les pods ne seront pas planifiés sur le nœud du plan de contrôle, sauf s'ils présentent une tolérance correspondante.

Le type d'affinité de nœud preferredDuringSchedulingIgnoredDuringExecution spécifie que les règles définies pour l'affinité de nœud sont préférées, mais ne sont pas obligatoires lors de la planification. Si les nœuds préférés ne sont pas disponibles, le pod peut toujours être planifié sur d'autres nœuds. La valeur de pondération 1 indique une préférence faible. Les critères de sélection des nœuds sont définis dans la section preference. La section matchExpressions contient un tableau d'expressions utilisées pour faire correspondre les nœuds. La clé another-node-label-key représente la clé du libellé de nœud à mettre en correspondance. L'opérateur In signifie que le nœud doit avoir la clé avec l'une des valeurs spécifiées. La clé another-node-label-key doit avoir la valeur another-node-label-value.

L'exemple de règle d'affinité de nœud indique une préférence pour la planification du pod sur les nœuds qui ont le libellé another-node-label-key avec la valeur another-node-label-value. La préférence est faible, il ne s'agit donc pas d'une exigence forte.

Le topologySpreadConstraints de cet exemple répartit les pods sur différentes zones Kubernetes. La valeur maxSkew de 1 indique qu'il peut y avoir au maximum un pod de plus dans une zone donnée par rapport au nombre minimal de pods dans une autre zone. Le paramètre whenUnsatisfiable, avec une valeur de DoNotSchedule, signifie que si cette contrainte ne peut pas être respectée, le pod reste non planifié.

L'exemple combine les éléments suivants :

  • Tolérances qui permettent au pod d'être planifié sur les nœuds du plan de contrôle en tolérant le rejet NoSchedule.
  • Affinité de nœud qui préfère les nœuds avec un libellé spécifique, mais ne l'exige pas strictement. Elle offre donc une certaine flexibilité dans la planification.
  • Contraintes de répartition de la topologie qui imposent une répartition équilibrée des pods dans les zones de disponibilité, ce qui améliore la résilience et l'utilisation des ressources.

Étapes suivantes