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

Descripción general

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

En la versión 1.30, los cambios y las actualizaciones llegaron a un punto en el que te recomendamos mucho que migres las implementaciones heredadas para aprovechar mejoras significativas. En esta página, se describen los beneficios de migrar de funciones desactualizadas a las funciones recomendadas más recientes.

Tienes las siguientes opciones para cada área de componentes:

Área de características Opciones recomendadas Opciones originales
Interfaz de red de contenedor (CNI)
  • Dataplane V2
    (enableDataplaneV2: true)
  • Dataplane V1 (Calico)
    (enableDataplaneV2: false)
Balanceador de cargas
  • ManualLB (funciona con agentes de Big IP de F5)
    (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 con alta disponibilidad (HA)
    (adminMaster.replicas: 3)
  • Clúster de administrador que no es de HA
    (adminMaster.replicas: 1)
Plano de control del clúster de usuario
  • Controlplane V2
    (enableControlplaneV2: true)
  • Clúster de usuarios de Kubeception
    (enableControlplaneV2: false)

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

En las siguientes tablas, se muestra la matriz de compatibilidad de estas funciones en los clústeres de usuarios y administradores:

Tipo de clúster Función desactualizada Agrega para un clúster nuevo Permite la actualización del clúster Migración a una función nueva
Versión 1.30
Administrador non-HA 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 non-HA No Sí Sí (Versión preliminar)
Seesaw No Sí Sí
F5 Big IP integrado Sí Sí Sí (Versión preliminar)
Usuario Kubeception Sí Sí Sí (Versión preliminar)
Seesaw Sí Sí Sí
F5 Big IP integrado Sí Sí Sí (Versión preliminar)
Dataplane V1 Sí Sí No
Versión 1.28
Administrador non-HA 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 nuevos, estas son las versiones en las que no se permiten las funciones originales:

    • Clústeres de administrador:

      • Plano de control sin HA: 1.28 y versiones posteriores
      • Balanceo de cargas 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

  • Aún puedes actualizar los clústeres existentes con las funciones originales.

Migra clústeres de usuario a Dataplane V2

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

Dataplane V2 proporciona un diseño optimizado y un uso eficiente de los recursos, lo que mejora el rendimiento de la red y la escalabilidad, en particular para clústeres grandes o entornos con altas demandas de tráfico de red. Te recomendamos que migres los clústeres a Dataplane V2 para obtener las funciones, las innovaciones y las capacidades de red más recientes.

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

La transición de Calico a Dataplane V2 requiere planificación y coordinación, pero está diseñada para no implicar tiempo de inactividad para las cargas de trabajo existentes. Si migras de forma proactiva a Dataplane V2, puedes obtener los siguientes beneficios:

  • Rendimiento y escalabilidad mejorados: El diseño optimizado y el uso eficiente de recursos de Dataplane V2 pueden mejorar el rendimiento de la red y la escalabilidad, en particular en clústeres grandes o entornos con demandas de tráfico de red alto. Esto se debe al uso de eBPF en lugar de IPTables, que permite que el clúster escale con mapas de BPF.

  • Administración y asistencia simplificadas: La estandarización en Dataplane V2 en Google Distributed Cloud y GKE puede simplificar la administración y solución de problemas de los clústeres, ya que puedes confiar en un conjunto coherente de herramientas y documentación.

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

Antes de la migración Después de la migración
kube-proxy Obligatorio y se implementa automáticamente No es obligatorio ni se implementó
Enrutamiento kube-proxy + iptables eBPF

Migra el tipo de balanceador de cargas

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

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

Migra la configuración del balanceador de cargas F5 BIG-IP

Planifica migrar los clústeres que usan F5 Big IP integrado a ManualLB. F5 Big IP integrado usa F5 BIG-IP con agentes de balanceador de cargas, que consisten en los siguientes dos controladores:

F5 Big IP integrado original tiene las siguientes limitaciones:

  • Expresividad limitada: F5 Big IP integrado limita el potencial completo de BIG-IP de F5, ya que limita la expresividad de la API de Service. Esto puede impedir que configures el controlador BIG-IP según tus necesidades específicas o aproveches las funciones avanzadas de F5 que podrían ser fundamentales para tu aplicación.
  • Componente heredado: La implementación actual se basa en tecnologías más antiguas, como la API de ConfigMap de CCCL y CIS 1.x. Es posible que estos componentes heredados no sean compatibles con los avances más recientes en las ofertas de F5, lo que podría generar oportunidades perdidas de mejoras de rendimiento y seguridad.

Entre los cambios después de migrar de BIG-IP de F5 integrado a ManualLB, se incluyen los siguientes:

Antes de la migración Después de la migración
Componentes de los agentes de F5
  • F5 Controller
  • OSS CIS Controller
  • F5 Controller (sin cambios)
  • OSS CIS Controller (sin cambios)
Actualización de la versión del componente de F5 Debes actualizar los clústeres para actualizar los componentes de F5. Las versiones de los componentes disponibles son limitadas, como se explicó anteriormente. Puedes actualizar las versiones de los componentes de F5 según sea necesario.
Creación de servicios Administrado por agentes de F5 Controlado por agentes de F5 (sin cambios)

Migra de Seesaw a MetalLB

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

  • Administración simplificada y recursos reducidos: A diferencia de Seesaw, MetalLB se ejecuta directamente en los nodos del clúster, lo que permite el uso dinámico de los recursos del clúster para el balanceo de cargas.
  • Asignación automática de IP: El controlador de MetalLB realiza la administración de direcciones IP para los objetos Service, por lo que no tienes que elegir de forma manual una dirección IP para cada objeto Service.
  • Distribución de la carga entre los nodos de LB: Las instancias activas de MetalLB para diferentes servicios pueden ejecutarse en diferentes nodos.
  • Funciones mejoradas y preparación para el futuro: El desarrollo activo de MetalLB y su integración en el ecosistema más amplio de Kubernetes lo convierten en una solución más preparada para el futuro en comparación con Seesaw. El uso de MetalLB te garantiza que puedas aprovechar los avances más recientes en la tecnología de balanceo de cargas.
Antes de la migración Después de la migración
Nodos de LB VMs de Seesaw adicionales (fuera del clúster) Nodos de LB en el clúster con opciones del cliente
Conservación de la IP del cliente Se puede lograr a través de externalTrafficPolicy: Local Se puede lograr a través del modo DSR de DataplaneV2
Creación de servicios IP del servicio especificada de forma manual IP del servicio asignada automáticamente desde el grupo de direcciones

Migra clústeres de usuario a Controlplane V2 y clústeres de administrador a HA

El plano de control recomendado para los clústeres de usuario es Controlplane V2. Con Controlplane V2, el plano de control se ejecuta en uno o más nodos del clúster de usuario. Con el plano de control heredado, denominado kubeception, el plano de control para un clúster de usuario se ejecuta en un clúster de administrador. Para crear un clúster de administrador con alta disponibilidad (HA), tus clústeres de usuario deben tener habilitado Controlplane V2.

A partir de la versión 1.30, los clústeres de usuarios nuevos deben tener Controlplane V2 habilitado, y los clústeres de administrador nuevos serán de alta disponibilidad. Las actualizaciones de clústeres de usuarios con el plano de control heredado aún se admiten, al igual que las actualizaciones de clústeres de administradores que no son de alta disponibilidad.

Migra clústeres de usuario a Controlplane V2

Históricamente, los clústeres de usuarios usaron kubeception. En la versión 1.13, se ingresó Controlplane V2 como una función en versión preliminar, que pasó a la versión de DG en la versión 1.14. Desde la versión 1.15, Controlplane V2 es la opción predeterminada para crear clústeres de usuarios, y Controlplane V2 es la única opción en la versión 1.30.

En comparación con kubeception, los beneficios de Controlplane V2 incluyen los siguientes:

  • Coherencia arquitectónica: Los clústeres de administrador y de usuario usan la misma arquitectura.
  • 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 de topología o en varias ubicaciones. Por ejemplo, en un modelo de implementación de procesamiento perimetral, un clúster de usuario puede estar en una ubicación diferente al clúster de administrador.

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

  • Crea un nuevo plano de control en el clúster de usuario.
  • Copia los datos de etcd del plano de control anterior.
  • Realiza la transición de los nodos del grupo de nodos existentes (también llamados nodos trabajadores) al nuevo plano de control.
Antes de la migración Después de la migración
Objetos de nodos de Kubernetes del plano de control Nodo del clúster de administrador Nodo del clúster de usuarios
Pods del plano de control de Kubernetes StatefulSets o implementaciones 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 implementaciones del clúster de administrador (espacio de nombres del clúster de usuario) StatefulSets o implementaciones del clúster de usuario (espacio de nombres kube-system)
VIP del plano de control Servicio de balanceador de cargas del clúster de administrador keepalived + haproxy (Pods estáticos del clúster de usuarios)
Datos de Etcd Volumen persistente del clúster de administrador Disco de datos
Administración de IP de la máquina 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

Migra a un clúster de administrador de alta disponibilidad

Históricamente, el clúster de administrador solo podía ejecutar un solo nodo del plano de control, lo que creaba un riesgo inherente de un punto único de fallo. Además del nodo del plano de control, los clústeres de administrador que no son de alta disponibilidad también tienen dos nodos de complementos. Un clúster de administrador con HA tiene tres nodos de plano de control sin nodos complementarios, por lo que la cantidad de VMs que requiere un clúster de administrador nuevo no cambió, pero la disponibilidad mejoró 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 la creación de clústeres nuevos en la versión 1.28.

La migración a un clúster de administrador de alta disponibilidad ofrece los siguientes beneficios:

  • Confiabilidad y tiempo de actividad mejorados: La configuración de HA elimina el punto único de fallo, lo que permite que el clúster de administrador siga funcionando incluso si uno de los nodos del plano de control tiene un problema.
  • Experiencia de actualización mejorada: Ahora, todos los pasos necesarios para actualizar un clúster de administrador se ejecutan en el clúster, en lugar de en una VM de administrador independiente. Esto garantiza que las actualizaciones continúen incluso si se interrumpe la sesión inicial a la VM de administrador.
  • Fuente de información confiable para los estados de los clústeres: Los clústeres de administrador que no son de alta disponibilidad dependen de un "archivo de punto de control" fuera de banda para almacenar el estado del clúster de administrador. En cambio, el clúster de administrador de HA almacena el estado actualizado del clúster dentro del clúster de administrador, lo que proporciona una fuente de información más confiable 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 tiempo de inactividad para las cargas de trabajo de los usuarios. El proceso causa un tiempo de inactividad mínimo y una interrupción mínima de los clústeres de usuario existentes, principalmente asociados con el cambio de plano de control. El proceso de migración hace lo siguiente:

  • Crea un nuevo plano de control de alta disponibilidad.
  • Restablece los datos de etcd del clúster existente sin HA.
  • Realiza la transición de los clústeres de usuario 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 de complementos 2 0
Tamaño del disco de datos 100 GB * 1 25 GB * 3
Ruta de acceso a los discos de datos Se establece con 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
VIP del plano de control Se establece con loadBalancer.kind en el archivo de configuración del clúster de administrador. keepalived + haproxy
Asignación de direcciones IP para los nodos del plano de control del clúster de administrador DHCP o estática, según network.ipMode.type 3 direcciones IP estáticas

Agrupa las migraciones del balanceador de cargas y del plano de control

Por lo general, cuando actualizas clústeres, te recomendamos que actualices solo una función o un parámetro de configuración a la vez. Sin embargo, en la versión 1.30 y versiones posteriores, puedes agrupar los cambios de configuración para la migración del balanceador de cargas y el plano de control, y, luego, actualizar el clúster solo una vez para realizar ambos cambios.

Si tienes clústeres de usuario que usan una CNI anterior, primero debes migrar a Dataplane V2. Después de eso, puedes agrupar la migración del balanceador de cargas y el plano de control. Agrupar la migración proporciona los siguientes beneficios:

  • Un proceso más sencillo: Si necesitas migrar un plano de control y un balanceador de cargas, por lo general, solo actualizas el clúster una vez. Además, no es necesario que decidas qué funciones debes migrar primero.
  • Reduce el tiempo de inactividad general: Algunas migraciones implican tiempo de inactividad del plano de control, por lo que agruparlas en una operación de actualización reduce el tiempo de inactividad general en comparación con realizar actualizaciones individuales secuenciales.

El proceso varía según las configuraciones del clúster. En general, realiza la migración de cada clúster en el siguiente orden:

  1. Migra cada clúster de usuario para usar el CNI recomendado, Dataplane V2.

    1. Realiza los cambios de configuración y actualiza el clúster de usuario para activar una migración del clúster de usuario de Calico a Dataplane V2.

  2. Migra cada clúster de usuario para usar el balanceador de cargas y Controlplane V2 recomendados.

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

  3. Migra el clúster de administrador para usar el balanceador de cargas recomendado y hacer que el plano de control tenga alta disponibilidad.

    1. Realiza cambios de configuración para usar el balanceador de cargas recomendado (MetalLB o ManualLB).
    2. Realiza cambios de configuración para migrar el plano de control del clúster de administrador de no HA a HA.
    3. Actualiza el clúster de administrador para migrar el balanceador de cargas y el plano de control.

  4. Realiza pasos de limpieza opcionales, como limpiar la VM del plano de control que no tiene HA.

Si tu clúster de administrador y todos tus clústeres de usuario están en la versión 1.30 o una posterior, puedes usar el proceso de migración de grupos. Para obtener pasos detallados, consulta lo siguiente: