Hola Habr!
Representem l'equip de la plataforma Exness. Anteriorment, els nostres companys ja van escriure un article sobre . Avui volem compartir la nostra experiència de migració de serveis a Kubernetes.
Per començar, us oferim alguns números per a una millor comprensió del que es parlarà:
- El nostre departament de desenvolupament consta de més de 100 persones, inclosos més de 10 equips diferents amb processos de control de qualitat, DevOps i Scrum autosuficients. Pila de desenvolupament: Python, PHP, C++, Java i Golang.
- La mida dels entorns de prova i producció és d'uns 2000 contenidors cadascun. Estan executant Rancher v1.6 amb la seva pròpia virtualització i sota VMware.
RњRѕS, ReRІR ° C † ReSЏ
Com diuen, res dura per sempre, i Rancher va anunciar el final del suport per a la versió 1.6 fa força temps. Sí, en més de tres anys hem après a preparar-lo i resoldre els problemes que sorgeixen, però cada cop més sovint ens trobem davant de problemes que mai es corregiran. Rancher 1.6 també té un sistema ossificat per emetre drets, on podeu fer gairebé tot o res.
Tot i que la virtualització propietària proporcionava un major control sobre l'emmagatzematge de dades i la seva seguretat, imposava uns costos operatius difícils d'acceptar donat el creixement constant de l'empresa, el nombre de projectes i els requisits per a aquests.
Volíem seguir els estàndards IaC i, si calia, obtenir capacitat ràpidament, en qualsevol ubicació geogràfica i sense bloqueig de proveïdor, i també poder abandonar-la ràpidament.
Primers passos
En primer lloc, volíem confiar en tecnologies i solucions modernes que permetessin als equips tenir un cicle de desenvolupament més ràpid i minimitzar els costos operatius per interactuar amb la plataforma que proporciona energia.
Per descomptat, el primer que ens va venir al cap va ser Kubernetes, però no ens vam emocionar i vam investigar una mica per veure si era l'opció correcta. Només vam avaluar solucions de codi obert i, en una batalla injusta, Kubernetes va guanyar incondicionalment.
Després va venir la qüestió de triar una eina per crear clústers. Hem comparat les solucions més populars: kops, kubespray, kubeadm.
Per començar, kubeadm ens va semblar un camí massa complicat, més aviat com una mena d'inventor d'una "bicicleta", i kops no tenia prou flexibilitat.
I el guanyador va ser:
Vam començar a experimentar amb la nostra pròpia virtualització i AWS, intentant recrear alguna cosa aproximadament semblant al nostre patró de gestió de recursos anterior, on tothom compartia el mateix "clúster". I ara tenim el nostre primer clúster de 10 petites màquines virtuals, un parell de les quals es troben a AWS. Vam començar a intentar migrar equips allà, tot semblava que anava "bo", i la història es podia acabar, però...
Primers problemes
Ansible és el que es basa kubespray, no és una eina que us permeti seguir IaC: quan es posaven en marxa/desmanten els nodes, alguna cosa va anar malament constantment i es va requerir algun tipus d'intervenció, i quan s'utilitzaven diferents sistemes operatius, el llibre de jugades es va comportar de manera diferent. . A mesura que creixia el nombre d'equips i nodes del clúster, vam començar a notar que el llibre de jugades trigava més i més a completar-se i, com a resultat, el nostre rècord va ser de 3,5 hores, què passa amb el vostre? 🙂
I sembla que kubespray és només Ansible, i tot està clar a primera vista, però:
Al començament del viatge, la tasca era llançar capacitats només en AWS i en virtualització, però després, com passa sovint, els requisits van canviar.
A la llum d'això, va quedar clar que el nostre vell patró de combinar recursos en un sistema d'orquestració no era adequat, en el cas en què els clústers són molt remots i estan gestionats per diferents proveïdors.
A més. Quan tots els equips treballen dins del mateix clúster, diversos serveis amb NodeSelectors instal·lats incorrectament podrien volar a l'amfitrió "estranger" d'un altre equip i utilitzar-hi recursos, i si s'establia taint, hi havia sol·licituds constants que un o un altre servei no funcionava. no es distribueixen correctament a causa del factor humà. Un altre problema va ser calcular el cost, sobretot tenint en compte els problemes de distribució de serveis entre nodes.
Una història a part va ser l'emissió de drets als empleats: cada equip volia estar "al capdavant" del clúster i gestionar-lo completament, cosa que podria provocar un col·lapse total, ja que els equips són bàsicament independents entre si.
Què fer?
Tenint en compte l'anterior i els desitjos dels equips de ser més independents, vam treure una conclusió senzilla: un equip - un clúster.
Així que en tenim una segona:
I després el tercer grup:
Llavors vam començar a pensar: diguem que d'aquí a un any els nostres equips tindran més d'un clúster? En diferents àrees geogràfiques, per exemple, o sota el control de diferents proveïdors? I alguns d'ells voldran poder desplegar ràpidament un clúster temporal per a algunes proves.
Vindria Kubernetes complet! Resulta que això és una mena de MultiKubernetes.
Al mateix temps, tots haurem de mantenir d'alguna manera tots aquests clústers, poder gestionar fàcilment l'accés als mateixos, així com crear-ne de nous i desactivar els antics sense intervenció manual.
Ha passat un temps des de l'inici del nostre viatge al món de Kubernetes i vam decidir tornar a examinar les solucions disponibles. Va resultar que ja existeix al mercat: Rancher 2.2.
En la primera etapa de la nostra investigació, Rancher Labs ja havia fet el primer llançament de la versió 2, però tot i que es podia plantejar molt ràpidament llançant un contenidor sense dependències externes amb un parell de paràmetres o utilitzant el gràfic oficial HELM, semblava cru. a nosaltres, i no sabíem si podríem confiar en aquesta decisió si es desenvoluparà o s'abandonarà ràpidament. El paradigma de clúster = clics a la interfície d'usuari en si no ens va bé, i no volíem lligar-nos a RKE, ja que és una eina molt enfocada.
La versió Rancher 2.2 ja tenia un aspecte més viable i, juntament amb les anteriors, tenia un munt de característiques interessants fora de la caixa, com ara la integració amb molts proveïdors externs, un únic punt de distribució de drets i fitxers kubeconfig, llançament d'un kubectl. imatge amb els vostres drets a la interfície d'usuari, espais de noms imbricats també coneguts com a projectes.
També hi havia una comunitat ja formada al voltant de Rancher 2, i es va crear un proveïdor anomenat HashiCorp Terraform per gestionar-lo, que ens va ajudar a armar-ho tot.
Què va passar
Com a resultat, vam acabar amb un petit clúster que executava Rancher, accessible per a tots els altres clústers, així com molts clústers connectats a ell, l'accés a qualsevol dels quals es pot concedir tan sols com afegir un usuari al directori ldap, independentment de on es troba i quins recursos del proveïdor utilitza.
Amb gitlab-ci i Terraform, es va crear un sistema que permet crear un clúster de qualsevol configuració en proveïdors de núvol o la nostra pròpia infraestructura i connectar-los a Rancher. Tot això es fa a l'estil IaC, on cada clúster és descrit per un repositori, i el seu estat es versiona. Al mateix temps, la majoria dels mòduls estan connectats des de repositoris externs, de manera que només queda passar variables o descriure la vostra configuració personalitzada per a instàncies, cosa que ajuda a reduir el percentatge de repetició de codi.
Per descomptat, el nostre viatge està lluny d'haver acabat i encara queden moltes tasques interessants per davant, com ara un únic punt de treball amb registres i mètriques de qualsevol clúster, malla de servei, gitops per gestionar les càrregues en un multiclúster i molt més. Esperem que trobeu interessant la nostra experiència!
L'article va ser escrit per A. Antipov, A. Ganush, enginyers de plataforma.
Font: www.habr.com