Una guida Kubernetes per gli amanti di Docker Swarm

Hai padroneggiato lo Sciame. Ora è il momento di padroneggiare l’Helm

Non ho mai guardato a Kubernetes perché Swarm mi ha fornito tutto ciò di cui avevo bisogno in termini di Container Orchestration. Pur essendo semplice da usare, ha brillato in un mondo in cui gli orchestrator di container come Mesos e Kubernetes erano difficili da configurare.

Ma ora nel 2018 la storia è abbastanza diversa: tutti e tre i principali fornitori di cloud (AWS, Google Cloud e Azure) ora scommettono su Kubernetes con Kubernetes as a Service gestito. Questo è grande, perché prende tutta la complessità della gestione di un cluster (che è il principale punto dolente in K8S, secondo me) e lo mette nelle mani del Cloud Provider. Per non parlare del fatto che le nuove versioni di Docker Enterprise e Docker per Mac & amp; Windows verrà fornito in bundle con Kubernetes fuori dalla scatola.

Anche le dimensioni della community sono un punto importante di questa storia. Ogni volta che ho avuto un problema con Docker Swarm, mi ci è voluto un po ‘per trovare una soluzione. Al contrario, anche con più funzionalità e possibilità di configurazione, semplici ricerche su Google e porre domande su Slack mi hanno aiutato a risolvere tutti i problemi che ho avuto finora con Kubernetes. Non fraintendetemi qui: la community di Docker Swarm è eccezionale, ma non eccezionale come quella di Kubernetes.

Questo punto non è colpa di Docker Swarm: la realtà è che Kubernetes è in fase di sviluppo attivo da parte di aziende come Google, Microsoft, Red Hat, IBM (e Docker, suppongo), nonché di singoli collaboratori. Dare uno sguardo a entrambi i repository Github rivela che in realtà Kubernetes è molto più attivo.

Ma ehi! Questa doveva essere una guida, quindi iniziamo confrontando come ottenere scenari simili sia in Swarm che in K8S.

Dichiarazione di non responsabilità: questa guida non intendeva fornire scenari pronti per la produzione. Ho reso semplice illustrare più facilmente le somiglianze tra Swarm e K8S.

Avvio di un cluster (1 master e 1 lavoratore)

Per mantenere le cose semplici, creiamo un semplice cluster con 1 Master e 1 Worker.

Avvio di un cluster – Docker Swarm

L’avvio di un cluster in Docker Swarm è semplicissimo. Con Docker installato sulla macchina, eseguire semplicemente:

Quindi, su un’altra macchina nella stessa rete, incolla il comando di cui sopra:

Avvio di un cluster – Kubernetes (utilizzando kubeadm)

Ho menzionato alcune volte che la configurazione di un cluster Kubernetes è complicata. Anche se ciò rimane vero, esiste uno strumento (che è ancora in versione beta) chiamato kubeadm che semplifica il processo. In effetti, la configurazione di un cluster K8S con kubeadm è molto simile a Docker Swarm. Installare kubeadm è facile, poiché può essere installato con la maggior parte dei gestori di pacchetti (brew, apt, ecc.)

Il completamento del comando richiede un po ‘di tempo, perché Kubernetes si basa sulla configurazione di servizi esterni come etcd per funzionare. Tutto questo è automatizzato con kubeadm.

Come con Swarm, per unirsi a un altro nodo è sufficiente eseguire il comando emesso in un altro nodo:

Finora, il processo di creazione del cluster è quasi identico in entrambe le soluzioni. Ma Kubernetes necessita di un passaggio aggiuntivo:

Installazione di una rete pod

Docker swarm viene fornito in bundle con una rete di servizi che fornisce funzionalità di rete all’interno del cluster. Sebbene sia conveniente, Kubernetes offre una maggiore flessibilità in questo spazio, consentendoti di installare una rete a tua scelta. Le implementazioni ufficiali includono Calico, Canal, Flannel, Kube-Router, Romana e Weave Net . Il processo di installazione di entrambi è più o meno lo stesso, ma continuerò con Calico per questo tutorial.

Per ulteriori informazioni sull’utilizzo di kubeadm, controlla qui

Avvio di un cluster – Kubernetes (utilizzando minikube)

Se vuoi sperimentare con Kubernetes sulla tua macchina locale, c’è un ottimo strumento chiamato minikube che fa girare un cluster Kubernetes all’interno di una macchina virtuale. Non ho intenzione di estendere così tanto con questo, ma puoi eseguire minikube nel tuo sistema facendo:

Per ulteriori informazioni su minikube, controlla qui

Esecuzione di un servizio

Ora che abbiamo un cluster in esecuzione, avviamo alcuni servizi! Sebbene ci siano alcune differenze dietro le quinte, farlo è molto simile in entrambi gli orchestratori.

Esecuzione di un servizio – Docker Swarm (inline)

Per eseguire un servizio con un comando inline, eseguire semplicemente:

Esecuzione di un servizio – Kubernetes (inline)

Come puoi immaginare, fare la stessa cosa in Kubernetes non è poi così diverso:

Come visto sopra, avevamo bisogno di due comandi per replicare il comportamento di Swarm. La differenza principale tra entrambi gli orchestratori è che nel caso di Swarm, abbiamo esposto esplicitamente la porta 80 sull’host. In Kubernetes, la porta viene selezionata in modo casuale da un intervallo di porte preconfigurato. Possiamo selezionare la porta di destinazione con un flag, ma deve essere all’interno di tale intervallo. Possiamo interrogare la porta selezionata utilizzando:

Esecuzione di un servizio – Docker Swarm (YAML)

Puoi definire servizi (così come volumi, reti e configurazioni) in un file stack. Un file Stack è un file YAML che utilizza la stessa notazione di Docker-Compose, con funzionalità aggiuntive. Avviamo il nostro servizio nginx utilizzando questa tecnica:

Poiché non abbiamo specificato alcuna rete, Docker Swarm ne ha creata una per noi. Tieni presente che ciò significa che non è possibile accedere al servizio nginx tramite il nome del servizio da un altro servizio. Se vogliamo farlo, possiamo definire tutti i servizi che devono comunicare tra loro nello stesso YAML (oltre che in una rete), oppure importare una rete di overlay preesistente in entrambi gli stack.

Esecuzione di un servizio – Kubernetes (YAML)

Kubernetes consente di creare risorse tramite un file manifest di Kubernetes. Questi file possono essere file YAML o file JSON. L’uso di YAML è il più consigliato, perché è praticamente lo standard.

Poiché è costruito attorno a un’architettura più modulare, Kubernetes richiede due risorse per ottenere la stessa funzionalità di Swarm: un Depoyment e un Servizio .

Una distribuzione definisce praticamente le caratteristiche di un servizio. È qui che vengono definiti contenitori, volumi, segreti e configurazioni. Le distribuzioni definiscono anche il numero di repliche e le strategie di replica e posizionamento. Puoi vederli come l’equivalente di una definizione di stack in swarm, meno il bilanciamento del carico.

In effetti, le implementazioni sono un’astrazione di livello superiore rispetto alle risorse Kubernetes di livello inferiore come pod e set di replica. Tutto quanto definito nella parte modello della definizione di distribuzione definisce un pod , che è la più piccola unità di pianificazione fornita da Kubernetes. Un pod non è uguale a un contenitore. È un insieme di risorse che dovrebbero essere programmate insieme; ad esempio un contenitore e un volume o due contenitori. Nella maggior parte dei casi, un pod conterrà un solo contenitore, ma è importante comprendere questa differenza.

La seconda parte del file definisce una risorsa del servizio , che può essere vista come un modo per fare riferimento a un insieme di pod nella rete e bilanciare il carico tra di loro. Il tipo NodePort indica a Kubernetes di assegnare una porta accessibile dall’esterno su ogni nodo del cluster (la stessa su tutti i nodi). Questo è ciò che ha fatto anche Swarm. Tu dici ai servizi cosa bilanciare il carico utilizzando i selettori ed è per questo che l’etichettatura è così importante in Kubernetes.

In questo caso, Kubernetes è molto più potente: ad esempio, puoi definire un servizio di tipo LoadBalancer, che genererà un Load Balancer nel tuo provider cloud (configurazione precedente), come un ELB in AWS, che punterà al tuo servizio. Il tipo di servizio predefinito è ClusterIP, che definisce un servizio a cui è possibile accedere ovunque nel cluster su una determinata porta, ma non esternamente. Usare ClusterIP equivale a definire un servizio senza una mappatura esterna in Swarm.

Creazione di volumi

I volumi sono necessari per mantenere lo stato e fornire le configurazioni. Entrambi gli orchestratori forniscono modi semplici per definirli, ma Kubernetes assume il comando con molte più funzionalità.

Creazione di volumi – Docker Swarm

Aggiungiamo un volume al nostro servizio nginx:

Questo è il caso più semplice e ovviamente questo tipo di volume non fornisce alcun vantaggio in questo caso, ma è sufficiente per una dimostrazione.

Creazione di volumi – Kubernetes

Fare lo stesso in K8S è abbastanza facile:

Il tipo di volume emptyDir è il tipo di volume più semplice fornito da Kubernetes. Mappa una cartella all’interno del contenitore con una cartella nel nodo che scompare quando il pod viene arrestato.
Kubernetes viene fornito con 26 tipi di volumi, quindi penso che copra praticamente qualsiasi caso d’uso. Ad esempio, puoi definire un volume supportato da un volume EBS in AWS.

Questo è tutto

Ci sono sicuramente più risorse oltre ai servizi e ai volumi, ma per ora le lascerò fuori da questa guida. Una delle mie risorse preferite in kubernetes sono ConfigMaps , che sono simili a Docker Configs ma forniscono funzionalità migliori. Farò uno sforzo per scrivere un’altra guida che metta a confronto questi due, ma per ora chiamiamolo un giorno.

Conclusione

Usare kubernetes allo stesso modo di Swarm è più facile che mai. Ci vorrà del tempo per prendere la decisione di migrare tutta la nostra infrastruttura su Kubernetes. Nel momento in cui scrivo, Swarm ci dà tutto ciò di cui abbiamo bisogno, ma è bello sapere che la barriera all’ingresso di K8S si sta abbassando con il passare del tempo.

Sono un ingegnere del software con sede a Buenos Aires, in Argentina. Attualmente lavora come Platform Engineer presso Etermax, la principale azienda di giochi per dispositivi mobili in America Latina.