Nota. trad.: L'adozione di Kubernetes presso GitLab è considerata uno dei due principali fattori che contribuiscono alla crescita dell'azienda. Tuttavia, fino a poco tempo fa, l'infrastruttura del servizio online GitLab.com era costruita su macchine virtuali e solo circa un anno fa è iniziata la sua migrazione su K8, che non è ancora stata completata. Siamo lieti di presentare una traduzione di un recente articolo di un ingegnere di GitLab SRE su come ciò accade e quali conclusioni traggono gli ingegneri che partecipano al progetto.
Da circa un anno, la nostra divisione infrastruttura sta migrando tutti i servizi in esecuzione su GitLab.com su Kubernetes. Durante questo periodo, abbiamo riscontrato sfide legate non solo allo spostamento dei servizi su Kubernetes, ma anche alla gestione della distribuzione ibrida durante la transizione. Le preziose lezioni che abbiamo imparato saranno discusse in questo articolo.
Fin dall'inizio di GitLab.com, i suoi server funzionavano nel cloud su macchine virtuali. Queste macchine virtuali sono gestite da Chef e installate utilizzando il nostro . nel caso in cui sia necessario aggiornare l'applicazione, consiste semplicemente nell'aggiornare il parco server in modo coordinato e sequenziale utilizzando una pipeline CI. Questo metodo, anche se lento e poco - garantisce che GitLab.com utilizzi le stesse pratiche di installazione e configurazione degli utenti offline (autogestito) Installazioni GitLab utilizzando i nostri pacchetti Linux per questo.
Usiamo questo metodo perché è estremamente importante sperimentare tutti i dolori e le gioie che i membri ordinari della comunità sperimentano durante l'installazione e la configurazione delle loro copie di GitLab. Questo approccio ha funzionato bene per qualche tempo, ma quando il numero di progetti su GitLab ha superato i 10 milioni, ci siamo resi conto che non soddisfaceva più le nostre esigenze di scalabilità e implementazione.
Primi passi verso Kubernetes e GitLab cloud-native
Il progetto è stato creato nel 2017 per preparare GitLab per la distribuzione nel cloud e per consentire agli utenti di installare GitLab su cluster Kubernetes. Sapevamo allora che spostare GitLab su Kubernetes avrebbe aumentato la scalabilità della piattaforma SaaS, semplificato le implementazioni e migliorato l'efficienza delle risorse di elaborazione. Allo stesso tempo, molte delle funzioni della nostra applicazione dipendevano dalle partizioni NFS montate, che rallentavano la transizione dalle macchine virtuali.
La spinta verso il cloud nativo e Kubernetes ha permesso ai nostri ingegneri di pianificare una transizione graduale, durante la quale abbiamo abbandonato alcune dipendenze dell'applicazione dallo storage di rete pur continuando a sviluppare nuove funzionalità. Da quando abbiamo iniziato a pianificare la migrazione nell'estate del 2019, molte di queste limitazioni sono state risolte e il processo di migrazione di GitLab.com a Kubernetes è ormai ben avviato!
Funzionalità di GitLab.com in Kubernetes
Per GitLab.com utilizziamo un singolo cluster GKE regionale che gestisce tutto il traffico delle applicazioni. Per ridurre al minimo la complessità della migrazione (già complessa), ci concentriamo su servizi che non si basano sullo storage locale o su NFS. GitLab.com utilizza una base di codice Rails prevalentemente monolitica e instradamo il traffico in base alle caratteristiche del carico di lavoro verso diversi endpoint isolati nei rispettivi pool di nodi.
Nel caso del frontend queste tipologie si dividono in richieste al web, API, Git SSH/HTTPS e Registro. Nel caso del backend, dividiamo i lavori in coda in base a varie caratteristiche a seconda , che ci consentono di impostare obiettivi del livello di servizio (SLO) per vari carichi di lavoro.
Tutti questi servizi GitLab.com sono configurati utilizzando un grafico Helm GitLab non modificato. La configurazione viene effettuata in sottografici, che possono essere abilitati selettivamente man mano che migriamo gradualmente i servizi nel cluster. Anche se abbiamo deciso di non includere nella migrazione alcuni dei nostri servizi stateful, come Redis, Postgres, GitLab Pages e Gitaly, l'utilizzo di Kubernetes ci consente di ridurre radicalmente il numero di VM attualmente gestite da Chef.
Visibilità e gestione della configurazione Kubernetes
Tutte le impostazioni sono gestite da GitLab stesso. A tale scopo vengono utilizzati tre progetti di configurazione basati su Terraform e Helm. Cerchiamo di utilizzare GitLab stesso quando possibile per eseguire GitLab, ma per le attività operative abbiamo un'installazione GitLab separata. Ciò è necessario per garantire di non dipendere dalla disponibilità di GitLab.com durante l'esecuzione di distribuzioni e aggiornamenti di GitLab.com.
Sebbene le nostre pipeline per il cluster Kubernetes vengano eseguite su un'installazione GitLab separata, esistono mirror dei repository di codice disponibili pubblicamente ai seguenti indirizzi:
- — Framework di configurazione GitLab.com per il grafico GitLab Helm;
- - Contiene configurazioni per servizi che non sono direttamente associati all'applicazione GitLab. Questi includono configurazioni per la registrazione e il monitoraggio dei cluster, nonché strumenti integrati come PlantUML;
- — Configurazione Terraform per Kubernetes e infrastruttura VM legacy. Qui puoi configurare tutte le risorse necessarie per eseguire il cluster, incluso il cluster stesso, i pool di nodi, gli account di servizio e le prenotazioni degli indirizzi IP.
La visualizzazione pubblica viene mostrata quando vengono apportate modifiche. con un collegamento alla differenza dettagliata che SRE analizza prima di apportare modifiche al cluster.
Per SRE il collegamento porta a una differenza dettagliata nell'installazione GitLab, utilizzata per la produzione e il cui accesso è limitato. Ciò consente ai dipendenti e alla comunità, senza accesso al progetto operativo (che è aperto solo agli SRE), di visualizzare le modifiche alla configurazione proposte. Combinando un'istanza GitLab pubblica per il codice con un'istanza privata per le pipeline CI, manteniamo un unico flusso di lavoro garantendo al tempo stesso l'indipendenza da GitLab.com per gli aggiornamenti della configurazione.
Cosa abbiamo scoperto durante la migrazione
Durante il trasloco è stata acquisita esperienza che applichiamo a nuove migrazioni e implementazioni in Kubernetes.
1. Aumento dei costi dovuto al traffico tra le zone di disponibilità
Statistiche giornaliere in uscita (byte al giorno) per il parco repository Git su GitLab.com
Google divide la sua rete in regioni. Queste, a loro volta, sono suddivise in zone di accessibilità (AZ). L'hosting Git è associato a grandi quantità di dati, quindi è importante per noi controllare l'uscita dalla rete. Per il traffico interno, l'uscita è gratuita solo se rimane all'interno della stessa zona di disponibilità. Al momento della stesura di questo articolo, serviamo circa 100 TB di dati in una tipica giornata lavorativa (e questo è solo per i repository Git). I servizi che risiedevano nelle stesse macchine virtuali nella nostra vecchia topologia basata su VM ora vengono eseguiti in pod Kubernetes diversi. Ciò significa che parte del traffico precedentemente locale alla VM potrebbe potenzialmente viaggiare al di fuori delle zone di disponibilità.
I cluster GKE regionali ti consentono di estendersi su più zone di disponibilità per la ridondanza. Stiamo valutando la possibilità per servizi che generano grandi volumi di traffico. Ciò ridurrà i costi di uscita mantenendo la ridondanza a livello di cluster.
2. Limiti, richieste di risorse e scalabilità
Il numero di repliche che elaborano il traffico di produzione su Registry.gitlab.com. I picchi di traffico sono alle 15:00 UTC circa.
La nostra storia di migrazione è iniziata nell'agosto 2019, quando abbiamo migrato il nostro primo servizio, GitLab Container Registry, su Kubernetes. Questo servizio mission-critical e ad alto traffico è stato una buona scelta per la prima migrazione perché è un'applicazione stateless con poche dipendenze esterne. Il primo problema che abbiamo riscontrato è stato un gran numero di pod sfrattati a causa della mancanza di memoria sui nodi. Per questo motivo abbiamo dovuto modificare richieste e limiti.
Si è scoperto che nel caso di un’applicazione in cui il consumo di memoria aumenta nel tempo, valori bassi di richieste (riservando memoria per ciascun pod) abbinati ad un “generoso” limite rigido all’utilizzo portavano alla saturazione (saturazione) nodi e un alto livello di sfratti. Per affrontare questo problema, lo era . Ciò ha alleviato la pressione dai nodi e ha assicurato che i pod avessero un ciclo di vita che non esercitasse troppa pressione sul nodo. Ora iniziamo le migrazioni con richieste generose (e quasi identiche) e valori limite, modificandoli se necessario.
3. Metriche e log
La divisione infrastruttura si concentra su latenza, tassi di errore e saturazione di installazioni (SLO) collegato a .
Nell'ultimo anno, uno degli eventi chiave nella divisione infrastrutture è stato il miglioramento del monitoraggio e del lavoro con gli SLO. Gli SLO ci hanno permesso di fissare obiettivi per i singoli servizi che abbiamo monitorato da vicino durante la migrazione. Ma anche con questa migliore osservabilità, non è sempre possibile vedere immediatamente i problemi utilizzando metriche e avvisi. Ad esempio, concentrandoci su latenza e tassi di errore, non copriamo completamente tutti i casi d'uso per un servizio in fase di migrazione.
Questo problema è stato scoperto quasi immediatamente dopo la migrazione di alcuni carichi di lavoro al cluster. La situazione è diventata particolarmente acuta quando abbiamo dovuto controllare funzioni per le quali il numero di richieste era piccolo, ma che avevano dipendenze di configurazione molto specifiche. Una delle lezioni chiave della migrazione è stata la necessità di tenere conto non solo delle metriche durante il monitoraggio, ma anche dei log e della “coda lunga” (si tratta di sul grafico - ca. trad.) errori. Ora per ogni migrazione includiamo un elenco dettagliato di query di registro (query di registro) e pianificare chiare procedure di ripristino che possano essere trasferite da un turno a quello successivo in caso di problemi.
Servire le stesse richieste in parallelo sulla vecchia infrastruttura VM e sulla nuova infrastruttura basata su Kubernetes rappresentava una sfida unica. A differenza della migrazione lift-and-shift (trasferimento rapido delle applicazioni “così come sono” su una nuova infrastruttura; maggiori dettagli possono essere letti, ad esempio, - ca. trad.), il lavoro parallelo sulle “vecchie” VM e Kubernetes richiede che gli strumenti di monitoraggio siano compatibili con entrambi gli ambienti e siano in grado di combinare le metriche in un’unica visualizzazione. È importante utilizzare le stesse dashboard e query di registro per ottenere un'osservabilità coerente durante il periodo di transizione.
4. Trasferimento del traffico a un nuovo cluster
Per GitLab.com, parte dei server è dedicata a . Canary Park serve i nostri progetti interni e può anche farlo . Ma è progettato principalmente per testare le modifiche apportate all'infrastruttura e all'applicazione. Il primo servizio migrato è iniziato accettando una quantità limitata di traffico interno e continuiamo a utilizzare questo metodo per garantire che gli SLO siano soddisfatti prima di inviare tutto il traffico al cluster.
Nel caso della migrazione, ciò significa che le richieste ai progetti interni vengono prima inviate a Kubernetes, quindi trasferiamo gradualmente il resto del traffico al cluster modificando il peso per il backend tramite HAProxy. Durante la migrazione da VM a Kubernetes, è diventato chiaro che era molto vantaggioso avere un modo semplice per reindirizzare il traffico tra la vecchia e la nuova infrastruttura e, di conseguenza, mantenere la vecchia infrastruttura pronta per il rollback nei primi giorni dopo la migrazione.
5. Capacità di riserva dei pod e loro utilizzo
Quasi immediatamente è stato identificato il seguente problema: i pod per il servizio Registro si avviavano rapidamente, ma l'avvio dei pod per Sidekiq richiedeva fino a . I lunghi tempi di avvio dei pod Sidekiq sono diventati un problema quando abbiamo iniziato a migrare i carichi di lavoro su Kubernetes per i lavoratori che avevano bisogno di elaborare rapidamente i lavori e scalarli rapidamente.
In questo caso, la lezione è stata che, sebbene l'Horizontal Pod Autoscaler (HPA) di Kubernetes gestisca bene la crescita del traffico, è importante considerare le caratteristiche dei carichi di lavoro e allocare capacità di riserva ai pod (soprattutto quando la domanda non è distribuita in modo uniforme). Nel nostro caso, si è verificato un improvviso aumento dei lavori, che ha portato a un rapido ridimensionamento, che ha portato alla saturazione delle risorse della CPU prima che avessimo il tempo di ridimensionare il pool di nodi.
C'è sempre la tentazione di spremere quanto più possibile da un cluster, tuttavia, avendo inizialmente riscontrato problemi di prestazioni, ora stiamo iniziando con un generoso budget per i pod e riducendolo in seguito, tenendo d'occhio gli SLO. Il lancio dei pod per il servizio Sidekiq ha subito un'accelerazione significativa e ora richiede in media circa 40 secondi. ha vinto sia GitLab.com che i nostri utenti di installazioni autogestite che lavorano con la tabella ufficiale GitLab Helm.
conclusione
Dopo la migrazione di ciascun servizio, ci siamo rallegrati dei vantaggi derivanti dall'utilizzo di Kubernetes in produzione: distribuzione delle applicazioni più rapida e sicura, scalabilità e allocazione delle risorse più efficiente. Inoltre, i vantaggi della migrazione vanno oltre il servizio GitLab.com. Ogni miglioramento alla tabella Helm ufficiale avvantaggia i suoi utenti.
Spero che la storia delle nostre avventure di migrazione su Kubernetes ti sia piaciuta. Continuiamo a migrare tutti i nuovi servizi nel cluster. Ulteriori informazioni possono essere reperite nelle seguenti pubblicazioni:
- «";
- «";
- .
PS da traduttore
Leggi anche sul nostro blog:
- «";
- «";
- «";
- «'.
Fonte: habr.com