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 correlacionan 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 grupo de lectura y principal 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.

Cómo especificar tolerancias

Para programar tus Pods de AlloyDB Omni en nodos que no tengan otros Pods de aplicaciones 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: Es el nombre único existente de la clave de taint, como el nombre de host de un nodo o algún otro valor inferido de forma local al que se aplica la tolerancia. La clave de aislamiento ya está definida en un nodo. Un campo vacío y el parámetro 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 uno de los siguientes valores:
      • exists: Kubernetes coincide con cualquier valor si el efecto está definido, independientemente de su valor.
      • equal: Kubernetes no programa un Pod en un nodo si los valores son diferentes. El operador requiere el valor de taint true.
    • 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 taint con el que se debe coincidir. Un campo vacío indica que se deben encontrar coincidencias para todos los efectos de taint. Establece el parámetro en uno de los siguientes valores:
      • 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 la base de datos para incluir la sección nodeaffinity después de la sección tolerations en la sección schedulingConfig de primarySpec para las instancias principales o spec para las instancias del 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 uno de los siguientes valores:
      • 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 la carga 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 los 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 específicos de los nodos.

    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 aislamiento 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 taint que tenga la clave de taint especificada, independientemente del valor.
  • El efecto NoSchedule significa que no se programarán Pods en el nodo del plano de control, a menos que tengan una tolerancia coincidente.

El tipo de afinidad de nodo preferredDuringSchedulingIgnoredDuringExecution especifica que las reglas definidas para la afinidad de nodo 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 del nodo que se debe correlacionar. 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 nodo del 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:

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

¿Qué sigue?