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

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.

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.

Configuración del objeto Cluster: La especificación del objeto Cluster configura las AZ 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 AZ:

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 Deployment Zone 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

AZ de grupo de hosts:

Para cada AZ, 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 grupo de hosts. Por ejemplo, para etiquetar el clúster /dc1/host/room1-mgmt como una región room1 y su grupo de hosts /dc1/host/room1-mgmt/esx-01a.corp.tanzu, etc. como AZ 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

Crear objetos `FailureDomain` y `Deployment Zone` en Kubernetes

Antes de implementar un clúster en varias zonas de disponibilidad, debe crear los objetos de Kubernetes FailureDomain y Deployment Zone que definen la región y las zonas. 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 los objetos FailureDomain y Deployment Zone como se indica a continuación, en función de si va a configurar AZ de clúster de vSphere o AZ 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
  spec:
   server: VSPHERE_SERVER
   failureDomain: us-west-1a
   placementConstraint:
     resourcePool: pool1
     folder: foo
  ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereDeploymentZone
  metadata:
   name: us-west-1b
  spec:
   server: VSPHERE_SERVER
   failureDomain: us-west-1b
   placementConstraint:
     resourcePool: pool2
     folder: bar
  ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereDeploymentZone
  metadata:
   name: us-west-1c
  spec:
   server: VSPHERE_SERVER
   failureDomain: us-west-1c
   placementConstraint:
     resourcePool: pool3
     folder: baz

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
  spec:
   server: VSPHERE_SERVER
   failureDomain: rack1
   placementConstraint:
     resourcePool: pool1
     folder: foo
  ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereDeploymentZone
  metadata:
   name: rack2
  spec:
   server: VSPHERE_SERVER
   failureDomain: rack2
   placementConstraint:
     resourcePool: pool2
     folder: bar
  ---
  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
  kind: VSphereDeploymentZone
  metadata:
   name: rack3
  spec:
   server: VSPHERE_SERVER
   failureDomain: rack3
   placementConstraint:
     resourcePool: pool3
   folder: baz

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

Para conocer los siguientes pasos para implementar el clúster, consulte Implementar un clúster de carga de trabajo con nodos repartidos entre las zonas de disponibilidad.

Implementar el clúster de

Después de realizar los pasos en Preparar regiones y AZ en vSphere y Crear objetos FailureDomain y Deployment Zone 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 Deployment Zone.

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 el archivo de configuración del clúster siguiendo Configurar varias zonas de disponibilidad para establecer VSPHERE_REGION, VSPHERE_ZONE, VSPHERE_AZ_0 y otras variables de configuración de modo que coincidan con las definiciones de objetos de AZ.
- 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.
(Opcional) Para evitar que el proceso de creación del clúster compruebe que las zonas y las regiones de vSphere especificadas en la configuración existen, son coherentes y están definidas en el mismo nivel, establezca SKIP_MULTI_AZ_VERIFY en "true" en el entorno local:
```
export SKIP_MULTI_AZ_VERIFY="true"
```
No puede establecer esta variable en el archivo de configuración del clúster.
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 mc 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
spec:
 server: VSPHERE_SERVER
 failureDomain: rack1
 placementConstraint:
 resourcePool: rp0
 folder: folder0
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereDeploymentZone
metadata:
 name: rack2
spec:
 server: VSPHERE_SERVER
 failureDomain: rack2
 placementConstraint:
 resourcePool: rp0
 folder: folder0
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereDeploymentZone
metadata:
 name: rack3
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

Requisitos previos

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

Preparar regiones y AZ en vSphere

Crear objetos FailureDomain y Deployment Zone 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 `Deployment Zone` en Kubernetes