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

Migra un clúster de usuario a Controlplane V2

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

1.29: Versión preliminar
1.28: No disponible

Acerca de los planos de control del clúster de usuario

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 más nodos de un clúster de administrador. Este tipo de plano de control se conoce como kubeception. En la versión 1.13, Controlplane V2 se introdujo para los clústeres de usuarios nuevos. Cuando Controlplane V2 está habilitado, el plano de control del clúster de usuario se ejecuta en el mismo clúster de usuario.

Los beneficios de Controlplane V2 incluyen lo siguiente:

Aislamiento de fallas. Una falla del clúster de administrador no afecta a los clústeres de usuario.
Separación operativa. Una actualización de un clúster de administrador no genera tiempo de inactividad para los clústeres de usuario.
Separación de la implementación. Puedes colocar los clústeres de administrador y de usuario en diferentes dominios con fallas o sitios geográficos. Por ejemplo, un clúster de usuario en una ubicación perimetral puede estar en un sitio geográfico diferente del clúster de administrador.

Requisitos

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

El clúster de usuario debe ser de la versión 1.29 o superior. El clúster de administrador y los grupos de nodos pueden ser de una o dos versiones secundarias anteriores al 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 cargas manual. Si el clúster de usuario usa el balanceador de cargas de SeeSaw, puedes migrarlo a MetalLB.
Revisa el documento de planificación de direcciones IP y asegúrate de tener suficientes direcciones IP disponibles para los nodos del plano de control del clúster de usuario. Los nodos del plano de control requieren direcciones IP estáticas, y necesitarás una dirección IP adicional para una IP virtual (VIP) nueva del plano de control.

Prepárate para la migración

Si la encriptación de secretos siempre activa se habilitó en el clúster de usuarios, debes seguir los pasos que se indican en Inhabilita la encriptación de secretos siempre activa y desencriptar secretos antes de iniciar la migración. De lo contrario, el nuevo clúster de ControlPlane V2 no podrá desencriptar los secretos.

Antes de iniciar la migración, ejecuta el siguiente comando para ver si la encriptación de secretos siempre activa se habilitó 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 el resultado del comando anterior está vacío, significa que nunca se habilitó la encriptación de secretos siempre activa. Puedes iniciar la migración.

Si el resultado del comando anterior no está vacío, significa que la encriptación de Secrets siempre activa ya se había habilitado. Antes de migrar, debes seguir los pasos de la siguiente sección para asegurarte de que el nuevo clúster de Controlplane V2 pueda desencriptar los secretos.

En el siguiente ejemplo, se muestra un resultado no vacío:

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

Inhabilita la encriptación de secretos siempre activa y desencripta los secretos si es necesario

Para inhabilitar la encriptación de secretos siempre activa y desencriptar los secretos, sigue estos pasos:

En el archivo de configuración del clúster de usuario, para inhabilitar la encriptación de secretos siempre activa, agrega 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
```
Reemplaza lo siguiente:
- ADMIN_CLUSTER_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador
- USER_CLUSTER_CONFIG: la ruta del archivo de configuración de tu clúster de usuario

Realiza una actualización progresiva en un DaemonSet específico de la siguiente manera:

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 simple, vuelve a aplicar todos los secretos en el clúster de usuario:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  apply -f SECRETS_MANIFEST.yaml
```
Ahora puedes comenzar la migración a Controlplane V2. Una vez que se complete la migración, puedes volver a habilitar la encriptación de secretos siempre activa en el clúster.

Corrige los webhooks de carga de trabajo mal configurados

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

Por ejemplo:

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

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

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

Configura enableControlplaneV2 como verdadero.
De manera opcional, haz que el plano de control para el clúster de usuario de Controlplane V2 tenga alta disponibilidad (HA). Para cambiar de un clúster sin alta disponibilidad a un clúster de alta disponibilidad, cambia masterNode.replicas de 1 a 3.
Agrega las direcciones IP estáticas para los nodos del plano de control del clúster de usuarios a la sección network.controlPlaneIPBlock.ips. Las direcciones IP de los nodos del plano de control deben estar en la misma VLAN que los nodos trabajadores. Los nombres de host son obligatorios.
Completa la máscara de red y la puerta de enlace en la sección network.controlPlaneIPBlock.
Si la sección network.hostConfig está vacía, completala.
Si el clúster de usuario usa el balanceo de cargas manual, configura el balanceador de cargas como se describe en la siguiente sección.
Si el clúster de usuario usa el balanceo de cargas manual, establece loadBalancer.manualLB.controlPlaneNodePort y loadBalancer.manualLB.konnectivityServerNodePort en 0, ya que no son necesarios cuando Controlplane V2 está habilitado.
Actualiza el campo loadBalancer.vips.controlPlaneVIP con la dirección IP nueva para la VIP del plano de control. Ten en cuenta que debe estar en la misma VLAN que las IP del nodo del plano de control.
Todos los campos anteriores son inmutables, excepto cuando se actualiza el clúster para la migración. Asegúrate de volver a verificar toda la configuración.
Ejecuta gkectl diagnose cluster y soluciona cualquier problema que encuentre el comando.
```
gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
      --cluster-name=USER_CLUSTER_NAME
```
Reemplaza lo siguiente:
- ADMIN_CLUSTER_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador.
- USER_CLUSTER_NAME es el nombre del clúster de usuario.

Ajusta la configuración manual del balanceador de cargas

Si el clúster de usuario usa el balanceo de cargas manual, realiza el paso en esta sección. De lo contrario, omite esta sección.

De manera similar a configurar tu balanceador de cargas para un clúster de usuario de CPv2, para cada una de las tres direcciones IP nuevas del nodo del plano de control que especificaste en network.controlPlaneIPBlock, configura las asignaciones en tu balanceador de cargas:

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

Actualiza 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

Reemplaza lo siguiente:

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

El comando realiza lo siguiente:

Crea el plano de control de un clúster nuevo con ControlPlane V2 habilitado.
Detén el plano de control de Kubernetes del clúster de kubeception.
Toma una instantánea de etcd del clúster de kubeception.
Apaga los nodos del plano de control del clúster de usuario del clúster de kubeception. Ten en cuenta que, para la recuperación de fallas, es decir, si se recurre al clúster de kubeception, los nodos no se borran hasta que se completa la migración.
Restablece los datos del clúster en el nuevo plano de control con la instantánea de etcd anterior.
Conecta los nodos del grupo de nodos del clúster de kubeception al nuevo plano de control, al que se puede acceder con el controlPlaneVIP nuevo.
Concilia el clúster de usuario restablecido para cumplir 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 del clúster de usuario.
Durante la migración, hay un tiempo de inactividad para el plano de control del clúster de usuario. En particular, el plano de control no está disponible entre el paso 2 y la finalización del paso 6. (El tiempo de inactividad es inferior a 7 minutos según nuestras pruebas, pero la duración real depende de tu infraestructura).
Al final de la migración, se borran los nodos del plano de control del clúster de usuario de los clústeres de kubeception. Si el clúster de administrador tiene network.ipMode.type configurado como “static”, puedes reciclar algunas de las IP estáticas sin usar si las quitas del archivo de configuración del clúster de administrador y ejecutas gkectl update admin. Puedes enumerar los objetos del nodo del clúster de administrador con kubectl get nodes -o wide para ver qué IP están en uso.
Después de la migración, la antigua dirección VIP del plano de control sigue funcionando, pero es inestable. No dependas de él. Actualiza lo antes posible las dependencias de la dirección VIP anterior para usar la nueva.

Después de la migración

Si inhabilitaste la encriptación de secretos siempre activa 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 usuario, configura secretsEncryption.generatedKey.disabled como falso. Por ejemplo:
```
secretsEncryption:
    mode: GeneratedKey
    generatedKey:
        keyVersion: KEY_VERSION
        disabled: false
```

Actualiza el clúster de usuario:

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