Asigna nodos a un clúster de bases de datos con la programación

Selecciona una versión de la documentación:

En el operador de Kubernetes de AlloyDB Omni, la programación es un proceso para hacer coincidir los Pods de bases de datos nuevos con los nodos para equilibrar la distribución de nodos en el clúster y ayudar a optimizar el rendimiento. Los Pods y los nodos se hacen coincidir según varios criterios y recursos disponibles, como la CPU y la memoria.

Para obtener más información sobre la programación, consulta Scheduling, Preemption and Eviction en la documentación de Kubernetes.

En esta página, se muestra cómo especificar las tolerancias y las configuraciones de programación de afinidad de nodos para las instancias principales y de grupos de lectura en tu manifiesto de Kubernetes.

Para obtener información sobre cómo definir taints en los nodos, consulta Taints y Tolerancias en la documentación de Kubernetes.

Especifica las tolerancias

Para programar tus Pods de AlloyDB Omni en nodos libres de otros Pods de aplicaciones o hacer coincidir un taint específico definido en esos nodos, aplica una o más tolerancias a los nodos de la siguiente manera:

  1. Modifica el manifiesto del clúster del operador de Kubernetes de AlloyDB Omni para incluir una sección tolerations en la sección schedulingConfig de cualquiera de las siguientes secciones:
    • primarySpec para instancias principales
    • spec para instancias de grupos de lectura
         tolerations:
      - key: "TAINT_KEY"
        operator: "OPERATOR_VALUE"
        value: "VALUE"
        effect: "TAINT_EFFECT"

    Reemplaza lo siguiente:

    • TAINT_KEY: El nombre único existente de la clave de taint, como el nombre de host de un nodo o cualquier otro valor inferido de forma local al que se aplica la tolerancia. La clave de taint ya está definida en un nodo. Un campo vacío y el OPERATOR_VALUE establecido en exists indican que la tolerancia debe coincidir con todos los valores y todas las claves.
    • OPERATOR_VALUE: Representa la relación de una clave con un conjunto de valores. Establece el parámetro en una de las siguientes opciones:
      • exists: Kubernetes hace coincidir cualquier valor si se define el taint, independientemente de su valor.
      • equal: Kubernetes no programa un Pod en un nodo si los valores son diferentes. El operador requiere el valor true de taint.
    • VALUE: El valor de taint con el que coincide la tolerancia. Si el operador es Exists, el valor está vacío; de lo contrario, es una cadena normal. Por ejemplo, true.
    • TAINT_EFFECT: Indica el efecto de taint con el que se debe coincidir. Un campo vacío indica que se deben hacer coincidir todos los efectos de taint. Establece el parámetro en una de las siguientes opciones:
      • NoSchedule: Kubernetes no programa Pods nuevos en el nodo con taint.
      • PreferNoSchedule: Kubernetes evita colocar Pods nuevos en el nodo con taint, a menos que sea necesario.
      • NoExecute: Kubernetes expulsa los Pods existentes que no toleran el taint.
  2. Vuelve a aplicar el manifiesto.

Define la afinidad de nodos

El programador de Kubernetes usa la afinidad de nodos como un conjunto de reglas para determinar dónde colocar un Pod. La afinidad de nodos es una versión más flexible y expresiva de los selectores de nodos.

Para especificar qué nodos se deben programar para ejecutar tu base de datos, sigue estos pasos:

  1. Modifica el manifiesto del clúster de base de datos para incluir la sección nodeaffinity después de la sección tolerations en la sección schedulingConfig de primarySpec para instancias principales o spec para instancias de grupos de lectura: 
          nodeaffinity:
         NODE_AFFINITY_TYPE:
         - weight: WAIT_VALUE
           preference:
             matchExpressions:
             - key: LABEL_KEY
               operator: OPERATOR_VALUE
               values:
               - LABEL_KEY_VALUE

    Reemplaza lo siguiente:

    • NODE_AFFINITY_TYPE: Establece el parámetro en una de las siguientes opciones:
      • requiredDuringSchedulingIgnoredDuringExecution: Kubernetes programa el Pod exactamente según las reglas definidas.
      • preferredDuringSchedulingIgnoredDuringExecution: El programador de Kubernetes intenta encontrar un nodo que cumpla con la regla definida para la programación. Sin embargo, si no existe tal nodo, Kubernetes programa en un nodo diferente del clúster.
    • WAIT_VALUE: Indica el peso de preferencia para los nodos especificados. Los valores más altos indican una preferencia más fuerte. Los valores válidos van de 1 a 100.
    • LABEL_KEY: La etiqueta del nodo para la clave que sirve como indicador de ubicación y facilita la distribución uniforme de Pods en el clúster. Por ejemplo, disktype=ssd.
    • OPERATOR_VALUE: Representa la relación de una clave con un conjunto de valores. Establece el parámetro en una de las siguientes opciones:
      • In: El array de valores no debe estar vacío.
      • NotIn: El array de valores no debe estar vacío.
      • Exists: El array de valores debe estar vacío.
      • DoesNotExist: El array de valores debe estar vacío.
      • Gt: El array de valores debe tener un solo elemento, que se interpreta como un número entero.
      • Lt: El array de valores debe tener un solo elemento, que se interpreta como un número entero.
    • LABEL_KEY_VALUE: El valor de tu clave de etiqueta. Establece el parámetro en un array de valores de cadena de la siguiente manera:
      • Si el operador es In o NotIn, el array de valores no debe estar vacío.
      • Si el operador es Exists o DoesNotExist, el array de valores debe estar vacío.
      • Si el operador es Gt o Lt, el array de valores debe tener un solo elemento, que se interpreta como un número entero.
  2. Vuelve a aplicar el manifiesto.

Ejemplo

En el siguiente ejemplo, se ilustra la programación de Pods en instancias principales y de grupos de lectura del operador de Kubernetes de AlloyDB Omni. Esta configuración de programación ayuda a garantizar que la instancia principal del clúster de base de datos se programe en los nodos adecuados y, al mismo tiempo, permite cierta flexibilidad en la selección de nodos. Esta flexibilidad puede ser útil para equilibrar la carga, optimizar el uso de recursos o cumplir con roles y características de nodos específicos.

    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

La tolerancia de ejemplo permite que el Pod se programe en nodos marcados como nodos del plano de control debido a los siguientes detalles:

  • La clave de taint node-role.kubernetes.io/control-plane indica que el nodo tiene un nodo del plano de control.
  • El operador Exists significa que la tolerancia coincide con cualquier taint con la clave de taint especificada, independientemente del valor.
  • El efecto NoSchedule significa que los Pods no se programarán en el nodo del plano de control, a menos que tengan una tolerancia coincidente.

El tipo de afinidad de nodos preferredDuringSchedulingIgnoredDuringExecution especifica que las reglas definidas para la afinidad de nodos son preferidas, pero no obligatorias durante la programación. Si los nodos preferidos no están disponibles, es posible que el Pod se programe en otros nodos. El valor de peso 1 indica una preferencia débil. Los criterios de selección de nodos se definen en la sección preference. La sección matchExpressions contiene un array de expresiones que se usan para hacer coincidir nodos. La clave another-node-label-key representa la clave de la etiqueta de nodo que se debe hacer coincidir. El operador In significa que el nodo debe tener la clave con uno de los valores especificados. La clave another-node-label-key debe tener el valor another-node-label-value.

La regla de afinidad de nodos de ejemplo indica una preferencia por programar el Pod en nodos que tienen la etiqueta another-node-label-key con el valor another-node-label-value. La preferencia es débil, por lo que no es un requisito estricto.

En el ejemplo, se combinan los siguientes elementos:

  • Tolerancias que permiten que el Pod se programe en nodos del plano de control tolerando el taint NoSchedule.
  • Una afinidad de nodos que prefiere nodos con una etiqueta específica, pero no la requiere de forma estricta; por lo tanto, ofrece flexibilidad en la programación.

¿Qué sigue?