Planificar la migración de clústeres a las funciones recomendadas

Información general

Google Distributed Cloud se basa en Kubernetes y en muchas otras tecnologías relacionadas, que se actualizan y mejoran continuamente para ofrecer una mayor escalabilidad, rendimiento, seguridad y capacidades de integración. Por lo tanto, Google Distributed Cloud se adapta y mejora constantemente.

En la versión 1.30, los cambios y las actualizaciones han llegado a un punto en el que te recomendamos encarecidamente que migres las implementaciones antiguas para aprovechar las mejoras significativas. En esta página se describen las ventajas de migrar de funciones obsoletas a las funciones recomendadas más recientes.

Tienes las siguientes opciones para cada área de funciones:

Área de la función Opciones recomendadas Opciones originales
Interfaz de red de contenedores (CNI)
  • Dataplane V2
    (enableDataplaneV2: true)
  • Dataplane V1 (Calico)
    (enableDataplaneV2: false)
Balanceador de carga
  • ManualLB (funciona con agentes de F5 Big IP)
    (loadBalancer.kind: "ManualLB")
  • MetalLB
    (loadBalancer.kind: "MetalLB")
  • F5 Big IP integrado1
    (loadBalancer.kind: "F5BigIP")
  • Seesaw
    (loadBalancer.kind: "Seesaw")
Plano de control del clúster de administrador
  • Clúster de administrador de alta disponibilidad (HA)
    (adminMaster.replicas: 3)
  • Clúster de administrador sin alta disponibilidad
    (adminMaster.replicas: 1)
Plano de control de clústeres de usuarios
  • Controlplane V2
    (enableControlplaneV2: true)
  • Clúster de usuario de Kubeception
    (enableControlplaneV2: false)

1 F5 BIG-IP integrado hace referencia a loadBalancer.kind: "F5BigIP" y a los ajustes relacionados en la sección loadBalancer.f5BigIP de tu archivo de configuración del clúster.

En las siguientes tablas se muestra la matriz de compatibilidad de estas funciones en clústeres de administrador y de usuario:

Tipo de clúster Función obsoleta Añadir a un nuevo clúster Permitir la actualización del clúster Migración a la nueva función
Versión 1.32 y posteriores
Administrador Sin alta disponibilidad No No N/A
Seesaw No No N/A
F5 Big IP integrado No No N/A
Usuario Kubeception No No N/A
Seesaw No No N/A
F5 Big IP integrado No No N/A
Dataplane V1 No No N/A
Versiones 1.30 y 1.31
Administrador Sin alta disponibilidad No Sí Sí
Seesaw No Sí Sí
F5 Big IP integrado No Sí Sí
Usuario Kubeception No Sí Sí
Seesaw No Sí Sí
F5 Big IP integrado No Sí Sí
Dataplane V1 No Sí Sí
Versión 1.29
Administrador Sin alta disponibilidad No Sí Sí (Vista previa)
Seesaw No Sí Sí
F5 Big IP integrado Sí Sí Sí (Vista previa)
Usuario Kubeception Sí Sí Sí (Vista previa)
Seesaw Sí Sí Sí
F5 Big IP integrado Sí Sí Sí (Vista previa)
Dataplane V1 Sí Sí No
Versión 1.28
Administrador Sin alta disponibilidad No Sí No
Seesaw No Sí Sí
F5 Big IP integrado Sí Sí No
Usuario Kubeception Sí Sí No
Seesaw Sí Sí Sí
F5 Big IP integrado Sí Sí No
Dataplane V1 Sí Sí No

Puntos clave:

  • A partir de la versión 1.30, todas las soluciones de migración están disponibles para migrar clústeres a sus alternativas recomendadas.

  • Cuando crees clústeres, estas son las versiones en las que no se permiten las funciones originales:

    • Clústeres de administrador:

      • Plano de control sin alta disponibilidad: 1.28 y versiones posteriores
      • Balanceo de carga de Seesaw: 1.28 y versiones posteriores
      • F5 Big IP integrado: 1.30 y versiones posteriores

    • Clústeres de usuarios:

      • Kubeception: 1.30 y versiones posteriores
      • Seesaw: 1.30 y versiones posteriores
      • F5 Big IP integrado: 1.30 y versiones posteriores
      • Dataplane V1: 1.30 y versiones posteriores

  • Puedes seguir actualizando los clústeres con las funciones originales.

Migrar clústeres de usuarios a Dataplane V2

Puedes elegir una interfaz de red de contenedor (CNI) que ofrezca funciones de red de contenedores, como Calico o Dataplane V2. Dataplane V2, la implementación de CNI de Google, se basa en Cilium y se usa tanto en Google Kubernetes Engine (GKE) como en Google Distributed Cloud.

Dataplane V2 ofrece un diseño optimizado y un uso eficiente de los recursos, lo que mejora el rendimiento de la red y la escalabilidad, especialmente en clústeres grandes o entornos con una gran demanda de tráfico de red. Te recomendamos encarecidamente que migres los clústeres a Dataplane V2 para disfrutar de las últimas funciones, innovaciones de redes y capacidades.

A partir de la versión 1.30, Dataplane V2 es la única opción de CNI para crear clústeres.

La transición de Calico a Dataplane V2 requiere planificación y coordinación, pero se ha diseñado para que no haya tiempo de inactividad en las cargas de trabajo. Si migras a Dataplane V2 de forma proactiva, podrás disfrutar de las siguientes ventajas:

  • Rendimiento y escalabilidad mejorados: el diseño optimizado y el uso eficiente de los recursos de Dataplane V2 pueden mejorar el rendimiento de la red y la escalabilidad, sobre todo en clústeres grandes o entornos con una gran demanda de tráfico de red. Esto se debe al uso de EBPF en lugar de IPTables, lo que permite que el clúster se escale mediante mapas BPF.

  • Gestión y asistencia simplificadas: estandarizar Dataplane V2 en Google Distributed Cloud y GKE puede simplificar la gestión de clústeres y la solución de problemas, ya que puedes usar un conjunto coherente de herramientas y documentación.

  • Funciones de redes avanzadas: EgressNAT y otras funciones de redes avanzadas solo se admiten en Dataplane V2. Las futuras solicitudes de red se implementarán en la capa Dataplane V2.

Antes de la migración Después de la migración
kube-proxy Obligatorio y desplegado automáticamente No es obligatorio y no se ha implementado
Enrutamiento kube-proxy + iptables eBPF

Migrar el tipo de balanceador de carga

Los tipos de balanceadores de carga recomendados (loadBalancer.kind) son "ManualLB" y "MetalLB". Usa "ManualLB" si tienes un balanceador de carga de terceros, como F5 BIG-IP o Citrix. Usa "MetalLB" para nuestra solución de balanceo de carga agrupada con el balanceador de carga MetalLB.

A partir de la versión 1.30, estas son las únicas opciones para crear clústeres. En el caso de los clústeres que ya usan el balanceador de carga integrado F5 Big IP o el balanceador de carga de Seesaw incluido, proporcionamos guías de migración para migrar los ajustes de configuración de "F5BigIP" a "ManualLB" y para migrar el balanceador de carga incluido de Seesaw a MetalLB.

Migrar la configuración del balanceador de carga F5 BIG-IP

Planifica la migración de los clústeres que usen F5 Big IP integrado a ManualLB. El servicio integrado F5 Big IP usa F5 BIG-IP con agentes de balanceador de carga, que constan de los dos controladores siguientes:

La integración original de F5 Big IP tiene las siguientes limitaciones:

  • Expresividad limitada: la integración de F5 Big IP restringe todo el potencial de F5 BIG-IP al limitar la expresividad de la API de servicio. Esto puede impedir que configures el controlador BIG-IP según tus necesidades específicas o que aproveches las funciones avanzadas de F5 que pueden ser cruciales para tu aplicación.
  • Componente antiguo: la implementación actual se basa en tecnologías antiguas, como la API ConfigMap de CCCL y CIS 1.x. Es posible que estos componentes antiguos no sean compatibles con los últimos avances de las ofertas de F5, lo que podría provocar que se pierdan oportunidades de mejorar el rendimiento y la seguridad.

Estos son algunos de los cambios que se producen al migrar de la integración de F5 BIG-IP a ManualLB:

Antes de la migración Después de la migración
Componentes de agentes de F5
  • Controlador F5
  • OSS CIS Controller
  • Controlador F5 (sin cambios)
  • Responsable del tratamiento de datos de CIS de OSS (sin cambios)
Actualización de la versión del componente F5 Para actualizar los componentes de F5, debes actualizar los clústeres. Las versiones de los componentes disponibles están limitadas, como se ha explicado anteriormente. Puedes actualizar las versiones de los componentes de F5 según sea necesario.
Creación de servicios Gestionado por agentes de F5 Gestionado por agentes de F5 (sin cambios)

Migrar de Seesaw a MetalLB

MetalLB ofrece las siguientes ventajas en comparación con Seesaw:

  • Gestión simplificada y reducción de recursos: a diferencia de Seesaw, MetalLB se ejecuta directamente en los nodos del clúster, lo que permite usar de forma dinámica los recursos del clúster para el balanceo de carga.
  • Asignación automática de IP: el controlador de MetalLB gestiona las direcciones IP de los servicios, por lo que no tienes que elegir manualmente una dirección IP para cada servicio.
  • Distribución de la carga entre los nodos de balanceo de carga: las instancias activas de MetalLB de diferentes servicios pueden ejecutarse en nodos distintos.
  • Funciones mejoradas y preparación para el futuro: el desarrollo activo de MetalLB y su integración con el ecosistema de Kubernetes en general lo convierten en una solución más preparada para el futuro que Seesaw. Si usas MetalLB, podrás aprovechar las últimas novedades en tecnología de balanceo de carga.
Antes de la migración Después de la migración
Nodos de balanceo de carga Máquinas virtuales de Seesaw adicionales (fuera del clúster) Nodos de balanceo de carga en clúster con opciones para el cliente
Conservación de la IP de cliente Se puede conseguir mediante externalTrafficPolicy: Local Se puede conseguir mediante el modo DSR de DataplaneV2
Creación de servicios IP de servicio especificada manualmente Dirección IP de servicio asignada automáticamente del grupo de direcciones

Migrar clústeres de usuarios a Controlplane V2 y clústeres de administrador a alta disponibilidad

El plano de control recomendado para los clústeres de usuarios es Controlplane V2. Con Controlplane V2, el plano de control se ejecuta en uno o varios nodos del propio clúster de usuario. Con el plano de control antiguo, denominado kubeception, el plano de control de un clúster de usuarios se ejecuta en un clúster de administrador. Para crear un clúster de administradores de alta disponibilidad, los clústeres de usuarios deben tener habilitado Controlplane V2.

A partir de la versión 1.30, los nuevos clústeres de usuario deben tener habilitado Controlplane V2 y los nuevos clústeres de administrador tendrán alta disponibilidad. Las actualizaciones de clústeres de usuarios con el plano de control antiguo siguen siendo compatibles, al igual que las actualizaciones de clústeres de administrador que no son de alta disponibilidad.

Migrar clústeres de usuarios a Controlplane V2

Históricamente, los clústeres de usuarios han usado kubeception. En la versión 1.13 se introdujo Controlplane V2 como función de vista previa, que pasó a estar disponible de forma general en la versión 1.14. Desde la versión 1.15, Controlplane V2 es la opción predeterminada para crear clústeres de usuario, y es la única opción en la versión 1.30.

En comparación con kubeception, estas son algunas de las ventajas de Controlplane V2:

  • Coherencia de la arquitectura: los clústeres de administrador y de usuario usan la misma arquitectura.
  • Aislamiento de errores: si se produce un error en un clúster de administrador, no afectará a los clústeres de usuario.
  • Separación operativa: la actualización de un clúster de administrador no provoca tiempo de inactividad en los clústeres de usuario.
  • Separación de la implementación: puedes colocar los clústeres de administrador y de usuario en dominios de topología diferentes o en varias ubicaciones. Por ejemplo, en un modelo de implementación de computación en el extremo, un clúster de usuarios puede estar en una ubicación diferente a la del clúster de administrador.

Durante la migración, las cargas de trabajo del clúster de usuarios no experimentarán ningún tiempo de inactividad. En función de tu entorno de vSphere subyacente, el plano de control experimentará un tiempo de inactividad mínimo durante el cambio a Controlplane V2. El proceso de migración hace lo siguiente:

  • Crea un nuevo plano de control en el clúster de usuarios.
  • Copia los datos de etcd del plano de control antiguo.
  • Transfiere los nodos del grupo de nodos (también llamados nodos de trabajo) al nuevo plano de control.
Antes de la migración Después de la migración
Objetos de nodo de Kubernetes del plano de control Nodo de clúster de administrador Nodo de clúster de usuarios
Pods del plano de control de Kubernetes StatefulSets o Deployments del clúster de administrador (espacio de nombres del clúster de usuario) Pods estáticos del clúster de usuarios (espacio de nombres kube-system)
Otros pods del plano de control StatefulSets o Deployments del clúster de administrador (espacio de nombres del clúster de usuario) StatefulSets o Deployments de clústeres de usuarios (espacio de nombres kube-system)
IP virtual del plano de control Servicio de balanceador de carga del clúster de administrador keepalived + haproxy (pods estáticos del clúster de usuario)
Datos de etcd Volumen persistente del clúster de administrador Disco de datos
Gestión de IPs de máquinas del plano de control IPAM o DHCP IPAM
Red del plano de control VLAN del clúster de administrador VLAN del clúster de usuarios

Migrar a un clúster de administradores de alta disponibilidad

Históricamente, el clúster de administrador solo podía ejecutar un nodo de plano de control, lo que creaba un riesgo inherente de un único punto de fallo. Además del nodo del plano de control, los clústeres de administración sin alta disponibilidad también tienen dos nodos de complementos. Un clúster de administrador de alta disponibilidad tiene tres nodos de plano de control sin nodos complementarios, por lo que el número de VMs que requiere un nuevo clúster de administrador no ha cambiado, pero la disponibilidad ha mejorado significativamente. A partir de la versión 1.16, puedes usar un clúster de administrador de alta disponibilidad (HA), que se convirtió en la única opción para crear clústeres en la versión 1.28.

Migrar a un clúster de administrador de alta disponibilidad ofrece las siguientes ventajas:

  • Mayor fiabilidad y tiempo de actividad: la configuración de alta disponibilidad elimina el único punto de fallo, lo que permite que el clúster de administrador siga funcionando aunque uno de los nodos del plano de control tenga un problema.
  • Experiencia de actualización mejorada: todos los pasos necesarios para actualizar un clúster de administrador ahora se ejecutan en el clúster, en lugar de en una estación de trabajo de administrador independiente. De esta forma, las actualizaciones y las mejoras se seguirán realizando aunque se interrumpa la sesión inicial en la estación de trabajo de administrador.
  • Fuente fiable de información sobre los estados del clúster: los clústeres de administradores que no son de alta disponibilidad se basan en un archivo de punto de control fuera de banda para almacenar el estado del clúster de administradores. Por el contrario, el clúster de administración de alta disponibilidad almacena el estado del clúster actualizado en el propio clúster de administración, lo que proporciona una fuente de información más fiable para el estado del clúster.

Puedes migrar tu clúster de administrador sin alta disponibilidad a un clúster de administrador con alta disponibilidad, lo que no implica ningún tiempo de inactividad para las cargas de trabajo de los usuarios. El proceso provoca un tiempo de inactividad mínimo y interrupciones en los clústeres de usuarios, principalmente asociados al cambio de plano de control. El proceso de migración hace lo siguiente:

  • Crea un nuevo plano de control de alta disponibilidad.
  • Restaura los datos de etcd del clúster sin alta disponibilidad.
  • Transfiere los clústeres de usuarios al nuevo clúster de administrador de alta disponibilidad.
Antes de la migración Después de la migración
Réplicas de nodos del plano de control 1 3
Nodos complementarios 2 0
Tamaño del disco de datos 100 GB * 1 25 GB * 3
Ruta de los discos de datos Definido por vCenter.dataDisk en el archivo de configuración del clúster de administrador Se genera automáticamente en el directorio: /anthos/[ADMIN_CLUSTER_NAME]/default/[MACHINE_NAME]-data.vmdk
IP virtual del plano de control Definido por loadBalancer.kind en el archivo de configuración del clúster de administrador keepalived + haproxy
Asignación de direcciones IP para los nodos de plano de control del clúster de administrador DHCP o estática, según network.ipMode.type 3 direcciones IP estáticas

Migraciones de balanceadores de carga y planos de control de grupos

Por lo general, cuando actualizas clústeres, te recomendamos que actualices solo una función o un ajuste a la vez. Sin embargo, en la versión 1.30 y posteriores, puedes agrupar los cambios de configuración de la migración tanto del balanceador de carga como del plano de control y, a continuación, actualizar el clúster solo una vez para aplicar ambos cambios.

Si tienes clústeres de usuarios que usan un CNI antiguo, primero debes migrar a DataPlane V2. Después, puedes agrupar la migración del balanceador de carga y del plano de control. Agrupar la migración ofrece las siguientes ventajas:

  • Un proceso más sencillo: si necesitas migrar tanto un plano de control como un balanceador de carga, normalmente solo tienes que actualizar el clúster una vez. Además, no tienes que decidir qué funciones quieres migrar primero.
  • Reducir el tiempo de inactividad general: algunas migraciones implican un tiempo de inactividad del plano de control, por lo que agrupar estas migraciones en una sola operación de actualización reduce el tiempo de inactividad general en comparación con la realización de actualizaciones individuales secuenciales.

El proceso varía en función de las configuraciones del clúster. En general, realiza la migración de cada clúster siguiendo los pasos que se indican a continuación:

  1. Migra cada clúster de usuarios para que use el CNI recomendado, Dataplane V2.

    1. Haz los cambios de configuración y actualiza el clúster de usuarios para activar la migración del clúster de usuarios del antiguo CNI, Calico, a Dataplane V2.

  2. Migra cada clúster de usuarios del antiguo balanceador de carga (LB) y del antiguo plano de control (CP) para que use el balanceador de carga recomendado y Controlplane V2.

    1. Cambia la configuración para usar el balanceador de carga recomendado (MetalLB o ManualLB).
    2. Haz cambios en la configuración para habilitar Controlplane V2.
    3. Actualiza el clúster de usuarios para migrar el balanceador de carga y el plano de control.

  3. Migra el clúster de administrador para que use el balanceador de carga recomendado y para que el plano de control tenga alta disponibilidad.

    1. Cambia la configuración para usar el balanceador de carga recomendado (MetalLB o ManualLB).
    2. Haz cambios en la configuración para migrar el plano de control del clúster de administrador de Non-HA a HA.
    3. Actualiza el clúster de administrador para migrar el balanceador de carga y el plano de control.

  4. Realiza los pasos de limpieza opcionales, como limpiar la VM del plano de control sin alta disponibilidad.

En el siguiente diagrama se muestran los pasos de la migración:

Pasos para migrar a las funciones recomendadas

Si tu clúster de administradores y todos tus clústeres de usuarios tienen la versión 1.30 o una posterior, puedes usar el proceso de migración de grupos. Para ver instrucciones detalladas, consulta las siguientes guías: