Ejecución de clústeres en varias zonas de disponibilidad

En este tema se describe cómo implementar nuevos clústeres de carga de trabajo de Tanzu Kubernetes Grid (TKG) que se ejecutan en varias zonas de disponibilidad (Availability Zones, AZ) y cómo cambiar los clústeres de carga de trabajo y de administración existentes para que se ejecuten en varias AZ o en AZ diferentes.

Para utilizar la interfaz del instalador para configurar un nuevo clúster de administración independiente para que se ejecute en varias zonas de disponibilidad, consulte Configurar recursos de vSphere en Deploy Management Clusters with the Installer Interface.

Nota
Este tema se aplica a TKG con un clúster de administración independiente. Para ejecutar TKG con un supervisor en varias zonas de disponibilidad, consulte Crear zonas de vSphere para una implementación de supervisor de varias zonas en la documentación de vSphere 8.0.

Descripción general

En TKG en vSphere, de forma opcional, puede definir regiones y zonas de disponibilidad en Kubernetes para alojar clústeres de administración independientes y sus clústeres de carga de trabajo y, a continuación, etiquetarlos en vSphere para asociarlos con clústeres de vSphere, grupos de hosts o centros de datos.

Esta configuración permite que TKG admita la distribución y la redundancia de cargas de trabajo en vSphere similar a la forma en que funciona con regiones y zonas de disponibilidad en otras infraestructuras.

Sin estas construcciones, puede colocar los clústeres de TKG en el nivel de vSphere haciendo referencia a objetos de vSphere directamente, pero, a continuación, TKG y Kubernetes no pueden administrar su colocación.

Definir zonas de disponibilidad

Para definir zonas de disponibilidad en TKG en vSphere, cree objetos de Kubernetes y asócielos a objetos vSphere en función de cómo se encuentren en el ámbito las zonas de disponibilidad:

Objetos de Kubernetes: Para habilitar varias zonas de disponibilidad para clústeres en vSphere, el vSphere del proveedor de API del clúster (Cluster API Provider vSphere, CAPV) utiliza dos definiciones de recursos personalizados (CRD) :

La CRD de VSphereFailureDomain captura la información de etiquetado específica de la región o la zona y la definición de topología, que incluye información del centro de datos, el clúster, el host y el almacén de datos de vSphere.
La CRD de VSphereDeploymentZone captura la asociación de un VSphereFailureDomain con información de restricción de colocación para el nodo de Kubernetes.

Para crear estos objetos, debe definirlos en una especificación de objeto, como un archivo vsphere-zones.yaml, que puede utilizar para crear los objetos en diferentes momentos, como se indica a continuación:

Cuando cree el clúster de administración por primera vez, pase el archivo a la opción --az-file de tanzu mc create.
- Para ejecutar el propio clúster de administración dentro de las zonas de disponibilidad definidas, debe crear los objetos de zonas de disponibilidad de esta manera en este momento.
- Si cree que va a necesitar objetos de zonas de disponibilidad adicionales para los clústeres de carga de trabajo y mantener todas las definiciones de zonas de disponibilidad en un solo lugar, puede definir zonas de disponibilidad adicionales en este mismo archivo. Si lo hace, establezca SKIP_MULTI_AZ_VERIFY=true como una variable env para omitir la validación de vSphere como se describe en Comprobaciones de validación en Ejecutar el comando tanzu mc create, ya que es posible que esas zonas de disponibilidad adicionales aún no tengan todas las configuraciones de vSphere establecidas.
Una vez creado el clúster de administración, pero antes de crear clústeres de carga de trabajo que requieran que los objetos de zonas de disponibilidad estén listos, pase el archivo a la opción -f del comando tanzu mc az set o kubectl apply.
Al crear clústeres de carga de trabajo, pase el archivo a la opción --az-file de tanzu cluster create.

Para enumerar los objetos de zonas de disponibilidad que ya se crearon, ejecute:

kubectl get VSphereFailureDomain,VSphereDeploymentZone -a

Asociación de Kubernetes con vSphere: Las definiciones de los objetos VSphereFailureDomain y VSphereDeploymentZone definen las regiones y las AZ con la siguiente configuración:

Región: spec.region
Zona/AZ: spec.zone

Las etiquetas de vSphere k8s-region y k8s-zone asocian regiones y AZ en Kubernetes con sus objetos subyacentes en vSphere.

Ámbito de AZ: Puede establecer el ámbito de las AZ y las regiones en diferentes niveles de vSphere asociándolas a objetos de vSphere de la siguiente manera:

Ámbito de AZ	Zona/AZ	Región	Uso de varias AZ
AZ de clúster	Clúster de vSphere	Centro de datos de vSphere	Distribuir nodos entre varios clústeres en un centro de datos
AZ de grupo de hosts	Grupo de hosts vSphere	Clúster de vSphere	Distribuir nodos entre varios hosts en un solo clúster

Las configuraciones de este tema propagan los nodos de trabajo y del plano de control del clúster de TKG a todos los objetos de vSphere, es decir, a los centros de datos, clústeres y hosts de vSphere, en función de cómo se etiquetan los objetos en vSphere y se hace referencia a ellos en las definiciones de VSphereFailureDomain y VSphereDeploymentZone en Kubernetes.

Configurar clústeres de para utilizar zonas de disponibilidad

Con los objetos VSphereFailureDomain y VSphereDeploymentZone definidos para zonas de disponibilidad en Kubernetes, puede configurar la forma en que los clústeres los utilizan a través de las variables del archivo de configuración o las propiedades del objeto Cluster.

Variables de configuración: Para utilizar variables de configuración del clúster, establezca VSPHERE_AZ_0, VSPHERE_AZ_1, VSPHERE_AZ_2, VSPHERE_AZ_CONTROL_PLANE_MATCHING_LABELS, VSPHERE_REGION y VSPHERE_ZONE como se describe en vSphere en la Referencia de variables del archivo de Configuration.

Propiedades de objetos: Para las propiedades del objeto Cluster, la especificación del objeto configura las zonas de disponibilidad para sus nodos de trabajo y del plano de control de diferentes maneras mediante el establecimiento de coincidencias con las diferentes propiedades de los objetos VSphereDeploymentZone que definen las zonas de disponibilidad:

Tipo de nodo	Propiedad en `spec.topology`	Para que coincida con las propiedades de `VSphereDeploymentZone`	Ejemplo
Nodos del plano de control	`variables.controlPlaneZoneMatchingLabels`	Lista de pares de `metadata.labels`	`{"environment": "staging", "region": "room1"}`
Nodos de trabajo	`machineDeployments.MD-INDEX.failureDomain` para cada implementación de máquina	Lista de valores de `metadata.name`	`[rack1,rack2,rack3]`

Debido a que los nodos del plano de control se asignan a las AZ en función de la coincidencia de etiquetas, debe crear una etiqueta que distinga cada combinación de AZ que puedan utilizar los nodos de los planos de control del clúster.

Requisitos previos

Los requisitos previos para implementar o cambiar clústeres de TKG para que se ejecuten en varias AZ o diferentes son los siguientes:

Un clúster de administración Tanzu Kubernetes Grid con clústeres de carga de trabajo que se ejecutan en vSphere.
El siguiente permiso se agregó a la cuenta de vSphere configurada para TKG según describe Permisos necesarios para la cuenta de vSphere:
- Host > Inventario (Inventory) > Modificar clúster (Modify cluster)

Implementar clústeres de carga de trabajo en varias zonas de disponibilidad

Puede implementar un clúster de carga de trabajo para ejecutar su plano de control o nodos de trabajo en varias zonas de disponibilidad (Availability Zones, AZ) en tres pasos básicos, como se describe en las siguientes secciones:

Preparar regiones y AZ en vSphere
Crear objetos FailureDomain y DeploymentZone en Kubernetes
Implementar el clúster de

Preparar regiones y AZ en vSphere

Para preparar vSphere para admitir regiones y AZ en TKG:

Identifique o cree los objetos de vSphere para las regiones y las AZ en las que se alojarán los nodos del clúster de TKG.
- AZ de grupo de hosts: Si utiliza grupos de hosts de vSphere como AZ, debe crear un grupo de hosts y un grupo de máquinas virtuales correspondiente para cada AZ que tenga previsto utilizar:
  1. Cree objetos de grupo de hosts y de grupo de máquinas virtuales de una de las siguientes maneras:
    - En vCenter, cree un grupo de hosts y un grupo de máquinas virtuales desde Configurar (Configure) > Grupos de máquinas virtuales/hosts (VM/Host Groups) > Agregar… (Add...).
      - Para crear un grupo de hosts, es posible que deba crear una máquina virtual ficticia para agregarla como miembro del grupo.
    - Con la CLI govc, ejecute comandos de govc similares a los siguientes. Por ejemplo, para crear un grupo de hosts rack1 y un grupo de máquinas virtuales rack1-vm-group:
```
govc cluster.group.create -cluster=RegionA01-MGMT -name=rack1 -host esx-01a.corp.tanzu esx-02a.corp.tanzu
```
```
govc cluster.group.create -cluster=RegionA01-MGMT -name=rack1-vm-group -vm
```
  2. Agregue reglas de afinidad entre los grupos de hosts y los grupos de máquinas virtuales creados para que las máquinas virtuales del grupo de máquinas virtuales se ejecuten en los hosts del grupo de hosts creado:
    - Establezca Tipo (Type) en Virtual Machines to Hosts (Máquinas virtuales en los hosts) e incluya la regla Debe ejecutarse en los hosts del grupo (Must run on hosts in group).

Etiquete los objetos vSphere de la siguiente manera, en función de si va a configurar vSphere AZ de clúster o de grupo de hosts. Estos ejemplos utilizan la CLI govc, pero también puede utilizar el panel Etiquetas y atributos personalizados (Tags & Custom Attributes) en vCenter:

AZ de clúster:

Para cada AZ, utilice govc para crear y asociar una etiqueta de categoría k8s-region al centro de datos y una etiqueta de categoría k8s-zone a cada clúster de vSphere. Por ejemplo, para etiquetar el centro de datos dc0 como una región us-west-1 y sus clústeres cluster1, etc. como AZ us-west-1a, etc.:

govc tags.category.create -t Datacenter k8s-region

govc tags.category.create -t ClusterComputeResource k8s-zone

govc tags.create -c k8s-region us-west-1

govc tags.create -c k8s-zone us-west-1a
govc tags.create -c k8s-zone us-west-1b
govc tags.create -c k8s-zone us-west-1c

govc tags.attach -c k8s-region us-west-1 /dc0

govc tags.attach -c k8s-zone us-west-1a /dc0/host/cluster1
govc tags.attach -c k8s-zone us-west-1b /dc0/host/cluster2
govc tags.attach -c k8s-zone us-west-1c /dc0/host/cluster3

Zonas de disponibilidad de grupo de hosts:

Para cada zona de disponibilidad, utilice govc para crear y asociar una etiqueta de categoría k8s-region al clúster de vSphere y una etiqueta de categoría k8s-zone a cada host. Por ejemplo, para etiquetar un clúster /dc1/host/room1-mgmt como regiónroom1 y el host en ese grupo/dc1/host/room1-mgmt/esx-01a.corp.tanzu etc. como zonas de disponibilidad rack1 etc.:

govc tags.category.create -t ClusterComputeResource k8s-region
govc tags.category.create -t HostSystem k8s-zone

govc tags.create -c k8s-region room1

govc tags.create -c k8s-zone rack1
govc tags.create -c k8s-zone rack2
govc tags.create -c k8s-zone rack3

govc tags.attach -c k8s-region room1 /dc1/host/room1-mgmt

govc tags.attach -c k8s-zone rack1 /dc1/host/room1-mgmt/esx-01a.corp.tanzu
govc tags.attach -c k8s-zone rack1 /dc1/host/room1-mgmt/esx-01b.corp.tanzu
govc tags.attach -c k8s-zone rack1 /dc1/host/room1-mgmt/esx-01c.corp.tanzu

Identifique o cree las carpetas y los grupos de recursos de vSphere que se utilizarán para colocar las máquinas virtuales para cada una de las zonas de disponibilidad. Estos ejemplos utilizan la CLI govc, pero también puede hacer esto en los paneles de Inventario en vCenter:
- AZ de clúster:
  
  Para cada zona de disponibilidad, utilice govc para crear objetos resource-pool en cada clúster vSphere que coincidan con cada una de las 3 zonas de disponibilidad y las 3 carpetas de máquina virtual
```
govc pool.create /dc0/host/cluster1/pool1
govc pool.create /dc0/host/cluster2/pool2
govc pool.create /dc0/host/cluster3/pool3
govc folder.create /dc0/vm/folder1
govc folder.create /dc0/vm/folder2
govc folder.create /dc0/vm/folder3
```
- Zonas de disponibilidad de grupo de hosts:
  
  Para cada zona de disponibilidad, utilice govc para crear 3 objetos resource-pool y 3 carpetas de máquina virtual
```
govc pool.create /dc1/host/cluster1/pool1
govc pool.create /dc1/host/cluster1/pool2
govc pool.create /dc1/host/cluster1/pool3
govc folder.create /dc1/vm/folder1
govc folder.create /dc1/vm/folder2
govc folder.create /dc1/vm/folder3
```

Crear objetos `FailureDomain` y `DeploymentZone` en Kubernetes

Antes de implementar un clúster en varias zonas de disponibilidad, debe definir los objetos de Kubernetes FailureDomain y DeploymentZone para la región y las zonas, como se describe en la sección anterior Definir zonas de disponibilidad.

Todos los ajustes de spec.region, spec.zone y spec.topology deben coincidir con las etiquetas y las rutas de objeto configuradas en vCenter:

Para los objetos VSphereDeploymentZone, el valor spec.failuredomain debe coincidir con uno de los valores metadata.name de las definiciones de VSphereFailureDomain.
El valor spec.server en los objetos VSphereDeploymentZone debe coincidir con la dirección del vCenter Server (IP o FQDN) introducida para VCENTER SERVER en el panel Proveedor de IaaS (IaaS Provider) de la interfaz del instalador o el ajuste VSPHERE_SERVER en el archivo de configuración del clúster de administración.
Los valores metadata.name deben estar todos en minúscula.

Cree las definiciones de los objetos FailureDomain y DeploymentZone como se indica a continuación, en función de si va a configurar zonas de disponibilidad de clúster de vSphere o zonas de disponibilidad de grupo de hosts.

AZ de clúster:

Como ejemplo de cómo distribuir el clúster de carga de trabajo entre varios nodos de clúster de vSphere dentro de un centro de datos, el siguiente código define los objetos necesarios para tres zonas de implementación denominadas us-west-1a, us-west-1b y us-west-1c, cada una de las cuales es un clúster de vSphere que tiene sus propios parámetros de red y almacenamiento:

  ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereFailureDomain
  metadata:
    name: us-west-1a
  spec:
    region:
      name: us-west-1
      type: Datacenter
      tagCategory: k8s-region
    zone:
      name: us-west-1a
      type: ComputeCluster
      tagCategory: k8s-zone
    topology:
      datacenter: dc0
      computeCluster: cluster1
      datastore: ds-c1
      networks:
      - net1
      - net2
  ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereFailureDomain
  metadata:
    name: us-west-1b
  spec:
    region:
      name: us-west-1
      type: Datacenter
      tagCategory: k8s-region
    zone:
      name: us-west-1b
      type: ComputeCluster
      tagCategory: k8s-zone
    topology:
      datacenter: dc0
      computeCluster: cluster2
      datastore: ds-c2
      networks:
      - net3
  ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereFailureDomain
  metadata:
    name: us-west-1c
  spec:
    region:
      name: us-west-1
      type: Datacenter
      tagCategory: k8s-region
    zone:
      name: us-west-1c
      type: ComputeCluster
      tagCategory: k8s-zone
    topology:
      datacenter: dc0
      computeCluster: cluster3
      datastore: ds-c3
      networks:
      - net4
  ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereDeploymentZone
  metadata:
    name: us-west-1a
    labels:
      environment: "staging"
      region: "us-west-1"
  spec:
    server: VSPHERE_SERVER
    failureDomain: us-west-1a
    placementConstraint:
      resourcePool: pool1
      folder: folder1
  ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereDeploymentZone
  metadata:
    name: us-west-1b
    labels:
      environment: "staging"
      region: "us-west-1"
  spec:
    server: VSPHERE_SERVER
    failureDomain: us-west-1b
    placementConstraint:
      resourcePool: pool2
      folder: folder2
  ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereDeploymentZone
  metadata:
    name: us-west-1c
    labels:
      environment: "staging"
      region: "us-west-1"
  spec:
    server: VSPHERE_SERVER
    failureDomain: us-west-1c
    placementConstraint:
      resourcePool: pool3
      folder: folder3

Donde VSPHERE_SERVER es la dirección IP o el FQDN de su vCenter Server.

Si diferentes clústeres de vSphere tienen grupos de recursos con nombres idénticos, establezca spec.placementConstraint.resourcePool de los objetos VSphereDeploymentZone en una ruta de recursos completa, no solo el nombre.

AZ de grupo de hosts:

Como ejemplo de cómo distribuir los nodos del clúster de carga de trabajo entre tres grupos de hosts en un único clúster de vSphere, el siguiente código define los objetos necesarios para tres AZ: rack1, rack2 y rack3, cada uno de los cuales representa un rack de hosts dentro del mismo clúster de vSphere, definido como región room1:

  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereFailureDomain
  metadata:
    name: rack1
  spec:
    region:
      name: room1
      type: ComputeCluster
      tagCategory: k8s-region
    zone:
      name: rack1
      type: HostGroup
      tagCategory: k8s-zone
    topology:
      datacenter: dc0
      computeCluster: cluster1
      hosts:
        vmGroupName: rack1-vm-group
        hostGroupName: rack1
      datastore: ds-r1
      networks:
      - net1
  ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereFailureDomain
  metadata:
    name: rack2
  spec:
    region:
      name: room1
      type: ComputeCluster
      tagCategory: k8s-region
    zone:
      name: rack2
      type: HostGroup
      tagCategory: k8s-zone
    topology:
      datacenter: dc0
      computeCluster: cluster1
      hosts:
        vmGroupName: rack2-vm-group
        hostGroupName: rack2
      datastore: ds-r2
      networks:
      - net2
  ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereFailureDomain
  metadata:
    name: rack3
  spec:
    region:
      name: room1
      type: ComputeCluster
      tagCategory: k8s-region
    zone:
      name: rack3
      type: HostGroup
      tagCategory: k8s-zone
    topology:
      datacenter: dc0
      computeCluster: cluster1
      hosts:
        vmGroupName: rack3-vm-group
        hostGroupName: rack3
      datastore: ds-c3
      networks:
      - net3
  ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereDeploymentZone
  metadata:
    name: rack1
    labels:
      region: room1
  spec:
    server: VSPHERE_SERVER
    failureDomain: rack1
    placementConstraint:
      resourcePool: pool1
      folder: folder1
  ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereDeploymentZone
  metadata:
    name: rack2
    labels:
      region: room1
  spec:
    server: VSPHERE_SERVER
    failureDomain: rack2
    placementConstraint:
      resourcePool: pool2
      folder: folder2
  ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereDeploymentZone
  metadata:
    name: rack3
    labels:
      region: room1
  spec:
    server: VSPHERE_SERVER
    failureDomain: rack3
    placementConstraint:
      resourcePool: pool3
      folder: folder3

Donde VSPHERE_SERVER es la dirección IP o el FQDN de su vCenter Server.

Después de crear las definiciones de los objetos FailureDomain y DeploymentZone para las zonas de disponibilidad, continúe según el tipo de clúster que va a implementar:

Clúster de administración independiente: Continúe con Configurar varias zonas de disponibilidad como parte de Implementar clústeres de administración desde un archivo de configuración.
Clúster de carga de trabajo: Continúe con Implementar el clúster a continuación.

Implementar el clúster de

Después de realizar los pasos en Preparar regiones y AZ en vSphere y Crear objetos FailureDomain y DeploymentZone en Kubernetes, puede implementar un clúster de carga de trabajo con sus nodos distribuidos en varias AZ.

En los siguientes pasos, se utiliza vsphere-zones.yaml como archivo que contiene las definiciones de objetos FailureDomain y DeploymentZone.

Siga Archivos de configuración de vSphere con clúster de administración independiente para crear el archivo de configuración del clúster para el clúster de carga de trabajo que va a implementar.
Compruebe o modifique las variables de las zonas de disponibilidad en el archivo de configuración del clúster para que coincidan con las definiciones de objetos de zonas de disponibilidad:
- Establezca VSPHERE_REGION y VSPHERE_ZONE con las categorías de etiqueta de región y zona k8s-region y k8s-zone.
  - Estas variables también configuran la topología CSI; consulte Implementar un clúster con etiquetas de región y zona para CSI.
- Establezca VSPHERE_AZ_0, VSPHERE_AZ_1 y VSPHERE_AZ_2 con los nombres de los objetos VsphereDeploymentZone en los que se deben implementar las máquinas.
  - La VsphereDeploymentZone asociada con VSPHERE_AZ_0 es el VSphereFailureDomain en el que se implementa la implementación de la máquina que termina en md-0; de igual modo, VSPHERE_AZ_1 es el VSphereFailureDomain en el que se implementa la implementación de la máquina que termina en md-1 y VSPHERE_AZ_2 es el VSphereFailureDomain en el que se implementa la implementación de la máquina que termina en md-2.
  - Si alguna de las configuraciones de AZ no está definida, la implementación de la máquina se implementará sin ningún VSphereFailureDomain.
- WORKER_MACHINE_COUNT establece el número total de trabajos para el clúster. El número total de trabajadores se distribuye por turnos entre el número de AZ especificadas
- VSPHERE_AZ_CONTROL_PLANE_MATCHING_LABELS establece etiquetas de selector de clave/valor para las zonas de disponibilidad en las que pueden implementarse los nodos del plano de control del clúster.
  - Establezca esta variable si las opciones VSPHERE_REGION y VSPHERE_ZONE están establecidas.
  - Las etiquetas deben existir en los recursos de VSphereDeploymentZone que cree.
  - Estas etiquetas permiten especificar todas las zonas de disponibilidad en una región y un entorno sin tener que enumerarlas de forma individual, por ejemplo: "region=us-west-1,environment=staging".
Las variables de configuración de clúster para las AZ funcionan de la misma manera para los clústeres de administración independientes y los clústeres de carga de trabajo. Para obtener la lista completa de opciones que debe especificar al implementar clústeres de carga de trabajo en vSphere, consulte la Referencia de variables del archivo de configuración.
Ejecute tanzu cluster create para crear el clúster de carga de trabajo. Para obtener más información, consulte Crear clústeres de carga de trabajo.
- Para crear los objetos AZ por separado de la creación del clúster, inicie sesión en el clúster de administración con tanzu login y ejecute lo siguiente antes de ejecutar tanzu cluster create:
```
tanzu mc az set -f vsphere-zones.yaml
```
  O bien, puede ejecutar kubectl apply -f vsphere-zones.yaml
- Para utilizar las definiciones de objetos de AZ con un archivo de configuración de clúster plano y crear los objetos AZ y cluster juntos, pase el archivo vsphere-zones.yaml a la opción --az-file de tanzu cluster create:
```
tanzu cluster create --file cluster-config-file.yaml --az-file vsphere-zones.yaml
```
- Para combinar las definiciones de objetos de AZ en un manifiesto de clúster, cree el manifiesto del clúster siguiendo el paso 1 del proceso de dos pasos descrito en Crear un clúster basado en clases, anexe el contenido de vsphere-zones.yaml al manifiesto y, a continuación, ejecute tanzu cluster create como se describe en el paso 2.
- Durante el proceso de creación del clúster, puede ver que sus máquinas virtuales y otros recursos aparecen en vCenter.
- Si creó una máquina virtual ficticia en vCenter para crear un grupo de máquinas virtuales, puede eliminar la máquina virtual de los grupos de máquinas virtuales una vez que el clúster esté en ejecución.

Actualizar clústeres existentes para utilizar varias o diferentes zonas de disponibilidad

Puede actualizar un clúster de carga de trabajo o de administración ya implementado para ejecutar su plano de control o nodos de trabajo en varias zonas de disponibilidad (Availability Zones, AZ) o para cambiar las AZ en las que se ejecutan los nodos.

Puede asignar zonas de disponibilidad (AZ) a nodos de trabajo o plano de control de un clúster en su totalidad, o bien establecer AZ para implementaciones de máquinas subyacentes, a fin de personalizar vSphere configuración de máquina junto con las AZ para el conjunto de implementación de máquinas.

Después de actualizar las zonas de disponibilidad de un clúster de carga de trabajo existente, debe actualizar su interfaz de almacenamiento de contenedor (Container Storage Interface, CSI) y la interfaz de proveedor de nube (Cloud Provider Interface, CPI) para reflejar el cambio, como se describe en Actualizar CPI y CSI para cambios de zona de disponibilidad.

En las siguientes secciones se explica cómo actualizar las configuraciones de AZ de clúster existentes para diferentes escenarios.

Agregar zonas de disponibilidad para los nodos del plano de control

Para expandir un clúster de existente cuyos nodos de plano de control se ejecutan en una sola zona de disponibilidad para que su plano de control se ejecute en varias zonas de disponibilidad:

Prepare un archivo de configuración que defina un objeto VSphereFailureDomain y VSphereDeploymentZone para cada nueva zona de disponibilidad. En el siguiente ejemplo, vsphere-3-zones.yaml, se definen las zonas de disponibilidad rack1, rack2 y rack3 con la región room1:

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind:VSphereFailureDomain
metadata:
  name:rack
spec:
 region:
   name: room1
   type: ComputeCluster
   tagCategory: k8s-region
 zone:
   name:rack
   type: HostGroup
   tagCategory: k8s-zone
 topology:
   datacenter: dc0
   computeCluster: cluster0
 hosts:
   vmGroupName:rack-vm-group
   hostGroupName:rack
   datastore: ds1
   networks:
   - "VM Network"
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind:VSphereFailureDomain
metadata:
  name:rack
spec:
  region:
    name: room1
    type: ComputeCluster
    tagCategory: k8s-region
  zone:
    name: rack2
    type: HostGroup
    tagCategory: k8s-zone
  topology:
    datacenter: dc0
    computeCluster: cluster0
  hosts:
    vmGroupName: rack2-vm-group
    hostGroupName: rack2
    datastore: ds2
    networks:
    - "VM Network"
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereFailureDomain
metadata:
  name: rack3
spec:
  region:
    name: room1
    type: ComputeCluster
    tagCategory: k8s-region
  zone:
    name: rack3:
    type: HostGroup
    tagCategory: k8s-zone
  topology:
    datacenter: dc0
    computeCluster: cluster0
  hosts:
    vmGroupName: rack3-vm-group
    hostGroupName: rack3
    datastore: ds3
    networks:
    - "VM Network"
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereDeploymentZone
metadata:
  name: rack1
  labels:
    environment: "staging"
    region: "room1"
spec:
  server: VSPHERE_SERVER
  failureDomain: rack1
  placementConstraint:
    resourcePool: rp0
    folder: folder0
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereDeploymentZone
metadata:
  name: rack2
  labels:
    environment: "staging"
    region: "room1"
spec:
  server: VSPHERE_SERVER
  failureDomain: rack2
  placementConstraint:
    resourcePool: rp0
    folder: folder0
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereDeploymentZone
metadata:
  name: rack3
  labels:
    environment: "staging"
    region: "room1"
spec:
  server: VSPHERE_SERVER
  failureDomain: rack3
  placementConstraint:
    resourcePool: rp0
    folder: folder0

Donde VSPHERE_SERVER es la dirección IP o el FQDN de su vCenter Server.

Notas:

Asegúrese de que se creen las etiquetas y de que los recursos del inventario de vCenter Server se etiqueten correctamente, como se describe en Etiquetas vSphere en vSphere documentación del producto.
Debe establecer spec.placementConstraint.resourcePool en VSphereDeploymentZone. Si no hay ningún grupo de recursos creado por el usuario para el clúster, establezca el valor en el grupo de recursos predeterminado del clúster, cuya ruta de acceso es /dc0/host/cluster1/Resources.
Para objetos VSphereFailureDomain, ya no se admiten spec.region.autoConfigure ni spec.zone.autoConfigure.

Cree los objetos vSphereFailureDomain y VSphereDeploymentZone, por ejemplo:
```
tanzu mc az set -f vsphere-3-zones.yaml
```
Obtenga KubeAdmControlPlane del clúster de destino. En nuestro ejemplo, el destino es el clúster de administración tkg-mgmt-vc, pero también puede ser un clúster de carga de trabajo:
```
kubectl get kcp --selector cluster.x-k8s.io/cluster-name=tkg-mgmt-vc -n tkg-system -o=name

kubeadmcontrolplane.controlplane.cluster.x-k8s.io/tkg-mgmt-vc-cpkxj
```

Actualice el selector de AZ del clúster, por ejemplo, controlPlaneZoneMatchingLabels: {"environment": "staging", "region": "room1"}:

kubectl get cluster tkg-mgmt-vc -n tkg-system -o json | jq '.spec.topology.variables |= map(if .name == "controlPlaneZoneMatchingLabels" then .value = {"environment": "staging", "region": "room1"} else . end)'| kubectl apply -f -

cluster.cluster.x-k8s.io/tkg-mgmt-vc replaced

Compruebe que el dominio de errores del clúster se haya actualizado según lo esperado:

kubectl get cluster tkg-mgmt-vc -n tkg-system -o json | jq -r '.status.failureDomains | to_entries[].key'

Aplique una revisión a KubeAdmControlPlane con rolloutAfter para activar una actualización de los nodos del plano de control.

kubectl patch kcp tkg-mgmt-vc-cpkxj -n tkg-system --type merge -p "{\"spec\":{\"rolloutAfter\":\"$(date +'%Y-%m-%dT%TZ')\"}}"

Compruebe que los nodos del plano de control se hayan movido a las nuevas zonas de disponibilidad. Para ello, compruebe el host y el almacén de datos de los nodos en la vCenter o ejecute comandos kubectl get node o govc vm.info como los siguientes:
- kubectl get node NODE-NAME -o=jsonpath='{.metadata.labels.node.cluster.x-k8s.io/esxi-host}' --context tkg-mgmt-vc-admin@tkg-mgmt-vc
- govc vm.info -json NODE-NAME | jq -r '.VirtualMachines[].Config.Hardware.Device[] | select(.DeviceInfo.Label == "Hard disk 1") | .Backing.FileName'

Usar etiquetas de selector para especificar nuevas AZ del plano de control

Seleccionar AZ con etiquetas de selección significa especificar VSphereDeploymentZone por su metadata.labels en lugar de su metadata.name. Esto le permite configurar los nodos de plano de control de un clúster, por ejemplo, para que se ejecuten en todas las zonas de disponibilidad en una región y un entorno especificados sin enumerar las zonas de disponibilidad de forma individual: "region=us-west-1,environment=staging". También significa que puede actualizar las AZ de un plano de control de clúster sin tener que cambiar los nombres de las zonas de disponibilidad para los nodos del plano de control.

Para utilizar etiquetas de selector a fin de especificar nuevas zonas de disponibilidad para los nodos de plano de control de un clúster existente:

Prepare un archivo de configuración que defina un objeto VSphereFailureDomain y VSphereDeploymentZone para cada nueva zona de disponibilidad. En el siguiente ejemplo, vsphere-labeled-zones.yaml, se define una zona de disponibilidad rack4 con metadatos de etiquetas de selector:

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereFailureDomain
metadata:
  name: rack4
spec:
  region:
    name: room1
    type: ComputeCluster
    tagCategory: k8s-region
  zone:
    name: rack4
    type: HostGroup
    tagCategory: k8s-zone
  topology:
    datacenter: dc0
    computeCluster: cluster0
  hosts:
    vmGroupName: rack4-vm-group
    hostGroupName: rack4
    datastore: vsanDatastore
    networks:
    - "VM Network"
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereDeploymentZone
metadata:
  name: rack4
  labels:
    environment: staging
    region: room1
spec:
  server: VSPHERE_SERVER
  failureDomain: rack4
  placementConstraint:
    resourcePool: rp0
    folder: folder0

Cree los objetos VSphereFailureDomain y VSphereDeploymentZone, por ejemplo:
```
tanzu mc az set -f vsphere-labeled-zones.yaml
```
Actualice el clúster con la etiqueta del selector de zona de disponibilidad. El ejemplo aquí utiliza un selector de zona de disponibilidad controlPlaneZoneMatchingLabels: {"environment": "staging", "region": "room1"} para el clúster de administración tkg-mgmt-vc, pero también puede ser un clúster de carga de trabajo:
```
kubectl get cluster tkg-mgmt-vc -n tkg-system -o json | \
jq '.spec.topology.variables |= \
map(if .name == "controlPlaneZoneMatchingLabels" \
then .value = {"environment": "staging", "region": "room1"} \
else . end)'| kubectl apply -f -

cluster.cluster.x-k8s.io/tkg-mgmt-vc replaced
```
Compruebe el estado del clúster para asegurarse de que el dominio de errores se actualizó según lo esperado:
```
kubectl get cluster tkg-mgmt-vc -n tkg-system -o json | jq -r '.status.failureDomains | to_entries[].key'
```

Aplique una revisión al KubeAdmControlPlane con rolloutAfter para activar una actualización de los nodos del plano de control.

kubectl patch kcp tkg-mgmt-vc-cpkxj -n tkg-system --type merge -p "{\"spec\":{\"rolloutAfter\":\"$(date +'%Y-%m-%dT%TZ')\"}}"

Compruebe que los nodos del plano de control se muevan a nuevas zonas de disponibilidad seleccionadas por el selector en controlPlaneZoneMatchingLabels comprobando el host y el almacén de datos de los nodos en el vCenter o ejecutando los comandos kubectl get node o govc vm.info como los siguientes. En nuestro ejemplo, la nueva zona de disponibilidad es rack4:
- kubectl get node NODE-NAME -o=jsonpath='{.metadata.labels.node.cluster.x-k8s.io/esxi-host}' --context tkg-mgmt-vc-admin@tkg-mgmt-vc
- govc vm.info -json NODE-NAME | jq -r '.VirtualMachines[].Config.Hardware.Device[] | select(.DeviceInfo.Label == "Hard disk 1") | .Backing.FileName'

Cambiar AZ de implementación de máquina

Para cambiar una configuración de zona de disponibilidad en un clúster existente, aplique una revisión a las configuraciones subyacentes de MachineDeployment de sus nodos con el nuevo valor de AZ.

Por ejemplo, si el archivo de configuración del clúster establece VSPHERE_AZ_0 en rack1 y desea mover sus nodos de trabajo a rack2:

Consulte las zonas de disponibilidad actuales utilizadas para el clúster. En este ejemplo, se utiliza un clúster de carga de trabajo tkg-wc, pero también puede ser un clúster de administración:
```
kubectl get cluster tkg-wc -o json \| jq -r '.spec.topology.workers.machineDeployments\[0\].failureDomain'
```

Enumere todas las AZ disponibles.

kubectl get vspheredeploymentzones -o=jsonpath='{range .items[?(@.status.ready == true)]}{.metadata.name}{"\n"}{end}'

rack1
rack2

Aplique una revisión a la configuración spec.toplogy.workers.machineDeployments del clúster tkg-wc wc para establecer su zona VSphereFailureDomain en rack2. En este ejemplo, se supone que tkg-wc es un clúster del plandev de nodo único. Para un clúster del plan prod, deberá aplicar revisiones a las tres configuraciones de objetos de MachineDeployment del clúster.
```
kubectl patch cluster tkg-wc --type=json -p='[{"op": "replace", "path": "/spec/topology/workers/machineDeployments/0/failureDomain", "value": "rack2"}]'

cluster.cluster.x-k8s.io/tkg-wc patched
```

Compruebe que el clúster esté actualizado con VSphereFailureDomain rack2.

kubectl get cluster tkg-wc -o=jsonpath='{.spec.topology.workers.machineDeployments[?(@.name=="md-0")].failureDomain}'

rack2

Compruebe que los nodos de trabajo estén implementados en VSphereFailureDomain rack2.

Agregar AZ para implementaciones de máquinas

Para configurar nuevas AZ para que las utilicen clústeres de TKG y, a continuación, utilícelas en un clúster existente:

Prepare un archivo de configuración que defina un objeto VSphereFailureDomain y VSphereDeploymentZone para cada nueva zona de disponibilidad. Utilice el ejemplo vsphere-3-zones.yaml en Agrega AZ para nodos de plano de control anterior, que define las AZ rack1, rack2 y rack3 con la región room1.
Cree los objetos VSphereFailureDomain y VSphereDeploymentZone.
```
tanzu mc az set -f vsphere-3-zones.yaml
```
O bien, puede ejecutar kubectl apply -f vsphere-3-zones.yaml

Aplique una revisión en el clúster tkg-wc con VSphereFailureDomain rack1, rack2 y rack3. En este ejemplo, tkg-wc es un plan de clúster prod con tres configuraciones de MachineDeployment. Con un clúster de plan de dev solo es necesario actualizar una MachineDeployment en la spec.toplogy.workers.machineDeployments del clúster.

kubectl patch cluster tkg-wc --type=json -p='[  \
{"op": "replace", "path": "/spec/topology/workers/machineDeployments/0/failureDomain", "value": "rack1"}, \
{"op": "replace", "path": "/spec/topology/workers/machineDeployments/1/failureDomain", "value": "rack2"}, \
{"op": "replace", "path": "/spec/topology/workers/machineDeployments/2/failureDomain", "value": "rack3"}]'

Compruebe que el clúster de esté actualizado con la nueva zona de disponibilidad.

kubectl get cluster tkg-wc -o=jsonpath='{range .spec.topology.workers.machineDeployments[*]}{"Name: "}{.name}{"\tFailure Domain: "}{.failureDomain}{"\n"}{end}'

Compruebe que sus nodos de trabajo estén ahora implementados en VSphereFailureDomain rack1, rack2 y rack3.

Agregar AZ e implementaciones de máquinas nuevas

Para configurar nuevas AZ y nuevos objetos MachineDeployment para que los clústeres de TKG los utilicen y, a continuación, utilícelos en un clúster existente:

Prepare un archivo de configuración que defina un objeto VSphereFailureDomain y VSphereDeploymentZone para cada nueva zona de disponibilidad. En el siguiente ejemplo, vsphere-1-zone.yaml, se define la nueva zona de disponibilidad rack2 con la región room1:

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereFailureDomain
metadata:
 name: rack2
spec:
 region:
   name: room1
   type: ComputeCluster
   tagCategory: k8s-region
 zone:
   name: rack2
   type: HostGroup
   tagCategory: k8s-zone
 topology:
   datacenter: dc0
   computeCluster: cluster0
   hosts:
     vmGroupName: rack2-vm-grou
     hostGroupName: rack2
     datastore: ds-r2
   networks:
   - "VM Network"
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereDeploymentZone
metadata:
  name: rack2
spec:
  server: VSPHERE_SERVER
  failureDomain: rack2
  placementConstraint:
    resourcePool: rp0
    folder: folder0

Cree los objetos VSphereFailureDomain y VSphereDeploymentZone.
```
tanzu mc az set -f vsphere-zones.yaml
```
O bien, puede ejecutar kubectl apply -f vsphere-1-zone.yaml
Prepare un archivo de configuración para la implementación de la nueva máquina. El siguiente ejemplo, md-1.yaml, define una nueva implementación de máquina md-1 con su propiedad az establecida en rack2:
```
name: md-1
replicas: 1
az: rack2
nodeMachineType: t3.large
workerClass: tkg-worker
tkrResolver: os-name=ubuntu,os-arch=amd64
```
Use la CLI de Tanzu para crear un nuevo grupo de nodos. En este ejemplo, se utiliza el clúster de carga de trabajo tkg-wc, pero también puede ser un clúster de administración:
```
tanzu cluster node-pool set wl-antrea -f md-1.yaml

Cluster update for node pool 'md-1' completed successfully
```

Obtenga el nombre de implementación de la máquina en el nuevo grupo de nodos creado:

kubectl get machinedeployments -l
topology.cluster.x-k8s.io/deployment-name=md-1
-o=jsonpath='{.items[*].metadata.name}'

wl-antrea-md-1-pd9vj

Compruebe que la implementación de la máquina esté actualizada con VSphereFailureDomain rack2:

kubectl get machinedeployments wl-antrea-md-1-pd9vj -o json | \
jq -r '.spec.template.spec.failureDomain'

rack2

Compruebe que el nodo de trabajo de md-1 esté implementado en rack2.

Actualizar CPI y CSI para cambios de AZ

Después de cambiar la configuración de AZ de un clúster de carga de trabajo como se describe en cualquiera de las secciones anteriores, debe actualizar sus configuraciones de complementos CPI y CSI y, a continuación, volver a crear los complementos para reflejar los cambios. Las instrucciones que aparecen a continuación describen cómo hacerlo.

Limitaciones:

Antes de habilitar varias AZ para un clúster existente o de mover sus nodos de trabajo o de plano de control a una AZ diferente para un clúster existente, debe asegurarse de que los nodos del clúster nuevos puedan acceder al volumen persistente (PV) original del clúster.
Todos los ajustes de tagCategory en diferentes regiones y zonas de VsphereFailureDomain deben coincidir.
Antes de habilitar varias AZ para vSphere CSI, debe habilitar el kcp/worker de varias zonas de disponibilidad.

Actualizar CPI después del cambio de AZ

Para actualizar la configuración del complemento CPI de un clúster para que refleje un cambio de zona de disponibilidad y, a continuación, eliminar el instalador del paquete correspondiente para volver a crear el complemento con los cambios:

Recupere el nombre de la vsphereCPIConfig del clúster mediante la referencia cb. Por ejemplo, con un clúster de carga de trabajo denominado wl:
```
kubectl -n default get cb wl -o json \| jq -r '.spec.cpi.valuesFrom.providerRef.name'
```

Edite la especificación vsphereCPIConfig del clúster para establecer su region y zona de zone en los campos tagCategory que estableció para la región y la zona de la zona de AZ en vSphere y en la especificación vsphereFailuredomain. Por ejemplo:

apiVersion: cpi.tanzu.vmware.com/v1alpha1
kind: VSphereCPIConfig
metadata:
  name: wl
  namespace: default
spec:
  vsphereCPI:
    mode: vsphereCPI
    region: k8s-zone
    tlsCipherSuites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  vmNetwork:
    excludeExternalSubnetCidr: 10.215.10.79/32
    excludeInternalSubnetCidr: 10.215.10.79/32
  zone: k8s-zone

Aplique los cambios y espere a que Reconcile succeeded.

Confirme que el instalador del paquete CPI (pkgi) se ha reinstalado:

kubectl -n tkg-system get wl-vsphere-cpi pkgi --context wl-admin@wl

Actualizar CSI después del cambio de zona de disponibilidad

Para actualizar la configuración del complemento CSI de un clúster para que refleje un cambio de zona de disponibilidad y, a continuación, eliminar el csinodetopology y ek instalador del paquete correspondiente para volver a crear el complemento con los cambios:

Recupere el nombre de la vsphereCPIConfig del clúster mediante la referencia cb. Por ejemplo, con un clúster de carga de trabajo denominado wl:
```
kubectl -n default get cb wl  -o json  |jq  -r '.spec.csi.valuesFrom.providerRef.name')
```

Edite la especificación vsphereCSIConfig del clúster para establecer su region y zona de zone en los campos tagCategory que estableció para la región y la zona de la zona de AZ en vSphere y en la especificación vsphereFailuredomain. Por ejemplo:

apiVersion: csi.tanzu.vmware.com/v1alpha1
kind: VSphereCSIConfig
metadata:
  name: wl
  namespace: default
spec:
  vsphereCSI:
    config:
      datacenter: /dc0
      httpProxy: ""
      httpsProxy: ""
    insecureFlag: true
    noProxy: ""
  region: k8s-region
  tlsThumbprint: ""
  useTopologyCategories: true
  zone: k8s-zone
mode: vsphereCSI

Aplique los cambios.

Elimine los objetos csinode y csiNodeTopology para que vuelvan a crearse. csinodetopology no se actualiza automáticamente:

kubectl -n delete csinode --all --context wl-admin@wl
kubectl -n delete csinodetopology --all --context wl-admin@wl

Elimine el instalador del paquete vsphere-csi del clúster y espere a que Reconcile succeeded.
```
kubectl delete pkgi -n tkg-system wl-vsphere-csi --context wl-admin@wl
```

Compruebe que todos los objetos csinodes incluyan el parámetro topologyKeys, por ejemplo:

kubectl get csinodes -o jsonpath='{range .items[*]}{.metadata.name} {.spec}{"\n"}{end}'

k8s-control-1 {"drivers":[{"name":"csi.vsphere.vmware.com","nodeID":"k8s-control-1","topologyKeys":["topology.csi.vmware.com/k8s-region","topology.csi.vmware.com/k8s-zone"]}]}
k8s-control-2 {"drivers":[{"name":"csi.vsphere.vmware.com","nodeID":"k8s-control-2","topologyKeys":["topology.csi.vmware.com/k8s-region","topology.csi.vmware.com/k8s-zone"]}]}
k8s-control-3 {"drivers":[{"name":"csi.vsphere.vmware.com","nodeID":"k8s-control-3","topologyKeys":["topology.csi.vmware.com/k8s-region","topology.csi.vmware.com/k8s-zone"]}]}
k8s-node-1 {"drivers":[{"name":"csi.vsphere.vmware.com","nodeID":"k8s-node-1","topologyKeys":["topology.csi.vmware.com/k8s-region","topology.csi.vmware.com/k8s-zone"]}]}
k8s-node-2 {"drivers":[{"name":"csi.vsphere.vmware.com","nodeID":"k8s-node-2","topologyKeys":["topology.csi.vmware.com/k8s-region","topology.csi.vmware.com/k8s-zone"]}]}
k8s-node-3 {"drivers":[{"name":"csi.vsphere.vmware.com","nodeID":"k8s-node-3","topologyKeys":["topology.csi.vmware.com/k8s-region","topology.csi.vmware.com/k8s-zone"]}]}
k8s-node-4 {"drivers":[{"name":"csi.vsphere.vmware.com","nodeID":"k8s-node-4","topologyKeys":["topology.csi.vmware.com/k8s-region","topology.csi.vmware.com/k8s-zone"]}]}
k8s-node-5 {"drivers":[{"name":"csi.vsphere.vmware.com","nodeID":"k8s-node-5","topologyKeys":["topology.csi.vmware.com/k8s-region","topology.csi.vmware.com/k8s-zone"]}]}
k8s-node-6 {"drivers":[{"name":"csi.vsphere.vmware.com","nodeID":"k8s-node-6","topologyKeys":["topology.csi.vmware.com/k8s-region","topology.csi.vmware.com/k8s-zone"]}]}

Compruebe que las etiquetas de topología de todos los nodos reflejen las zonas y las regiones de AZ correctas, por ejemplo:

kubectl get nodes --show-labels
NAME            STATUS   ROLES                  AGE  VERSION   LABELS
k8s-control-1   Ready    control-plane          1d   v1.21.1   topology.csi.vmware.com/k8s-region=region-1,topology.csi.vmware.com/k8s-zone=zone-A
k8s-control-2   Ready    control-plane          1d   v1.21.1   topology.csi.vmware.com/k8s-region=region-1,topology.csi.vmware.com/k8s-zone=zone-B
k8s-control-3   Ready    control-plane          1d   v1.21.1   topology.csi.vmware.com/k8s-region=region-1,topology.csi.vmware.com/k8s-zone=zone-C
k8s-node-1      Ready    <none>                 1d   v1.21.1   topology.csi.vmware.com/k8s-region=region-1,topology.csi.vmware.com/k8s-zone=zone-A
k8s-node-2      Ready    <none>                 1d   v1.21.1   topology.csi.vmware.com/k8s-region=region-1,topology.csi.vmware.com/k8s-zone=zone-B
k8s-node-3      Ready    <none>                 1d   v1.21.1   topology.csi.vmware.com/k8s-region=region-1,topology.csi.vmware.com/k8s-zone=zone-B
k8s-node-4      Ready    <none>                 1d   v1.21.1   topology.csi.vmware.com/k8s-region=region-1,topology.csi.vmware.com/k8s-zone=zone-C
k8s-node-5      Ready    <none>                 1d   v1.21.1   topology.csi.vmware.com/k8s-region=region-2,topology.csi.vmware.com/k8s-zone=zone-D
k8s-node-6      Ready    <none>                 1d   v1.21.1   topology.csi.vmware.com/k8s-region=region-2,topology.csi.vmware.com/k8s-zone=zone-D

Enumerar zonas de disponibilidad

Utilice el comando tanzu mc az list para enumerar las AZ definidas en el clúster de administración independiente o utilizadas por un clúster de carga de trabajo:

Para enumerar las zonas de disponibilidad que están utilizando actualmente un clúster de administración y sus clústeres de carga de trabajo:
```
tanzu management-cluster available-zone list
```
Para enumerar todas las zonas de disponibilidad definidas en el clúster de administración y, por lo tanto, disponibles para los nodos del clúster de carga de trabajo:
```
tanzu management-cluster available-zone list -a
```
Para enumerar las zonas de disponibilidad utilizadas actualmente por el clúster de carga de trabajo CLUSTER-NAME:
```
tanzu management-cluster available-zone list -c CLUSTER-NAME:
```

El alias de los comandos tanzu mc az se obtiene de tanzu management-cluster available-zone.

Resultados de ejemplo:

AZNAME   ZONENAME  ZONETYPE    REGIONNAME REGIONTYPE DATASTORE   NETWORK   OWNERCLUSTER STATUS
us-west-1a us-west-1a ComputeCluster us-west-1  Datacenter sharedVmfs-0 VM Network az-1     ready
us-west-1b us-west-1b ComputeCluster us-west-1  Datacenter sharedVmfs-0 VM Network az-1     ready
us-west-1c us-west-1c ComputeCluster us-west-1  Datacenter sharedVmfs-0 VM Network az-1     ready

Los resultados indican:

AZNAME, ZONENAME: el nombre de la AZ
ZONETYPE: el tipo de objeto de vSphere en el ámbito de la AZ, ComputeCluster o HostGroup
REGIONNAME: el nombre de la región que contiene la AZ
REGIONTYPE: el tipo de objeto de vSphere en el ámbito de la región, Datacenter o ComputeCluster
DATASTORE: el almacén de datos que aloja las máquinas virtuales en la región
NETWORK: la red que presta servicio a las máquinas virtuales en la región
OWNERCLUSTER: clúster o clústeres de TKG que se ejecutan en la AZ
STATUS: el estado actual de la AZ

El alias del grupo de comandos tanzu mc az se obtiene de tanzu management-cluster available-zone.

Eliminar zonas de disponibilidad

Utilice el comando tanzu mc az delete para eliminar una AZ que no se utilice, por ejemplo:

tanzu mc az delete AZNAME

Donde AZNAME es el nombre de la AZ que aparece en tanzu mc az list.

Solo puede eliminar una AZ si actualmente no aloja nodos del clúster de TKG, es decir, si en tanzu mc az list no aparece ningún OWNERCLUSTER para la AZ.

Ejecución de clústeres en varias zonas de disponibilidad

Descripción general

Definir zonas de disponibilidad

Configurar clústeres de para utilizar zonas de disponibilidad

Requisitos previos

Implementar clústeres de carga de trabajo en varias zonas de disponibilidad

Preparar regiones y AZ en vSphere

Crear objetos FailureDomain y DeploymentZone en Kubernetes

Implementar el clúster de

Actualizar clústeres existentes para utilizar varias o diferentes zonas de disponibilidad

Agregar zonas de disponibilidad para los nodos del plano de control

Usar etiquetas de selector para especificar nuevas AZ del plano de control

Cambiar AZ de implementación de máquina

Agregar AZ para implementaciones de máquinas

Agregar AZ e implementaciones de máquinas nuevas

Actualizar CPI y CSI para cambios de AZ

Actualizar CPI después del cambio de AZ

Actualizar CSI después del cambio de zona de disponibilidad

Enumerar zonas de disponibilidad

Eliminar zonas de disponibilidad

Crear objetos `FailureDomain` y `DeploymentZone` en Kubernetes