This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

Administrar grupos de nodos de diferentes tipos de máquina virtual

En este tema se explica cómo crear, actualizar y eliminar grupos de nodos en un clúster de carga de trabajo. Los grupos de nodos permiten que un único clúster de carga de trabajo contenga y administre distintos tipos de nodos para satisfacer las diversas necesidades de diferentes aplicaciones.

Por ejemplo, un clúster puede utilizar nodos con alta capacidad de almacenamiento para ejecutar un almacén de datos y nodos de nodos para procesar solicitudes de aplicaciones.

Nota

Para crear y utilizar grupos de nodos en clústeres de carga de trabajo creados por vSphere with Tanzu, debe estar ejecutando vSphere v7.0 U3 o una versión posterior.

Si utiliza vSphere with Tanzu, los clústeres de vSphere with Tanzu deben utilizar la API v1alpha2 para ejecutar correctamente los comandos node-pool. Para obtener más información, consulte la documentación de vSphere with Tanzu.

Acerca de los grupos de nodos

Los grupos de nodos definen propiedades para los conjuntos de nodos de trabajo que utiliza un clúster de carga de trabajo.

Algunas propiedades del grupo de nodos dependen de las opciones de máquina virtual que están disponibles en la infraestructura subyacente, pero todos los grupos de nodos en todas las infraestructuras de nube comparten las siguientes propiedades:

  • name: un identificador único para el grupo de nodos, que se utiliza para operaciones como actualizaciones y eliminación.
  • replicas: el número de nodos del grupo, todos los cuales comparten las mismas propiedades.
  • labels: los pares de clave/valor se establecen como metadatos en los nodos para que las cargas de trabajo coincidan con los nodos del grupo. Para obtener más información y etiquetas de ejemplo, consulte Etiquetas y selectores en la documentación de Kubernetes.

Para los clústeres de carga de trabajo en vSphere, los clústeres de administración independientes siguen de forma predeterminada las reglas de antiafinidad para implementar nodos de plano de control y de trabajo de grupo de nodos en diferentes hosts ESXi. Para desactivar las reglas de antiafinidad para la colocación de nodos, consulte Desactivar reglas de antiafinidad.

Todos los clústeres de carga de trabajo se crean con un primer grupo de nodos original. Cuando se crean grupos de nodos adicionales para un clúster, como se describe a continuación, el primer grupo de nodos proporciona valores predeterminados para las propiedades no establecidas en las nuevas definiciones de grupos de nodos.

Enumerar grupos de nodos

Para inspeccionar los grupos de nodos disponibles actualmente en un clúster, ejecute:

tanzu cluster node-pool list CLUSTER-NAME

El comando devuelve una lista de todos los grupos de nodos del clúster y el estado de las réplicas de cada grupo de nodos.

Crear un grupo de nodos

Para crear un grupo de nodos en un clúster:

  1. Cree un archivo de configuración para el grupo de nodos. Consulte Configuración de ejemplo para un archivo de configuración de ejemplo.

    Para obtener una lista completa de las propiedades de configuración, consulte Propiedades de configuración.

  2. Cree el grupo de nodos definido por el archivo de configuración:

    tanzu cluster node-pool set CLUSTER-NAME -f /PATH/TO/CONFIG-FILE

    Opciones:

    • --namespace especifica el espacio de nombres del clúster. El valor predeterminado es default
    • (Clústeres heredados)--base-machine-deployment especifica el objecto base MachineDeployment a partir del cual crear el nuevo grupo de nodos.
      • Establezca este valor como un identificador MachineDeployment como aparece en el resultado del clúster de tanzu cluster get en Details.
      • El valor predeterminado es el primero en la matriz del clúster de nodos de trabajo MachineDeployment objetos, representados internamente como workerMDs[0].

Configuración de ejemplo

A continuación, se proporciona un ejemplo de configuración para la infraestructura subyacente.

Configuración de vSphere
Además de las propiedades requeridas de name, replicas y labels, los archivos de configuración de los grupos de nodos en vSphere pueden incluir un bloque de vsphere para definir propiedades opcionales específicas con el fin de configurar máquinas virtuales en vSphere.

Ejemplo de definición de grupo de nodos para vSphere clúster:

    name: tkg-wc-oidc-md-1
    replicas: 4
    labels:
      key1: value1
      key2: value2
    vsphere:
      memoryMiB: 8192
      diskGiB: 64
      numCPUs: 4
      datacenter: dc0
      datastore: iscsi-ds-0
      storagePolicyName: name
      folder: vmFolder
      resourcePool: rp-1
      vcIP: 10.0.0.1
      template: templateName
      cloneMode: clone-mode
      network: network-name

Los valores que no se establecen en el bloque vsphere se heredan de los valores del primer grupo de nodos del clúster.

Para el valor vcIP, los grupos de nodos del clúster de carga de trabajo deben ejecutarse en la misma instancia de vCenter que el plano de control del clúster.

Para los clústeres implementados por un supervisor vSphere with Tanzu, defina storageClass, tkr y vmClass. Para obtener más información sobre las propiedades, consulte TanzuKubernetesCluster v1alpha3 API – Annotated en la documentación de vSphere with Tanzu.

De forma predeterminada, los clústeres de carga de trabajo en vSphere se implementan siguiendo reglas de antiafinidad que distribuyen los nodos de plano de control y los nodos de trabajo dentro de cada grupo de nodos en varios hosts ESXi. Para desactivar o reactivar las reglas de antiafinidad, consulte Activar reglas de antiafinidad (vSphere) a continuación.

Configuración de AWS
Además de las propiedades requeridas de name, replicas y labels, los archivos de configuración de los grupos de nodos en AWS admiten las siguientes propiedades opcionales:
  • az: Zona de disponibilidad
  • nodeMachineType: Tipo de instancia

Es posible que se omita esta configuración, en cuyo caso sus valores heredan del primer grupo de nodos del clúster.

Ejemplo de definición de grupo de nodos para un clúster de AWS:

name: tkg-aws-wc-np-1
replicas: 2
az: us-west-2b
nodeMachineType: t3.large
labels:
  key1: value1
  key2: value2
Nota

Los grupos de nodos del clúster de carga de trabajo en AWS deben estar en la misma zona de disponibilidad que el clúster de administración independiente.

Configuración de Azure
Además de las propiedades requeridas de name, replicas y labels anteriormente, los archivos de configuración de los grupos de nodos en Microsoft Azure admiten las siguientes propiedades opcionales:
  • az: Zona de disponibilidad
  • nodeMachineType: Tipo de instancia

Si se omite la configuración, sus valores heredan del primer grupo de nodos del clúster.

Ejemplo de definición de grupo de nodos para el clúster de Azure:

name: tkg-azure-wc-np-1
replicas: 2
az: 2
nodeMachineType: Standard_D2s_v3
labels:
  key1: value1
  key2: value2

Propiedades de configuración

En la siguiente tabla se enumeran todas las propiedades que puede definir en un archivo de configuración de grupo de nodos para clústeres de carga de trabajo.

Nombre Tipo Objeto de clúster Proveedor Notas
name cadena Cualquiera Todo Nombre del grupo de nodos que se va a crear o actualizar.
replicas entero Cualquiera Todo Número de nodos en el grupo de nodos.
az cadena Cualquiera TKG en AWS o Azure AZ para colocar los nodos dentro.
nodeMachineType cadena Cualquiera TKG en AWS o Azure instanceType o vmSize para el nodo en AWS y Azure, respectivamente.
labels map[string]string Cualquiera Todo Etiquetas que se establecerán en el nodo mediante kubeletExtraArgs (‐‐node-labels).
vmClass cadena Cualquiera Todo Nombre de un vmClass de Kubernetes. Coincide con el vmClass definido en el clúster de TKC. Esta clase establece la CPU y la memoria disponibles para el nodo. Para ver una lista de las clases de máquinas virtuales disponibles, ejecute kubectl describe virtualmachineclasses.
storageClass cadena Cualquiera Todo Nombre de un kubernetes StorageClass que se utilizará para el grupo de nodos. Esta clase se aplica a los discos que almacenan los sistemas de archivos raíz de los nodos. Para ver una lista de las clases de almacenamiento disponibles, ejecute kubectl describe storageclasses.
volumes:
  • name, cadena
  • mountPath, cadena
  • capacity, corev1. Lista de recursos
  • storageClass, cadena
 []objeto Cualquiera Todo Volúmenes que se utilizarán para los nodos.
tkr:
  • reference, cadena
 objeto Basado en TKC Todo Nombre del TKR que se utilizará para el grupo de nodos. Por ejemplo, v1.25.7—vmware.2-tkg.2.
tkrResolver cadena Basado en clases Todo Obligatorio para clústeres basados en clases. Valor de la anotación run.tanzu.vmware.com/resolve-os-image del recurso Cluster.
nodeDrainTimeout metav1. Duración Cualquiera Todo Tiempo de espera de purga de nodo.
vsphere objeto Cualquiera Todo Consulte Propiedades de configuración (solo vSphere).
workerClass cadena Basado en clases Todo Obligatorio para clústeres basados en clases. El workerClass del ClusterClass que desea que use el grupo de nodos.

Propiedades de configuración (solo vSphere)

Para obtener información sobre las variables de configuración VSPHERE_*, consulte vSphere en Referencia de variables de archivo de configuración.

Nombre Tipo Tipo de clúster de administración Notas
cloneMode cadena Independiente Igual que VSPHERE_CLONE_MODE.
datacenter cadena Independiente Igual que VSPHERE_DATACENTER.
datastore cadena Independiente Igual que VSPHERE_DATASTORE.
storagePolicyName cadena Independiente Igual que VSPHERE_STORAGE_POLICY_NAME.
taints []corev1. Mancha Supervisor Manchas que se aplicarán al nodo.
folder cadena Independiente Igual que VSPHERE_FOLDER.
network cadena Independiente Igual que VSPHERE_NETWORK.
nameservers []cadena Independiente Igual que VSPHERE_WORKER_NAMESERVERS.
tkgIPFamily cadena Independiente Igual que TKG_IP_FAMILY.
resourcePool cadena Independiente Igual que VSPHERE_RESOURCE_POOL.
vcIP cadena Independiente Igual que VSPHERE_SERVER.
template cadena Independiente Igual que VSPHERE_TEMPLATE.
memoryMiB entero Independiente Igual que VSPHERE_WORKER_MEM_MIB.
diskGiB entero Independiente Igual que VSPHERE_WORKER_DISK_GIB.
numCPUs entero Independiente Igual que VSPHERE_WORKER_NUM_CPUS.

Asignar cargas de trabajo a un grupo de nodos

Para asignar una carga de trabajo a un grupo de nodos:

  1. En el recurso o los recursos de carga de trabajo de Kubernetes que administran los pods, establezca nodeSelector en el valor de labels que definió en el archivo de configuración del grupo de nodos. Para obtener información sobre los recursos de carga de trabajo de Kubernetes, consulte Carga de trabajo en la documentación de Kubernetes.
  2. Aplique la configuración ejecutando el comando kubectl apply -f.

Para reasignar una carga de trabajo a un grupo de nodos diferente:

  1. En el recurso o los recursos de carga de trabajo de Kubernetes que administran los pods, actualice el valor de nodeSelector al nuevo valor.
  2. Aplique la actualización de la configuración ejecutando el comando kubectl apply -f.

Actualizar grupos de nodos

Si solo necesita cambiar el número de nodos en un grupo de nodos, utilice el comando de la CLI de Tanzu en Escalar nodos solo. Si desea agregar etiquetas, siga el procedimiento descrito en Agregar etiquetas y escalar nodos.

Precaución

Con estos procedimientos, no cambie las etiquetas existentes, la zona de disponibilidad, el tipo de instancia de nodo (en AWS o Azure) ni las propiedades de máquina virtual (en vSphere) del grupo de nodos. Esto puede tener efectos negativos graves en las cargas de trabajo en ejecución. Para cambiar estas propiedades, cree un nuevo grupo de nodos con estas propiedades y reasigne las cargas de trabajo al nuevo grupo de nodos antes de eliminar el original. Para obtener instrucciones, consulte la sección anterior Asignar cargas de trabajo a un grupo de nodos.

Escalar nodos solo

Para cambiar el número de nodos en un grupo de nodos, ejecute:

tanzu cluster scale CLUSTER-NAME -p NODE-POOL-NAME -w NODE-COUNT

Donde:

  • CLUSTER-NAME es el nombre del clúster de carga de trabajo.
  • NODE-POOL-NAME es el nombre del grupo de nodos.
  • NODE-COUNT es el número de nodos, como un número entero, que pertenecen a este grupo de nodos.

Agregar etiquetas y escalar nodos

Puede agregar etiquetas a un grupo de nodos y escalar sus nodos al mismo tiempo a través del archivo de configuración del grupo de nodos.

  1. Abra el archivo de configuración del grupo de nodos que desea actualizar.

  2. Si va a aumentar o reducir el número de nodos en este grupo de nodos, actualice el número después de replicas.

  3. Si va a agregar etiquetas, aplíquelas a continuación de labels. Por ejemplo:

    labels:
  key1: value1
  key2: value2

  4. Guarde el archivo de configuración del grupo de nodos.

  5. En un terminal, ejecute:

    tanzu cluster node-pool set CLUSTER-NAME -f /PATH/TO/CONFIG-FILE

    Si CLUSTER-NAME en el comando y name en el archivo de configuración coinciden con un grupo de nodos del clúster, este comando actualiza el grupo de nodos existente en lugar de crear uno nuevo.

Eliminar grupos de nodos

Para eliminar un grupo de nodos, ejecute:

tanzu cluster node-pool delete CLUSTER-NAME -n NODE-POOL-NAME

Donde CLUSTER-NAME es el nombre del clúster de carga de trabajo y NODE-POOL-NAME es el nombre de grupo del nodo.

De forma opcional, utilice --namespace para especificar el espacio de nombres del clúster. El valor predeterminado es default.

Precaución

Reasigne las cargas de trabajo de estos nodos a otros grupos de nodos antes de realizar esta operación. tanzu cluster node-pool delete no migra las cargas de trabajo fuera de los nodos antes de eliminarlas. Para obtener instrucciones, consulte la sección anterior Asignar cargas de trabajo a un grupo de nodos.

Desactivar reglas de antiafinidad (vSphere)

De forma predeterminada, los clústeres de carga de trabajo en vSphere se implementan siguiendo reglas de antiafinidad que distribuyen los nodos de plano de control y los nodos de trabajo dentro de cada grupo de nodos en varios hosts ESXi. Realice lo siguiente para desactivar o reactivar las reglas de antiafinidad durante la creación del clúster:

  1. Establezca el contexto kubectl en el clúster de administración:

    kubectl config use-context MGMT-CLUSTER-NAME-admin@MGMT-CLUSTER-NAME

    Donde MGMT-CLUSTER-NAME es el nombre del clúster.

  2. Ejecute kubectl get deployment en el controlador CAPV para recopilar los valores de args para su contenedor manager, por ejemplo:

    kubectl get deployment -n capv-system capv-controller-manager -o=json | jq '.spec.template.spec.containers[] | select(.name=="manager") | .args'
[
  "--leader-elect",
  "--logtostderr",
  "--v=4",
  "--feature-gates=NodeAntiAffinity=true,NodeLabeling=true"
]

  3. Con los resultados copiados del paso anterior, cambie los valores de --feature-gates y pase la lista de argumentos a un comando kubectl patch que revise sus valores en el objeto. Por ejemplo, para establecer las puertas de función NodeAntiAffinity y NodeLabeling en false, lo que desactiva las reglas de antiafinidad del nodo:

    kubectl patch deployment -n capv-system capv-controller-manager --type=json -p '[{"op":"replace", "path":"/spec/template/spec/containers/0/args", "value": [
"--leader-elect",
"--logtostderr",
"--v=4",
"--feature-gates=NodeAntiAffinity=false,NodeLabeling=false"
]}]'
check-circle-line exclamation-circle-line close-line
Scroll to top icon