Alla fine di maggio abbiamo condotto un meetup online sul tema . Abbiamo discusso di container, Kubernetes e orchestrazione in generale, dei criteri di scelta dell'infrastruttura e molto altro. I partecipanti hanno condiviso casi dai loro progetti.
Partecipanti:
- Evgeny Potapov, CEO di «ITSumma». Più della metà dei suoi clienti sta già migrando o desidera passare a Kubernetes.
- Dmitry Stolyarov, CTO di «Flant». Ha oltre 10 anni di esperienza con sistemi containerizzati.
- Denis Remchukov (aka Eric Oldmann), COO di argotech.io, ex-RAO EES. Ha promesso di condividere casi dal «cruento» settore enterprise.
- Andrey Fedorovsky, CTO di «News360.com»Dopo l'acquisizione dell'azienda da parte di un altro attore, è responsabile di diversi progetti ML e AI e dell'infrastruttura.
- Ivan Kruglov, ingegnere di sistema, ex-Booking.com.È la persona che ha fatto molto con Kubernetes con le sue stesse mani.
Temi:
- Insight dei partecipanti sui container e sull'orchestrazione (Docker, Kubernetes e altro); cosa hanno provato nella pratica o analizzato.
- Case: In the company, a long-term infrastructure development plan is being built. How is the decision made whether to build (or migrate the current) infrastructure on containers and Kubernetes or not?
- Issues in the cloud-native world, what is missing, let's imagine what tomorrow will bring.
An interesting discussion has arisen, participants' opinions turned out to be so diverse and sparked so many comments that we want to share them with you. There is , and below – a summary of the discussion.
Is Kubernetes already a standard or just great marketing?
"We came to it (Kubernetes. — Ed.) when no one knew about it yet. We arrived at it even before it existed. We wanted it even before that" — Dmitry Stolyarov
Photo from Reddit.com
Five to ten years ago, there were a huge number of tools, and no single standard existed. Every six months, a new product, or even several, appeared. First Vagrant, then Salt, Chef, Puppet,… "and every six months you're rebuilding your infrastructure. You have five admins who are constantly busy rewriting configs," recalls Andrei Fedorovsky. He believes that Docker and Kubernetes have 'overwhelmed' the others. Docker è diventato lo standard negli ultimi cinque anni, Kubernetes negli ultimi due. E questo è positivo per l'industria..
Dmitry Stolyarov e il suo team amano Kubernetes. Lo desideravano come strumento ancor prima che fosse lanciato, e vi si sono avvicinati quando ancora nessuno ne parlava. Al momento, per comodità, non accettano clienti se capiscono che non saranno in grado di implementare Kubernetes. Secondo Dmitry, la loro azienda ha "innumerevoli storie di successo nella trasformazione di orribili sistemi legacy".
Kubernetes non è solo orchestrazione dei container, ma è un sistema di gestione della configurazione con un'API avanzata, un componente di gestione della rete, bilanciamento del traffico L3 e controllori Ingress, che consente di gestire le risorse in modo relativamente semplice, scalare e astrarsi dagli strati sottostanti dell'infrastruttura.
Purtroppo, nella vita bisogna pagare per tutto. E questa tassa è alta, specialmente quando si parla di migrazione verso Kubernetes per aziende con infrastrutture consolidate, come sostiene Ivan Kruglov. É in grado di lavorare in aziende con infrastrutture tradizionali così come con Kubernetes. La cosa più importante è comprendere le caratteristiche dell'azienda e del mercato. Tuttavia, per Evgeny Potapov, che ridurrebbe Kubernetes a qualsiasi strumento di orchestrazione dei container, questa non è una questione di discussione.
Evgeny ha paragonato la situazione attuale con quella degli anni '90, quando emerse la programmazione orientata agli oggetti come metodo per sviluppare applicazioni complesse. In quel periodo si svolgevano dibattiti incessanti e apparivano nuovi strumenti a supporto dell'OOP. In seguito, sono emersi i microservizi come modo per allontanarsi dal concetto monolitico. Questo, a sua volta, ha portato all'introduzione dei contenitori e degli strumenti per la loro gestione. "Penso che presto arriveremo a un punto in cui non ci sarà più il problema di scrivere un'applicazione piccola in modo microservizi: si scriverà per default come microservizio", afferma. Allo stesso modo, Docker e Kubernetes diventeranno nel tempo la soluzione standard senza necessità di scelta.
Il problema dei database in stateless
Foto di
Oggi ci sono molti modi per avviare database in Kubernetes. Anche come separare la parte che lavora con il disco I/O dalla parte, in un certo senso, applicativa del database. È possibile che in futuro i database si trasformino in modo tale da essere forniti in un pacchetto, in cui una parte viene orchestrata tramite Docker e Kubernetes, mentre l'altra parte dell'infrastruttura, tramite un software separato, fornirà la parte di archiviazione? I database si trasformeranno come prodotto?
Questa descrizione somiglia alla gestione delle code, ma i requisiti di affidabilità e sincronizzazione delle informazioni nei database tradizionali sono molto più elevati, afferma Andrey. Il cache hit ratio nei database normali si mantiene attorno al 99%. Se un worker si arresta, viene avviato uno nuovo, e la cache deve essere 'riscaldata' da zero. Finché la cache non è riscaldata, il worker lavora lentamente, il che significa che non può gestire il carico degli utenti. Finché non c'è carico degli utenti, la cache non si riscalda. Questo è un circolo vizioso.
Dmitry è fermamente in disaccordo: i quorum e lo sharding risolvono il problema. Ma Andrey insiste sul fatto che la soluzione non è adatta a tutti. In alcune situazioni un quorum può andare bene, ma questo comporta un carico aggiuntivo sulla rete. Un database NoSQL non va bene in tutte le situazioni.
I partecipanti al meetup si sono divisi in due fazioni.
Denis e Andrey sostengono che tutto ciò che si scrive su disco — database e altro — non è possibile farlo nell'attuale ecosistema di Kubernetes. È impossibile mantenere l'integrità e la coerenza dei dati di produzione in Kubernetes. Questa è una caratteristica fondamentale. Soluzione: infrastruttura ibrida.
Anche i moderni database cloud-native, come MongoDB e Cassandra, o sistemi di messaggistica come Kafka o RabbitMQ, richiedono archiviazione permanente al di fuori di Kubernetes.
Evgeny obietta: «I database in Kubernetes sono una frustrazione che riguarda l'area post-sovietica, o quasi aziendale, legata al fatto che in Russia non c'è adozione del cloud». Le piccole e medie imprese in Occidente sono nel cloud. Utilizzare Amazon RDS è più semplice che gestire Kubernetes da soli. In Russia, Kubernetes viene utilizzato "on-premise" e le aziende vi migrano i database quando cercano di liberarsi del loro zoo tecnologico.
Dmitry non ha nemmeno concordato con l'affermazione che nessun database possa essere gestito in Kubernetes: «I database sono diversi tra loro. E se si cerca di inserire un enorme database relazionale, allora assolutamente no. Se si tratta di qualcosa di piccolo e cloud native, che è moralmente pronto a una vita semieffimera, andrà tutto bene.» Dmitry ha anche menzionato che gli strumenti di gestione dei database non sono pronti né per Docker né per Kubernetes, causando quindi grandi difficoltà.
Ivan, dal canto suo, è convinto che anche astrarre i concetti di stateful e stateless, l'ecosistema delle soluzioni enterprise in Kubernetes non sia ancora maturo. Con Kubernetes è difficile rispettare le richieste delle autorità legislative e regolatorie. Ad esempio, è impossibile creare una soluzione per la fornitura di identità, dove sono richieste garanzie rigorose di identificazione del server, fino all'hardware inserito nei server. Questo settore si sta sviluppando, ma finora non esiste una soluzione.
I partecipanti non sono riusciti a raggiungere un accordo, quindi non ci saranno conclusioni in questa parte. Meglio fornire un paio di esempi pratici.
Caso 1. Cybersecurity dell'«megaregoliatore» con database al di fuori di Kubernetes
In un sistema avanzato di cybersicurezza, 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 collegamento tra l'orchestratore e un servizio SIEM addestrato, che analizza i log in tempo reale e identifica il processo di attacco, violazione o guasto. In caso di attacco, tentativi di inserimento o durante un'intrusione da parte di un malware, l'orchestratore avvia contenitori con applicazioni più rapidamente di quanto possano essere infettati, o più velocemente di quanto l'attaccante possa colpirli.
Caso 2. Trasferimento parziale dei database di Booking.com in Kubernetes
In Booking.com, il database principale è MySQL con replica asincrona, con un master e un'intera gerarchia di slave. Al momento della partenza di Ivan dall'azienda, era stato avviato un progetto per il trasferimento degli slave, che possono essere "scartati" con un danno limitato.
Oltre al database principale, c'è un'installazione di Cassandra con orchestrazione personalizzata, sviluppata prima che Kubernetes diventasse mainstream. Non ci sono problemi in questo senso, ma ha uno storage persistente su SSD locali. Le memorie remote, anche all'interno della stessa data center, non vengono usate a causa dei problemi di alta latenza.
La terza classe di database è il servizio di ricerca di Booking.com, dove ogni nodo del servizio funge da database. I tentativi di trasferire il servizio di ricerca su Kubernetes non hanno avuto successo, perché ogni nodo ha 60-80 GB di storage locale, che è difficile da 'alzare' e 'riscaldare'.
Di conseguenza, il motore di ricerca non è stato trasferito su Kubernetes, e Ivan non pensa che ci saranno nuovi tentativi a breve. La base di MySQL è stata trasferita a metà: solo gli slave, che non è un problema 'eliminare'. Cassandra ha trovato una buona collocazione.
La scelta dell'infrastruttura è un compito senza una soluzione unica.
Foto di
Supponiamo che abbiamo una nuova azienda, o un'azienda in cui parte dell'infrastruttura è costruita in modo tradizionale. Qui viene redatto un piano di sviluppo dell'infrastruttura per gli anni futuri. Come viene presa la decisione 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 ripaga in termini di affidabilità, ma ci sono aziende che dovrebbero considerare nuovi approcci.
Ivan: «Adesso, senza dubbio, avvierei un'azienda nel cloud, semplicemente perché è più veloce», anche se non necessariamente più economico. Con lo sviluppo del venture capital, le startup non hanno grandi problemi di liquidità e l'obiettivo principale è conquistare il mercato.
Ivan sostiene che il grado di sviluppo dell'infrastruttura attuale è un criterio di scelta. Se in passato ci sono stati investimenti significativi e tutto funziona, non ha senso rifare. Se l'infrastruttura è poco sviluppata e ci sono problemi con gli strumenti, la sicurezza e il monitoraggio, allora vale la pena considerare un'infrastruttura distribuita.
Dovrà comunque pagare le tasse, e Ivan pagherebbe quella che gli permetterebbe in futuro di pagare meno. «Perché solo viaggiando su un treno che viene guidato da altri, arriverò molto più lontano rispetto a se salgo su un altro treno, dove devo mettere io stesso il carburante.» — dice Ivan. Quando si tratta di una nuova azienda, e le esigenze di latenza sono nell'ordine delle decine di millisecondi, Ivan avrebbe considerato «operatori» che oggi gestiscono database classici. Questi attivano una catena di replicazione 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 Andrei. Ma se intende crescere fino a cento server e oltre, allora è necessaria l'automazione e un sistema di gestione delle risorse. Il 90% dei casi giustifica i costi. E questo indipendentemente dal livello di carico e dalle risorse. È logico che tutti, dagli startup alle grandi aziende con audience milioni, inizino a considerare gradualmente soluzioni per l'orchestrazione dei container. «Sì, è davvero il futuro», è convinto Andrei.
Denis ha evidenziato due criteri principali — scalabilità e resilienza. Sceglierà gli strumenti più adatti a questo compito. «Può trattarsi di un nome sconosciuto assemblato in modo artigianale, con Nutanix Community Edition. Potrebbe essere una seconda linea sotto forma di applicazione su Kubernetes con un database sul backend, che viene replicato e ha parametri RTO e RPO impostati» (obiettivi di recovery time/point — nota).
Evgenij ha segnalato un possibile problema con il personale. Al momento non ci sono molti specialisti di alta qualità sul mercato che capiscano «le dinamiche interne». Infatti, se la tecnologia scelta è obsoleta, è difficile assumere qualcuno che non sia persone più anziane, annoiate e stanche della vita. Tuttavia, altri partecipanti ritengono che si tratti di una questione di formazione del personale.
Se si pone 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, i partecipanti hanno scelto Amazon RDS.
Poiché la maggior parte degli ascoltatori del meetup non proviene da «grandi» imprese, le soluzioni distribuite sono ciò a cui bisogna aspirare. I sistemi di archiviazione dati devono essere distribuiti, affidabili e creare latenza misurabile in millisecondi, al massimo qualche decina., — ha riassunto Andrei.
Valutazione dell'utilizzo di Kubernetes
L'ascoltatore Anton Zhbankov ha posto una domanda-trappola agli apologeti di Kubernetes: come è stata effettuata la valutazione tecnico-economica? Perché Kubernetes, perché non le macchine virtuali, ad esempio?
Foto di
Dmitrij e Ivan hanno risposto. In entrambi i casi, attraverso tentativi ed errori, è stata elaborata una sequenza di decisioni che ha portato entrambi i partecipanti a scegliere Kubernetes. Attualmente, le aziende iniziano a sviluppare autonomamente software che ha senso trasferire in Kubernetes. Non si tratta di classici sistemi di terze parti, come 1C. Kubernetes è utile quando gli sviluppatori hanno bisogno di rilasciare in modo rapido e continuo durante il Continuous Improvement.
Il team di Andrei ha provato a creare un cluster scalabile basato su macchine virtuali. I nodi cadevano come dominò, portando a volte al crollo del cluster. «Teoricamente, si può finire e mantenere manualmente, ma è un lavoro noioso. E se c'è una soluzione sul mercato che permette di lavorare out-of-the-box, ci andiamo volentieri. E infatti abbiamo fatto il passaggio.», — racconta Andrei.
Ci sono standard per tale analisi e calcolo, ma nessuno può dire quanto siano validi sul reale hardware in uso. È anche fondamentale comprendere ogni strumento e l'ecosistema, ma questo è impossibile.
Cosa ci aspetta
Foto di
Con l'avanzare della tecnologia, emergono sempre più pezzi disparati e poi avviene un cambiamento di fase, appare un fornitore che ha investito abbastanza 'capitale' per unire tutto in uno strumento unico.
Non pensate che arriverà un momento in cui apparirà uno strumento simile a quello che è diventata Ubuntu per il mondo Linux? Forse uno strumento unificato per la containerizzazione e l'orchestrazione includerà anche Kubernetes. Sarà più semplice costruire cloud on-premise.
Ivan ha risposto: 'Google sta attualmente costruendo Anthos - è la loro offerta pacchetto che implementa il cloud e include Kubernetes, Service Mesh, monitoraggio - l'intera infrastruttura necessaria per i microservizi in ambiente on-premise. Siamo quasi nel futuro.'
Denis ha anche menzionato Nutanix e VMWare con il prodotto vRealize Suite, che possono affrontare sfide simili senza containerizzazione.
Dmitry ha condiviso l'opinione che la riduzione del «dolore» e la diminuzione delle tasse sono due aree in cui ci si aspetta miglioramenti.
Riassumendo la discussione, possiamo identificare i seguenti problemi dell'infrastruttura moderna.
- Tre partecipanti hanno evidenziato il problema con lo stateful.
- Varie problematiche relative al supporto della sicurezza, inclusa la possibilità che in Docker ci siano più versioni di Python, server applicazioni e componenti.
Spreco eccessivo, di cui sarebbe meglio fare un incontro separato.
Il problema dell'istruzione, poiché l'orchestrazione rappresenta un ecosistema complesso.
Un problema generale del settore è l'uso degli strumenti in modo improprio.Le altre conclusioni spettano a voi. Rimane la sensazione che l'accoppiamento Docker+Kubernetes fatichi a diventare una parte «centrale» del sistema. Ad esempio, i sistemi operativi vengono installati per primi sull'hardware, cosa che non si può dire per i contenitori e l'orchestrazione. Forse in futuro i sistemi operativi e i contenitori si integreranno con il software di gestione cloud.
Foto diColgo l'occasione per salutare mia madre e ricordare che abbiamo un gruppo su Facebook. , canale con contenuti interessanti da vari blog tecnologici. E il mio canale , dove parlo della gestione dello sviluppo nelle aziende produttrici.
Fonte: habr.com
