Hola a todos!
En este artículo, decidimos especular un poco sobre cuándo y por qué las empresas necesitan Kubernetes. Qué difícil es la tecnología de entrada, qué tan rápido y cómo valdrá la pena. ¿Vale la pena y lo que todo amenaza? No nos propusimos la tarea de escribir una revisión técnica profunda, de la cual hay muchas, pero en los siguientes materiales definitivamente compartiremos nuestras mejores prácticas en términos de arquitectura de aplicaciones y estabilidad bajo Kubernetes. Ahora nos enfocamos en si el juego vale la pena y lo que obtenemos al salir.
El tiempo de comercialización, la velocidad de actualización de las actualizaciones en el mercado, hoy se está convirtiendo en un factor clave en la efectividad de las soluciones de TI. El producto debe mejorarse todos los días: agregue nuevas funciones y módulos, mantenga la documentación y los scripts en perfectas condiciones. Al mismo tiempo, los sistemas en línea deben funcionar sin problemas y actualizarse sin afectar a los usuarios.
Protegiendo la discreta actualización continua están los microservicios, los contenedores y la infraestructura para su orquestación: Kubernetes (o K8S, se llama en círculos técnicos).
Cómo Kubernetes proporciona actualizaciones continuas del sistema
La tarea principal al actualizar una solución de TI es garantizar su correcto funcionamiento después de la transferencia del entorno de desarrollo a la plataforma del producto. Y también en el buen funcionamiento del sistema a la hora de actualizar el producto.
El problema radica en el hecho de que la configuración del entorno de desarrollo y los servidores industriales a menudo no coinciden. Los contenedores solucionan este problema combinando todos los componentes de software en un paquete aislado del entorno externo. Esto le permite implementar aplicaciones de manera rápida y confiable en cualquier infraestructura y facilita la actualización de la base de código del sistema.
Inadvertidos por los usuarios, las actualizaciones se realizan mediante la duplicación de contenedores y la redirección secuencial de los usuarios de uno a otro. Para la gestión de contenedores (orquestación) utilizamos Kuberenetes. En última instancia, facilita la gestión de la solución, la implementación y la actualización, la supervisión del rendimiento y la depuración en caso de falla.
Cuando una empresa necesita Kubernetes
Es hora de que las empresas piensen en cambiarse a la plataforma Kubernetes cuando:
- Un proyecto o sistema es una herramienta importante para las empresas y, por lo tanto, debe ser tolerante a fallas y continuar funcionando, incluso si alguna parte está fuera de servicio.
- El sistema está muy cargado, mientras mantiene actualizaciones o mejoras rápidas.
- El sistema necesita periódicamente capacidad adicional. Y los necesita con prontitud.
- Y con todo esto, la velocidad de entrega de actualizaciones al entorno industrial se mide en semanas, meses, años, pero nunca en horas o días.
También necesita Kubernetes como herramienta para la automatización y estandarización del trabajo con la solución, si además de lo anterior:
- No hay aislamiento entre los sistemas de TI de la empresa y cada uno puede influir en el otro.
- Si necesita escribir un script por separado cada vez para comunicarse con los parámetros del servidor en el que se implementa el sistema, es decir, puede escalar este proceso solo a mano.
- Hay personas clave en el equipo de desarrollo: portadores de "conocimiento secreto" sobre el proyecto o sistema, y parecen únicos e irremplazables.
Esencialmente, cambiar a Kubernetes es una necesidad para las empresas que necesitan soportar sistemas de información en línea 24/7.
¿Por qué kubernetes?
Kubernetes no es la única alternativa para la integración y la implementación continuas (CI / CD). Pero fue Kubernetes el que se convirtió en el estándar de la industria para administrar sistemas que requieren alta disponibilidad.
Para nosotros, como desarrolladores, los argumentos decisivos a favor de Kubernetes son los siguientes:
- La plataforma se centra en aplicaciones, no en infraestructura.
- Kubernetes es conveniente para trabajar con un centro de datos, así como con varios, distribuidos en diferentes ciudades.
- Soporte de solución fácil a través de documentación clara y una comunidad activa.
- Configuración flexible de diferentes aplicaciones, distribución segura del tráfico.
- Soporte para contenedores Docker.
¿Cuáles son los beneficios del negocio de Kubernetes?
- Configuración flexible y proceso de actualización automatizado.
Usted mismo determina qué parte del sistema poner en operación comercial. Kubernetes te permite hacer un ciclo de lanzamiento corto. Todas las operaciones, desde el código fuente del sistema hasta el lanzamiento al entorno del producto, se realizan automáticamente. No necesita un equipo de ingenieros para que el sistema funcione. Las actualizaciones actuales no afectan el rendimiento del sistema y pueden llevarse a cabo en cualquier momento conveniente para los desarrolladores. - Colocación y escalado del sistema.
El sistema se puede colocar tanto en la potencia informática del cliente (o en el centro de datos) como en cualquier proveedor de la nube, por ejemplo, Amazon o Azure. Cualquier nivel de rendimiento y tolerancia a fallas se puede lograr fácilmente escalando el clúster. - Estandarización y auto documentación
La solución no requiere instrucciones. Se auto documenta y se empaqueta automáticamente en una unidad de uso: un contenedor. Describimos la configuración en Kubernetes como un plan / diagrama. No escribimos guiones que preparen el entorno, como era antes de Kubernetes. En cambio, pasamos a Kubernetes información (un diagrama) sobre cómo debería funcionar la solución. Y él mismo implementa este esquema.
Los desarrolladores ahora están escribiendo una aplicación para trabajar en un contenedor. Los ingenieros de DevOps escriben un diagrama de cómo debería funcionar una aplicación en un contenedor, y Kubernetes realiza las tareas de crear una solución.
La tecnología de Kubernetes está estandarizada. Le resultará fácil capacitar a un nuevo empleado en su sistema de liberación o transferir el sistema a un nuevo contratista.
La descripción final de la configuración que crea Kubernetes es también la documentación del sistema. De los nombres queda claro de inmediato qué parámetros están configurados y para qué sirven.
Debido a esto, la plataforma Kubernetes en su conjunto universaliza los lanzamientos, las actualizaciones y el lanzamiento de la aplicación.
- Prueba en vivo sin dolor
El proceso de probar la solución ha cambiado. Los desarrolladores pueden, bajo demanda, crear entornos que sean idénticos a los del producto para pruebas automatizadas. Y los registros generales de la aplicación y Kubernetes que trabajan con la aplicación ayudan a investigar problemas y encontrar errores aún más rápido.
Lo que requerirá una transición comercial a Kubernetes
Kubernetes solo será una pequeña parte de su nuevo sistema. Debe estar preparado para que Kubernetes sea una herramienta para estandarizar todo el ciclo de desarrollo, actualizar y publicar aplicaciones implicará un cambio en todo en el momento de la transición: arquitectura de software, proceso de desarrollo y mantenimiento de la infraestructura.
- Arquitectura de soluciones
Desde el punto de vista del producto, la transición es posible solo si el sistema se implementa o actualiza a una arquitectura de microservicio basada en servicios que se pueden empaquetar en contenedores (servicios sin estado). - Proceso de desarrollo
Desde el punto de vista del proceso de desarrollo, la transición implica principalmente un cambio de pensamiento. Cualquier mejora situacional y "muletas" agregadas en el último momento están completamente excluidas. Un desarrollador de soluciones de TI puede trabajar solo como un equipo, lo que inicialmente hace un producto descompuesto, compatible, compatible y inicialmente probado. Todo debe construirse lógicamente desde la primera línea de código hasta la operación. - Proceso de actualización
Incluso en la etapa de desarrollo de la arquitectura de la aplicación, debe pensar en cómo actualizar la solución sin detenerse. E inmediatamente comprenda cómo actualizará la base de datos, la API, cómo es lógico admitir varias versiones de la aplicación, teniendo en cuenta el hecho de que las personas trabajan con el sistema durante la actualización y pueden caer en diferentes versiones.
Y un pensamiento más está relacionado con el hecho de que cuando se cambia a Kubernetes, la infraestructura comienza a funcionar en modo de solo lectura, y para actualizar el sistema, debe crear nuevas versiones de las imágenes de la aplicación y decirle a Kubernetes que use la nueva versión, y luego apagará la versión anterior y se eliminará a sí mismo.
Para que las mejoras del sistema y los cambios en la tecnología del trabajo no puedan evitarse. Moverse no será rápido. Pero necesitará cambiar el paradigma solo una vez.
Caso. Cómo transferimos el sistema de microservicios a Kubernetes
Operamos en un entorno de producto una solución altamente cargada basada en la arquitectura de microservicios, que transmite más de 300 mil transacciones por día, y en las horas punta: 60-80 mil por hora. Actualizamos regularmente el producto, también hay versiones más urgentes que antes requerían suspender el sistema o parte de su funcionalidad por un tiempo.
Entramos en el entorno de la tienda de comestibles sin K8S, pero desarrollamos el sistema inicialmente con un ojo. Tomó 6 semanas traducir la solución a Kubernetes. Nos movimos en las siguientes direcciones:
1) Configuración de la tubería de implementación
a. Configurar la canalización para el ensamblaje continuo, las pruebas y la actualización de aplicaciones (CI / CD) en entornos de prueba.
b. Configure actualizaciones continuas en un entorno industrial.
c. Preparación y configuración del entorno lo más cerca posible del entorno industrial (preprod). Implementamos y probamos el clúster junto a las máquinas virtuales actuales.
d. Desarrollo de un plan de migración a un entorno industrial.
Entonces, todo parece ser simple, tenemos una tubería de CI / CD para todos los entornos y puede cambiar, ¡pero es demasiado pronto!
2) Selección de configuración de clúster
Pasamos un par de semanas seleccionando la configuración más estable de componentes y versiones del clúster de Kubernetes: sistema operativo + Docker + Kubernetes.
Probamos 3 configuraciones diferentes de sistemas operativos (Ubuntu, CentOS, últimas versiones de Oracle Linux). En cada sistema operativo, verificamos 2 versiones diferentes de Docker y Kubernetes, la que se entregó en las últimas versiones de los paquetes estándar del sistema operativo y la última versión del fabricante. Como resultado, las configuraciones de la distribución estándar de Oracle Linux mostraron la mayor estabilidad, y nos decidimos por ellas.
3) Configurar ajustes de contenedor
Dedicamos un poco más de tiempo a ajustar los parámetros del contenedor: configuramos los requisitos de memoria, disco y procesos.
Y solo después de que hicimos todo esto y probamos varios parámetros del funcionamiento del sistema (estabilidad, tolerancia a fallas y otros) en el preproceso bajo cargas cercanas a las de combate, y el sistema funcionó de manera estable, pasamos a la etapa final: migración.
Entonces todo fue simple.
Día C. Migración
Para la migración de combate, elegimos el tiempo con la carga mínima del sistema: el número mínimo de usuarios y la ausencia de una carga aumentada de acuerdo con el programa de trabajo interno de los algoritmos del sistema.
El tiempo de inactividad del sistema fue de aproximadamente una hora y prácticamente no afectó a los usuarios. La migración en sí consistió en cambiar a los usuarios de un sistema a otro y observar que todo salió bien.
La vida con kubernetes
Ahora el proceso de actualización no afecta el rendimiento del sistema, puede llevarse a cabo en cualquier momento conveniente para los desarrolladores y tiene el siguiente aspecto:
- Los desarrolladores hicieron una revisión, la probaron y enviaron el código a la publicación.
- El código se ensambló automáticamente, se empaquetó en imágenes acoplables y se publicó en un repositorio privado de acopladores.
- Kubernetes genera automáticamente nuevas versiones de servicios, verifica que los servicios funcionen correctamente, cambia a los usuarios para que usen nuevas versiones de servicios, detiene el trabajo de versiones antiguas y las elimina del clúster. La actualización ha tenido lugar.
Resumiendo nuestra experiencia
Necesitas Kubernetes si:
- Se requiere alta disponibilidad del sistema.
- El sistema se está desarrollando dinámicamente y debe realizar cambios en el entorno del producto con los ojos cerrados.
- Desea trabajar como un solo equipo desde el código hasta el entorno del producto.
- Está creando un sistema dinámico y en evolución que operará durante años.
Kubernetes es "costoso", ya que ingresar a la tecnología requerirá:
- Estudiar por desarrolladores de tecnologías relacionadas.
- Revisión de los procesos de diseño, desarrollo, implementación, pruebas y gestión ambiental.
- Experiencia en el funcionamiento de Kubernetes: ahora necesita supervisar no solo su sistema, sino también los servicios de aplicaciones de Kubernetes.
Paga a Kubernetes muy rápido:
- El procedimiento de actualización del sistema es mucho más simple y rápido. Los desarrolladores se liberan de todo un bloque de mano de obra.
- Cada nuevo especialista ingresará al proyecto ya sobre rieles.
- El transportador será transparente y automatizado.
- Su equipo repetirá la experiencia para otros sistemas.
- Actualizará el sistema sin ponerlo fuera de operación, lo que significa que no detendrá el negocio.
PD Consejos prácticos: divida la entrada a la tecnología en dos etapas: desarrollar un sistema con la arquitectura de microservicio adecuada y moverlo bajo el control de K8S. Por lo tanto, la transición bajo Kubernetes no se convertirá en una refactorización global.