Attribuer des nœuds à un cluster de base de données à 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 et d'affinité de nœuds pour les instances de pool de lecture et principal 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.

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

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.

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.

Étapes suivantes