Nota. transl.: L'adopció de Kubernetes a GitLab es considera un dels dos factors principals que contribueixen al creixement de l'empresa. No obstant això, fins fa poc, la infraestructura del servei en línia GitLab.com es va construir en màquines virtuals i fa només un any que va començar la seva migració a K8s, que encara no s'ha completat. Ens complau presentar la traducció d'un article recent d'un enginyer SRE de GitLab sobre com passa això i quines conclusions treuen els enginyers que participen en el projecte.
Des de fa aproximadament un any, la nostra divisió d'infraestructura ha estat migrant tots els serveis que s'executen a GitLab.com a Kubernetes. Durant aquest temps, ens hem trobat amb reptes relacionats no només amb el trasllat de serveis a Kubernetes, sinó també amb la gestió del desplegament híbrid durant la transició. Les valuoses lliçons que vam aprendre es comentaran en aquest article.
Des del començament de GitLab.com, els seus servidors funcionaven al núvol en màquines virtuals. Aquestes màquines virtuals són gestionades per Chef i instal·lades mitjançant el nostre . en cas que l'aplicació s'hagi d'actualitzar, consisteix simplement a actualitzar la flota de servidors de manera coordinada i seqüencial mitjançant un pipeline CI. Aquest mètode - encara que lent i una mica - assegura que GitLab.com utilitza les mateixes pràctiques d'instal·lació i configuració que els usuaris fora de línia (autogestionat) Instal·lacions de GitLab utilitzant els nostres paquets de Linux per a això.
Utilitzem aquest mètode perquè és extremadament important experimentar totes les tristeses i alegries que experimenten els membres corrents de la comunitat quan instal·len i configuren les seves còpies de GitLab. Aquest enfocament va funcionar bé durant un temps, però quan el nombre de projectes a GitLab va superar els 10 milions, ens vam adonar que ja no responia a les nostres necessitats d'escala i desplegament.
Primers passos per a Kubernetes i GitLab natiu del núvol
El projecte es va crear l'any 2017 per preparar GitLab per al desplegament al núvol i per permetre als usuaris instal·lar GitLab als clústers de Kubernetes. Aleshores sabíem que traslladar GitLab a Kubernetes augmentaria l'escalabilitat de la plataforma SaaS, simplificaria els desplegaments i milloraria l'eficiència dels recursos informàtics. Al mateix temps, moltes de les funcions de la nostra aplicació depenien de particions NFS muntades, la qual cosa va frenar la transició de les màquines virtuals.
L'empenta cap al núvol natiu i Kubernetes va permetre als nostres enginyers planificar una transició gradual, durant la qual vam abandonar algunes de les dependències de l'aplicació de l'emmagatzematge en xarxa mentre vam continuar desenvolupant noves funcions. Des que vam començar a planificar la migració l'estiu del 2019, moltes d'aquestes limitacions s'han resolt i el procés de migració de GitLab.com a Kubernetes ja està en marxa.
Característiques de GitLab.com a Kubernetes
Per a GitLab.com, utilitzem un únic clúster regional de GKE que gestiona tot el trànsit d'aplicacions. Per minimitzar la complexitat de la migració (ja complicada), ens centrem en serveis que no depenen de l'emmagatzematge local o NFS. GitLab.com utilitza una base de codi de Rails predominantment monolítica i encaminem el trànsit en funció de les característiques de la càrrega de treball a diferents punts finals que estan aïllats als seus propis grups de nodes.
En el cas del frontend, aquests tipus es divideixen en peticions a web, API, Git SSH/HTTPS i Registre. En el cas del backend, dividim els treballs de la cua segons diverses característiques segons , que ens permeten establir objectius de nivell de servei (SLO) per a diferents càrregues de treball.
Tots aquests serveis de GitLab.com es configuren mitjançant un gràfic de GitLab Helm sense modificar. La configuració es realitza en subgràfics, que es poden activar de manera selectiva a mesura que migrem els serveis al clúster gradualment. Tot i que vam decidir no incloure alguns dels nostres serveis amb estat a la migració, com ara Redis, Postgres, GitLab Pages i Gitaly, l'ús de Kubernetes ens permet reduir radicalment el nombre de màquines virtuals que Chef gestiona actualment.
Visibilitat i gestió de la configuració de Kubernetes
Totes les configuracions són gestionades pel mateix GitLab. Per a això, s'utilitzen tres projectes de configuració basats en Terraform i Helm. Intentem utilitzar el mateix GitLab sempre que sigui possible per executar GitLab, però per a les tasques operatives tenim una instal·lació separada de GitLab. Això és necessari per assegurar-vos que no dependreu de la disponibilitat de GitLab.com quan realitzeu implementacions i actualitzacions de GitLab.com.
Tot i que els nostres pipelines per al clúster de Kubernetes s'executen en una instal·lació de GitLab independent, hi ha rèpliques dels dipòsits de codi que estan disponibles públicament a les adreces següents:
- — Marc de configuració de GitLab.com per al gràfic GitLab Helm;
- - Conté configuracions per a serveis que no estan directament associats amb l'aplicació GitLab. Aquests inclouen configuracions per al registre i la supervisió de clúster, així com eines integrades com PlantUML;
- — Configuració de Terraform per a Kubernetes i infraestructura de VM heretada. Aquí configureu tots els recursos necessaris per executar el clúster, inclosos el propi clúster, grups de nodes, comptes de servei i reserves d'adreces IP.
La vista pública es mostra quan es fan canvis. amb un enllaç a la diferència detallada que SRE analitza abans de fer canvis al clúster.
Per a SRE, l'enllaç condueix a una diferència detallada a la instal·lació de GitLab, que s'utilitza per a la producció i l'accés està restringit. Això permet als empleats i la comunitat, sense accés al projecte operatiu (que només està obert a SRE), veure els canvis de configuració proposats. En combinar una instància pública de GitLab per al codi amb una instància privada per a canalitzacions CI, mantenim un únic flux de treball alhora que garantim la independència de GitLab.com per a les actualitzacions de configuració.
El que vam descobrir durant la migració
Durant el trasllat, es va adquirir experiència que apliquem a noves migracions i desplegaments a Kubernetes.
1. Augment de costos per trànsit entre zones de disponibilitat
Estadístiques diàries de sortida (bytes per dia) per a la flota de dipòsits de Git a GitLab.com
Google divideix la seva xarxa en regions. Aquestes, al seu torn, es divideixen en zones d'accessibilitat (AZ). L'allotjament de Git està associat a grans quantitats de dades, per la qual cosa és important que controlem la sortida de la xarxa. Per al trànsit intern, la sortida només és gratuïta si es manté dins de la mateixa zona de disponibilitat. En el moment d'escriure aquest article, estem donant servei aproximadament 100 TB de dades en un dia laboral típic (i això només és per als dipòsits Git). Els serveis que residien a les mateixes màquines virtuals de la nostra antiga topologia basada en VM ara s'executen en diferents pods de Kubernetes. Això significa que una part del trànsit que abans era local a la màquina virtual podria viatjar fora de les zones de disponibilitat.
Els clústers regionals de GKE us permeten abastar diverses zones de disponibilitat per a la redundància. Estem considerant la possibilitat per a serveis que generen grans volums de trànsit. Això reduirà els costos de sortida mentre es manté la redundància a nivell de clúster.
2. Límits, peticions de recursos i escalat
El nombre de rèpliques que processen el trànsit de producció a registry.gitlab.com. El trànsit arriba a les ~15:00 UTC.
La nostra història de migració va començar l'agost de 2019, quan vam migrar el nostre primer servei, el GitLab Container Registry, a Kubernetes. Aquest servei crític i de gran trànsit va ser una bona opció per a la primera migració perquè és una aplicació sense estat amb poques dependències externes. El primer problema que vam trobar va ser un gran nombre de pods desallotjats per falta de memòria als nodes. Per això hem hagut de canviar les peticions i els límits.
Es va descobrir que en el cas d'una aplicació on el consum de memòria augmenta amb el temps, els valors baixos de les sol·licituds (reserva de memòria per a cada pod) juntament amb un límit dur "generós" d'ús van provocar la saturació. (saturació) nodes i un alt nivell de desnonaments. Per fer front a aquest problema, va ser . Això va treure la pressió dels nodes i va assegurar que les beines tinguessin un cicle de vida que no pressionés massa el node. Ara comencem les migracions amb sol·licituds i valors límit generosos (i gairebé idèntics), ajustant-los segons sigui necessari.
3. Mètriques i registres
La divisió d'infraestructura se centra en la latència, les taxes d'error i la saturació amb instal·lats (SLO) vinculat a .
Durant l'últim any, un dels esdeveniments clau a la divisió d'infraestructures ha estat la millora en el seguiment i el treball amb els SLO. Els SLO ens van permetre establir objectius per a serveis individuals que vam supervisar de prop durant la migració. Però fins i tot amb aquesta observabilitat millorada, no sempre és possible veure immediatament problemes amb mètriques i alertes. Per exemple, en centrar-nos en la latència i les taxes d'error, no cobrim completament tots els casos d'ús d'un servei en procés de migració.
Aquest problema es va descobrir gairebé immediatament després de migrar algunes càrregues de treball al clúster. Es va fer especialment greu quan vam haver de comprovar funcions per a les quals el nombre de peticions era petit, però que tenien dependències de configuració molt específiques. Una de les lliçons clau de la migració va ser la necessitat de tenir en compte no només les mètriques en el seguiment, sinó també els registres i la "cua llarga" (això tracta al gràfic - aprox. trad.) errors. Ara, per a cada migració, incloem una llista detallada de consultes de registre (consultes de registre) i planificar procediments de retrocés clars que es puguin transferir d'un torn a un altre si sorgeixen problemes.
Atendre les mateixes sol·licituds en paral·lel a l'antiga infraestructura de VM i a la nova infraestructura basada en Kubernetes presentava un repte únic. A diferència de la migració lift-and-shift (transferència ràpida d'aplicacions "tal qual" a una nova infraestructura; es poden llegir més detalls, per exemple, -aprox. trad.), el treball paral·lel en màquines virtuals "antigues" i Kubernetes requereix que les eines de monitorització siguin compatibles amb ambdós entorns i puguin combinar mètriques en una sola vista. És important que utilitzem els mateixos taulers de control i consultes de registre per aconseguir una observabilitat coherent durant el període de transició.
4. Canviar el trànsit a un nou clúster
Per a GitLab.com, part dels servidors es dedica . Canary Park dóna servei als nostres projectes interns i també pot . Però està dissenyat principalment per provar els canvis fets a la infraestructura i l'aplicació. El primer servei migrat va començar acceptant una quantitat limitada de trànsit intern i seguim utilitzant aquest mètode per garantir que es compleixin els SLO abans d'enviar tot el trànsit al clúster.
En el cas de la migració, això vol dir que les sol·licituds als projectes interns s'envien primer a Kubernetes i després canviem gradualment la resta del trànsit al clúster canviant el pes del backend mitjançant HAProxy. Durant la migració de VM a Kubernetes, va quedar clar que era molt beneficiós tenir una manera senzilla de redirigir el trànsit entre la infraestructura antiga i la nova i, en conseqüència, mantenir la infraestructura antiga preparada per a la recuperació durant els primers dies després de la migració.
5. Capacitats de reserva de les beines i el seu ús
Gairebé immediatament es va identificar el següent problema: els pods per al servei de registre van començar ràpidament, però el llançament de pods per a Sidekiq va trigar fins a . El llarg temps d'inici dels pods Sidekiq es va convertir en un problema quan vam començar a migrar les càrregues de treball a Kubernetes per als treballadors que havien de processar les feines ràpidament i escalar ràpidament.
En aquest cas, la lliçó va ser que, tot i que l'Horizontal Pod Autoscaler (HPA) de Kubernetes gestiona bé el creixement del trànsit, és important tenir en compte les característiques de les càrregues de treball i assignar capacitat excedent als pods (especialment quan la demanda es distribueix de manera desigual). En el nostre cas, hi va haver un augment sobtat de llocs de treball, que va provocar una escalada ràpida, que va provocar la saturació dels recursos de la CPU abans que tinguéssim temps d'escalar el conjunt de nodes.
Sempre hi ha la temptació d'extreure el màxim possible d'un clúster, però, després d'haver trobat problemes de rendiment inicialment, ara comencem amb un pressupost de pod generós i el reduïm més tard, vigilant de prop els SLO. El llançament de pods per al servei Sidekiq s'ha accelerat significativament i ara triga uns 40 segons de mitjana. va guanyar tant GitLab.com com els nostres usuaris d'instal·lacions autogestionades que treballen amb el gràfic oficial de GitLab Helm.
Conclusió
Després de migrar cada servei, ens vam alegrar dels avantatges d'utilitzar Kubernetes en producció: desplegament d'aplicacions més ràpid i segur, escalat i assignació de recursos més eficient. A més, els avantatges de la migració van més enllà del servei GitLab.com. Cada millora al gràfic oficial de Helm beneficia els seus usuaris.
Espero que us hagi agradat la història de les nostres aventures de migració a Kubernetes. Continuem migrant tots els serveis nous al clúster. Podeu trobar informació addicional a les següents publicacions:
- «»;
- «»;
- .
PS del traductor
Llegeix també al nostre blog:
- «»;
- «»;
- «»;
- «».
Font: www.habr.com
