Migra contenedores a Google Cloud: migra de OpenShift a GKE Enterprise

Con este documento, podrás planificar, diseñar e implementar la migración desde OpenShift hacia GKE Enterprise. Si se hace de forma incorrecta, mover las cargas de trabajo de un entorno a otro puede ser una tarea desafiante, por lo que debes planificar y ejecutar la migración con cuidado.

Este documento es parte de una serie de varias partes sobre la migración a Google Cloud. Si te interesa ver una descripción general de la serie, consulta Migración a Google Cloud: elige tu 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 desde OpenShift, que se ejecuta en un entorno local o de hosting privado o en otro proveedor de servicios en la nube, hacia GKE Enterprise. Este documento también es útil si estás evaluando la posibilidad de migrar y deseas explorar cómo podría ser. El entorno de destino puede ser uno de los siguientes:

  • Un entorno alojado por completo en Google Cloud
  • Un entorno híbrido en el que mantienes parte de la carga de trabajo de forma local o en un entorno de hosting privado y migras el resto a Google Cloud

Para decidir qué entorno se adapta a tus necesidades, ten en cuenta los requisitos. Por ejemplo, puedes enfocarte en aumentar el valor de tu empresa en lugar de preocuparte por la infraestructura mediante la migración a un entorno de nube pública y la subcontratación de algunas responsabilidades a Google. Obtienes beneficios de un modelo de consumo elástico para optimizar los gastos y el uso de recursos. Si tienes requisitos, como mantener algunas de las cargas de trabajo fuera de Google Cloud, puedes considerar un entorno híbrido, por ejemplo, si debes mantener parte de las cargas de trabajo en el entorno actual para cumplir políticas y normativas de ubicación de datos. O bien, puedes implementar una estrategia de migración de mejora y traslado, en la que primero modernizas las cargas de trabajo y, luego, migras a Google Cloud.

Sin importar el tipo de entorno de destino, el objetivo de esta migración es administrar las cargas de trabajo que se ejecutan en ese entorno mediante GKE Enterprise. Si adoptas GKE Enterprise, tienes acceso a una variedad de servicios, incluidos los siguientes:

  • Administración de varios clústeres para ayudarte a ti y a tu organización a administrar clústeres, infraestructura y cargas de trabajo en entornos locales y en la nube desde un solo lugar.
  • Sincronizador de configuración y Controlador de políticas para crear una configuración y políticas comunes en toda la infraestructura y aplicarlas de forma local y en la nube.
  • Anthos Service Mesh para adoptar una malla de servicios completamente administrada que simplifica los servicios operativos, la administración del tráfico, la telemetría y la seguridad de las comunicaciones entre servicios.
  • Autorización binaria para garantizar que los contenedores que implementas en tus entornos sean de confianza.
  • Cloud Run for Anthos para admitir las cargas de trabajo sin servidores en el entorno de GKE Enterprise.

Se recomienda evaluar estos servicios al comienzo del proceso de migración mientras se diseña la migración. Ahora es más fácil adoptar estos servicios, en lugar de modificar los procesos y la infraestructura más adelante. Puedes comenzar a usar estos servicios de inmediato o cuando estés listo para modernizar las cargas de trabajo.

En esta migración, sigues el framework de migración que se define en Migración a Google Cloud: Comienza ahora. El framework tiene cuatro fases:

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

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

Ruta de migración con cuatro fases

Este documento se basa en los conceptos que se describen en Migra contenedores a Google Cloud: Migra Kubernetes a GKE, por lo que hay vínculos a ese documento, cuando corresponde.

Evalúa y descubre las cargas de trabajo

En la fase de evaluación, determinarás los requisitos y las dependencias para migrar las cargas de trabajo de OpenShift a GKE Enterprise:

  1. Crea un inventario integral de los procesos y las aplicaciones.
  2. Clasifica los procesos y las apps según sus propiedades y dependencias.
  3. Capacita y educa a tus equipos en Google Cloud.
  4. Crea experimentos y pruebas 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 Migración a Google Cloud: Evalúa y descubre tus cargas de trabajo, pero proporcionan información específica para evaluar las cargas de trabajo que deseas migrar de OpenShift a GKE Enterprise.

Compila tus inventarios

Para compilar el inventario de los componentes del entorno, considera lo siguiente:

  • Modelo de administración de plataformas y entrega de servicios
  • Proyectos de OpenShift
  • Proceso de implementación y compilación
  • Cargas de trabajo, requisitos y dependencias
  • Configuración de clústeres de OpenShift

Modelo de administración de plataformas y entrega de servicios

Para migrar las cargas de trabajo de OpenShift a GKE Enterprise, evalúa el modelo de administración de plataformas y entrega de servicios actual del entorno de OpenShift. Es probable que este modelo refleje la estructura y las necesidades organizativas actuales. Si te das cuenta de que el modelo actual no satisface las necesidades de la organización, puedes usar esta migración como una oportunidad para mejorar el modelo.

En primer lugar, recopila información sobre los equipos responsables de los siguientes aspectos:

  • Desarrollo e implementación de aplicaciones, incluidos todos los usuarios de OpenShift, por lo general, equipos de desarrollo o de cargas de trabajo
  • Administración de la plataforma de OpenShift, incluida la creación de proyectos de OpenShift, la asignación de funciones a usuarios, la configuración de contextos de seguridad y de la canalización de CI/CD
  • Instalación de OpenShift y administración de clústeres, incluidos el escalamiento de clústeres, la administración de capacidad, la actualización y la instalación de OpenShift
  • Administración de la infraestructura: estos equipos administran los servidores físicos, el almacenamiento, las redes, la plataforma de virtualización y los sistemas operativos

Un modelo de administración de plataformas y entrega de servicios puede estar compuesto por los siguientes equipos:

  • El equipo de desarrollo: este equipo desarrolla cargas de trabajo y las implementa en OpenShift. Cuando se trata de entornos de producción complejos, el equipo que implementa las cargas de trabajo puede ser uno diferente al equipo de desarrollo. Para simplificar este documento, consideramos que este equipo forma parte del equipo de desarrollo. En entornos de autoservicio, el equipo de desarrollo también es responsable de la creación de proyectos de OpenShift.
  • El equipo de la plataforma: este equipo es responsable de la administración de la plataforma de OpenShift. Se los conoce como administradores de clústeres de OpenShift. Este equipo configura plantillas de proyecto de OpenShift para diferentes equipos de desarrollo y, en entornos con una mayor administración, crea proyectos de OpenShift. Este equipo también asigna funciones y permisos, configura contextos de seguridad y control de acceso basado en funciones (RBAC), define cuotas para recursos de procesamiento y objetos y define estrategias de compilación y de implementación. A veces se los conoce como el equipo de DevOps o como el equipo de middleware si administran configuraciones de servidor de aplicaciones y de middleware para desarrolladores. El equipo de la plataforma y el equipo de infraestructura también pueden participar en actividades de administración de clústeres de OpenShift de bajo nivel, como instalación y actualización de software, escalamiento de clústeres y administración de capacidad.
  • El equipo de infraestructura: este equipo administra la infraestructura subyacente que admite el entorno de OpenShift. Por ejemplo, están a cargo de los servidores, el almacenamiento, las redes, la plataforma de virtualización y el sistema operativo base. A veces, se hace referencia a este equipo como el equipo del centro de datos o el equipo de operaciones. Si OpenShift se implementa en un entorno de nube pública, este equipo es responsable de los servicios de infraestructura como servicio (IaaS) que ofrece un proveedor de servicios en la nube pública.

También es importante evaluar si tienes clústeres dedicados de OpenShift para diferentes entornos. Por ejemplo, es posible que tengas diferentes entornos para el desarrollo, el control de calidad y la producción o para la separación diferentes zonas de red y seguridad, como zonas internas y zonas desmilitarizadas.

Proyectos de OpenShift

Un proyecto de OpenShift es un espacio de nombres de Kubernetes con anotaciones adicionales que permite a los desarrolladores administrar recursos separados de otros equipos para separarlos de forma lógica. Si quieres compilar el inventario de los proyectos de OpenShift, considera lo siguiente para cada proyecto:

  • Funciones de clúster y funciones locales: OpenShift admite funciones locales para un proyecto de OpenShift o funciones de todo el clúster. Evalúa si creaste alguna función local y de clúster para diseñar un mecanismo de control de acceso eficaz en el entorno de destino.
  • Vinculaciones de funciones para funciones del clúster y funciones locales: a los usuarios y grupos se les otorgan permisos para realizar operaciones en proyectos de OpenShift mediante la asignación de vinculaciones de funciones. Las funciones pueden ser a nivel de clúster o a nivel local. A menudo, las vinculaciones de funciones locales están vinculadas a funciones de clúster predefinidas. Por ejemplo, la vinculación de la función de administrador del proyecto predeterminada de OpenShift podría estar vinculada a la función de administrador de clúster predeterminada.
  • ResourceQuotas: para limitar el consumo total de recursos, OpenShift te permite definir cuotas a nivel de proyecto de OpenShift y cuotas en varios proyectos de OpenShift. Evalúa cómo se asignan a ResourceQuotas de Kubernetes y propaga una lista de todos los ResourceQuotas que aprovisionaste y configuraste en el entorno de OpenShift.

En Evalúa el entorno, se describe cómo evaluar los recursos de Kubernetes, como ServiceAccounts y PersistentVolumes.

Procesos de compilación y de implementación

Después de recopilar información sobre el modelo de administración de plataformas y entrega de servicios y sobre los proyectos de OpenShift, evalúa cómo compilas e implementas las cargas de trabajo en el entorno.

En el entorno de OpenShift existente, es posible que tengas el mismo proceso de compilación y de implementación para todas las cargas de trabajo, o que se evalúen diferentes procesos. Las imágenes de contenedor son los artefactos del proceso de compilación para una carga de trabajo en contenedor. En un entorno de OpenShift, puedes compilar imágenes de contenedor, almacenarlas e implementarlas de diferentes maneras:

Después de compilar cada imagen de contenedor, la almacenas en un registro de contenedores que puedes implementar más tarde. El registro de contenedores se puede alojar en OpenShift o fuera del entorno de OpenShift. Evalúa este aspecto porque es posible que necesites un sistema similar en el entorno de destino.

Cargas de trabajo, requisitos y dependencias

Cada aplicación OpenShift tiene los siguientes componentes:

Según el propósito de la aplicación, puedes usar objetos diferentes para definir la app en lugar de usar los objetos Deployment o DeploymentConfig:

  • Define las aplicaciones por lotes mediante un trabajo o un trabajo cron.
  • Define las aplicaciones con estado mediante StatefulSets.
  • Si tienes cargas de trabajo relacionadas con las operaciones que deben ejecutarse en cada nodo o estar vinculadas a nodos específicos, puedes definirlas con DaemonSets.

En la siguiente tabla, se enumeran los objetos spec y los parámetros más importantes que recopilas de los recursos de OpenShift para migrar las aplicaciones al entorno de GKE Enterprise de destino.

Manifiesto de recursos de OpenShift de origen Parámetros y especificaciones más importantes
Deployment, DeploymentConfig, StatefulSet, trabajo, trabajo cron Imagen y repositorio del contenedor, puerto del contenedor, cantidad de réplicas de pod, ConfigMaps, secretos, PersistentVolumeClaims, solicitudes y límites de recursos, estrategia de actualización, nombre del servicio de StatefulSet, programación de trabajo cron
ImageStream Imagen de contenedor, política de extracción de imágenes, repositorio de imágenes de contenedor
Escalador automático de pod horizontal Criterios de ajuste de escala automático
Service Nombre de host que se usa para conectarse a la aplicación desde el clúster, dirección IP y puerto en el que se expone el objeto Service, extremos que se crearon para recursos externos
Route Nombre de host y ruta del recurso que se usan para conectarse a la aplicación desde fuera del clúster, reglas de enrutamiento, encriptación, información de la cadena de certificados

En Evalúa el entorno, se describe cómo evaluar los recursos de Kubernetes como los siguientes:

OpenShift 4 introdujo Operator Framework. Si usas esta versión de OpenShift, es posible que hayas implementado algunas aplicaciones mediante Operators instalados. En este caso, obtienes la lista de los Operators instalados y recopilas información para cada uno de ellos sobre las instancias de Operator implementadas. Estas instancias son recursos personalizados definidos por el Operator que implementan algunos de los recursos de Kubernetes enumerados con anterioridad.

Además de evaluar estos recursos, evalúa lo siguiente:

  • Requisitos de conectividad de red de la aplicación. Por ejemplo, ¿sus servicios o pods deben estar expuestos a una red específica? ¿Necesitan llegar a sistemas de backend específicos?
  • Restricciones para ejecutar cargas de trabajo en una ubicación específica. Por ejemplo, ¿las cargas de trabajo o los conjuntos de datos deben permanecer en un entorno local para cumplir con requisitos como la latencia en la comunicación con otras cargas de trabajo, con políticas relacionadas con la ubicación de los datos y con la proximidad a los usuarios?

Configuración de clústeres de OpenShift

A continuación, evalúa los clústeres de OpenShift. Para completar esta tarea, debes recopilar la siguiente información:

  • Versión de OpenShift. Las versiones principales de OpenShift que se incluyen en este documento son OpenShift 3 y OpenShift 4. Las diferentes versiones de OpenShift pueden tener capacidades diferentes. Evalúa qué versión de OpenShift ejecutas para saber si usas alguna función específica de una versión de OpenShift.
  • Proveedor de identidad para la autenticación: para la autenticación, es posible que estés usando el servidor OAuth integrado y uno o más proveedores de identidad.
  • Restricciones del contexto de seguridad: evalúa las restricciones del contexto de seguridad de OpenShift que definiste en los clústeres, su configuración y a qué usuarios, grupos y cuentas de servicio están asignadas.
  • Aislamiento y política de red: evalúa NetworkPolicies, cómo configuraste el aislamiento de red de pods y qué modo SDN de OpenShift configuraste en los clústeres.
  • Supervisión: evalúa los requisitos de supervisión actuales y cómo aprovisionaste y configuraste el sistema de supervisión actual para decidir cómo diseñar e implementar una solución de supervisión en el entorno de destino. Esta evaluación puede ayudarte a determinar si debes usar una solución de supervisión nueva o si puedes seguir usando la solución existente. Muchas versiones de OpenShift incluyen una pila de supervisión basada en Prometheus para supervisar los componentes del sistema, que también se puede usar a fin de supervisar las aplicaciones. Cuando diseñes la solución de destino, ten en cuenta lo siguiente:

    • La solución de supervisión que usas en este momento en el entorno de OpenShift, por ejemplo, Prometheus alojado en OpenShift, una pila Prometheus y Grafana independiente, Zabbix, InflueData o Nagios
    • La forma en que se producen y recopilan las métricas, por ejemplo, un mecanismo de extracción o envío
    • Las dependencias en cualquier componente implementado en los clústeres de OpenShift
    • La ubicación del sistema de supervisión, por ejemplo, si se implementó en un entorno de nube o local
    • Las métricas que recopilas en este momento para las cargas de trabajo
    • Cualquier alerta sobre las métricas que configuraste en el sistema de supervisión actual
  • Registros: evalúa los requisitos de registro actuales y la forma en la que aprovisionaste y configuraste el sistema de registro actual para decidir cómo diseñar e implementar una solución de registro en el entorno de destino. Esta evaluación puede ayudarte a determinar si debes usar una solución de registro nueva o si puedes seguir usando la solución existente. Muchas versiones de OpenShift se envían con una solución de registro basada en una pila Elasticsearch, Fluentd y Kibana (EFK) que se usa para recopilar registros de los componentes del sistema. Esta solución también se puede usar para el registro de aplicaciones. Cuando diseñes la solución de destino, ten en cuenta lo siguiente:

    • El sistema de registro que usas en este momento en el entorno de OpenShift, por ejemplo, una pila EFK alojada en OpenShift, una pila EFK independiente o Splunk
    • Las dependencias en cualquier componente implementado en los clústeres de OpenShift
    • La arquitectura y la capacidad de los componentes de almacenamiento de registros
    • La ubicación del sistema de registro, por ejemplo, si se implementó en un entorno de nube o local
    • Las políticas y la configuración de retención de registros

En Evalúa el entorno, se describe cómo evaluar los siguientes elementos:

  • Cantidad de clústeres
  • Cantidad y tipo de nodos por clúster
  • Consideraciones adicionales sobre el registro, la supervisión y el seguimiento
  • Recursos personalizados de Kubernetes

Completa la evaluación

Después de compilar los inventarios relacionados con los procesos y cargas de trabajo de OpenShift, completa el resto de las actividades de la fase de evaluación en Migración a Google Cloud: Evalúa y descubre tus cargas de trabajo.

Planifica y compila tu base

En la fase de planificación y compilación, aprovisionas y configuras la infraestructura y los servicios que admiten las cargas de trabajo:

  1. Compila una jerarquía de recursos.
  2. Configura la administración de identidades y accesos.
  3. Configura la facturación.
  4. Configura la conectividad de red.
  5. Endurece tu seguridad.
  6. Configura la supervisión y las alertas.

En esta sección, se proporciona información específica para compilar la base en GKE Enterprise en función de la información de Migración a Google Cloud: Compila tu base.

Antes de compilar una base en Google Cloud, lee la descripción técnica de GKE Enterprise para comprender cómo funciona GKE Enterprise y qué componentes de GKE Enterprise necesitas. Según los requisitos de la carga de trabajo y la localidad de los datos que recopilaste en la fase de evaluación, debes implementar tus cargas de trabajo en GKE en WMware en clústeres de GKE Enterprise en Google Cloud o en GKE en AWS. Los clústeres pueden estar distribuidos entre diferentes entornos. Si quieres obtener más información sobre cómo compilar una base para GKE en Google Cloud, consulta Planifica y compila tu base.

Para compilar una base para GKE en WMware, lee sobre los conceptos principales y, luego, considera lo siguiente cuando instales GKE en WMware:

A fin de compilar una base para GKE on AWS, lee sobre sus conceptos principales, como la arquitectura y el almacenamiento. Ten en cuenta lo siguiente cuando instales GKE on AWS:

Implementa tus cargas de trabajo

En la fase de implementación, sigue estos pasos para implementar las cargas de trabajo en GKE Enterprise:

  1. Aprovisionar y configurar tu plataforma y entornos de ejecución
  2. Migrar datos de tu entorno anterior a tu entorno nuevo
  3. Implementar tus cargas de trabajo

En las siguientes secciones, se proporciona información específica sobre la implementación de cargas de trabajo en GKE Enterprise, en función de la información de Migración a Google Cloud: Transfiere grandes conjuntos de datos, Migración a Google Cloud: Implementa cargas de trabajo y Migración a Google Cloud: Migra de implementaciones manuales a implementaciones automatizadas en contenedores.

Aprovisiona y configura la plataforma y entornos de ejecución

Antes de que puedas implementar cualquier carga de trabajo, debes aprovisionar y configurar los clústeres de GKE Enterprise necesarios.

Puedes aprovisionar clústeres de GKE en Google Cloud, clústeres de GKE en WMware o clústeres de GKE en AWS. Por ejemplo, si tienes una carga de trabajo que debes implementar de forma local, aprovisiona uno o más clústeres de GKE en WMware. Si las cargas de trabajo no tienen ningún requisito de localidad, aprovisiona clústeres de GKE en Google Cloud. En ambos casos, administras y supervisas los clústeres mediante GKE Enterprise. Si tienes requisitos de múltiples nubes, debes aprovisionar clústeres de GKE en AWS, junto con otros clústeres de GKE Enterprise.

Primero, define la cantidad y el tipo de clústeres de GKE Enterprise que necesitas. Estos requisitos dependen en gran medida de la información que recopilaste en la fase de evaluación, como el modelo de servicio que deseas implementar y la forma en la que deseas aislar los diferentes entornos. Si varios equipos de desarrollo comparten tus clústeres de OpenShift, debes implementar un modelo de multiusuario en GKE Enterprise:

  • Usa diferentes espacios de nombres de Kubernetes. El equipo de la plataforma crea un espacio de nombres de Kubernetes para cada proyecto de OpenShift y, luego, implementa un modelo de multiusuario de clústeres. Este modelo se parece mucho al que tal vez adoptaste en el entorno de OpenShift, por lo que podría requerir una cantidad de clústeres de GKE Enterprise similar a la de los clústeres de OpenShift. Si es necesario, aún puedes tener clústeres dedicados para diferentes entornos.
  • Usa diferentes clústeres de GKE Enterprise. El equipo de infraestructura proporciona un clúster de GKE Enterprise para cada equipo de desarrollo, y el equipo de la plataforma administra cada uno de estos clústeres. Este modelo puede requerir una cantidad mayor de clústeres de GKE Enterprise que la cantidad de clústeres de OpenShift, ya que proporciona mayor flexibilidad y aislamiento para el desarrollo.
  • Usa diferentes proyectos de Google Cloud. El equipo de infraestructura crea un proyecto de Google Cloud para cada equipo de desarrollo y aprovisiona los clústeres de GKE Enterprise dentro de ese proyecto. Luego, el equipo de la plataforma administra estos clústeres. Este modelo puede requerir más clústeres de GKE Enterprise que de clústeres de OpenShift, ya que proporciona la máxima flexibilidad y aislamiento para los equipos de desarrollo.

Después de decidir la cantidad de clústeres que necesitas y en qué entorno aprovisionarlos, defines el tamaño, la configuración y los tipos de nodos del clúster. Luego, aprovisiona los clústeres y grupos de nodos, según los requisitos de carga de trabajo que recopilaste durante la fase de evaluación. Por ejemplo, las cargas de trabajo pueden requerir ciertas garantías de escalabilidad y rendimiento, junto con cualquier otro requisito, como la necesidad de GPU y TPU.

Para obtener más información sobre el aprovisionamiento y la configuración de clústeres, consulta la siguiente información:

Después de crear los clústeres y antes de implementar cualquier carga de trabajo, configura los siguientes componentes para cumplir con los requisitos que recopilaste en la fase de evaluación de los proyectos de OpenShift y de los clústeres:

Con el Sincronizador de configuración, puedes definir de forma central la configuración de los siguientes recursos en un repositorio común que cumpla con Git y aplicar esa configuración a todos los clústeres, tanto en un entorno local como en la nube:

Para instalar el Sincronizador de configuración, consulta Instala el Sincronizador de configuración. Para instalar el Controlador de políticas, consulta Instala el Controlador de políticas.

Migra datos desde tu entorno anterior

Ahora puedes migrar datos del entorno de origen al entorno de destino.

Si tus aplicaciones con estado de OpenShift alojan datos en los volúmenes persistentes de Kubernetes, existen diferentes estrategias para migrar datos al entorno de destino. La elección de la estrategia correcta depende de varios factores, como los proveedores de almacenamiento de backend de origen y destino y las ubicaciones de implementación:

  • Confía en las capacidades de clonación, importación y exportación del volumen del proveedor de almacenamiento. Si usas volúmenes de VMware vSphere en tu entorno local y migras a GKE en WMware, clona PersistentVolumes subyacentes a los discos virtuales de VMDK y actívalos como volúmenes en el entorno de destino. Si migras a GKE, importa los discos virtuales como discos persistentes de Compute Engine y úsalos como volúmenes persistentes.
  • Crea una copia de seguridad de los datos del entorno de origen mediante las herramientas del sistema operativo o de la base de datos. Aloja esos datos en una ubicación temporal a la que se pueda acceder desde ambos entornos y, luego, restablece los datos en tu entorno de destino.
  • Usa una herramienta de copia remota, como rsync, para copiar datos del entorno de origen al entorno de destino.
  • Usa una solución de copia de seguridad independiente del almacenamiento, como Velero mediante la integración de restic.

Para obtener más información, consulta Migración a Google Cloud: Transfiere grandes conjuntos de datos.

Si quieres obtener información sobre la migración de datos y estrategias para administrar el almacenamiento en GKE, consulta Migra datos de tu entorno anterior a tu nuevo entorno y los documentos de GKE sobre la configuración de almacenamiento.

Con GKE en WMware, puedes elegir entre diferentes opciones para la integración con sistemas de almacenamiento externo, como el almacenamiento de VMware vSphere, los complementos de volumen de árbol de Kubernetes y los controladores de la interfaz de almacenamiento de contenedores (CSI). Tu elección depende del sistema de almacenamiento externo con el que necesites integrar, los modos de acceso compatibles y si necesitas aprovisionamiento de volumen dinámico.

GKE on AWS implementa de forma automática el controlador CSI para Amazon Elastic Block Store (EBS) y un elemento StorageClass predeterminado que respalda PersistentVolumeClaims con volúmenes de EBS y un StorageClass para otros tipos de volúmenes de EBS. También puedes instalar controladores CSI adicionales y StorageClass personalizados. Si tienes un volumen de EBS que deseas importar en GKE on AWS, puedes crear un PersistentVolume desde él.

Implementa tus cargas de trabajo

Después de aprovisionar el clúster de GKE Enterprise y migrar los datos, ahora compila e implementa las cargas de trabajo. Tienes diferentes opciones, desde implementaciones manuales hasta las que son automatizadas por completo.

Si necesitas usar Operators para implementar cargas de trabajo que usan este método de implementación en el entorno de OpenShift, debes instalar el Operator antes de implementar tu carga de trabajo. En las siguientes fuentes, puedes verificar la disponibilidad de los Operators que necesitas:

Implementa de forma manual

Si implementas las cargas de trabajo de forma manual en el entorno de OpenShift, puedes adaptar este proceso de implementación manual al nuevo entorno de GKE Enterprise. Por ejemplo, puedes traducir de forma manual los manifiestos de recursos de OpenShift que evaluaste en cargas de trabajo, requisitos y dependencias para los manifiestos de recursos de GKE Enterprise correspondientes.

La siguiente tabla es una extensión de la tabla de la sección sobre las cargas de trabajo, requisitos y dependencias de este documento en la que se agrega información de los recursos de GKE Enterprise de destino en los que puedes usarlos.

Manifiesto de recursos de OpenShift de origen Parámetros y especificaciones más importantes Manifiesto de recursos de GKE Enterprise de destino
Deployment, DeploymentConfig, StatefulSet, trabajo, trabajo cron Imagen y repositorio del contenedor, puerto del contenedor, cantidad de réplicas de pod, ConfigMaps, secretos, PersistentVolumeClaims, solicitudes y límites de recursos, estrategia de actualización, nombre del servicio de StatefulSet, programación de trabajo cron Deployment, StatefulSet, trabajo, trabajo cron
ImageStream Imagen de contenedor, política de extracción de imágenes, repositorio de imágenes de contenedor Deployment
Escalador automático de pod horizontal Criterios de ajuste de escala automático Escalador automático de pod horizontal
Service Nombre de host que se usa para conectarse a la aplicación desde el clúster, dirección IP y puerto en el que se expone el objeto Service, extremos que se crearon para recursos externos Service
Route Nombre de host y ruta de recursos que se usan para conectarse a la aplicación desde fuera del clúster, reglas de enrutamiento Ingress

Diseña e implementa un proceso de implementación automatizado

Para compilar e implementar de forma automática las cargas de trabajo, diseña e implementa procesos de compilación y de implementación o adapta los existentes para admitir el nuevo entorno. Si necesitas implementar tus cargas de trabajo en un entorno híbrido, tus procesos de implementación deben admitir GKE en Google Cloud y GKE en WMware.

Para implementar los procesos de compilación y de implementación, puedes usar Cloud Build. Si deseas automatizar los procesos de compilación y de implementación, puedes configurar activadores de compilación, activadores de aplicaciones de GitHub o implementaciones automatizadas de la consola de Google Cloud. Si usas alguna restricción de controlador de políticas, puedes verificar los descriptores de Kubernetes y GKE Enterprise con las políticas de tus trabajos de Cloud Build para proporcionar comentarios a los desarrolladores.

Si necesitas ejecutar trabajos de compilación o almacenar código fuente de forma local, puedes usar GitLab. GitLab ofrece repositorios de código fuente y una plataforma de colaboración, capacidades de CI/CD y un registro de imagen de contenedor. Puedes implementar GitLab en los clústeres de GKE Enterprise directamente desde Cloud Marketplace o usar una de las otras opciones de instalación disponibles.

Si en este momento usas una de las instalaciones de OpenShift para compilar o implementar de forma automática las cargas de trabajo, puedes adoptar una de las siguientes estrategias, según tu proceso actual:

Sin importar el enfoque que elijas para compilar tus imágenes de contenedor, debes almacenarlas en un repositorio de imágenes de contenedor. Tienes las siguientes opciones:

Sin importar tu elección de almacenamiento de imágenes de contenedor, debes aprovisionar y configurar las credenciales para que los clústeres accedan al repositorio de imágenes de contenedor.

Si necesitas enviar notificaciones sobre el estado de las compilaciones y las imágenes de contenedor a usuarios o servicios de terceros, puedes usar Cloud Functions para responder a eventos que producen Cloud Build y Container Registry.

Resumen de la asignación de capacidades de OpenShift a GKE Enterprise

En la siguiente tabla, se resume la forma de asignar funciones de GKE Enterprise a las que usaste en OpenShift.

OpenShift GKE Enterprise
Proyectos de OpenShift
  • Espacios de nombres de Kubernetes administrados de forma centralizada por el Sincronizador de configuración
  • Autorización de RBAC de Kubernetes administrada de forma centralizada por el Sincronizador de configuración
  • Cuotas de recursos de Kubernetes administradas de forma centralizada por el Sincronizador de configuración
SDN de OpenShift y aislamiento de red
  • Políticas de seguridad de red de Calico administradas de forma centralizada por el Sincronizador de configuración
Restricciones del contexto de seguridad de OpenShift
  • Restricciones de Policy Controller
Canalizaciones de OpenShift
  • Cloud Build
  • Integración de Jenkins con el complemento de Jenkins de Google Cloud
  • GitLab
Origen a imagen de OpenShift
  • Cloud Native Buildpacks
  • Jib
Integración de identidades
  • Cloud Identity
  • Google Cloud Directory Sync
  • Integración de OIDC de GKE en VMware

Optimiza tu entorno

La optimización es la última fase de la migración. En esta fase, harás que el entorno sea más eficiente que antes. También, ejecutarás varias iteraciones de un bucle que se repite hasta que el entorno cumpla con tus requisitos de optimización. Los pasos de este bucle que se repite son los siguientes:

  1. Evalúa el entorno actual, los equipos y el bucle 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.

Las siguientes secciones se basan en Migración a Google Cloud: optimiza tu entorno.

Evalúa tu entorno actual, los equipos y el ciclo de optimización

Si bien la primera evaluación se centra en la migración de tu entorno a GKE Enterprise, esta evaluación se adapta a la fase de optimización.

Establece tus requisitos de optimización

Para conocer los requisitos de optimización de GKE en Google Cloud, revisa los requisitos de optimización que se establecen en Optimiza tu entorno.

Revisa los siguientes requisitos de optimización para tu entorno de GKE Enterprise:

Completa la optimización

Después de propagar la lista de requisitos de optimización, completa el resto de las actividades de la fase de optimización de Migración a Google Cloud: Optimiza tu entorno.

Obtén ayuda

Google Cloud ofrece varias opciones y recursos a fin de que encuentres la ayuda y la asistencia que necesitas para hacer mejor uso de los servicios de Google Cloud:

Hay más recursos para ayudarte a migrar cargas de trabajo a Google Cloud en el Centro de migración de Google Cloud.

Para obtener más información sobre estos recursos, consulta la sección sobre obtención de ayuda de Migración a Google Cloud: Comienza ahora.

¿Qué sigue?