Esta página se ha traducido con Cloud Translation API.

Migrar un clúster de usuarios a Controlplane V2

En este documento se muestra cómo migrar un clúster de usuario de la versión 1.29 a Controlplane V2 mediante kubeception. Si tus clústeres tienen la versión 1.30 o una posterior, te recomendamos que sigas las instrucciones que se indican en el artículo Planificar la migración de clústeres a las funciones recomendadas.

1.29: Vista previa
1.28: No disponible

Acerca de los planos de control de clústeres de usuarios

Antes de la versión 1.13 de Google Distributed Cloud, el plano de control de un clúster de usuario se ejecutaba en uno o varios nodos de un clúster de administrador. Este tipo de plano de control se denomina kubeception. En la versión 1.13, se introdujo Controlplane V2 para los nuevos clústeres de usuarios. Cuando Controlplane V2 está habilitado, el plano de control del clúster de usuarios se ejecuta en el propio clúster de usuarios.

Estas son algunas de las ventajas de Controlplane V2:

Aislamiento de errores. Si falla un clúster de administrador, no se verán afectados los clústeres de usuarios.
Separación operativa. La actualización de un clúster de administradores no provoca tiempos de inactividad en los clústeres de usuarios.
Separación de la implementación. Puedes colocar los clústeres de administradores y de usuarios en dominios de errores o sitios geográficos diferentes. Por ejemplo, un clúster de usuarios de una ubicación perimetral puede estar en un sitio geográfico diferente al del clúster de administrador.

Requisitos

Para migrar un clúster de usuarios a Controlplane V2, el clúster de usuarios debe cumplir los siguientes requisitos:

El clúster de usuarios debe tener la versión 1.29 o una posterior. El clúster de administrador y los grupos de nodos pueden tener una o dos versiones secundarias anteriores a la del clúster de usuario. Si es necesario, actualiza el clúster.
El clúster de usuario debe tener habilitado Dataplane V2. Este campo es inmutable, por lo que, si Dataplane V2 no está habilitado en el clúster, no puedes migrarlo a Controlplane V2.
El clúster de usuario debe configurarse para usar MetalLB o un balanceador de carga manual. Si el clúster de usuario usa el balanceador de carga SeeSaw, puedes migrarlo a MetalLB.
Consulta el documento de planificación de direcciones IP y asegúrate de que tienes suficientes direcciones IP disponibles para los nodos del plano de control del clúster de usuarios. Los nodos del plano de control requieren direcciones IP estáticas y necesitarás una dirección IP adicional para una nueva IP virtual (VIP) del plano de control.

Preparar la migración

Si el cifrado de secretos siempre activo se ha habilitado alguna vez en el clúster de usuario, debes seguir los pasos que se indican en Inhabilitar el cifrado de secretos siempre activo y descifrar secretos antes de iniciar la migración. De lo contrario, el nuevo clúster Controlplane V2 no podrá descifrar los secretos.

Antes de iniciar la migración, ejecuta el siguiente comando para ver si el cifrado de secretos siempre activo se ha habilitado en algún momento:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  get onpremusercluster USER_CLUSTER_NAME \
  -n USER_CLUSTER_NAME-gke-onprem-mgmt \
  -o jsonpath={.spec.secretsEncryption}

Si la salida del comando anterior está vacía, significa que el cifrado de secretos siempre activo nunca se ha habilitado. Puedes iniciar la migración.

Si la salida del comando anterior no está vacía, significa que el cifrado de secretos siempre activo se había habilitado anteriormente. Antes de migrar, debes seguir los pasos de la sección siguiente para asegurarte de que el nuevo clúster de Controlplane V2 pueda descifrar secretos.

En el siguiente ejemplo se muestra una salida no vacía:

{"generatedKeyVersions":{"keyVersions":[1]}}

Inhabilitar el encriptado de secretos siempre activo y descifrar los secretos si es necesario

Para inhabilitar el encriptado de secretos siempre activo y descifrar secretos, sigue estos pasos:

En el archivo de configuración del clúster de usuarios, para inhabilitar el cifrado de secretos siempre activos, añade un campo disabled: true a la sección secretsEncryption:
```
secretsEncryption:
    mode: GeneratedKey
    generatedKey:
        keyVersion: KEY_VERSION
        disabled: true
```
Actualiza el clúster:
```
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG
```
Haz los cambios siguientes:
- ADMIN_CLUSTER_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador
- USER_CLUSTER_CONFIG: la ruta del archivo de configuración del clúster de usuarios

Para hacer una actualización continua de un DaemonSet específico, sigue estos pasos:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  rollout restart statefulsets kube-apiserver \
  -n USER_CLUSTER_NAME

Obtén los manifiestos de todos los secretos del clúster de usuario en formato YAML:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  get secrets -A -o yaml > SECRETS_MANIFEST.yaml

Para que todos los secretos se almacenen en etcd como texto sin formato, vuelve a aplicar todos los secretos del clúster de usuario:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  apply -f SECRETS_MANIFEST.yaml
```
Ahora puedes iniciar la migración a Controlplane V2. Una vez completada la migración, puedes volver a habilitar el cifrado de secretos siempre activo en el clúster.

Corregir webhooks de cargas de trabajo mal configurados

Si tienes webhooks que incluyen pods del sistema en el espacio de nombres kube-system, añade namespaceSelector para filtrar el espacio de nombres kube-system.

Por ejemplo,

  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: NotIn
      values:
      - kube-system

Actualizar el archivo de configuración del clúster de usuarios

Haz los siguientes cambios en el archivo de configuración del clúster de usuarios:

Asigna el valor true a enableControlplaneV2.
Si quieres, puedes hacer que el plano de control del clúster de usuario Controlplane V2 tenga alta disponibilidad. Para cambiar de un clúster que no es de alta disponibilidad a uno que sí lo es, cambia masterNode.replicas de 1 a 3.
Añade la dirección IP estática (o las direcciones) de los nodos del plano de control del clúster de usuario a la sección network.controlPlaneIPBlock.ips. La dirección o las direcciones IP de los nodos del plano de control deben estar en la misma VLAN que los nodos de trabajo. Los nombres de host son obligatorios.
Rellena la máscara de subred y la pasarela en la sección network.controlPlaneIPBlock.
Si la sección network.hostConfig está vacía, rellénala.
Si el clúster de usuario usa el balanceo de carga manual, configura el balanceador de carga tal como se describe en la sección siguiente.
Si el clúster de usuario usa el balanceo de carga manual, asigna el valor 0 a loadBalancer.manualLB.controlPlaneNodePort y loadBalancer.manualLB.konnectivityServerNodePort, ya que no son necesarios cuando Controlplane V2 está habilitado.
Actualiza el campo loadBalancer.vips.controlPlaneVIP con la nueva dirección IP virtual del plano de control. Ten en cuenta que debe estar en la misma VLAN que las IPs de los nodos del plano de control.
Todos los campos anteriores son inmutables, excepto cuando se actualiza el clúster para la migración. Asegúrate de comprobar todos los ajustes.
Ejecuta gkectl diagnose cluster. Corrige los problemas que encuentre el comando.
```
gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
      --cluster-name=USER_CLUSTER_NAME
```
Haz los cambios siguientes:
- ADMIN_CLUSTER_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador.
- USER_CLUSTER_NAME: el nombre del clúster de usuarios.

Ajustar la configuración manual del balanceador de carga

Si tu clúster de usuario usa el balanceo de carga manual, sigue los pasos de esta sección. De lo contrario, sáltate esta sección.

Al igual que configuras el balanceador de carga para un clúster de usuario de CPv2, para cada una de las tres nuevas direcciones IP de los nodos del plano de control que hayas especificado en la sección network.controlPlaneIPBlock, configura las asignaciones en el balanceador de carga:

(ingressVIP:80) -> (NEW_NODE_IP_ADDRESS:ingressHTTPNodePort)
(ingressVIP:443) -> (NEW_NODE_IP_ADDRESS:ingressHTTPNodePort)

Actualizar el clúster

Ejecuta el siguiente comando para migrar el clúster a Controlplane V2:

gkectl update cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG

Haz los cambios siguientes:

ADMIN_CLUSTER_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador.
USER_CLUSTER_CONFIG: la ruta del archivo de configuración del clúster de usuarios.

El comando realiza lo siguiente:

Crea el plano de control de un clúster con ControlPlane V2 habilitado.
Detén el plano de control de Kubernetes del clúster de kubeception.
Haz una instantánea de etcd del clúster de kubeception.
Apaga los nodos del plano de control del clúster de usuarios del clúster de kubeception. Ten en cuenta que, para poder recuperarse en caso de fallo (es decir, volver al clúster de kubeception), los nodos no se eliminan hasta que se completa la migración.
Restaura los datos del clúster en el nuevo plano de control con la instantánea de etcd mencionada anteriormente.
Conecta los nodos del grupo de nodos del clúster de kubeception al nuevo plano de control, al que se puede acceder con el nuevo controlPlaneVIP.
Reconcilia el clúster de usuarios restaurado para que coincida con el estado final del clúster con ControlPlane V2 habilitado.

Notas

Durante la migración, no hay tiempo de inactividad para las cargas de trabajo de los clústeres de usuarios.
Durante la migración, el plano de control del clúster de usuarios experimenta un tiempo de inactividad. En concreto, el plano de control no está disponible entre el paso 2 y el paso 6. Según nuestras pruebas, el tiempo de inactividad es inferior a 7 minutos, pero la duración real depende de tu infraestructura.
Al final de la migración, se eliminan los nodos del plano de control del clúster de usuarios de los clústeres de kubeception. Si el clúster de administrador tiene el valor "static" en network.ipMode.type, puedes reciclar algunas de las IPs estáticas que no se utilicen. Para ello, elimínalas del archivo de configuración del clúster de administrador y ejecuta gkectl update admin. Puedes enumerar los objetos de nodo del clúster de administrador con kubectl get nodes -o wide para ver qué IPs se están usando.
Después de la migración, la antigua dirección VIP del plano de control sigue funcionando, pero es inestable. No te fíes de él. Actualiza lo antes posible las dependencias de la dirección VIP antigua para que usen la nueva.

Después de la migración

Si has inhabilitado el cifrado de secretos siempre activo antes de la migración, sigue estos pasos para volver a habilitar la función:

En el archivo de configuración del clúster de usuarios, asigna el valor false a secretsEncryption.generatedKey.disabled. Por ejemplo:
```
secretsEncryption:
    mode: GeneratedKey
    generatedKey:
        keyVersion: KEY_VERSION
        disabled: false
```

Actualiza el clúster de usuarios:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG