{"id":83787,"date":"2020-06-03T07:42:26","date_gmt":"2020-06-03T05:42:26","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/devoxx-uk-kubernetes-v-prodakshene-blue-green-deployment-avtomasshtabirovanie-i-avtomatizacziya-razvertyvaniya-chast-2"},"modified":"2020-06-03T07:42:26","modified_gmt":"2020-06-03T05:42:26","slug":"devoxx-uk-kubernetes-v-prodakshene-blue-green-deployment-avtomasshtabirovanie-i-avtomatizacziya-razvertyvaniya-chast-2","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/devoxx-uk-kubernetes-v-prodakshene-blue-green-deployment-avtomasshtabirovanie-i-avtomatizacziya-razvertyvaniya-chast-2","title":{"rendered":"DEVOXX UK. Kubernetes in produzione: Blue\/Green deployment, autoscaling e automazione del deployment. Parte 2.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Kubernetes \u00e8 un ottimo strumento per l'esecuzione di container Docker in un ambiente di produzione clusterizzato. Tuttavia, ci sono compiti che Kubernetes non \u00e8 in grado di risolvere. Durante il deployment frequente in un ambiente operativo, abbiamo bisogno di un sistema di Blue\/Green deployment completamente automatizzato per evitare downtime in questo processo, che deve anche gestire le richieste HTTP esterne e gestire il caricamento SSL. Ci\u00f2 richiede l'integrazione con un bilanciatore di carico, come ha-proxy. Un'altra sfida \u00e8 il ridimensionamento semi-automatico del cluster Kubernetes stesso quando si opera in un ambiente cloud, ad esempio una diminuzione parziale della dimensione del cluster durante la notte.<\/p>\n

Sebbene Kubernetes non disponga di queste funzionalit\u00e0 direttamente 'out of the box', offre API che possono essere utilizzate per affrontare compiti simili. Gli strumenti per il deployment automatizzato Blue\/Green e il ridimensionamento del cluster Kubernetes sono stati sviluppati all'interno del progetto Cloud RTI, creato sulla base di software open-source.<\/p>\n

In questo articolo, la trascrizione video spiega come configurare Kubernetes insieme ad altri componenti open source per creare un ambiente di produzione che gestisce il codice dal commit git senza interruzioni in produzione.<\/p>\n

\"DEVOXX<\/a><\/noindex><\/p>\n

DEVOXX UK. Kubernetes in produzione: Deployment Blue\/Green, autoscalabilit\u00e0 e automazione del deployment. Parte 1<\/a><\/noindex><\/p>\n

Quindi, una volta che hai accesso alle tue applicazioni dal mondo esterno, puoi procedere con la configurazione completa dell'automazione, raggiungendo il punto in cui puoi eseguire un commit git e assicurarti che questo commit git si conclusa in produzione. Naturalmente, durante l'implementazione di questi passaggi e nel processo di deployment, non vogliamo affrontare interruzioni. Pertanto, ogni automazione in Kubernetes inizia con l'API. <\/p>\n

\"DEVOXX
\n
\nKubernetes non \u00e8 uno strumento che pu\u00f2 essere utilizzato in modo produttivo \u00abcos\u00ec com'\u00e8\u00bb. Certo, puoi farlo, utilizzare kubectl e cos\u00ec via, ma l'API \u00e8 la parte pi\u00f9 interessante e utile di questa piattaforma. Utilizzando l'API come un insieme di funzioni, puoi accedere praticamente a tutto ci\u00f2 che desideri fare in Kubernetes. Anche kubectl stesso utilizza l'API REST. <\/p>\n

\u00c8 REST, quindi puoi utilizzare qualsiasi linguaggio e strumento per lavorare con questa API, ma le librerie client renderanno la tua vita molto pi\u00f9 semplice. Il mio team ha scritto 2 di queste librerie: una per Java \/ OSGi e una per Go. La seconda non viene utilizzata spesso, ma in ogni caso hai a disposizione queste risorse utili. Sono progetti open-source con licenza parziale. Ci sono molte di queste librerie disponibili per diversi linguaggi, quindi puoi scegliere quelle pi\u00f9 adatte. <\/p>\n

\"DEVOXX
\n
\nQuindi, prima di iniziare l'automazione del deployment, \u00e8 fondamentale assicurarsi che questo processo non subisca interruzioni. Ad esempio, il nostro team esegue il deployment in produzione a met\u00e0 giornata, quando le persone utilizzano maggiormente le applicazioni, quindi \u00e8 molto importante evitare ritardi in questo processo. Per prevenire downtime, si utilizzano 2 metodi: il deployment blue\/green o l'aggiornamento rolling. Nel secondo caso, se hai 5 repliche dell'applicazione in esecuzione, vengono aggiornate una dopo l'altra. Questo metodo funziona molto bene, ma non \u00e8 adatto se durante il deployment hai versioni diverse dell'applicazione in esecuzione contemporaneamente. In tal caso, puoi aggiornare l'interfaccia utente mentre il backend continua a lavorare con la vecchia versione, comportando l'interruzione del funzionamento dell'applicazione. Pertanto, sotto il profilo della programmazione, lavorare in tali condizioni \u00e8 piuttosto complicato. <\/p>\n

Questa \u00e8 una delle ragioni per cui preferiamo utilizzare il blue\/green deployment per automatizzare il dispiegamento delle nostre applicazioni. Con questo approccio, \u00e8 necessario assicurarsi che solo una versione dell'applicazione sia attiva in un dato momento. <\/p>\n

Il meccanismo del blue\/green deployment funziona nel seguente modo. Riceviamo il traffico per le nostre applicazioni attraverso ha-proxy, che lo instrada verso le repliche in esecuzione della stessa versione dell'applicazione. <\/p>\n

Quando viene effettuato un nuovo dispiegamento, utilizziamo Deployer, a cui vengono forniti i nuovi componenti, e si occupa del deploy della nuova versione. Il deploy della nuova versione dell'applicazione significa che viene \"attivato\" un nuovo insieme di repliche, che vengono quindi avviate in un pod separato e nuovo. Tuttavia, ha-proxy non \u00e8 a conoscenza di esse e al momento non instrada alcun carico di lavoro verso di esse.<\/p>\n

Pertanto, \u00e8 fondamentale eseguire prima il controllo della salute delle nuove versioni, per garantire che le repliche siano pronte a gestire il carico.<\/p>\n

\"DEVOXX
\n
\nTutti i componenti di distribuzione devono supportare una qualche forma di health check. Pu\u00f2 trattarsi di un semplice controllo HTTP in cui si ottiene un codice di stato 200, oppure di un controllo pi\u00f9 approfondito in cui si verifica la connessione tra le repliche e il database e altri servizi, la stabilit\u00e0 delle connessioni nell'ambiente dinamico, e se tutto si avvia e funziona correttamente. Questo processo pu\u00f2 essere piuttosto complesso. <\/p>\n

\"DEVOXX
\n
\nDopo che il sistema ha verificato il funzionamento di tutte le repliche aggiornate, Deployer aggiorner\u00e0 la configurazione e trasmetter\u00e0 il confd corretto, che riconfigurer\u00e0 ha-proxy. <\/p>\n

\"DEVOXX
\n
\nSolo dopo questo il traffico verr\u00e0 diretto al pod con le repliche della nuova versione, mentre il vecchio pod scomparir\u00e0. <\/p>\n

\"DEVOXX
\n
\nQuesto meccanismo non \u00e8 una caratteristica esclusiva di Kubernetes. Il concetto di Blue\/green deployment esiste da molto tempo e ha sempre utilizzato un bilanciatore di carico. Inizialmente si dirige tutto il traffico verso la vecchia versione dell'applicazione, e dopo l'aggiornamento si trasferisce completamente sulla nuova versione. Questo principio \u00e8 utilizzato non solo in Kubernetes.<\/p>\n

Ora vi presenter\u00f2 un nuovo componente di distribuzione - Deployer, che esegue il controllo delle funzionalit\u00e0, riconfigura il proxy e cos\u00ec via. Questo \u00e8 un concetto che non \u00e8 rivolto al mondo esterno e esiste all'interno di Kubernetes. Vi mostrer\u00f2 come creare il proprio concetto di Deployer utilizzando strumenti open-source. <\/p>\n

Quindi, la prima cosa che fa Deployer \u00e8 creare un controller di replica RC, utilizzando l'API di Kubernetes. Quest'API crea pod e servizi per la successiva distribuzione, ovvero crea un nuovo cluster per le nostre applicazioni. Una volta che RC verifica che le repliche siano state avviate, eseguir\u00e0 un controllo delle loro funzionalit\u00e0 tramite il Health check. A questo scopo, Deployer utilizza il comando GET \/health. Questo esegue i componenti di controllo appropriati e verifica tutti gli elementi che garantiscono il funzionamento del cluster. <\/p>\n

\"DEVOXX
\n
\nDopo che tutti i nodi hanno segnalato il loro stato di \u00absalute\u00bb, Deployer crea un nuovo elemento di configurazione: uno storage distribuito etcd, che viene utilizzato internamente in Kubernetes, inclusa la memorizzazione della configurazione del bilanciatore di carico. Registriamo i dati in etcd e un piccolo strumento confd monitora etcd per eventuali nuovi dati. <\/p>\n

Se rileva eventuali modifiche alla configurazione originale, genera un nuovo file di configurazione e lo trasmette a ha-proxy. In questo caso, ha-proxy si riavvia senza perdere alcuna connessione e indirizza il carico ai nuovi servizi, che garantiscono il funzionamento della nuova versione delle nostre applicazioni. <\/p>\n

\"DEVOXX
\n
\nCome potete vedere, nonostante l'abbondanza di componenti, non c'\u00e8 nulla di complicato. Dovete solo prestare maggiore attenzione all'API e a etcd. Voglio parlarvi di un deployer open-source che utilizziamo noi stessi: Amdatu Kubernetes Deployer.<\/p>\n

\"DEVOXX
\n
\n\u00c8 uno strumento per l'orchestrazione dei deployment di Kubernetes, dotato delle seguenti funzionalit\u00e0: <\/p>\n