CREAZIONE DI MICROSERVIZI MONGODB A

DISPONIBILITÀ ELEVATA CON

CONTENITORI DOCKER E KUBERNETES

Marco Bonezzi

Technical Services Engineer Senior, MongoDB

@marcobonezzi

marco@mongodb.com

Informazioni sul relatore

Sono Marco Bonezzi:

Senior TSE in MongoDB

TSE = aiuto i clienti a ottenere il massimo da MongoDB

Sede di lavoro: Dublino, Irlanda

Esperienza in database, sistemi distribuiti, alta disponibilità e

contenitori:

MICROSERVIZI E CONTENITORI

App

VI SONO PROBLEMI COMUNI NELL’UTILIZZO DEI CONTENITORI:

Capacità

Connettività

Stato

Isolamento

Affinità

Come

gestire

tutto

questo?

ARGOMENTI DI OGGI

1. Distribuzione di MongoDB su contenitori utilizzando

Kubernetes

1. Creazione di uno StatefulSet per la nostra distribuzione di

MongoDB

1. Raccomandazioni per uno scenario di produzione per i set

di repliche su GCE

1. Considerazioni sulla disponibilità elevata per

un’applicazione a microservizi

1. MONGODB SU CONTENITORI CON KUBERNETES

• Perché MongoDB è particolarmente adatto ai

microservizi:

• Vantaggi dell’utilizzo di Kubernetes: automatizzazione più efficiente

della distribuzione e della pianificazione dei contenitori MongoDB

su un cluster.

Time-to-market Scalabilità Resilienza

Allineamento (API)Modello dati

flessibileDisponibilitá

Orchestrazione Persistenza Monitoraggio

COMPONENTI DI KUBERNETES

Nodo: Fornisce capacitào Computer agente per i pod (e i loro contenitori)

o Virtuale o fisico

o Possono essere raggruppati in un cluster, gestito dal nodo primario

CPU

Memoria

CPU

Memoria

Po

d

Po

d

Po

d

Pod: Consuma capacità

Gruppo di uno o più contenitori di applicazioni + risorse condivise

per i contenitori

contenitor

econtenitor

econtenitor

econtenitor

e

VolumeVolume

VolumeIP

Immagine

Porta

……

POD

Contenitore: Unità di raggruppamento

Processo isolato. Basato sul kernel

Linux:

• Spazi dei nomi: ciò che un processo può

vedere

• Gruppi di controllo: ciò che un processo può utilizzare

Applicazione + dipendenze + kernel condiviso + librerie

contenitore

mongod –dbpath /data/db--port 27017

contenito

re

Servizio Consente all’applicazione di ricevere traffico

o Set logico di pod e criteri per accedervi

o LabelSelector per definire i pod di destinazione

o Tipi disponibili: ClusterIP, NodePort, LoadBalancer, ExternalName o Headless

Servizio B:

10.10.9.3

Servizio A:

10.10.9.4

POD

NOD

O

ESEMPIO DI SET DI REPLICHE BASE

Nodo

S

P

S

mongod

mongodmongod

https://github.com/kubernetes/minikube

ESEMPIO DI SET DI REPLICHE BASE

https://github.com/sisteming/mongo-kube/tree/master/demo1

2. CREAZIONE DEL NOSTRO STATEFULSET DI MONGODB• StatefulSet: ideato per applicazioni che richiedono

• Componenti richiesti:

Identificativi di rete stabili e

univoci

mongo-1

mongo-n...

Volu

meVolu

medati

Archiviazione stabile e

persistente

1 2 3 n

Distribuzione e

ridimensionamento ordinati,

con gestione automatica degli

errori

Eliminazione e terminazione

ordinate, con gestione

automatica degli errori

Richiesta

volume

persistente

Servizio

headlessStatefulSet

STATEFULSET

• Fornisce ai pod un’identità univoca che include un numero ordinale

L’identità resta associata al pod, a prescindere dal nodo su cui è pianificato

Nomi host:

Pod creati, ridimensionati ed eliminati sequenzialmente (mongo-{0..N-1})

mongo-

1

mongo-

2

mongo-

0

FUNZIONALITÀ BETA A PARTIRE DA

KUBERNETES 1.5

$(nome StatefulSet)-$(ordinale)

SERVIZIO HEADLESS

• Simile ai servizi Kubernetes ma senza bilanciamento del carico

‒ Combinato con StatefulSet: indirizzi DNS univoci per accedere ai pod

‒ Il modello del nome DNS è <nome-pod>.<nome-servizio>

Sono mongo-1.mongo!

Bene, posso

aggiungervi entrambi

al set di repliche

Sono mongo-

2.mongo!

rs.initiate()rs.add(“mongo-1.mongo:27017”)rs.add(“mongo-2.mongo:27017”)

VOLUMI DI ARCHIVIAZIONE PERSISTENTE

• Archiviazione: componente critico per i contenitori con stato

• Provisioning di volumi dinamici

Prima: provisioning della nuova risorsa di archiviazione, quindi creazione

del volume in Kubernetes

Ora: provisioning dinamico utilizzando lo strumento definito

Volume

persistente

Archiviazion

e

fisica

Richiesta

volume

persisten

te

Volume

persistente

Richiesta

volume

persisten

te

POD

POD

StatefulSet

STABILE A PARTIRE DA KUBERNETES 1.6

STATEFULSET MONGODB

STATEFULSET MONGODB

STATEFULSET MONGODB

POD - mongo-0

contenitore

(mongod)

POD - mongo-1 POD - mongo-2

Volume

SSD

Volume

SSD

Volume

SSD

Servizio headless (*.mongo, 27017)

contenitore

(mongod)

contenitore

(mongod)

Applicazione

RIEPILOGO: PERCHÉ GLI STATEFULSET SONO OTTIMI PER MONGODB

Identità pod univoca

Rete stabile

Archiviazione stabile

Scalabilità

Nomi host noti e prevedibili

Persistenza resiliente alla ripianificazione

Scalabilità delle letture dell’applicazione

Gestione più facile

DEMO 2: SET DI REPLICHE COME STATEFULSET

mongo-watch: https://github.com/sisteming/mongo-

kube/tree/master/mongo-watch

https://github.com/sisteming/mongo-kube/tree/master/demo2

Nodo 2Nodo 1

3. ORCHESTRAZIONE E DISTRIBUZIONE DI STATEFULSET PER UNO SCENARIO DI PRODUZIONE

Nodo 0rs0

• I set di repliche garantiscono la disponibilità elevata

rs0 rs0

Come assicurarsi che tutti i contenitori siano distribuiti

uniformemente?

• Cluster Kubernetes

o Cluster coordinato di computer connessi per operare come una singola unità

o Applicazioni disaccoppiate dai singoli host

o Automatizza la distribuzione e la pianificazione dei contenitori delle applicazioni attraverso un cluster

• Due risorse principali

PRIMARIO NODO

Kubelet Docker/rkt

Pianificazione

applicazioni

Mantenimento stato

Scalabilità

Aggiornamenti in

sequenza

Computer agente

Kubelet: agente (API)

Docker/rkt: runtime

contenitore

PIANIFICAZIONE POD

• Il primario controlla i nodi

(minion) tramite lo strumento di

pianificazione

• Ha il compito di tenere traccia

di tutte le risorse e i pod

• Si occupa di:

Requisiti di risorse

Vincoli

Affinità / anti-affinità

PIANIFICAZIONE DEI MEMBRI DEL SET DI REPLICHEnodeSelector Etichette

nodiAffinità

Idoneo se il nodo ha

ognuna delle coppie k-

v come etichette

Nodo 1

mongod-RS1

amb: prodrs: rs0

amb: prodrs: rs0

amb: testrs: rs-t1

mongod-RS1

Nome host

SO

Istanza

arch

Serie standard di

etichette,

beta.kubernetes.io

Vincoli

software/hardware

su nodi e pod

nodeAffinity

Affinità o anti-affinità

etichette

nodi

etichette sui

pod

attualmente in

esecuzione

CARATTERISTICHE BETA IN

KUBERNETES 1.6

DISTRIBUZIONE SU PIÙ NODI

Nodo 2Nodo 1Nodo 0

mongo-0 / rs0 mongo-1 / rs0 mongo-2 / rs0

CALCOLO DELLE RISORSE PER I CONTENITORI

È possibile definire la CPU e la memoria necessarie per ogni contenitore

CPU

Memoria

Richieste

Limiti

Quanto vorrei ricevere

(pianificazione)

Il massimo che posso

ricevere

(conflitto)

Unità CPU:spec.containers[].resources.limits.cpuspec.containers[].resources.requests.cpu

Byte:spec.containers[].resources.limits.memoryspec.containers[].resources.requests.memory

Strumento di pianificazioneAssicura che la somma delle richieste di risorse da parte dei contenitori

pianificati sia inferiore alla capacità del nodo.

DISPONIBILITÀ ELEVATA NEL NOSTRO STATEFULSET

Replica dei dati

Failover automatico

Scalabilità delle operazioni di lettura

Riavvio del contenitore (stesso

nodo)

Ripianificazione del contenitore

(nodo diverso)

Volumi persistenti

Set di repliche di MongoDB Kubernetes + StatefulSet

4. APPLICAZIONI A MICROSERVIZI CON MONGODB SU STATEFULSET KUBERNETES

Collegamento della nostra applicazione a microservizi (all’interno di

Kubernetes)mongodb://mongo-0.mongo,mongo-1.mongo,mongo-2.mongo:27017/APP_?

Casi da gestireo Disponibilità elevata:

1. Failover (cambio del primario nel set di repliche)

2. Pod terminato ( il pod viene terminato e torna in funzione)

3. Pod ripianificato ( il nodo è inattivo e il pod viene pianificato su un nodo diverso)

o Letture distribuite geograficamente:1. Lettura dal secondario più vicino utilizzando ReadPreference + tag del set di

repliche

DEMO: ELENCO DOMANDE E RISPOSTE

Scenari:

1. Failover set di repliche

2. Il pod con mongod primario viene terminato

3. Il nodo con mongod primario è inattivo

DEMO 3: STATEFULSET DEL SET DI REPLICHE MONGODB SUL MOTORE GOOGLE CLOUD https://github.com/sisteming/mongo-kube/tree/master/demo3

RIEPILOGO

Elementi chiave per un uso efficiente degli StatefulSet di Kubernetes

con MongoDB

Richieste di

risorse/limiti

Stato

persistenteIsolamento

AffinitàPianificazion

eIdentificativi di

rete univoci

Disponibilità

elevataEtichette Monitoraggio

Analisi di

liveness

Disruption

Budget

Ulteriori miglioramenti

GRAZIE!

https://github.com/sisteming/mongo-kube