Nota. transl.: L'adopzione di Kubernetes in GitLab hè cunsideratu unu di i dui fatturi principali chì cuntribuiscenu à a crescita di a cumpagnia. In ogni casu, finu à pocu tempu, l'infrastruttura di u serviziu in linea GitLab.com hè stata custruita nantu à e macchine virtuali, è solu circa un annu fà a so migrazione à K8s hà iniziatu, chì ùn hè micca cumpletu. Semu piacè di prisentà una traduzzione di un articulu recente da un ingegnere di GitLab SRE nantu à cumu si succede questu è chì cunclusioni facenu i ingegneri chì participanu à u prugettu.
Dapoi circa un annu, a nostra divisione infrastruttura hà migratu tutti i servizii in esecuzione in GitLab.com à Kubernetes. Duranti stu tempu, avemu scontru sfide ligati micca solu à u muvimentu di servizii à Kubernetes, ma ancu à a gestione di a implementazione hibrida durante a transizione. E lezioni preziose chì avemu amparatu seranu discututi in questu articulu.
Dapoi u principiu di GitLab.com, i so servitori currenu in u nuvulu nantu à e macchine virtuali. Queste macchine virtuali sò gestite da Chef è installate cù u nostru . in casu chì l'applicazione deve esse aghjurnata, cunsiste solu in l'aghjurnamentu di a flotta di u servitore in una manera coordinata è sequenziale utilizendu un pipeline CI. Stu metudu - anche lentu è pocu - assicura chì GitLab.com utilizeghja e stesse pratiche di installazione è cunfigurazione cum'è l'utilizatori offline (autogestionatu) Installazioni GitLab chì utilizanu i nostri pacchetti Linux per questu.
Utilizemu stu metudu perchè hè estremamente impurtante per sperienze tutti i disgrazii è e gioia chì i membri ordinali di a cumunità sperimentanu quandu installanu è cunfigurà e so copie di GitLab. Stu approcciu hà travagliatu bè per qualchì tempu, ma quandu u nùmeru di prughjetti in GitLab superava i 10 milioni, avemu capitu chì ùn hà più risponde à i nostri bisogni di scala è implementazione.
I primi passi per Kubernetes è GitLab nativu in nuvola
U prugettu hè statu creatu in u 2017 per preparà GitLab per l'implementazione in nuvola, è per permette à l'utilizatori di stallà GitLab in clusters Kubernetes. Sapemu allora chì u muvimentu di GitLab à Kubernetes aumenterà a scalabilità di a piattaforma SaaS, simplificà e implementazioni, è migliurà l'efficienza di e risorse di l'informatica. À u listessu tempu, assai di e funzioni di a nostra applicazione dependevanu di partizioni NFS muntati, chì rallentavanu a transizione da e macchine virtuali.
A spinta versu u cloud native è Kubernetes hà permessu à i nostri ingegneri di pianificà una transizione graduale, durante a quale avemu abbandunatu alcune di e dipendenze di l'applicazione nantu à u almacenamentu di a rete mentre cuntinuemu à sviluppà novi funzioni. Dapoi chì avemu cuminciatu à pianificà a migrazione in l'estiu di 2019, assai di sti limitazioni sò stati risolti, è u prucessu di migrazione di GitLab.com à Kubernetes hè avà bè avviatu!
Funzioni di GitLab.com in Kubernetes
Per GitLab.com, usemu un unicu cluster GKE regiunale chì gestisce tuttu u trafficu di l'applicazioni. Per minimizzà a cumplessità di a migrazione (dighjà complicata), ci focalizemu nantu à i servizii chì ùn si basanu micca in u almacenamentu locale o NFS. GitLab.com usa una basa di codice Rails principarmenti monolitica, è indirizzemu u trafficu basatu annantu à e caratteristiche di a carica di travagliu à e diverse endpoints chì sò isolati in i so propri pools di nodi.
In u casu di u frontend, sti tipi sò spartuti in richieste à web, API, Git SSH / HTTPS è Registru. In u casu di u backend, spartemu i travaglii in a fila secondu e diverse caratteristiche secondu , chì ci permettenu di stabilisce Obiettivi à Livellu di Serviziu (SLO) per diversi carichi di travagliu.
Tutti questi servizii di GitLab.com sò cunfigurati cù un graficu GitLab Helm senza modificazione. A cunfigurazione hè realizata in subcharts, chì ponu esse attivati selettivamente cum'è migrate gradualmente i servizii à u cluster. Ancu s'è avemu decisu di ùn include micca alcuni di i nostri servizii stateful in a migrazione, cum'è Redis, Postgres, GitLab Pages è Gitaly, l'usu di Kubernetes ci permette di riduce radicalmente u numeru di VM chì Chef gestisce attualmente.
Kubernetes Configurazione Visibilità è Gestione
Tutti i paràmetri sò gestiti da GitLab stessu. Per questu, trè prughjetti di cunfigurazione basati in Terraform è Helm sò usati. Pruvemu d'utilizà GitLab stessu ogni volta chì hè pussibule per eseguisce GitLab, ma per i travaglii operativi avemu una stallazione separata di GitLab. Questu hè necessariu per assicurà chì ùn site micca dipendente da a dispunibilità di GitLab.com quandu eseguite implementazioni è aghjurnamenti di GitLab.com.
Ancu se i nostri pipeline per u cluster Kubernetes funzionanu in una installazione GitLab separata, ci sò specchi di i repositori di codice chì sò publicamente dispunibuli à l'indirizzi seguenti:
- - Quadru di cunfigurazione GitLab.com per u graficu GitLab Helm;
- - Cuntene cunfigurazioni per i servizii chì ùn sò micca direttamente assuciati cù l'applicazione GitLab. Queste include cunfigurazioni per u logging è u monitoraghju di cluster, è ancu strumenti integrati cum'è PlantUML;
- — Configurazione Terraform per Kubernetes e infrastruttura VM legacy. Quì cunfigurà tutte e risorse necessarie per eseguisce u cluster, cumpresu u cluster stessu, pools di nodi, cunti di serviziu è riservazioni di indirizzu IP.
A vista publica hè mostrata quandu i cambiamenti sò fatti. cù un ligame à u diffettu detallatu chì SRE analizà prima di fà cambiamenti à u cluster.
Per SRE, u ligame porta à un diffettu detallatu in l'installazione di GitLab, chì hè utilizatu per a produzzione è l'accessu à quale hè limitatu. Questu permette à l'impiegati è a cumunità, senza accessu à u prughjettu operativu (chì hè apertu solu à SRE), per vede i cambiamenti di cunfigurazione pruposti. Cumminendu una istanza publica di GitLab per u codice cù una istanza privata per i pipelines CI, mantenemu un flussu di travagliu unicu mentre assicurendu l'indipendenza da GitLab.com per l'aghjurnamenti di cunfigurazione.
Ciò chì avemu scupertu durante a migrazione
Durante u muvimentu, l'esperienza hè stata acquistata chì applichemu à novi migrazioni è implementazioni in Kubernetes.
1. Aumentu di i costi per via di u trafficu trà e zoni di dispunibilità
Statistiche di uscita di ogni ghjornu (byte per ghjornu) per a flotta di repository Git in GitLab.com
Google divide a so reta in regioni. Quelli, à u turnu, sò divisi in zoni di accessibilità (AZ). Git hosting hè assuciatu cù grandi quantità di dati, cusì hè impurtante per noi di cuntrullà l'egress di a rete. Per u trafficu internu, l'uscita hè libera solu s'ellu si ferma in a stessa zona di dispunibilità. A partire da questa scrittura, servemu circa 100 TB di dati in un ghjornu di travagliu tipicu (è questu hè solu per i repositori Git). I servizii chì residenu in e stesse macchine virtuali in a nostra vechja topulugia basata in VM ora funzionanu in diverse pod Kubernetes. Questu significa chì un pocu di trafficu chì era prima locale à a VM puderia viaghjà fora di e zone di dispunibilità.
I clusters GKE regionali permettenu di spannà parechje Zone di Disponibilità per a ridondanza. Avemu cunsiderà a pussibilità per i servizii chì generanu grandi volumi di trafficu. Questu riducerà i costi di uscita mentre mantene a redundanza à livellu di cluster.
2. Limiti, dumande di risorse è scala
U numeru di repliche chì trasfurmanu u trafficu di produzzione in registry.gitlab.com. U trafficu culmina à ~ 15:00 UTC.
A nostra storia di migrazione hà iniziatu in Aostu 2019, quandu avemu migratu u nostru primu serviziu, u Registru di Container GitLab, à Kubernetes. Stu serviziu criticu di missione, altu trafficu era una bona scelta per a prima migrazione perchè hè una applicazione senza statu cù pocu dipendenze esterne. U primu prublema chì avemu scontru era un gran numaru di baccelli scacciati per mancanza di memoria nantu à i nodi. Per quessa, avemu avutu à cambià e dumande è i limiti.
Hè statu scupertu chì in u casu di una applicazione induve u cunsumu di memoria aumenta cù u tempu, i valori bassi per e richieste (riservazione di memoria per ogni pod) accumpagnati da un limitu duru "generoso" di l'usu hà purtatu à a saturazione. (saturazione) nodi è un altu livellu di evictions. Per trattà stu prublema, era . Questu hà pigliatu a pressione di i nodi è hà assicuratu chì i baccelli avianu un ciclu di vita chì ùn hà micca fattu troppu pressione nantu à u nodu. Avà avemu principiatu migrazioni cù generosa (è quasi identica) richieste è valori limite, aghjustendu cum'è necessariu.
3. Metrics è logs
A divisione di l'infrastruttura si cuncentra nantu à a latenza, i tassi d'errore è a saturazione cù installati (SLO) ligatu à .
L'annu passatu, unu di l'avvenimenti chjave in a divisione di l'infrastruttura hè stata migliuramentu in u monitoraghju è u travagliu cù SLO. I SLO ci anu permessu di stabilisce scopi per i servizii individuali chì avemu monitoratu da vicinu durante a migrazione. Ma ancu cù questa observabilità mejorata, ùn hè micca sempre pussibule di vede immediatamente i prublemi cù metriche è alerti. Per esempiu, fighjendu nantu à a latenza è i tassi d'errore, ùn copremu micca cumplettamente tutti i casi d'usu per un serviziu in migrazione.
Stu prublema hè stata scuperta quasi subitu dopu a migrazione di qualchi carichi di travagliu à u cluster. Hè diventatu soprattuttu agutu quandu avemu avutu à verificà e funzioni per quale u numeru di richieste era chjuca, ma chì avianu dependenzii di cunfigurazione assai specifichi. Una di e lezioni chjave da a migrazione era a necessità di piglià in contu micca solu metrica quandu u monitoraghju, ma ancu i logs è a "coda longa" (questu hè circa nantu à a carta - circa. trad.) errori. Avà per ogni migrazione includemu una lista dettagliata di e dumande di log (questioni di log) è pianificà e prucedure di rollback chjaramente chì ponu esse trasferite da un turnu à l'altru se i prublemi sò.
U serviziu di e stesse richieste in parallelu nantu à a vechja infrastruttura VM è a nova infrastruttura basata in Kubernetes presentava una sfida unica. A cuntrariu di a migrazione lift-and-shift (trasferimentu rapidu di l'applicazioni "cum'è" à una nova infrastruttura; più dettagli ponu esse leghje, per esempiu, - ca. trad.), u travagliu parallelu nantu à "vechi" VMs è Kubernetes esige chì l'arnesi di monitoraghju sò cumpatibili cù i dui ambienti è esse capaci di cumminà metriche in una vista. Hè impurtante chì usemu i stessi dashboards è log queries per ottene una osservabilità coherente durante u periodu di transizione.
4. Cambia u trafficu à un novu cluster
Per GitLab.com, una parte di i servitori hè dedicata à . Canary Park serve i nostri prughjetti interni è ponu ancu . Ma hè principalmente pensatu per pruvà i cambiamenti fatti à l'infrastruttura è l'applicazione. U primu serviziu migratu hà iniziatu accettendu una quantità limitata di trafficu internu, è cuntinuemu à aduprà stu metudu per assicurà chì i SLO sò scontri prima di mandà tuttu u trafficu à u cluster.
In u casu di migrazione, questu significa chì e dumande à i prughjetti internu sò mandati prima à Kubernetes, è poi cambiamu gradualmente u restu di u trafficu à u cluster cambiendu u pesu per u backend attraversu HAProxy. Durante a migrazione da VM à Kubernetes, hè diventatu chjaru chì era assai benefiziu per avè un modu faciule per redirige u trafficu trà l'antica è a nova infrastruttura è, per quessa, mantene a vechja infrastruttura pronta per rollback in i primi ghjorni dopu a migrazione.
5. Capacità di riserva di baccelli è u so usu
Quasi subitu u prublema seguente hè statu identificatu: i pods per u serviziu di u Registru cuminciaru prestu, ma u lanciu di pods per Sidekiq hà pigliatu . U longu tempu di startup per i pod Sidekiq hè diventatu un prublema quandu avemu cuminciatu à migrà carichi di travagliu à Kubernetes per i travagliadori chì avianu bisognu di processà i travaglii rapidamente è scala rapidamente.
In questu casu, a lezziò era chì, mentri l'Horizontal Pod Autoscaler (HPA) di Kubernetes gestisce bè a crescita di u trafficu, hè impurtante cunsiderà e caratteristiche di i carichi di travagliu è attribuisce capacità di riserva à i pods (soprattuttu quandu a dumanda hè distribuita in modu irregulare). In u nostru casu, ci hè stata una crescita brusca di l'impieghi, chì porta à una scala rapida, chì hà purtatu à a saturazione di e risorse di CPU prima di avè u tempu di scala u node pool.
Ci hè sempre una tentazione di strincà quant'è pussibule fora di un cluster, in ogni modu, avè inizialmente scontru prublemi di rendiment, avemu principiatu avà cù un generoso budget di pod è riduzzione dopu, mantenendu un ochju vicinu à SLO. U lanciu di pods per u serviziu Sidekiq hà acceleratu significativamente è avà dura circa 40 seconde in media. hà vintu sia GitLab.com sia i nostri utilizatori di installazioni autogestionate chì travaglianu cù u graficu ufficiale di GitLab Helm.
cunchiusioni
Dopu avè migratu ogni serviziu, ci rallegramu di i benefici di l'usu di Kubernetes in a produzzione: implementazione di l'applicazioni più veloce è sicura, scala, è allocazione di risorse più efficiente. Inoltre, i vantaghji di a migrazione vanu oltre u serviziu GitLab.com. Ogni migliuramentu di a carta ufficiale Helm benefiziu i so utilizatori.
Spergu chì avete piaciutu a storia di e nostre avventure di migrazione Kubernetes. Cuntinuemu à migrà tutti i novi servizii à u cluster. L'infurmazioni supplementari ponu esse truvati in e seguenti publicazioni:
- «";
- «";
- .
PS da u traduttore
Leghjite puru nant'à u nostru blog:
- «";
- «";
- «";
- «».
Source: www.habr.com