Alla fine di maggio abbiamo condotto un meetup online sul tema . Abbiamo parlato di container, Kubernetes e orchestrazione in generale, sui criteri di scelta dell'infrastruttura e molto altro. I partecipanti hanno condiviso casi dalla propria esperienza.
Partecipanti:
- Evgenij Potapov, CEO «ITSumma». Più della metà dei suoi clienti sta già passando o desidera passare a Kubernetes.
- Dmitrij Stoljarov, CTO «Flant». Ha oltre 10 anni di esperienza con sistemi containerizzati.
- Denis Remchukov (aka Eric Oldmann), COO argotech.io, ex-RAO EES. Ha promesso di raccontare casi dal «bloody» enterprise.
- Andrej Fedorovskij, CTO «News360.com»Dopo l'acquisto dell'azienda da parte di un altro attore, è responsabile di vari progetti ML e AI e dell'infrastruttura.
- Ivan Kruglov, ingegnere di sistema, ex–Booking.com.Proprio quell'uomo che ha fatto molto con Kubernetes con le sue mani.
Temi:
- Insight dei partecipanti sui container e sull'orchestrazione (Docker, Kubernetes e altro); cosa hanno provato nella pratica o analizzato.
- Caso: L'azienda sta costruendo un piano di sviluppo dell'infrastruttura per anni. Come viene presa la decisione di costruire (o migrare l'attuale) infrastruttura su container e Kubernetes o meno?
- Problemi nel mondo del cloud-native, cosa manca, facciamo delle fantasie su cosa ci sarà domani.
Si è instaurata una discussione interessante, le opinioni dei partecipanti erano così diverse e hanno suscitato così tanti commenti che vogliamo condividerli con voi. C'è , e qui sotto – un sunto della discussione.
Kubernetes è già uno standard o una grande strategia di marketing?
«Siamo arrivati a lui (Kubernetes. — Ndr.) quando ancora nessuno sapeva di cosa si trattasse. Siamo arrivati a lui quando non esisteva ancora. Lo volevamo già prima» — Dmitrij Stoljarov
Foto da Reddit.com
Cinque-dieci anni fa esistevano una miriade di strumenti, e non c'era uno standard unico. Ogni sei mesi appariva un nuovo prodotto, e a volte anche più di uno. Prima Vagrant, poi Salt, Chef, Puppet,… «e dovevi ricostruire la tua infrastruttura ogni sei mesi. Avevi cinque amministratori impegnati a riscrivere costantemente le configurazioni» — ricorda Andrej Fedorovskij. Ritiene che Docker e Kubernetes abbiano «soppiantato» gli altri. Docker è diventato uno standard negli ultimi cinque anni, Kubernetes — negli ultimi due anni. E questo è positivo per l'industria..
Dmitry Stolyarov e il suo team amano Kubernetes. Hanno desiderato questo strumento prima che fosse disponibile e si sono avvicinati a esso quando nessuno ne era a conoscenza. Al momento, per comodità, non prendono clienti se comprendono che non implementeranno Kubernetes. Secondo Dmitry, l'azienda ha "moltissime storie di successo gigantesche nella trasformazione di terribili legacy".
Kubernetes non è solo orchestrazione di container, ma un sistema di gestione della configurazione con API avanzata, un componente di rete, bilanciamento L3 e controller Ingress, che consente di gestire relativamente facilmente le risorse, scalare e astrarsi dai livelli inferiori dell'infrastruttura.
Sfortunatamente, nella nostra vita bisogna pagare per tutto. E questa tassa è alta, soprattutto quando si parla della transizione verso Kubernetes per aziende con infrastrutture consolidate, secondo Ivan Kruglov. Potrebbe lavorare facilmente sia in un'azienda con un'infrastruttura tradizionale che con Kubernetes. È fondamentale comprendere le peculiarità dell'azienda e del mercato. Ma, ad esempio, per Yevgeny Potapov, che generalizzerebbe Kubernetes a qualsiasi strumento di orchestrazione di container, questo problema non si pone.
Yevgeny ha fatto un'analogia con la situazione degli anni '90, quando è emersa la programmazione orientata agli oggetti come modo per programmare applicazioni complesse. In quel momento, i dibattiti non si fermavano e comparivano nuovi strumenti che supportavano l'OOP. Poi sono emersi i microservizi come modo per allontanarsi dal concetto monolitico. Questo, a sua volta, ha portato alla nascita dei container e degli strumenti per la loro gestione. "Credo che presto arriveremo a un momento in cui non ci si chiederà se valga la pena scrivere un'applicazione piccola in microservizi, sarà scritta automaticamente come microservizio", afferma. Allo stesso modo, Docker e Kubernetes diventeranno nel tempo soluzioni standard senza necessità di scelta.
Il problema delle basi è stateless
Foto di
Ogni giorno ci sono molti ricette per avviare database in Kubernetes. Anche su come separare la parte che lavora con il disco I/O dalla parte, in modo condizionale, dell'applicazione del database. È possibile che in futuro i database si trasformino così tanto da essere forniti in un pacchetto in cui una parte sarà orchestrata tramite Docker e Kubernetes, mentre l'altra parte dell'infrastruttura, tramite un software separato, fornirà la parte di storage? I database si trasformeranno come prodotto?
Questa descrizione ricorda la gestione delle code, ma le richieste per l'affidabilità e la sincronizzazione delle informazioni nei database tradizionali sono molto più elevate, sostiene Andrey. Il cache hit ratio nei database normali si mantiene attorno al 99%. Se un worker si ferma, ne viene avviato un altro e la cache viene "riscaldata" da zero. Finché la cache non è riscaldata, il worker lavora lentamente, quindi non si può caricare un carico utente. Senza carico utente, la cache non viene riscaldata. È un circolo vizioso.
Dmitry è totalmente in disaccordo: i quorum e lo sharding risolvono il problema. Ma Andrey insiste che la soluzione non è adatta a tutti. In alcune situazioni un quorum può funzionare, ma comporta un carico aggiuntivo sulla rete. Un database NoSQL non è adatto in tutti i casi.
I partecipanti al meet-up si sono divisi in due fazioni.
Denis e Andrey affermano che tutto ciò che scrive su disco — database e altro — non è possibile realizzare nell'attuale ecosistema di Kubernetes. È impossibile mantenere l'integrità e la coerenza dei dati produttivi in Kubernetes. Questa è una caratteristica fondamentale. Soluzione: infrastruttura ibrida.
Anche i moderni database cloud native, come MongoDB e Cassandra, o le code di messaggi, come Kafka o RabbitMQ, richiedono costanti archiviazioni di dati al di fuori di Kubernetes.
Eugene obietta: «I database in Kubernetes sono un trauma quasi russo o quasi aziendale, legato al fatto che in Russia non c'è adozione del cloud». Le piccole o medie imprese in occidente sono cloud. Utilizzare i database Amazon RDS è più semplice che gestire Kubernetes da soli. In Russia si utilizza Kubernetes "on-premise" e si trasferiscono in esso i database quando si cerca di liberarsi dello zoo tecnico.
Dmitry non è d'accordo con l'affermazione che non si possono mantenere database in Kubernetes: «Un database non è come un altro. Se si inserisce un enorme database relazionale — allora assolutamente no. Se si mette qualcosa di piccolo e cloud native, pronto a una vita semi-efimerale, andrà tutto bene.» Dmitry ha anche menzionato che gli strumenti di gestione dei database non sono pronti né per Docker né per Kubernetes, quindi sorgono grandi problemi.
Ivan, da parte sua, è certo che anche se si astraesse dai concetti di stateful e stateless, l'ecosistema delle soluzioni enterprise in Kubernetes non è ancora pronto. Con Kubernetes è difficile soddisfare i requisiti delle autorità legislative e regolatorie. Ad esempio, non è possibile implementare una soluzione di identity provision che richieda garanzie rigorose di identificazione del server, fino all'hardware inserito nei server. Questo settore si sta sviluppando, ma al momento non esiste una soluzione.
I partecipanti non sono riusciti a trovare un accordo, pertanto non ci saranno conclusioni in questa parte. Ecco alcuni casi pratici.
Caso 1. Sicurezza informatica del «megaregulator» con database esterni a Kubernetes
In caso di un sistema di cybersecurity sviluppato, l'uso di contenitori e orchestrazione consente di difendersi da attacchi e intrusioni. Ad esempio, in un megaregulator, Denis e il suo team hanno implementato un legame tra l'orchestratore e un servizio SIEM addestrato, che analizza i log in tempo reale e determina il processo di attacco, violazione o guasto. In caso di attacco, tentativi di caricare qualcosa o durante un'intrusione da parte di un ransomware, il sistema solleva i contenitori con le applicazioni più velocemente di quanto possano infettarsi, o più velocemente di quanto possa attaccarli l'aggressore.
Caso 2. Parziale migrazione dei database di Booking.com in Kubernetes
In Booking.com, il database principale è MySQL con replica asincrona: c'è un master e un'intera gerarchia di slave. Al momento della partenza di Ivan dall'azienda, era stato avviato un progetto per trasferire gli slave, che possono essere «deportati» con un certo danno.
Oltre al database principale, esiste un'installazione di Cassandra con orchestrazione personalizzata, creata ancor prima che Kubernetes diventasse mainstream. Non ci sono problemi in questo senso, ma essa conserva persistentemente su SSD locali. I repository remoti, anche all'interno dello stesso data center, non vengono utilizzati a causa di problemi di elevata latenza.
La terza classe di database è il servizio di ricerca di Booking.com, dove ogni nodo del servizio è un database. I tentativi di migrare il servizio di ricerca in Kubernetes non sono andati a buon fine, poiché ogni nodo ha 60-80 GB di storage locale, che è difficile da «sollevare» e «riscaldare».
Di conseguenza, il motore di ricerca non è stato migrato in Kubernetes, e Ivan non pensa che ci saranno nuovi tentativi nel prossimo futuro. Il database MySQL è stato trasferito solo parzialmente: solo gli slave, che non sono un problema «deportare». Cassandra si è adattata perfettamente.
La scelta dell'infrastruttura come compito senza soluzione generale
Foto di
Supponiamo di avere una nuova azienda, o un'azienda in cui parte dell'infrastruttura è stata costruita in modo tradizionale. In essa si sta elaborando un piano di sviluppo dell'infrastruttura per gli anni a venire. Come si decide se costruire l'infrastruttura su container e Kubernetes o meno?
Le aziende che si battono per i nanosecondi sono escluse dalla discussione. Un sano conservatorismo si ripaga per motivi di affidabilità, ma ci sono comunque aziende che dovrebbero considerare nuovi approcci.
Ivan: «Sicuramente adesso avvierei un'azienda nel cloud, semplicemente perché è più veloce», anche se non necessariamente più economico. Con lo sviluppo del capitale di rischio, le startup non hanno grandi problemi di denaro e l'obiettivo principale è conquistare il mercato.
Ivan sostiene che lo sviluppo dell'infrastruttura attuale è un criterio di scelta. Se in passato ci sono stati investimenti significativi e funziona, non ha senso rifarlo. Se invece l'infrastruttura non è sviluppata e ci sono problemi con gli strumenti, la sicurezza e il monitoraggio, ha senso considerare un'infrastruttura distribuita.
Le tasse dovranno essere pagate in ogni caso, e Ivan pagherebbe quella che gli consentirebbe in futuro di pagare meno. «Perché semplicemente viaggiando su un treno trainato da altri, percorrerò molta più distanza rispetto a se salissi su un altro treno, nel quale devo mettere io stesso il carburante.» — dice Ivan. Quando l'azienda è nuova e i requisiti per la latenza sono di decine di millisecondi, Ivan guarderebbe verso gli «operatori», dove oggi si «inseriscono» i database classici. Questi sollevano una catena di replica che si commuta automaticamente in caso di failover, e così via...
Per una piccola azienda con un paio di server in Kubernetes non ha senso, - afferma Andrey. Ma se si prevede di crescere fino a cento server e oltre, allora è necessaria l'automazione e un sistema di gestione delle risorse. Nel 90% dei casi, i costi si ripagano. Questo vale indipendentemente dal livello di carico e risorse. A tutti, dalle startup fino alle grandi aziende con un milione di utenti, conviene cominciare a guardare ai prodotti per l'orchestrazione dei container. «Sì, questo è davvero il futuro», è convinto Andrey.
Denis ha identificato due criteri principali - scalabilità e resilienza delle operazioni. Sceglierà quegli strumenti che si adattano meglio a questo compito. «Può essere un no-name assemblato a mano, con Nutanix Community Edition. Può essere una seconda linea in forma di applicazione su Kuber con un database sul backend, che viene replicato e ha parametri RTO e RPO definiti» (obiettivi di recovery time/point — esempio).
Evgeny ha evidenziato un possibile problema con le risorse umane. Al momento, non ci sono molti specialisti di alto livello sul mercato che comprendano «le interiora» della tecnologia. Infatti, se la tecnologia scelta è obsoleta, è difficile assumere qualcuno che non sia molto anziano e stanco della vita. Tuttavia, altri partecipanti ritengono che si tratti di una questione di formazione delle risorse umane.
Se poniamo la questione della scelta: avviare una piccola azienda nel Public Cloud con database in Amazon RDS o “on premise” con database in Kubernetes, nonostante alcuni svantaggi, la scelta dei partecipanti è ricaduta su Amazon RDS.
Poiché la maggior parte degli ascoltatori del meetup non proviene dal «cruento» enterprise, le soluzioni distribuite sono ciò a cui bisogna aspirare. I sistemi di archiviazione dei dati devono essere distribuiti, affidabili e creare latenze misurabili in millisecondi, al massimo in decine di millisecondi., ha riassunto Andrey.
Valutazione dell'utilizzo di Kubernetes
L'ascoltatore Anton Zhbankov ha posto una trappola per gli apologeti di Kubernetes: come hanno scelto e fatto la valutazione tecnico-economica? Perché Kubernetes, perché non macchine virtuali, ad esempio?
Foto di
A questa domanda hanno risposto Dmitry e Ivan. In entrambi i casi, attraverso un processo di tentativi ed errori, è stata elaborata una sequenza di decisioni, che ha portato entrambi i partecipanti a scegliere Kubernetes. Ora le aziende iniziano a sviluppare autonomamente software che ha senso trasferire su Kubernetes. Non si parla di sistemi terzi classici, come 1C. Kubernetes è utile quando gli sviluppatori devono rilasciare rapidamente aggiornamenti, in un continuo miglioramento senza interruzioni.
Il team di Andrey ha provato a realizzare un cluster scalabile basato su macchine virtuali. I nodi cadevano come pedine del domino, il che a volte portava al crollo del cluster. «Teoricamente si può continuare a implementarlo e mantenerlo manualmente, ma è faticoso. E se sul mercato esiste una soluzione che funziona subito, ci dirigiamo verso di essa con piacere. Ed è ciò che abbiamo fatto», racconta Andrey.
Esistono standard per tale analisi e calcolo, ma nessuno può dire quanto siano validi su hardware reale in uso. È inoltre importante comprendere ogni strumento e l'ecosistema, ma questo è impossibile.
Cosa ci aspetta
Foto di
Quando le tecnologie si evolvono, emergono sempre più pezzi disgiunti, e poi avviene una transizione, appare un fornitore che ha raccolto abbastanza "risorse" affinché tutto si unisca in un unico strumento.
Non pensate che arriverà un momento in cui emergerà uno strumento come è stata Ubuntu per il mondo Linux? Potrebbe darsi che un unico strumento di containerizzazione e orchestrazione includa anche Kubernetes. Con esso diventerà semplice costruire cloud on-premise.
Ivan ha risposto: "Google sta attualmente costruendo Anthos — è la loro offerta pacchetto che distribuisce il cloud e include Kuber, Service Mesh, monitoraggio, — tutta l'infrastruttura necessaria per i microservizi in un ambiente "on-premise". Siamo quasi nel futuro."
Denis ha anche menzionato Nutanix e VMWare con il prodotto vRealize Suite, che possono affrontare compiti simili senza la containerizzazione.
Dmitry ha condiviso l'opinione che ridurre il "dolore" e abbattere le tasse siano due direzioni in cui ci si può aspettare miglioramenti.
Riassumendo la discussione, evidenziamo i seguenti problemi dell'infrastruttura moderna
- Tre partecipanti hanno subito segnalato il problema con lo stato.
- Varie problematiche di supporto alla sicurezza, inclusa la probabilità che in Docker ci siano più versioni di Python, server applicazioni e componenti.
Spreco di risorse, di cui sarebbe meglio fare un incontro separato.
Problema della formazione, poiché l'orchestrazione rappresenta un ecosistema complesso.
Un problema generale del settore è l'uso improprio degli strumenti.Spetta a voi trarre le conclusioni. Rimane l'impressione che l'accoppiamento Docker+Kubernetes abbia difficoltà a diventare la parte "centrale" del sistema. Ad esempio, i sistemi operativi sono installati su hardware per primi, cosa che non si può dire dei container e dell'orchestrazione. Magari in futuro sistemi operativi e container si integreranno con il software di gestione cloud.
Foto diColgo l'occasione per salutare mia madre e ricordo che abbiamo un gruppo su Facebook , canale con pubblicazioni interessanti da vari tecnoblog. E il mio canale , dove parlo della gestione dello sviluppo nelle aziende di prodotto.
Fonte: habr.com
