Crea un clúster de usuario con un modelo de instalación nuevo

En este documento, se muestra cómo crear un clúster de usuario que usa un modelo de instalación nuevo que está disponible como una función de vista previa en la versión 1.13 de los clústeres de Anthos alojados en VMware (GKE On-Prem).

¿Qué es kubeception?

El término kubeception se usa para transmitir la idea de que un clúster de Kubernetes se usa a fin de crear y administrar otros clústeres de Kubernetes. En el contexto de los clústeres de Anthos alojados en VMware, kubeception hace referencia al caso en el que el plano de control de un clúster de usuario se ejecuta en uno o más nodos de un clúster de administrador.

A partir de la versión 1.13.0, tienes la opción de hacer que el plano de control de un clúster de usuario se ejecute en uno o más nodos en el clúster de usuario. En versiones anteriores de las clústeres de Anthos alojados en VMware, kubeception era la única opción. Es decir, todos los clústeres de usuario tenían sus planos de control en el clúster de administrador.

El nuevo modelo de instalación aporta coherencia de arquitectura entre los clústeres de administrador y de usuario, y separa el clúster de usuario del clúster de administrador. Esta es una ventaja para situaciones como la ejecución de clústeres en diferentes sitios geográficos.

Antes de comenzar

Debes tener un clúster de administrador y su versión debe ser 1.13.0 o posterior.

Planifica las direcciones IP

Cuando planifiques tus direcciones IP para el clúster de usuario, ten en cuenta estos requisitos del nuevo modelo de instalación:

  • Los nodos del plano de control del clúster de usuario deben obtener sus direcciones IP de una lista de direcciones estáticas que proporciones. Esto sucede incluso si los nodos trabajadores obtienen sus direcciones de un servidor DHCP. Necesitas tres nodos de plano de control para un clúster de usuario de alta disponibilidad (HA), pero solo un nodo de plano de control para un clúster de usuario sin alta disponibilidad.

  • Los nodos del plano de control del clúster de usuario deben estar en la misma VLAN que los nodos trabajadores del clúster de usuario. Esto contrasta con el modelo de kubeception.

  • La VIP del plano de control del clúster de usuario debe estar en la misma VLAN que los nodos trabajadores del clúster de usuario y los nodos del plano de control del clúster de usuario. Esto contrasta con el modelo de kubeception.

Planifica el entorno de vSphere

El archivo de configuración del clúster de administrador y el archivo de configuración del clúster de usuario tienen una sección vCenter en la que puedes especificar los recursos de vSphere que deseas que usen el clúster de administrador o de usuario.

Para un clúster de usuario, no tienes que completar la sección vCenter porque, de forma predeterminada, un clúster de usuario usa los mismos recursos de vSphere que el clúster de administrador. Sin embargo, si deseas que tu clúster de usuario use recursos de vSphere diferentes de los que especificaste para el clúster de administrador, puedes completar los campos que elijas en la sección vCenter del archivo de configuración del clúster de usuario. Para obtener más información, consulta Configura la jerarquía de objetos de vSphere.

En el modelo de instalación nuevo, los nodos del plano de control para el clúster de usuario se encuentran en el clúster de usuario en sí. Por lo tanto, los nodos del plano de control usan los recursos de vSphere especificados en el archivo de configuración del clúster de usuario. Por ejemplo, supongamos que especificas datacenter-1 para el clúster de administrador y datacenter-2 para el clúster de usuario. Los nodos del plano de control del clúster de usuario estarán en datacenter-2.

Grupos antiafinidad

El archivo de configuración del clúster de administrador y el archivo de configuración del clúster de usuario tienen un campo antiAffinityGroups.enabled que puedes establecer en true o false.

En el modelo de instalación nuevo, los nodos del plano de control del clúster de usuario se distribuyen de acuerdo con el valor antiAffinityGroups.enabled en el archivo de configuración del clúster de usuario.

Por el contrario, con el modelo de kubeception, los nodos del plano de control del clúster de usuario se distribuyen de acuerdo con el valor antiAffinityGroups.enabled en el archivo de configuración del clúster de administrador.

Ejemplo

Aquí proporcionamos un ejemplo de un clúster de usuario que tiene las siguientes características:

  • Hay tres nodos trabajadores.

  • Los nodos trabajadores tienen direcciones IP estáticas.

  • Hay tres nodos del plano de control. Es decir, es un clúster de alta disponibilidad.

  • El balanceador de cargas es MetalLB.

  • El clúster de usuario usa los mismos recursos de vSphere que el clúster de administrador.

En el siguiente diagrama, se ilustra la red para los clústeres de administrador y de usuario:

Clúster de administrador y clúster de usuario
Un clúster de administrador y un clúster de usuario (haz clic para ampliar)

Este es un ejemplo de un archivo de bloque de IP y una parte de un archivo de configuración de clúster de usuario.

user-ipblock.yaml.

blocks:
  - netmask: 255.255.255.0
    gateway: 172.16.21.1
    ips:
    - ip: 172.16.21.2
      hostname: worker-vm-1
    - ip: 172.16.21.3
      hostname: worker-vm-2
    - ip: 172.16.21.4
      hostname: worker-vm-3
    - ip: 172.16.21.5
      hostname: worker-vm-4

user-cluster.yaml

apiVersion: v1
kind: UserCluster
...
kubeception: false
network:
  hostConfig:
    dnsServers:
    - "203.0.113.2"
    - "198.51.100.2"
    ntpServers:
    - "216.239.35.4"
  ipMode:
    type: "static"
    ipBlockFilePath: "user-ipblock.yaml"
  controlPlaneIPBlock:
    netmask: "255.255.255.0"
    gateway: "172.16.21.1"
    ips:
    - ip: "172.16.21.6"
      hostname: "cp-vm-1"
    - ip: "172.16.21.7"
      hostname: "cp-vm-2"
    - ip: "172.16.21.8"
      hostname: "cp-vm-3"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.21.40"
    ingressVIP: "172.16.21.30"
  kind: MetalLB
  metalLB:
    addressPools:
    - name: "address-pool-1"
      addresses:
    - "172.16.21.30-172.16.21.39"
...
masterNode:
  cpus: 4
  memoryMB: 8192
  replicas: 3
nodePools:
- name: "worker-node-pool"
  enableLoadBalancer: true

Estos son los puntos importantes que debes comprender en el ejemplo anterior:

  • Las direcciones IP estáticas para los nodos trabajadores se especifican en un archivo de bloque de IP. El archivo de bloque de IP tiene cuatro direcciones, aunque solo haya tres nodos trabajadores. La dirección IP adicional es necesaria durante la actualización, la actualización y la reparación automática del clúster.

  • Las direcciones IP estáticas para los tres nodos del plano de control se especifican en la sección network.controlPlaneIPBlock del archivo de configuración del clúster de usuario. No es necesario agregar una dirección IP adicional en este bloque.

  • El campo masterNode.replicas está configurado como 3.

  • La VIP del plano de control y la VIP de entrada están en la misma VLAN que los nodos trabajadores y los nodos del plano de control.

  • Las VIP que se reservan para los servicios de tipo LoadBalancer se especifican en la sección loadBalancer.metalLB.addressPools del archivo de configuración del clúster de usuario. Estas VIP están en la misma VLAN que los nodos trabajadores y los nodos del plano de control.

  • El archivo de configuración del clúster de usuario no incluye una sección vCenter. Por lo tanto, el clúster de usuario usa los mismos recursos de vSphere que el clúster de administrador.

Crea reglas de firewall

Además de las reglas de firewall estándar, crea las siguientes reglas de firewall según sea necesario:

Desde

Puerto de origen

Para

Puerto DST

Protocolo

Descripción

Nodos del clúster del administrador

Todas

VIP del plano de control del clúster de usuario

443

https

Permite que los nodos y los pods en el clúster de administrador se comuniquen con el servidor de la API de Kubernetes del clúster de usuario.

Nodos del clúster del administrador

Todas

Nodos del plano de control del clúster de usuario

443

https

Permite que los nodos y los pods en el clúster de administrador se comuniquen con el servidor de la API de Kubernetes del clúster de usuario mediante la dirección IP de un nodo del plano de control del clúster de usuario.

Nodos del clúster del administrador

Todas

Servidor de vCenter del clúster de usuario

443

https

Permite que el clúster de administrador gestione el ciclo de vida del clúster de usuario. Es obligatorio si especificaste un valor para vCenter.address que es diferente de la dirección de vCenter en el archivo de configuración del clúster de administrador.

Nodos del plano de control del clúster de usuario

1024 - 65535

Registro local de Docker

Depende del registro

TCP/https

Es obligatorio si especificaste un registro privado en el archivo de configuración del clúster de administrador.

Crea un clúster de usuario con el modelo nuevo

En esta sección, se muestra cómo crear un clúster de usuario que use el nuevo modelo de instalación. En este ejemplo, el clúster de usuario usa la misma instancia de vCenter Server que el clúster de administrador.

Sigue las instrucciones en Crea un clúster de usuario.

A medida que completas el archivo de configuración del clúster de usuario, haz lo siguiente:

  • Establece kubeception en false.

  • No especifiques un valor para vCenter.address.

  • Completa la sección network.controlPlaneIPBlock. Si deseas un clúster de usuario con alta disponibilidad, especifica tres direcciones IP. De lo contrario, especifica una dirección IP.

Cuando tu clúster de usuario esté en ejecución, verifica que el plano de control se ejecute en uno o tres nodos en el clúster de usuario:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get nodes

Reemplaza USER_CLUSTER_KUBECONFIG por la ruta del archivo kubeconfig del clúster de usuario.

El resultado muestra uno o tres nodos del plano de control junto con los nodos trabajadores. Por ejemplo:

cp-vm-1       Ready    control-plane,master   18m
cp-vm-2       Ready    control-plane,master   18m
cp-vm-3       Ready    control-plane,master   18m
worker-vm-1   Ready                           6m7s
worker-vm-2   Ready                           6m6s
worker-vm-3   Ready                           6m14s

Verifica que el plano de control del clúster de usuario no se ejecute en el clúster de administrador:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get nodes --output wide

Reemplaza ADMIN_CLUSTER_KUBECONFIG por la ruta de acceso del archivo kubeconfig del clúster de administrador.

El resultado muestra un nodo del plano de control para el clúster de administrador, pero no muestra ningún nodo del plano de control para el clúster de usuario. Por ejemplo:

admin-vm-1   Ready    control-plane,master   82m
admin-vm-2   Ready                           71m
admin-vm-3   Ready                           71m

Actualiza un clúster de usuario

Sigue las instrucciones en Actualiza clústeres de Anthos alojados en VMware.

Ten en cuenta que cuando actualizas un clúster de usuario mediante el modelo de instalación nuevo, se actualiza todo el clúster de usuario, incluidos los nodos del plano de control del usuario.

Por el contrario, en los clústeres de usuario implementados con el modelo de kubeception, los nodos del plano de control no se actualizan durante la actualización del clúster de usuario y no se actualizarán hasta que se actualice el clúster de administrador.

Borrar un clúster de usuario

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

gkectl delete cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --cluster USER_CLUSTER

Reemplaza USER_CLUSTER por el nombre del clúster de usuario.

Cuando borras un clúster de usuario que usa el modelo de instalación nuevo, los discos de datos del clúster no se borran de forma automática. Así que debes borrar los discos de datos de forma manual. Un clúster de HA tiene tres discos de datos, y un clúster que no es de alta disponibilidad tiene un disco de datos.

Los discos de datos para el clúster de usuario se encuentran en una de estas ubicaciones:

  • ADMIN_CLUSTER/USER_CLUSTER/

  • ADMIN_DISK_FOLDER/ADMIN_CLUSTER/USER_CLUSTER/

Reemplaza ADMIN_CLUSTER por el nombre del clúster de administrador.

Si especificaste una carpeta en el campo vCenter.dataDisk del archivo de configuración del clúster de administrador, reemplaza ADMIN_DISK_FOLDER por el nombre de la carpeta.

Para un clúster sin alta disponibilidad, el disco de datos se llama USER_CLUSTER-0-data.vmdk.

Para un clúster con alta disponibilidad, los discos de datos se nombran de la siguiente manera:

  • USER_CLUSTER-0-data.vmdk.
  • USER_CLUSTER-1-data.vmdk.
  • USER_CLUSTER-2-data.vmdk.

Puedes usar el cliente de vSphere para borrar los discos de datos.

Crea un clúster de usuario con su propio vCenter Server

En algunas situaciones, tiene sentido crear un clúster de usuario que use su propia instancia de vCenter Server. Es decir, el clúster de administrador y un clúster de usuario asociado usan instancias diferentes de vCenter Server.

Por ejemplo, en una ubicación perimetral, es posible que desees tener una máquina física que ejecute vCenter Server y una o más máquinas físicas que ejecuten ESXi. Luego, podrías usar tu instancia local de vCenter Server para crear una jerarquía de objetos de vSphere, incluidos centros de datos, clústeres, grupos de recursos, almacenes de datos y carpetas.

Sigue las instrucciones en Crea un clúster de usuario con el modelo nuevo.

Además de los pasos indicados en esa sección, completa toda la sección vCenter del archivo de configuración del clúster de usuario. En particular, especifica un valor para vCenter.address que sea diferente de la dirección de vCenter Server que especificaste en el archivo de configuración del clúster de administrador.

Ejemplo

vCenter:
  address: "vc-edge.example"
  datacenter: "vc-edge"
  cluster: "vc-edge-workloads"
  resourcePool: "vc-edge-pool
  datastore: "vc-edge-datastore
  caCertPath: "/usr/local/google/home/me/certs/edge-cacert.pem"
  credentials:
    fileRef:
      path: "credential.yaml"
      entry: "vCenter-edge"
  folder: "edge-vm-folder"

Soluciona problemas

Consulta Soluciona problemas de creación y actualización de clústeres.

¿Qué sigue?