{"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, automazione della scalabilit\u00e0 e dell'implementazione. Parte 2","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Kubernetes \u00e8 uno strumento eccellente per eseguire contenitori Docker in un ambiente produttivo clusterizzato. Tuttavia, esistono compiti che Kubernetes non \u00e8 in grado di gestire. Con distribuzioni frequenti in un ambiente di lavoro, abbiamo bisogno di un deployment Blue\/Green completamente automatizzato per evitare inattivit\u00e0 in questo processo, durante il quale \u00e8 anche necessario gestire le richieste HTTP esterne e gestire il caricamento SSL. Ci\u00f2 richiede integrazione con un bilanciatore di carico, come ha-proxy. Un altro compito \u00e8 il ridimensionamento semi-automatico del cluster Kubernetes stesso quando opera in un ambiente cloud, ad esempio, una riduzione parziale della dimensione del cluster durante la notte.<\/p>\n

Sebbene Kubernetes non disponga di queste funzionalit\u00e0 'out of the box', fornisce un'API che pu\u00f2 essere utilizzata per affrontare tali compiti. Gli strumenti per il deployment Blue\/Green automatizzato e il ridimensionamento del cluster Kubernetes sono stati sviluppati nell'ambito del progetto Cloud RTI, che \u00e8 stato creato sulla base di open-source.<\/p>\n

In questo articolo, nella trascrizione del video, si discute di come configurare Kubernetes insieme ad altri componenti open source per ottenere un ambiente pronto per la produzione, che riceve il codice dalla modifica git commit senza downtime in produzione.<\/p>\n

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

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

Quindi, una volta che hai accesso alle tue applicazioni dal mondo esterno, puoi iniziare a configurare completamente l'automazione, portandola a uno stato in cui puoi eseguire un git commit e assicurarti che quel git commit si concluda in produzione. Naturalmente, durante l'implementazione di questi passaggi e durante il deployment, non vogliamo affrontare downtime. Quindi, ogni automazione in Kubernetes inizia con l'API. <\/p>\n

\"DEVOXX
\n
\nKubernetes non \u00e8 uno strumento che pu\u00f2 essere utilizzato produttivamente 'out of the box'. Certo, puoi farlo, utilizzare kubectl e cos\u00ec via, ma l'API rimane la parte pi\u00f9 interessante e utile di questa piattaforma. Usando l'API come un insieme di funzioni, puoi accedere praticamente a tutto quello che desideri fare in Kubernetes. Anche kubectl utilizza REST API. <\/p>\n

Questo \u00e8 REST, quindi puoi utilizzare qualsiasi linguaggio e strumento per lavorare con questa API, ma le librerie utente possono semplificarti significativamente la vita. Il mio team ha scritto 2 di queste librerie: una per Java \/ OSGi e una per Go. Quest'ultima non viene utilizzata spesso, ma in ogni caso hai a disposizione queste cose utili. Rappresentano un progetto open-source parzialmente licenziato. Ci sono molte di queste librerie per diversi linguaggi, quindi puoi scegliere quelle pi\u00f9 adatte. <\/p>\n

\"DEVOXX
\n
\nQuindi, prima di iniziare l'automazione del deployment, \u00e8 necessario assicurarsi che questo processo non sar\u00e0 soggetto a fermi. Ad esempio, il nostro team effettua il deployment in produzione a met\u00e0 giornata, quando le persone utilizzano al massimo le applicazioni, quindi \u00e8 molto importante evitare ritardi in questo processo. Per evitare fermi, vengono utilizzati 2 metodi: il deployment blue\/green o l'aggiornamento continuo rolling update. 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 processo di deployment hai versioni diverse dell'applicazione in esecuzione contemporaneamente. In tal caso, puoi aggiornare l'interfaccia utente mentre il backend funziona con la vecchia versione, e il funzionamento dell'applicazione sar\u00e0 interrotto. Pertanto, dal punto di vista della programmazione, lavorare in tali condizioni \u00e8 piuttosto complicato. <\/p>\n

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

Il meccanismo del deployment blue\/green funziona come segue. Riceviamo il traffico per le nostre applicazioni tramite ha-proxy, che lo indirizza alle repliche dell'applicazione della stessa versione in esecuzione. <\/p>\n

Quando viene effettuato un nuovo deployment, utilizziamo Deployer, al quale vengono forniti nuovi componenti, e lui effettua il deployment della nuova versione. Il deployment della nuova versione dell'applicazione significa che viene \"sollevato\" un nuovo set di repliche, dopo di che queste repliche della nuova versione vengono avviate in un pod separato e nuovo. Tuttavia, ha-proxy non sa nulla di esse e non indirizza ancora alcun carico di lavoro a loro.<\/p>\n

Pertanto, \u00e8 necessario innanzitutto eseguire un controllo di funzionalit\u00e0 delle nuove versioni health checking, per assicurarsi che le repliche siano pronte a gestire il carico.<\/p>\n

\"DEVOXX
\n
\nTutti i componenti del deployment devono supportare qualche forma di health check. Questo pu\u00f2 essere un controllo HTTP molto semplice in cui si riceve un codice di stato 200, o un controllo pi\u00f9 approfondito in cui si verifica la connessione delle repliche al database e ad altri servizi, la stabilit\u00e0 delle connessioni nell'ambiente dinamico, se tutto viene avviato e funziona correttamente. Questo processo pu\u00f2 essere piuttosto complesso. <\/p>\n

\"DEVOXX
\n
\nDopo che il sistema si sar\u00e0 assicurato della funzionalit\u00e0 di tutte le repliche aggiornate, Deployer aggiorner\u00e0 la configurazione e passer\u00e0 il confd corretto, il quale riconfigurer\u00e0 ha-proxy. <\/p>\n

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

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

Ora vi presenter\u00f2 un nuovo componente di deployment \u2013 Deployer, che esegue i controlli di funzionalit\u00e0, riconfigura il proxy e cos\u00ec via. \u00c8 un concetto che non riguarda il mondo esterno e esiste all'interno di Kubernetes. Vi mostrer\u00f2 come creare il proprio concetto Deployer utilizzando strumenti open-source. <\/p>\n

Quindi, la prima cosa che fa Deployer \u00e8 creare un controller di replicazione RC utilizzando l'API Kubernetes. Questa API crea pod e servizi per il successivo deployment, ovvero crea un nuovo cluster per le nostre applicazioni. Una volta che l'RC verifica che le repliche siano state avviate, eseguir\u00e0 un controllo di salute Health check. A tal fine, nel Deployer viene utilizzato il comando GET \/health. Questo avvia i componenti di verifica appropriati e controlla tutti gli elementi che garantiscono il funzionamento del cluster. <\/p>\n

\"DEVOXX
\n
\nDopo che tutti i pod hanno segnalato il loro \"stato di salute\", Deployer crea un nuovo elemento di configurazione: un archivio distribuito etcd, utilizzato all'interno di Kubernetes, incluso per memorizzare la configurazione del bilanciatore di carico. Scriviamo i dati in etcd, e un piccolo strumento confd tiene traccia di etcd per eventuali nuovi dati. <\/p>\n

Se rileva delle modifiche alla configurazione iniziale, 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 verso i nuovi services, che garantiscono il funzionamento della nuova versione delle nostre applicazioni. <\/p>\n

\"DEVOXX
\n
\nCome vedete, nonostante la variet\u00e0 di componenti, non c'\u00e8 nulla di complicato. \u00c8 sufficiente 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
\nQuesto \u00e8 uno strumento per l'orchestrazione dei deployment di Kubernetes, dotato delle seguenti funzionalit\u00e0: <\/p>\n