Attribuer des nœuds à un cluster de base de données à l'aide de la planification

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

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

Cette page explique comment spécifier des tolérances et des configurations de planification d'affinité de nœud pour les instances de pool primaire et de pool de lecture dans votre fichier manifeste Kubernetes.

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

Spécifier des tolérances

Pour planifier vos pods AlloyDB Omni sur des nœuds sans autres pods d'application ou pour qu'ils correspondent à un taint 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 l'hôte du nœud ou une autre valeur inférée localement à laquelle la tolérance s'applique. La clé de contamination 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 sa valeur.
      • 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 la tolérance correspond. Si l'opérateur est "Existe", la valeur est vide, sinon il s'agit d'une chaîne régulière. Exemple :true
    • TAINT_EFFECT: indique l'effet de rejet à faire correspondre. Un champ vide signifie que tous les effets de taint doivent être mis en correspondance. 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 contaminé, sauf si 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 planificateur Kubernetes utilise l'affinité de nœud comme ensemble de règles pour déterminer où placer un pod. L'affinité de nœud est une version plus flexible et expressive des sélecteurs de nœuds.

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

  1. Modifiez le fichier manifeste du cluster de base 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 exactement en fonction des règles définies.
      • preferredDuringSchedulingIgnoredDuringExecution: le planificateur Kubernetes tente de trouver un nœud qui répond à la règle définie pour la planification. Toutefois, si aucun nœud de ce type n'est disponible, Kubernetes planifie l'exécution 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 distribution 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 contenir un seul élément, qui est interprété comme un entier.
  2. Appliquez à nouveau le fichier manifeste.

Exemple

L'exemple suivant illustre la planification de pods dans les instances de pool de lecture et principales de l'opérateur Kubernetes AlloyDB Omni. Cette configuration de planification permet de s'assurer que l'instance principale du cluster de base de données est planifiée sur les nœuds appropriés, tout en permettant 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œud 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

L'exemple de tolérance permet au pod d'être planifié sur des nœuds marqués comme nœuds de plan de contrôle pour les raisons suivantes:

  • La clé de contamination node-role.kubernetes.io/control-plane indique que le nœud dispose d'un nœud de plan de contrôle.
  • L'opérateur Exists signifie que la tolérance correspond à n'importe quel rejet avec 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 privilégiées, mais qu'elles 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 des nœuds. La clé another-node-label-key représente la clé du libellé de nœud à faire correspondre. 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 avec le libellé another-node-label-key et la valeur another-node-label-value. La préférence est faible, ce n'est donc pas une exigence stricte.

L'exemple combine les éléments suivants:

  • Tolérances permettant de planifier le pod 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 qui ne l'exige pas strictement. Elle offre donc une flexibilité de planification.

Étape suivante