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

En el operador de Kubernetes de AlloyDB Omni, la programación es un proceso para hacer coincidir los nuevos pods de base de datos 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 coinciden en función de varios criterios y recursos disponibles, como la CPU y la memoria.

Para obtener más información sobre la programación, consulta Programación, interrupción y expulsión en la documentación de Kubernetes.

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

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

Especifica tolerancias

Para programar tus Pods de AlloyDB Omni en nodos sin otros Pods de aplicación o que coincidan con 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 grupo 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 contaminación ya está definida en un nodo. Un campo vacío y el OPERATOR_VALUE establecido en exists significan 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 uno de los siguientes valores:
      • exists: Kubernetes coincide con cualquier valor si se define la contaminación, 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 contaminación.
    • VALUE: Es 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 contaminación que debe coincidir. Un campo vacío significa que todos los efectos de contaminación deben coincidir. Establece el parámetro en uno de los siguientes valores:
      • NoSchedule: Kubernetes no programa pods nuevos en el nodo contaminado.
      • PreferNoSchedule: Kubernetes evita colocar pods nuevos en el nodo contaminado, 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 los 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 la base de datos, sigue estos pasos:

  1. Modifica el manifiesto del clúster de bases 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 grupo 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 hay un nodo de ese tipo, 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 sólida. Los valores válidos van desde 1 hasta 100.
    • LABEL_KEY: Es la etiqueta del nodo para la clave que funciona 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 uno de los siguientes valores:
      • 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: Es el valor de la 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 las instancias principales y de grupo 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 bases 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 contaminación node-role.kubernetes.io/control-plane indica que el nodo tiene un nodo de plano de control.
  • El operador Exists significa que la tolerancia coincide con cualquier contaminación con la clave de contaminación 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 son 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 los nodos. La clave another-node-label-key representa la clave de la etiqueta del nodo que debe 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 para 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.

El ejemplo combina lo siguiente:

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

¿Qué sigue?