K8S మల్టీక్లస్టర్ జర్నీ

హే హబ్ర్!

మేము Exness ప్లాట్‌ఫారమ్ బృందానికి ప్రాతినిధ్యం వహిస్తాము. ఇంతకుముందు, మా సహోద్యోగులు ఇప్పటికే దీని గురించి ఒక కథనాన్ని రాశారు k8s కోసం ఉత్పత్తికి సిద్ధంగా ఉన్న చిత్రాలు. ఈ రోజు మేము కుబెర్నెట్‌లకు సేవలను తరలించిన మా అనుభవాన్ని పంచుకోవాలనుకుంటున్నాము.

ప్రారంభించడానికి, ఏమి చర్చించబడుతుందో బాగా అర్థం చేసుకోవడానికి మేము మీకు కొన్ని సంఖ్యలను అందిస్తున్నాము:

• మా డెవలప్‌మెంట్ డిపార్ట్‌మెంట్ 100+ మంది వ్యక్తులను కలిగి ఉంది, ఇందులో 10 కంటే ఎక్కువ విభిన్న బృందాలు స్వయం సమృద్ధి గల QA, DevOps మరియు స్క్రమ్ ప్రాసెస్‌లు ఉన్నాయి. డెవలప్‌మెంట్ స్టాక్ - పైథాన్, PHP, C++, జావా మరియు గోలాంగ్. 
• పరీక్ష మరియు ఉత్పత్తి పరిసరాల పరిమాణం ఒక్కొక్కటి 2000 కంటైనర్లు. వారు తమ స్వంత వర్చువలైజేషన్ మరియు VMware క్రింద Rancher v1.6ని అమలు చేస్తున్నారు. 

ప్రేరణ

వారు చెప్పినట్లు, ఏదీ శాశ్వతంగా ఉండదు మరియు రాంచర్ చాలా కాలం క్రితం వెర్షన్ 1.6 కోసం మద్దతు ముగింపును ప్రకటించారు. అవును, మూడు సంవత్సరాలకు పైగా మేము దానిని ఎలా సిద్ధం చేయాలో మరియు తలెత్తే సమస్యలను ఎలా పరిష్కరించాలో నేర్చుకున్నాము, అయితే ఎప్పటికీ సరిదిద్దబడని సమస్యలను మరింత తరచుగా ఎదుర్కొంటున్నాము. రాంచర్ 1.6 కూడా హక్కులను జారీ చేయడానికి ఓసిఫైడ్ సిస్టమ్‌ను కలిగి ఉంది, ఇక్కడ మీరు దాదాపు ప్రతిదీ లేదా ఏమీ చేయలేరు.

యాజమాన్య వర్చువలైజేషన్ డేటా నిల్వ మరియు దాని భద్రతపై ఎక్కువ నియంత్రణను అందించినప్పటికీ, సంస్థ యొక్క స్థిరమైన వృద్ధి, ప్రాజెక్ట్‌ల సంఖ్య మరియు వాటి అవసరాలను బట్టి అంగీకరించడం కష్టంగా ఉండే నిర్వహణ ఖర్చులను ఇది విధించింది.

మేము IaC ప్రమాణాలను అనుసరించాలనుకుంటున్నాము మరియు అవసరమైతే, ఏదైనా భౌగోళిక ప్రదేశంలో మరియు విక్రేత లాక్ లేకుండా త్వరగా సామర్థ్యాన్ని పొందాలనుకుంటున్నాము మరియు దానిని త్వరగా వదిలివేయగలము.

మొదటి దశలను

అన్నింటిలో మొదటిది, మేము ఆధునిక సాంకేతికతలు మరియు పరిష్కారాలపై ఆధారపడాలని కోరుకున్నాము, తద్వారా బృందాలు వేగవంతమైన అభివృద్ధి చక్రాన్ని కలిగి ఉంటాయి మరియు శక్తిని అందించే ప్లాట్‌ఫారమ్‌తో పరస్పర చర్య చేయడానికి కార్యాచరణ ఖర్చులను తగ్గించవచ్చు. 
 
అయితే, మా మనసులోకి వచ్చిన మొదటి విషయం కుబెర్నెటెస్, కానీ మేము సంతోషించలేదు మరియు ఇది సరైన ఎంపిక కాదా అని చూడటానికి కొంచెం పరిశోధన చేసాము. మేము ఓపెన్‌సోర్స్ పరిష్కారాలను మాత్రమే విశ్లేషించాము మరియు అన్యాయమైన యుద్ధంలో, కుబెర్నెట్స్ బేషరతుగా గెలిచారు.  

క్లస్టర్‌లను సృష్టించడానికి ఒక సాధనాన్ని ఎంచుకునే ప్రశ్న తదుపరిది. మేము అత్యంత ప్రజాదరణ పొందిన పరిష్కారాలను పోల్చాము: kops, kubespray, kubeadm.

ప్రారంభించడానికి, kubeadm అనేది ఒక రకమైన "సైకిల్" యొక్క ఆవిష్కర్త వలె కాకుండా చాలా సంక్లిష్టమైన మార్గంగా మాకు అనిపించింది మరియు కోప్స్‌కు తగినంత సౌలభ్యం లేదు.

మరియు విజేత:

మేము మా స్వంత వర్చువలైజేషన్ మరియు AWSతో ప్రయోగాలు చేయడం ప్రారంభించాము, మా మునుపటి రిసోర్స్ మేనేజ్‌మెంట్ ప్యాటర్న్‌కు సమానమైన దానిని పునఃసృష్టి చేయడానికి ప్రయత్నిస్తున్నాము, ఇక్కడ అందరూ ఒకే “క్లస్టర్”ని భాగస్వామ్యం చేసారు. మరియు ఇప్పుడు మేము మా మొదటి క్లస్టర్ 10 చిన్న వర్చువల్ మిషన్‌లను కలిగి ఉన్నాము, వీటిలో కొన్ని AWSలో ఉన్నాయి. మేము అక్కడికి జట్లను తరలించడానికి ప్రయత్నించడం ప్రారంభించాము, అంతా “మంచిది” అనిపించింది మరియు కథను ముగించవచ్చు, కానీ...

మొదటి సమస్యలు

Ansible అంటే kubespray నిర్మించబడింది, ఇది IaCని అనుసరించడానికి మిమ్మల్ని అనుమతించే సాధనం కాదు: నోడ్‌లను కమీషన్/డికమిషన్ చేసేటప్పుడు, నిరంతరం ఏదో తప్పు జరిగింది మరియు కొన్ని రకాల జోక్యం అవసరం మరియు వివిధ OSలను ఉపయోగిస్తున్నప్పుడు, ప్లేబుక్ భిన్నంగా ప్రవర్తిస్తుంది. . క్లస్టర్‌లోని జట్లు మరియు నోడ్‌ల సంఖ్య పెరిగేకొద్దీ, ప్లేబుక్ పూర్తి కావడానికి ఎక్కువ సమయం పడుతుందని మేము గమనించడం ప్రారంభించాము మరియు ఫలితంగా, మా రికార్డ్ 3,5 గంటలు, మీది ఏమిటి? 🙂

మరియు kubespray కేవలం Ansible లాగా ఉంది మరియు మొదటి చూపులో ప్రతిదీ స్పష్టంగా ఉంది, కానీ:

ప్రయాణం ప్రారంభంలో, AWS మరియు వర్చువలైజేషన్‌లో మాత్రమే సామర్థ్యాలను ప్రారంభించడం పని, కానీ తరచుగా జరిగే విధంగా, అవసరాలు మారాయి.
 


దీని దృష్ట్యా, క్లస్టర్‌లు చాలా రిమోట్‌గా ఉండి, వివిధ ప్రొవైడర్‌లచే నిర్వహించబడుతున్న సందర్భంలో - వనరులను ఒక ఆర్కెస్ట్రేషన్ సిస్టమ్‌లో కలపడం యొక్క మా పాత నమూనా తగినది కాదని స్పష్టమైంది. 

ఇంకా ఎక్కువ. అన్ని బృందాలు ఒకే క్లస్టర్‌లో పని చేస్తున్నప్పుడు, తప్పుగా ఇన్‌స్టాల్ చేయబడిన NodeSelectorsతో వివిధ సేవలు మరొక బృందం యొక్క "విదేశీ" హోస్ట్‌కి వెళ్లి అక్కడ వనరులను ఉపయోగించుకోవచ్చు మరియు టేన్ట్ సెట్ చేయబడితే, ఒకటి లేదా మరొక సేవ పనిచేయడం లేదని నిరంతరం అభ్యర్థనలు ఉన్నాయి, మానవ కారకం కారణంగా సరిగ్గా పంపిణీ చేయబడలేదు. మరొక సమస్య ఏమిటంటే, ఖర్చును లెక్కించడం, ప్రత్యేకించి నోడ్స్‌లో సేవలను పంపిణీ చేయడంలో ఉన్న సమస్యలను పరిగణనలోకి తీసుకోవడం.

ఉద్యోగులకు హక్కులను జారీ చేయడం ఒక ప్రత్యేక కథనం: ప్రతి బృందం క్లస్టర్ యొక్క "తల వద్ద" ఉండాలని మరియు దానిని పూర్తిగా నిర్వహించాలని కోరుకుంది, ఇది పూర్తిగా పతనానికి కారణమవుతుంది, ఎందుకంటే జట్లు ప్రాథమికంగా ఒకదానికొకటి స్వతంత్రంగా ఉంటాయి.

ఎలా?

పైన పేర్కొన్న వాటిని మరియు మరింత స్వతంత్రంగా ఉండాలనే జట్ల కోరికలను పరిగణనలోకి తీసుకుని, మేము ఒక సాధారణ ముగింపు చేసాము: ఒక జట్టు - ఒక క్లస్టర్. 

కాబట్టి మేము రెండవదాన్ని పొందాము:

ఆపై మూడవ క్లస్టర్: 

అప్పుడు మేము ఆలోచించడం ప్రారంభించాము: ఒక సంవత్సరంలో మా బృందాలు ఒకటి కంటే ఎక్కువ క్లస్టర్లను కలిగి ఉంటాయని చెప్పాలా? వివిధ భౌగోళిక ప్రాంతాలలో, ఉదాహరణకు, లేదా వివిధ ప్రొవైడర్ల నియంత్రణలో ఉందా? మరియు వాటిలో కొన్ని కొన్ని పరీక్షల కోసం తాత్కాలిక క్లస్టర్‌ను త్వరగా అమలు చేయగలుగుతాయి. 

పూర్తి కుబెర్నెట్స్ వస్తారు! ఇది ఒకరకమైన MultiKubernetes అని తేలింది. 

అదే సమయంలో, మనమందరం ఈ క్లస్టర్‌లన్నింటినీ ఏదో ఒకవిధంగా నిర్వహించాలి, వాటికి ప్రాప్యతను సులభంగా నిర్వహించగలగాలి, అలాగే కొత్త వాటిని సృష్టించడం మరియు మాన్యువల్ జోక్యం లేకుండా పాత వాటిని తొలగించడం.

కుబెర్నెటెస్ ప్రపంచంలో మా ప్రయాణం ప్రారంభం నుండి కొంత సమయం గడిచిపోయింది మరియు అందుబాటులో ఉన్న పరిష్కారాలను మళ్లీ పరిశీలించాలని మేము నిర్ణయించుకున్నాము. ఇది ఇప్పటికే మార్కెట్లో ఉందని తేలింది - రాంచర్ 2.2.

మా పరిశోధన యొక్క మొదటి దశలో, రాంచర్ ల్యాబ్స్ ఇప్పటికే వెర్షన్ 2 యొక్క మొదటి విడుదలను చేసింది, అయితే రెండు పారామీటర్‌లతో బాహ్య డిపెండెన్సీలు లేకుండా కంటైనర్‌ను ప్రారంభించడం ద్వారా లేదా అధికారిక HELM చార్ట్‌ని ఉపయోగించడం ద్వారా చాలా త్వరగా పెంచవచ్చు, అయితే ఇది క్రూడ్‌గా అనిపించింది. మాకు, మరియు ఈ నిర్ణయం అభివృద్ధి చేయబడుతుందా లేదా త్వరగా వదిలివేయబడుతుందా అనే దానిపై మేము ఆధారపడగలమో మాకు తెలియదు. UI లోనే క్లస్టర్ = క్లిక్‌ల నమూనా కూడా మాకు సరిపోలేదు మరియు మేము RKEతో ముడిపడి ఉండాలనుకోలేదు, ఎందుకంటే ఇది చాలా ఇరుకైన దృష్టి కేంద్రీకరించబడిన సాధనం. 

వెర్షన్ రాంచర్ 2.2 ఇప్పటికే మరింత పని చేయగల రూపాన్ని కలిగి ఉంది మరియు మునుపటి వాటితో పాటు, అనేక బాహ్య ప్రొవైడర్‌లతో ఏకీకరణ, హక్కులు మరియు kubeconfig ఫైల్‌ల పంపిణీ యొక్క ఒకే పాయింట్, kubectlని ప్రారంభించడం వంటి అనేక ఆసక్తికరమైన ఫీచర్‌లను కలిగి ఉంది. UIలో మీ హక్కులతో కూడిన చిత్రం, సమూహ నేమ్‌స్పేసులు లేదా ప్రాజెక్ట్‌లు. 

Rancher 2 చుట్టూ ఇప్పటికే ఒక కమ్యూనిటీ కూడా ఏర్పడింది మరియు దానిని నిర్వహించడానికి HashiCorp Terraform అనే ప్రొవైడర్ సృష్టించబడింది, ఇది మాకు అన్నింటినీ కలిపి ఉంచడంలో సహాయపడింది.

ఏమి జరిగినది

ఫలితంగా, మేము అన్ని ఇతర క్లస్టర్‌లకు ప్రాప్యత చేయగల ఒక చిన్న క్లస్టర్‌తో రాంచర్‌తో ముగించాము, అలాగే దానికి కనెక్ట్ చేయబడిన అనేక క్లస్టర్‌లు, వీటిలో దేనికైనా యాక్సెస్‌ను ldap డైరెక్టరీకి వినియోగదారుని జోడించడం ద్వారా మంజూరు చేయవచ్చు. అది ఎక్కడ ఉంది మరియు ఏ ప్రొవైడర్ యొక్క వనరులను ఉపయోగిస్తుంది.

gitlab-ci మరియు Terraform ఉపయోగించి, క్లౌడ్ ప్రొవైడర్లు లేదా మా స్వంత మౌలిక సదుపాయాలలో ఏదైనా కాన్ఫిగరేషన్ యొక్క క్లస్టర్‌ను సృష్టించడానికి మరియు వాటిని రాంచర్‌కి కనెక్ట్ చేయడానికి మిమ్మల్ని అనుమతించే సిస్టమ్ సృష్టించబడింది. ఇవన్నీ IaC శైలిలో చేయబడతాయి, ఇక్కడ ప్రతి క్లస్టర్ రిపోజిటరీ ద్వారా వివరించబడుతుంది మరియు దాని స్థితి వెర్షన్ చేయబడింది. అదే సమయంలో, చాలా మాడ్యూల్‌లు బాహ్య రిపోజిటరీల నుండి కనెక్ట్ చేయబడ్డాయి, తద్వారా వేరియబుల్‌లను పాస్ చేయడం లేదా ఉదాహరణల కోసం మీ అనుకూల కాన్ఫిగరేషన్‌ను వివరించడం మాత్రమే మిగిలి ఉంటుంది, ఇది కోడ్ పునరావృత శాతాన్ని తగ్గించడంలో సహాయపడుతుంది.

వాస్తవానికి, మా ప్రయాణం ముగియలేదు మరియు ఏదైనా క్లస్టర్‌ల లాగ్‌లు మరియు మెట్రిక్‌లతో ఒకే పాయింట్ వర్క్, సర్వీస్ మెష్, మల్టీక్లస్టర్‌లో లోడ్‌లను నిర్వహించడానికి జిటాప్‌లు మరియు మరెన్నో వంటి అనేక ఆసక్తికరమైన పనులు ఇంకా ముందుకు ఉన్నాయి. మా అనుభవం మీకు ఆసక్తికరంగా ఉంటుందని మేము ఆశిస్తున్నాము! 

కథనాన్ని ఎ. ఆంటిపోవ్, ఎ. గనుష్, ప్లాట్‌ఫారమ్ ఇంజనీర్లు రాశారు. 

మూలం: www.habr.com