Alla fine di maggio ha tenuto un incontro online sull'argomento . Abbiamo parlato di container, Kubernetes e orchestrazione in linea di principio, criteri per la scelta dell'infrastruttura e molto altro ancora. I partecipanti hanno condiviso casi della propria pratica.
Utenti:
- Evgeniy Potapov, CEO di ITSumma. Più della metà dei suoi clienti si sta già trasferendo o vorrebbe passare a Kubernetes.
- Dmitry Stolyarov, direttore tecnico di "Flant". Ha oltre 10 anni di esperienza di lavoro con sistemi di container.
- Denis Remchukov (alias Eric Oldmann), COO argotech.io, ex RAO UES. Ha promesso di parlare di casi nell'impresa "sanguinosa".
- Andrey Fedorovsky, direttore tecnico di “News360.com”Dopo aver acquistato l'azienda da un altro giocatore, è responsabile di una serie di progetti e infrastrutture di ML e AI.
- Ivan Kruglov, ingegnere di sistema, ex-Booking.com.La stessa persona che ha fatto molto con Kubernetes con le proprie mani.
Temi:
- Approfondimenti dei partecipanti su contenitori e orchestrazione (Docker, Kubernetes, ecc.); ciò che è stato provato nella pratica o analizzato.
- Caso: L'azienda sta costruendo da anni un piano di sviluppo infrastrutturale. Come viene presa la decisione se costruire (o migrare l'attuale) infrastruttura su container e Kuber oppure no?
- Problemi nel mondo cloud-native, cosa manca, immaginiamo cosa succederà domani.
Ne è nata una discussione interessante, le opinioni dei partecipanti erano così diverse e hanno suscitato così tanti commenti che voglio condividerle con voi. Mangiare , e di seguito è riportato un riassunto della discussione.
Kubernetes è già uno standard o un ottimo marketing?
“Ci siamo arrivati (Kubernetes. - ndr) quando ancora nessuno lo sapeva. Siamo venuti da lui anche quando non c'era. Lo volevamo prima" - Dmitry Stolyarov
Foto da Reddit.com
5-10 anni fa esisteva un numero enorme di strumenti e non esisteva uno standard unico. Ogni sei mesi appariva un nuovo prodotto, o anche più di uno. Prima Vagrant, poi Salt, Chef, Puppet,... “e ricostruisci la tua infrastruttura ogni sei mesi. Hai cinque amministratori costantemente impegnati a riscrivere le configurazioni", ricorda Andrey Fedorovsky. Crede che Docker e Kubernetes abbiano “spiazzato” il resto. Docker è diventato uno standard negli ultimi cinque anni, Kubernetes negli ultimi due anni. Ed è positivo per l'industria.
Dmitry Stolyarov e il suo team adorano Kuber. Volevano uno strumento del genere prima che apparisse e ci sono arrivati quando nessuno lo sapeva. Attualmente, per ragioni di comodità, non assumono un cliente se capiscono che con lui non implementeranno Kubernetes. Allo stesso tempo, secondo Dmitry, l'azienda ha "molte gigantesche storie di successo sul rifacimento della terribile eredità".
Kubernetes non è solo orchestrazione di container, è un sistema di gestione della configurazione con un'API sviluppata, un componente di rete, bilanciamento L3 e controller Ingress, che rende relativamente semplice la gestione delle risorse, la scalabilità e l'astrazione dagli strati inferiori dell'infrastruttura.
Purtroppo nella nostra vita dobbiamo pagare per tutto. E questa tassa è elevata, soprattutto se parliamo del passaggio a Kubernetes di un'azienda con un'infrastruttura sviluppata, come crede Ivan Kruglov. Potrebbe lavorare liberamente sia in un'azienda con un'infrastruttura tradizionale che con Kuber. L’importante è comprendere le caratteristiche dell’azienda e del mercato. Ma, ad esempio, per Evgeny Potapov, che generalizzerebbe Kubernetes a qualsiasi strumento di orchestrazione dei contenitori, una domanda del genere non si pone.
Evgeniy ha tracciato un'analogia con la situazione degli anni '1990, quando la programmazione orientata agli oggetti appariva come un modo per programmare applicazioni complesse. A quel tempo, il dibattito continuava e apparivano nuovi strumenti a supporto dell’OOP. Poi sono emersi i microservizi come un modo per allontanarsi dal concetto monolitico. Ciò, a sua volta, ha portato alla nascita di container e strumenti di gestione dei container. "Penso che presto arriveremo al momento in cui non ci saranno dubbi se valga la pena scrivere una piccola applicazione di microservizi, sarà scritta come microservizio per impostazione predefinita", ritiene. Allo stesso modo, Docker e Kubernetes diventeranno eventualmente la soluzione standard senza bisogno di scelta.
Il problema delle basi di dati in stateless
Foto di
Al giorno d'oggi esistono molte ricette per eseguire database in Kubernetes. Anche come separare la parte che funziona con il disco I/O dalla parte applicativa del database. È possibile che in futuro i database cambino così tanto da essere consegnati in una scatola, dove una parte sarà orchestrata tramite Docker e Kubernetes, e in un'altra parte dell'infrastruttura, tramite software separati, verrà fornita la parte di storage? ? Le basi cambieranno come prodotto?
Questa descrizione è simile alla gestione delle code, ma i requisiti di affidabilità e sincronizzazione delle informazioni nei database tradizionali sono molto più elevati, ritiene Andrey. La percentuale di riscontri nella cache nei database normali rimane al 99%. Se un lavoratore non funziona, ne viene avviato uno nuovo e la cache si "riscalda" da zero. Fino a quando la cache non viene riscaldata, il lavoratore lavora lentamente, il che significa che non può essere caricato con il carico dell'utente. Sebbene non sia presente alcun carico da parte dell'utente, la cache non si riscalda. È un circolo vizioso.
Dmitry fondamentalmente non è d'accordo: i quorum e lo sharding risolvono il problema. Ma Andrey insiste che la soluzione non è adatta a tutti. In alcune situazioni, il quorum è adeguato, ma comporta un carico aggiuntivo sulla rete. Un database NoSQL non è adatto in tutti i casi.
I partecipanti al meetup erano divisi in due campi.
Denis e Andrey sostengono che tutto ciò che viene scritto su disco - database e così via - è impossibile da fare nell'attuale ecosistema Kuber. È impossibile mantenere l'integrità e la coerenza dei dati di produzione in Kubernetes. Questa è una caratteristica fondamentale. Soluzione: infrastruttura ibrida.
Anche i moderni database nativi del cloud come MongoDB e Cassandra, o code di messaggi come Kafka o RabbitMQ, richiedono archivi dati persistenti al di fuori di Kubernetes.
Evgeniy obietta: "Le basi a Kubera sono un danno quasi russo, o quasi aziendale, associato al fatto che non esiste l'adozione del cloud in Russia". Le piccole e medie imprese in Occidente sono Cloud. I database Amazon RDS sono più facili da usare che armeggiare tu stesso con Kubernetes. In Russia usano Kuber “on-premise” e vi trasferiscono le basi quando cercano di sbarazzarsi dello zoo.
Dmitry non è d'accordo anche con l'affermazione secondo cui nessun database può essere conservato in Kubernetes: “Base è diversa da base. E se spingi un gigantesco database relazionale, in nessun caso. Se promuovi qualcosa di piccolo e nativo del cloud, che è mentalmente preparato per la vita semi-effimera, andrà tutto bene”. Dmitry ha anche affermato che gli strumenti di gestione dei database non sono pronti né per Docker né per Kuber, quindi sorgono grandi difficoltà.
Ivan, a sua volta, è sicuro che anche se astraiamo dai concetti di stateful e stateless, l'ecosistema delle soluzioni aziendali in Kubernetes non è ancora pronto. Con Kuber è difficile mantenere i requisiti legislativi e normativi. Ad esempio, è impossibile realizzare una soluzione di fornitura dell’identità in cui siano richieste rigide garanzie di identificazione dei server, fino all’hardware inserito nei server. Quest’area si sta sviluppando, ma non c’è ancora una soluzione.
I partecipanti non sono riusciti a raggiungere un accordo, quindi in questa parte non verranno tratte conclusioni. Facciamo un paio di esempi pratici.
Caso 1. Sicurezza informatica di un “mega-regolatore” con basi fuori Kubera
Nel caso di un sistema di sicurezza informatica sviluppato, l’uso di contenitori e orchestrazione consente di respingere attacchi e intrusioni. Ad esempio, in un mega-regolatore, Denis e il suo team hanno implementato una combinazione di un orchestratore con un servizio SIEM addestrato che analizza i log in tempo reale e determina il processo di attacco, hacking o fallimento. In caso di attacco, tentativo di inserire qualcosa o in caso di invasione di virus ransomware, tramite l'orchestratore preleva i contenitori con le applicazioni più velocemente di quanto vengono infettati o più velocemente di quanto l'aggressore li attacca.
Caso 2. Migrazione parziale dei database di Booking.com su Kubernetes
In Booking.com, il database principale è MySQL con replica asincrona: c'è un master e un'intera gerarchia di slave. Quando Ivan lasciò l'azienda, fu lanciato un progetto per trasferire gli schiavi che potevano essere "fucilati" con certi danni.
Oltre alla base principale, c'è un'installazione di Cassandra con un'orchestrazione autoscritta, scritta ancor prima che Kuber diventasse mainstream. Non ci sono problemi a riguardo, ma è persistente sugli SSD locali. L'archiviazione remota, anche all'interno dello stesso data center, non viene utilizzata a causa del problema dell'elevata latenza.
La terza classe di database è il servizio di ricerca di Booking.com, in cui ogni nodo del servizio è un database. I tentativi di trasferire il servizio di ricerca su Kuber sono falliti, perché ogni nodo ha 60-80 GB di spazio di archiviazione locale, che è difficile da "sollevare" e "riscaldare".
Di conseguenza, il motore di ricerca non è stato trasferito a Kubernetes e Ivan non pensa che ci saranno nuovi tentativi nel prossimo futuro. Il database MySQL è stato trasferito a metà: solo Slave, che non hanno paura di essere “fucilati”. Cassandra si è ambientata perfettamente.
La selezione delle infrastrutture come compito senza una soluzione generale
Foto di
Diciamo che abbiamo una nuova azienda, o un'azienda in cui parte dell'infrastruttura è costruita alla vecchia maniera. Costruisce da anni un piano di sviluppo delle infrastrutture. Come viene presa la decisione se realizzare o meno l'infrastruttura su container e Kuber?
Sono escluse dalla discussione le aziende che lottano per i nanosecondi. Un sano conservatorismo ripaga in termini di affidabilità, ma ci sono ancora aziende che dovrebbero prendere in considerazione nuovi approcci.
Ivan: “Adesso avvierei sicuramente un’azienda sul cloud, semplicemente perché è più veloce”, anche se non necessariamente più economico. Con lo sviluppo del venture capitalism, le startup non hanno grossi problemi con i soldi e il compito principale è conquistare il mercato.
Ivan è di questo parere lo sviluppo dell'infrastruttura attuale è un criterio di selezione. Se in passato è stato effettuato un investimento serio e funziona, non ha senso rifarlo. Se l’infrastruttura non è sviluppata e ci sono problemi con gli strumenti, la sicurezza e il monitoraggio, allora ha senso guardare a un’infrastruttura distribuita.
La tassa dovrà essere pagata in ogni caso, e Ivan pagherebbe quella che gli permetterebbe di pagare di meno in futuro. "Perché semplicemente per il fatto che viaggio su un treno su cui viaggiano altri, viaggerò molto più lontano che se fossi seduto su un altro treno, nel quale devo mettere io stesso il carburante.“dice Ivan. Quando l’azienda è nuova e i requisiti di latenza sono di decine di millisecondi, allora Ivan guarderebbe agli “operatori” in cui sono “avvolti” oggi i database classici. Sollevano una catena di replica, che cambia automaticamente in caso di failover, ecc...
Per una piccola azienda con un paio di server, Kubera non ha senso”, afferma Andrey. Ma se prevede di crescere fino a centinaia di server o più, allora avrà bisogno di automazione e di un sistema di gestione delle risorse. Il 90% dei casi vale il costo. Inoltre, indipendentemente dal livello di carico e risorse. È logico che tutti, dalle startup alle grandi aziende con un pubblico di milioni, guardino gradualmente ai prodotti di orchestrazione dei contenitori. "Sì, questo è davvero il futuro", è sicuro Andrey.
Denis ha delineato due criteri principali: scalabilità e stabilità operativa. Selezionerà gli strumenti più adatti al compito. “Potrebbe essere un non-nome assemblato sulle tue ginocchia, e su di esso c'è la Nutanix Community Edition. Potrebbe trattarsi di una seconda linea sotto forma di un'applicazione su Kuber con un database sul backend, che viene replicato e ha parametri RTO e RPO specificati" (obiettivi tempi/punti di ripristino - ca.).
Evgeniy ha identificato un possibile problema con il personale. Al momento non sono molti gli specialisti altamente qualificati sul mercato che capiscono il “coraggio”. In effetti, se la tecnologia scelta è vecchia, è difficile assumere qualcuno che non sia persone di mezza età annoiate e stanche della vita. Sebbene altri partecipanti credano che si tratti di una questione di formazione del personale.
Se poniamo la questione della scelta: lanciare una piccola azienda nel cloud pubblico con database in Amazon RDS o “on premise” con database in Kubernetes, nonostante alcune carenze, Amazon RDS è diventata la scelta dei partecipanti.
Dal momento che la maggior parte degli ascoltatori del meetup non proviene dall'impresa "sanguinosa", allora le soluzioni distribuite sono ciò a cui dovremmo aspirare. I sistemi di archiviazione dei dati devono essere distribuiti, affidabili e creare una latenza misurata in unità di millisecondi, decine al massimo“, ha riassunto Andrej.
Valutazione dell'utilizzo di Kubernetes
L'ascoltatore Anton Zhbankov ha posto una domanda trappola agli apologeti di Kubernetes: come avete selezionato e condotto uno studio di fattibilità? Perché Kubernetes e perché non le macchine virtuali, ad esempio?
Foto di
Dmitry e Ivan hanno risposto. In entrambi i casi, attraverso tentativi ed errori, è stata presa una sequenza di decisioni, a seguito della quale entrambi i partecipanti sono arrivati a Kubernetes. Ora le aziende stanno iniziando a sviluppare in modo indipendente software che abbia senso trasferire a Kuber. Non stiamo parlando dei classici sistemi di terze parti, come 1C. Kubernetes aiuta quando gli sviluppatori hanno bisogno di rilasciare rapidamente rilasci, con un miglioramento continuo continuo.
Il team di Andrey ha provato a creare un cluster scalabile basato su macchine virtuali. I nodi cadevano come tessere del domino, il che a volte portava al collasso del cluster. “In teoria puoi finirlo e sostenerlo con le mani, ma è noioso. E se sul mercato esiste una soluzione che ti consente di lavorare fuori dagli schemi, allora saremo felici di adottarla. E di conseguenza abbiamo cambiato”, dice Andrey.
Esistono standard per tali analisi e calcoli, ma nessuno può dire quanto siano accurati sull'hardware reale in funzione. Per i calcoli è anche importante comprendere ogni strumento ed ecosistema, ma ciò non è possibile.
Cosa ci aspetta
Foto di
Man mano che la tecnologia si evolve, compaiono pezzi sempre più disparati, quindi avviene una transizione di fase, appare un venditore che ha ucciso abbastanza soldi perché tutto si riunisca in un unico strumento.
Pensi che arriverà il momento in cui ci sarà uno strumento come Ubuntu per il mondo Linux? Forse un unico strumento di containerizzazione e orchestrazione includerà Kuber. Semplificherà la creazione di cloud on-premise.
La risposta è stata data da Ivan: "Google sta ora costruendo Anthos - questa è la loro offerta in pacchetto che distribuisce il cloud e include Kuber, Service Mesh, monitoraggio - tutto l'hardware necessario per i microservizi on-premise." Siamo quasi nel futuro."
Denis ha menzionato anche Nutanix e VMWare con il prodotto vRealize Suite, che può far fronte a un compito simile senza containerizzazione.
Dmitry ha condiviso la sua opinione secondo cui la riduzione del “dolore” e la riduzione delle tasse sono due aree in cui possiamo aspettarci miglioramenti.
Per riassumere la discussione, evidenziamo i seguenti problemi delle infrastrutture moderne:
- Tre partecipanti hanno immediatamente identificato un problema con stateful.
- Vari problemi di supporto alla sicurezza, inclusa la possibilità che Docker si ritrovi con più versioni di Python, server delle applicazioni e componenti.
Spese eccessive, di cui è meglio discutere in una riunione separata.
Una sfida di apprendimento poiché l’orchestrazione è un ecosistema complesso.
Un problema comune nel settore è l’uso improprio degli strumenti.Il resto delle conclusioni dipende da te. C’è ancora la sensazione che non sarà facile per la combinazione Docker+Kubernetes diventare una parte “centrale” del sistema. Ad esempio, i sistemi operativi vengono installati prima sull’hardware, il che non si può dire dei contenitori e dell’orchestrazione. Forse in futuro i sistemi operativi e i contenitori si fonderanno con i software di gestione del cloud.
Foto diColgo l'occasione per salutare mia madre e ricordarvi che abbiamo un gruppo su Facebook , canale con pubblicazioni interessanti da vari blog tecnologici. E il mio canale , dove parlo di gestione dello sviluppo nelle aziende prodotto.
Fonte: habr.com