Asignar nodos a un clúster de base de datos mediante la programación

Selecciona una versión de la documentación:

En el operador de AlloyDB Omni Kubernetes, la programación es un proceso que empareja los nuevos pods de la base de datos con los nodos para equilibrar la distribución de los nodos en el clúster y optimizar el rendimiento. Los pods y los nodos se emparejan 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, preferencia y desalojo en la documentación de Kubernetes.

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

Para obtener información sobre cómo definir tolerancias en los nodos, consulta Tolerancias e intolerancias en la documentación de Kubernetes.

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 varias tolerancias a los nodos de la siguiente manera:

  1. Modifica el archivo de manifiesto del clúster del operador AlloyDB Omni Kubernetes 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"

    Haz los cambios siguientes:

    • TAINT_KEY: nombre único de la clave de taint, como el nombre de host de un nodo u otro valor inferido localmente al que se aplica la tolerancia. La clave de taint ya está definida en un nodo. Si el campo está vacío y OPERATOR_VALUE se ha definido como exists, significa 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. Asigne al parámetro uno de los siguientes valores:
      • exists: Kubernetes coincide con cualquier valor si el taint se define independientemente del valor del taint.
      • equal: Kubernetes no programa un pod en un nodo si los valores son diferentes. El operador requiere el valor de intolerancia true.
    • 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 contaminación que se debe buscar. Un campo vacío significa que se deben encontrar todas las consecuencias de taint. Asigne al parámetro uno de los siguientes valores:
      • NoSchedule: Kubernetes no programa nuevos pods en el nodo contaminado.
      • PreferNoSchedule: Kubernetes evita colocar nuevos pods en el nodo contaminado a menos que sea necesario.
      • NoExecute: Kubernetes expulsa los pods que no toleran el taint.
  2. Vuelve a aplicar el archivo de manifiesto.

Definir 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 deben programarse 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 las instancias principales o de 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

    Haz los cambios siguientes:

    • NODE_AFFINITY_TYPE: asigna al parámetro 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 la regla definida para la programación. Sin embargo, si no hay ningún nodo de este tipo, Kubernetes programa el pod en otro nodo del clúster.
    • WAIT_VALUE: indica la ponderación de la preferencia de los nodos especificados. Los valores más altos indican una mayor preferencia. Los valores válidos van de 1 a 100.
    • LABEL_KEY: etiqueta del nodo de la clave que sirve 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. Asigne al parámetro uno de los siguientes valores:
      • In: la matriz de valores no puede estar vacía.
      • NotIn: la matriz de valores no puede estar vacía.
      • 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 la clave de la etiqueta. Defina el parámetro como una matriz de valores de cadena de la siguiente manera:
      • Si el operador es In o NotIn, la matriz de valores no puede estar vacía.
      • Si el operador es Exists o DoesNotExist, la matriz de valores debe estar vacía.
      • Si el operador es Gt o Lt, la matriz de valores debe tener un solo elemento, que se interpreta como un número entero.
  2. Vuelve a aplicar el archivo de manifiesto.

Ejemplo

En el siguiente ejemplo se muestra cómo programar pods en las instancias principales y de grupo de lectura del operador AlloyDB Omni Kubernetes. Esta configuración de programación ayuda a asegurar que la instancia principal del clúster de base de datos se programe en los nodos adecuados, al tiempo que 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 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 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 los pods no se van a programar 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 preferentes, 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 una matriz de expresiones que se usan para buscar nodos coincidentes. La clave another-node-label-key representa la clave de la etiqueta del nodo que se va a buscar. 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 de ejemplo indica una preferencia por programar el pod en nodos que tengan 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 los nodos del plano de control tolerando la intolerancia NoSchedule.
  • Una afinidad de nodo que prefiere los nodos con una etiqueta específica, pero no es estrictamente necesaria. Por lo tanto, ofrece flexibilidad en la programación.

Siguientes pasos