Hola a tots! Em dic Pavel Agaletsky. Treballo com a líder d'equip en un equip que desenvolupa el sistema de lliurament Lamoda. El 2018 vaig parlar a la conferència HighLoad ++ i avui vull presentar una transcripció del meu informe.

El meu tema està dedicat a l'experiència de la nostra empresa en el desplegament de sistemes i serveis a diferents entorns. A partir dels nostres temps prehistòrics, quan vam desplegar tots els sistemes en servidors virtuals normals, acabant amb una transició gradual del desplegament de Nomad a Kubernetes. Us explicaré per què ho hem fet i quins problemes hem tingut en el procés.

Desplegueu aplicacions a la VM

Comencem pel fet que fa 3 anys tots els sistemes i serveis de l'empresa es van desplegar en servidors virtuals normals. Tècnicament, s'organitzava de manera que tot el codi dels nostres sistemes es trobava i s'assemblava mitjançant eines de muntatge automàtiques, utilitzant jenkins. Amb l'ajuda d'Ansible, ja es va implementar des del nostre sistema de control de versions als servidors virtuals. Al mateix temps, cada sistema que hi havia a la nostra empresa es va desplegar en almenys 2 servidors: un d'ells - al capdavant, el segon - a la cua. Aquests dos sistemes eren absolutament idèntics entre ells en tots els seus paràmetres, potència, configuració, etc. L'única diferència entre ells va ser que el cap rebia trànsit d'usuaris, mentre que tail mai va rebre trànsit d'usuaris per si mateix.

Per a què va ser?

Quan vam desplegar noves versions de la nostra aplicació, volíem poder desplegar-se sense problemes, és a dir, sense conseqüències perceptibles per als usuaris. Això es va aconseguir a causa del fet que la següent versió compilada amb Ansible es va llançar a la cua. Allà, les persones que van participar en el desplegament van poder comprovar i assegurar-se que tot està bé: totes les mètriques, seccions i aplicacions funcionen; s'inicien els scripts necessaris. Només després d'estar convençuts que tot estava bé, el trànsit va canviar. Va començar a anar al servidor que abans era cua. I el que abans era el cap es va quedar sense trànsit d'usuaris, mentre que amb la versió anterior de la nostra aplicació disponible en ell.

Així que va ser perfecte per als usuaris. Perquè la commutació és instantània, ja que només és una commutació d'equilibrador. És molt fàcil tornar a la versió anterior simplement tornant a canviar l'equilibrador. També podríem assegurar-nos que l'aplicació estigués preparada per a la producció fins i tot abans que el trànsit d'usuaris hi arribés, cosa que era força convenient.

Quines virtuts hi veiem en tot això?

1. En primer lloc, n'hi ha prou només funciona. Tothom entén com funciona aquest esquema de desplegament, perquè la majoria de la gent s'ha implementat mai a servidors virtuals normals.
2. Amb això n'hi ha prou de forma segura, ja que la tecnologia de desplegament és senzilla, provada per milers d'empreses. Milions de servidors es despleguen d'aquesta manera. És difícil trencar alguna cosa.
3. I finalment vam poder aconseguir desplegaments atòmics. Desplegaments que es produeixen simultàniament per als usuaris, sense una etapa notable de canvi entre la versió antiga i la nova.

Però també hem vist diverses mancances en tot això:

1. A més de l'entorn de producció, l'entorn de desenvolupament, hi ha altres entorns. Per exemple, qa i preproducció. En aquell moment, teníem molts servidors i uns 60 serveis. Per aquest motiu va haver de fer-ho per a cada servei, mantingueu la versió més recent màquina virtual. A més, si voleu actualitzar biblioteques o instal·lar noves dependències, heu de fer-ho en tots els entorns. També va ser necessari sincronitzar l'hora en què vas a desplegar la següent versió nova de la teva aplicació amb l'hora en què devops realitza la configuració d'entorn necessària. En aquest cas, és fàcil arribar a una situació en què el nostre entorn serà una mica diferent alhora en tots els entorns seguits. Per exemple, en un entorn de control de qualitat hi haurà algunes versions de biblioteques i, en producció, d'altres, la qual cosa comportarà problemes.
2. Dificultat per actualitzar dependències la teva aplicació. No depèn de tu, sinó de l'altre equip. És a dir, de l'equip devops que manté els servidors. Hauríeu de donar-los una tasca adequada i descriure el que voleu fer.
3. Aleshores també volíem dividir els grans monòlits que teníem en petits serveis separats, ja que enteníem que cada cop n'hi hauria més. Aleshores, ja en teníem més de 100. Calia crear una màquina virtual nova per a cada nou servei, que també calia donar-hi servei i desplegar. A més, no necessiteu un cotxe, sinó almenys dos. A tot això s'afegeix un entorn de control de qualitat. Això causa problemes i dificulta la creació i l'execució de nous sistemes. procés complex, costós i llarg.

Per tant, vam decidir que seria més convenient passar de desplegar màquines virtuals normals a desplegar les nostres aplicacions en un contenidor docker. Si teniu Docker, necessiteu un sistema que pugui executar l'aplicació en un clúster, ja que no podeu crear un contenidor així. Normalment es vol fer un seguiment de quants contenidors s'aixequen perquè s'aixequin automàticament. Per aquest motiu, hem hagut de triar un sistema de control.

Vam pensar molt i molt sobre quin agafar. El cas és que en aquell moment aquesta pila de desplegament als servidors virtuals ordinaris estava una mica obsoleta, ja que no existien les últimes versions dels sistemes operatius. En algun moment, fins i tot FreeBSD hi va ser, cosa que no era molt convenient de donar suport. Vam entendre que havíem de migrar a Docker el més aviat possible. Els nostres devops van analitzar la seva experiència amb diferents solucions i van triar un sistema com Nomad.

Canvi a Nomad

Nomad és un producte de HashiCorp. També són coneguts per les seves altres solucions:

cònsol és una eina per a la descoberta de serveis.

"Terraforma" - un sistema de gestió de servidors que permet configurar-los mitjançant una configuració, l'anomenada infrastructure-as-a-code.

Vagabund permet desplegar màquines virtuals localment o al núvol mitjançant fitxers de configuració específics.

Nomad en aquell moment semblava una solució bastant senzilla a la qual podeu canviar ràpidament sense canviar tota la infraestructura. A més, és bastant fàcil d'aprendre. Per tant, l'hem escollit com a sistema de filtrat per al nostre contenidor.

Què necessites per implementar el teu sistema a Nomad?

1. En primer lloc, cal imatge docker la teva aplicació. Heu de crear-lo i posar-lo a la botiga d'imatges de Docker. En el nostre cas, això és un artefacte: un sistema que us permet introduir-hi diversos artefactes de diversos tipus. Pot emmagatzemar arxius, imatges docker, paquets de compositor PHP, paquets NPM, etc.
2. També cal fitxer de configuració, que dirà a Nomad què, on i quant voleu desplegar.

Quan parlem de Nomad, utilitza el llenguatge HCL com a format de fitxer d'informació, que significa Llenguatge de configuració HashiCorp. És un superconjunt de Yaml que us permet descriure el vostre servei en termes de Nomad.

Permet dir quants contenidors voleu desplegar, des de quines imatges transferir-hi diversos paràmetres durant el desplegament. Per tant, alimenteu aquest fitxer a Nomad i llança contenidors a la producció d'acord amb això.

En el nostre cas, ens vam adonar que escriure exactament els mateixos fitxers HCL idèntics per a cada servei no seria gaire convenient, perquè hi ha molts serveis i, de vegades, voleu actualitzar-los. Succeeix que un servei no es desplega en una instància, sinó en una varietat de diferents. Per exemple, un dels sistemes que tenim en producció té més de 100 instàncies en producció. S'executen a partir de les mateixes imatges, però difereixen en la configuració i els fitxers de configuració.

Per tant, vam decidir que ens seria convenient emmagatzemar tots els nostres fitxers de configuració per al desplegament en un dipòsit comú. D'aquesta manera es feien visibles: eren fàcils de mantenir i es podia veure quin tipus de sistemes tenim. Si cal, també és fàcil actualitzar o canviar alguna cosa. Afegir un nou sistema tampoc és difícil: només cal afegir un fitxer de configuració dins del nou directori. En el seu interior hi ha fitxers: service.hcl, que conté una descripció del nostre servei, i alguns fitxers env que permeten configurar aquest mateix servei, que s'està desplegant en producció.

Tanmateix, alguns dels nostres sistemes es despleguen en producció no en una còpia, sinó en diverses alhora. Per tant, vam decidir que ens seria convenient emmagatzemar no les configuracions en la seva forma pura, sinó la seva forma de plantilla. I com a llenguatge de plantilla que hem escollit jinja 2. En aquest format, emmagatzemem tant les configuracions del propi servei com els fitxers env necessaris per a això.

A més, hem col·locat al repositori un script de desplegament que és comú per a tots els projectes, que permet llançar i desplegar el teu servei en producció, en l'entorn adequat, en el target adequat. En el cas que vam convertir la nostra configuració HCL en una plantilla, llavors el fitxer HCL, que abans era la configuració habitual de Nomad, en aquest cas va començar a semblar una mica diferent.

És a dir, hem substituït algunes variables de lloc de configuració per insercions de variables que es prenen dels fitxers env o d'altres fonts. A més, tenim la possibilitat de crear fitxers HCL de manera dinàmica, és a dir, podem utilitzar no només les insercions de variables habituals. Com que jinja admet cicles i condicions, també podeu posar-hi fitxers de configuració, que canvien en funció d'on exactament desplegueu les vostres aplicacions.

Per exemple, voleu implementar el vostre servei a la preproducció i la producció. Suposem que en preproducció no voleu executar scripts cron, sinó que només voleu veure el servei en un domini separat per assegurar-vos que s'està executant. Per a qualsevol persona que implementi un servei, el procés és molt senzill i transparent. N'hi ha prou amb executar el fitxer deploy.sh, especificar quin servei voleu desplegar i a quin objectiu. Per exemple, voleu desplegar algun sistema a Rússia, Bielorússia o Kazakhstan. Per fer-ho, només cal canviar un dels paràmetres, i tindreu el fitxer de configuració correcte.

Quan el servei Nomad ja està desplegat al vostre clúster, sembla aquest.

Per començar, necessiteu un equilibrador de càrrega des de l'exterior, que prendrà tot el trànsit d'usuaris en si mateix. Treballarà conjuntament amb Consul i aprendrà d'ell on, en quin node, a quina adreça IP es troba un servei concret, que correspon a un nom de domini concret. Els serveis a Cònsol provenen del mateix Nomad. Com que es tracta de productes de la mateixa empresa, estan ben connectats. Podem dir que Nomad és capaç de registrar tots els serveis llançats en ella dins de Cònsol.

Un cop el vostre equilibrador extern sap a quin servei enviar trànsit, el redirigeix ​​al contenidor adequat o a diversos contenidors que coincideixin amb la vostra aplicació. Naturalment, també cal pensar en la seguretat. Tot i que tots els serveis s'executen a les mateixes màquines virtuals en contenidors, això sol requerir que qualsevol servei tingui accés gratuït a qualsevol altre. Això ho hem aconseguit mitjançant la segmentació. Cada servei es va llançar a la seva pròpia xarxa virtual, en la qual s'escrivien regles d'encaminament i regles per permetre/negar l'accés a altres sistemes i serveis. Podrien estar tant dins d'aquest clúster com fora d'ell. Per exemple, si voleu evitar que un servei es connecti a una base de dades concreta, això es pot fer mitjançant la segmentació a nivell de xarxa. És a dir, fins i tot per error, no us podeu connectar accidentalment des de l'entorn de prova a la vostra base de producció.

Quant ens ha costat la transició en recursos humans?

Aproximadament 5-6 mesos va trigar la transició de tota l'empresa a Nomad. Ens vam moure servei per servei, però a un ritme força ràpid. Cada equip havia de crear els seus propis contenidors de servei.

Hem adoptat aquest enfocament que cada equip és responsable de les imatges docker dels seus sistemes de manera independent. Els Devops, en canvi, proporcionen la infraestructura general necessària per al desplegament, és a dir, suport per al propi clúster, suport per al sistema CI, etc. I en aquell moment, teníem més de 60 sistemes traslladats a Nomad, que van resultar ser uns 2 mil contenidors.

DevOps és responsable de la infraestructura global de tot allò relacionat amb el desplegament, amb servidors. I cada equip de desenvolupament, al seu torn, s'encarrega d'implementar contenidors per al seu sistema específic, ja que és l'equip qui sap què necessita generalment en un contenidor concret.

Motius per deixar Nomad

Quins avantatges hem obtingut en canviar al desplegament amb Nomad i Docker també?

1. Nosaltres amb les mateixes condicions per a tots els ambients. En desenvolupament, QA-entorn, preproducció, producció, s'utilitzen les mateixes imatges de contenidors, amb les mateixes dependències. En conseqüència, pràcticament no teniu cap possibilitat que una cosa diferent del que vau provar anteriorment a nivell local o en un entorn de prova surti en producció.
2. També hem trobat que n'hi ha prou fàcil d'afegir un nou servei. Qualsevol sistema nou en termes de desplegament es llança de manera molt senzilla. N'hi ha prou d'anar al repositori que emmagatzema les configuracions, afegir-hi la següent configuració del vostre sistema i ja ho teniu tot. Podeu implementar el vostre sistema a producció sense cap esforç addicional dels devops.
3. Tots fitxers de configuració en un dipòsit compartit va resultar passar per alt. En el moment en què vam desplegar els nostres sistemes mitjançant servidors virtuals, vam utilitzar Ansible, en què les configuracions estaven al mateix repositori. Tanmateix, per a la majoria de desenvolupadors, això era una mica més difícil de treballar. Aquí el volum de configuracions i codi que cal afegir per implementar el servei s'ha fet molt més petit. A més, per als devops és molt fàcil arreglar-lo o canviar-lo. En el cas de les transicions, per exemple, a una nova versió de Nomad, poden agafar i actualitzar massivament tots els fitxers operatius que es troben al mateix lloc.

Però també hem trobat diversos inconvenients:

Va resultar que nosaltres no s'han pogut aconseguir desplegaments perfectes en el cas de Nomad. En llançar contenidors de diferents condicions, podria resultar que estava en funcionament, i Nomad el va percebre com un contenidor preparat per rebre trànsit. Això va passar fins i tot abans que l'aplicació a l'interior tingués temps d'iniciar-se. Per aquest motiu, el sistema va començar a emetre 500 errors durant poc temps, perquè el trànsit va començar a anar al contenidor, que encara no estava preparat per acceptar-lo.

Ens hem trobat amb alguns errors. L'error més important és que Nomad no gestiona molt bé un clúster gran si teniu molts sistemes i contenidors. Quan voleu posar en servei un dels servidors que s'inclouen al clúster Nomad, hi ha una probabilitat bastant alta que el clúster no se senti molt bé i es desfà. Alguns contenidors poden, per exemple, caure i no pujar; això us costarà molt més endavant si tots els vostres sistemes en producció es troben en un clúster gestionat per Nomad.

Així que vam decidir pensar cap a on hauríem d'anar després. En aquell moment, vam ser molt més conscients del que volem aconseguir. És a dir: volem fiabilitat, una mica més de funcions de les que ofereix Nomad i un sistema més madur i més estable.

En aquest sentit, la nostra elecció va recaure en Kubernetes com la plataforma més popular per executar clústers. Sobretot tenint en compte que la mida i el nombre dels nostres contenidors era prou gran. Per a aquests propòsits, Kubernetes semblava ser el sistema més adequat dels que podíem mirar.

Passant a Kubernetes

Parlaré una mica sobre quins són els conceptes bàsics de Kubernetes i com es diferencien de Nomad.

En primer lloc, el concepte més bàsic de Kubernetes és el concepte de pod. Beina és un grup d'un o més contenidors que comencen sempre junts. I funcionen com sempre estrictament a la mateixa màquina virtual. Estan disponibles entre ells mitjançant l'adreça IP 127.0.0.1 en diferents ports.

Suposem que teniu una aplicació PHP que consta de nginx i php-fpm, el patró clàssic. El més probable és que voldreu que els contenidors nginx i php-fpm estiguin sempre junts. Kubernetes us permet aconseguir-ho descrivint-los com un pod comú. Això és exactament el que no podríem aconseguir amb Nomad.

El segon concepte és desplegament. La qüestió és que la beina en si és una cosa efímera, comença i desapareix. Tant si voleu matar primer tots els vostres contenidors anteriors i, a continuació, llançar noves versions immediatament, com si voleu implementar-les gradualment, aquest és precisament el concepte de desplegament responsable d'aquest procés. Descriu com desplegueu els vostres pods, quants i com actualitzeu-los.

El tercer concepte és servei. El vostre servei és en realitat el vostre sistema que capta una mica de trànsit i després el dirigeix ​​a un o més pods corresponents al vostre servei. És a dir, permet dir que tot el trànsit entrant a tal o tal servei amb tal o tal nom s'ha d'enviar a aquests pods concrets. I al mateix temps, us proporciona un equilibri de trànsit. És a dir, podeu executar dos pods de la vostra aplicació i tot el trànsit entrant s'equilibrarà de manera uniforme entre els pods relacionats amb aquest servei.

I el quart concepte bàsic: Ingrés. Aquest és un servei que s'executa en un clúster de Kubernetes. Actua com un equilibrador de càrrega extern que es fa càrrec de totes les sol·licituds. Mitjançant l'API de Kubernetes, Ingress pot determinar on s'han d'enviar aquestes sol·licituds. I ho fa amb molta flexibilitat. Podeu dir que totes les sol·licituds d'aquest amfitrió i tal o tal URL s'envien a aquest servei. I aquestes sol·licituds que arriben a aquest amfitrió i a un altre URL s'envien a un altre servei.

El més genial des del punt de vista d'algú que desenvolupa una aplicació és que pots gestionar-ho tot tu mateix. En configurar la configuració d'Ingress, podeu enviar tot el trànsit que arriba a tal o tal API a contenidors separats, registrats, per exemple, a Go. Però aquest trànsit que arriba al mateix domini, però a una URL diferent, s'envia a contenidors escrits en PHP, on hi ha molta lògica, però no són molt ràpids.

Si comparem tots aquests conceptes amb Nomad, podem dir que els tres primers conceptes són tots junts Servei. I l'últim concepte està absent en Nomad mateix. Hem utilitzat un equilibrador extern: pot ser haproxy, nginx, nginx +, etc. En el cas d'un cub, no cal que introduïu aquest concepte addicional per separat. Tanmateix, si mireu Ingress dins, llavors és nginx, haproxy o traefik, però, per dir-ho, està integrat a Kubernetes.

Tots els conceptes que he descrit són, de fet, recursos que existeixen dins d'un clúster de Kubernetes. Per descriure'ls al cub, s'utilitza el format yaml, que és més llegible i familiar que els fitxers HCL en el cas de Nomad. Però estructuralment, descriuen el mateix en el cas, per exemple, d'una beina. Diuen: vull desplegar-hi tals i tals beines, amb tal i tal imatge, en tal o tal quantitat.

A més, ens vam adonar que no volíem crear manualment cada recurs individual: desplegament, serveis, Ingress, etc. En canvi, volíem descriure cada sistema en termes de Kubernetes durant el desplegament, de manera que no haguéssim de tornar a crear manualment totes les dependències de recursos necessàries en l'ordre correcte. Helm va ser escollit com un sistema que ens va permetre fer-ho.

Conceptes bàsics a Helm

Helm és gestor de paquets per a Kubernetes. És molt semblant a com funcionen els gestors de paquets en llenguatges de programació. Us permeten emmagatzemar un servei que consisteix, per exemple, en el desplegament nginx, el desplegament php-fpm, config for Ingress, configmaps (aquesta és una entitat que us permet establir env i altres paràmetres per al vostre sistema) en forma de so- anomenats gràfics. Al mateix temps, Helm s'executa a sobre de Kubernetes. És a dir, no es tracta d'una mena de sistema de banda, sinó d'un altre servei que s'executa dins del cub. Interaccioneu amb ell mitjançant la seva API mitjançant una comanda de consola. La seva comoditat i encant és que fins i tot si el timó es trenca o l'elimines del clúster, els teus serveis no desapareixeran, ja que el timó només serveix bàsicament per iniciar el sistema. El mateix Kubernetes també és responsable de la salut i l'estat dels serveis.

També ens vam adonar d'això plantilla, que fins aleshores havíem de fer pel nostre compte mitjançant la introducció de jinja a les nostres configuracions, és una de les principals característiques d'helm. Totes les configuracions que creeu per als vostres sistemes s'emmagatzemen a Helm com a plantilles, una mica com jinja, però en realitat utilitzant la plantilla de l'idioma Go en què està escrit Helm, igual que Kubernetes.

Helm ens afegeix uns quants conceptes addicionals.

Gràfic és una descripció del vostre servei. En altres gestors de paquets, s'anomenaria paquet, paquet o alguna cosa semblant. Aquí s'anomena gràfic.

Valors són les variables que voleu utilitzar per crear les vostres configuracions a partir de plantilles.

Deixeu anar. Cada vegada que un servei que es desplega amb Helm rep una versió incremental del llançament. Helm recorda quina era la configuració del servei per a la versió anterior, l'any anterior, i així successivament. Per tant, si necessiteu tornar enrere, només heu d'executar l'ordre de devolució de trucada Helm, apuntant-lo a la versió anterior de la versió. Fins i tot si la configuració corresponent al vostre dipòsit no està disponible en el moment de la restauració, Helm encara recordarà què era i tornarà el vostre sistema a l'estat en què es trobava a la versió anterior.

En el cas que fem servir helm, les configuracions habituals de Kubernetes també es converteixen en plantilles en les quals és possible utilitzar variables, funcions i aplicar declaracions condicionals. Així, podeu recollir la configuració del vostre servei en funció de l'entorn.

A la pràctica, vam decidir fer les coses una mica diferent a les que vam fer amb Nomad. Si Nomad va emmagatzemar tant les configuracions de desplegament com les n-variables necessàries per implementar el nostre servei en un dipòsit, aquí vam decidir dividir-les en dos dipòsits separats. El dipòsit "desplegament" només emmagatzema les n variables necessàries per al desplegament, mentre que el dipòsit "helm" emmagatzema configuracions o gràfics.

Què ens va donar?

Tot i que no emmagatzemem cap dada realment sensible als fitxers de configuració. Per exemple, contrasenyes de bases de dades. S'emmagatzemen com a secrets a Kubernetes, però, tanmateix, encara hi ha coses separades que no volem donar accés a tothom seguit. Per tant, l'accés al dipòsit "desplegament" és més limitat, i el dipòsit "helm" conté només una descripció del servei. Per aquest motiu, es pot donar accés de manera segura a un cercle més gran de persones.

Com que no només tenim producció, sinó també altres entorns, gràcies a aquesta divisió, podem reutilitzar els nostres gràfics de timó per desplegar serveis no només a la producció, sinó també, per exemple, a un entorn de control de qualitat. Fins i tot per desplegar-los localment utilitzant Minikube - Això és una cosa per executar Kubernetes localment.

Dins de cada repositori, vam deixar la divisió en directoris separats per a cada servei. És a dir, dins de cada directori hi ha plantilles relacionades amb el gràfic corresponent i que descriuen els recursos que cal desplegar per posar en marxa el nostre sistema. Al repositori "desplegar", només vam deixar enveja. En aquest cas, no hem utilitzat plantilles jinja perquè Helm proporciona plantilles fora de la caixa, aquesta és una de les seves principals característiques.

Hem deixat l'script de desplegament: deploy.sh, que simplifica i estandarditza el llançament per al desplegament mitjançant Helm. Així, per a qualsevol persona que vulgui desplegar, la interfície de desplegament té exactament el mateix aspecte que en el cas de desplegar-se mitjançant Nomad. El mateix deploy.sh, el nom del vostre servei i on voleu desplegar-lo. Això fa que el timó funcioni internament. Ell, al seu torn, recopila les configuracions de les plantilles, hi substitueix els fitxers de valors necessaris, després els desplega i els llança a Kubernetes.

Troballes

El servei Kubernetes sembla ser més complex que Nomad.

Aquí és on arriba el trànsit de sortida a Ingress. Aquest és només el controlador frontal, que es fa càrrec de totes les sol·licituds i les envia posteriorment als serveis corresponents a les dades de la sol·licitud. Els determina en funció de les configuracions que formen part de la descripció de la vostra aplicació a Helm i que els desenvolupadors es defineixen. El servei, en canvi, envia peticions als seus pods, és a dir, contenidors específics, equilibrant el trànsit entrant entre tots els contenidors que pertanyen a aquest servei. I, per descomptat, no hem d'oblidar que no hem d'anar enlloc de la seguretat a nivell de xarxa. Per tant, la segmentació funciona al clúster de Kubernetes, que es basa en l'etiquetatge. Tots els serveis tenen determinades etiquetes, a les quals s'adjunten els drets d'accés dels serveis a determinats recursos externs/interns dins o fora del clúster.

A mesura que vam fer la transició, vam veure que Kubernetes té totes les funcions del Nomad que hem estat utilitzant fins ara i que també afegeix moltes coses noves. Es pot ampliar mitjançant connectors i, de fet, mitjançant tipus de recursos personalitzats. És a dir, tens l'oportunitat no només d'utilitzar alguna cosa que ve amb Kubernetes fora de la caixa, sinó de crear el teu propi recurs i servei que llegirà el teu recurs. Això us ofereix més opcions per ampliar el vostre sistema sense haver de tornar a instal·lar Kubernetes i sense haver de fer canvis.

Un exemple d'aquest ús és Prometheus, que executem dins d'un clúster de Kubernetes. Perquè comenci a recollir mètriques d'un servei concret, hem d'afegir un tipus addicional de recurs a la descripció del servei, l'anomenat servei de monitor. Prometheus, pel fet de poder llegir, al ser llançat a Kubernetes, un tipus de recurs personalitzat, comença automàticament a recollir mètriques del nou sistema. És prou convenient.

El primer desplegament que vam fer a Kubernetes va ser el març del 2018. I durant aquest temps mai vam tenir cap problema amb ell. Funciona de manera bastant estable sense errors significatius. A més, el podem ampliar encara més. Fins ara, tenim prou de les capacitats que té i ens agrada molt el ritme de desenvolupament de Kubernetes. En aquests moments, més de 3000 contenidors es troben a Kubernetes. El clúster ocupa diversos nodes. Al mateix temps, és útil, estable i molt controlable.

Font: www.habr.com