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 F5 BIG-IP integrado en ManualLB.

    o

  • El balanceador de cargas de Seesaw incluido en MetalLB

• Migra a un clúster de administrador con alta disponibilidad (HA) desde un clúster de administrador sin HA. La disponibilidad mejora significativamente con un clúster de administrador de HA cuando 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 con alta disponibilidad 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 Roles y tareas comunes de los usuarios de GKE.

Para obtener más información sobre la planificación de la migración, consulta Planifica la migración del clúster 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 migra tu entorno de producción al final. 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 haberse migrado 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 sin HA durante unos 20 minutos, pero el plano de control de Kubernetes sigue disponible para los clústeres de administrador con HA y F5. Durante las migraciones, el plano de datos de Kubernetes sigue funcionando de forma estable.

Nota: Las cargas de trabajo de los usuarios solo deben ejecutarse en los clústeres de usuarios, que no se ven afectados cuando se migran los clústeres de administrador.

De	Para	Acceso a la API de Kubernetes	Cargas de trabajo de usuarios
Clústeres de administrador con alta disponibilidad y BIG-IP de F5	Clústeres de administrador con alta disponibilidad y 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 con alta disponibilidad y ManualLB	Afectado	No afectado
Clústeres de administrador sin alta disponibilidad con Seesaw	Clústeres de administrador con alta disponibilidad y 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 es de alta disponibilidad, prepárate para migrar a un clúster de administrador de alta disponibilidad siguiendo los pasos de esta sección. Si tu clúster de administrador ya es de 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 sin alta disponibilidad a alta disponibilidad, 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 use:

• 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 una dirección IP nueva a 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 sin alta disponibilidad a alta disponibilidad, 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 acceder a todas las APIs y otros destinos necesarios, 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 F5 BIG-IP integrada o el balanceador de cargas Seesaw incluido, 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, pasa a la siguiente sección, Cómo prepararse para migrar de un clúster sin alta disponibilidad a uno con alta disponibilidad.

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:

1. Establece el campo loadBalancer.kind en "ManualLB".
2. Establece o conserva el valor del campo loadBalancer.vips.controlPlaneVIP. Si tu clúster de administrador ya tiene alta disponibilidad, conserva el mismo valor. Si migras de un clúster de administrador sin 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.
3. Borra toda la sección loadBalancer.f5BigIP.

En el siguiente ejemplo de un 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:

1. Establece el campo loadBalancer.kind en "MetalLB".
2. Conserva la sección network.hostConfig.
3. Establece o conserva el valor del campo loadBalancer.vips.controlPlaneVIP]5. Si tu clúster de administrador ya tiene alta disponibilidad, puedes conservar el mismo valor. Si migras de un clúster de administrador sin 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.
4. Quita la sección loadBalancer.seesaw.

En el siguiente ejemplo de un 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 es de alta disponibilidad, prepárate para migrar a la alta disponibilidad siguiendo los pasos de esta sección.

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 de 1.29.0 a 1.29.600 o de 1.30.0 a 1.30.100, y si 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 antigua, 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 siguiendo los pasos que se indican en este problema conocido.

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

Advertencia: Si iniciaste la migración sin rotar la clave de encriptación, comunícate con el equipo de asistencia de Google.

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:

1. Completa network.controlPlaneIPBlock con las tres direcciones IP que asignaste para los nodos del plano de control.
2. 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.
3. Asegúrate de haber reemplazado el valor de loadBalancer.vips.controlPlaneVIP por la dirección IP que asignaste.
4. Establece adminMaster.replicas en 3.
5. Quita el campo vCenter.dataDisk. En el caso de un clúster de administrador con HA, las rutas de acceso a 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.
6. Si loadBalancer.kind se establece en "ManualLB", establece loadBalancer.manualLB.controlPlaneNodePort en 0.

En el siguiente ejemplo de un 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 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 con atención todos los cambios que realizaste 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 al 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 sin alta disponibilidad a alta disponibilidad, la VIP del plano de control anterior sigue funcionando y se puede usar para acceder al nuevo clúster de administrador con alta disponibilidad. Cuando se completa la migración, el archivo kubeconfig del clúster de administrador se actualiza automáticamente para usar la VIP nueva 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

El resultado muestra los Pods del 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 para el clúster de administrador. 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 que usen el balanceo de cargas manual, no se interrumpirá el tráfico hacia ellos. Esto se debe a que los recursos existentes de F5 siguen presentes, 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