Versión 1.5. Esta versión es compatible como se describe en la política de asistencia de la versión de Anthos, que ofrece los últimos parches y actualizaciones de vulnerabilidades de seguridad, exposiciones y problemas que afectan a los clústeres de Anthos alojados en VMware (GKE On-Prem). Consulta las notas de la versión para obtener más detalles. Esta no es la versión más reciente.

Crea y administra grupos de nodos

A partir de la versión 1.3 de GKE On-Prem, puedes crear un grupo de nodos en el clúster de usuario en el que todos los nodos tengan la misma configuración mediante la definición de un grupo de nodos en el archivo de configuración de ese clúster. Luego, puedes administrar ese grupo de nodos por separado sin afectar a los otros nodos del clúster. Más información sobre los grupos de nodos

Se pueden definir uno o más grupos de nodos en el archivo de configuración de cualquier clúster de usuario. Mediante la creación de un grupo de nodos, se crean nodos adicionales en el clúster de usuarios. La administración de grupos de nodos, incluidas la creación, la actualización y la eliminación de grupos de nodos en un clúster de usuarios, se realiza mediante la modificación de la sección nodePools de tu archivo de configuración y la implementación de esos cambios en tu clúster existente a través del comando gkectl update cluster. Ten en cuenta que borrar grupos de nodos provocará la eliminación inmediata de los nodos relacionados, sin importar si alguno de ellos ejecuta una carga de trabajo.

Ejemplo de grupo de nodos:

nodePools:
  - name: pool-1
    cpus: 4
    memoryMB: 8192
    replicas: 5

Sugerencia para instalaciones nuevas: Crea el primer clúster de usuario y define los grupos de nodos en ese clúster. Luego, usa el archivo de configuración de ese clúster para crear clústeres de usuario adicionales con la misma configuración de grupos de nodos.

Antes de comenzar

  • Asistencia:

    • Solo se admiten la versión 1.3.0 del clúster del usuario o versiones posteriores.

    • Los grupos de nodos en los clústeres de administrador no son compatibles.

    • En este momento, el comando de gkectl update cluster tiene compatibilidad total para actualizar grupos de nodos y agregar IP estáticas. También permite habilitar el registro de auditoría en la nube y habilitar o inhabilitar la reparación automática. Se ignoran todos los demás cambios que haya en el archivo de configuración.

    • Si bien los nodos en un grupo de nodos se pueden administrar de forma independiente de los demás nodos, los nodos de cualquier clúster no se pueden actualizar por separado. Todos los nodos se actualizan cuando actualizas los clústeres.

  • Recursos:

    • Solo puedes implementar cambios en el grupo de nodos replicas sin interrupciones en la carga de trabajo de un nodo.

      Importante: Si implementas cualquier otro cambio de configuración del grupo de nodos, se recrean los nodos del grupo. Debes asegurarte de que ese grupo de nodos no ejecute una carga de trabajo que no deba interrumpirse.

    • Cuando implementas tus cambios en el grupo de nodos, los nodos no deseados se borran después de que se crean o actualizan los nodos deseados. Una implicación de esta política es que, incluso si la cantidad total de nodos permanece igual antes y después de una actualización, es posible que se requieran más recursos (por ejemplo, direcciones IP) durante la actualización. Debes verificar que haya suficientes direcciones IP disponibles para el aumento en el uso.

Crea y actualiza grupos de nodos

Administra un grupo de nodos mediante la modificación y la implementación del archivo de configuración del clúster de usuario. Puedes crear e implementar uno o más grupos de nodos en un clúster de usuario.

Para crear o actualizar grupos de nodos, debes hacer lo siguiente:

  1. En un editor, abre el archivo de configuración del clúster de usuario en el que deseas crear o actualizar los grupos de nodos.

  2. Define uno o más grupos de nodos en la sección nodePools del archivo de configuración del clúster de usuario:

    1. Configura los atributos mínimos necesarios del grupo de nodos. Debes especificar los siguientes atributos para cada grupo de nodos:

      • nodePools.name: Especifica un nombre único para el grupo de nodos. La actualización de este atributo vuelve a crear el nodo. Ejemplo: - name: pool-1

      • nodePools.cpus: Especifica cuántas CPU se asignan a cada nodo trabajador en el grupo. La actualización de este atributo vuelve a crear el nodo. Ejemplo: cpus: 4

      • nodePools.memoryMB: Especifica la cantidad de memoria, en megabytes, que se asigna a cada nodo trabajador del clúster de usuario. La actualización de este atributo vuelve a crear el nodo. Ejemplo: memoryMB: 8192

      • nodePools.replicas: Especifica la cantidad total de nodos trabajadores en el grupo. El clúster de usuario usa nodos en todos los grupos para ejecutar cargas de trabajo. Puedes actualizar este atributo sin afectar los nodos ni las cargas de trabajo en ejecución. Ejemplo: replicas: 5

      Ten en cuenta que, aunque algunos de los atributos nodePools son los mismos que los workernode (DHCP | IP estática) en el archivo de configuración anterior, aún se requiere la sección workernode en los archivos de configuración anteriores de cada clúster de usuario. No puedes quitar la sección workernode ni reemplazarla por nodepools. En el archivo de configuración del clúster de usuario nuevo, ya no hay una sección workernode. Debes definir al menos un grupo de nodos para un clúster de usuario y asegurarte de que haya suficientes nodos sin taint para reemplazar el grupo predeterminado workernode en los archivos de configuración anteriores.

      Ejemplo:

      nodePools:
      - name: pool-1
        cpus: 4
        memoryMB: 8192
        replicas: 5
      

      Consulta Ejemplos para obtener un archivo de configuración del clúster de usuario de ejemplo con varios grupos de nodos.

    2. Configura los atributos opcionales del grupo de nodos. Puedes agregar etiquetas y taints a la configuración del grupo de nodos para dirigir las cargas de trabajo de los nodos. En este archivo, puedes especificar qué Datastore de vSphere usa el grupo de nodos.

      • nodePools.labels: Especifica uno o más pares key : value para identificar de forma única los grupos de nodos. key y value deben comenzar con una letra o un número, y pueden contener letras, números, guiones, puntos y guiones bajos, hasta 63 caracteres cada uno.

        Para obtener información detallada sobre la configuración, consulta etiquetas.

        Importante: No puedes especificar las siguientes claves en una etiqueta porque están reservadas para que las use GKE On-Prem: kubernetes.io, k8s.io y googleapis.com.

        Ejemplo:

        labels:
          key1: value1
          key2: value2
        
      • nodePools.taints: Especifica key, value y effect que definen taints para los grupos de nodos. Estos taints se corresponden con las tolerations que configuras para los pods.

        La key es obligatoria y el value es opcional. Ambos deben comenzar con una letra o un número, y pueden contener letras, números, guiones, puntos y guiones bajos y hasta 253 caracteres. De manera opcional, puedes insertar un prefijo en la key con un subdominio DNS seguido de un /. Por ejemplo: example.com/my-app.

        Los valores effect válidos son NoSchedule, PreferNoSchedule o NoExecute.

        Para obtener información detallada sobre la configuración, consulta taints.

        Ejemplo:

        taints:
          - key: key1
            value: value1
            effect: NoSchedule
        
      • nodePools.bootDiskSizeGB: Especifica el tamaño del disco de arranque, en gigabytes, que se asigna a cada nodo trabajador en el grupo. Esta configuración está disponible a partir de la versión 1.5.0 de GKE On-Prem

        Ejemplo:

        bootDiskSizeGB: 40
        
      • nodePools.vsphere.datastore: especifica el Datastore de vSphere en el que se creará cada nodo del grupo. Esto anula el Datastore de vSphere predeterminado del clúster de usuario.

        Ejemplo:

        vsphere:
          datastore: datastore_name
        

    Consulta Ejemplos para ver un ejemplo de configuración con varios grupos de nodos.

  3. Usa el comando gkectl update cluster para implementar los cambios en el clúster de usuario.

    gkectl update cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --config [USER_CLUSTER_CONFIG_FILE] --dry-run --yes
    
    En el ejemplo anterior, se ilustra lo siguiente:
    • [ADMIN_CLUSTER_KUBECONFIG]: Especifica el archivo kubeconfig del clúster de administrador.
    • [USER_CLUSTER_CONFIG_FILE]: Especifica el archivo configuration del clúster de usuario.
    • --dry-run: Una marca opcional. Agrega esta marca para ver solo el cambio. No se implementaron cambios en el clúster de usuario.
    • --yes: Una marca opcional. Agrega esta marca para ejecutar el comando de forma silenciosa. El mensaje para verificar que deseas continuar está inhabilitado.

    Si anulaste el comando antes de tiempo, puedes volver a ejecutar el mismo comando para completar la operación e implementar los cambios en el clúster de usuario.

    Si necesitas revertir los cambios, debes hacerlo en el archivo de configuración y, luego, volver a implementar esos cambios en el clúster de usuario.

  4. Verifica que los cambios se ejecuten de forma correcta. Para ello, inspecciona todos los nodos. Ejecuta el siguiente comando para enumerar todos los nodos del clúster de usuario:

    kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] get nodes -o wide
    

    En el ejemplo anterior, [USER_CLUSTER_KUBECONFIG] es el archivo kubeconfig del clúster de usuario.

Borra un grupo de nodos

Para borrar un grupo de nodos de un clúster de usuario, haz lo siguiente:

  1. Quita su definición de la sección nodePools del archivo de configuración del clúster de usuario.

  2. Asegúrate de que no haya cargas de trabajo en ejecución en los nodos afectados.

  3. Implementa los cambios mediante la ejecución del comando gkectl update cluster:

    gkectl update cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --config [USER_CLUSTER_CONFIG_FILE] --dry-run --yes
    
    En el ejemplo anterior, se ilustra lo siguiente:
    • [ADMIN_CLUSTER_KUBECONFIG]: Especifica el archivo kubeconfig del clúster de administrador.
    • [USER_CLUSTER_CONFIG_FILE]: Especifica el archivo configuration del clúster de usuario.
    • --dry-run: Una marca opcional. Agrega esta marca para ver solo el cambio. No se implementaron cambios en el clúster de usuario.
    • --yes: Una marca opcional. Agrega esta marca para ejecutar el comando de forma silenciosa. El mensaje para verificar que deseas continuar está inhabilitado.
  4. Verifica que los cambios se ejecuten de forma correcta. Para ello, inspecciona todos los nodos. Ejecuta el siguiente comando para enumerar todos los nodos del clúster de usuario:

    kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] get nodes -o wide
    

    En el ejemplo anterior, [USER_CLUSTER_KUBECONFIG] es el archivo kubeconfig del clúster de usuario.

Ejemplos

En la siguiente configuración de ejemplo, hay cuatro grupos de nodos, cada uno con atributos diferentes:

  • pool-1: Solo se especifican los atributos mínimos obligatorios.
  • pool-2: Incluye el Datastore de vSphere.
  • pool-3: Incluye bootDiskSizeGB.
  • pool-4: Incluye taints y etiquetas.
  • pool-5: Incluye todos los atributos.
apiVersion: v1
kind: UserCluster
...
# (Required) List of node pools. The total un-tainted replicas across all node pools
# must be greater than or equal to 3
nodePools:
- name: pool-1
  cpus: 4
  memoryMB: 8192
  replicas: 5
- name: pool-2
  cpus: 8
  memoryMB: 16384
  replicas: 3
  vsphere:
    datastore: my_datastore
- name: pool-3
  cpus: 8
  memoryMB: 8192
  replicas: 3
  bootDiskSizeGB: 40
- name: pool-4
  cpus: 4
  memoryMB: 8192
  replicas: 5
  taints:
    - key: "example-key"
      effect: NoSchedule
  labels:
    environment: production
    app: nginx
- name: pool-5
  cpus: 8
  memoryMB: 16384
  replicas: 3
  taints:
    - key: "my_key"
      value: my_value1
      effect: NoExecute
  labels:
    environment: test
  vsphere:
    datastore: my_datastore
  bootDiskSizeGB: 60
...

Soluciona problemas

  • En general, el comando gkectl update cluster proporciona información específica cuando falla. Si el comando se ejecutó de forma correcta y no ves los nodos, puedes solucionar el problema con la guía Diagnostica problemas de clústeres.

  • Es posible que haya recursos de clúster insuficientes, como la falta de direcciones IP disponibles durante la creación o actualización del grupo de nodos. Consulta el tema Cambia el tamaño de un clúster de usuario para obtener detalles sobre cómo verificar que las direcciones IP estén disponibles.

  • También puedes consultar la guía general de Solución de problemas.

  • No pasará de Creating node MachineDeployment(s) in user cluster….

    La creación o la actualización de los grupos de nodos en el clúster de usuario puede tomar un tiempo. Sin embargo, si el tiempo de espera es demasiado largo y sospechas que algo falló, puedes ejecutar los siguientes comandos:

    1. Ejecuta kubectl get nodes para obtener el estado de los nodos.
    2. Si deseas obtener un nodo que no esté listo, ejecuta kubectl describe node [node_name] para obtener más detalles.