Ola Habr!
Representamos ao equipo da plataforma Exness. Anteriormente, os nosos compañeiros xa escribiron un artigo sobre . Hoxe queremos compartir a nosa experiencia de migrar servizos a Kubernetes.
Para comezar, ofrecémosche algúns números para comprender mellor o que se tratará:
- O noso departamento de desenvolvemento está composto por máis de 100 persoas, incluíndo máis de 10 equipos diferentes con procesos de control de calidade, DevOps e Scrum autosuficientes. Pila de desenvolvemento: Python, PHP, C++, Java e Golang.
- O tamaño dos ambientes de proba e produción é duns 2000 contedores cada un. Están executando Rancher v1.6 na súa propia virtualización e baixo VMware.
Motivación
Como din, nada dura para sempre, e Rancher anunciou o fin do soporte para a versión 1.6 hai moito tempo. Si, en máis de tres anos aprendemos a preparalo e a resolver os problemas que xurden, pero cada vez nos atopamos con problemas que nunca serán corrixidos. Rancher 1.6 tamén ten un sistema osificado para emitir dereitos, onde podes facer case todo ou nada.
Aínda que a virtualización propietaria proporcionaba un maior control sobre o almacenamento de datos e a súa seguridade, impoñía uns custos operativos difíciles de aceptar dado o constante crecemento da empresa, o número de proxectos e os requisitos para os mesmos.
Queriamos seguir os estándares de IaC e, se é necesario, obter capacidade rapidamente, en calquera localización xeográfica e sen bloqueo de vendedores, e tamén poder abandonala rapidamente.
Primeiros Pasos
En primeiro lugar, queriamos confiar en tecnoloxías e solucións modernas que permitisen aos equipos ter un ciclo de desenvolvemento máis rápido e minimizar os custos operativos para interactuar coa plataforma que proporciona enerxía.
Por suposto, o primeiro que se nos ocorreu foi Kubernetes, pero non nos emocionamos e investigamos un pouco para ver se era a opción correcta. Avaliamos só solucións de código aberto e, nunha batalla inxusta, Kubernetes gañou incondicionalmente.
A continuación veu a cuestión de escoller unha ferramenta para crear clusters. Comparamos as solucións máis populares: kops, kubespray, kubeadm.
Para comezar, kubeadm pareceunos un camiño demasiado complicado, máis ben como unha especie de inventor dunha "bicicleta", e kops non tiña a flexibilidade suficiente.
E o gañador foi:
Comezamos a experimentar coa nosa propia virtualización e AWS, tentando recrear algo máis ou menos similar ao noso patrón de xestión de recursos anterior, onde todos compartían o mesmo "clúster". E agora temos o noso primeiro clúster de 10 pequenas máquinas virtuais, un par delas situadas en AWS. Comezamos a tentar migrar equipos alí, todo parecía "ben" e a historia podía estar rematada, pero...
Primeiros problemas
Ansible é no que está construído kubespray, non é unha ferramenta que che permita seguir IaC: ao poñer en funcionamento/desmantelar os nodos, algo saíu mal constantemente e requiriuse algún tipo de intervención, e ao usar diferentes sistemas operativos, o manual de xogos comportouse de forma diferente. . A medida que creceu o número de equipos e nodos do clúster, comezamos a notar que o libro de xogos estaba tardando máis e máis tempo en completarse e, como resultado, o noso rexistro era de 3,5 horas, e o teu? 🙂
E parece que kubespray é só Ansible, e todo está claro a primeira vista, pero:
Ao comezo da viaxe, a tarefa consistía en lanzar capacidades só en AWS e na virtualización, pero despois, como adoita suceder, os requisitos cambiaron.
Tendo en conta isto, quedou claro que o noso antigo patrón de combinar recursos nun só sistema de orquestración non era o adecuado, no caso de que os clústeres sexan moi remotos e sexan xestionados por diferentes provedores.
Máis aínda máis. Cando todos os equipos traballan dentro do mesmo clúster, varios servizos con NodeSelectors instalados incorrectamente podían voar ao host "estranxeiro" doutro equipo e utilizar os recursos alí, e, se se definiu a mancha, había solicitudes constantes de que un ou outro servizo non funcionaba. non se distribúen correctamente debido ao factor humano. Outro problema foi o cálculo do custo, especialmente tendo en conta os problemas na distribución dos servizos entre nós.
Unha historia aparte foi a emisión de dereitos aos empregados: cada equipo quería estar "á cabeza" do clúster e xestionalo completamente, o que podería provocar un colapso total, xa que os equipos son basicamente independentes entre si.
¿Que facer?
Tendo en conta o anterior e os desexos dos equipos de ser máis independentes, fixemos unha conclusión sinxela: un equipo - un cluster.
Entón temos unha segunda:
E despois o terceiro grupo:
Entón comezamos a pensar: digamos que nun ano os nosos equipos terán máis dun cluster? En diferentes áreas xeográficas, por exemplo, ou baixo o control de diferentes provedores? E algúns deles quererán poder implantar rapidamente un clúster temporal para algunhas probas.
Chegaría Kubernetes completo! Isto é unha especie de MultiKubernetes, ao parecer.
Ao mesmo tempo, todos necesitaremos manter dalgún xeito todos estes clusters, poder xestionar facilmente o acceso a eles, así como crear outros novos e desmantelar os antigos sen intervención manual.
Xa pasou algún tempo dende o inicio da nosa viaxe no mundo de Kubernetes, e decidimos volver examinar as solucións dispoñibles. Resultou que xa existe no mercado - Rancher 2.2.
Na primeira fase da nosa investigación, Rancher Labs xa fixera o primeiro lanzamento da versión 2, pero aínda que se podía levantar moi rapidamente lanzando un contedor sen dependencias externas cun par de parámetros ou utilizando o gráfico oficial HELM, pareceume tosco. a nós, e non sabiamos se poderiamos confiar nesta decisión se se desenvolverá ou se abandonará rapidamente. O paradigma clúster = clics na propia IU tampouco nos conveña, e non queriamos vincularnos a RKE, xa que é unha ferramenta moi limitada.
A versión Rancher 2.2 xa tiña un aspecto máis viable e, xunto coas anteriores, tiña unha morea de características interesantes fóra da caixa, como a integración con moitos provedores externos, un único punto de distribución de dereitos e ficheiros kubeconfig, o lanzamento dun kubectl. imaxe cos teus dereitos na IU, espazos de nomes anidados tamén coñecidos como proxectos.
Tamén había unha comunidade xa formada ao redor de Rancher 2, e creouse un provedor chamado HashiCorp Terraform para xestionalo, que nos axudou a xuntar todo.
Que pasou
Como resultado, acabamos cun pequeno clúster que executaba Rancher, accesible para todos os outros clústeres, así como para moitos clústeres conectados a el, o acceso a calquera dos cales se pode conceder simplemente como engadir un usuario ao directorio ldap, independentemente de onde se atopa e os recursos do provedor que utiliza.
Usando gitlab-ci e Terraform, creouse un sistema que permite crear un clúster de calquera configuración en provedores de nube ou a nosa propia infraestrutura e conectalos a Rancher. Todo isto faise no estilo IaC, onde cada clúster é descrito por un repositorio, e o seu estado é versionado. Ao mesmo tempo, a maioría dos módulos están conectados desde repositorios externos, polo que só queda pasar variables ou describir a súa configuración personalizada para as instancias, o que axuda a reducir a porcentaxe de repetición de código.
Por suposto, a nosa viaxe está lonxe de rematar e aínda quedan moitas tarefas interesantes por diante, como un único punto de traballo con rexistros e métricas de calquera clúster, malla de servizo, gitops para xestionar cargas nun multicluster e moito máis. Esperamos que vos resulte interesante a nosa experiencia!
O artigo foi escrito por A. Antipov, A. Ganush, Platform Engineers.
Fonte: www.habr.com