Uno de los servicios que más estamos utilizando en Datadope, de los proveedores de nube pública en los últimos años, es el servicio de Kubernetes. La mayoría de nuestros clientes utilizan los servicios de Cloud de la plataforma de Google, así que casi todas las migraciones de servicios que hemos tenido que hacer han sido contra el servicio de GKE (Google Kubernetes Engine), que es el servicio ofrecido por la plataforma de Cloud de Google.

Hemos querido hacer esta entrada para desglosar una serie de pautas que seguir para realizar una migración de un servicio a GKE, así como los errores que se han cometido, para que aprendamos de ellos e intentar evitarlos en algún proyecto futuro.

¿Qué es GKE?

Comencemos realizando una breve introducción sobre qué es y qué nos proporciona el servicio de Cloud de Kubernetes, más específicamente el servicio que ofrece la plataforma de nube pública de Google.

• Las siglas de GKE provienen de Google Kubernetes Engine.
• Kubernetes como servicio ofrecido por la plataforma de Google Cloud.
• Principales características de Kubernetes como servicio: Aunque en esta entrada esté orientada al servicio de GKE, estas características son comunes por la mayoría de los proveedores de nube pública.
• Proceso de creación del cluster sencillo e intuitivo.
• Escalabilidad del cluster automática.
• Alta disponibilidad del cluster.
• Servicios de monitorización completos.

Ahora que conocemos un poco qué nos proporciona un servicio de Kubernetes en una nube pública, vamos a comenzar con las pautas que recomendamos seguir a la hora de realizar una migración de un servicio a GKE.

Pauta 1: Análisis del servicio a migrar

Comenzamos por lo básico, realizar un análisis del servicio que vamos a migrar. Este análisis recomendamos que sea lo más exhaustivo posible, ya que gran parte de las desviaciones en los plazos de entrega, pueden venir por un análisis incompleto de los requisitos del servicio.

Como cada aplicación o servicio cuenta con unos requisitos muy específicos para que funcione correctamente, vamos a indicar las principales características que, por lo general, se recomienda analizar del servicio que vamos a migrar.

Recursos hardware utilizados por el servicio

Uno de los requisitos más importantes para que un servicio o una aplicación funcione correctamente, son los recursos hardware utilizados durante su funcionamiento.

Será necesario medir los recursos que está utilizando nuestro servicio. Podemos diferenciar varios estados en el funcionamiento de un servicio.

• El funcionamiento habitual en largos momentos, con baja carga de trabajo: Digamos que sería el comportamiento y el consumo de recursos que tendría la mayoría del tiempo.
• El funcionamiento habitual con alta carga de trabajo: En este caso son momentos, en el que el servicio tendrá una alta carga de trabajo, pero que conocemos dichos momentos de gran carga.

En base al análisis de los recursos utilizados habitualmente, se configurarán los límites que utilizará el servicio migrado.

• Por otro lado tenemos los picos de carga: Será necesario analizar diferentes momentos en los que nuestro servicio haya tenido picos de carga, de un tiempo predeterminado, pero que no suelen ser el comportamiento habitual.

Esta información nos servirá para configurar un posible autoescalado del servicio que nos permita cubrir dichos picos de carga en momentos muy concretos.

La idea del análisis de recursos es medir los recursos utilizados por el servicio en cada uno de estos estados, para así, tener toda la información posible y redimensionar lo más óptimo posible, los recursos que le vamos a asociar al servicio a la hora de desplegarlo en nuestro cluster de GKE.

 Comunicaciones necesarias

Una vez analizados los requisitos hardware que tiene nuestro servicio, otro análisis importante que se recomienda realizar es el análisis de las comunicaciones que necesita el servicio para funcionar correctamente.

Algunas de las preguntas que nos ayudarán a analizar estas comunicaciones pueden ser las siguientes:

• ¿Nuestro servicio necesita estar expuesto a Internet? Si el servicio necesita estar expuesto a internet, es necesario conocer este requisito ya que es probable que necesitemos también otros recursos como un registro DNS para nuestro servicio y algún servicio de balanceador de carga que nos envíe las peticiones entrantes desde Internet hacia nuestro servicio.
• ¿Qué comunicaciones con nuestra red o redes internas realiza nuestro servicio? En este caso, analizaremos las comunicaciones que se deberán permitir en nuestros firewalls, para que haya comunicación entre el servicio desplegado en GKE y nuestras redes internas.
• ¿Nuestro servicio tiene algún componente que realice comunicaciones adicionales a las que realiza el propio servicio? Para explicar este tipo de comunicaciones, utilizaremos un ejemplo, el servicio de Logstash. Logstash es una aplicación que se utiliza para manipular todo tipo de ficheros de log, estos ficheros de log pueden ser enviados a Logstash desde diferentes servicios y aplicaciones. Sería necesario conocer todas las comunicaciones que existen entre Logstash y cada uno de esos servicios que necesitan enviar sus logs. Estas comunicaciones se añadirán a la lista de comunicaciones a habilitar en nuestros firewalls, para que aunque nuestro servicio esté en GKE, continúe funcionando correctamente.

Este análisis de comunicaciones es un punto importante del proyecto de migración. Podemos desviarnos mucho de los plazos de entrega si no realizamos un análisis completo y detallado. Puede ser un análisis tedioso, pero si se realiza correctamente, nos evitará peticiones de apertura de comunicaciones de última hora que, si conllevan una burocracia considerable, nos puede retrasar bastante la entrega del proyecto.

Configuraciones, credenciales y datos sensibles

Por último, pero no menos importante, se analizará la propia configuración del servicio. Entre estos ficheros de configuración podemos encontrar desde ficheros de configuración en texto plano, hasta ficheros binarios con información confidencial en su interior. Será necesario conocer todos estos ficheros utilizados por nuestro servicio, para que, a la hora de realizar la migración, los convirtamos en objetos utilizables por Kubernetes y los asociemos al servicio migrado.

Pauta 2: Estudio de servicios existentes en los proveedores de nube pública

 

Ya conocemos los requisitos de nuestro servicio, tras el análisis realizado. El siguiente paso será estudiar las diferentes soluciones que nos ofrece la nube pública, de cara a utilizar la solución que más se adapte a nuestras necesidades.

Normalmente, a la hora de migrar un servicio a la nube pública, dispondremos de dos opciones:

• El proveedor de nube pública ofrece el servicio o la aplicación que estamos migrando:

-Puede ser una buena solución si las ventajas se ajustan a nuestras necesidades.

Posibles ventajas de utilizar un servicio ofrecido por el proveedor de Cloud:

1. Facilidad a la hora de gestionar los recursos necesarios para el servicio.
2. Alta disponibilidad a nivel internacional.
3. Pago por uso más ajustado que el realizado por el servicio de GKE.
4. Soporte técnico específico para el servicio.

Posibles inconvenientes:

1. Coste superior.
2. Imposibilidad de integrar con los sistemas y servicios de onpremise.

• El proveedor de nube pública no ofrece el servicio porque es un servicio custom del cliente. En este post nos centraremos en este caso, pero quería mencionar la opción anterior, porque siempre deberemos comprobar si se ajusta mejor a las necesidades del cliente si existe la posibilidad de utilizar el propio servicio de la plataforma de nube pública.

Tras analizar los diferentes proveedores de Cloud y los requisitos de nuestro servicio, se podrá decidir la mejor opción y hacer una propuesta.

 

Pauta 3: Analizar y gestionar la integración con GKE

 

Como hemos comentado varias veces, este post está centrado en el servicio de GKE, así que, una vez decidido que vamos a utilizar GKE para desplegar nuestro servicio a migrar, analizaremos el servicio de GKE del que disponemos, ya sea un clúster existente en la infraestructura de un cliente o un cluster desplegado por nosotros.

A continuación os dejamos algunas preguntas y puntos importantes, que os ayudarán a analizar y gestionar el servicio de GKE: 

• ¿El cluster tiene una estructura definida (Respositorios, etc)?. ¿Debemos generar dicha estructura nosotros? Si el cliente cuenta con un cluster, donde despliega sus aplicaciones, será nuestra función, conocer su estructura y si, para desplegar una aplicación nueva, debemos generar una estructura adicional, o solicitar que la genere el equipo correspondiente dentro de los equipos del cliente.
• ¿Existe un entorno no productivo?. De ser así, siempre que sea posible, es recomendable utilizar dicho entorno para desplegar una versión del servicio que vamos a migrar, primero a este entorno no productivo, para realizar comprobaciones y pruebas, antes de desplegarlo finalmente en el cluster de producción.
• Espacios de nombre. ¿Qué espacio de nombre utilizará el servicio que vamos a migrar?. Será necesario conocer cómo están organizados los espacios de nombre del cluster, si éste está creado previamente, o decidir en qué espacio de nombre vamos a desplegar el servicio, si el cluster ha sido creado por nosotros.
• Recursos asociados al espacio de nombre que utilizaremos. De igual manera, debemos conocer si el espacio de nombre que vamos a utilizar tiene alguna limitación a nivel de recursos, para solicitar más en el caso de que sea necesario.
• CI/CD. Solicitaremos información sobre si existe una estructura de repositorios, y alguna herramienta que realice integración continua y despliegue continuo sobre el cluster, herramientas como ArgoCD o algún servicio similar.
• Subdominio asociado al cluster. Si vamos a desplegar un servicio que necesita estar accesible a través de un nombre de dominio. Ej: Traefik para administrar el subdominio asociado al cluster o si el cluster del cliente ya cuenta con alguna herramienta parecida.
• Sistema de monitorización propio. Por defecto, GKE proporciona un sistema de recolección de métricas y visualización del cluster, podríamos utilizar dicho sistema para controlar el servicio a lo largo de la migración.
• Gestionar las comunicaciones necesarias por el servicio que vamos a migrar.

Pauta 4: Migración del servicio a GKE

Con la infraestructura de GKE definida, el siguiente paso será la propia migración del servicio.

Si disponemos de un cluster no productivo, realizaremos la migración en este cluster, antes de desplegar el servicio en el cluster de aplicaciones productivas. Si solo disponemos de un cluster, se migrará el servicio a ese cluster, pero no actuará como servicio productivo hasta que no validemos su funcionamiento.

Como pasos importantes de la migración recalcar los siguientes:

Recursos asociados al servicio:

• Utilizaremos el análisis del servicio realizado para definir los recursos que utilizará el servicio.
• Limitar los recursos.
• Debemos definir los recursos asociados teniendo en cuenta la característica de réplicas de Kubernetes.

Ejemplos de uso:

1. Si el servicio que vamos a migrar tiene que soportar mucha carga constantemente, podremos asociar varias réplicas con unos recursos lo suficientemente altos para que soporte la carga. Asociaremos mínimo dos réplicas para proporcionar alta disponibilidad siempre que podamos.
2. Si el servicio tiene picos de carga y generalmente una carga baja, podremos asociar un autoescalado al servicio, para que se generen réplicas automáticamente en cuanto se detecte un aumento de la carga.

Comunicaciones:

Al igual que con los recursos, utilizaremos el análisis del servicio realizado para ajustar las comunicaciones necesarias por el servicio en sí, y las de todos sus componentes. Mencionamos algunas pautas a tener en cuenta:

• Es posible que durante la migración se necesiten comunicaciones adicionales a las existentes. Principalmente para no afectar al servicio en producción.
• Habilitar conexión entre el cluster y las redes onprem si el servicio las necesita.
• Conocer si las aplicaciones desplegadas en el cluster necesitan un proxy para acceder a internet, si el servicio lo necesita.
• Permitir el acceso desde internet al servicio, si fuera necesario.

Una vez desplegada una versión no productiva del servicio, podríamos empezar con las pruebas de funcionamiento, para asegurarnos, antes de poner el servicio en producción, que disponemos de todo lo necesario para que éste funcione correctamente.

 

Pauta 5: Pruebas de funcionamiento

Realizaremos las pruebas sobre el servicio migrado, antes de ponerlo en producción.

Como recomendación, realizaremos mínimo dos pruebas, pruebas de recursos, que nos ayudarán a comprobar si la configuración que hemos asignado al servicio es suficiente para cubrir su funcionalidad o si estamos utilizando recursos de más, lo que conlleva a gastos innecesarios y prueba de comunicaciones, que nos permitirá detectar si todas las conexiones necesarias por el servicio están disponibles.

Os dejamos algunas pautas adicionales sobre estas dos pruebas:

Pruebas de recursos:

• Si es posible, enviaremos la carga de trabajo por igual al servicio productivo, como al servicio que acabamos de migrar, así las pruebas serán lo más parecidas a la realidad.
• Asociaremos un número de réplicas en función de los resultados de las pruebas.
  Pruebas de comunicaciones:
• Probaremos las comunicaciones tanto del servicio como de todos sus componentes.
• Si se han realizado comunicaciones temporales para el proceso de migración, debemos asegurarnos, que las que necesitaremos para cuando el servicio se ponga en producción, están disponibles.

 

Pauta 6: Monitorización del servicio

Junto a las pruebas de funcionamiento, otro aspecto importante a tener en cuenta es la monitorización del servicio. En este punto, podemos destacar lo siguiente:

• GKE ofrece junto a todos los clusters de Kubernetes desplegados, la herramienta de Grafana, que nos permitirá la visualización de métricas del cluster.
• Podemos utilizar la API de Kubernetes para extraer cualquier métrica sobre la infraestructura del espacio de nombre en el que estará desplegado el servicio que vamos a migrar.
• Además de las métricas que ofrece GKE, generalmente, podemos monitorizar el estado funcional del servicio utilizando algún recolector de métricas como Telegraf o extractor de logs como Filebeat si tenemos información sobre la funcionalidad del servicio en los logs.

 

Pauta 7: Pase a producción del servicio

Por último, una vez ya realizadas todas las pruebas de funcionamiento del servicio, y preparada la monitorización del mismo, nos enfrentamos al pase a producción. Sobre el pase a producción podemos recomendar que se revisen los siguientes puntos:

• Si se han realizado comunicaciones temporales para el proceso de migración, debemos asegurarnos, que las comunicaciones que necesitaremos para cuando el servicio se ponga en producción, están disponibles.
• Si es posible, simular un pase a producción del servicio, en una ventana horaria predefinida. Muy recomendable.
• Si hemos utilizado un cluster no productivo para migrar el servicio, se desplegará el servicio en el cluster productivo con todas las correcciones realizadas tras las pruebas en el cluster no productivo.

 

Y hasta aquí éste repaso por las pautas y recomendaciones a seguir en un proceso de migración de un servicio desde onpremise hacia la nube pública. ¿Qué pautas añadirías tú a este proceso tan común en los últimos años?