Upload
mongodb
View
554
Download
2
Embed Size (px)
Citation preview
CREAZIONE DI MICROSERVIZI MONGODB A
DISPONIBILITÀ ELEVATA CON
CONTENITORI DOCKER E KUBERNETES
Marco Bonezzi
Technical Services Engineer Senior, MongoDB
@marcobonezzi
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