Migración a Kubernetes: beneficios y mejores prácticas

Cambiar la arquitectura del servidor es siempre un gran paso para cualquier proyecto. En Dysnix, guiamos a la mayoría de nuestros clientes en este proceso al proporcionarles servicios de Kubernetes. Y cada vez, ha sido una experiencia diferente.

Si su empresa elige la estrategia de migración de Kubernetes, obviamente, hay una buena razón para ello: aumentar la estabilidad, unificar el entorno y acelerar el escalado automático.

Kubernetes se adapta mejor a las arquitecturas de microservidores. De hecho, cuanto más distintas sean las entidades del clúster, mejor. Esto permite:

• Establecer límites precisos para cada servicio
• Establecer solo las conexiones necesarias
• Elegir el tipo de entidad de Kubernetes único de cada servicio (Deployment, ReplicationController, DaemonSet, etc.)

Antes de que me acerque siquiera a explicar el proceso, me gustaría que imaginaras el objetivo real de tu migración.

• Por qué ¿planeas migrar a Kubernetes?
• Si es necesario cambiar la lógica de tu aplicación, ¿tendrás suficientes recursos para modificarla? ¿Se puede llamar al diseño de tu aplicación «nativo de contenedores»?
• ¿Qué beneficios de Kubernetes espera obtener más adelante?

Estas y otras preguntas deben tenerse en cuenta antes de empezar a migrar a Kubernetes, ya que este proceso no es ninguna broma para los desarrolladores y las empresas en general. Por debajo de la punta del iceberg, tu equipo puede tener que hacer todo un montón de tareas pendientes, por lo que no cabe duda de que tienen que estar preparados para ello y saber con certeza para qué sirven estas acciones. Por otro lado, incluso si la migración a Kubernetes finaliza sin problemas, el diseño de tu aplicación o la lógica empresarial no pueden sacar ningún beneficio de Kubernetes en tu caso particular.

En este artículo, compartiré la experiencia de Dysnix sobre la migración a los procesos y las herramientas de Kubernetes, describiré los errores más comunes y cómo evitarlos.

Zona cero: descomposición de una aplicación y reinventarla como nativa de Kubernetes

Como continuación lógica del punto anterior, voy a pasar del punto de la estrategia al de la táctica. Veamos qué tienes que tener en cuenta y qué tienes que hacer con las respuestas que obtienes de las preguntas sobre los «objetivos».

Compruebe y visualice su arquitectura actual

La documentación, las herramientas de visualización y la planificación general le ayudarán a estimar el tiempo y el alcance de los recursos que necesitará para la migración. Describe cada parte de tu aplicación y las conexiones intermedias y márcalas en el esquema. Usa una vista de implementación o hexagonal para tu comodidad, o incluso un simple diagrama de flujo de datos hará lo mismo. Una vez completado este paso, tendrá un mapa completo de los módulos y de cómo están conectados. Esto le permitirá comprender completamente qué es exactamente lo que se migrará a Kubernetes.

Repensar la arquitectura actual de las aplicaciones

A pesar del entusiasmo que pueda sentir en este momento: «¡Vamos a reescribirlo todo!» — tienes que mantener la calma y construir el orden de migración de tus módulos del más simple al más difícil. Con este enfoque, podrás capacitar a tu equipo y prepararlo para las «tareas más hercúleas». O intenta preparar tu plan utilizando otro concepto: elige los módulos más esenciales (los responsables del trabajo de lógica empresarial, por ejemplo) y configúralos como los más importantes. Otros módulos pueden marcarse como secundarios y trabajar en ellos una vez que el núcleo de la aplicación se haya migrado a k8s.

Las tareas que tendrás que resolver aquí serán:

1. Busque un método de registro aplicable a su aplicación;
2. Elija cómo se almacenarán sus sesiones (en la memoria compartida, por ejemplo);
3. Piense cómo implementará el almacenamiento de archivos para su futura aplicación k8s;
4. Considera los nuevos desafíos de las pruebas y la solución de problemas de tu aplicación.

Debo mencionar que, según el tipo de aplicación, algunas etapas pueden reducirse o ampliarse con el tiempo, y no pasa nada. Además, es posible que necesites contratar personal adicional y multiplicar la experiencia de tu equipo. Cada empresa experimenta la migración de forma individual.

Pero volvamos al siguiente proceso en una breve descripción:

• Etapa de contenerización. Aquí prepararás un contenedor de lanzamiento de Docker con configuraciones para tu aplicación. Describe el entorno, los lenguajes de programación y otras preferencias de la imagen de Docker. Más adelante, describiré cómo lanzar un contenedor en un caso práctico.
• Obtenga un esquema de los módulos de su aplicación y elija objetos de Kubernetes para cada módulo. Por lo general, esta etapa se desarrolla sin problemas, ya que hay una gran variedad de tipos y opciones para los componentes de tu aplicación. Después, debes escribir archivos YAML para crear objetos de Kubernetes mapeados.
• Adaptación de bases de datos. La práctica más común es dejarlo como está, pero conectarlo con una nueva aplicación basada en Kubernetes. Después de lanzar un contenedor Docker, solo necesitas la decisión ejecutiva para tomar y convertir toda la aplicación en contenedores, incluida tu base de datos.

Ahora tiene una comprensión general de la adopción de Kubernetes. Profundicemos en el tema con las peculiaridades técnicas, las mejores prácticas de migración de aplicaciones y los casos de uso de Kubernetes.

Migre la aplicación a Kubernetes paso a paso

Almacenamiento de datos persistentes

Al desarrollar la arquitectura de un proyecto, intentamos evitar por completo el almacenamiento de datos en archivos. ¿Por qué?

• La mayoría de las plataformas (AWS, Google) solo permiten instalar almacenamiento a nivel de bloque desde un único punto. Impone límites al escalado horizontal de los contenedores que utiliza Persistent Volume.
• Cuando un sistema de archivos contiene muchos archivos, se producen problemas para acceder al sistema de archivos, lo que dificulta considerablemente la capacidad de respuesta general del recurso.

Las formas de evitarlo son las siguientes:

• Almacenamos contenido estático en Object Storage. Si estamos hablando de Amazon, utilizamos S3. Si se trata de un clúster de hardware: Ceph RDB para almacenamiento persistente y Ceph rados para S3.
• Intentamos almacenar la mayoría de los datos en almacenamientos de bases de datos y/o NoSQL (como ElasticSearch).
• Almacenamos las sesiones y la caché en bases de datos en memoria (redis/memcache).

Sin embargo, si lo que se requiere es un volumen persistente, debe prepararse correctamente.

1. Primero, recopile la lista de TODOS los catálogos que almacenan datos persistentes. Si no lo hace, los datos se registrarán sin ningún error, pero después de reiniciar el contenedor o migrar a un nodo diferente, TODOS los datos se PERDERÁN.
2. Intente compilar los catálogos de tal manera que todos sus datos se almacenen en un solo catálogo en la parte inferior, ya que es necesario poder usar solo un volumen persistente para un contenedor. Esta regla no siempre se aplica y, a veces, simplemente es necesario distribuir los datos entre varios PVs. Solo el arquitecto de la aplicación, que conoce el propósito de un almacenamiento persistente y el volumen de datos previsto que se almacena allí, puede dar la respuesta definitiva.
3. Seleccione un sistema de archivos adecuado. Ext4 es adecuado para la mayoría de las tareas, pero a veces la elección de un sistema de archivos más adecuado puede mejorar el rendimiento.
4. Seleccione un PV de tamaño óptimo. No te preocupes, podrás ampliarlo fácilmente si es necesario. Sin embargo, si un sistema de archivos está sobrecargado, el redimensionamiento consumirá aún más recursos y puede afectar al rendimiento.

Cuando cumplas todos los requisitos, crea un archivo YAML para Kubernetes Persistent Volume. En el caso de AWS, puede tener este aspecto:

apiVersion: v1
    kind: PersistentVolume
    metadata:
        name: example-my-pv
        annotations:
            volume.beta.kubernetes.io/storage-class: "default"
    spec:
        capacity:
            storage: 100Gi
        accessModes:
            - ReadWriteOnce
        awsElasticBlockStore:
            volumeID: vol-0dc1fcf80ac20300a
            fsType: ext4