🥇Zökkenőmentes MongoDB migráció Kubernetesben

Ez a cikk folytatja legutóbbi anyagunkat a RabbitMQ-ról és a MongoDB-re vonatkozik. Mivel számos Kubernetes és MongoDB klasztert üzemeltetünk, természetes igényként merült fel az adatok migrálása egyik telepítéstől a másikig, mindezt leállás nélkül. Az alapvető forgatókönyvek változatlanok: MongoDB átköltöztetése virtuális/ fizikai szerverről Kubernetesbe, vagy a MongoDB áthelyezése ugyanazon Kubernetes klaszteren belül (egy névtérből a másikba).

A receptünk olyan esetekre készült, amikor egy régi MongoDB klaszter működik (például 3 csomópontból áll és vagy már K8s-en van, vagy régi szervereken), amelyhez egy Kubernetes-ben futó alkalmazás kapcsolódik:

Hogyan fogjuk átvinni ezt a klasztert egy új production környezetbe Kubernetes alatt?

Elmélet

A migráció általános algoritmusa hasonló a RabbitMQ helyzetében leírtakhoz.

Fontos megjegyezni, hogy a költözés lehetőségéhez szükséges, hogy a MongoDB és Kubernetes szerverek ugyanabban a hálózatban legyenek. A MongoDB klaszter csomópontjai az IP címeken fognak kommunikálni a régi szerverek között (ahol a régi MongoDB telepítések találhatók) és a K8s-ben lévő MongoDB pod-ok DNS nevein keresztül. Ezért a régi szervereken (régi telepítésekkel) szükséges beállítani az útvonalakat a pod-okhoz, majd konfigurálni őket, hogy használják a Kubernetes-ben futó DNS szervert (vagy pedig a szükséges neveket megadni a /etc/hosts, bár általánosan javasolt ilyen lehetőségeket elkerülni).

A következő lépés a MongoDB klaszter felemelése Kubernetes pod-okban. Ebben az esetben az adatbázis klaszter három csomópontból áll, és minden csomópont külön K8s pod-ban helyezkedik el — a számuk azonban változhat. A ConfigMap-ban meg kell adni a régi telepítésből származó MongoDB mester címét: ezután a K8s pod-ban lévő MongoDB csomópontok azonnal elkezdik a szinkronizálást vele.

Miután az összes pod felállt, létrejön egy 6 csomópontból álló MongoDB klaszter:

Vedd figyelembe, hogy a pod-ok lassan fognak elindulni, mivel minden pod egyesével indul el, és a rendszerindítás során adatait a mesterről szinkronizálja.

Ezután az alkalmazást átválthatjuk az új MongoDB szerverek használatára:

És csak annyit kell tennünk, hogy eltávolítjuk a régi csomópontokat a MongoDB klaszterből, így a költözés befejezettnek tekinthető:

Ezt a kibővített sémát gyakran használjuk production környezetben, és a használat megkönnyítése érdekében a addon-operator keretrendszerén belül megvalósítottuk (ezt az eszközt nemrégiben bejelentettük)), amely lehetővé teszi a MongoDB klasszikus konfigurációk elosztását több klaszteren. A moduljaink publikálását hamarosan tervezzük, addig is bemutatjuk azokat az egyes útmutatókat, melyek segítségével kipróbálhatja a javasolt megoldást anélkül, hogy az addon-operatorra lenne szüksége.

Próbáljuk ki a gyakorlatban.

Követelmények

Az alábbiak:

Kubernetes klaszter (a minikube is megfelelő);
A MongoDB klaszter (lehet, hogy bare metal környezetben is ki van építve, illetve hagyományos klaszter formájában is létrehozható Kubernetesben az hivatalos Helm-chartból).

Az alábbi példa segítségével a régi MongoDB klasztert fogjuk nevezni mongo-old és a Kubernetes klaszterben telepítjük, ahol a jövőben a új klasztert is telepítjük (mongo-new).

Régi klaszter előkészítése

1. A példa kedvéért, amely bemutatja a leírt sémát működés közben, létrehozunk egy 'régi' (azaz migrálásra váró) MongoDB klasztert közvetlenül Kubernetesben (a valóságban külön álló szervereken is futtatható). Ehhez letöltjük a Helm-chartot:

helm fetch --untar stable/mongodb-replicaset

… és kissé módosítjuk, beállítva az engedélyezést:

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

Ezen kívül a values.yaml is beállíthatók a tanúsítványok és sok más dolog.

2. Telepítjük a chartot:

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

Ezután elindul a teszt 'régi' MongoDB telepítése:

kubectl --namespace=mongo-old get pods

Bemenjünk a podba, amelynek a mestere, és létrehozzuk a tesztadatbázist:

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

Különböző podokba belépve kiderítettem, hogy a mester mongo-old-mongodb-replicaset-0. Azonban a probléma kényelmesebb megoldása érdekében a Helm-chart telepítése után kiadott parancs mutatja, hogyan lehet meghatározni a MASTER_POD. Az én esetemben (a mongo-old 3 csomópontból) így néz ki:

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

Ezzel elkészült a régi MongoDB telepítés előkészítése, amelynek adatai átkerülnek.

A MongoDB klaszter migrálása

Most telepítsük az új MongoDB példányt, amely a Kubernetesben lesz, és a termelésben használják az alkalmazások.

NB: Felhívom a figyelmet, hogy az előzőekhez képest ugyanazt a MongoDB verziót kell használni. Egyéb esetekben kompatibilitási problémák merülhetnek fel.

A korábbi szakaszhoz hasonlóan (ahol a 'régi' MongoDB telepítést szimuláltuk), vegyük azt a már említett Helm-chartot (parancsot követően helm fetch) és beállítjuk az azonosítást, valamint egyéb paramétereket, ha szükséges. Ezen kívül javítjuk a fájlt init/on-start.sh, átmenetileg hozzáadva a 165. sorba a mesterszerver címét, amelyet az előző lépésben kaptunk (vagy az Ön által ismert MongoDB telepítéséből származik különböző szervereken):

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

Készen állunk egy új MongoDB telepítés létrehozására:

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

Várjuk, hogy minden pod elinduljon (ha sok adat van, elindításuk órákig eltarthat):

Most létrehozunk exec új pod-ot és megnézzük az adatbázisok listáját:

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

Két MongoDB klaszter egyesült egy hat csomópontból álló klaszterré.

Jelenleg már át lehet kapcsolni az alkalmazást az új klaszterre, de a migraláshoz még néhány lépés hátravan.

A fájlból init/on-start.sh az új telepítésben eltávolítjuk az általunk hozzáadott sort:

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

Most lépjünk be a régi klaszter mesterébe és "döntsük le" őt – ekkor a klaszterben új mester kerül kijelölésre. Belépünk a MongoDB mester pod-jába:

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

Ezt követően megváltoztatjuk a csomópontok prioritásait és módosítjuk a mestert:

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

A jelenlegi csomópont megszűnt mester lenni – új választásokra kerül sor. Mivel megváltoztattuk a prioritásokat, a kívánt csomópont válik mesterré.

NB: Alapértelmezés szerint minden MongoDB csomópont prioritása 1. Fent emeljük 2-re a szükséges csomópont prioritását. Így biztosan a legújabb klaszter tagja válik közös mesteré. dokumentáció.

Kapcsoljuk ki a régi MongoDB telepítést, majd lépjünk be az új mesterbe, és töröljük a régi csomópontokat:

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")

Ezt követően a migrációt befejezettnek tekinthetjük: sikeresen átálltunk a régi MongoDB klaszterről az újra!

Összegzés

A leírt séma gyakorlatilag minden olyan esetre megfelelő, amikor MongoDB-t kell áthelyezni vagy egyszerűen új klaszterre kell költözni.

Valószínűleg a legfontosabb szempont a migráció során az új pod-ok IP-címeinek átkonfigurálása a régi MongoDB telepítés szerverein, ha az K8s-en kívül helyezkedik el, és azok helyes elnevezése a DNS-ben (vagy /etc/hosts). A példában ezek a lépések nem voltak szükségesek, mivel a migráció ugyanazon Kubernetes klaszter különböző névtartományaiban zajlott.