నివేదిక కుబెర్నెట్స్‌లో ఆపరేటర్‌ను అభివృద్ధి చేయడం, దాని నిర్మాణం మరియు ప్రాథమిక నిర్వహణ సూత్రాల రూపకల్పన వంటి ఆచరణాత్మక సమస్యలకు అంకితం చేయబడింది.
నివేదిక యొక్క మొదటి భాగంలో మేము పరిశీలిస్తాము:
- కుబెర్నెట్స్‌లో ఆపరేటర్ అంటే ఏమిటి మరియు అది ఎందుకు అవసరం;
- సంక్లిష్ట వ్యవస్థల నిర్వహణను ఆపరేటర్ ఎలా సులభతరం చేస్తాడు;
- ఆపరేటర్ ఏమి చేయగలడు మరియు చేయలేడు.
తరువాత, ఆపరేటర్ యొక్క అంతర్గత నిర్మాణాన్ని చర్చించడానికి వెళ్దాం. ఆపరేటర్ యొక్క నిర్మాణం మరియు ఆపరేషన్ దశల వారీగా చూద్దాం. దానిని వివరంగా పరిశీలిద్దాం:
- ఆపరేటర్ మరియు కుబెర్నెట్స్ మధ్య పరస్పర చర్య;
- ఆపరేటర్ ఏ విధులను తీసుకుంటాడు మరియు అది కుబెర్నెట్‌లకు ఏ విధులను అప్పగిస్తుంది.
కుబెర్నెట్స్‌లో షార్డ్‌లు మరియు డేటాబేస్ ప్రతిరూపాలను నిర్వహించడాన్ని చూద్దాం.
తరువాత, మేము డేటా నిల్వ సమస్యలను చర్చిస్తాము:
- ఆపరేటర్ దృష్టికోణం నుండి పెర్సిస్టెంట్ స్టోరేజ్‌తో ఎలా పని చేయాలి;
- స్థానిక నిల్వను ఉపయోగించడం వల్ల కలిగే నష్టాలు.
నివేదిక యొక్క చివరి భాగంలో, మేము అప్లికేషన్ యొక్క ఆచరణాత్మక ఉదాహరణలను పరిశీలిస్తాము Amazon లేదా Google క్లౌడ్ సర్వీస్ నుండి. నివేదిక ClickHouse కోసం ఆపరేటర్ యొక్క అభివృద్ధి మరియు నిర్వహణ అనుభవం యొక్క ఉదాహరణపై ఆధారపడి ఉంటుంది.
వీడియోలు:
నా పేరు వ్లాడిస్లావ్ క్లిమెంకో. ఈ రోజు నేను ఆపరేటర్‌ను అభివృద్ధి చేయడంలో మరియు ఆపరేట్ చేయడంలో మా అనుభవం గురించి మాట్లాడాలనుకుంటున్నాను మరియు ఇది డేటాబేస్ క్లస్టర్‌లను నిర్వహించడానికి ప్రత్యేకమైన ఆపరేటర్. ఉదాహరణకి క్లిక్‌హౌస్ క్లస్టర్‌ని నిర్వహించడానికి.
ఆపరేటర్ మరియు క్లిక్‌హౌస్ గురించి మాట్లాడే అవకాశం మనకు ఎందుకు ఉంది?
- మేము క్లిక్‌హౌస్‌కు మద్దతునిస్తాము మరియు అభివృద్ధి చేస్తాము.
- ప్రస్తుతానికి, మేము క్లిక్‌హౌస్ అభివృద్ధికి నెమ్మదిగా మా సహకారాన్ని అందించడానికి ప్రయత్నిస్తున్నాము. క్లిక్‌హౌస్‌కి చేసిన మార్పుల పరిమాణంలో మేము Yandex తర్వాత రెండవ స్థానంలో ఉన్నాము.
- మేము ClickHouse పర్యావరణ వ్యవస్థ కోసం అదనపు ప్రాజెక్ట్‌లను రూపొందించడానికి ప్రయత్నిస్తున్నాము.
ఈ ప్రాజెక్ట్‌లలో ఒకదాని గురించి నేను మీకు చెప్పాలనుకుంటున్నాను. ఇది Kubernetes కోసం క్లిక్‌హౌస్-ఆపరేటర్ గురించి.
నా నివేదికలో నేను రెండు అంశాలపై టచ్ చేయాలనుకుంటున్నాను:
- మా ClickHouse డేటాబేస్ మేనేజ్‌మెంట్ ఆపరేటర్ Kubernetesలో ఎలా పని చేస్తుంది అనేది మొదటి అంశం.
- రెండవ అంశం ఏమిటంటే, ఏదైనా ఆపరేటర్ ఎలా పని చేస్తుంది, అంటే అది కుబెర్నెట్స్‌తో ఎలా వ్యవహరిస్తుంది.
అయితే, ఈ రెండు ప్రశ్నలు నా నివేదిక అంతటా కలుస్తాయి.
నేను చెప్పాలనుకున్నది వినడానికి ఎవరు ఆసక్తి చూపుతారు?
- ఆపరేటర్లను నిర్వహించే వారికి ఇది చాలా ఆసక్తిని కలిగిస్తుంది.
- లేదా అంతర్గతంగా ఇది ఎలా పని చేస్తుందో, కుబెర్నెట్స్‌తో ఆపరేటర్ ఎలా వ్యవహరిస్తాడు మరియు ఎలాంటి ఆపదలు కనిపించవచ్చో అర్థం చేసుకోవడానికి వారి స్వంతం చేసుకోవాలనుకునే వారికి.
ఈ రోజు మనం ఏమి చర్చిస్తామో బాగా అర్థం చేసుకోవడానికి, కుబెర్నెట్స్ ఎలా పనిచేస్తుందో తెలుసుకోవడం మరియు కొన్ని ప్రాథమిక క్లౌడ్ శిక్షణ పొందడం మంచిది.
క్లిక్‌హౌస్ అంటే ఏమిటి? ఇది విశ్లేషణాత్మక ప్రశ్నల ఆన్‌లైన్ ప్రాసెసింగ్ కోసం నిర్దిష్ట లక్షణాలతో కూడిన కాలమ్ డేటాబేస్. మరియు ఇది పూర్తిగా ఓపెన్ సోర్స్.
మరియు మనం రెండు విషయాలు మాత్రమే తెలుసుకోవడం ముఖ్యం. ఇది డేటాబేస్ అని మీరు తెలుసుకోవాలి, కాబట్టి నేను మీకు చెప్పేది దాదాపు ఏ డేటాబేస్‌కైనా వర్తిస్తుంది. మరియు క్లిక్‌హౌస్ DBMS స్కేల్‌లు చాలా బాగా ఉండడం వల్ల దాదాపు లీనియర్ స్కేలబిలిటీని ఇస్తుంది. అందువల్ల, క్లస్టర్ స్థితి క్లిక్‌హౌస్‌కు సహజ స్థితి. మరియు మేము Kubernetes లో ClickHouse క్లస్టర్‌ను ఎలా అందించాలో చర్చించడానికి చాలా ఆసక్తిగా ఉన్నాము.
అతను అక్కడ ఎందుకు అవసరం? దీన్ని మనమే ఎందుకు ఆపరేట్ చేయలేకపోతున్నాం? మరియు సమాధానాలు పాక్షికంగా సాంకేతికంగా మరియు పాక్షికంగా సంస్థాగతంగా ఉంటాయి.
- ఆచరణలో, పెద్ద కంపెనీలలో దాదాపు అన్ని భాగాలు ఇప్పటికే కుబెర్నెట్స్‌లో ఉన్న పరిస్థితిని మేము ఎక్కువగా ఎదుర్కొంటున్నాము. డేటాబేస్‌లు బయట ఉంటాయి.
- మరియు ప్రశ్న ఎక్కువగా అడగబడుతోంది: "ఇది లోపల ఉంచవచ్చా?" అందువల్ల, పెద్ద కంపెనీలు తమ డేటా గిడ్డంగులను త్వరగా నిర్వహించగలిగేలా నిర్వహణ యొక్క గరిష్ట ఏకీకరణను సాధించడానికి ప్రయత్నిస్తున్నాయి.
- మరియు ఒక కొత్త స్థలంలో అదే విషయాన్ని పునరావృతం చేయడానికి మీకు గరిష్ట అవకాశం అవసరమైతే ఇది ప్రత్యేకంగా సహాయపడుతుంది, అంటే గరిష్ట పోర్టబిలిటీ.
ఇది ఎంత సులభం లేదా కష్టం? ఇది, వాస్తవానికి, చేతితో చేయవచ్చు. కానీ ఇది అంత సులభం కాదు, ఎందుకంటే మేము కుబెర్నెట్‌లను నిర్వహించడంలో అదనపు సంక్లిష్టతను కలిగి ఉన్నాము, కానీ అదే సమయంలో ClickHouse యొక్క ప్రత్యేకతలు సూపర్మోస్ చేయబడ్డాయి. మరియు అటువంటి సమీకరణ ఫలితాలు.
మరియు అన్నీ కలిసి ఇది చాలా పెద్ద సాంకేతిక పరిజ్ఞానాన్ని అందిస్తుంది, ఇది నిర్వహించడం చాలా కష్టమవుతుంది, ఎందుకంటే Kubernetes దాని స్వంత రోజువారీ సమస్యలను ఆపరేషన్‌కు తీసుకువస్తుంది మరియు ClickHouse దాని స్వంత సమస్యలను రోజువారీ కార్యకలాపాలకు తీసుకువస్తుంది. ప్రత్యేకించి మనకు అనేక క్లిక్‌హౌస్‌లు ఉంటే, వాటితో మనం నిరంతరం ఏదైనా చేయవలసి ఉంటుంది.
డైనమిక్ కాన్ఫిగరేషన్‌తో, DevOpsలో స్థిరమైన లోడ్‌ను సృష్టించే సమస్యలను ClickHouse చాలా పెద్ద సంఖ్యలో కలిగి ఉంది:
- మనం క్లిక్‌హౌస్‌లో ఏదైనా మార్చాలనుకున్నప్పుడు, ఉదాహరణకు, ప్రతిరూపం లేదా షార్డ్‌ని జోడించండి, ఆపై మనం కాన్ఫిగరేషన్‌ను నిర్వహించాలి.
- ఆపై డేటా స్కీమాను మార్చండి, ఎందుకంటే ClickHouseకి నిర్దిష్ట షేడింగ్ పద్ధతి ఉంది. అక్కడ మీరు డేటా రేఖాచిత్రాన్ని వేయాలి, కాన్ఫిగరేషన్లను వేయాలి.
- మీరు పర్యవేక్షణను సెటప్ చేయాలి.
- కొత్త శకలాల కోసం, కొత్త ప్రతిరూపాల కోసం లాగ్‌లను సేకరిస్తోంది.
- పునరుద్ధరణకు శ్రద్ధ వహించండి.
- మరియు పునఃప్రారంభించండి.
ఇవి రొటీన్ టాస్క్‌లు, వీటిని నేను సులభంగా ఉపయోగించాలనుకుంటున్నాను.
కుబెర్నెట్స్ స్వయంగా ఆపరేషన్‌లో బాగా సహాయపడుతుంది, కానీ ప్రాథమిక సిస్టమ్ విషయాలపై.
ఇలాంటి వాటిని సులభతరం చేయడంలో మరియు స్వయంచాలకంగా చేయడంలో కుబెర్నెటెస్ మంచివాడు:
- రికవరీ
- పునఃప్రారంభించండి.
- నిల్వ వ్యవస్థ నిర్వహణ.
అది మంచిది, ఇది సరైన దిశ, కానీ అతను డేటాబేస్ క్లస్టర్‌ను ఎలా ఆపరేట్ చేయాలనే దాని గురించి పూర్తిగా క్లూలెస్‌గా ఉన్నాడు.
మాకు మరిన్ని కావాలి, మొత్తం డేటాబేస్ Kubernetesలో పని చేయాలని మేము కోరుకుంటున్నాము.
నేను మీరు నొక్కే ఒక పెద్ద మ్యాజిక్ రెడ్ బటన్‌ను పొందాలనుకుంటున్నాను మరియు పరిష్కరించాల్సిన రోజువారీ పనులతో కూడిన క్లస్టర్ దాని మొత్తం జీవిత చక్రంలో అమలు చేయబడి, నిర్వహించబడుతుంది. కుబెర్నెట్స్‌లోని క్లిక్‌హౌస్ క్లస్టర్.
మరియు మేము పనిని సులభతరం చేయడానికి సహాయపడే పరిష్కారాన్ని రూపొందించడానికి ప్రయత్నించాము. ఇది ఆల్టినిటీ నుండి కుబెర్నెట్స్ కోసం క్లిక్‌హౌస్-ఆపరేటర్.
ఆపరేటర్ అనేది ఒక ప్రోగ్రామ్, దీని ప్రధాన పని ఇతర ప్రోగ్రామ్‌లను నిర్వహించడం, అంటే ఇది మేనేజర్.
మరియు ఇది ప్రవర్తన యొక్క నమూనాలను కలిగి ఉంటుంది. మీరు సబ్జెక్ట్ ఏరియా గురించి క్రోడీకరించిన ఈ జ్ఞానాన్ని కాల్ చేయవచ్చు.
మరియు అతని ప్రధాన పని DevOps యొక్క జీవితాన్ని సులభతరం చేయడం మరియు మైక్రోమేనేజ్‌మెంట్‌ను తగ్గించడం, తద్వారా అతను (DevOps) ఇప్పటికే ఉన్నత స్థాయి పరంగా ఆలోచిస్తాడు, అనగా, అతను (DevOps) మైక్రోమేనేజ్‌మెంట్‌లో పాల్గొనడు, తద్వారా అతను కాన్ఫిగర్ చేయడు. అన్ని వివరాలు మానవీయంగా.
మరియు కేవలం ఆపరేటర్ మైక్రోటాస్క్‌లతో వ్యవహరించే మరియు DevOpsకి సహాయపడే రోబోటిక్ అసిస్టెంట్.
మీకు ఆపరేటర్ ఎందుకు అవసరం? అతను ముఖ్యంగా రెండు రంగాలలో బాగా పని చేస్తాడు:
- ClickHouseతో వ్యవహరించే నిపుణుడికి తగినంత అనుభవం లేనప్పటికీ, ఇప్పటికే ClickHouseని ఆపరేట్ చేయవలసి వచ్చినప్పుడు, ఆపరేటర్ ఆపరేషన్‌ను సులభతరం చేస్తుంది మరియు ఇది ఎలా పని చేస్తుందనే దాని గురించి చాలా వివరంగా చెప్పకుండా, క్లిష్టమైన కాన్ఫిగరేషన్‌తో క్లిక్‌హౌస్ క్లస్టర్‌ను ఆపరేట్ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది. లోపల. మీరు అతనికి ఉన్నత-స్థాయి టాస్క్‌లు ఇవ్వండి మరియు అది పని చేస్తుంది.
- మరియు పెద్ద సంఖ్యలో సాధారణ పనులను ఆటోమేట్ చేయడానికి అవసరమైనప్పుడు ఇది ఉత్తమంగా పనిచేసే రెండవ పని. సిస్టమ్ నిర్వాహకుల నుండి మైక్రోటాస్క్‌లను తొలగిస్తుంది.
తమ ప్రయాణాన్ని ప్రారంభించే వారికి లేదా చాలా ఆటోమేషన్ చేయాల్సిన వారికి ఇది చాలా అవసరం.
ఇతర సిస్టమ్‌ల నుండి ఆపరేటర్-ఆధారిత విధానం ఎలా భిన్నంగా ఉంటుంది? హెల్మ్ ఉంది. ఇది ClickHouseని ఇన్‌స్టాల్ చేయడంలో కూడా సహాయపడుతుంది; మీరు హెల్మ్ చార్ట్‌లను గీయవచ్చు, ఇది మొత్తం ClickHouse క్లస్టర్‌ను కూడా ఇన్‌స్టాల్ చేస్తుంది. ఆపరేటర్ మరియు అదే మధ్య తేడా ఏమిటి, ఉదాహరణకు, హెల్మ్?
ప్రధాన ప్రాథమిక వ్యత్యాసం ఏమిటంటే, హెల్మ్ ప్యాకేజీ నిర్వహణ మరియు ఆపరేటర్ ఒక అడుగు ముందుకు వేస్తాడు. ఇది మొత్తం జీవిత చక్రానికి మద్దతు. ఇది ఇన్‌స్టాలేషన్ మాత్రమే కాదు, ఇవి స్కేలింగ్, షార్డింగ్, అంటే జీవిత చక్రంలో చేయవలసిన ప్రతిదీ (అవసరమైతే, ఆపై తొలగింపు కూడా) కలిగి ఉన్న రోజువారీ పనులు - ఇవన్నీ ఆపరేటర్ ద్వారా నిర్ణయించబడతాయి. ఇది మొత్తం సాఫ్ట్‌వేర్ జీవితచక్రాన్ని ఆటోమేట్ చేయడానికి మరియు నిర్వహించడానికి ప్రయత్నిస్తుంది. అందించిన ఇతర పరిష్కారాల నుండి ఇది దాని ప్రాథమిక వ్యత్యాసం.
అది పరిచయ భాగం, ముందుకు వెళ్దాం.
మేము మా ఆపరేటర్‌ను ఎలా నిర్మిస్తాము? క్లిక్‌హౌస్ క్లస్టర్‌ను ఒకే వనరుగా నిర్వహించడానికి మేము సమస్యను చేరుకోవడానికి ప్రయత్నిస్తున్నాము.
ఇక్కడ మనకు చిత్రం యొక్క ఎడమ వైపున ఇన్‌పుట్ డేటా ఉంది. ఇది క్లస్టర్ స్పెసిఫికేషన్‌తో కూడిన YAML, ఇది kubectl ద్వారా క్లాసిక్ పద్ధతిలో Kubernetesకి పంపబడుతుంది. అక్కడ మా ఆపరేటర్ దాన్ని ఎత్తుకుని తన మ్యాజిక్ చేస్తాడు. మరియు అవుట్పుట్ వద్ద మేము క్రింది పథకాన్ని పొందుతాము. ఇది కుబెర్నెట్స్‌లోని క్లిక్‌హౌస్ అమలు.
ఆపై ఆపరేటర్ ఎలా సరిగ్గా పనిచేస్తుందో, ఏ సాధారణ పనులను పరిష్కరించవచ్చో మేము నెమ్మదిగా పరిశీలిస్తాము. మాకు పరిమిత సమయం ఉన్నందున మేము సాధారణ పనులను మాత్రమే పరిశీలిస్తాము. మరియు ఆపరేటర్ నిర్ణయించగల ప్రతిదీ చర్చించబడదు.
అభ్యాసం నుండి ప్రారంభిద్దాం. మా ప్రాజెక్ట్ పూర్తిగా ఓపెన్ సోర్స్, కనుక ఇది GitHubలో ఎలా పనిచేస్తుందో మీరు చూడవచ్చు. మరియు మీరు దీన్ని ప్రారంభించాలనుకుంటే, మీరు క్విక్ స్టార్ట్ గైడ్‌తో ప్రారంభించవచ్చు.
మీరు వివరంగా అర్థం చేసుకోవాలనుకుంటే, మేము డాక్యుమెంటేషన్‌ను ఎక్కువ లేదా తక్కువ మంచి రూపంలో నిర్వహించడానికి ప్రయత్నిస్తాము.
ఆచరణాత్మక సమస్యతో ప్రారంభిద్దాం. మనమందరం ప్రారంభించాలనుకుంటున్న మొదటి పని, మొదటి ఉదాహరణను ఎలాగైనా అమలు చేయడం. ఆపరేటర్‌ని ఉపయోగించి క్లిక్‌హౌస్‌ను ఎలా ప్రారంభించగలను, అది ఎలా పనిచేస్తుందో నాకు నిజంగా తెలియకపోయినా? మేం మేనిఫెస్టో రాస్తున్నాం, ఎందుకంటే... k8sతో అన్ని కమ్యూనికేషన్లు మానిఫెస్ట్‌ల ద్వారా కమ్యూనికేషన్.
ఇది చాలా క్లిష్టమైన మేనిఫెస్టో. మేము ఎరుపు రంగులో ఏది హైలైట్ చేసాము, దానిపై దృష్టి పెట్టాలి. డెమో అనే క్లస్టర్‌ని సృష్టించమని మేము ఆపరేటర్‌ని అడుగుతాము.
ఇవి ప్రస్తుతానికి ప్రాథమిక ఉదాహరణలు. నిల్వ ఇంకా వివరించబడలేదు, అయితే మేము కొంత సమయం తరువాత నిల్వకు తిరిగి వస్తాము. ప్రస్తుతానికి, మేము క్లస్టర్ అభివృద్ధి యొక్క గతిశీలతను గమనిస్తాము.
మేం ఈ మేనిఫెస్టో రూపొందించాం. మేము దానిని మా ఆపరేటర్‌కు అందిస్తాము. అతను పనిచేశాడు, అతను మాయాజాలం చేశాడు.
మేము కన్సోల్ వైపు చూస్తాము. మూడు భాగాలు ఆసక్తిని కలిగి ఉన్నాయి: ఒక పాడ్, రెండు సేవలు మరియు స్టేట్‌ఫుల్‌సెట్.
ఆపరేటర్ పని చేసారు మరియు అతను సరిగ్గా ఏమి సృష్టించాడో మనం చూడవచ్చు.
అతను ఇలాంటివి సృష్టిస్తాడు. ప్రతి ప్రతిరూపానికి స్టేట్‌ఫుల్‌సెట్, పాడ్, కాన్ఫిగ్‌మ్యాప్, మొత్తం క్లస్టర్ కోసం కాన్ఫిగ్‌మ్యాప్ ఉన్నాయి. క్లస్టర్‌లోకి ప్రవేశ కేంద్రాలుగా సేవలు అవసరం.
సేవలు సెంట్రల్ లోడ్ బ్యాలెన్సర్ సర్వీస్ మరియు ప్రతి ప్రతిరూపానికి, ప్రతి షార్డ్ కోసం కూడా ఉపయోగించవచ్చు.
మా ప్రాథమిక క్లస్టర్ ఇలా కనిపిస్తుంది. ఇది ఒకే నోడ్ నుండి.
మరింత ముందుకు వెళ్లి విషయాలను క్లిష్టతరం చేద్దాం. మేము క్లస్టర్‌ను ముక్కలు చేయాలి.
మా పనులు పెరుగుతున్నాయి, డైనమిక్స్ ప్రారంభమవుతాయి. మేము ఒక ముక్కను జోడించాలనుకుంటున్నాము. మేము అభివృద్ధిని అనుసరిస్తాము. మేము మా స్పెసిఫికేషన్‌ను మారుస్తున్నాము. మేము రెండు ముక్కలు కావాలని సూచిస్తాము.
సిస్టమ్ యొక్క పెరుగుదలతో డైనమిక్‌గా అభివృద్ధి చెందే ఫైల్ ఇదే. నిల్వ సంఖ్య, నిల్వ మరింత చర్చించబడుతుంది, ఇది ప్రత్యేక అంశం.
మేము YAML ఆపరేటర్‌కు ఫీడ్ చేస్తాము మరియు ఏమి జరుగుతుందో చూద్దాం.
ఆపరేటర్ ఆలోచించి, కింది అంశాలను రూపొందించారు. మాకు ఇప్పటికే రెండు పాడ్‌లు, మూడు సేవలు మరియు అకస్మాత్తుగా 2 స్టేట్‌ఫుల్‌సెట్‌లు ఉన్నాయి. ఎందుకు 2 స్టేట్‌ఫుల్‌సెట్‌లు?
రేఖాచిత్రంలో ఇది ఇలా ఉంది - ఇది మా ప్రారంభ స్థితి, మనకు ఒక పాడ్ ఉన్నప్పుడు.
ఇది ఇలా మారింది. ఇప్పటివరకు ప్రతిదీ సులభం, ఇది నకిలీ చేయబడింది.
మరి రెండు స్టేట్‌ఫుల్‌సెట్‌లు ఎందుకు అయ్యాయి? కుబెర్నెట్స్‌లో పాడ్‌లు ఎలా నిర్వహించబడుతున్నాయి అనే ప్రశ్నను ఇక్కడ మనం డైగ్రెస్ చేసి చర్చించాలి.
టెంప్లేట్ నుండి పాడ్‌ల సెట్‌ను సృష్టించడానికి మిమ్మల్ని అనుమతించే స్టేట్‌ఫుల్‌సెట్ అనే ఆబ్జెక్ట్ ఉంది. ఇక్కడ కీలకమైన అంశం మూస. మరియు మీరు ఒక స్టేట్‌ఫుల్‌సెట్‌లో ఒక టెంప్లేట్‌ని ఉపయోగించి అనేక పాడ్‌లను ప్రారంభించవచ్చు. మరియు ఇక్కడ ముఖ్య పదబంధం "ఒక టెంప్లేట్ కోసం చాలా పాడ్‌లు."
మరియు మొత్తం క్లస్టర్‌ను ఒక స్టేట్‌ఫుల్‌సెట్‌గా ప్యాక్ చేయడానికి గొప్ప టెంప్టేషన్ ఉంది. ఇది పని చేస్తుంది, దానితో సమస్య లేదు. కానీ ఒక హెచ్చరిక ఉంది. మేము ఒక వైవిధ్యమైన క్లస్టర్‌ను సమీకరించాలనుకుంటే, అంటే, క్లిక్‌హౌస్ యొక్క అనేక వెర్షన్‌ల నుండి, అప్పుడు ప్రశ్నలు తలెత్తుతాయి. అవును, స్టేట్‌ఫుల్‌సెట్ రోలింగ్ అప్‌డేట్ చేయగలదు మరియు అక్కడ మీరు కొత్త వెర్షన్‌ను రూపొందించవచ్చు, మీరు ఒకే సమయంలో చాలా నోడ్‌ల కంటే ఎక్కువ ప్రయత్నించాల్సిన అవసరం లేదని వివరించండి.
కానీ మేము టాస్క్‌ను ఎక్స్‌ట్రాపోలేట్ చేసి, మేము పూర్తిగా భిన్నమైన క్లస్టర్‌ని తయారు చేయాలనుకుంటున్నాము మరియు రోలింగ్ అప్‌డేట్‌ని ఉపయోగించి పాత వెర్షన్ నుండి కొత్తదానికి మార్చకూడదనుకుంటే, మేము రెండు పరంగా భిన్నమైన క్లస్టర్‌ను సృష్టించాలనుకుంటున్నాము. ClickHouse యొక్క విభిన్న సంస్కరణలు మరియు విభిన్న నిల్వ పరంగా. ఉదాహరణకు, కొన్ని ప్రతిరూపాలను ప్రత్యేక డిస్క్‌లలో, నెమ్మదిగా ఉన్న వాటిపై, సాధారణంగా, పూర్తిగా భిన్నమైన క్లస్టర్‌ని నిర్మించాలని మేము కోరుకుంటున్నాము. మరియు స్టేట్‌ఫుల్‌సెట్ ఒక టెంప్లేట్ నుండి ప్రామాణికమైన పరిష్కారాన్ని చేస్తుంది కాబట్టి, దీన్ని చేయడానికి మార్గం లేదు.
కాస్త ఆలోచించిన తర్వాత ఈ విధంగా చేద్దామని నిర్ణయించుకున్నారు. మేము ప్రతి ప్రతిరూపాన్ని దాని స్వంత స్టేట్‌ఫుల్‌సెట్‌లో కలిగి ఉన్నాము. ఈ పరిష్కారానికి కొన్ని లోపాలు ఉన్నాయి, కానీ ఆచరణలో ఇది పూర్తిగా ఆపరేటర్చే కప్పబడి ఉంటుంది. మరియు ప్రయోజనాలు చాలా ఉన్నాయి. మనకు కావలసిన ఖచ్చితమైన క్లస్టర్‌ను మనం నిర్మించగలము, ఉదాహరణకు, పూర్తిగా భిన్నమైనది. అందువల్ల, మనకు ఒక ప్రతిరూపంతో రెండు ముక్కలు ఉన్న క్లస్టర్‌లో, మనకు 2 స్టేట్‌ఫుల్‌సెట్‌లు మరియు 2 పాడ్‌లు ఉంటాయి, ఎందుకంటే మేము ఒక భిన్నమైన క్లస్టర్‌ను నిర్మించడానికి పైన పేర్కొన్న కారణాల కోసం ఈ విధానాన్ని ఎంచుకున్నాము.
ఆచరణాత్మక సమస్యలకు తిరిగి వెళ్దాం. మా క్లస్టర్‌లో మనం వినియోగదారులను కాన్ఫిగర్ చేయాలి, అనగా. మీరు Kubernetes లో ClickHouse యొక్క కొంత కాన్ఫిగరేషన్ చేయాలి. దీని కోసం ఆపరేటర్ అన్ని అవకాశాలను అందిస్తుంది.
మనకు కావలసినది నేరుగా YAMLలో వ్రాయవచ్చు. అన్ని కాన్ఫిగరేషన్ ఎంపికలు ఈ YAML నుండి నేరుగా క్లిక్‌హౌస్ కాన్ఫిగర్‌లలోకి మ్యాప్ చేయబడతాయి, అవి క్లస్టర్ అంతటా పంపిణీ చేయబడతాయి.
మీరు దీన్ని ఇలా వ్రాయవచ్చు. ఇది ఉదాహరణకు. పాస్వర్డ్ను ఎన్క్రిప్ట్ చేయవచ్చు. ఖచ్చితంగా అన్ని ClickHouse కాన్ఫిగరేషన్ ఎంపికలకు మద్దతు ఉంది. ఇక్కడ ఒక ఉదాహరణ మాత్రమే ఉంది.
క్లస్టర్ కాన్ఫిగరేషన్ కాన్ఫిగ్ మ్యాప్‌గా పంపిణీ చేయబడింది. ఆచరణలో, కాన్ఫిగమ్యాప్ నవీకరణ తక్షణమే జరగదు, కనుక క్లస్టర్ పెద్దగా ఉంటే, ఆకృతీకరణను నెట్టడానికి కొంత సమయం పడుతుంది. కానీ ఇవన్నీ ఉపయోగించడానికి చాలా సౌకర్యవంతంగా ఉంటాయి.
పనిని క్లిష్టతరం చేద్దాం. క్లస్టర్ అభివృద్ధి చెందుతోంది. మేము డేటాను పునరావృతం చేయాలనుకుంటున్నాము. అంటే, మనకు ఇప్పటికే రెండు ముక్కలు ఉన్నాయి, ఒక్కొక్కటి ఒక్కో ప్రతిరూపం మరియు వినియోగదారులు కాన్ఫిగర్ చేయబడ్డారు. మేము పెరుగుతున్నాము మరియు ప్రతిరూపం చేయాలనుకుంటున్నాము.
ప్రతిరూపణ కోసం మనకు ఏమి కావాలి?
మాకు ZooKeeper కావాలి. క్లిక్‌హౌస్‌లో, జూకీపర్‌ని ఉపయోగించి ప్రతిరూపణ నిర్మించబడింది. ZooKeeper అవసరం కాబట్టి వివిధ క్లిక్‌హౌస్ ప్రతిరూపాలు ఏ క్లిక్‌హౌస్‌లో ఏ డేటా బ్లాక్‌లు ఉన్నాయో ఏకాభిప్రాయాన్ని కలిగి ఉంటాయి.
ZooKeeperని ఎవరైనా ఉపయోగించవచ్చు. ఎంటర్‌ప్రైజ్‌కు బాహ్య జూకీపర్ ఉంటే, దానిని ఉపయోగించవచ్చు. కాకపోతే, మీరు దీన్ని మా రిపోజిటరీ నుండి ఇన్‌స్టాల్ చేయవచ్చు. ఈ మొత్తం విషయాన్ని సులభతరం చేసే ఇన్‌స్టాలర్ ఉంది.
మరియు మొత్తం సిస్టమ్ యొక్క పరస్పర రేఖాచిత్రం ఇలా మారుతుంది. మేము కుబెర్నెట్‌లను వేదికగా కలిగి ఉన్నాము. ఇది ClickHouse ఆపరేటర్‌ని అమలు చేస్తుంది. నేను ఇక్కడ జూకీపర్‌ని చిత్రీకరించాను. మరియు ఆపరేటర్ ClickHouse మరియు ZooKeeper రెండింటితో పరస్పర చర్య చేస్తారు. అంటే, పరస్పర ఫలితాలు.
మరియు K8sలో డేటాను విజయవంతంగా పునరావృతం చేయడానికి క్లిక్‌హౌస్‌కి ఇవన్నీ అవసరం.
ప్రతిరూపణ కోసం మానిఫెస్ట్ ఎలా ఉంటుందో ఇప్పుడు టాస్క్‌ని చూద్దాం.
మేము మా మానిఫెస్ట్‌కు రెండు విభాగాలను జోడిస్తున్నాము. మొదటిది జూకీపర్‌ని ఎక్కడ పొందాలి, ఇది కుబెర్నెట్స్ లోపల లేదా బాహ్యంగా ఉండవచ్చు. ఇది కేవలం వివరణ మాత్రమే. మరియు మేము ప్రతిరూపాలను ఆర్డర్ చేస్తాము. ఆ. మాకు రెండు ప్రతిరూపాలు కావాలి. మొత్తంగా, అవుట్పుట్ వద్ద మనకు 4 పాడ్‌లు ఉండాలి. మేము నిల్వ గురించి గుర్తుంచుకుంటాము, అది కొంచెం తర్వాత తిరిగి వస్తుంది. నిల్వ అనేది ఒక ప్రత్యేక కథ.
ఇది ఇలా ఉంది.
ఇది ఇలా అవుతుంది. ప్రతిరూపాలు జోడించబడ్డాయి. 4వది సరిపోలేదు, అక్కడ చాలా మంది ఉండవచ్చని మేము నమ్ముతున్నాము. మరియు ZooKeeper వైపు జోడించబడింది. పథకాలు మరింత క్లిష్టంగా మారుతున్నాయి.
మరియు తదుపరి పనిని జోడించడానికి ఇది సమయం. మేము పెర్సిస్టెంట్ స్టోరేజ్‌ని జోడిస్తాము.
శాశ్వత నిల్వ కోసం మేము వివిధ ఎంపికలను కలిగి ఉన్నాము.
మేము క్లౌడ్ ప్రొవైడర్‌లో నడుస్తున్నట్లయితే, ఉదాహరణకు, అమెజాన్, గూగుల్‌ని ఉపయోగిస్తుంటే, క్లౌడ్ స్టోరేజ్‌ని ఉపయోగించడానికి గొప్ప టెంప్టేషన్ ఉంది. ఇది చాలా సౌకర్యవంతంగా ఉంటుంది, మంచిది.
మరియు రెండవ ఎంపిక ఉంది. ఇది ప్రతి నోడ్‌లో స్థానిక డిస్క్‌లను కలిగి ఉన్నప్పుడు స్థానిక నిల్వ కోసం. ఈ ఎంపికను అమలు చేయడం చాలా కష్టం, కానీ అదే సమయంలో ఇది మరింత ఉత్పాదకతను కలిగి ఉంటుంది.
క్లౌడ్ స్టోరేజీకి సంబంధించి మన దగ్గర ఏమి ఉందో చూద్దాం.
ప్రయోజనాలు ఉన్నాయి. ఇది కాన్ఫిగర్ చేయడం చాలా సులభం. మేము క్లౌడ్ ప్రొవైడర్ నుండి ఆర్డర్ చేస్తాము, దయచేసి అటువంటి మరియు అటువంటి తరగతికి చెందిన అటువంటి మరియు అటువంటి సామర్థ్యం యొక్క నిల్వను మాకు అందించండి. తరగతులు ప్రొవైడర్లచే స్వతంత్రంగా షెడ్యూల్ చేయబడతాయి.
మరియు ఒక లోపం ఉంది. కొంతమందికి, ఇది క్లిష్టమైన లోపం. వాస్తవానికి, కొన్ని పనితీరు సమస్యలు ఉంటాయి. ఇది ఉపయోగించడానికి చాలా సౌకర్యవంతంగా ఉంటుంది మరియు నమ్మదగినది, కానీ కొన్ని సంభావ్య పనితీరు లోపాలు ఉన్నాయి.
మరియు ఎందుకంటే ClickHouse ఉత్పాదకతపై ప్రత్యేకంగా దృష్టి సారిస్తుంది, అది చేయగలిగిన ప్రతిదాన్ని బయటకు తీస్తుందని కూడా చెప్పవచ్చు, అందుకే చాలా మంది క్లయింట్లు గరిష్ట ఉత్పాదకతను తగ్గించడానికి ప్రయత్నిస్తారు.
మరియు దాని నుండి ఎక్కువ ప్రయోజనం పొందడానికి, మాకు స్థానిక నిల్వ అవసరం.
Kubernetes లో స్థానిక నిల్వను ఉపయోగించడం కోసం Kubernetes మూడు సారాంశాలను అందిస్తుంది. ఇది:
- ఖాళీ డైర్
- హోస్ట్‌పాత్.
- స్థానిక
అవి ఎలా విభిన్నంగా ఉన్నాయో మరియు అవి ఎలా సారూప్యంగా ఉన్నాయో చూద్దాం.
ముందుగా, మూడు విధానాలలో మనకు నిల్వ ఉంది - ఇవి ఒకే భౌతిక k8s నోడ్‌లో ఉన్న స్థానిక డిస్క్‌లు. కానీ వారికి కొన్ని తేడాలు ఉన్నాయి.
సరళమైన దానితో ప్రారంభిద్దాం, అనగా ఖాళీడిర్. ఆచరణలో ఇది ఏమిటి? మా స్పెసిఫికేషన్‌లో, స్థానిక డిస్క్‌లోని ఫోల్డర్‌కు యాక్సెస్‌ను అందించమని మేము కంటైనర్‌లీకరణ వ్యవస్థను (చాలా తరచుగా డాకర్) అడుగుతాము.
ఆచరణలో, డాకర్ దాని స్వంత మార్గాల్లో ఎక్కడో తాత్కాలిక ఫోల్డర్‌ను సృష్టిస్తుంది మరియు దానిని లాంగ్ హ్యాష్ అని పిలుస్తుంది. మరియు దీన్ని యాక్సెస్ చేయడానికి ఇంటర్‌ఫేస్‌ను అందిస్తుంది.
పనితీరు వారీగా ఇది ఎలా పని చేస్తుంది? ఇది స్థానిక డిస్క్ వేగంతో పని చేస్తుంది, అనగా. ఇది మీ స్క్రూకు పూర్తి యాక్సెస్.
కానీ ఈ సందర్భంలో దాని లోపం ఉంది. ఈ విషయంలో పట్టుదల చాలా సందేహాస్పదంగా ఉంది. మొదటిసారి డాకర్ కంటైనర్‌లతో కదులుతున్నప్పుడు, పెర్సిస్టెంట్ పోతుంది. Kubernetes కొన్ని కారణాల వల్ల ఈ పాడ్‌ని మరొక డిస్క్‌కి తరలించాలనుకుంటే, డేటా పోతుంది.
ఈ విధానం పరీక్షలకు మంచిది, ఎందుకంటే ఇది ఇప్పటికే సాధారణ వేగాన్ని చూపుతుంది, కానీ తీవ్రమైనదానికి ఈ ఎంపిక తగినది కాదు.
కాబట్టి రెండవ విధానం ఉంది. ఇది హోస్ట్‌పాత్. మీరు మునుపటి స్లయిడ్ మరియు దీనిని చూస్తే, మీరు ఒకే ఒక తేడాను చూడగలరు. మా ఫోల్డర్ డాకర్ నుండి నేరుగా కుబెర్నెట్స్ నోడ్‌కి తరలించబడింది. ఇది ఇక్కడ కొంచెం సరళమైనది. మేము మా డేటాను నిల్వ చేయాలనుకుంటున్న స్థానిక ఫైల్ సిస్టమ్‌లోని మార్గాన్ని నేరుగా నిర్దేశిస్తాము.
ఈ పద్ధతి ప్రయోజనాలు ఉన్నాయి. ఇది ఇప్పటికే నిజమైన పెర్సిస్టెంట్ మరియు క్లాసిక్ ఒకటి. మేము డిస్క్‌లో ఏదో ఒక చిరునామాలో డేటాను రికార్డ్ చేస్తాము.
ప్రతికూలతలు కూడా ఉన్నాయి. ఇది నిర్వహణ యొక్క సంక్లిష్టత. మా కుబెర్నెట్‌లు పాడ్‌ను మరొక భౌతిక నోడ్‌కి తరలించాలనుకోవచ్చు. మరియు ఇక్కడే DevOps అమలులోకి వస్తుంది. మీరు ఈ మార్గాల్లో ఏదైనా మౌంట్ చేసిన నోడ్‌లకు మాత్రమే ఈ పాడ్‌లు తరలించబడతాయని మరియు ఒకేసారి ఒకటి కంటే ఎక్కువ నోడ్‌లు ఉండవని అతను మొత్తం సిస్టమ్‌కు సరిగ్గా వివరించాలి. ఇది చాలా కష్టం.
ప్రత్యేకించి ఈ ప్రయోజనాల కోసం, ఈ సంక్లిష్టతను దాచడానికి మేము మా ఆపరేటర్‌లో టెంప్లేట్‌లను తయారు చేసాము. మరియు మీరు ఇలా చెప్పవచ్చు: "నేను ప్రతి ఫిజికల్ నోడ్‌కి మరియు అలాంటి మార్గంలో క్లిక్‌హౌస్ యొక్క ఒక ఉదాహరణను కలిగి ఉండాలనుకుంటున్నాను."
కానీ ఈ అవసరం మనకు మాత్రమే అవసరం లేదు, కాబట్టి కుబెర్నెట్స్ నుండి వచ్చిన పెద్దమనుషులు కూడా ప్రజలు భౌతిక డిస్క్‌లను యాక్సెస్ చేయాలనుకుంటున్నారని అర్థం చేసుకున్నారు, కాబట్టి వారు మూడవ పొరను అందిస్తారు.
దాన్ని లోకల్ అంటారు. మునుపటి స్లయిడ్ నుండి ఆచరణాత్మకంగా తేడా లేదు. మేము ఈ పాడ్‌లను నోడ్ నుండి నోడ్‌కు బదిలీ చేయలేమని మాన్యువల్‌గా ధృవీకరించాల్సిన అవసరం ఉంది, ఎందుకంటే అవి స్థానిక ఫిజికల్ డిస్క్‌కి ఏదో ఒక మార్గంలో జతచేయబడాలి, కానీ ఇప్పుడు ఈ జ్ఞానం అంతా కుబెర్నెట్స్‌లోనే కప్పబడి ఉంది. మరియు ఇది కాన్ఫిగర్ చేయడం చాలా సులభం అవుతుంది.
మన ఆచరణాత్మక సమస్యకు తిరిగి వద్దాం. YAML టెంప్లేట్‌కి తిరిగి వెళ్దాం. ఇక్కడ మనకు నిజమైన నిల్వ ఉంది. మేము దాని వద్దకు తిరిగి వచ్చాము. మేము k8sలో వలె క్లాసిక్ VolumeClaim టెంప్లేట్‌ని సెట్ చేసాము. మరియు మనకు ఎలాంటి నిల్వ కావాలో వివరిస్తాము.
దీని తర్వాత, k8s నిల్వను అభ్యర్థిస్తుంది. స్టేట్‌ఫుల్‌సెట్‌లో మాకు కేటాయిస్తుంది. మరియు చివరికి అది ClickHouse పారవేయడం వద్ద ఉంటుంది.
మాకు ఈ పథకం ఉంది. మా పెర్సిస్టెంట్ స్టోరేజ్ ఎరుపు రంగులో ఉంది, ఇది చేయాల్సిన అవసరం ఉందని సూచించింది.
మరియు అది ఆకుపచ్చగా మారుతుంది. ఇప్పుడు క్లిక్‌హౌస్ ఆన్ k8s క్లస్టర్ పథకం పూర్తిగా ఖరారు చేయబడింది. మాకు ముక్కలు, ప్రతిరూపాలు, జూకీపర్ ఉన్నాయి, మాకు నిజమైన పెర్సిస్టెంట్ ఉంది, ఇది ఒక విధంగా లేదా మరొక విధంగా అమలు చేయబడుతుంది. ఈ పథకం ఇప్పటికే పూర్తిగా అమలులో ఉంది.
మేము జీవించడం కొనసాగిస్తున్నాము. మా క్లస్టర్ అభివృద్ధి చెందుతోంది. మరియు అలెక్సీ క్లిక్‌హౌస్ యొక్క కొత్త వెర్షన్‌ను ప్రయత్నించి విడుదల చేశాడు.
ఒక ఆచరణాత్మక పని తలెత్తుతుంది - మా క్లస్టర్‌లో క్లిక్‌హౌస్ యొక్క కొత్త సంస్కరణను పరీక్షించడానికి. మరియు, సహజంగా, మీరు అన్నింటినీ రోల్ చేయకూడదు; మీరు ఎక్కడో ఒక మూలలో ఒక ప్రతిరూపంలో కొత్త సంస్కరణను ఉంచాలనుకుంటున్నారు, మరియు బహుశా ఒక కొత్త వెర్షన్ కాదు, కానీ ఒకేసారి రెండు, ఎందుకంటే అవి తరచుగా బయటకు వస్తాయి.
దీని గురించి మనం ఏమి చెప్పగలం?
ఇక్కడ మనకు అలాంటి అవకాశం ఉంది. ఇవి పాడ్ టెంప్లేట్లు. వైవిధ్యమైన క్లస్టర్‌ను నిర్మించడానికి మా ఆపరేటర్ మిమ్మల్ని పూర్తిగా అనుమతిస్తుంది అని మీరు వ్రాయవచ్చు. ఆ. కాన్ఫిగర్ చేయండి, బంచ్‌లోని అన్ని ప్రతిరూపాల నుండి ప్రారంభించి, ప్రతి వ్యక్తిగత ప్రతిరూపంతో ముగుస్తుంది, మనకు క్లిక్‌హౌస్ ఏ వెర్షన్ కావాలి, మనకు ఏ వెర్షన్ స్టోరేజ్ కావాలి. మనకు అవసరమైన కాన్ఫిగరేషన్‌తో క్లస్టర్‌ను పూర్తిగా కాన్ఫిగర్ చేయవచ్చు.
లోపలికి కొంచెం లోతుగా వెళ్దాం. దీనికి ముందు, ClickHouse యొక్క ప్రత్యేకతలకు సంబంధించి ClickHouse-ఆపరేటర్ ఎలా పనిచేస్తుందనే దాని గురించి మేము మాట్లాడాము.
ఇప్పుడు నేను సాధారణంగా ఏ ఆపరేటర్ ఎలా పనిచేస్తుందో అలాగే అది K8sతో ఎలా సంకర్షణ చెందుతుంది అనే దాని గురించి కొన్ని మాటలు చెప్పాలనుకుంటున్నాను.
ముందుగా K8sతో పరస్పర చర్యను చూద్దాం. మేము kubectl దరఖాస్తు చేసినప్పుడు ఏమి జరుగుతుంది? మా వస్తువులు API ద్వారా etcdలో కనిపిస్తాయి.
ఉదాహరణకు, ప్రాథమిక కుబెర్నెట్స్ ఆబ్జెక్ట్‌లు: పాడ్, స్టేట్‌ఫుల్‌సెట్, సర్వీస్ మరియు మొదలైనవి.
అదే సమయంలో, భౌతికంగా ఏమీ జరగదు. ఈ వస్తువులు తప్పనిసరిగా క్లస్టర్‌లో మెటీరియలైజ్ చేయబడాలి.
ఈ ప్రయోజనం కోసం, ఒక నియంత్రిక కనిపిస్తుంది. కంట్రోలర్ అనేది ఈ వివరణలను మెటీరియలైజ్ చేయగల ప్రత్యేక k8s భాగం. శారీరకంగా ఎలా మరియు ఏమి చేయాలో అతనికి తెలుసు. కంటైనర్లను ఎలా నడపాలి, సర్వర్ పని చేయడానికి అక్కడ ఏమి కాన్ఫిగర్ చేయాలి అని అతనికి తెలుసు.
మరియు ఇది K8 లలో మన వస్తువులను సాకారం చేస్తుంది.
కానీ మేము పాడ్‌లు మరియు స్టేట్‌ఫుల్‌సెట్‌లతో మాత్రమే ఆపరేట్ చేయాలనుకుంటున్నాము, మేము ఒక క్లిక్‌హౌస్‌ఇన్‌స్టాలేషన్‌ను సృష్టించాలనుకుంటున్నాము, అంటే క్లిక్‌హౌస్ రకం యొక్క ఆబ్జెక్ట్‌ను ఒకే మొత్తంగా ఆపరేట్ చేయడానికి. ఇప్పటి వరకు అలాంటి అవకాశం లేదు.
కానీ K8s కింది మంచి విషయం కలిగి ఉంది. మా క్లస్టర్ పాడ్‌లు మరియు స్టేట్‌ఫుల్‌సెట్ నుండి అసెంబుల్ చేయబడే ఈ సంక్లిష్ట ఎంటిటీని మనం ఎక్కడైనా కలిగి ఉండాలని మేము కోరుకుంటున్నాము.
మరియు దీని కోసం ఏమి చేయాలి? మొదట, కస్టమ్ రిసోర్స్ డెఫినిషన్ చిత్రంలోకి వస్తుంది. అదేంటి? ఇది K8s కోసం వివరణ, మీరు మరొక డేటా రకాన్ని కలిగి ఉంటారు, మేము పాడ్‌కి అనుకూల వనరుని జోడించాలనుకుంటున్నాము, స్టేట్‌ఫుల్‌సెట్, ఇది లోపల సంక్లిష్టంగా ఉంటుంది. ఇది డేటా నిర్మాణం యొక్క వివరణ.
మేము దానిని kubectl apply ద్వారా కూడా అక్కడికి పంపుతాము. కుబెర్నెట్స్ దానిని సంతోషంగా తీసుకున్నాడు.
ఇప్పుడు మన స్టోరేజ్‌లో, etcdలోని ఆబ్జెక్ట్ క్లిక్‌హౌస్‌ఇన్‌స్టాలేషన్ అనే కస్టమ్ రిసోర్స్‌ను రికార్డ్ చేసే అవకాశం ఉంది.
అయితే ప్రస్తుతానికి ఇంకేమీ జరగదు. అంటే, ఇప్పుడు మనం YAML ఫైల్‌ని క్రియేట్ చేసి, షార్డ్‌లు మరియు ప్రతిరూపాలను వివరించి, “kubectl వర్తిస్తాయి” అని చెబితే, అప్పుడు కుబెర్నెట్‌లు దానిని అంగీకరించి, etcdలో ఉంచి ఇలా అంటారు: “అద్భుతం, కానీ నాకు ఏమి చేయాలో తెలియదు దానితో. ClickHouseInstallationని ఎలా నిర్వహించాలో నాకు తెలియదు."
దీని ప్రకారం, కొత్త డేటా రకాన్ని అందించడంలో కుబెర్నెట్‌లకు సహాయం చేయడానికి మాకు ఎవరైనా అవసరం. ఎడమవైపు స్థానిక డేటా రకాలతో పనిచేసే స్థానిక Kubernetes కంట్రోలర్‌ని కలిగి ఉన్నాము. మరియు కుడివైపున కస్టమ్ డేటా రకాలతో పని చేయగల కస్టమ్ కంట్రోలర్‌ని కలిగి ఉండాలి.
మరియు మరొక విధంగా దీనిని ఆపరేటర్ అంటారు. నేను దీన్ని ప్రత్యేకంగా ఇక్కడ కుబెర్నెట్స్‌గా చేర్చాను, ఎందుకంటే ఇది K8s వెలుపల కూడా అమలు చేయబడుతుంది. చాలా తరచుగా, అన్ని ఆపరేటర్లు కుబెర్నెట్స్‌లో అమలు చేయబడతారు, కానీ బయట నిలబడకుండా ఏదీ నిరోధించదు, కాబట్టి ఇక్కడ ఇది ప్రత్యేకంగా బయటికి తరలించబడుతుంది.
మరియు క్రమంగా, కస్టమ్ కంట్రోలర్, ఆపరేటర్ అని కూడా పిలుస్తారు, API ద్వారా కుబెర్నెట్స్‌తో పరస్పర చర్య చేస్తుంది. APIతో ఎలా ఇంటరాక్ట్ అవ్వాలో దీనికి ఇప్పటికే తెలుసు. మరియు మనం కస్టమ్ రిసోర్స్ నుండి తయారు చేయాలనుకుంటున్న కాంప్లెక్స్ సర్క్యూట్‌ను ఎలా మెటీరియలైజ్ చేయాలో అతనికి ఇప్పటికే తెలుసు. ఆపరేటర్ చేసేది ఇదే.
ఆపరేటర్ ఎలా పని చేస్తాడు? అతను దీన్ని ఎలా చేస్తాడో చూడటానికి కుడి వైపున చూద్దాం. ఆపరేటర్ ఇవన్నీ ఎలా కార్యరూపం దాల్చుతుందో మరియు K8sతో తదుపరి పరస్పర చర్య ఎలా జరుగుతుందో తెలుసుకుందాం.
ఆపరేటర్ ఒక ప్రోగ్రామ్. ఆమె ఈవెంట్ ఓరియెంటెడ్. ఆపరేటర్ Kubernetes APIని ఉపయోగించి ఈవెంట్‌లకు సభ్యత్వాన్ని పొందారు. Kubernetes API మీరు ఈవెంట్‌లకు సభ్యత్వం పొందగల ఎంట్రీ పాయింట్‌లను కలిగి ఉంది. మరియు K8sలో ఏదైనా మారితే, కుబెర్నెటెస్ ఈవెంట్‌లను అందరికీ పంపుతుంది, అనగా. ఈ API పాయింట్‌కి సభ్యత్వం పొందిన వారు నోటిఫికేషన్‌లను స్వీకరిస్తారు.
ఆపరేటర్ ఈవెంట్‌లకు సబ్‌స్క్రయిబ్ చేస్తారు మరియు తప్పనిసరిగా ఒక రకమైన ప్రతిచర్యను చేయాలి. అభివృద్ధి చెందుతున్న సంఘటనలకు ప్రతిస్పందించడం దీని పని.
ఈవెంట్‌లు నిర్దిష్ట నవీకరణల ద్వారా రూపొందించబడ్డాయి. ClickHouseInstallation వివరణతో మా YAML ఫైల్ వస్తుంది. అతను kubectl అప్లై ద్వారా etcdకి వెళ్ళాడు. అక్కడ ఒక ఈవెంట్ ట్రిగ్గర్ చేయబడింది మరియు ఫలితంగా ఈ ఈవెంట్ క్లిక్‌హౌస్-ఆపరేటర్‌కి వచ్చింది. ఆపరేటర్ ఈ వివరణను స్వీకరించారు. మరియు అతను ఏదో ఒకటి చేయాలి. ClickHouseInstallation ఆబ్జెక్ట్‌కు అప్‌డేట్ వచ్చినట్లయితే, మీరు క్లస్టర్‌ను అప్‌డేట్ చేయాలి. మరియు ఆపరేటర్ యొక్క పని క్లస్టర్‌ను నవీకరించడం.
అతను ఏమి చేస్తున్నాడు? ముందుగా, ఈ అప్‌డేట్‌తో మనం ఏమి చేస్తామో దానికి సంబంధించిన కార్యాచరణ ప్రణాళికను రూపొందించాలి. నవీకరణలు చాలా తక్కువగా ఉండవచ్చు, అనగా. YAML ఎగ్జిక్యూషన్‌లో చిన్నది, కానీ క్లస్టర్‌లో చాలా పెద్ద మార్పులను కలిగి ఉంటుంది. అందువల్ల, ఆపరేటర్ ఒక ప్రణాళికను సృష్టిస్తాడు, ఆపై అతను దానికి కట్టుబడి ఉంటాడు.
ఈ ప్రణాళిక ప్రకారం, అతను పాడ్‌లు, సేవలు, అనగా. అతని ప్రధాన పనిని చేయండి. కుబెర్నెటెస్‌లో క్లిక్‌హౌస్ క్లస్టర్‌ని ఎలా నిర్మించాలో ఇలా ఉంది.
ఇప్పుడు అలాంటి ఆసక్తికరమైన విషయం గురించి తెలుసుకుందాం. ఇది కుబెర్నెట్స్ మరియు ఆపరేటర్ మధ్య బాధ్యత యొక్క విభజన, అనగా. కుబెర్నెట్స్ ఏమి చేస్తారు, ఆపరేటర్ ఏమి చేస్తారు మరియు వారు ఒకరితో ఒకరు ఎలా పరస్పరం వ్యవహరిస్తారు.
సిస్టమ్ విషయాలకు కుబెర్నెటెస్ బాధ్యత వహిస్తాడు, అనగా. సిస్టమ్-స్కోప్‌గా అన్వయించబడే ప్రాథమిక వస్తువుల సెట్ కోసం. కుబెర్నెటెస్‌కు పాడ్‌లను ఎలా లాంచ్ చేయాలి, కంటైనర్లను ఎలా రీస్టార్ట్ చేయాలి, వాల్యూమ్‌లను ఎలా మౌంట్ చేయాలి, కాన్ఫిగ్‌మ్యాప్‌తో ఎలా పని చేయాలి, అనగా. వ్యవస్థ అని పిలవబడే ప్రతిదీ.
ఆపరేటర్లు డొమైన్‌లలో పనిచేస్తారు. ప్రతి ఆపరేటర్ దాని స్వంత సబ్జెక్ట్ ఏరియా కోసం తయారు చేయబడింది. మేము క్లిక్‌హౌస్ కోసం చేసాము.
మరియు ఆపరేటర్ ప్రతిరూపాన్ని జోడించడం, రేఖాచిత్రాన్ని రూపొందించడం, పర్యవేక్షణను సెటప్ చేయడం వంటి సబ్జెక్ట్ ఏరియా పరంగా ఖచ్చితంగా పరస్పర చర్య చేస్తారు. ఇది విభజనకు దారి తీస్తుంది.
మేము యాడ్ రెప్లికా చర్యను చేసినప్పుడు ఈ బాధ్యత విభజన ఎలా జరుగుతుందనే దానికి ఆచరణాత్మక ఉదాహరణను చూద్దాం.
ఆపరేటర్ ఒక పనిని అందుకుంటారు - ప్రతిరూపాన్ని జోడించడానికి. ఆపరేటర్ ఏమి చేస్తాడు? ఆపరేటర్ కొత్త స్టేట్‌ఫుల్‌సెట్‌ను సృష్టించాల్సిన అవసరం ఉందని గణిస్తారు, అందులో అలాంటి మరియు అలాంటి టెంప్లేట్లు, వాల్యూమ్ క్లెయిమ్ తప్పనిసరిగా వివరించబడాలి.
అతను అన్నింటినీ సిద్ధం చేసి, దానిని K8 లకు పంపాడు. తనకు కాన్ఫిగ్‌మ్యాప్, స్టేట్‌ఫుల్‌సెట్, వాల్యూమ్ అవసరమని చెప్పారు. Kubernetes పని చేస్తున్నారు. అతను నిర్వహించే ప్రాథమిక యూనిట్లను అతను మెటీరియలైజ్ చేస్తాడు.
ఆపై క్లిక్‌హౌస్-ఆపరేటర్ మళ్లీ అమలులోకి వస్తుంది. అతను ఇప్పటికే భౌతిక పాడ్‌ని కలిగి ఉన్నాడు, దానిపై అతను ఇప్పటికే ఏదైనా చేయగలడు. క్లిక్‌హౌస్-ఆపరేటర్ మళ్లీ డొమైన్ పరంగా పని చేస్తుంది. ఆ. ప్రత్యేకంగా క్లిక్‌హౌస్, క్లస్టర్‌లో ప్రతిరూపాన్ని చేర్చడానికి, మీరు ముందుగా, ఈ క్లస్టర్‌లో ఉన్న డేటా స్కీమాను కాన్ఫిగర్ చేయాలి. మరియు, రెండవది, ఈ ప్రతిరూపాన్ని పర్యవేక్షణలో తప్పనిసరిగా చేర్చాలి, తద్వారా దానిని స్పష్టంగా గుర్తించవచ్చు. ఆపరేటర్ దీన్ని ఇప్పటికే కాన్ఫిగర్ చేసారు.
మరియు ఆ తర్వాత మాత్రమే క్లిక్‌హౌస్ అమలులోకి వస్తుంది, అనగా. మరొక ఉన్నత స్థాయి సంస్థ. ఇది ఇప్పటికే డేటాబేస్. ఇది దాని స్వంత ఉదాహరణను కలిగి ఉంది, క్లస్టర్‌లో చేరడానికి సిద్ధంగా ఉన్న మరొక కాన్ఫిగర్ చేసిన ప్రతిరూపం.
ప్రతిరూపాన్ని జోడించేటప్పుడు అమలు మరియు బాధ్యత యొక్క విభజన యొక్క గొలుసు చాలా పొడవుగా ఉందని తేలింది.
మేము మా ఆచరణాత్మక పనులను కొనసాగిస్తాము. మీకు ఇప్పటికే క్లస్టర్ ఉంటే, మీరు కాన్ఫిగరేషన్‌ను మార్చవచ్చు.
మేము దీన్ని తయారు చేసాము, తద్వారా మీరు ఇప్పటికే ఉన్న xmlలో అతికించవచ్చు, ఇది ClickHouse అర్థం చేసుకుంటుంది.
మీరు క్లిక్‌హౌస్‌ని చక్కగా ట్యూన్ చేయవచ్చు. హోస్ట్‌పాత్, లోకల్ స్టోరేజ్‌ని వివరించేటప్పుడు నేను మాట్లాడినది జస్ట్ జోన్‌డ్ డిప్లాయ్‌మెంట్. జోన్‌ల విస్తరణను సరిగ్గా ఈ విధంగా చేయాలి.
తదుపరి ఆచరణాత్మక పని పర్యవేక్షణ.
మా క్లస్టర్ మారితే, మేము క్రమానుగతంగా పర్యవేక్షణను కాన్ఫిగర్ చేయాలి.
రేఖాచిత్రం చూద్దాం. మేము ఇప్పటికే ఇక్కడ ఆకుపచ్చ బాణాలను చూశాము. ఇప్పుడు ఎరుపు బాణాలను చూద్దాం. ఈ విధంగా మేము మా క్లస్టర్‌ను పర్యవేక్షించాలనుకుంటున్నాము. క్లిక్‌హౌస్ క్లస్టర్ నుండి కొలమానాలు ప్రోమేతియస్‌లోకి, ఆపై గ్రాఫానాలోకి ఎలా వస్తాయి.
పర్యవేక్షణలో ఇబ్బంది ఏమిటి? ఇది ఒక రకమైన విజయంగా ఎందుకు ప్రదర్శించబడింది? కష్టం డైనమిక్స్‌లో ఉంది. మనకు ఒక క్లస్టర్ ఉన్నప్పుడు మరియు అది స్థిరంగా ఉన్నప్పుడు, మేము ఒకసారి మానిటరింగ్‌ని సెటప్ చేయవచ్చు మరియు ఇకపై ఇబ్బంది పడకూడదు.
కానీ మనకు చాలా క్లస్టర్‌లు ఉంటే, లేదా ఏదైనా నిరంతరం మారుతూ ఉంటే, అప్పుడు ప్రక్రియ డైనమిక్‌గా ఉంటుంది. మరియు నిరంతరం పర్యవేక్షణను పునర్నిర్మించడం వనరులు మరియు సమయాన్ని వృధా చేస్తుంది, అనగా. కేవలం సోమరితనం కూడా. ఇది స్వయంచాలకంగా ఉండాలి. ప్రక్రియ యొక్క డైనమిక్స్‌లో ఇబ్బంది ఉంది. మరియు ఆపరేటర్ దీన్ని బాగా ఆటోమేట్ చేస్తుంది.
మా క్లస్టర్ ఎలా అభివృద్ధి చెందింది? మొదట్లో ఆయన అలానే ఉండేవారు.
అప్పుడు అతను ఇలా ఉన్నాడు.
చివరికి ఇలా అయ్యాడు.
మరియు పర్యవేక్షణ ఆపరేటర్ ద్వారా స్వయంచాలకంగా చేయబడుతుంది. సింగిల్ పాయింట్ ఆఫ్ ఎంట్రీ.
మరియు నిష్క్రమణ వద్ద మన క్లస్టర్ యొక్క జీవితం లోపల ఎలా ఉడికిపోతుందో చూడటానికి గ్రాఫానా డాష్‌బోర్డ్‌ని చూస్తాము.
మార్గం ద్వారా, గ్రాఫానా డ్యాష్‌బోర్డ్ కూడా నేరుగా సోర్స్ కోడ్‌లో మా ఆపరేటర్‌తో పంపిణీ చేయబడుతుంది. మీరు కనెక్ట్ చేసి ఉపయోగించవచ్చు. మా DevOps నాకు ఈ స్క్రీన్‌షాట్ ఇచ్చింది.
మేము తర్వాత ఎక్కడికి వెళ్లాలనుకుంటున్నాము? ఇది:
- పరీక్ష ఆటోమేషన్‌ను అభివృద్ధి చేయండి. ప్రధాన పని కొత్త సంస్కరణల స్వయంచాలక పరీక్ష.
- మేము నిజంగా ZooKeeperతో ఏకీకరణను ఆటోమేట్ చేయాలనుకుంటున్నాము. మరియు ZooKeeper-ఆపరేటర్‌తో ఏకీకృతం చేయడానికి ప్రణాళికలు ఉన్నాయి. ఆ. ZooKeeper కోసం ఒక ఆపరేటర్ వ్రాయబడింది మరియు ఇద్దరు ఆపరేటర్లు మరింత అనుకూలమైన పరిష్కారాన్ని రూపొందించడానికి ఏకీకృతం చేయడం ప్రారంభించడం తార్కికం.
- మేము మరింత క్లిష్టమైన కీలక సంకేతాలను చేయాలనుకుంటున్నాము.
- మేము టెంప్లేట్‌ల వారసత్వానికి చేరుకుంటున్నామని నేను ఆకుపచ్చ రంగులో హైలైట్ చేసాను - పూర్తయింది, అనగా ఆపరేటర్ యొక్క తదుపరి విడుదలతో మేము ఇప్పటికే టెంప్లేట్‌ల వారసత్వాన్ని కలిగి ఉంటాము. ఇది ముక్కల నుండి సంక్లిష్టమైన కాన్ఫిగరేషన్లను రూపొందించడానికి మిమ్మల్ని అనుమతించే శక్తివంతమైన సాధనం.
- మరియు మేము సంక్లిష్ట పనుల ఆటోమేషన్ కావాలి. ప్రధానమైనది రీ-షార్డింగ్.
కొన్ని ఇంటర్మీడియట్ ఫలితాలను తీసుకుందాం.
ఫలితంగా మనకు ఏమి లభిస్తుంది? మరియు అది చేయడం విలువైనదేనా లేదా? డేటాబేస్‌ను కుబెర్నెట్స్‌లోకి లాగి, సాధారణంగా ఆపరేటర్‌ని మరియు ముఖ్యంగా అలిట్నిటీ ఆపరేటర్‌ని ఉపయోగించడం కూడా అవసరమా?
అవుట్పుట్ వద్ద మనకు లభిస్తుంది:
- కాన్ఫిగరేషన్, విస్తరణ మరియు నిర్వహణ యొక్క ముఖ్యమైన సరళీకరణ మరియు ఆటోమేషన్.
- తక్షణమే అంతర్నిర్మిత పర్యవేక్షణ.
- మరియు సంక్లిష్ట పరిస్థితుల కోసం క్రోడీకరించబడిన టెంప్లేట్లు ఉపయోగించడానికి సిద్ధంగా ఉన్నాయి. ప్రతిరూపాన్ని జోడించడం వంటి చర్య మానవీయంగా చేయవలసిన అవసరం లేదు. ఆపరేటర్ దీన్ని చేస్తాడు.
చివరిగా ఒక్క ప్రశ్న మాత్రమే మిగిలి ఉంది. మేము ఇప్పటికే Kubernetes, వర్చువలైజేషన్‌లో డేటాబేస్ కలిగి ఉన్నాము. ముఖ్యంగా క్లిక్‌హౌస్ పనితీరు కోసం ఆప్టిమైజ్ చేయబడినందున, అటువంటి పరిష్కారం యొక్క పనితీరు గురించి ఏమిటి?
సమాధానం అంతా బాగానే ఉంది! నేను వివరాల్లోకి వెళ్లను; ఇది ప్రత్యేక నివేదిక యొక్క అంశం.
కానీ TSBS వంటి ప్రాజెక్ట్ ఉంది. దాని ప్రధాన విధి ఏమిటి? ఇది డేటాబేస్ పనితీరు పరీక్ష. వెచ్చటితో వెచ్చగా, మృదువుగా మృదువుగా పోల్చే ప్రయత్నం ఇది.
అతను ఎలా పని చేస్తాడు? ఒక డేటా సెట్ రూపొందించబడింది. అప్పుడు ఈ డేటా సెట్ ఒకే పరీక్షలను ఉపయోగించి వేర్వేరు డేటాబేస్‌లలో అమలు చేయబడుతుంది. మరియు ప్రతి డేటాబేస్ తనకు తెలిసిన విధంగా ఒక సమస్యను పరిష్కరిస్తుంది. ఆపై మీరు ఫలితాలను పోల్చవచ్చు.
ఇది ఇప్పటికే పెద్ద సంఖ్యలో డేటాబేస్‌లకు మద్దతు ఇస్తుంది. నేను మూడు ప్రధానమైన వాటిని గుర్తించాను. ఇది:
- టైమ్‌స్కేల్DB.
- InfluxDB.
- క్లిక్‌హౌస్.
ఇదే విధమైన మరొక పరిష్కారంతో పోలిక కూడా చేయబడింది. RedShiftతో పోలిక. అమెజాన్‌లో పోలిక జరిగింది. ఈ విషయంలో క్లిక్‌హౌస్ కూడా అందరికంటే చాలా ముందుంది.
నేను చెప్పిన దాని నుండి ఏ ముగింపులు తీసుకోవచ్చు?
- కుబెర్నెట్స్‌లో DB సాధ్యమే. బహుశా ఏదైనా సాధ్యమే, కానీ మొత్తంమీద అది సాధ్యమేననిపిస్తోంది. మా ఆపరేటర్ సహాయంతో Kubernetes లో క్లిక్‌హౌస్ ఖచ్చితంగా సాధ్యమవుతుంది.
- ఆపరేటర్ ప్రక్రియలను ఆటోమేట్ చేయడంలో సహాయపడుతుంది మరియు నిజంగా జీవితాన్ని సులభతరం చేస్తుంది.
- పనితీరు సాధారణంగా ఉంది.
- మరియు దీనిని ఉపయోగించవచ్చని మరియు ఉపయోగించాలని మాకు అనిపిస్తుంది.
ఓపెన్ సోర్స్ - మాతో చేరండి!
నేను ఇప్పటికే చెప్పినట్లుగా, ఆపరేటర్ పూర్తిగా ఓపెన్ సోర్స్ ఉత్పత్తి, కాబట్టి గరిష్ట సంఖ్యలో ప్రజలు దీనిని ఉపయోగిస్తే చాలా మంచిది. మాతో చేరండి! మేము మీ అందరి కోసం ఎదురు చూస్తున్నాము!
అందరికి ధన్యవాదాలు!
మీ ప్రశ్నలు
నివేదికకు ధన్యవాదాలు! నా పేరు అంటోన్. నేను SEMrush నుండి వచ్చాను. లాగింగ్‌లో ఏముందని నేను ఆశ్చర్యపోతున్నాను. మేము మానిటరింగ్ గురించి విన్నాము, కానీ లాగింగ్ గురించి ఏమీ లేదు, మేము మొత్తం క్లస్టర్ గురించి మాట్లాడినట్లయితే. ఉదాహరణకు, మేము హార్డ్‌వేర్‌పై క్లస్టర్‌ను పెంచాము. మరియు మేము కేంద్రీకృత లాగింగ్‌ని ఉపయోగిస్తాము, ప్రామాణిక మార్గాలను ఉపయోగించి వాటిని సాధారణ కుప్పగా సేకరిస్తాము. ఆపై అక్కడ నుండి మనకు ఆసక్తి ఉన్న డేటాను పొందుతాము.
మంచి ప్రశ్న, అంటే టోడో జాబితాలో లాగిన్ అవ్వడం. మా ఆపరేటర్ దీన్ని ఇంకా ఆటోమేట్ చేయలేదు. ఇది ఇంకా అభివృద్ధి చెందుతోంది, ప్రాజెక్ట్ ఇప్పటికీ చాలా చిన్నది. లాగింగ్ యొక్క అవసరాన్ని మేము అర్థం చేసుకున్నాము. ఇది కూడా చాలా ముఖ్యమైన అంశం. మరియు ఇది బహుశా పర్యవేక్షణ కంటే తక్కువ ముఖ్యమైనది కాదు. కానీ అమలు కోసం జాబితాలో మొదటిది పర్యవేక్షణ. లాగింగ్ ఉంటుంది. సహజంగానే, మేము క్లస్టర్ జీవితంలోని అన్ని అంశాలను ఆటోమేట్ చేయడానికి ప్రయత్నిస్తాము. అందువల్ల, సమాధానం ఏమిటంటే, ప్రస్తుతానికి ఆపరేటర్, దురదృష్టవశాత్తు, దీన్ని ఎలా చేయాలో తెలియదు, కానీ ఇది ప్రణాళికలలో ఉంది, మేము దీన్ని చేస్తాము. మీరు చేరాలనుకుంటే, దయచేసి అభ్యర్థనను లాగండి.
హలో! నివేదికకు ధన్యవాదాలు! నా దగ్గర పెర్సిస్టెంట్ వాల్యూమ్‌లకు సంబంధించిన ప్రామాణిక ప్రశ్న ఉంది. మేము ఈ ఆపరేటర్‌తో కాన్ఫిగరేషన్‌ను సృష్టించినప్పుడు, మనకు ఏ నోడ్‌లో నిర్దిష్ట డిస్క్ లేదా ఫోల్డర్ జోడించబడిందో ఆపరేటర్ ఎలా నిర్ణయిస్తారు? డిస్క్‌ని కలిగి ఉన్న ఈ నోడ్‌లలో దయచేసి మా క్లిక్‌హౌస్‌ను ఉంచమని మేము మొదట అతనికి వివరించాలి?
నేను అర్థం చేసుకున్నంత వరకు, ఈ ప్రశ్న స్థానిక నిల్వ యొక్క కొనసాగింపు, ముఖ్యంగా హోస్ట్‌పాత్ భాగం. పాడ్‌ని అటువంటి నోడ్‌లో లాంచ్ చేయాల్సిన అవసరం ఉందని, దానికి భౌతికంగా కనెక్ట్ చేయబడిన డిస్క్‌ను కలిగి ఉందని, ఇది అటువంటి మార్గంలో మౌంట్ చేయబడిందని ఇది మొత్తం సిస్టమ్‌కు వివరించడం లాంటిది. నేను చాలా ఉపరితలంగా తాకిన మొత్తం విభాగం ఇది ఎందుకంటే అక్కడ సమాధానం చాలా పెద్దది.
క్లుప్తంగా ఇది ఇలా కనిపిస్తుంది. సహజంగానే, మేము ఈ వాల్యూమ్‌లను అందించాలి. ప్రస్తుతానికి, స్థానిక నిల్వలో డైనమిక్ ప్రొవిజన్ లేదు, కాబట్టి DevOps తప్పనిసరిగా డిస్క్‌లను ఈ వాల్యూమ్‌లను కట్ చేయాలి. మరియు మీరు అటువంటి మరియు అటువంటి తరగతి యొక్క నిరంతర వాల్యూమ్‌లను కలిగి ఉంటారని కుబెర్నెటెస్ ప్రొవిజనింగ్‌ను వారు తప్పనిసరిగా వివరించాలి, అవి అటువంటి మరియు అటువంటి నోడ్‌లలో ఉన్నాయి. అటువంటి మరియు అటువంటి లోకల్ స్టోరేజ్ క్లాస్ అవసరమయ్యే పాడ్‌లను లేబుల్‌లను ఉపయోగించి అటువంటి మరియు అలాంటి నోడ్‌లకు మాత్రమే మళ్లించాల్సిన అవసరం ఉందని మీరు కుబెర్నెట్‌లకు వివరించాలి. ఈ ప్రయోజనాల కోసం, ఆపరేటర్‌కు ఒక రకమైన లేబుల్‌ని కేటాయించగల సామర్థ్యం ఉంది మరియు ఒక్కో హోస్ట్ ఉదాహరణకి ఒకటి. మరియు సాధారణ పరంగా అవసరాలు, లేబుల్‌లకు అనుగుణంగా ఉండే నోడ్‌లపై మాత్రమే రన్ అయ్యేలా కుబెర్నెట్స్ ద్వారా పాడ్‌లు రూట్ చేయబడతాయని తేలింది. నిర్వాహకులు లేబుల్స్ మరియు ప్రొవిజన్ డిస్క్‌లను మాన్యువల్‌గా కేటాయిస్తారు. ఆపై అది స్కేల్స్.
మరియు ఇది మూడవ ఎంపిక, స్థానికం, ఇది కొంచెం సులభతరం చేయడంలో సహాయపడుతుంది. నేను ఇప్పటికే నొక్కిచెప్పినట్లుగా, ఇది ట్యూనింగ్‌పై శ్రమతో కూడుకున్న పని, ఇది చివరికి గరిష్ట పనితీరును పొందడంలో సహాయపడుతుంది.
దీనికి సంబంధించి నాకు రెండవ ప్రశ్న ఉంది. మేము నోడ్‌ను కోల్పోయామా లేదా అనేది మనకు పట్టింపు లేని విధంగా కుబెర్నెటెస్ రూపొందించబడింది. మన ముక్క వేలాడుతున్న నోడ్‌ను కోల్పోయినట్లయితే ఈ సందర్భంలో మనం ఏమి చేయాలి?
అవును, కుబెర్నెటెస్ మొదట్లో మా పాడ్‌లతో మా సంబంధం పశువుల లాంటిదని భావించారు, కానీ ఇక్కడ మాతో ప్రతి డిస్క్ పెంపుడు జంతువు లాగా మారుతుంది. అలాంటి సమస్య ఉంది, మనం వాటిని విసిరేయలేము. మరియు కుబెర్నెటెస్ అభివృద్ధి పూర్తిగా విస్మరించబడిన వనరుగా ఉన్నట్లుగా, దానిని పూర్తిగా తాత్వికంగా పరిగణించడం అసాధ్యం అనే దిశలో సాగుతోంది.
ఇప్పుడు ప్రాక్టికల్ ప్రశ్న కోసం. మీరు డిస్క్ ఉన్న నోడ్‌ను పోగొట్టుకుంటే ఏమి చేయాలి? ఇక్కడ సమస్య ఉన్నత స్థాయిలో పరిష్కరించబడుతుంది. ClickHouse విషయంలో, మేము ఉన్నత స్థాయిలో పనిచేసే ప్రతిరూపాలను కలిగి ఉన్నాము, అనగా. ClickHouse స్థాయిలో.
ఫలితంగా ఏర్పడే వైఖరి ఏమిటి? డేటా కోల్పోకుండా చూసుకోవడం DevOps బాధ్యత. అతను ప్రతిరూపణను సరిగ్గా సెటప్ చేయాలి మరియు ప్రతిరూపణ అమలులో ఉందని నిర్ధారించుకోవాలి. ClickHouse స్థాయిలో ఉన్న ప్రతిరూపం తప్పనిసరిగా నకిలీ డేటాను కలిగి ఉండాలి. ఇది ఆపరేటర్ పరిష్కరించే పని కాదు. మరియు కుబెర్నెట్స్ స్వయంగా పరిష్కరించే సమస్య కాదు. ఇది క్లిక్‌హౌస్ స్థాయిలో ఉంది.
మీ ఐరన్ నోడ్ పడిపోతే ఏమి చేయాలి? మరియు మీరు రెండవదాన్ని ఇన్‌స్టాల్ చేయాలి, దానిపై డిస్క్‌ను సరిగ్గా అందించాలి మరియు లేబుల్‌లను వర్తింపజేయాలి. మరియు ఆ తర్వాత, కుబెర్నెట్స్ దానిపై ఒక ఉదాహరణ పాడ్‌ను ప్రారంభించగల అవసరాలను ఇది తీరుస్తుంది. కుబెర్నెటెస్ దీన్ని ప్రారంభించనున్నారు. పేర్కొన్న సంఖ్యను చేరుకోవడానికి మీ పాడ్‌ల సంఖ్య సరిపోదు. ఇది నేను చూపిన చక్రం గుండా వెళుతుంది. మరియు అత్యధిక స్థాయిలో, క్లిక్‌హౌస్ మేము ప్రతిరూపాన్ని నమోదు చేసామని అర్థం చేసుకుంటుంది, అది ఇప్పటికీ ఖాళీగా ఉంది మరియు మేము దానికి డేటాను బదిలీ చేయడం ప్రారంభించాలి. ఆ. ఈ ప్రక్రియ ఇంకా బాగా ఆటోమేట్ కాలేదు.
నివేదికకు ధన్యవాదాలు! అన్ని రకాల అసహ్యకరమైన విషయాలు జరిగినప్పుడు, ఆపరేటర్ క్రాష్ అవుతుంది మరియు పునఃప్రారంభించబడుతుంది మరియు ఆ సమయంలో ఈవెంట్‌లు వస్తాయి, మీరు దీన్ని ఎలాగైనా నిర్వహిస్తారా?
ఆపరేటర్ క్రాష్ అయ్యి, రీస్టార్ట్ అయితే ఏమి జరుగుతుంది, సరియైనదా?
అవును. మరియు ఆ సమయంలో సంఘటనలు వచ్చాయి.
ఈ సందర్భంలో ఏమి చేయాలో ఆపరేటర్ మరియు కుబెర్నెట్స్ మధ్య పాక్షికంగా భాగస్వామ్యం చేయబడుతుంది. కుబెర్నెటెస్‌కు జరిగిన ఈవెంట్‌ని రీప్లే చేయగల సామర్థ్యం ఉంది. అతను రీప్లే చేస్తాడు. మరియు ఈవెంట్ లాగ్ అతనిపై మళ్లీ ప్లే చేయబడినప్పుడు, ఈ ఈవెంట్‌లు అసంపూర్తిగా ఉన్నాయని నిర్ధారించుకోవడం ఆపరేటర్ యొక్క పని. మరియు అదే సంఘటన పునరావృతమయ్యేలా మన వ్యవస్థను విచ్ఛిన్నం చేయదు. మరియు మా ఆపరేటర్ ఈ పనిని ఎదుర్కొంటాడు.
హలో! నివేదికకు ధన్యవాదాలు! డిమిత్రి Zavyalov, కంపెనీ స్మెడోవా. హ్యాప్రాక్సీతో కాన్ఫిగర్ చేసే సామర్థ్యాన్ని ఆపరేటర్‌కు జోడించడానికి ప్రణాళికలు ఉన్నాయా? నేను స్టాండర్డ్ బ్యాలెన్సర్‌తో పాటు మరికొన్ని బ్యాలెన్సర్‌లపై ఆసక్తి కలిగి ఉంటాను, తద్వారా ఇది స్మార్ట్‌గా ఉంటుంది మరియు క్లిక్‌హౌస్ నిజంగా ఉందని అర్థం చేసుకోవచ్చు.
మీరు ప్రవేశం గురించి మాట్లాడుతున్నారా?
అవును, హాప్రాక్సీతో ఇంగ్రెస్‌ని భర్తీ చేయండి. హాప్రాక్సీలో మీరు ప్రతిరూపాలను కలిగి ఉన్న క్లస్టర్ యొక్క టోపోలాజీని పేర్కొనవచ్చు.
మేము ఇంకా దాని గురించి ఆలోచించలేదు. మీకు ఇది అవసరమైతే మరియు అది ఎందుకు అవసరమో వివరించగలిగితే, ప్రత్యేకించి మీరు పాల్గొనాలనుకుంటే దాన్ని అమలు చేయడం సాధ్యమవుతుంది. ఎంపికను పరిగణనలోకి తీసుకోవడం మాకు సంతోషంగా ఉంటుంది. సంక్షిప్త సమాధానం లేదు, ప్రస్తుతం మాకు అలాంటి కార్యాచరణ లేదు. చిట్కాకు ధన్యవాదాలు, మేము ఈ విషయాన్ని పరిశీలిస్తాము. మరియు మీరు వినియోగ సందర్భాన్ని మరియు ఆచరణలో ఎందుకు అవసరమో కూడా వివరిస్తే, ఉదాహరణకు, GitHubలో సమస్యలను సృష్టించినట్లయితే, అది గొప్పగా ఉంటుంది.
ఇప్పటికే ఉంది.
ఫైన్. మేము ఏవైనా సూచనలకు సిద్ధంగా ఉన్నాము. మరియు హాప్రాక్సీ టోడో జాబితాకు జోడించబడింది. టోడో జాబితా పెరుగుతోంది, ఇంకా తగ్గిపోలేదు. కానీ ఇది మంచిది, అంటే ఉత్పత్తికి డిమాండ్ ఉందని అర్థం.
మూలం: www.habr.com