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:
- Migra contenedores a Google Cloud: Migra Kubernetes a Google Kubernetes Engine (GKE)
- Migra contenedores a Google Cloud: Migra a un nuevo entorno de GKE
- Migra contenedores a Google Cloud: Migra de OpenShift a GKE Enterprise (este documento)
- Migra contenedores a Google Cloud: Migra proyectos de OpenShift a GKE Enterprise
- Migra de OpenShift a GKE Enterprise: Migra las SCC de OpenShift a las restricciones de Policy Controller
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:
- Evalúa y descubre las cargas de trabajo.
- Planifica y compila una base.
- Implementa cargas de trabajo.
- Optimiza el entorno.
En el siguiente diagrama, se ilustra la ruta del recorrido de la migración.
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:
- Crea un inventario integral de los procesos y las aplicaciones.
- Clasifica los procesos y las apps según sus propiedades y dependencias.
- Capacita y educa a tus equipos en Google Cloud.
- Crea experimentos y pruebas de concepto en Google Cloud.
- Calcula el costo total de propiedad (TCO) del entorno de destino.
- 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:
- El proceso de compilación de la imagen de contenedor se ejecuta en su totalidad fuera de OpenShift. El proceso de compilación se puede basar en pasos manuales o en una canalización automatizada de integración y de implementación continuas (CI/CD) que tenga la imagen de contenedor y los manifiestos de Kubernetes como producto final.
- El proceso de compilación de la imagen de contenedor se ejecuta dentro de OpenShift. OpenShift admite diferentes opciones, como proporcionar un Dockerfile y todos los artefactos necesarios para compilar una imagen de contenedor, configurar una compilación de origen a imagen, configurar una compilación de canalización o configurar una compilación personalizada. Estas estrategias de compilación crean un recurso BuildConfig que define la elección de compilación, la ubicación de los artefactos de origen, las imágenes de contenedor de destino y los eventos que pueden activar el proceso de compilación de imágenes de contenedor.
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:
- Un objeto DeploymentConfig de OpenShift o Deployment de Kubernetes. Para obtener más información sobre las diferencias entre estos objetos, consulta Compara Deployments y DeploymentConfigs
- Un objeto Service de Kubernetes para que los clientes puedan acceder a la aplicación, y Route de OpenShift a fin de conectarse a ese Service de Kubernetes desde fuera del clúster
- Un ImageStream de OpenShift para proporcionar una abstracción que haga referencia a las imágenes de contenedor. Un ImageStream de OpenShift incluye una o más imágenes de contenedor, cada una identificada por etiquetas, y presenta una sola vista abstracta de imágenes relacionadas, similar a un repositorio de imágenes de contenedor
- Un objeto BuildConfig de OpenShift para compilar las imágenes de contenedor de esa aplicación en OpenShift
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:
- Otros controladores de Kubernetes
- Escalador automático de pod horizontal
- Contextos de seguridad de pods
- Cargas de trabajo sin estado y con estado.
- Almacenamiento
- Incorporación de secretos y configuración
- Objetos Ingress
- Registros y supervisión
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:
- 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.
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:
- Asegúrate de que el entorno local cumpla con los requisitos de Anthos GKE On-Prem. Debes proporcionar suficiente capacidad en el entorno de VMware vSphere para satisfacer los requisitos de los clústeres de administrador y los clústeres de usuarios. Estos requisitos dependen de la cantidad de solicitudes de recursos de las cargas de trabajo y la cantidad de clústeres que necesitas. Evaluaste ambos aspectos en la fase de evaluación.
Configura la red. Debes configurar tu red local para cumplir con los requisitos de conectividad de red de las aplicaciones recopilados en la evaluación, además de los requisitos de instalación de GKE en WMware. Considera las siguientes necesidades de red:
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:
- Asegúrate de que tus entornos de Amazon Web Services (AWS) y Google Cloud cumplan con los requisitos para GKE on AWS. GKE on AWS requiere una cuenta (AWS) con acceso a la línea de comandos y una clave de AWS Key Management Service (KMS) para encriptar secretos de la capa de la aplicación en clústeres. Necesitas Terraform y kubectl.
- Configura el entorno de AWS. Debes configurar el entorno de AWS, instalar las herramientas, como la interfaz de línea de comandos de AWS, configurar credenciales de IAM para AWS y aprovisionar recursos en tu entorno de AWS, como una clave de AWS KMS.
- Configura el entorno de Google Cloud. Debes configurar el entorno de Google Cloud, crear los proyectos y las cuentas de servicio necesarios de Google Cloud, y configurar la IAM.
Implementa tus cargas de trabajo
En la fase de implementación, sigue estos pasos para implementar las cargas de trabajo en GKE Enterprise:
- Aprovisionar y configurar tu plataforma y entornos de ejecución
- Migrar datos de tu entorno anterior a tu entorno nuevo
- 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:
- Aprovisiona y configura la plataforma y entornos de ejecución para clústeres de GKE en Google Cloud.
- Crea clústeres de administrador y de usuario para los clústeres de GKE en WMware
- Instala el clúster de administración y crea un clúster de usuario para clústeres de GKE on AWS.
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:
- Administración de identidades y accesos: puedes configurar la administración de identidades y accesos como se describe en Configurar la administración de identidades y accesos. Puedes migrar a Cloud Identity como tu proveedor de identidad principal o usar Cloud Directory Sync para sincronizar Cloud Identity con un servidor de Active Directory o LDAP existente. GKE en WMware admite OpenID Connect (OIDC) para autenticarse en clústeres de usuarios mediante la línea de comandos. Consulta Autentica con OIDC y Google para integrar la autenticación de línea de comandos en Cloud Identity.
- Supervisión: Puedes adaptar la solución de supervisión actual al entorno de GKE Enterprise de destino según las restricciones y los requisitos. Si tu solución actual está alojada en OpenShift, puedes implementar Cloud Monitoring como se describe en Compila tu base o puedes implementar Prometheus y Grafana mediante GKE en WMware.
- Registros: Puedes adaptar la solución de registro actual al entorno de GKE Enterprise de destino según las restricciones y los requisitos. Si tu solución actual está alojada en OpenShift, puedes implementar Cloud Logging como se describe en Construye tu base: Supervisión y alertas.
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:
- Control de acceso según la función (RBAC): Después de configurar la autenticación, puedes implementar tus políticas de autorización con una combinación de administración de identidades y accesos y RBAC de Kubernetes. Estas políticas cumplen con los requisitos que recopilaste en la evaluación del proyecto OpenShift y el modelo de multiusuario que elegiste.
- Cuotas de recursos: puedes aplicar cuotas de recursos a los espacios de nombres para asignar cuotas a los equipos de desarrolladores según sea necesario.
- Contexto de seguridad para las cargas de trabajo: Puedes usar Policy Controller para crear restricciones para aplicar la seguridad del pod según tus requisitos y la configuración de restricciones del contexto de seguridad de OpenShift que se recopilaron en la fase de evaluación.
- Aislamiento y política de red: puedes implementar el aislamiento de red requerido entre espacios de nombres o cargas de trabajo mediante las políticas de red de Kubernetes.
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:
- Google Cloud Marketplace
- operatorhub.io
- Sitio web de un proveedor de software específico o repositorio de GitHub
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:
- Canalizaciones de Jenkins: si usas canalizaciones de Jenkins para automatizar tu proceso de compilación y de implementación, puedes transferir tu canalización a Cloud Build, usar tu entorno de Jenkins existente o implementar Jenkins en Google Cloud.
- Implementaciones y compilaciones desde un Dockerfile y los artefactos necesarios: puedes usar Cloud Build para compilar imágenes de contenedor con un Dockerfile o un archivo de configuración de compilación. Si deseas ejecutar las compilaciones en un clúster local, puedes usar GitLab.
- Compilaciones de origen a imagen: en Cloud Build, debes implementar un paso preliminar para compilar los artefactos que requiere la imagen del contenedor resultante. Si el trabajo de origen a imagen compila una aplicación de Python y produce una imagen de contenedor, debes configurar un paso de compilación personalizado para compilar la aplicación de Python y, luego, compilar la imagen de contenedor. Este enfoque también requiere que proporciones un Dockerfile o, si no deseas proporcionar uno, puedes usar paquetes de compilación de Google Cloud o Jib para aplicaciones de Java.
- Compilaciones personalizadas: puedes crear compiladores personalizados de Cloud Build como lo haces ahora en OpenShift. Si los compiladores personalizados no usan funciones específicas de OpenShift, es posible que puedas usarlos como en Cloud Build.
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:
- Conserva tu repositorio de imágenes de contenedor existente. Si usas un repositorio de imágenes de contenedor externo que no se ejecuta en OpenShift y aún no estás listo para migrar, puedes seguir usando ese repositorio como almacenamiento de tus imágenes de contenedor.
- Container Registry. Si prefieres un servicio completamente administrado, puedes usar Container Registry para almacenar tus imágenes de contenedor. Si necesitas capas de seguridad adicionales, puedes administrar las claves de encriptación de Container Registry por tu cuenta, configurar un perímetro seguro para acceder a Container Registry, mejorar la seguridad de la cadena de suministro del software y analizar las imágenes de contenedor para detectar vulnerabilidades conocidas mediante Artifact Analysis. Container Registry también admite imágenes base administradas que Google mantiene como base para tus imágenes de contenedor.
- Repositorio local. Si necesitas migrar el repositorio actual porque está alojado en OpenShift y necesitas almacenar las imágenes de contenedor en un entorno local, puedes elegir el registro que se proporciona mediante GitLab.
- Enfoque híbrido. Puedes combinar las opciones anteriores para aprovechar las fortalezas de cada una. Por ejemplo, puedes usar Container Registry como el repositorio principal y duplicarlo en el repositorio local. En este caso, usas funciones de Container Registry y aún te beneficias de tener un repositorio local.
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 |
|
SDN de OpenShift y aislamiento de red |
|
Restricciones del contexto de seguridad de OpenShift |
|
Canalizaciones de OpenShift |
|
Origen a imagen de OpenShift |
|
Integración de identidades |
|
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:
- Evalúa el entorno actual, los equipos y el bucle de optimización.
- Establece tus requisitos y objetivos de optimización.
- Optimiza tu entorno y tus equipos.
- 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:
- Comienza a implementar cargas de trabajo en un entorno sin servidores. Si necesitas reducir el esfuerzo de los equipos de operaciones, puedes comenzar a usar plataformas sin servidores completamente administradas, como Cloud Run y Cloud Run for Anthos.
- Moderniza los procesos de implementación. En Migración a Google Cloud: Implementa tus cargas de trabajo, se describen los procesos de implementación de extremo a extremo típicos y la forma de modernizar los procesos existentes. Si deseas modernizar los procesos de implementación existentes o diseñar otros nuevos, consulta Migración a Google Cloud: Migra de implementaciones manuales a implementaciones automatizadas en contenedores para obtener información.
- Implementa mediante Spinnaker. Si necesitas implementar la lógica de implementación, como las implementaciones de versiones canary y las implementaciones azul-verde a fin de aumentar la confiabilidad de tu entorno y reducir el impacto para los usuarios, puedes usar Spinnaker. Para usar Spinnaker en Google Cloud, debes instalarlo. Luego, implementa tus procesos de implementación con Spinnaker. Por ejemplo, puedes registrar los clústeres de GKE existentes en Spinnaker, habilitar la asistencia de Kustomize para Spinnaker o implementar canalizaciones de entrega continua con Spinnaker y GKE.
- Implementa una cadena de suministro de software segura. En cargas de trabajo críticas para la seguridad, puedes implementar una cadena de suministro de software segura en tus clústeres de GKE Enterprise mediante la autorización binaria.
- Cambia a Anthos Service Mesh. Si ya usas OpenShift Service Mesh o buscas las capacidades de administración de tráfico, observabilidad y seguridad que proporciona una malla de servicios, puedes adoptar Anthos Service Mesh. Anthos Service Mesh proporciona una distribución de Istio probada y compatible con GKE Enterprise, junto con capacidades de backend administradas por Google para la observabilidad, la administración de certificados mTLS y la integración con Identity Aware Proxy (IAP).
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:
- Recursos de autoservicio: Si no necesitas asistencia personalizada, tienes varias opciones que puedes usar a tu propio ritmo.
- Socios de tecnología: Google Cloud se asoció con varias empresas para ayudarte a usar nuestros productos y servicios.
- Servicios profesionales de Google Cloud: Nuestros servicios profesionales pueden ayudarte a aprovechar al máximo tu inversión en 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?
- Migración a Google Cloud: Comienza ahora.
- Obtén más información sobre GKE Enterprise y Migrate to Containers.
- Obtén más información sobre cómo respaldar tu migración con la expansión de malla de Istio.
- Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.