Migra contenedores a Google Cloud: Migra de OpenShift a Anthos

Con este documento, podrás planificar, diseñar e implementar la migración desde OpenShift hacia Anthos. 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 ú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 Anthos. 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 Anthos. Si adoptas Anthos, 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.
  • Anthos Config Management 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 Anthos.

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 Anthos:

  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 Anthos.

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 Anthos, 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 Anthos 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 Anthos 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 Anthos para comprender cómo funciona Anthos y qué componentes de Anthos necesitas. Según los requisitos de la carga de trabajo y la localidad de datos que recopiles en la fase de evaluación, implementarás tus cargas de trabajo en GKE On-Prem, en Anthos GKE en Google Cloud o en GKE on 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.

A fin de compilar una base para GKE On-Prem, lee sobre los conceptos principales y, luego, considera lo siguiente cuando instales GKE On-Prem:

A fin de compilar una base para GKE on AWS, lee sobre sus conceptos principales, como la arquitectura de GKE on AWS y el almacenamiento de GKE on AWS. 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 Anthos:

  1. Aprovisionar y configurar la 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 Anthos, 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 Anthos necesarios.

Puedes aprovisionar clústeres de GKE en Google Cloud, clústeres de GKE On-Prem o clústeres de GKE on AWS. Por ejemplo, si tienes una carga de trabajo que debes implementar de forma local, aprovisiona uno o más clústeres de GKE On-Prem. 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 Anthos. Si tienes requisitos de múltiples nubes, debes aprovisionar clústeres de GKE on AWS, junto con otros clústeres de Anthos.

Primero, define la cantidad y el tipo de clústeres de Anthos 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 Anthos:

  • 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 Anthos 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 Anthos. El equipo de infraestructura proporciona un clúster de Anthos 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 Anthos 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 Anthos dentro de ese proyecto. Luego, el equipo de la plataforma administra estos clústeres. Este modelo puede requerir más clústeres de Anthos 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 Anthos Config Management, 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 usar Anthos Config Management, debes instalarlo junto con 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 On-Prem, 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. Si planeas modernizar tus cargas de trabajo para aplicar una arquitectura de microservicios, o si ya la adoptaste, consulta Migra una aplicación monolítica a microservicios en GKE.

Con GKE On-Prem, 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 Anthos 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 Anthos. 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 Anthos 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 Anthos 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 Anthos 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 y, luego, 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 On-Prem.

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 Cloud Console. Si usas alguna restricción de controlador de políticas, puedes verificar los descriptores de Kubernetes y Anthos 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 Anthos 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 Cloud Native Buildpacks 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:

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 Anthos

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

OpenShift Anthos
Proyectos de OpenShift
  • Espacios de nombres de Kubernetes administrados de forma centralizada por Anthos Config Management
  • Autorización de RBAC de Kubernetes administrada de forma centralizada por Anthos Config Management
  • Cuotas de recursos de Kubernetes administradas de forma centralizada por Anthos Config Management
SDN de OpenShift y aislamiento de red
  • Políticas de seguridad de red de Calico administradas de forma centralizada por Anthos Config Management
Restricciones del contexto de seguridad de OpenShift
  • Limitaciones del controlador de políticas de Anthos Config Management
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 On-Prem

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 el entorno actual, los equipos y el bucle de optimización

Si bien la primera evaluación se centra en la migración del entorno actual a Anthos, 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 el entorno de Anthos:

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 necesarias 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.

Próximos pasos