¡Hola, Habr!
Representamos al equipo de la plataforma Exness. Anteriormente, nuestros compañeros ya escribieron un artículo sobre . Hoy queremos compartir nuestra experiencia de migración de servicios a Kubernetes.
Para empezar, te ofrecemos algunos números para una mejor comprensión de lo que se tratará:
- Nuestro departamento de desarrollo está formado por más de 100 personas, incluidos más de 10 equipos diferentes con procesos de control de calidad, DevOps y Scrum autosuficientes. Pila de desarrollo: Python, PHP, C++, Java y Golang.
- El tamaño de los entornos de prueba y producción es de aproximadamente 2000 contenedores cada uno. Están ejecutando Rancher v1.6 en su propia virtualización y bajo VMware.
Motivación
Como dicen, nada dura para siempre, y Rancher anunció el fin del soporte para la versión 1.6 hace bastante tiempo. Sí, en más de tres años hemos aprendido a prepararlo y solucionar los problemas que surgen, pero cada vez más nos enfrentamos a problemas que nunca se corregirán. Rancher 1.6 también tiene un sistema osificado para emitir derechos, donde puedes hacer casi todo o nada.
Si bien la virtualización propietaria proporcionó un mayor control sobre el almacenamiento de datos y su seguridad, impuso costos operativos difíciles de aceptar dado el constante crecimiento de la empresa, la cantidad de proyectos y los requisitos para los mismos.
Queríamos seguir los estándares de IaC y, si fuera necesario, obtener capacidad rápidamente, en cualquier ubicación geográfica y sin bloqueo de proveedor, y también poder abandonarla rápidamente.
Primeros pasos
En primer lugar, queríamos confiar en tecnologías y soluciones modernas que permitieran a los equipos tener un ciclo de desarrollo más rápido y minimizar los costos operativos para interactuar con la plataforma que proporciona energía.
Por supuesto, lo primero que nos vino a la mente fue Kubernetes, pero no nos entusiasmamos e investigamos un poco para ver si era la elección correcta. Evaluamos solo soluciones de código abierto y, en una batalla injusta, Kubernetes ganó incondicionalmente.
Luego vino la cuestión de elegir una herramienta para crear clusters. Comparamos las soluciones más populares: kops, kubespray, kubeadm.
Para empezar, kubeadm nos parecía un camino demasiado complicado, más bien como una especie de inventor de una “bicicleta”, y kops no tenía suficiente flexibilidad.
Y el ganador fue:
Comenzamos a experimentar con nuestra propia virtualización y AWS, tratando de recrear algo más o menos similar a nuestro patrón de administración de recursos anterior, donde todos compartían el mismo "clúster". Y ahora tenemos nuestro primer grupo de 10 máquinas virtuales pequeñas, algunas de las cuales están ubicadas en AWS. Empezamos a intentar migrar equipos allí, todo parecía estar “bien”, y la historia se podía terminar, pero...
Primeros problemas
Ansible es en lo que se basa kubespray, no es una herramienta que le permite seguir IaC: al poner en servicio/desmantelar nodos, algo salía constantemente mal y se requería algún tipo de intervención, y cuando se usaban diferentes sistemas operativos, el libro de jugadas se comportaba de manera diferente. . A medida que crecía el número de equipos y nodos en el clúster, comenzamos a notar que el libro de jugadas tardaba cada vez más en completarse y, como resultado, nuestro récord fue de 3,5 horas, ¿qué pasa con el suyo? 🙂
Y parece que Kubespray es simplemente Ansible, y todo está claro a primera vista, pero:
Al comienzo del viaje, la tarea era lanzar capacidades solo en AWS y en virtualización, pero luego, como suele suceder, los requisitos cambiaron.
A la luz de esto, quedó claro que nuestro antiguo patrón de combinar recursos en un sistema de orquestación no era adecuado, en el caso de que los clústeres sean muy remotos y sean administrados por diferentes proveedores.
Además. Cuando todos los equipos trabajan dentro del mismo clúster, varios servicios con NodeSelectors instalados incorrectamente podrían volar al host "extranjero" de otro equipo y utilizar recursos allí, y si se configuraba la contaminación, había solicitudes constantes de que uno u otro servicio no estaba funcionando. no distribuido correctamente debido al factor humano. Otro problema fue calcular el costo, especialmente considerando los problemas en la distribución de servicios entre nodos.
Una historia aparte fue la concesión de derechos a los empleados: cada equipo quería estar "a la cabeza" del clúster y gestionarlo por completo, lo que podría provocar un colapso total, ya que los equipos son básicamente independientes entre sí.
¿Qué hacer?
Teniendo en cuenta lo anterior y los deseos de los equipos de ser más independientes, llegamos a una conclusión simple: un equipo, un grupo.
Entonces tenemos un segundo:
Y luego el tercer grupo:
Entonces empezamos a pensar: digamos que en un año nuestros equipos tendrán más de un clúster. ¿En diferentes zonas geográficas, por ejemplo, o bajo el control de diferentes proveedores? Y algunos de ellos querrán poder implementar rápidamente un clúster temporal para algunas pruebas.
¡Vendría Kubernetes completo! Resulta que se trata de una especie de MultiKubernetes.
Al mismo tiempo, todos necesitaremos mantener de alguna manera todos estos clústeres, poder gestionar fácilmente el acceso a ellos, así como crear otros nuevos y desmantelar los antiguos sin intervención manual.
Ha pasado algún tiempo desde el inicio de nuestro viaje en el mundo de Kubernetes y decidimos reexaminar las soluciones disponibles. Resultó que ya existe en el mercado: Rancher 2.2.
En la primera etapa de nuestra investigación, Rancher Labs ya había realizado el primer lanzamiento de la versión 2, pero aunque se podía plantear muy rápidamente lanzando un contenedor sin dependencias externas con un par de parámetros o usando el HELM Chart oficial, parecía tosco. para nosotros, y no sabíamos si podíamos confiar en esta decisión, si se desarrollaría o se abandonaría rápidamente. El paradigma cluster = clicks en la interfaz de usuario tampoco nos convenía y no queríamos vincularnos a RKE, ya que es una herramienta con un enfoque bastante limitado.
La versión Rancher 2.2 ya tenía una apariencia más funcional y, junto con las anteriores, tenía un montón de características interesantes listas para usar, como la integración con muchos proveedores externos, un punto único de distribución de derechos y archivos kubeconfig, el lanzamiento de kubectl. Imagen con sus derechos en la interfaz de usuario, espacios de nombres anidados, también conocidos como proyectos.
También ya se había formado una comunidad en torno a Rancher 2, y se creó un proveedor llamado HashiCorp Terraform para administrarla, lo que nos ayudó a armar todo.
Qué pasó
Como resultado, terminamos con un pequeño clúster ejecutando Rancher, accesible a todos los demás clústeres, así como a muchos clústeres conectados a él, y el acceso a cualquiera de ellos se puede otorgar tan simplemente como agregar un usuario al directorio ldap, independientemente de dónde está ubicado y qué recursos del proveedor utiliza.
Usando gitlab-ci y Terraform, se creó un sistema que le permite crear un clúster de cualquier configuración en proveedores de nube o nuestra propia infraestructura y conectarlos a Rancher. Todo esto se hace al estilo IaC, donde cada clúster se describe mediante un repositorio y su estado está versionado. Al mismo tiempo, la mayoría de los módulos se conectan desde repositorios externos por lo que solo queda pasar variables o describir su configuración personalizada para instancias, lo que ayuda a reducir el porcentaje de repetición de código.
Por supuesto, nuestro viaje está lejos de terminar y todavía quedan muchas tareas interesantes por delante, como un punto de trabajo único con registros y métricas de cualquier clúster, malla de servicios, gitops para administrar cargas en un multiclúster y mucho más. ¡Esperamos que nuestra experiencia te resulte interesante!
El artículo fue escrito por A. Antipov, A. Ganush, ingenieros de plataforma.
Fuente: habr.com