🥇Zökkenőmentes MongoDB a Kubernetes Migration

Ez a cikk folytatja a mi friss anyag a RabbitMQ migrációról és a MongoDB-nek szentelt. Mivel sok Kubernetes- és MongoDB-fürtöt karbantartunk, természetes igényhez jutottunk, hogy az adatokat egyik telepítésről a másikra migráljuk, és ezt leállás nélkül végezzük. A fő forgatókönyvek ugyanazok: a MongoDB áthelyezése egy virtuális/hardveres kiszolgálóról a Kubernetesre, vagy a MongoDB áthelyezése ugyanazon a Kubernetes-fürtön belül (egyik névtérből a másikba).

Receptünk azokra az esetekre szolgál, amikor van egy régi MongoDB-fürt (például 3 csomópontból, és már K8-ban vagy régebbi szervereken található), amellyel egy Kubernetesben tárolt alkalmazás fut:

Hogyan fogunk átvinni egy ilyen klasztert egy új produkcióba Kubernetesben?

elmélet

Az általános migrációs algoritmus hasonló a RabbitMQ esetében leírthoz.

Fontos megjegyezni, hogy az áthelyezéshez a MongoDB és a Kubernetes szervereknek ugyanazon a hálózaton kell lenniük. A MongoDB-fürtcsomópontok a régi kiszolgálók IP-címével (ahol a régi MongoDB-telepítések találhatók) és a K8-ban lévő MongoDB-vel rendelkező podok DNS-nevével kommunikálnak egymással. Ezért a hardveres szervereken (régi telepítéssel) útvonalakat kell továbbítania a podokhoz, majd be kell állítani őket egy Kubernetesben futó DNS-kiszolgáló használatára (vagy regisztrálnia kell a szükséges neveket a /etc/hosts, bár általában jobb elkerülni ezt a lehetőséget).

A következő lépés egy MongoDB-fürt létrehozása Kubernetes podokban. Esetünkben az adatbázis-klaszter 3 csomópontból áll, és mindegyik csomópont külön K8s podban található - számuk azonban eltérő lehet. A ConfigMap-ben meg kell adnia a régi telepítésből származó MongoDB master címét: akkor a K8s-ban podokban található MongoDB csomópontok azonnal elkezdik a szinkronizálást vele.

Miután az összes pod felállt, egy 6 csomópontból álló MongoDB-fürt jön létre:

Kérjük, vegye figyelembe, hogy a pod-ok felemelkedése sokáig tart, mivel minden egyes pod felváltva indul el, és az indításkor szinkronizálja a mester adatait.

Ezután átállíthatja az alkalmazást az új MongoDB-kiszolgálók használatára:

Már csak a régi csomópontok eltávolítása van hátra a MongoDB-fürtből, ami után az áthelyezés befejezettnek tekinthető:

A gyártás során gyakran használjuk ezt a sémát, és a könnyebb használhatóság érdekében a for modulon belül implementáltuk addon-operátor (mi nemrég jelentették be), amely lehetővé teszi a tipikus MongoDB konfigurációk elosztását számos fürt között. Terveink szerint hamarosan megjelentetjük moduljainkat, de egyelőre külön instrukciókat mutatunk be, amelyekkel kipróbálhatja a javasolt megoldást az addon-operátor használata nélkül.

Próbáljuk ki a gyakorlatban

Követelmények

Követelmények:

Kubernetes klaszter (a minikube is működni fog);
MongoDB-fürt (csupasz fémre telepíthető, és úgy készíthető, mint egy szokásos fürt a Kubernetesben a hivatalos Helm diagramról).

Az alábbi példában a régi MongoDB-fürt lesz elnevezve mongo-old és ugyanabba a Kubernetes-fürtbe telepítve, ahol később telepítjük az újat (mongo-new).

A régi fürt előkészítése

1. A leírt sémát működés közben bemutató példaként hozzunk létre egy „régi” (azaz áttelepítés alatt álló) MongoDB-fürtöt közvetlenül a Kubernetesben (a valóságban a K8s-on kívül külön szervereken is elhelyezhető). Ehhez töltse le a Helm diagramot:

helm fetch --untar stable/mongodb-replicaset

... és módosítsa egy kicsit az engedélyezés beállításával:

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

Szintén values.yaml konfigurálhatja a tanúsítványokat és még sok mást.

2. Telepítse a diagramot:

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

Ezt követően elindul a MongoDB „régi” teszttelepítése:

kubectl --namespace=mongo-old get pods

Menjünk be a podba a mesterével, és hozzunk létre egy 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ő hüvelyekbe menve rájöttem, hogy a mester az mongo-old-mongodb-replicaset-0. A probléma kényelmesebb megoldása érdekében azonban a Helm diagram telepítése után megjelenik egy parancs, hogyan lehet meghatározni MASTER_POD. Az én esetemben (azért 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

Ekkor már készen áll a régi MongoDB telepítés előkészítése, aminek az adatai átkerülnek.

MongoDB-fürt migrálása

Most helyezzük üzembe a MongoDB új telepítését, amely a Kubernetesben lesz, és az alkalmazás éles környezetben fog használni.

NB: Felhívjuk figyelmét, hogy a MongoDB ugyanazt a verzióját kell használni, mint korábban. Ellenkező esetben fennáll a kompatibilitási problémák veszélye.

Az előző részhez hasonlóan (ahol egy „régi” MongoDB telepítést szimuláltunk) vegyük a már említett Helm diagramot (a paranccsal helm fetch) és konfigurálja a jogosultságot, valamint egyéb paramétereket, ha van ilyen. Ezenkívül javítjuk a fájlt init/on-start.sh, ideiglenesen hozzáadva a 165. sorban az előző lépésben kapott (vagy a MongoDB egyes szerverekre történő telepítéséből ismert) főcímet:

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

Megvárjuk, amíg az összes pod elindul (ha sok az adat, akkor az indításuk órákig is eltarthat):

Most megtesszük exec az új podba, és nézze meg az adatbázisok listáját:

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

Két MongoDB-fürt egy 6 csomópontból áll össze.

Ezen a ponton átállíthatja az alkalmazást az új fürtre, de még néhány lépés van hátra az áttelepítés befejezéséhez.

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

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

Most menjünk a régi fürt mesterhez, és „döntsük meg” azt - akkor egy új mester lesz hozzárendelve a fürthöz. Bemegyünk a podba a MongoDB mesterrel:

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 megváltoztatjuk a mestereket:

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

A jelenlegi csomópont megszűnt mester lenni – új csomópont kerül kiválasztásra. Mivel megváltoztattuk a prioritásokat, a szükséges csomópont lesz a mester.

NB: Alapértelmezés szerint az összes MongoDB csomópont prioritása 1. Fent 2-re emeljük a számunkra szükséges csomópont prioritását. Így az új klaszter egy tagja mindenképpen általános mesterré válik. A MongoDB-ben ezeknek a mechanizmusoknak a működéséről bővebben itt olvashat dokumentáció.

Letiltjuk a régi MongoDB telepítést, majd menjünk az új varázslóhoz, é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")

Ezek után a migráció befejezettnek tekinthető: sikeresen váltottunk a régi MongoDB klaszterről az újra!

Eredményei

A leírt séma szinte minden olyan esetre alkalmas, amikor át kell költöztetni a MongoDB-t, vagy egyszerűen át kell lépnie egy új fürtbe.

Az átvitel során talán a fő árnyalat az, hogy az új podok IP-címeit továbbítani kell a régi MongoDB telepítés szervereire, ha az a K8s-on kívül található, és helyesen kell elnevezni őket a DNS-ben (vagy /etc/hosts). A példában ezekre a lépésekre nem volt szükség, mivel az áttelepítés ugyanazon Kubernetes-fürt különböző névterei között történt.