కుబెర్నెటీస్‌కు మొంగోడిబి యొక్క అతుకులు లేని వలస

కుబెర్నెటీస్‌కు మొంగోడిబి యొక్క అతుకులు లేని వలస

ఈ వ్యాసం మా కొనసాగుతుంది ఇటీవలి పదార్థం RabbitMQ మైగ్రేషన్ గురించి మరియు MongoDBకి అంకితం చేయబడింది. మేము అనేక కుబెర్నెట్‌లు మరియు మొంగోడిబి క్లస్టర్‌లను నిర్వహిస్తున్నందున, డేటాను ఒక ఇన్‌స్టాలేషన్ నుండి మరొక ఇన్‌స్టాలేషన్‌కి తరలించడం మరియు పనిని నిలిపివేసే సమయం లేకుండా చేయడం సహజమైన అవసరానికి మేము వచ్చాము. ప్రధాన దృశ్యాలు ఒకటే: MongoDBని వర్చువల్/హార్డ్‌వేర్ సర్వర్ నుండి Kubernetesకి తరలించడం లేదా MongoDBని అదే Kubernetes క్లస్టర్‌లో (ఒక నేమ్‌స్పేస్ నుండి మరొక నేమ్‌స్పేస్‌కి) తరలించడం.

మా రెసిపీ పాత MongoDB క్లస్టర్ (ఉదాహరణకు, 3 నోడ్‌లు మరియు ఇప్పటికే K8sలో లేదా పాత సర్వర్‌లలో ఉంది) ఉన్న సందర్భాల కోసం ఉద్దేశించబడింది, దానితో Kubernetesలో హోస్ట్ చేయబడిన అప్లికేషన్ అమలులో ఉంది:

కుబెర్నెటీస్‌కు మొంగోడిబి యొక్క అతుకులు లేని వలస

మేము అటువంటి క్లస్టర్‌ను కుబెర్నెట్స్‌లోని కొత్త ఉత్పత్తికి ఎలా బదిలీ చేస్తాము?

సిద్ధాంతం

సాధారణ మైగ్రేషన్ అల్గోరిథం RabbitMQతో పరిస్థితిలో వివరించిన మాదిరిగానే ఉంటుంది.

మొంగోడిబి మరియు కుబెర్నెటెస్ సర్వర్‌లు ఒకే నెట్‌వర్క్‌లో ఉండటం ఈ చర్యకు అవసరమని గమనించడం ముఖ్యం. MongoDB క్లస్టర్ నోడ్‌లు పాత సర్వర్‌ల IPని (పాత MongoDB ఇన్‌స్టాలేషన్‌లు ఉన్నచోట) ఉపయోగించి మరియు K8sలో MongoDBతో పాడ్‌ల DNS పేర్లతో పరస్పరం సంభాషించుకుంటాయి. అందువల్ల, హార్డ్‌వేర్ సర్వర్‌లలో (పాత ఇన్‌స్టాలేషన్‌లతో) మీరు పాడ్‌లకు రూట్‌లను ఫార్వార్డ్ చేయాలి, ఆపై వాటిని కుబెర్నెట్స్‌లో నడుస్తున్న DNS సర్వర్‌ని ఉపయోగించడానికి కాన్ఫిగర్ చేయాలి (లేదా అవసరమైన పేర్లను నమోదు చేయండి /etc/hosts, అయితే సాధారణంగా ఈ అవకాశాన్ని నివారించడం మంచిది).

కుబెర్నెటెస్ పాడ్స్‌లో మొంగోడిబి క్లస్టర్‌ను పెంచడం తదుపరి దశ. మా విషయంలో, డేటాబేస్ క్లస్టర్ 3 నోడ్‌లను కలిగి ఉంటుంది మరియు ప్రతి నోడ్ ప్రత్యేక K8s పాడ్‌లో ఉంటుంది - అయినప్పటికీ, వాటి సంఖ్య భిన్నంగా ఉండవచ్చు. కాన్ఫిగ్‌మ్యాప్‌లో, మీరు పాత ఇన్‌స్టాలేషన్ నుండి MongoDB మాస్టర్ యొక్క చిరునామాను పేర్కొనాలి: K8sలోని పాడ్‌లలో ఉన్న MongoDB నోడ్‌లు వెంటనే దానితో సమకాలీకరించడం ప్రారంభిస్తాయి.

అన్ని పాడ్‌లు పెరిగిన తర్వాత, 6 నోడ్‌ల మొంగోడిబి క్లస్టర్ ఏర్పడుతుంది:

కుబెర్నెటీస్‌కు మొంగోడిబి యొక్క అతుకులు లేని వలస

పాడ్‌లు పెరగడానికి చాలా సమయం పడుతుందని దయచేసి గమనించండి, ఎందుకంటే ప్రతి పాడ్ క్రమంగా ప్రారంభించబడుతుంది మరియు లాంచ్ సమయంలో అది మాస్టర్ నుండి డేటాను సింక్రొనైజ్ చేస్తుంది.

మీరు కొత్త MongoDB సర్వర్‌లను ఉపయోగించడానికి మీ అప్లికేషన్‌ను మార్చవచ్చు:

కుబెర్నెటీస్‌కు మొంగోడిబి యొక్క అతుకులు లేని వలస

మొంగోడిబి క్లస్టర్ నుండి పాత నోడ్‌లను తీసివేయడం మాత్రమే మిగిలి ఉంది, ఆ తర్వాత తరలింపు పూర్తయినట్లు పరిగణించవచ్చు:

కుబెర్నెటీస్‌కు మొంగోడిబి యొక్క అతుకులు లేని వలస

మేము తరచుగా ఈ పథకాన్ని ఉత్పత్తిలో ఉపయోగిస్తాము మరియు వాడుకలో సౌలభ్యం కోసం, మేము దీన్ని మాడ్యూల్‌లో అమలు చేస్తాము addon-operator (మేము ఇటీవల ప్రకటించారు), ఇది సాధారణ MongoDB కాన్ఫిగరేషన్‌లను అనేక క్లస్టర్‌లలో పంపిణీ చేయడానికి అనుమతిస్తుంది. మేము మా మాడ్యూల్‌లను త్వరలో ప్రచురించాలని ప్లాన్ చేస్తున్నాము, కానీ ప్రస్తుతానికి మేము ప్రత్యేక సూచనలను అందిస్తున్నాము, దానితో మీరు యాడ్ఆన్-ఆపరేటర్‌ని ఉపయోగించకుండా చర్యలో ప్రతిపాదిత పరిష్కారాన్ని ప్రయత్నించవచ్చు.

ఆచరణలో ప్రయత్నిద్దాం

అవసరాలు

అవసరాలు:

  • కుబెర్నెటెస్ క్లస్టర్ (మినీక్యూబ్ కూడా పని చేస్తుంది);
  • MongoDB క్లస్టర్ (బేర్ మెటల్‌పై అమర్చవచ్చు మరియు అధికారిక హెల్మ్ చార్ట్ నుండి కుబెర్నెట్స్‌లో సాధారణ క్లస్టర్‌గా తయారు చేయవచ్చు).

దిగువ ఉదాహరణలో, పాత MongoDB క్లస్టర్ పేరు పెట్టబడుతుంది mongo-old మరియు అదే కుబెర్నెట్స్ క్లస్టర్‌లో ఇన్‌స్టాల్ చేయబడుతుంది, ఇక్కడ మేము కొత్తదాన్ని ఇన్‌స్టాల్ చేస్తాము (mongo-new).

పాత క్లస్టర్‌ను సిద్ధం చేస్తోంది

1. వివరించిన స్కీమ్‌ను చర్యలో ప్రదర్శించే ఉదాహరణ కోసం, "పాత" (అనగా, వలసలకు లోబడి) మొంగోడిబి క్లస్టర్‌ను నేరుగా కుబెర్నెట్స్‌లో సృష్టిద్దాం (వాస్తవానికి, ఇది K8s వెలుపల ఉన్న ప్రత్యేక సర్వర్‌లలో ఉంటుంది). దీన్ని చేయడానికి, హెల్మ్ చార్ట్‌ని డౌన్‌లోడ్ చేయండి:

helm fetch --untar stable/mongodb-replicaset

... మరియు అధికారాన్ని సెటప్ చేయడం ద్వారా దీన్ని కొద్దిగా సవరించండి:

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

కూడా values.yaml మీరు ధృవపత్రాలు మరియు మరిన్నింటిని కాన్ఫిగర్ చేయవచ్చు.

2. చార్ట్‌ను ఇన్‌స్టాల్ చేయండి:

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

దీని తరువాత, MongoDB యొక్క పరీక్ష "పాత" ఇన్‌స్టాలేషన్ ప్రారంభించబడుతుంది:

kubectl --namespace=mongo-old get pods

కుబెర్నెటీస్‌కు మొంగోడిబి యొక్క అతుకులు లేని వలస

దాని మాస్టర్‌తో పాడ్‌లోకి వెళ్లి పరీక్ష డేటాబేస్‌ను క్రియేట్ చేద్దాం:

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

కుబెర్నెటీస్‌కు మొంగోడిబి యొక్క అతుకులు లేని వలస

వివిధ పాడ్‌లలోకి వెళ్లి, మాస్టర్ అని నేను కనుగొన్నాను mongo-old-mongodb-replicaset-0. అయితే, ఈ సమస్యకు మరింత అనుకూలమైన పరిష్కారం కోసం, హెల్మ్ చార్ట్‌ను ఇన్‌స్టాల్ చేసిన తర్వాత, ఎలా నిర్ణయించాలో ఆదేశం ప్రదర్శించబడుతుంది. MASTER_POD. నా విషయంలో (కోసం mongo-old 3 నోడ్స్) ఇది ఇలా కనిపిస్తుంది:

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

ఈ సమయంలో, పాత MongoDB ఇన్‌స్టాలేషన్ యొక్క తయారీ, దాని డేటా బదిలీ చేయబడుతుంది, సిద్ధంగా ఉంది.

మొంగోడిబి క్లస్టర్‌ని మైగ్రేట్ చేయండి

ఇప్పుడు మొంగోడిబి యొక్క కొత్త ఇన్‌స్టాలేషన్‌ని అమలు చేద్దాం, ఇది కుబెర్నెట్స్‌లో ఉంది మరియు ఉత్పత్తిలో అప్లికేషన్ ద్వారా ఉపయోగించబడుతుంది.

NB: దయచేసి మొంగోడిబి యొక్క అదే వెర్షన్ తప్పనిసరిగా మునుపటిలా ఉపయోగించబడుతుందని గమనించండి. లేకపోతే, అనుకూలత సమస్యలు వచ్చే ప్రమాదం ఉంది.

మునుపటి విభాగంతో సారూప్యతతో (ఇక్కడ మనం “పాత” మొంగోడిబి ఇన్‌స్టాలేషన్‌ను అనుకరించాము), ఇప్పటికే పేర్కొన్న హెల్మ్ చార్ట్ (ఆదేశంతో) తీసుకుందాం. helm fetch) మరియు అధికారాన్ని కాన్ఫిగర్ చేయండి, అలాగే ఇతర పారామితులను ఉపయోగించినట్లయితే. అదనంగా, మేము ఫైల్ను సరిచేస్తాము init/on-start.sh, మునుపటి దశలో పొందిన (లేదా వ్యక్తిగత సర్వర్‌లలో మొంగోడిబిని ఇన్‌స్టాల్ చేయడం ద్వారా మీకు తెలిసిన) మాస్టర్ చిరునామాను లైన్ 165లో తాత్కాలికంగా జోడించడం:

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

మేము కొత్త MongoDB ఇన్‌స్టాలేషన్‌ని సృష్టించడానికి సిద్ధంగా ఉన్నాము:

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

అన్ని పాడ్‌లు ప్రారంభమయ్యే వరకు మేము వేచి ఉన్నాము (చాలా డేటా ఉంటే, వాటి ప్రయోగానికి గంటలు పట్టవచ్చు):

కుబెర్నెటీస్‌కు మొంగోడిబి యొక్క అతుకులు లేని వలస

ఇప్పుడు చేద్దాం exec కొత్త పాడ్‌కి మరియు డేటాబేస్‌ల జాబితాను చూడండి:

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

కుబెర్నెటీస్‌కు మొంగోడిబి యొక్క అతుకులు లేని వలస

రెండు మొంగోడిబి క్లస్టర్‌లు 6 నోడ్‌లను కలిగి ఉన్న ఒకటిగా మిళితం చేయబడ్డాయి.

ఈ సమయంలో, మీరు అప్లికేషన్‌ను కొత్త క్లస్టర్‌కి మార్చవచ్చు, అయితే మైగ్రేషన్‌ను పూర్తి చేయడానికి కొన్ని దశలు మిగిలి ఉన్నాయి.

ఫైల్ నుండి init/on-start.sh కొత్త ఇన్‌స్టాలేషన్‌లో మేము జోడించిన పంక్తిని తీసివేస్తాము:

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

ఇప్పుడు పాత క్లస్టర్ మాస్టర్ వద్దకు వెళ్లి దానిని "పారద్రోలండి" - అప్పుడు క్లస్టర్‌కు కొత్త మాస్టర్ కేటాయించబడతారు. మేము MongoDB మాస్టర్‌తో పాడ్‌లోకి వెళ్తాము:

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

ఆ తరువాత, మేము నోడ్‌ల ప్రాధాన్యతలను మారుస్తాము మరియు మాస్టర్‌లను మారుస్తాము:

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

ప్రస్తుత నోడ్ మాస్టర్‌గా నిలిచిపోయింది - కొత్త నోడ్ ఎన్నుకోబడుతుంది. మేము ప్రాధాన్యతలను మార్చినందున, మనకు అవసరమైన నోడ్ మాస్టర్ అవుతుంది.

NB: డిఫాల్ట్‌గా, అన్ని మొంగోడిబి నోడ్‌లకు 1 ప్రాధాన్యత ఉంటుంది. పైన, మనకు అవసరమైన నోడ్ ప్రాధాన్యతను 2కి పెంచుతాము. అందువలన, కొత్త క్లస్టర్ సభ్యుడు ఖచ్చితంగా సాధారణ మాస్టర్ అవుతాడు. ఈ మెకానిజమ్‌లు మొంగోడిబిలో ఎలా పనిచేస్తాయనే దాని గురించి మీరు మరింత చదువుకోవచ్చు డాక్యుమెంటేషన్.

పాత MongoDB ఇన్‌స్టాలేషన్‌ని డిసేబుల్ చేద్దాం, ఆపై కొత్త విజార్డ్‌కి వెళ్లి పాత నోడ్‌లను తొలగించండి:

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

దీని తర్వాత, మైగ్రేషన్ పూర్తయినట్లు పరిగణించవచ్చు: మేము పాత MongoDB క్లస్టర్ నుండి కొత్తదానికి విజయవంతంగా మారాము!

ఫలితాలు

మీరు మొంగోడిబిని తరలించాల్సిన అవసరం వచ్చినప్పుడు లేదా కొత్త క్లస్టర్‌కు తరలించాల్సిన అవసరం వచ్చినప్పుడు వివరించిన పథకం దాదాపు అన్ని సందర్భాల్లో అనుకూలంగా ఉంటుంది.

బదిలీ చేసేటప్పుడు బహుశా ప్రధాన సూక్ష్మభేదం ఏమిటంటే, కొత్త పాడ్‌ల యొక్క IP చిరునామాలను పాత MongoDB ఇన్‌స్టాలేషన్ యొక్క సర్వర్‌లకు ఫార్వార్డ్ చేయడం, అది K8s వెలుపల ఉన్నట్లయితే మరియు వాటిని DNSలో సరిగ్గా పేరు పెట్టడం (లేదా /etc/hosts) ఉదాహరణలో, ఈ దశలు అవసరం లేదు, ఎందుకంటే ఒకే కుబెర్నెటెస్ క్లస్టర్ యొక్క వివిధ నేమ్‌స్పేస్‌ల మధ్య వలసలు జరిగాయి.

PS

మా బ్లాగులో కూడా చదవండి:

మూలం: www.habr.com

DDoS రక్షణ, VPS VDS సర్వర్‌లతో సైట్‌ల కోసం నమ్మకమైన హోస్టింగ్‌ను కొనుగోలు చేయండి 🔥 DDoS రక్షణతో కూడిన నమ్మకమైన వెబ్‌సైట్ హోస్టింగ్, VPS VDS సర్వర్‌లను కొనండి | ProHoster