Get best of the week

K8S Multicluster Journey

Hola Habr!

Representamos al equipo de la plataforma Exness. Anteriormente, nuestros colegas ya han escrito un artículo sobre imágenes listas para producción para k8 . Hoy queremos compartir la experiencia de la migración de servicios en Kubernetes.



Para comenzar, le ofrecemos algunos números para una mejor comprensión de lo que se discutirá:

  • 100+ , 10 QA, DevOps Scrum. — Python, PHP, C++, Java Golang. 
  • — 2000 . Rancher v1.6 VMware. 


Como dicen, nada dura para siempre, y Rancher ha anunciado el fin del soporte para la versión 1.6. Sí, durante más de tres años hemos aprendido cómo cocinarlo y resolver los problemas que surgen, pero cada vez más nos enfrentamos a problemas que nunca se solucionarán. Rancher 1.6 también tiene un sistema osificado para emitir derechos, donde puedes hacer casi todo o nada.

Virtualización propia, aunque proporcionaba un mayor control sobre el almacenamiento y la seguridad de los datos, pero imponía costos operativos, que eran difíciles de soportar con el crecimiento constante de la empresa, la cantidad de proyectos y los requisitos para ellos.

Queríamos seguir los estándares de IaC y, si es necesario, obtener el poder rápidamente, en cualquier ubicación geográfica y sin un bloqueo de proveedor, y también poder abandonarlos rápidamente.

Primeros pasos


En primer lugar, queríamos confiar en las tecnologías y soluciones modernas que permitirían a los equipos tener un ciclo de desarrollo más rápido y minimizar los costos operativos para la interacción con una plataforma que proporciona energía. 
 
Por supuesto, lo primero que se nos ocurrió fue Kubernetes, pero no nos emocionamos e investigamos un poco sobre el tema de la elección correcta. Evaluamos solo soluciones de código abierto, y Kubernetes derrotó incondicionalmente en una batalla injusta.  

Luego vino la cuestión de elegir una herramienta para crear clústeres. Comparamos las soluciones más populares: kops, kubespray, kubeadm.

Para empezar, kubeadm nos parecía una forma demasiado complicada, más bien, una especie de inventor de la "bicicleta", y kops carecía de flexibilidad.

Y salió el ganador:



Comenzamos a experimentar con nuestra propia virtualización y AWS, tratando de recrear una semejanza aproximada de nuestro patrón anterior de administración de recursos, donde todos usan el mismo "clúster". Y ahora tenemos el primer grupo de 10 máquinas virtuales pequeñas, algunas de las cuales están en AWS. Comenzamos a tratar de migrar equipos allí, todo parecía ser "bueno", y la historia podía terminar, pero ...

Primeros problemas


Resultable es en lo que se basa kubespray, no es la herramienta que permite seguir a IaC: algo salió mal durante la entrada / salida de los nodos, y se requirió alguna intervención, y al usar diferentes sistemas operativos, el libro de jugadas se comportó En maneras diferentes. Con el creciente número de comandos y nodos en el clúster, comenzamos a notar que el libro de jugadas tomó más y más tiempo, al final, nuestro récord fue de 3.5 horas, ¿y el suyo? :)

Y parece que kubespray es solo Ansible, y todo está claro a primera vista, pero:



Al comienzo del viaje, había una tarea para ejecutar capacidades solo en AWS y virtualización, pero luego, como sucede a menudo, los requisitos cambiaron.
 


A la luz de esto, quedó claro que nuestro viejo patrón de combinar recursos en un sistema de orquestación no era adecuado, en el caso de que los clústeres estén muy lejos y sean administrados por diferentes proveedores. 

Además. Cuando todos los equipos trabajan dentro del mismo clúster, varios servicios con NodeSelector instalado incorrectamente podrían volar al host "alienígena" de otro equipo y utilizar recursos allí, y en el caso de establecer contaminación, hubo constantes llamadas de que este o aquel servicio no funcionaba, no distribuido correctamente debido al factor humano. Otro problema fue el cálculo del costo, especialmente dados los problemas en la distribución de servicios por nodos.

Una historia separada fue la cuestión de los derechos de los empleados: cada equipo quería estar "a la cabeza" del clúster y administrarlo completamente, lo que podría causar un colapso completo, ya que los equipos son en su mayoría independientes entre sí.

Cómo ser


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 obtuvimos un segundo:



Y luego un tercer grupo: 



Entonces comenzamos a pensar: digamos, ¿en un año nuestros equipos tendrán más de un grupo? ¿En diferentes áreas 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 cualquier prueba. 



¡Llegaría Kubernetes lleno! Resulta que este es un tipo de MultiKubernetes. 

Al mismo tiempo, todos tendremos que admitir de alguna manera todos estos grupos, poder controlar fácilmente el acceso a ellos, así como crear nuevos y desmantelar los antiguos sin intervención manual.

Desde el comienzo de nuestro viaje en el mundo de Kubernetes, ha pasado un tiempo y decidimos volver a examinar las soluciones disponibles. Resultó que ya existe en el mercado - Rancher 2.2.



En la primera etapa de nuestra investigación, Rancher Labs ya realizó el primer lanzamiento de la versión 2, pero aunque podría generarse muy rápidamente ejecutando el contenedor sin dependencias externas con un par de parámetros o usando el Gráfico HELM oficial, nos pareció crudo, y no sabíamos si confíe en esta decisión, ya sea que se desarrolle o se abandone rápidamente. El paradigma cluster = clicks en sí mismo en la interfaz de usuario tampoco nos convenía, y no queríamos asociarnos a RKE, ya que esta es una herramienta bastante estrecha. 

La versión Rancher 2.2 ya tenía una apariencia más eficiente 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 único punto de distribución de derechos y archivos kubeconfig, el lanzamiento de una imagen kubectl con sus derechos en la interfaz de usuario, espacios de nombres anidados o proyectos. 

Ya se formó una comunidad alrededor de Rancher 2, y el proveedor HashiCorp Terraform fue creado para administrarlo, lo que nos ayudó a armar todo.

Que pasó


Como resultado, obtuvimos un pequeño clúster en el que se lanza Rancher, accesible a todos los otros clústeres, así como a muchos clústeres asociados con él, el acceso a cualquiera de los cuales se puede emitir simplemente agregando un usuario al directorio ldap, independientemente de dónde se encuentre. se encuentra y los recursos que utiliza el proveedor.

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 en estilo IaC, donde cada clúster es descrito por un repositorio, y su estado es versionado. En este caso, la mayoría de los módulos están conectados desde repositorios externos, de modo que solo queda transferir variables o describir su configuración personalizada para las instancias, lo que ayuda a reducir el porcentaje de repetibilidad del código.



Por supuesto, nuestro viaje está lejos de terminar y todavía hay muchas tareas interesantes por delante, como un solo punto de trabajo con los registros y las métricas de cualquier clúster, malla de servicio, gitops para administrar cargas en un multiclúster y mucho más. ¡Esperamos que te interese nuestra experiencia! 

El artículo fue escrito por A. Antipov, A. Ganush, Platform Engineers. 

More articles:


All Articles