Il modello tradizionale di Microservices su Kubernetes/Docker presenta alcuni svantaggi che portano a una gestione e un consumo di risorse eccessivamente complessi. In questo articolo spieghiamo come layline.io abbracci la tecnologia dei container e dell'orchestrazione dei container, aiutando a risolvere le sfide sopra menzionate con un approccio migliore.
Spiegazione rapida: Kubernetes (K8S) & Docker
Container
I programmi che girano su Kubernetes sono confezionati in Container. Il vantaggio è che software e dipendenze sono impacchettati insieme. Un problema in meno di cui preoccuparsi, garantendo l'indipendenza del Container. Esistono moltissimi Container pronti all'uso scaricabili da portali come DockerHub, che confezionano software di ogni tipo.
In teoria, puoi impacchettare molti programmi in un solo Container, ma la raccomandazione e lo standard del settore è un Container = un Processo. Questo rende tutto più granulare e consente di sostituire più facilmente i singoli container (e quindi i processi).
Pod
I Container non funzionano da soli, ma sono confezionati in un altro "contenitore". Questa volta si chiamano Pod. I Pod, tra le altre cose, gestiscono risorse virtuali come rete, memoria, CPU, ecc. per i Container che vi girano all'interno.
È importante capire che non si assegna potenza di calcolo a un Container, ma a un Pod. Pertanto, se esegui più di un Container nello stesso Pod, tutti devono condividere le risorse disponibili per il Pod. Per le stesse ragioni per cui non dovresti mettere più di un programma in un Container, non dovresti mettere più di un Container in un Pod, a meno che più Container non siano necessari per servire lo scopo del Microservice.
Problemi di risorse durante lo scaling in Kubernetes
In Kubernetes la valuta della scalabilità sono i Pod. Per avere più potenza di elaborazione, si avviano più Pod, noti anche come repliche.
Se osservi questo design, un Pod in sé è in realtà piuttosto statico. Se vuoi aderire alla massima flessibilità ed essere in grado di sostituire un programma con un altro, allora il tuo Pod contiene un Container, che a sua volta contiene un programma che verrà eseguito come un processo.
Considerando che le risorse effettive richieste per il container sono configurate a livello di Pod, l'immagine appare più simile a questa:
Osserva lo spazio contrassegnato come "slack". Quando dimensioni le risorse per un container, devi tenere conto di un certo margine in CPU e memoria. Ma poiché è quasi impossibile determinare esattamente le risorse necessarie per un programma, finisci per avere una certa riserva in ogni pod. Se ne esegui 100, il margine si somma 100 volte. Non c'è condivisione delle risorse tra i Pod. Inoltre, c'è un certo overhead per ogni Pod e Nodo che viene aggiunto al cluster. Quindi, sebbene il concetto di K8S sia complessivamente ottimo, aggiunge anche un considerevole overhead di risorse complessivo.
Distribuzione dei Container all'interno di un Cluster Kubernetes
I Pod sono anche il denominatore più piccolo per distribuire funzionalità all'interno di un Cluster Kubernetes. Supponiamo che tu abbia Microservices A, B e C e voglia distribuirli in modo non uniforme all'interno di un Cluster, hai o Pod individuali che contengono ciascuno A, B o C, oppure devi avere un certo numero di Pod per creare tutte le permutazioni di Pod contenenti i container A, B e C (ad esempio, un Pod con A e B, un Pod con A e C, ecc.). Questo significa gestire un gran numero di Pod, che può diventare rapidamente opprimente e inefficiente.
La distribuzione dei Pod diventa quindi una grande sfida di configurazione all'interno di Kubernetes e/o del tuo strumento CI/CD preferito. Aggiungi a questo la gestione dello scaling automatico e del bilanciamento del carico tra i Nodi e ti ritroverai con un grande mal di testa in termini di configurazione e monitoraggio.
Come layline.io affronta scalabilità, risorse e distribuzione in un Cluster Kubernetes
Reactive Engine
layline.io introduce il Reactive Engine. Il motore funge da contesto di esecuzione per i Workflows che possono essere configurati per funzionare all'interno di un Reactive Engine. I Workflows sono paragonabili ai Microservices in quanto svolgono specifici compiti di elaborazione dei dati che vanno dall'ingestione, analisi e arricchimento, fino alla risposta a richieste di query, ecc. I Workflows sono configurati utilizzando il Configuration Center basato sul web:
Molti Reactive Engines formano un Reactive Cluster a sé stante. Quando si configura layline.io in un ambiente Cluster come Kubernetes, in realtà si configurano un certo numero di Nodi che eseguono Reactive Engines incapsulati in container:
Tutti i Reactive Engines sono creati uguali. Servono come contesti di esecuzione per i Workflows. Semplificando, puoi considerare i Workflows equivalenti ai Microservices. La differenza è che i Workflows sono configurati e quindi una Configurazione, e non codice oggetto programmato come nei tipici Microservices.
Ogni Reactive Engine può eseguire diversi Workflows (A, B e C sopra). Ogni Workflow può essere istanziato dinamicamente più volte. Il numero di istanze è limitato da quante risorse consuma una singola istanza di Workflow e da quante risorse sono disponibili e assegnate al contesto di esecuzione in cui gira il Reactive Engine stesso. In un Cluster Kubernetes questa sarebbe l'immagine di un Pod corrispondente:
Qualsiasi Reactive Engine può eseguire qualsiasi Workflow. I Workflows sono distribuiti direttamente tramite il Configuration Center o tramite il tuo strumento CI/CD preferito (ad esempio, Bamboo e altri).
Questo potrebbe risultare in una configurazione come questa:
Scalabilità elastica
Il numero di istanze di ciascun Workflow può essere scalato dinamicamente, sia tramite intervento manuale dal Config Center o dalla riga di comando, sia automaticamente in base alla pressione dei dati.
Mentre il percorso standard di Kubernetes per scalare avviando Pod aggiuntivi rimane valido, puoi semplicemente avviare istanze aggiuntive di Workflow all'interno di un Pod. Nota che in questo esempio non verrebbero attivati Pod aggiuntivi, dato che ogni Pod contiene abbastanza margine per scalare. Poiché tutto viene scalato all'interno di un Reactive Engine, questo processo è estremamente veloce ed efficiente, richiedendo solo poche risorse aggiuntive per istanza e nessun intervento a livello di Kubernetes.
Vantaggio Risorse
Ha senso pensare che si richieda rispettivamente potenza di calcolo e RAM indipendentemente dal fatto che si distribuiscano 30 Pod con lo stesso Microservice su tre Nodi, o tre Reactive Engines con 10 istanze dello stesso Workflow ciascuno su tre Nodi. Ma non è così.
A seconda delle caratteristiche del Microservice che viene sostituito da un Workflow, in genere si risparmia tra il 25-50% delle risorse rispetto al modo tradizionale di distribuire i Microservices. È anche vero, tuttavia, che un Reactive Engine che esegue una sola istanza di Workflow richiede più risorse rispetto a un Microservice personalizzato eseguito una sola volta.
È un compromesso tra flessibilità e requisiti di risorse, che si sposta rapidamente a favore del modello di layline.io con l'aumentare delle dimensioni del tuo scenario di elaborazione.
Vantaggio Configurazione
Configurare layline.io in un cluster Kubernetes/Docker significa distribuire lo stesso container su ogni Nodo. Ogni container esegue un Reactive Engine e non ci sono altri tipi di container con contenuti diversi. Solo uno.
Affinché un Reactive Engine sappia quali Workflows eseguire, una configurazione viene iniettata in fase di runtime. Poiché tutti i Reactive Engines formano un Reactive Cluster a sé stante, è sufficiente iniettare la Configurazione in un solo Reactive Engine. Questa viene poi automaticamente distribuita a tutti gli altri Engines nel Cluster. Anche in questo caso, tutto può essere attivato manualmente o automaticamente tramite strumenti CI/CD.
Quindi, a differenza del concetto puro di Kubernetes/Docker, non c'è bisogno di preoccuparsi di diversi Pod contenenti diversi container che devono essere ricostruiti a ogni modifica e poi gestiti dal punto di vista della distribuzione. Contrariamente a Kubernetes, non devi pensare a dove eseguire quale Pod/Container in anticipo, o a come riorganizzare i Pod nel caso tu voglia riorganizzarli. In layline.io puoi semplicemente attivare un Workflow precaricato in uno o più Reactive Engines, o distribuire una nuova Configurazione di Workflow al Cluster per mettere online questo Workflow.
Riepilogo
| Aspetto | Kubernetes/Docker | layline.io |
|---|---|---|
| Scalabilità | Scala tramite Pod | Scala all'interno del Pod tramite istanze di Workflow |
| Tempo di reazione dello scaling | medio | veloce |
| Consumo di risorse | Migliore con scenari piccoli | Migliore con scenari medi o grandi |
| Configurazione | Molti Pod e Container diversi | Configurazioni iniettate nel Reactive Engine |
Kubernetes è fantastico. Punto. Ma ci sono degli svantaggi in termini di complessità e operatività.
layline.io offre un modo molto migliore e più snello non solo per creare e gestire i Servizi, ma anche per gestirli e distribuirli in un ambiente Cluster. Per scenari medi o grandi, c'è anche un vantaggio significativo in termini di gestione e consumo delle risorse.
Puoi scaricare e utilizzare gratuitamente layline.io qui. Se hai domande su layline.io non esitare a contattarci!
Risorse
- Scarica layline.io
- Fixing what's wrong with Microservices
- Leggi di più su layline.io qui.
- Contattaci a hello@layline.io.