🥇Problemløs migration af MongoDB til Kubernetes

Denne artikel fortsætter vores seneste materiale om migrering af RabbitMQ og handler om MongoDB. Da vi håndterer mange Kubernetes- og MongoDB-klynger, har vi naturligt behov for at migrere data fra en installation til en anden uden nedetid. De primære scenarier er de samme: overførsel af MongoDB fra en virtuel/fysisk server til Kubernetes eller overførsel af MongoDB inden for en enkelt Kubernetes-klynge (fra et navnerum til et andet).

Vores opskrift er designet til tilfælde, hvor en gammel MongoDB-klynge fungerer (for eksempel med 3 noder og som allerede er i K8s eller på gamle servere), som et applikation arbejder med, der er hostet i Kubernetes:

Hvordan vil vi migrere en sådan klynge til den nye produktion i Kubernetes?

Teori

Den overordnede migreringsalgoritme er analog med den, der er beskrevet i situationen med RabbitMQ.

Det er vigtigt at bemærke, at for at kunne flytte, skal serverne med MongoDB og Kubernetes befinde sig i samme netværk. Noderne i MongoDB-klyngen vil kommunikere med hinanden via IP-adresserne fra de gamle servere (hvor de gamle installationer af MongoDB er placeret) og via DNS-navne fra pod'ene med MongoDB i K8s. Derfor skal der på de fysiske servere (med de gamle installationer) oprettes ruter til pod'ene, og derefter skal de konfigureres til at bruge DNS-serveren, der kører i Kubernetes (eller skrive de nødvendige navne i /etc/hosts, selvom det i almindelighed er bedre at undgå denne mulighed).

Næste skridt er at oprette MongoDB-klyngen i pod'ene i Kubernetes. I vores tilfælde består databasen af 3 noder, hvor hver node ligger i en separat K8s-pod – dog kan antallet også være et andet. I ConfigMap skal den gamle installations masteradresse for MongoDB angives: så vil de MongoDB-noder, der ligger i pod'ene i K8s, straks begynde at synkronisere med den.

Når alle pod'ene er oppe at køre, dannes der en MongoDB-klynge på 6 noder:

Bemærk, at pod'ene vil tage lang tid at starte, da hver pod startes én ad gangen, og ved opstart synkroniseres data med masteren.

Herefter kan applikationen skiftes til at bruge de nye MongoDB-servere:

Og det vil kun være tilbage at fjerne de gamle noder fra MongoDB-klyngen, hvorefter flytningen kan betragtes som afsluttet:

Vi anvender ofte denne skema i produktion, og for at lette brugen implementerede vi den i modulet addon-operator (denne nyttighed vi for nylig annoncerede), som gør det muligt at distribuere standardkonfigurationer af MongoDB på flere klynger. Vi planlægger at offentliggøre vores moduler snart, men indtil da præsenterer vi separate instruktioner, som man kan prøve den foreslåede løsning i aktion uden brug af addon-operator.

Prøver i praksis

Krav

Oplysninger:

Kubernetes klynge (minikube virker også);
MongoDB klynge (kan være installeret på bare metal eller være en almindelig klynge i Kubernetes fra det officielle Helm-diagram).

I det nedenstående eksempel vil den gamle klynge med MongoDB blive kaldt mongo-old og blive installeret i samme Kubernetes-klynge, hvor vi senere vil installere den nye (mongo-new).

Forbereder den gamle klynge

1. For at demonstrere den beskrevne skema i aktion, lad os oprette en "gammel" (dvs. migrerende) MongoDB klynge direkte i Kubernetes (i virkeligheden kan den være placeret på separate servere uden for K8s). For dette downloader vi Helm-diagrammet:

helm fetch --untar stable/mongodb-replicaset

… og redigerer det lidt for at indstille godkendelse:

auth:
  enabled: true
  adminUser: mongo
  adminPassword: pa33w0rd
  # metricsUser: metrics
  # metricsPassword: password
  # key: keycontent
  # existingKeySecret:
  # existingAdminSecret:
  # exisitingMetricsSecret:

Det er også muligt at indstille certifikater og meget mere. values.yaml 2. Installer diagrammet:

helm install . --name mongo-old --namespace mongo-old

Efter dette vil en test "gammel" installation af MongoDB blive startet:

kubectl --namespace=mongo-old get pods

Lad os gå ind i pod med dens master og oprette en testdatabase:

kubectl --namespace=mongo-old exec -ti mongo-old-mongodb-replicaset-0 mongo use admin db.auth('mongo','password') use music db.artists.insert({ artistname: "The Tea Party" }) show dbs

Da jeg gik ind i forskellige pod’ere, fandt jeg ud af, at masteren er

mongo-old-mongodb-replicaset-0 . Dog, for en mere bekvem løsning på dette spørgsmål, gives en kommando efter installationen af Helm-diagrammet for, hvordan man bestemmerMASTER_POD . I mit tilfælde (foraf 3 noder) ser det sådan ud: mongo-old for ((i = 0; i < 3; ++i)); do kubectl exec --namespace mongo-old mongo-old-mongodb-replicaset-$i -- sh -c 'mongo --eval="printjson(rs.isMaster())"'; done

Med dette er forberedelsen af den gamle installation af MongoDB, hvis data skal overføres, klar.

Migrering af MongoDB klyngen

Nu vil vi implementere en ny installation af MongoDB, som vil være i Kubernetes og bruges af applikationen i produktion.

: Jeg vil gerne understrege, at den samme version af MongoDB skal bruges som før. Ellers er der risiko for kompatibilitetsproblemer.

NB: Jeg vil gerne påpege, at den samme version af MongoDB skal bruges som før. Ellers er der risiko for kompatibilitetsproblemer.

Ligesom i det foregående afsnit (hvor vi simulerede en "gammel" installation af MongoDB) vil vi tage den nævnte Helm-chart (med kommandoen helm fetch) og konfigurere godkendelse samt andre parametre, hvis de bruges. Derudover vil vi rette filen init/on-start.sh, midlertidigt tilføje master-adressen på linje 165, som vi fik i det tidligere trin (eller som du allerede kender fra installationen af MongoDB på separate servere):

peers='mongo-old-mongodb-replicaset-0.mongo-old-mongodb-replicaset.mongo-old.svc.cluster.local:27017'

Vi er klar til at oprette en ny installation af MongoDB:

helm install . --name mongo-new --namespace mongo-new

Vent på, at alle pods starter (hvis der er meget data, kan dette tage timer):

Nu laver vi exec til den nye pod og ser en liste over databaser:

kubectl --namespace=mongo-new exec -ti mongo-new-mongodb-replicaset-0 mongo

To MongoDB-klynger er slået sammen til én, bestående af 6 noder.

På nuværende tidspunkt kan vi allerede skifte applikationen til den nye klynge, men der er stadig et par trin tilbage for at fuldføre migrationen.

Fra filen init/on-start.sh fjerner vi den tilføjede linje i den nye installation:

peers='mongo-old-mongodb-replicaset-0.mongo-old-mongodb-replicaset.mongo-old.svc.cluster.local:27017'

Lad os nu logge ind på den gamle master-klynge og "afsætte" den — så vil der blive udnævnt en ny master i klyngen. Log ind på pod med MongoDB-masteren:

kubectl --namespace=mongo-old exec -ti mongo-old-mongodb-replicaset-0 mongo
use admin
db.auth('mongo','password')

Herefter ændrer vi prioriteterne for noderne og skifter masteren:

cfg = rs.conf()
cfg.members[5].priority = 2
rs.reconfig(cfg)
rs.stepDown(120)

Den nuværende node er ikke længere master — der vil finde valg af ny sted. Da vi ændrede prioriteterne, vil den ønskede node blive master.

NB: Som standard har alle MongoDB-noder en prioritet på 1. Ovenfor hæver vi prioritetsniveauet til 2 for den ønskede node. På den måde bliver medlemmet af den nye klynge helt sikkert den overordnede master. Læs mere om, hvordan disse mekanismer fungerer i MongoDB, i dokumentationen.

Vi deaktiverer den gamle installation af MongoDB, hvorefter vi logger ind på masteren af den nye og fjerner de gamle noder:

rs.remove("mongo-old-mongodb-replicaset-0.mongo-old-mongodb-replicaset.mongo-old.svc.cluster.local:27017")
rs.remove("mongo-old-mongodb-replicaset-1.mongo-old-mongodb-replicaset.mongo-old.svc.cluster.local:27017")
rs.remove("mongo-old-mongodb-replicaset-2.mongo-old-mongodb-replicaset.mongo-old.svc.cluster.local:27017")

Herefter kan migrationen betragtes som afsluttet: vi har med succes skiftet fra den gamle MongoDB-klynge til den nye!

Resumé

Den beskrevne fremgangsmåde er velegnet til næsten alle situationer, hvor det er nødvendigt at overføre MongoDB eller blot flytte til en ny klynge.

Det vigtigste aspekt ved migrering er behovet for at videresende IP-adresserne fra de nye pods til serverne i den gamle MongoDB-installation, hvis den er uden for K8s, samt at navngive dem korrekt i DNS (eller /etc/hosts). I eksemplet var disse trin ikke nødvendige, da migreringen fandt sted mellem forskellige navneområder i den samme Kubernetes-klynge.