Migra contenedores a Google Cloud: migra a un entorno de GKE de varios clústeres

Last reviewed 2023-05-08 UTC

Con este documento, podrás planificar, diseñar y, también, implementar la migración desde un entorno de Google Kubernetes Engine (GKE) a un entorno de GKE nuevo. Si se hace de forma incorrecta, mover las aplicaciones de un entorno a otro puede ser una tarea desafiante. Por lo tanto, debes planificar y ejecutar tu migración con cuidado.

Este documento pertenece a una serie de varias partes sobre la migración a Google Cloud. Para obtener una descripción general de la serie, consulta Migración a Google Cloud: Elige la ruta de migración.

Este documento es parte de una serie en la que se analiza la migración de contenedores a Google Cloud:

Este documento es útil si planeas migrar de un entorno de GKE a otro entorno de GKE. Este documento también es útil si estás evaluando la posibilidad de migrar y deseas explorar cómo podría ser.

Los motivos para migrar de un entorno de GKE a otro entorno de GKE pueden incluir los siguientes:

  • Habilita atributos de GKE disponibles solo durante la creación de clústeres. GKE está en constante evolución con nuevos atributos y correcciones de seguridad. Para beneficiarte de la mayoría de los atributos y correcciones nuevas, es posible que debas actualizar los clústeres y los grupos de nodos de GKE a una versión más reciente, ya sea a través de la actualización automática o de forma manual

    Algunos atributos nuevos de GKE no se pueden habilitar en los clústeres existentes, y requieren que crees clústeres de GKE nuevos con esos atributos nuevos habilitados. Por ejemplo, puedes habilitar los siguientes atributos: Redes nativas de VPC en GKE, Dataplane V2 u Ocultamiento de metadatos solo cuando creas clústeres nuevos. No puedes actualizar la configuración de los clústeres existentes para habilitar esos atributos después de su creación.

  • Implementar un proceso de aprovisionamiento y configuración automatizado para tu infraestructura. Si aprovisionas y configuras la infraestructura de forma manual, puedes diseñar e implementar un proceso automatizado para aprovisionar y configurar los clústeres de GKE, en lugar de depender de métodos manuales y propensos a errores.

Cuando diseñes la arquitectura de tu entorno nuevo, te recomendamos que consideres un entorno de GKE de varios clústeres. Si aprovisionas y configuras varios clústeres de GKE en tu entorno, harás lo siguiente:

  • Reducirás las posibilidades de ingresar un punto único de fallo en tu arquitectura. Por ejemplo, si un clúster sufre una interrupción, otros clústeres pueden tomar el control.
  • Obtendrás beneficios de la mayor flexibilidad que brinda un entorno de varios clústeres. Por ejemplo, la aplicación de cambios en un subconjunto de tus clústeres puede limitar el impacto de los problemas causados por los cambios de configuración erróneos. Luego, puedes validar los cambios antes de aplicarlos a los clústeres restantes.
  • Permitirá que tus cargas de trabajo se comuniquen entre clústeres. Por ejemplo, las cargas de trabajo implementadas en un clúster pueden comunicarse con las que se implementan en otro.

La guía de este documento también se aplica a un entorno de GKE de un solo clúster. Cuando migras a un entorno de GKE de un solo clúster, tu entorno es menos complejo de administrar en comparación con un entorno de varios clústeres. Sin embargo, un entorno de un solo clúster no se beneficia del aumento de flexibilidad, confiabilidad y resiliencia de un entorno de GKE de varios clústeres.

En el siguiente diagrama, se ilustra la ruta del recorrido de tu migración.

Ruta de migración con cuatro fases

El framework que se ilustra en el diagrama anterior tiene las siguientes fases, que se definen en Migración a Google Cloud: Comienza ahora:

  1. Evalúa y descubre las cargas de trabajo.
  2. Planifica y compila una base.
  3. Implementa cargas de trabajo.
  4. Optimiza tu entorno.

Debes seguir las fases anteriores durante cada paso de migración. Este documento también se basa en los conceptos que se analizan en Migra contenedores a Google Cloud: migra Kubernetes a GKE. Incluye vínculos cuando corresponda.

Evalúa tu entorno

En la fase de evaluación, debes recopilar información sobre tu entorno de origen y las cargas de trabajo que deseas migrar. Esta evaluación es fundamental para la migración y para redimensionar los recursos que necesitas para la migración y el entorno de destino. En la fase de evaluación, debes realizar las siguientes tareas:

  1. Crea un inventario completo de tus apps.
  2. Cataloga tus aplicaciones según sus propiedades y dependencias.
  3. Capacita y educa a tus equipos en Google Cloud.
  4. Compila un experimento y prueba de concepto en Google Cloud.
  5. Calcula el costo total de propiedad (TCO) del entorno de destino.
  6. Elige las cargas de trabajo que deseas migrar primero.

Las siguientes secciones se basan en el documento Migración a Google Cloud: evalúa y descubre tus cargas de trabajo. Sin embargo, proporcionan información específica para evaluar las cargas de trabajo que deseas migrar a clústeres de GKE nuevos.

En la guía Migra Kubernetes a GKE, Evalúa tu entorno describe cómo evaluar los recursos y clústeres de Kubernetes, como ServiceAccounts y PersistentVolumes. La información también se aplica a la evaluación del entorno de GKE.

Compila tus inventarios

Para determinar el alcance de tu migración, debes comprender tu entorno actual de GKE. Debes comenzar por recopilar información sobre tus clústeres y, luego, enfocarte en las cargas de trabajo implementadas en esos clústeres y en sus dependencias. Al final de la fase de evaluación, tienes dos inventarios: uno para los clústeres y otro para las cargas de trabajo implementadas en esos clústeres.

En la guía Migra Kubernetes a GKE, Compila tus inventarios describe cómo compilar los inventarios de los clústeres y cargas de trabajo de Kubernetes. También se aplica a la compilación de los inventarios de tus entornos de GKE. Antes de continuar con este documento, sigue esa guía para compilar el inventario de los clústeres de Kubernetes.

Después de seguir la guía Migra Kubernetes a GKE para compilar tus inventarios, define mejor los inventarios. A fin de completar el inventario de tus clústeres de GKE y los grupos de nodos, considera los aspectos y las funciones específicos de GKE para cada clúster y grupo de nodos, incluidos los siguientes:

Cuando compilas tu inventario, es posible que encuentres algunos clústeres de GKE que deban retirarse como parte de tu migración. Algunos recursos de Google Cloud no se borran cuando borras los clústeres de GKE que los crearon. Asegúrate de que tu plan de migración incluya la eliminación de esos recursos.

Para obtener información sobre otros posibles aspectos y características específicos de GKE, consulta la documentación de GKE.

Completa la evaluación

Después de compilar los inventarios relacionados con tus clústeres y cargas de trabajo de GKE, completa el resto de las actividades de la fase de evaluación en Migra contenedores a Google Cloud: Migra Kubernetes a GKE.

Planifica y compila tu base

En la fase de planificación, debes aprovisionar y configurar la base, la infraestructura de nube y los servicios compatibles con tus cargas de trabajo en Google Cloud. En la fase de planificación, debes realizar las siguientes tareas:

  • Compila una jerarquía de recursos.
  • Configura la administración de identidades y accesos.
  • Configura la facturación.
  • Configura la conectividad de red.
  • Endurece tu seguridad.
  • Configura la supervisión y las alertas.

Cuando configures la conectividad de red, asegúrate de tener suficientes direcciones IP en tus subredes para asignar nodos, Pods y objetos Service. Cuando configures las herramientas de redes para tus clústeres, planifica las asignaciones de direcciones IP con cuidado. Por ejemplo, puedes configurar IP públicas de uso privado para GKE. Los rangos de direcciones IP secundarios que estableces para los Pods y los objetos Service en tus clústeres no se pueden cambiar después de asignarlos. Ten especial cuidado si asignas un rango de Pod o Service de /22 (1,024 direcciones) o menos. De lo contrario, es posible que te quedes sin direcciones IP para los Pods y los objetos Service a medida que crece tu clúster. Para obtener más información, consulta Planificación del rango de direcciones IP.

Te recomendamos que uses una subred compartida separada para los balanceadores de cargas internos que crees para tu entorno de GKE. Cuando usas un Service de Kubernetes de type: LoadBalancer, puedes especificar una subred del balanceador de cargas. Cuando configuras balanceadores de cargas internos de HTTP(S) internos, debes configurar una subred de solo proxy.

Para compilar la base de tu entorno de GKE, completa las actividades de la fase de planificación y compilación en Migra contenedores a Google Cloud: Migra Kubernetes a GKE.

Implementa tus cargas de trabajo

En la fase de implementación, debes realizar las siguientes tareas:

  1. Aprovisionar y configurar el entorno de destino.
  2. Migrar datos de tu entorno de origen al entorno de destino.
  3. Implementar tus cargas de trabajo en el entorno de destino.

En esta sección, se proporciona información específica para implementar cargas de trabajo en GKE. Se basa en la información de Migra Kubernetes a GKE: implementa tus cargas de trabajo.

Evalúa la plataforma y los entornos de ejecución

Para tener una infraestructura más flexible, confiable y fácil de mantener, te recomendamos que diseñes y, además, implementes una arquitectura de varios clústeres. En una arquitectura de varios clústeres, tienes varios clústeres de producción de GKE en tu entorno. Por ejemplo, si aprovisionas varios clústeres de GKE en tu entorno, puedes implementar estrategias avanzadas de ciclo de vida de los clústeres, como actualizaciones progresivas o actualizaciones azul-verde. Para obtener más información sobre los diseños de arquitectura de GKE de varios clústeres y sus beneficios, consulta Actualizaciones de GKE de varios clústeres con Ingress de varios clústeres.

Cuando ejecutas tu entorno en varios clústeres, existen desafíos adicionales que debes considerar, como los siguientes:

  • Debes adaptar la administración de configuración, el descubrimiento y la comunicación de servicios, los lanzamientos de aplicaciones y el balanceo de cargas para el tráfico entrante.
  • Es probable que debas ejecutar software adicional en tu clúster, y una infraestructura y automatización adicionales.

Para abordar estos desafíos, es posible que necesites canalizaciones de integración continua/implementación continua (CI/CD) para actualizar la configuración de los clústeres de forma secuencial para minimizar el impacto de los errores. Es posible que también necesites balanceadores de cargas para distribuir el tráfico de un clúster a otros clústeres.

La administración manual de tu infraestructura es propensa a errores y te expone a problemas debido a una configuración incorrecta y a la falta de documentación interna sobre el estado actual de la infraestructura. Para mitigar los riesgos debido a esos problemas, te recomendamos que apliques la infraestructura como patrón de código. Cuando aplicas este patrón, tratas el aprovisionamiento de la infraestructura de la misma manera que manejas el código fuente de las cargas de trabajo.

Existen varias opciones de arquitectura para tu entorno de GKE de varios clústeres, que se describen más adelante en esta sección. Elegir una opción por sobre otras depende de varios factores, y ninguna opción es intrínsecamente mejor que las otras. Cada tipo tiene sus propias fortalezas y debilidades. Para elegir un tipo de arquitectura, sigue estos pasos:

  1. Establece un conjunto de criterios para evaluar los tipos de arquitecturas de entornos de GKE de varios clústeres
  2. Evalúa cada opción en función de los criterios de evaluación.
  3. Elige la opción que mejor se adapte a tus necesidades.

Para establecer los criterios de evaluación de los tipos de arquitectura de entornos de GKE de varios clústeres, usa la evaluación del entorno que completaste para identificar las funciones que necesitas. Ordena las funciones según la importancia. Por ejemplo, después de evaluar las cargas de trabajo y el entorno, puedes considerar los siguientes criterios de evaluación, que se muestran según su posible orden de importancia:

  1. Solución administrada por Google. ¿Prefieres los servicios y productos autoadministrados o administrados por Google?
  2. Interfaces para interactuar con la arquitectura. ¿Existe una interfaz procesable con la que puedas interactuar? ¿Se define la interfaz como un estándar abierto? ¿Admite la interfaz directivas declarativas, directivas imperativas o ambas?
  3. Expón los servicios fuera del entorno de GKE. ¿Te permite la arquitectura exponer tus cargas de trabajo fuera del clúster de GKE en el que se implementan?
  4. Comunicación entre clústeres. ¿Admite la arquitectura canales de comunicación entre clústeres? ¿Admiten las cargas de trabajo una arquitectura distribuida? Este criterio es importante para admitir cargas de trabajo con un diseño distribuido, como Jenkins.
  5. Administración del tráfico. ¿La arquitectura admite atributos de administración avanzada del tráfico, como inyección de fallas, transferencia de tráfico, solicitud de tiempos de espera y reintentos, disyuntores y duplicación de tráfico? ¿Estos atributos están listos para usarse o tienes que implementarlos tú mismo?
  6. Aprovisiona y configura herramientas adicionales. ¿Necesitas aprovisionar y configurar componentes adicionales de hardware o software?

Google Cloud proporciona las siguientes opciones para diseñar la arquitectura de un entorno de GKE de varios clústeres. Para elegir la mejor opción para tus cargas de trabajo, primero debes evaluarlas según los criterios previos de evaluación que estableciste. Usa una escala ordenada arbitraria para asignar a cada opción de diseño una puntuación según cada criterio de evaluación. Por ejemplo, puedes asignar a cada entorno una puntuación de una escala de 1 a 10 según cada criterio de evaluación. Las siguientes opciones se presentan en orden creciente según el esfuerzo necesario para administrar el entorno nuevo de GKE de varios clústeres.

  1. Ingress de varios clústeres y el descubrimiento de servicios de varios clústeres
  2. Ingress de varios clústeres y Cloud Service Mesh
  3. Cloud Service Mesh
  4. Kubernetes y actualizaciones del registro DNS autoadministradas

En las siguientes secciones, se describen estas opciones en detalle y se incluye una lista de criterios para evaluar cada opción. Para asignar puntuaciones basadas en algunos de los criterios, lee la documentación del producto. Por ejemplo, cuando lees la documentación, puedes evaluar Cloud Service Mesh con algunos de los criterios que estableciste antes. Sin embargo, para asignar puntuaciones basadas en otros criterios, es posible que debas diseñar y ejecutar comparativas y simulaciones más detalladas. Por ejemplo, podrías tener que realizar una comparativa sobre el rendimiento de diferentes arquitecturas de GKE de varios clústeres para evaluar si se ajustan a tus cargas de trabajo.

Ingress de varios clústeres y el descubrimiento de servicios de varios clústeres

Ingress de varios clústeres es un servicio administrado por Google que te permite exponer las cargas de trabajo sin importar en qué clúster de GKE se implementen. También te permite configurar balanceadores de cargas compartidos en clústeres de GKE y entre regiones. Para obtener más información sobre cómo usar Ingress de varios clústeres en un entorno de GKE de varios clústeres, consulta Actualizaciones de GKE de varios clústeres con Ingress de varios clústeres y Respalda la migración con la expansión de malla de Istio.

El descubrimiento de servicios de varios clústeres es un mecanismo de conectividad y descubrimiento de servicios entre clústeres nativos de Kubernetes para GKE. El descubrimiento de servicios de varios clústeres se basa en el recurso Service de Kubernetes para ayudar a que las apps se descubran y se conecten entre sí a través de los límites del clúster. Para evaluar Ingress de varios clústeres y el descubrimiento de servicios de varios clústeres con los criterios que estableciste con anterioridad, usa la siguiente lista, numerada en orden de importancia relativa:

  1. Solución administrada por Google. El descubrimiento de servicios de varios clústeres es una función completamente administrada de GKE. Configura recursos (zonas y registros de Cloud DNS, reglas de firewall y Cloud Service Mesh) para que no tengas que administrarlos.
  2. Interfaces para interactuar con la arquitectura. Los Services se exportan a otros clústeres a través de un recurso declarativo de Kubernetes llamado ServiceExport.
  3. Expón los servicios fuera del entorno de GKE. Cuando usas Ingress de varios clústeres y descubrimiento de servicios de varios clústeres, puedes exponer tus cargas de trabajo fuera de tus clústeres de GKE, sin importar dónde se hayan implementado.
  4. Comunicación entre clústeres. Puedes exportar los servicios existentes a otros clústeres de GKE si declaras un objeto ServiceExport. Los clústeres de GKE en la misma flota importan automáticamente servicios que exportas usando objetos ServiceExport. El descubrimiento de servicios de varios clústeres configura una dirección IP virtual para cada servicio exportado. El descubrimiento de servicios de varios clústeres configura de forma automática los recursos de Traffic Director, Cloud DNS y las reglas de firewall para descubrir y conectarse a los servicios con una variación simple de la convención de DNS de Kubernetes. Por ejemplo, para acceder al servicio my-svc, puedes usar el nombre my-svc.my-ns.svc.clusterset.local.
  5. Administración del tráfico. El descubrimiento de servicios de varios clústeres configura la conectividad simple de capa 3/4 y se basa en el DNS para el descubrimiento de servicios. No proporciona ninguna función de administración de tráfico.
  6. Aprovisiona y configura herramientas adicionales. Puedes configurar el descubrimiento de servicios de varios clústeres si habilitas las APIs de Google. No requiere la instalación de ninguna herramienta adicional. Para obtener más información, consulta Migra contenedores a Google Cloud: Migra a un entorno de GKE de varios clústeres con el descubrimiento de servicios de varios clústeres y la entrada de varios clústeres

Ingress de varios clústeres y Cloud Service Mesh

Una malla de servicios es un patrón de arquitectura que ayuda con los desafíos de red de las apps distribuidas. Estos desafíos incluyen el descubrimiento de servicios, el balanceo de cargas, la tolerancia a errores, el control de tráfico, la observabilidad, la autenticación, la autorización y la encriptación en tránsito. Las implementaciones de malla de servicios típicas constan de un plano de datos y un plano de control. El plano de datos es responsable de administrar el tráfico directamente y reenviarlo a las cargas de trabajo de destino, por lo general, a través de proxies de archivo adicional. El plano de control hace referencia a los componentes que configuran el plano de datos.

Cuando implementas el patrón de malla de servicios en la infraestructura, puedes elegir entre dos productos de Google Cloud: Cloud Service Mesh y Cloud Service Mesh. Ambos productos proporcionan un plano de control para configurar las herramientas de redes de la capa de la aplicación (L7) en varios clústeres de GKE. Cloud Service Mesh se basa en Istio y ofrece API de código abierto declarativas. Cloud Service Mesh se basa en una combinación de funciones de balanceo de cargas de Google, tecnologías de código abierto y ofrece APIs de Google imperativas.

Cloud Service Mesh es un conjunto de herramientas administradas por Google que te permite conectar, administrar, proteger y supervisar tus cargas de trabajo sin importar en qué clúster de GKE se implementen y sin modificar el código de tu app. Si deseas obtener más información para usar Cloud Service Mesh para configurar una malla que abarque varios clústeres de GKE, consulta Agrega clústeres de GKE a Cloud Service Mesh. Para evaluar el Ingress de varios clústeres y Cloud Service Mesh en función de los criterios que estableciste antes, usa la siguiente lista, numerada por importancia relativa:

  1. Solución administrada por Google. Ingress de varios clústeres y Anthos Service Mesh son productos completamente administrados. No es necesario que aprovisiones esos productos, ya que Google los administra por ti.
  2. Interfaces para interactuar con la arquitectura. Cloud Service Mesh usa Istio como base. La API de Cloud Service Mesh admite la configuración declarativa en función del modelo de recursos de Kubernetes.
  3. Expón los servicios fuera del entorno de GKE. Las puertas de enlace de Ingress de Ingress de varios clústeres y Cloud Service Mesh te permiten exponer tus cargas de trabajo fuera de tus clústeres de GKE.
  4. Comunicación entre clústeres. Cloud Service Mesh configura los canales de comunicación seguros directamente entre los Pods, sin importar el clúster en el que se ejecuten. Esta configuración te permite evitar el esfuerzo adicional de aprovisionar y configurar estos canales de comunicación. Cloud Service Mesh usa el concepto de flotas y similitud de servicio para extender el descubrimiento de los servicios de GKE a varios clústeres. Por lo tanto, no necesitas modificar tus cargas de trabajo a fin de descubrir cargas de trabajo que se ejecuten en otros clústeres de la malla.
  5. Administración del tráfico. Cloud Service Mesh proporciona funciones avanzadas de administración del tráfico que puedes usar para controlar cómo se protege y enruta el tráfico entrante a las cargas de trabajo. Por ejemplo, Cloud Service Mesh admite todas las funciones de administración de tráfico de Istio, como: inyección de fallas, tiempos de espera y reintentos de la solicitud, disyuntores, duplicación de tráfico, y desplazamiento del tráfico. También puedes usar estas funciones de administración de tráfico para simplificar tu migración a un nuevo entorno de GKE. Por ejemplo, puedes cambiar el tráfico de forma gradual del entorno anterior al nuevo.
  6. Aprovisiona y configura herramientas adicionales. Para usar Ingress de varios clústeres, debes cumplir con los requisitos previos del descubrimiento de servicios de clústeres múltiples, pero no necesitas instalar herramientas adicionales en tus clústeres de GKE. Para usar Cloud Service Mesh, debes instalarlo en tus clústeres.

Cloud Service Mesh

Cloud Service Mesh es un plano de control administrado para redes de aplicaciones. Te permite aprovisionar y configurar topologías de malla de servicios enriquecidas con funciones avanzadas de observabilidad y administración del tráfico. Para obtener más información sobre Cloud Service Mesh, consulta la Descripción general de Cloud Service Mesh y las funciones de Cloud Service Mesh. Para aprovisionar y configurar una malla de servicios que abarque varios clústeres de GKE, puedes usar una configuración de Cloud Service Mesh de varios clústeres o de varios entornos. Para evaluar Cloud Service Mesh en función de los criterios que estableciste antes, usa la siguiente lista, numerada en orden de importancia relativa:

  1. Solución administrada por Google. Cloud Service Mesh es un producto completamente administrado. No es necesario que aprovisiones esos productos, ya que Google los administra por ti.
  2. Interfaces para interactuar con la arquitectura. Puedes configurar Cloud Service Mesh usando la consola de Google Cloud, Google Cloud CLI, la API de Traffic Director o herramientas como Terraform. Cloud Service Mesh admite un modelo de configuración imperativo y es compilado en productos y tecnologías de código abierto, como xDS y gRPC.
  3. Expón los servicios fuera del entorno de GKE. Puedes usar Cloud Load Balancing para enviar tráfico entrante desde fuera a los servicios de la red de servicio.
  4. Comunicación entre clústeres. El plano de control de Cloud Service Mesh ofrece APIs que te permiten agrupar extremos (como Pods de GKE en varios clústeres) en backends de servicio. Estos backends se pueden enrutar desde otros clientes en la malla. Cloud Service Mesh no se integra directamente al descubrimiento de servicios de GKE, pero puedes automatizar la integración con un controlador de código abierto, como gke-autoneg-controller. De manera opcional, puedes usar el Descubrimiento de servicios de varios clústeres para extender el descubrimiento de servicios de GKE a varios clústeres.
  5. Administración del tráfico. Cloud Service Mesh proporciona funciones avanzadas de administración del tráfico que puedes usar para simplificar tu migración a un entorno de GKE nuevo y mejorar la confiabilidad de tu arquitectura. Para obtener información sobre la configuración de atributos como:enrutamiento de tráfico detallado ,división del tráfico según el peso, duplicación de tráfico yBalanceo de cargas más preciso, consulta Configurar la administración avanzada del tráfico.
  6. Aprovisiona y configura herramientas adicionales. Cloud Service Mesh no se ejecuta en tus clústeres de GKE. Si deseas obtener información sobre cómo aprovisionar y configurar Cloud Service Mesh, consulta Prepárate para la configuración de Cloud Service Mesh. Si deseas configurar los Pods del archivo adicional que Cloud Service Mesh necesita para incluir tus cargas de trabajo en la red de servicio, consulta Implementa Cloud Service Mesh con Envoy en Pods de GKE.

Kubernetes y actualizaciones del registro DNS autoadministradas

Si no deseas instalar software adicional en tu clúster y no necesitas las funciones que proporciona una malla de servicios, puedes elegir la opción Kubernetes y actualizaciones del registro DNS autoadministradas.

Aunque puedes configurar el descubrimiento y la conectividad entre clústeres con esta opción, te recomendamos que elijas una de las otras opciones descritas en este documento. El esfuerzo necesario para operar una solución autoadministrada supera considerablemente los beneficios que podrías obtener. También ten en cuenta las siguientes limitaciones importantes:

Cuando creas un objeto Service de type: LoadBalancer o Ingress en un clúster de GKE, GKE crea de forma automática balanceadores de cargas de red y balanceadores de cargas HTTP(S) para exponer ese Service usando la dirección IP del balanceador de cargas. Puedes usar las direcciones IP de los balanceadores de cargas para comunicarte con tus Services. Sin embargo, no recomendamos que dependas de las direcciones IP mediante la asignación de esas direcciones IP a registros DNS con Cloud DNS o a extremos del Directorio de servicios que puedas consultar con DNS, y que configures los clientes para que usen esos registros DNS. Puedes implementar varias instancias de Service y mapear todas las direcciones IP del balanceador de cargas resultantes al registro DNS relacionado o al extremo del Directorio de servicios.

Para retirar una instancia de un Service, primero quita la dirección IP del balanceador de cargas relacionado del registro DNS relevante o del extremo del Directorio de servicios. Luego, asegúrate de que la caché de DNS de los clientes se actualice y, luego, retira el Service.

Puedes configurar las cargas de trabajo para que puedan comunicarse entre sí en diferentes clústeres de GKE. Para ello, primero debes exponer tus servicios fuera del clúster mediante Balanceadores de cargas de TCP/UDP internos o Balanceadores de cargas de HTTP(S) internos. Luego, asigna las direcciones IP de los balanceadores de cargas a los registros DNS o extremos del Directorio de servicios. Por último, debes crear objetos Service de type: ExternalName que apunten a esos registros DNS o extremos del Directorio de servicios en cada clúster.

De forma opcional, puedes usar un controlador de Ingress adicional para compartir un solo balanceador de cargas y un registro de Cloud DNS o extremo de Directorio de Services con varias cargas de trabajo. Por ejemplo, si aprovisionas un controlador de Ingress en un clúster, puedes configurarlo para que redireccione las solicitudes que llegan al balanceador de cargas que GKE crea para ese controlador de Ingress a varios Services. El uso de un controlador de Ingress adicional te permite reducir la cantidad de registros DNS o extremos de Directorio de Services que debes administrar.

Para evaluar las actualizaciones del registro DNS autoadministradas y de Kubernetes con los criterios que estableciste antes, usa la siguiente lista, ordenada por importancia relativa:

  1. Solución administrada por Google. Tú administras los objetos de Kubernetes que forman parte de esta solución. Cloud DNS, el Directorio de servicios y el balanceo de cargas son servicios administrados por Google.
  2. Interfaces para interactuar con la arquitectura. GKE usa Kubernetes en esencia y admite modelos de configuración imperativos y declarativos.
  3. Expón los servicios fuera del entorno de GKE. Puedes usar registros DNS, extremos del Directorio de servicios y balanceadores de cargas para exponer servicios a clientes fuera de los clústeres de GKE.
  4. Comunicación entre clústeres. Los servicios de type: ExternalName te permiten definir extremos que apuntan a los servicios implementados en el otro clúster de GKE. Esta configuración permite que los servicios se comuniquen entre sí como si se implementaran en el mismo clúster.
  5. Administración del tráfico. La solución no ofrece capacidades de administración de tráfico adicionales, excepto las que ya ofrecen Kubernetes y GKE. Por ejemplo, esta opción no admite la partición del tráfico entre clústeres diferentes.
  6. Aprovisiona y configura herramientas adicionales. Esta opción no requiere que se aprovisione y se configure software adicional en tus clústeres de GKE. De manera opcional, puedes instalar un controlador Ingress.

Selecciona una arquitectura

Después de asignar un valor a cada criterio para cada opción, calcularás la puntuación total de cada opción. Para calcular la puntuación total de cada opción, agrega todas las calificaciones de esa opción de diseño basadas en los criterios. Por ejemplo, si un entorno obtuvo 10 puntos en un criterio y 6 en otro, la puntuación total de esa opción será 16.

También puedes asignar pesos diferentes a la puntuación de cada criterio a fin de representar la importancia que cada uno de ellos tiene en tu evaluación. Por ejemplo, si una solución administrada por Google es más importante que la compatibilidad con una arquitectura de carga de trabajo distribuida en tu evaluación, podrías definir multiplicadores para reflejar eso: un multiplicador 1.0 para la solución administrada por Google y un multiplicador de 0.7 para la arquitectura de carga de trabajo distribuida. Luego, usa estos multiplicadores para calcular la puntuación total de una opción.

Después de calcular la puntuación total de cada entorno que evaluaste, organiza los entornos por su puntuación total, en orden descendente. Luego, elige la opción con la puntuación más alta como tu entorno.

Existen varias formas de representar estos datos, por ejemplo, puedes visualizar los resultados con un gráfico adecuado para representar los datos de variables múltiples, como un gráfico radial.

Migra datos de tu entorno anterior a tu entorno nuevo

Para obtener información sobre cómo migrar datos de tu entorno anterior a tu entorno nuevo, consulta Migra Kubernetes a GKE, Migra datos de tu entorno anterior a tu entorno nuevo.

Implementa tus cargas de trabajo

Para obtener orientación sobre cómo migrar datos de tu entorno anterior a tu entorno nuevo, consulta Implementa tus cargas de trabajo.

Todas las arquitecturas propuestas en este documento te permiten migrar tus cargas de trabajo de un entorno de GKE existente a un entorno de varios clústeres nuevo sin tiempo de inactividad ni período de migración. Para migrar tus cargas de trabajo sin ningún tiempo de inactividad, haz lo siguiente:

  1. Integra de forma temporal tus clústeres de GKE heredados existentes en el entorno de GKE de varios clústeres nuevo.
  2. Implementa instancias de tus cargas de trabajo en tu entorno de varios clústeres nuevo.
  3. Migra el tráfico desde tu entorno existente de forma gradual para que puedas migrar gradualmente tus cargas de trabajo a los nuevos clústeres de GKE y, luego, retirar los clústeres de GKE heredados.

Complete la implementación

Después de aprovisionar y configurar la plataforma y los entornos de ejecución, completa las actividades descritas en Migra Kubernetes a GKE, Implementa tus cargas de trabajo.

Optimiza tu entorno

La optimización es la última fase de la migración. En esta fase, harás que tu entorno sea más eficiente que antes. Para optimizar tu entorno, completa varias iteraciones del siguiente bucle repetible hasta que el entorno cumpla con tus requisitos de optimización:

  1. Evalúa tu entorno actual, los equipos y el ciclo de optimización.
  2. Establece tus requisitos y objetivos de optimización.
  3. Optimiza tu entorno y tus equipos.
  4. Ajusta el ciclo de optimización.

Para realizar la optimización de tu entorno de GKE, consulta Migra Kubernetes a GKE, Optimiza tu entorno.

¿Qué sigue?