Los clústeres de Anthos en VMware ahora son Google Distributed Cloud (solo software) para VMware. Para obtener más información, consulta la descripción general del producto.

Se usó la API de Cloud Translation para traducir esta página.

Migra un clúster de administrador a las funciones recomendadas

Descripción general

En esta página, se muestra cómo migrar un clúster de administrador de la versión 1.30 o posterior a estas funciones recomendadas:

La configuración del balanceador de cargas:
- La configuración del balanceador de cargas BIG-IP de F5 integrado a ManualLB
  
  o
- El balanceador de cargas de Seesaw incluido en MetalLB.
Migra a un clúster de administrador de alta disponibilidad (HA) desde un clúster de administrador que no tiene HA. La disponibilidad mejora de forma significativa con un clúster de administrador de HA mientras se usa la misma cantidad de VMs. Un clúster de administrador sin alta disponibilidad tiene un nodo del plano de control y dos nodos de complementos. Los tres nodos de un clúster de administrador de HA son todos nodos del plano de control sin nodos de complementos.

Esta página está destinada a administradores de TI y operadores que administran el ciclo de vida de la infraestructura tecnológica subyacente. Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que hacemos referencia en el contenido de Google Cloud , consulta Tareas y roles comunes de los usuarios de GKE Enterprise.

Para obtener más información sobre la planificación de la migración, consulta Planifica la migración de clústeres a las funciones recomendadas.

Prácticas recomendadas

Si tienes varios entornos, como de prueba, desarrollo y producción, te recomendamos que primero migres el entorno menos crítico, como el de prueba. Después de verificar que la migración se realizó correctamente, repite este proceso para cada entorno y, por último, migra tu entorno de producción. Esto te permite validar el éxito de cada migración y asegurarte de que tus cargas de trabajo se ejecuten correctamente antes de pasar al siguiente entorno más crítico.

Requisitos

El clúster de administrador debe estar en la versión 1.30 o una posterior.
Todos los clústeres de usuario administrados por el clúster de administrador ya deben estar migrados a las funciones recomendadas, como se describe en Migra un clúster de usuario a las funciones recomendadas.

Planifica el tiempo de inactividad durante la migración

Para la migración, planifica un tiempo de inactividad limitado del plano de control. El acceso a la API de Kubernetes no está disponible para los clústeres de administrador que no son de alta disponibilidad durante aproximadamente 20 minutos, pero el plano de control de Kubernetes sigue disponible para los clústeres de administrador de alta disponibilidad con F5. Durante las migraciones, el plano de datos de Kubernetes sigue funcionando en un estado estable.

Desde	Para	Acceso a la API de Kubernetes	Cargas de trabajo de usuarios
Clústeres de administrador de alta disponibilidad con BIG-IP de F5	Clústeres de administrador de alta disponibilidad con `ManualLB`	No afectado	No afectado
clústeres de administrador sin alta disponibilidad con `MetalLB` o `ManualLB`	Clústeres de administrador de alta disponibilidad con el mismo tipo de balanceador de cargas	Afectado	No afectado
clústeres de administrador sin alta disponibilidad con BIG-IP de F5	Clústeres de administrador de alta disponibilidad con `ManualLB`	Afectado	No afectado
clústeres de administrador sin alta disponibilidad con Seesaw	Clústeres de administrador de alta disponibilidad con MetalLB	Afectado	No afectado

Afectado: Hay una interrupción notable del servicio durante la migración.
No afectado: No hay interrupción del servicio o es casi imperceptible.

Prepárate para la migración

Si tu clúster de administrador no tiene alta disponibilidad, sigue los pasos de esta sección para prepararte para migrar a un clúster de administrador con alta disponibilidad. Si tu clúster de administrador ya tiene HA, ve a la siguiente sección, Prepárate para la migración del balanceador de cargas.

Asigna direcciones IP adicionales

Cuando migres el clúster de administrador de no HA a HA, asigna cuatro direcciones IP adicionales. Asegúrate de que estas direcciones IP estén en la misma VLAN que los nodos del clúster de administrador existentes y que ningún nodo existente las esté usando:

Asigna una dirección IP para la nueva VIP del plano de control, para el campo loadBalancer.vips.controlPlaneVIP en el archivo de configuración del clúster de administrador.
Asigna direcciones IP nuevas para cada uno de los tres nodos del plano de control, para la sección network.controlPlaneIPBlock en el archivo de configuración del clúster de administrador.

Actualiza reglas de firewall

Cuando migres el clúster de administrador de no HA a HA, actualiza las reglas de firewall en tu clúster de administrador. Esto garantiza que las direcciones IP recién asignadas para los nodos del plano de control puedan llegar a todas las APIs requeridas y a otros destinos, como se describe en Reglas de firewall para clústeres de administrador.

Prepárate para la migración del balanceador de cargas

Si tu clúster de administrador usa la configuración de BIG-IP de F5 integrada o el balanceador de cargas Seesaw empaquetado, sigue los pasos de esta sección para realizar los cambios necesarios en el archivo de configuración del clúster de administrador. De lo contrario, continúa con la siguiente sección, Prepárate para migrar de un entorno sin HA a uno con HA.

BIG-IP de F5

Si tu clúster de administrador usa la configuración de BIG-IP F5 integrada, realiza los siguientes cambios en el archivo de configuración del clúster de administrador:

Establece el campo loadBalancer.kind como "ManualLB".
Establece o conserva el valor del campo loadBalancer.vips.controlPlaneVIP. Si tu clúster de administrador ya tiene alta disponibilidad, mantén el mismo valor. Si migras de un clúster de administrador que no tiene alta disponibilidad a un clúster de administrador con alta disponibilidad, cambia el valor del campo loadBalancer.vips.controlPlaneVIP a la dirección IP que asignaste.
Borra toda la sección loadBalancer.f5BigIP.

En el siguiente ejemplo de archivo de configuración del clúster de administrador, se muestran estos cambios:

loadBalancer:
vips:
  controlPlaneVIP: 192.0.2.6
kind: "F5BigIP" "ManualLB"
f5BigIP:
    address: "203.0.113.20"
  credentials:
    fileRef:
      path: ""my-config-folder/user-creds.yaml"
      entry: "f5-creds"
  partition: "my-f5-user-partition"

Seesaw

Si tu clúster de administrador usa el balanceador de cargas de Seesaw, realiza los siguientes cambios en el archivo de configuración del clúster de administrador:

Establece el campo loadBalancer.kind como "MetalLB".
Conserva la sección network.hostConfig.
Establece o conserva el valor del campo loadBalancer.vips.controlPlaneVIP]5. Si tu clúster de administrador ya tiene HA, puedes mantener el mismo valor. Si migras de un clúster de administrador que no tiene alta disponibilidad a uno que sí la tiene, cambia el valor del campo loadBalancer.vips.controlPlaneVIP a la dirección IP que asignaste.
Quita la sección loadBalancer.seesaw.

En el siguiente ejemplo de archivo de configuración del clúster de administrador, se muestran estos cambios:

network:
hostConfig:
  dnsServers:
  - "203.0.113.1"
  - "203.0.113.2"
  ntpServers:
  - "203.0.113.3"
loadBalancer:
vips:
  controlPlaneVIP: 192.0.2.6
kind: "MetalLB" "Seesaw"
seesaw:
  ipBlockFilePath: "user-cluster-1-ipblock.yaml"
  vrid: 1
  masterIP: ""
  cpus: 4
  memoryMB: 3072

Prepárate para migrar de un clúster sin alta disponibilidad a uno con alta disponibilidad

Si tu clúster de administrador no tiene alta disponibilidad, sigue los pasos de esta sección para prepararte para migrar a HA.

Si tu clúster de administrador ya tiene alta disponibilidad, ve a la siguiente sección, Migra el clúster de administrador.

Si la versión de tu clúster de administrador es 1.29.0-1.29.600 o 1.30.0-1.30.100, y la encriptación de secretos siempre activa se habilitó en el clúster de administrador en la versión 1.14 o anterior, debes rotar la clave de encriptación antes de iniciar la migración. De lo contrario, el nuevo clúster de administrador de HA no podrá desencriptar los secretos.

Para verificar si el clúster podría estar usando una clave de encriptación anterior, haz lo siguiente:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secret -n kube-system admin-master-component-options -o jsonpath='{.data.data}' | base64 -d | grep -oP '"GeneratedKeys":\[.*?\]'

Si el resultado muestra una clave vacía, como en el siguiente ejemplo, debes rotar la clave de encriptación con los pasos que se indican en este problema conocido.

"GeneratedKeys":[{"KeyVersion":"1","Key":""}]

Actualiza el archivo de configuración del clúster de administrador

Realiza los siguientes cambios en el archivo de configuración del clúster de administrador:

Completa network.controlPlaneIPBlock con las tres direcciones IP que asignaste para los nodos del plano de control.
Asegúrate de haber completado la sección network.hostConfig. En esta sección, se incluye información sobre los servidores NTP, los servidores DNS y los dominios de búsqueda de DNS que usan las VMs que son los nodos del clúster.
Asegúrate de reemplazar el valor de loadBalancer.vips.controlPlaneVIP por la dirección IP que asignaste.
Establece adminMaster.replicas en 3.
Quita el campo vCenter.dataDisk. En el caso de un clúster de administrador con HA, las rutas de acceso de los tres discos de datos que usan los nodos del plano de control se generan automáticamente en el directorio raíz anthos del almacén de datos.
Si loadBalancer.kind está configurado como "ManualLB", establece loadBalancer.manualLB.controlPlaneNodePort en 0.

En el siguiente ejemplo de archivo de configuración del clúster de administrador, se muestran estos cambios:

vCenter:
  address: "my-vcenter-server.my-domain.example"
  datacenter: "my-data-center"
  dataDisk: "xxxx.vmdk"
...
network:
  hostConfig:
    dnsServers:
    - 203.0.113.1
    - 203.0.113.2
    ntpServers:
    - 203.0.113.3
  ...
  controlPlaneIPBlock:
    netmask: "255.255.255.0"
    gateway: "198.51.100.1"
    ips:
    - ip: "192.0.2.1"
      hostname: "admin-cp-hostname-1"
    - ip: "192.0.2.2"
      hostname: "admin-cp-hostname-2"
    - ip: "192.0.2.3"
      hostname: "admin-cp-hostname-3"
...

...
loadBalancer:
  vips:
    controlPlaneVIP: 192.0.2.6 192.0.2.50
  kind: ManualLB
  manualLB:
    controlPlaneNodePort: 30003 0

...
adminMaster:
  replicas: 3
  cpus: 4
  memoryMB: 8192
...

Si es necesario, ajusta las asignaciones en el balanceador de cargas

Si tu clúster de administrador usó el balanceo de cargas manual, completa el paso que se indica en esta sección.

Si migras de F5 BIG-IP integrado al balanceo de cargas manual o a MetalLB, avanza a la siguiente sección, Migra el clúster de administrador.

Para cada una de las tres direcciones IP nuevas del nodo del plano de control que especificaste en la sección network.controlPlaneIPBlock, configura esta asignación en tu balanceador de cargas externo (como BIG-IP de F5 o Citrix):

(old controlPlaneVIP:443) -> (NEW_NODE_IP_ADDRESS:old controlPlaneNodePort)

Esto garantiza que la VIP del plano de control anterior siga funcionando durante la migración.

Migra el clúster de administrador

Revisa cuidadosamente todos los cambios que hiciste en el archivo de configuración del clúster de administrador. Todos los parámetros de configuración son inmutables, excepto cuando se actualiza el clúster para la migración.

Actualiza el clúster:

gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG

Replace the following:

ADMIN_CLUSTER_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador
ADMIN_CLUSTER_CONFIG: Es la ruta de acceso del archivo de configuración del clúster de administrador.

El comando muestra el progreso de la migración.

Cuando se le solicite, ingrese Y para continuar.

Durante la migración de no HA a HA, la VIP del plano de control anterior sigue funcionando y se puede usar para acceder al nuevo clúster de administrador de HA. Cuando se completa la migración, el archivo kubeconfig del clúster de administrador se actualiza automáticamente para usar la nueva VIP del plano de control.

Después de la migración

Cuando se complete la actualización, verifica que el clúster de administrador esté en ejecución:

kubectl get nodes --kubeconfig ADMIN_CLUSTER_KUBECONFIG

El resultado esperado es similar al siguiente:

Migración del balanceador de cargas

Si migraste el balanceador de cargas, verifica que los componentes del balanceador de cargas se ejecuten correctamente.

MetalLB

Si migraste a MetalLB, verifica que los componentes de MetalLB se ejecuten correctamente con el siguiente comando:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods \
    --namespace kube-system --selector app=metallb

En el resultado, se muestran los Pods para el controlador y el interlocutor de MetalLB. Por ejemplo:

metallb-controller-744884bf7b-rznr9 1/1 Running
metallb-speaker-6n8ws 1/1 Running
metallb-speaker-nb52z 1/1 Running
metallb-speaker-rq4pp 1/1 Running

Después de una migración exitosa, borra las VMs de Seesaw apagadas del clúster de admin. Puedes encontrar los nombres de las VMs de Seesaw en la sección vmnames del archivo seesaw-for-gke-admin.yaml en tu directorio de configuración.

`ManualLB`

Después de actualizar tus clústeres para usar el balanceo de cargas manual, el tráfico a los clústeres no se interrumpe. Esto se debe a que los recursos de F5 existentes aún existen, como puedes ver si ejecutas el siguiente comando:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \

El resultado esperado es similar al siguiente:

Warning: v1 ComponentStatus is deprecated in v1.19+
NAMESPACE     NAME                        TYPE     DATA   AGE
kube-system   secret/bigip-login-xt697x   Opaque   4      13h
NAMESPACE     NAME                              SECRETS   AGE
kube-system   serviceaccount/bigip-ctlr         0         13h
kube-system   serviceaccount/load-balancer-f5   0         13h
NAMESPACE     NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
kube-system   deployment.apps/k8s-bigip-ctlr-deployment   1/1     1            1           13h
kube-system   deployment.apps/load-balancer-f5            1/1     1            1           13h
NAME                                                                                ROLE                                       AGE
clusterrolebinding.rbac.authorization.k8s.io/bigip-ctlr-clusterrole-binding         ClusterRole/bigip-ctlr-clusterrole         13h
clusterrolebinding.rbac.authorization.k8s.io/load-balancer-f5-clusterrole-binding   ClusterRole/load-balancer-f5-clusterrole   13h
NAME                                                                 CREATED AT
clusterrole.rbac.authorization.k8s.io/bigip-ctlr-clusterrole         2024-03-25T04:37:34Z
clusterrole.rbac.authorization.k8s.io/load-balancer-f5-clusterrole   2024-03-25T04:37:34Z