Kubernetes è un ottimo strumento per eseguire contenitori Docker in un ambiente di produzione in cluster. Tuttavia, ci sono problemi che Kubernetes non può risolvere. Per implementazioni di produzione frequenti, abbiamo bisogno di una distribuzione Blue/Green completamente automatizzata per evitare tempi di inattività nel processo, che deve anche gestire richieste HTTP esterne ed eseguire offload SSL. Ciò richiede l'integrazione con un bilanciatore del carico come ha-proxy. Un'altra sfida è il ridimensionamento semiautomatico del cluster Kubernetes stesso quando viene eseguito in un ambiente cloud, ad esempio ridimensionando parzialmente il cluster durante la notte.
Sebbene Kubernetes non disponga di queste funzionalità pronte all'uso, fornisce un'API che puoi utilizzare per risolvere problemi simili. Nell'ambito del progetto Cloud RTI, creato sulla base dell'open source, sono stati sviluppati strumenti per l'implementazione automatizzata Blue/Green e il dimensionamento di un cluster Kubernetes.
Questo articolo, una trascrizione video, mostra come configurare Kubernetes insieme ad altri componenti open source per creare un ambiente pronto per la produzione che accetta codice da un commit git senza tempi di inattività in produzione.
Quindi, una volta che hai accesso alle tue applicazioni dal mondo esterno, puoi iniziare a configurare completamente l'automazione, ovvero portarla allo stadio in cui puoi eseguire un git commit e assicurarti che questo git commit finisca in produzione. Naturalmente, quando implementiamo questi passaggi, quando implementiamo la distribuzione, non vogliamo incontrare tempi di inattività. Pertanto, qualsiasi automazione in Kubernetes inizia con l'API.
Kubernetes non è uno strumento che può essere utilizzato in modo produttivo immediatamente. Certo, puoi farlo, usare kubectl e così via, ma l'API rimane comunque la cosa più interessante e utile di questa piattaforma. Utilizzando l'API come insieme di funzioni, puoi accedere a quasi tutto ciò che desideri fare in Kubernetes. Anche kubectl utilizza l'API REST.
Questo è REST, quindi puoi utilizzare qualsiasi linguaggio o strumento per lavorare con questa API, ma la tua vita sarà resa molto più semplice dalle librerie personalizzate. Il mio team ha scritto 2 librerie di questo tipo: una per Java/OSGi e una per Go. Il secondo non viene utilizzato spesso, ma in ogni caso hai queste cose utili a tua disposizione. Sono un progetto open source parzialmente concesso in licenza. Esistono molte librerie di questo tipo per diverse lingue, quindi puoi scegliere quelle più adatte a te.
Pertanto, prima di iniziare ad automatizzare la distribuzione, è necessario assicurarsi che il processo non sia soggetto a tempi di inattività. Ad esempio, il nostro team esegue le distribuzioni di produzione durante le ore centrali della giornata, quando le persone utilizzano maggiormente le applicazioni, quindi è importante evitare ritardi in questo processo. Per evitare tempi di inattività, vengono utilizzati 2 metodi: distribuzione blu/verde o aggiornamento in sequenza. In quest'ultimo caso, se si hanno 5 repliche dell'applicazione in esecuzione, queste verranno aggiornate in sequenza una dopo l'altra. Questo metodo funziona benissimo, ma non è adatto se sono presenti diverse versioni dell'applicazione in esecuzione contemporaneamente durante il processo di distribuzione. In questo caso, puoi aggiornare l'interfaccia utente mentre il backend esegue la versione precedente e l'applicazione smetterà di funzionare. Pertanto, dal punto di vista della programmazione, lavorare in tali condizioni è piuttosto difficile.
Questo è uno dei motivi per cui preferiamo utilizzare la distribuzione blu/verde per automatizzare la distribuzione delle nostre applicazioni. Con questo metodo è necessario assicurarsi che sia attiva solo una versione dell'applicazione alla volta.
Il meccanismo di distribuzione blu/verde si presenta così. Riceviamo il traffico per le nostre applicazioni tramite ha-proxy, che lo inoltra alle repliche in esecuzione dell'applicazione della stessa versione.
Quando viene effettuata una nuova distribuzione, utilizziamo Deployer, a cui vengono forniti i nuovi componenti e distribuisce la nuova versione. La distribuzione di una nuova versione di un'applicazione significa che un nuovo set di repliche viene “generato”, dopodiché queste repliche della nuova versione vengono avviate in un nuovo pod separato. Tuttavia, ha-proxy non ne sa nulla e non indirizza loro ancora alcun carico di lavoro.
Pertanto, prima di tutto, è necessario eseguire un controllo delle prestazioni delle nuove versioni del controllo dello stato per garantire che le repliche siano pronte a servire il carico.
Tutti i componenti di distribuzione devono supportare una qualche forma di controllo dello stato. Può trattarsi di un controllo molto semplice delle chiamate HTTP, quando si riceve un codice con stato 200, oppure di un controllo più approfondito, in cui si verifica la connessione delle repliche con il database e altri servizi, la stabilità delle connessioni dell'ambiente dinamico e se tutto si avvia e funziona correttamente. Questo processo può essere piuttosto complesso.
Dopo che il sistema ha verificato che tutte le repliche aggiornate funzionino, Deployer aggiornerà la configurazione e passerà il confd corretto, che riconfigurerà ha-proxy.
Solo dopo questo il traffico verrà indirizzato al pod con le repliche della nuova versione e il vecchio pod scomparirà.
Questo meccanismo non è una caratteristica di Kubernetes. Il concetto di distribuzione blu/verde esiste da molto tempo e ha sempre utilizzato un bilanciatore del carico. Innanzitutto, indirizzi tutto il traffico alla vecchia versione dell'applicazione e, dopo l'aggiornamento, lo trasferisci completamente alla nuova versione. Questo principio viene utilizzato non solo in Kubernetes.
Ora ti presenterò un nuovo componente di distribuzione: Deployer, che esegue controlli di integrità, riconfigura i proxy e così via. Questo è un concetto che non si applica al mondo esterno ed esiste all'interno di Kubernetes. Ti mostrerò come creare il tuo concetto di Deployer utilizzando strumenti open source.
Pertanto, la prima cosa che fa Deployer è creare un controller di replica RC utilizzando l'API Kubernetes. Questa API crea pod e servizi per un'ulteriore distribuzione, ovvero crea un cluster completamente nuovo per le nostre applicazioni. Non appena RC sarà convinto che le repliche siano state avviate, eseguirà un controllo dello stato sulla loro funzionalità. Per fare ciò, Deployer utilizza il comando GET /health. Esegue i componenti di scansione appropriati e controlla tutti gli elementi che supportano il funzionamento del cluster.
Dopo che tutti i pod hanno segnalato il proprio stato, Deployer crea un nuovo elemento di configurazione: l'archiviazione distribuita etcd, che viene utilizzata internamente da Kubernetes, inclusa la memorizzazione della configurazione del sistema di bilanciamento del carico. Scriviamo i dati su etcd e un piccolo strumento chiamato confd monitora etcd per i nuovi dati.
Se rileva modifiche alla configurazione iniziale, genera un nuovo file di impostazioni e lo trasferisce a ha-proxy. In questo caso, ha-proxy si riavvia senza perdere alcuna connessione e indirizza il carico su nuovi servizi che consentono il funzionamento della nuova versione delle nostre applicazioni.
Come puoi vedere, nonostante l'abbondanza di componenti, qui non c'è nulla di complicato. Devi solo prestare maggiore attenzione all'API e etcd. Voglio parlarvi del distributore open source che utilizziamo noi stessi: Amdatu Kubernetes Deployer.
È uno strumento per orchestrare le distribuzioni Kubernetes e presenta le seguenti funzionalità:
- Schieramento Blu/Verde;
- impostazione di un bilanciatore del carico esterno;
- gestione dei descrittori di distribuzione;
- gestire la distribuzione effettiva;
- verificare la funzionalità dei controlli di integrità durante la distribuzione;
- implementazione delle variabili di ambiente nei pod.
Questo Deployer è basato sull'API Kubernetes e fornisce un'API REST per la gestione di handle e distribuzioni, nonché un'API Websocket per lo streaming dei log durante il processo di distribuzione.
Inserisce i dati di configurazione del bilanciatore del carico in etcd, quindi non è necessario utilizzare ha-proxy con supporto pronto all'uso, ma usa facilmente il tuo file di configurazione del bilanciatore del carico. Amdatu Deployer è scritto in Go, come lo stesso Kubernetes, ed è concesso in licenza da Apache.
Prima di iniziare a utilizzare questa versione del deployer, ho utilizzato il seguente descrittore di deploy, che specifica i parametri di cui ho bisogno.
Uno dei parametri importanti di questo codice è abilitare il flag "useHealthCheck". Dobbiamo specificare che durante il processo di distribuzione deve essere eseguito un controllo di integrità. Questa impostazione può essere disabilitata quando la distribuzione utilizza contenitori di terze parti che non devono essere verificati. Questo descrittore indica anche il numero di repliche e l'URL del frontend di cui ha bisogno ha-proxy. Alla fine c'è il flag della specifica del pod "podspec", che chiama Kubernetes per informazioni sulla configurazione della porta, immagine, ecc. Questo è un descrittore JSON abbastanza semplice.
Un altro strumento che fa parte del progetto Amdatu open source è Deploymentctl. Dispone di un'interfaccia utente per la configurazione delle distribuzioni, archivia la cronologia delle distribuzioni e contiene webhook per richiamate da utenti e sviluppatori di terze parti. Non puoi utilizzare l'interfaccia utente poiché Amdatu Deployer stesso è un'API REST, ma questa interfaccia può semplificare molto la distribuzione senza coinvolgere alcuna API. Deploymentctl è scritto in OSGi/Vertx utilizzando Angular 2.
Ora dimostrerò quanto sopra sullo schermo utilizzando una registrazione preregistrata in modo da non dover aspettare. Distribuiremo una semplice applicazione Go. Non preoccuparti se non hai mai provato Go prima, è un'applicazione molto semplice quindi dovresti essere in grado di capirla.
Qui stiamo creando un server HTTP che risponde solo a /health, quindi questa applicazione verifica solo il controllo dello stato e nient'altro. Se il controllo passa viene utilizzata la struttura JSON mostrata di seguito. Contiene la versione dell'applicazione che verrà distribuita dal distributore, il messaggio visualizzato nella parte superiore del file e il tipo di dati booleano, indipendentemente dal fatto che la nostra applicazione funzioni o meno.
Ho barato un po' con l'ultima riga, perché ho inserito un valore booleano fisso all'inizio del file, che in futuro mi aiuterà a distribuire anche un'applicazione “malsana”. Ci occuperemo di questo più tardi.
Quindi iniziamo. Innanzitutto, controlliamo la presenza di eventuali pod in esecuzione utilizzando il comando ~ kubectl get pods e, in base all'assenza di una risposta dall'URL del frontend, ci assicuriamo che non siano attualmente in corso distribuzioni.
Successivamente sullo schermo viene visualizzata l'interfaccia Deploymentctl di cui ho parlato, in cui sono impostati i parametri di distribuzione: spazio dei nomi, nome dell'applicazione, versione di distribuzione, numero di repliche, URL front-end, nome del contenitore, immagine, limiti delle risorse, numero di porta per il controllo dello stato, ecc. I limiti delle risorse sono molto importanti poiché consentono di utilizzare la massima quantità possibile di hardware. Qui puoi anche visualizzare il registro di distribuzione.
Se ora ripeti il comando ~ kubectl get pods, puoi vedere che il sistema si “blocca” per 20 secondi, durante i quali ha-proxy viene riconfigurato. Successivamente, il pod si avvia e la nostra replica può essere visualizzata nel registro di distribuzione.
Ho eliminato i 20 secondi di attesa dal video e ora puoi vedere sullo schermo che la prima versione dell'applicazione è stata distribuita. Tutto questo è stato fatto utilizzando solo l'interfaccia utente.
Ora proviamo la seconda versione. Per fare ciò, cambio il messaggio dell'applicazione da "Hello, Kubernetes!" su “Hello, Deployer!”, il sistema crea questa immagine e la inserisce nel registro Docker, dopodiché dobbiamo semplicemente fare nuovamente clic sul pulsante “Deploy” nella finestra Deploymentctl. In questo caso, il registro di distribuzione viene avviato automaticamente nello stesso modo in cui è avvenuto durante la distribuzione della prima versione dell'applicazione.
Il comando ~ kubectl get pods mostra che attualmente ci sono 2 versioni dell'applicazione in esecuzione, ma il frontend mostra che stiamo ancora eseguendo la versione 1.
Il sistema di bilanciamento del carico attende il completamento del controllo dello stato prima di reindirizzare il traffico alla nuova versione. Dopo 20 secondi, passiamo a curl e vediamo che ora abbiamo distribuito la versione 2 dell'applicazione e la prima è stata eliminata.
Si trattava della distribuzione di un'applicazione “sana”. Vediamo cosa succede se per una nuova versione dell'applicazione cambio il parametro Healthy da true a false, ovvero provo a distribuire un'applicazione non integra che non ha superato il controllo di integrità. Ciò può accadere se sono stati commessi degli errori di configurazione nell'applicazione in fase di sviluppo ed è stata mandata in produzione in questa forma.
Come puoi vedere, la distribuzione segue tutti i passaggi precedenti e ~kubectl get pods mostra che entrambi i pod sono in esecuzione. Ma a differenza della distribuzione precedente, il registro mostra lo stato di timeout. Cioè, poiché il controllo dello stato non è riuscito, non è possibile distribuire la nuova versione dell'applicazione. Di conseguenza, vedi che il sistema è tornato a utilizzare la vecchia versione dell'applicazione e la nuova versione è stata semplicemente disinstallata.
L'aspetto positivo è che anche se si dispone di un numero enorme di richieste simultanee in arrivo nell'applicazione, queste non noteranno nemmeno i tempi di inattività durante l'implementazione della procedura di distribuzione. Se provi questa applicazione utilizzando il framework Gatling, che le invia quante più richieste possibile, nessuna di queste richieste verrà ignorata. Ciò significa che i nostri utenti non noteranno nemmeno gli aggiornamenti di versione in tempo reale. Se fallisce, il lavoro continuerà sulla vecchia versione; se ha successo, gli utenti passeranno alla nuova versione.
C'è solo una cosa che può fallire: se il controllo dello stato ha esito positivo, ma l'applicazione fallisce non appena le viene applicato il carico di lavoro, ovvero il collasso avverrà solo dopo il completamento della distribuzione. In questo caso, dovrai ripristinare manualmente la versione precedente. Quindi, abbiamo esaminato come utilizzare Kubernetes con gli strumenti open source progettati per questo. Il processo di distribuzione sarà molto più semplice se crei questi strumenti nelle pipeline di creazione/distribuzione. Allo stesso tempo, per avviare la distribuzione, è possibile utilizzare l'interfaccia utente o automatizzare completamente questo processo utilizzando, ad esempio, commit to master.
Il nostro Build Server creerà un'immagine Docker, la inserirà in Docker Hub o in qualsiasi registro tu utilizzi. Docker Hub supporta il webhook, quindi possiamo attivare la distribuzione remota tramite Deployer nel modo mostrato sopra. In questo modo puoi automatizzare completamente la distribuzione della tua applicazione alla potenziale produzione.
Passiamo all'argomento successivo: ridimensionamento del cluster Kubernetes. Tieni presente che il comando kubectl è un comando di ridimensionamento. Con ulteriore aiuto, possiamo facilmente aumentare il numero di repliche nel nostro cluster esistente. Tuttavia, in pratica, di solito vogliamo aumentare il numero di nodi anziché di pod.
Allo stesso tempo, durante l'orario di lavoro potrebbe essere necessario aumentare e di notte, per ridurre il costo dei servizi Amazon, potrebbe essere necessario ridurre il numero di istanze dell'applicazione in esecuzione. Ciò non significa che sarà sufficiente ridimensionare solo il numero di pod, perché anche se uno dei nodi è inattivo, dovrai comunque pagare Amazon per questo. Cioè, oltre a ridimensionare i pod, dovrai ridimensionare il numero di macchine utilizzate.
Questo può essere complicato perché, sia che utilizziamo Amazon o un altro servizio cloud, Kubernetes non sa nulla del numero di macchine utilizzate. Manca uno strumento che permetta di scalare il sistema a livello di nodo.
Quindi dovremo occuparci sia dei nodi che dei pod. Possiamo facilmente scalare il lancio di nuovi nodi utilizzando l'API AWS e le macchine del gruppo Scaling per configurare il numero di nodi di lavoro Kubernetes. Puoi anche utilizzare cloud-init o uno script simile per registrare i nodi nel cluster Kubernetes.
La nuova macchina si avvia nel gruppo Scaling, si inizializza come nodo, si registra nel registro del master e inizia a funzionare. Successivamente è possibile aumentare il numero di repliche da utilizzare sui nodi risultanti. La riduzione delle dimensioni richiede uno sforzo maggiore, poiché è necessario assicurarsi che tale passaggio non porti alla distruzione delle applicazioni già in esecuzione dopo lo spegnimento delle macchine “non necessarie”. Per evitare tale scenario, è necessario impostare i nodi sullo stato “non programmabile”. Ciò significa che lo scheduler predefinito ignorerà questi nodi durante la pianificazione dei pod DaemonSet. Lo scheduler non cancellerà nulla da questi server, ma non lancerà nemmeno nuovi contenitori lì. Il passo successivo è eliminare il nodo di drenaggio, ovvero trasferire i pod in esecuzione da esso a un'altra macchina o ad altri nodi che abbiano capacità sufficiente per questo. Dopo esserti assicurato che non siano più presenti contenitori su questi nodi, puoi rimuoverli da Kubernetes. Successivamente cesseranno semplicemente di esistere per Kubernetes. Successivamente, devi utilizzare l'API AWS per disabilitare i nodi o le macchine non necessari.
Puoi utilizzare Amdatu Scalerd, un altro strumento di dimensionamento open source simile all'API AWS. Fornisce una CLI per aggiungere o rimuovere nodi in un cluster. La sua caratteristica interessante è la possibilità di configurare lo scheduler utilizzando il seguente file json.
Il codice riportato riduce della metà la capacità del cluster durante il periodo notturno. Configura sia il numero di repliche disponibili che la capacità desiderata del cluster Amazon. L'utilizzo di questo pianificatore ridurrà automaticamente il numero di nodi durante la notte e li aumenterà al mattino, risparmiando sui costi di utilizzo dei nodi da un servizio cloud come Amazon. Questa funzionalità non è integrata in Kubernetes, ma l'utilizzo di Scalerd ti consentirà di ridimensionare questa piattaforma come preferisci.
Vorrei sottolineare che molte persone mi dicono: "Va tutto bene, ma per quanto riguarda il mio database, che di solito è statico?" Come puoi eseguire qualcosa di simile in un ambiente dinamico come Kubernetes? Secondo me, non dovresti farlo, non dovresti provare a gestire un data warehouse in Kubernetes. Questo è tecnicamente possibile e ci sono tutorial su Internet su questo argomento, ma ti complicherà seriamente la vita.
Sì, esiste il concetto di archivi persistenti in Kubernetes e puoi provare a eseguire archivi dati come Mongo o MySQL, ma questo è un compito piuttosto laborioso. Ciò è dovuto al fatto che i data warehouse non supportano completamente l'interazione con un ambiente dinamico. La maggior parte dei database richiede una configurazione significativa, inclusa la configurazione manuale del cluster, non ama la scalabilità automatica e altre cose simili.
Pertanto, non dovresti complicarti la vita provando a gestire un data warehouse in Kubernetes. Organizza il tuo lavoro in modo tradizionale utilizzando servizi familiari e fornisci semplicemente a Kubernetes la possibilità di utilizzarli.
Per concludere l'argomento vorrei presentarvi la piattaforma Cloud RTI basata su Kubernetes, su cui sta lavorando il mio team. Fornisce registrazione centralizzata, monitoraggio di applicazioni e cluster e molte altre funzionalità utili che torneranno utili. Utilizza vari strumenti open source come Grafana per visualizzare il monitoraggio.
C'era una domanda sul perché utilizzare il bilanciatore del carico ha-proxy con Kubernetes. Bella domanda perché attualmente ci sono 2 livelli di bilanciamento del carico. I servizi Kubernetes risiedono ancora su indirizzi IP virtuali. Non puoi utilizzarli per le porte su macchine host esterne perché se Amazon sovraccarica il suo host cloud, l'indirizzo cambierà. Questo è il motivo per cui posizioniamo ha-proxy davanti ai servizi, per creare una struttura più statica affinché il traffico possa comunicare senza problemi con Kubernetes.
Un'altra buona domanda è: come puoi gestire le modifiche allo schema del database durante la distribuzione blu/verde? Il fatto è che, indipendentemente dall'uso di Kubernetes, modificare lo schema del database è un compito difficile. È necessario assicurarsi che il vecchio e il nuovo schema siano compatibili, dopodiché è possibile aggiornare il database e quindi aggiornare le applicazioni stesse. È possibile scambiare a caldo il database e quindi aggiornare le applicazioni. Conosco persone che hanno avviato un cluster di database completamente nuovo con un nuovo schema, questa è un'opzione se hai un database senza schema come Mongo, ma comunque non è un compito facile. Se non hai ulteriori domande, grazie per l'attenzione!
Alcuni annunci 🙂
Grazie per stare con noi. Ti piacciono i nostri articoli? Vuoi vedere contenuti più interessanti? Sostienici effettuando un ordine o raccomandando agli amici, , un analogo unico dei server entry-level, che è stato inventato da noi per te: (disponibile con RAID1 e RAID10, fino a 24 core e fino a 40 GB DDR4).
Dell R730xd 2 volte più economico nel data center Equinix Tier IV ad Amsterdam? Solo qui In Olanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - da $99! Leggi
Fonte: habr.com