{"id":94977,"date":"2020-09-24T07:43:00","date_gmt":"2020-09-24T05:43:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/nashi-vyvody-za-god-migraczii-gitlab-com-na-kubernetes"},"modified":"2020-09-24T07:43:00","modified_gmt":"2020-09-24T05:43:00","slug":"nashi-vyvody-za-god-migraczii-gitlab-com-na-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/nashi-vyvody-za-god-migraczii-gitlab-com-na-kubernetes","title":{"rendered":"Le nostre conclusioni sulla migrazione di GitLab.com su Kubernetes nell'anno passato.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i><b>Nota del traduttore.<\/b>: l'adattamento di Kubernetes in GitLab \u00e8 considerato uno dei due principali fattori alla base della 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 \u00e8 iniziata la sua migrazione in K8s, che non \u00e8 ancora completata. Siamo lieti di presentare la traduzione di un recente articolo di un ingegnere SRE di GitLab su come sta avvenendo questo processo e quali conclusioni traggono gli ingegneri coinvolti nel progetto.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Le nostre conclusioni sulla migrazione di GitLab.com su Kubernetes nell&#039;anno passato.\" src=\"\/wp-content\/uploads\/2020\/09\/58429abf60cd19a49c5ce593051c2fca.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDa circa un anno, il nostro dipartimento infrastrutturale si occupa della migrazione di tutti i servizi operanti su GitLab.com verso Kubernetes. Durante questo periodo, abbiamo affrontato problemi non solo relativi al trasferimento dei servizi su Kubernetes, ma anche alla gestione di un deployment ibrido durante la transizione. In questo articolo parleremo delle lezioni preziose che abbiamo appreso.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Sin dalla sua nascita, i server di GitLab.com hanno funzionato nel cloud su macchine virtuali. Queste macchine virtuali sono gestite da Chef, mentre la loro installazione avviene tramite il nostro <noindex><a rel=\"nofollow\" href=\"https:\/\/about.gitlab.com\/install\/#ubuntu\">pacchetto ufficiale per Linux<\/a><\/noindex>. <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-org\/release\/docs\/-\/blob\/master\/general\/deploy\/gitlab-com-deployer.md\">Strategia di deploy<\/a><\/noindex> nel caso sia necessario aggiornare l'applicazione, consiste in un semplice aggiornamento del parco server coordinato in modo sequenziale tramite una CI pipeline. Questo metodo \u2014 sebbene lento e un po' <noindex><a rel=\"nofollow\" href=\"https:\/\/about.gitlab.com\/handbook\/values\/#boring-solutions\">noioso<\/a><\/noindex> \u2014 garantisce che GitLab.com utilizzi gli stessi metodi di installazione e configurazione che usano gli utenti delle <i>(installazioni self-managed)<\/i> di GitLab, impiegando per questo i nostri pacchetti Linux.<\/p>\n<p>Adottiamo questo metodo perch\u00e9 \u00e8 assolutamente fondamentale sperimentare tutte le gioie e le difficolt\u00e0 che affrontano i membri comuni della comunit\u00e0 durante l'installazione e la configurazione delle proprie copie di GitLab. Questo approccio ha funzionato bene per un certo periodo, ma quando il numero di progetti su GitLab ha superato i 10 milioni, abbiamo capito che non soddisfaceva pi\u00f9 le nostre esigenze di scalabilit\u00e0 e distribuzione.<\/p>\n<h2>I primi passi verso Kubernetes e GitLab cloud-native<\/h2>\n<p>\nNel 2017, \u00e8 stato avviato il progetto <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-org\/charts\">GitLab Charts<\/a><\/noindex> per preparare GitLab per il deployment nel cloud e per consentire agli utenti di installare GitLab in cluster Kubernetes. Allora sapevamo che il trasferimento di GitLab in Kubernetes avrebbe aumentato le capacit\u00e0 di scalabilit\u00e0 della piattaforma SaaS, semplificato i deployment e migliorato l'efficienza dell'uso delle risorse computazionali. Tuttavia, molte funzionalit\u00e0 della nostra applicazione dipendevano da partizioni NFS montate, il che rallentava la transizione dalle macchine virtuali.<\/p>\n<p>La spinta verso il cloud native e Kubernetes ha permesso ai nostri ingegneri di pianificare una transizione graduale, durante la quale abbiamo abbandonato alcune dipendenze dell'applicazione dai storage di rete, continuando nel frattempo a sviluppare nuove funzionalit\u00e0. Da quando abbiamo iniziato a pianificare la migrazione nell'estate del 2019, molte di queste limitazioni sono state eliminate, e il processo di trasferimento di GitLab.com su Kubernetes sta ora procedendo a ritmo intenso!<\/p>\n<h2>Caratteristiche operative di GitLab.com in Kubernetes<\/h2>\n<p>\nPer GitLab.com utilizziamo un cluster GKE regionale unificato che gestisce tutto il traffico dell'applicazione. Per minimizzare la complessit\u00e0 (gi\u00e0 piuttosto intricata) della migrazione, ci concentriamo sui servizi che non dipendono da storage locali o NFS. GitLab.com utilizza principalmente una base di codice monolitica su Rails e reindirizziamo il traffico a vari endpoint, isolati in propri pool di nodi, in base alle caratteristiche del carico di lavoro.<\/p>\n<p>Nel caso del frontend, questi tipi di traffico si dividono in richieste web, API, Git SSH\/HTTPS e Registry. Per quanto riguarda il backend, suddividiamo i job in coda in diverse categorie a seconda delle <noindex><a rel=\"nofollow\" href=\"https:\/\/about.gitlab.com\/blog\/2020\/06\/24\/scaling-our-use-of-sidekiq\/\">limiti di risorse predefiniti<\/a><\/noindex>, che ci consentono di impostare obiettivi di livello di servizio (Service-Level Objectives, SLO) per i vari carichi.<\/p>\n<p>Tutti questi servizi di GitLab.com sono configurati utilizzando la chart Helm di GitLab non modificata. La configurazione avviene nei sub-chart, che possono essere inclusi selettivamente man mano che trasferiamo gradualmente i servizi nel cluster. Anche se \u00e8 stato deciso di non includere nella migrazione alcuni dei nostri servizi stateful, come Redis, Postgres, GitLab Pages e Gitaly, l'uso di Kubernetes consente di ridurre radicalmente il numero di VM gestite attualmente da Chef.<\/p>\n<h2>Trasparenza e gestione della configurazione di Kubernetes<\/h2>\n<p>\nTutte le configurazioni sono gestite dallo stesso GitLab. Per questo utilizziamo tre progetti di configurazione basati su Terraform e Helm. Cerchiamo di utilizzare GitLab per eseguire GitLab il pi\u00f9 possibile, ma per le operazioni abbiamo una distribuzione separata di GitLab. Questa \u00e8 necessaria per non dipendere dalla disponibilit\u00e0 di GitLab.com durante i deployment e gli aggiornamenti di GitLab.com.<\/p>\n<p>Sebbene le nostre pipeline per il cluster Kubernetes funzionino su un'installazione separata di GitLab, ci sono specchi dei repository di codice accessibili pubblicamente ai seguenti indirizzi:<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-com\/gl-infra\/k8s-workloads\/gitlab-com\">k8s-workloads\/gitlab-com<\/a><\/noindex> \u2014 wrapper di configurazione di GitLab.com per la chart Helm di GitLab;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-com\/gl-infra\/k8s-workloads\/gitlab-helmfiles\/\">k8s-workloads\/gitlab-helmfiles<\/a><\/noindex> \u2014 contiene configurazioni per i servizi che non sono direttamente associati all'applicazione GitLab. Queste includono configurazioni per la registrazione e il monitoraggio del cluster, oltre a strumenti integrati come PlantUML;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-com\/gitlab-com-infrastructure\">Gitlab-com-infrastructure<\/a><\/noindex> \u2014 configurazione Terraform per Kubernetes e l'infrastruttura VM legacy. Qui si impostano tutte le risorse necessarie per avviare il cluster, inclusi il cluster stesso, i pool di nodi, gli account di servizio e il riservamento degli indirizzi IP.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"Le nostre conclusioni sulla migrazione di GitLab.com su Kubernetes nell&#039;anno passato.\" src=\"\/wp-content\/uploads\/2020\/09\/612125403171d73106a081bf4244a52b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Le modifiche apportate vengono mostrate pubblicamente <\/i><noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-com\/gl-infra\/k8s-workloads\/gitlab-com\/-\/merge_requests\/315#note_390180361\"><i>un riepilogo<\/i><\/a><\/noindex><i> con un link al diff dettagliato che gli SRE analizzano prima di apportare modifiche al cluster.<\/i><\/p>\n<p>Per SRE, il link porta a una diff dettagliata nella distribuzione di GitLab utilizzata per le operazioni, alla quale l'accesso \u00e8 limitato. Questo consente ai dipendenti e alla comunit\u00e0 senza accesso al progetto operativo (che \u00e8 aperto solo per SRE) di visualizzare le modifiche proposte nella configurazione. Combinando un'istanza pubblica di GitLab per il codice con un'istanza chiusa per le pipeline CI, manteniamo un flusso di lavoro unico, garantendo al contempo indipendenza da GitLab.com durante gli aggiornamenti della configurazione.<\/p>\n<h2>Cosa abbiamo appreso durante la migrazione<\/h2>\n<p>\nDurante il processo di migrazione abbiamo acquisito esperienze che applichiamo a nuove migrazioni e deployment in Kubernetes.<\/p>\n<h3>1. Aumento dei costi dovuto al traffico tra le zone di disponibilit\u00e0<\/h3>\n<p>\n<img decoding=\"async\" alt=\"Le nostre conclusioni sulla migrazione di GitLab.com su Kubernetes nell&#039;anno passato.\" src=\"\/wp-content\/uploads\/2020\/09\/3dce44b3f803ffcea13e0101e7343d91.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Statistiche giornaliere di egress (byte al giorno) per il parco di repository Git su GitLab.com<\/i><\/p>\n<p>Google suddivide la sua rete in regioni. Queste ultime sono suddivise in zone di disponibilit\u00e0 (AZ). L'hosting Git \u00e8 associato a grandi volumi di dati, quindi \u00e8 fondamentale controllare l'egress di rete. Nel caso del traffico interno, l'egress \u00e8 gratuito solo se rimane all'interno di una singola zona di disponibilit\u00e0. Al momento della scrittura di questo articolo, stiamo trasferendo circa 100 TB di dati in un giorno lavorativo normale (e questo \u00e8 solo per i repository Git). I servizi che nella nostra vecchia topologia basata su VM si trovavano sulle stesse macchine virtuali ora operano in diversi pod di Kubernetes. Questo significa che una parte del traffico, che prima era locale per le VM, pu\u00f2 potenzialmente uscire dai confini delle zone di disponibilit\u00e0.<\/p>\n<p>I cluster regionali GKE consentono di coprire pi\u00f9 zone di disponibilit\u00e0 per la ridondanza. Stiamo considerando la possibilit\u00e0 <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-com\/gl-infra\/delivery\/-\/issues\/1175\">di suddividere il cluster regionale GKE in cluster a zona singola<\/a><\/noindex> per i servizi che generano grandi volumi di traffico. Questo permetter\u00e0 di ridurre i costi dell'egress mantenendo la ridondanza a livello di cluster.<\/p>\n<h3>2. Limiti, richieste di risorse e scalabilit\u00e0<\/h3>\n<p>\n<img decoding=\"async\" alt=\"Le nostre conclusioni sulla migrazione di GitLab.com su Kubernetes nell&#039;anno passato.\" src=\"\/wp-content\/uploads\/2020\/09\/6e2e1ca4d37666b49358d94cd8660c56.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Il numero di repliche che gestiscono il traffico di produzione su registry.gitlab.com. Il traffico raggiunge il suo picco intorno alle 15:00 UTC.<\/i><\/p>\n<p>La nostra storia di migrazione \u00e8 iniziata nell'agosto 2019, quando abbiamo trasferito il primo servizio \u2014 il registro dei container GitLab (GitLab Container Registry) \u2014 in Kubernetes. Questo servizio critico con alti volumi di traffico si \u00e8 rivelato adatto per la prima migrazione, poich\u00e9 rappresenta un'applicazione stateless con poche dipendenze esterne. Il primo problema che abbiamo affrontato \u00e8 stato il gran numero di pod espulsi a causa di carenza di memoria sui nodi. Questo ci ha costretti a modificare le richieste e i limiti.<\/p>\n<p>\u00c8 stato rilevato che, nel caso di un'applicazione il cui consumo di memoria cresce nel tempo, valori bassi per le richieste (che riservano memoria per ogni pod) associati a un limite 'generoso' sull'uso portavano a... <i>(saturazione)<\/i> dei nodi e a un alto livello di espulsione. Per affrontare questo problema, \u00e8 stato <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-com\/gl-infra\/delivery\/-\/issues\/998#note_388983696\">\u00e8 stato deciso di aumentare le richieste e ridurre i limiti.<\/a><\/noindex>. Questo ha alleviato la pressione sui nodi e assicurato un ciclo di vita dei pod che non esercitava una pressione eccessiva sul nodo. Ora iniziamo le migrazioni con valori richiesti e limiti generosi (e quasi identici), correggendoli secondo necessit\u00e0.<\/p>\n<h3>3. Metriche e log<\/h3>\n<p>\n<img decoding=\"async\" alt=\"Le nostre conclusioni sulla migrazione di GitLab.com su Kubernetes nell&#039;anno passato.\" src=\"\/wp-content\/uploads\/2020\/09\/66d1fd47b57d5826f13defa6e6a7fe3c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Il reparto infrastrutture si concentra sui ritardi, sulla percentuale di errori e sulla saturazione rispetto agli obiettivi stabiliti <\/i><noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Service-level_objective\"><i>per il livello di servizio<\/i><\/a><\/noindex><i> (SLO), legati a <\/i><noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-com\/dashboards-gitlab-com\/-\/metrics\/sla-dashboard.yml?environment=1790496&amp;duration_seconds=86400\"><i>disponibilit\u00e0 complessiva del nostro sistema.<\/i><\/a><\/noindex><i>.<\/i><\/p>\n<p>Nel corso dell'ultimo anno, uno degli eventi chiave nel reparto infrastrutture \u00e8 stato il miglioramento nel monitoraggio e nella gestione degli SLO. Gli SLO ci hanno permesso di stabilire obiettivi per singoli servizi, che abbiamo monitorato attentamente durante la migrazione. Tuttavia, anche con una visibilit\u00e0 migliorata, non \u00e8 sempre possibile rilevare subito i problemi utilizzando metriche e avvisi. Ad esempio, concentrandoci sui ritardi e sulla percentuale di errori, non copriamo completamente tutti gli scenari d'uso del servizio in fase di migrazione.<\/p>\n<p>Questo problema \u00e8 stato riscontrato quasi subito dopo il trasferimento di parte dei carichi di lavoro nel cluster. Si \u00e8 manifestato in particolare quando \u00e8 stato necessario testare le funzionalit\u00e0, il cui numero di richieste \u00e8 ridotto, ma con dipendenze di configurazione molto specifiche. Una delle lezioni chiave apprese dalla migrazione \u00e8 stata la necessit\u00e0 di tenere conto nel monitoraggio non solo delle metriche, ma anche dei log e del \"long tail\". <i>(si tratta di <\/i><noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Long_tail\"><i>tale distribuzione<\/i><\/a><\/noindex><i> nel grafico \u2014 nota del traduttore)<\/i> di errori. Ora per ogni migrazione includiamo un elenco dettagliato delle richieste ai log <i>(log queries)<\/i> e pianifichiamo procedure di rollback chiare, che in caso di problemi possano essere trasferite da un turno all'altro.<\/p>\n<p>La gestione parallela delle stesse richieste sull'infrastruttura VM vecchia e su quella nuova basata su Kubernetes rappresentava una sfida unica. A differenza della migrazione tipo lift-and-shift <i>(trasferimento rapido delle applicazioni \"cos\u00ec come sono\" nella nuova infrastruttura; si pu\u00f2 approfondire, ad esempio, <\/i><noindex><a rel=\"nofollow\" href=\"https:\/\/www.ibm.com\/cloud\/learn\/lift-and-shift\"><i>qui<\/i><\/a><\/noindex><i> \u2014 nota di traduzione)<\/i>, il funzionamento parallelo su VM \"vecchie\" e Kubernetes richiede che gli strumenti di monitoraggio siano compatibili con entrambi gli ambienti e siano in grado di unire le metriche in un'unica vista. \u00c8 fondamentale utilizzare gli stessi dashboard e le stesse query sui log per garantire una visibilit\u00e0 coerente durante il periodo di transizione.<\/p>\n<h3>4. Reindirizzamento del traffico al nuovo cluster<\/h3>\n<p>\nPer GitLab.com, parte dei server \u00e8 riservata alla <noindex><a rel=\"nofollow\" href=\"https:\/\/about.gitlab.com\/handbook\/engineering\/#canary-testing\">fase canary<\/a><\/noindex>. Il parco canary gestisce i nostri progetti interni e pu\u00f2 <noindex><a rel=\"nofollow\" href=\"https:\/\/next.gitlab.com\/\">essere attivato dagli utenti<\/a><\/noindex>. Tuttavia, \u00e8 principalmente destinato a testare le modifiche apportate all'infrastruttura e all'applicazione. Il primo servizio migrato ha iniziato ad accettare un volume limitato di traffico interno e continuiamo a utilizzare questo metodo per garantire il rispetto degli SLO prima di indirizzare tutto il traffico verso il cluster.<\/p>\n<p>In caso di migrazione, questo significa che inizialmente le richieste in Kubernetes vengono dirette ai progetti interni e poi gradualmente switchiamo il resto del traffico sul cluster modificando il peso per il backend tramite HAProxy. Durante il passaggio da VM a Kubernetes, \u00e8 diventato evidente che avere un semplice modo per reindirizzare il traffico tra la vecchia e la nuova infrastruttura \u00e8 molto vantaggioso e, di conseguenza, mantenere la vecchia infrastruttura pronta per il rollback nei primi giorni dopo la migrazione.<\/p>\n<h3>5. Capacit\u00e0 di riserva dei pod e il loro utilizzo<\/h3>\n<p>\nQuasi immediatamente \u00e8 emerso un altro problema: i pod per il servizio Registry si avviavano rapidamente, tuttavia il avvio dei pod per Sidekiq richiedeva fino a... <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-org\/charts\/gitlab\/-\/issues\/1775\">due minuti.<\/a><\/noindex>. L'avvio prolungato dei pod per Sidekiq \u00e8 diventato un problema quando abbiamo iniziato a migrare i carichi di lavoro in Kubernetes per i worker, i quali devono elaborare rapidamente i job e scalare velocemente.<\/p>\n<p>In questo caso, la lezione era che, sebbene l'Horizontal Pod Autoscaler (HPA) in Kubernetes gestisca bene l'aumento del traffico, \u00e8 importante considerare le caratteristiche dei carichi di lavoro e riservare potenzialit\u00e0 extra ai pod (soprattutto in condizioni di domanda irregolare). Nel nostro caso, abbiamo osservato un'improvvisa impennata di job, che ha portato a un rapido scaling, saturando le risorse CPU prima che potessimo scalare il pool di nodi.<\/p>\n<p>C'\u00e8 sempre la tentazione di sfruttare al massimo il cluster, tuttavia, dopo aver inizialmente affrontato problemi di prestazioni, ora partiamo con un budget di pod generoso e lo riduciamo successivamente, monitorando attentamente gli SLO. L'avvio dei pod per il servizio Sidekiq \u00e8 notevolmente accelerato e ora richiede in media circa 40 secondi. <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-org\/charts\/gitlab\/-\/issues\/1775\">Dalla riduzione del tempo di avvio dei pod<\/a><\/noindex> sia GitLab.com che i nostri utenti delle installazioni self-managed, che utilizzano il chart Helm ufficiale di GitLab, ne hanno beneficiato.<\/p>\n<h2>Conclusione<\/h2>\n<p>\nDopo la migrazione di ciascun servizio, abbiamo apprezzato i vantaggi dell'utilizzo di Kubernetes in produzione: un deploy pi\u00f9 veloce e sicuro delle applicazioni, scalabilit\u00e0 e una distribuzione delle risorse pi\u00f9 efficiente. Inoltre, i benefici della migrazione superano il servizio di GitLab.com. Ogni miglioramento dell'Helm chart ufficiale porta vantaggi anche agli utenti.<\/p>\n<p>Spero che vi sia piaciuta la storia delle nostre avventure con la migrazione su Kubernetes. Continuiamo a trasferire sempre pi\u00f9 servizi nel cluster. Ulteriori informazioni possono essere trovate nelle seguenti pubblicazioni:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/about.gitlab.com\/handbook\/engineering\/infrastructure\/production\/kubernetes\/gitlab-com\/\">Perch\u00e9 stiamo migrando su Kubernetes?<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/about.gitlab.com\/handbook\/engineering\/infrastructure\/production\/architecture\/#gitlab-com-on-kubernetes\">GitLab.com su Kubernetes<\/a><\/noindex>\u00bb;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/groups\/gitlab-com\/gl-infra\/-\/epics\/112\">Epic di migrazione di GitLab.com su Kubernetes<\/a><\/noindex>.<\/li>\n<\/ul>\n<p><\/p>\n<h2>P.S. dal traduttore<\/h2>\n<p>\nLeggete anche nel nostro blog:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/519962\/\">3 anni con Kubernetes in produzione: ecco cosa abbiamo capito<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/504396\/\">10 errori comuni nell'utilizzo di Kubernetes<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/335814\/\">Storie di successo di Kubernetes in produzione. Parte 3: GitHub<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/440278\/\">Il passaggio di Tinder a Kubernetes<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/520150\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u0430\u0434\u0430\u043f\u0442\u0430\u0446\u0438\u044e Kubernetes \u0432 GitLab \u0441\u0447\u0438\u0442\u0430\u044e\u0442 \u043e\u0434\u043d\u0438\u043c \u0438\u0437 \u0434\u0432\u0443\u0445 \u0433\u043b\u0430\u0432\u043d\u044b\u0445 \u0444\u0430\u043a\u0442\u043e\u0440\u043e\u0432, \u0441\u043f\u043e\u0441\u043e\u0431\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445 \u0440\u043e\u0441\u0442\u0443 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438. \u0422\u0435\u043c \u043d\u0435 \u043c\u0435\u043d\u0435\u0435, \u0434\u043e \u043d\u0435\u0434\u0430\u0432\u043d\u0435\u0433\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0438 \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0430 \u043e\u043d\u043b\u0430\u0439\u043d-\u0441\u0435\u0440\u0432\u0438\u0441\u0430 GitLab.com \u0431\u044b\u043b\u0430 \u043f\u043e\u0441\u0442\u0440\u043e\u0435\u043d\u0430 \u043d\u0430 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u044b\u0445 \u043c\u0430\u0448\u0438\u043d\u0430\u0445, \u0438 \u0442\u043e\u043b\u044c\u043a\u043e \u043e\u043a\u043e\u043b\u043e \u0433\u043e\u0434\u0430 \u043d\u0430\u0437\u0430\u0434 \u043d\u0430\u0447\u0430\u043b\u0430\u0441\u044c \u0435\u0451 \u043c\u0438\u0433\u0440\u0430\u0446\u0438\u044f \u0432 K8s, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0434\u043e \u0441\u0438\u0445 \u043f\u043e\u0440 \u043d\u0435 \u0437\u0430\u0432\u0435\u0440\u0448\u0435\u043d\u0430. \u0420\u0430\u0434\u044b \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u0442\u044c \u043f\u0435\u0440\u0435\u0432\u043e\u0434 \u043d\u0435\u0434\u0430\u0432\u043d\u0435\u0439 \u0441\u0442\u0430\u0442\u044c\u0438 SRE-\u0438\u043d\u0436\u0435\u043d\u0435\u0440\u0430 GitLab \u043e \u0442\u043e\u043c, \u043a\u0430\u043a [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":94978,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-94977","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.0.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u0430\u0434\u0430\u043f\u0442\u0430\u0446\u0438\u044e Kubernetes \u0432 GitLab \u0441\u0447\u0438\u0442\u0430\u044e\u0442 \u043e\u0434\u043d\u0438\u043c \u0438\u0437 \u0434\u0432\u0443\u0445 \u0433\u043b\u0430\u0432\u043d\u044b\u0445 \u0444\u0430\u043a\u0442\u043e\u0440\u043e\u0432, \u0441\u043f\u043e\u0441\u043e\u0431\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445 \u0440\u043e\u0441\u0442\u0443 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/nashi-vyvody-za-god-migraczii-gitlab-com-na-kubernetes\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.0.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041d\u0430\u0448\u0438 \u0432\u044b\u0432\u043e\u0434\u044b \u0437\u0430 \u0433\u043e\u0434 \u043c\u0438\u0433\u0440\u0430\u0446\u0438\u0438 GitLab.com \u043d\u0430 Kubernetes | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u0430\u0434\u0430\u043f\u0442\u0430\u0446\u0438\u044e Kubernetes \u0432 GitLab \u0441\u0447\u0438\u0442\u0430\u044e\u0442 \u043e\u0434\u043d\u0438\u043c \u0438\u0437 \u0434\u0432\u0443\u0445 \u0433\u043b\u0430\u0432\u043d\u044b\u0445 \u0444\u0430\u043a\u0442\u043e\u0440\u043e\u0432, \u0441\u043f\u043e\u0441\u043e\u0431\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445 \u0440\u043e\u0441\u0442\u0443 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/nashi-vyvody-za-god-migraczii-gitlab-com-na-kubernetes\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-09-24T05:43:00+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-09-24T05:43:00+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47 Le nostre conclusioni dopo un anno di migrazione di GitLab.com su Kubernetes | ProHoster","description":"Nota del traduttore: l'adattamento di Kubernetes in GitLab \u00e8 considerato uno dei due principali fattori che favoriscono la crescita dell'azienda.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/nashi-vyvody-za-god-migraczii-gitlab-com-na-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041d\u0430\u0448\u0438 \u0432\u044b\u0432\u043e\u0434\u044b \u0437\u0430 \u0433\u043e\u0434 \u043c\u0438\u0433\u0440\u0430\u0446\u0438\u0438 GitLab.com \u043d\u0430 Kubernetes | ProHoster","og:description":"\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u0430\u0434\u0430\u043f\u0442\u0430\u0446\u0438\u044e Kubernetes \u0432 GitLab \u0441\u0447\u0438\u0442\u0430\u044e\u0442 \u043e\u0434\u043d\u0438\u043c \u0438\u0437 \u0434\u0432\u0443\u0445 \u0433\u043b\u0430\u0432\u043d\u044b\u0445 \u0444\u0430\u043a\u0442\u043e\u0440\u043e\u0432, \u0441\u043f\u043e\u0441\u043e\u0431\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445 \u0440\u043e\u0441\u0442\u0443 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/nashi-vyvody-za-god-migraczii-gitlab-com-na-kubernetes","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-09-24T05:43:00+00:00","article:modified_time":"2020-09-24T05:43:00+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"94977","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 11:14:45","updated":"2022-10-03 07:39:43","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/94977","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=94977"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/94977\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/94978"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=94977"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=94977"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=94977"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}