🥇Yandex.Cloud కోసం Kubernetesలో CSI డ్రైవర్‌ను అభివృద్ధి చేయడంలో మా అనుభవం

విడుదల చేయడం ద్వారా కుబెర్నెట్స్ కోసం ఓపెన్ సోర్స్ సాధనాలకు ఫ్లాంట్ తన సహకారాన్ని విస్తరిస్తున్నట్లు ప్రకటించడానికి మేము సంతోషిస్తున్నాము CSI డ్రైవర్ యొక్క ఆల్ఫా వెర్షన్ Yandex.Cloud కోసం (కంటైనర్ స్టోరేజ్ ఇంటర్‌ఫేస్).

కానీ అమలు వివరాలకు వెళ్లే ముందు, Yandex ఇప్పటికే సేవను కలిగి ఉన్నప్పుడు ఇది ఎందుకు అవసరం అనే ప్రశ్నకు సమాధానం ఇద్దాం. కుబెర్నెట్స్ కోసం నిర్వహించబడే సేవ.

పరిచయం

ఇది ఎందుకు?

మా కంపెనీలో, ఉత్పత్తిలో కుబెర్నెట్‌లను ఉపయోగించడం ప్రారంభించినప్పటి నుండి (అనగా ఇప్పుడు చాలా సంవత్సరాలుగా), మేము మా స్వంత సాధనాన్ని (డెక్‌హౌస్) అభివృద్ధి చేస్తున్నాము, ఇది మార్గం ద్వారా, మేము త్వరలో ఓపెన్ సోర్స్ ప్రాజెక్ట్‌గా అందుబాటులోకి తీసుకురావాలని ప్లాన్ చేస్తున్నాము. . దాని సహాయంతో, మేము మా అన్ని క్లస్టర్‌లను ఏకరీతిగా కాన్ఫిగర్ చేస్తాము మరియు కాన్ఫిగర్ చేస్తాము మరియు ప్రస్తుతం వాటిలో 100 కంటే ఎక్కువ ఉన్నాయి, అనేక రకాల హార్డ్‌వేర్ కాన్ఫిగరేషన్‌లలో మరియు అందుబాటులో ఉన్న అన్ని క్లౌడ్ సేవల్లో.

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

NB: ఇది మా అనుభవం, మరియు ఇది చాలా నిర్దిష్టమైనది. రెడీమేడ్ సొల్యూషన్‌లను ఉపయోగించకుండా ప్రతి ఒక్కరూ తమ స్వంతంగా కుబెర్నెట్స్ క్లస్టర్‌లను అమలు చేయాలని మేము ఏ విధంగానూ సూచించడం లేదు. మార్గం ద్వారా, Yandex నుండి Kubernetes ఆపరేట్ చేయడంలో మాకు నిజమైన అనుభవం లేదు మరియు మేము ఈ వ్యాసంలో ఈ సేవ యొక్క ఏ అంచనాను ఇవ్వము.

ఇది ఏమిటి మరియు ఎవరి కోసం?

కాబట్టి, మేము ఇప్పటికే కుబెర్నెట్స్‌లో నిల్వ చేయడానికి ఆధునిక విధానం గురించి మాట్లాడాము: CSI ఎలా పని చేస్తుంది? и సంఘం ఎలా వచ్చింది ఈ విధానానికి.

ప్రస్తుతం, చాలా పెద్ద క్లౌడ్ సర్వీస్ ప్రొవైడర్లు కుబెర్నెట్స్‌లో తమ క్లౌడ్ డిస్క్‌లను పెర్సిస్టెంట్ వాల్యూమ్‌గా ఉపయోగించడం కోసం డ్రైవర్‌లను అభివృద్ధి చేశారు. సరఫరాదారుకు అలాంటి డ్రైవర్ లేకపోతే, కానీ అవసరమైన అన్ని విధులు API ద్వారా అందించబడితే, డ్రైవర్‌ను మీరే అమలు చేయకుండా ఏదీ మిమ్మల్ని నిరోధించదు. Yandex.Cloudతో ఇదే జరిగింది.

అభివృద్ధికి ప్రాతిపదికగా తీసుకున్నాం డిజిటల్ ఓషన్ క్లౌడ్ కోసం CSI డ్రైవర్ మరియు నుండి కొన్ని ఆలోచనలు GCP కోసం డ్రైవర్లు, ఈ మేఘాల API (Google మరియు Yandex)తో పరస్పర చర్య అనేక సారూప్యతలను కలిగి ఉంది. ముఖ్యంగా, API మరియు జిసిపి, మరియు వై Yandex ఒక వస్తువును తిరిగి ఇవ్వండి Operation దీర్ఘకాలిక కార్యకలాపాల స్థితిని ట్రాక్ చేయడానికి (ఉదాహరణకు, కొత్త డిస్క్‌ను సృష్టించడం). Yandex.Cloud APIతో పరస్పర చర్య చేయడానికి, ఉపయోగించండి Yandex.Cloud Go SDK.

చేసిన పనికి ఫలితం GitHubలో ప్రచురించబడింది మరియు కొన్ని కారణాల వల్ల, Yandex.Cloud వర్చువల్ మెషీన్‌లలో (కానీ రెడీమేడ్ మేనేజ్డ్ క్లస్టర్ కాదు) మరియు CSI ద్వారా డిస్క్‌లను (ఆర్డర్) ఉపయోగించాలనుకునే వారి స్వంత కుబెర్నెట్స్ ఇన్‌స్టాలేషన్‌ను ఉపయోగించే వారికి ఉపయోగకరంగా ఉండవచ్చు.

అమలు

ముఖ్య లక్షణాలు

ప్రస్తుతం డ్రైవర్ క్రింది ఫంక్షన్లకు మద్దతు ఇస్తుంది:

క్లస్టర్‌లోని నోడ్‌ల టోపోలాజీ ప్రకారం క్లస్టర్‌లోని అన్ని జోన్‌లలో డిస్క్‌లను ఆర్డర్ చేయడం;
గతంలో ఆర్డర్ చేసిన డిస్కులను తొలగించడం;
డిస్క్‌ల కోసం ఆఫ్‌లైన్ పునఃపరిమాణం (Yandex.Cloud మద్దతు ఇవ్వరు వర్చువల్ మెషీన్‌కు మౌంట్ చేయబడిన డిస్క్‌లను పెంచడం). రీసైజింగ్‌ని వీలైనంత నొప్పిలేకుండా చేయడానికి డ్రైవర్‌ని ఎలా సవరించాలి అనే సమాచారం కోసం, దిగువన చూడండి.

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

ప్రధాన కష్టం మరియు దానిని ఎలా అధిగమించాలి

Yandex.Cloud APIలో నిజ సమయంలో డిస్క్‌లను పెంచే సామర్థ్యం లేకపోవడం అనేది PV (పర్సిస్టెంట్ వాల్యూమ్) కోసం పరిమాణాన్ని మార్చే ఆపరేషన్‌ను క్లిష్టతరం చేసే పరిమితి: ఈ సందర్భంలో, డిస్క్‌ని ఉపయోగించే అప్లికేషన్ పాడ్‌ని నిలిపివేయడం అవసరం, మరియు ఇది డౌన్‌టైమ్ అప్లికేషన్‌లకు కారణం కావచ్చు.

ప్రకారం CSI లక్షణాలు, CSI కంట్రోలర్ అది డిస్క్‌ల పరిమాణాన్ని “ఆఫ్‌లైన్” మాత్రమే మార్చగలదని నివేదించినట్లయితే (VolumeExpansion.OFFLINE), అప్పుడు డిస్క్‌ను పెంచే ప్రక్రియ ఇలా ఉండాలి:

ప్లగ్ఇన్ మాత్రమే కలిగి ఉంటే VolumeExpansion.OFFLINE విస్తరణ సామర్థ్యం మరియు వాల్యూమ్ ప్రస్తుతం ప్రచురించబడింది లేదా నోడ్‌లో అందుబాటులో ఉంది ControllerExpandVolume దేని తర్వాత మాత్రమే పిలవాలి:

ప్లగిన్‌లో కంట్రోలర్ ఉంది PUBLISH_UNPUBLISH_VOLUME సామర్థ్యం మరియు ControllerUnpublishVolume విజయవంతంగా అమలు చేయబడింది.

లేకపోతే

ప్లగిన్‌కు కంట్రోలర్ లేదు PUBLISH_UNPUBLISH_VOLUME సామర్థ్యం, ప్లగ్ఇన్ నోడ్ కలిగి ఉంది STAGE_UNSTAGE_VOLUME సామర్థ్యం, మరియు NodeUnstageVolume విజయవంతంగా పూర్తయింది.

లేకపోతే

ప్లగిన్‌కు కంట్రోలర్ లేదు PUBLISH_UNPUBLISH_VOLUME సామర్థ్యం, లేదా నోడ్ STAGE_UNSTAGE_VOLUME సామర్థ్యం, మరియు NodeUnpublishVolume విజయవంతంగా పూర్తి చేసింది.

దీని అర్థం మీరు డిస్క్‌ని విస్తరించే ముందు వర్చువల్ మెషీన్ నుండి వేరుచేయాలి.

అయితే, దురదృష్టవశాత్తు సాక్షాత్కారము సైడ్‌కార్‌ల ద్వారా CSI స్పెసిఫికేషన్ ఈ అవసరాలకు అనుగుణంగా లేదు:

సైడ్‌కార్ కంటైనర్‌లో csi-attacher, ఇది మౌంట్‌ల మధ్య అవసరమైన గ్యాప్ ఉనికికి బాధ్యత వహించాలి, ఈ కార్యాచరణ కేవలం ఆఫ్‌లైన్ పునఃపరిమాణంలో అమలు చేయబడదు. దీనిపై చర్చ మొదలైంది ఇక్కడ.
ఈ సందర్భంలో సైడ్‌కార్ కంటైనర్ అంటే ఏమిటి? CSI ప్లగిన్ స్వయంగా Kubernetes APIతో పరస్పర చర్య చేయదు, కానీ సైడ్‌కార్ కంటైనర్‌ల ద్వారా పంపిన gRPC కాల్‌లకు మాత్రమే ప్రతిస్పందిస్తుంది. తాజా అభివృద్ధి చేస్తున్నారు కుబెర్నెట్స్ సంఘం ద్వారా.

మా విషయంలో (CSI ప్లగిన్), డిస్క్‌ను పెంచే ఆపరేషన్ ఇలా కనిపిస్తుంది:

మేము gRPC కాల్‌ని అందుకుంటాము ControllerExpandVolume;
మేము APIలో డిస్క్‌ను పెంచడానికి ప్రయత్నిస్తున్నాము, అయితే డిస్క్ మౌంట్ చేయబడినందున ఆపరేషన్ చేయడం అసంభవం గురించి మేము ఒక దోషాన్ని అందుకుంటాము;
మేము డిస్క్ ఐడెంటిఫైయర్‌ను మ్యాప్‌లో నిల్వ చేస్తాము, ఇది డిస్క్‌లను కలిగి ఉంటుంది, దీని కోసం పెరుగుదల ఆపరేషన్ చేయవలసి ఉంటుంది. దిగువన, సంక్షిప్తత కోసం, మేము ఈ మ్యాప్‌ని ఇలా పిలుస్తాము volumeResizeRequired;
డిస్క్‌ని ఉపయోగిస్తున్న పాడ్‌ను మాన్యువల్‌గా తీసివేయండి. కుబెర్నెటెస్ దీన్ని పునఃప్రారంభిస్తారు. తద్వారా డిస్క్ మౌంట్ చేయడానికి సమయం లేదు (ControllerPublishVolume) మౌంట్ చేయడానికి ప్రయత్నిస్తున్నప్పుడు పెరుగుదల ఆపరేషన్‌ని పూర్తి చేయడానికి ముందు, మేము ఇచ్చిన డిస్క్ ఇప్పటికీ ఉందో లేదో తనిఖీ చేస్తాము volumeResizeRequired మరియు లోపాన్ని తిరిగి ఇవ్వండి;
CSI డ్రైవర్ పునఃపరిమాణం ఆపరేషన్‌ను మళ్లీ అమలు చేయడానికి ప్రయత్నిస్తుంది. ఆపరేషన్ విజయవంతమైతే, దాని నుండి డిస్క్‌ను తీసివేయండి volumeResizeRequired;
ఎందుకంటే నుండి డిస్క్ ID లేదు volumeResizeRequired, ControllerPublishVolume విజయవంతంగా వెళుతుంది, డిస్క్ మౌంట్ చేయబడింది, పాడ్ ప్రారంభమవుతుంది.

ప్రతిదీ చాలా సరళంగా కనిపిస్తుంది, కానీ ఎప్పటిలాగే ఆపదలు ఉన్నాయి. డిస్క్‌లను విస్తరిస్తుంది బాహ్య-రీసైజర్, ఇది ఆపరేషన్ సమయంలో లోపం విషయంలో క్యూను ఉపయోగిస్తుంది 1000 సెకన్ల వరకు సమయం ముగిసిన సమయంలో ఘాతాంక పెరుగుదలతో:

func DefaultControllerRateLimiter() RateLimiter {
  return NewMaxOfRateLimiter(
  NewItemExponentialFailureRateLimiter(5*time.Millisecond, 1000*time.Second),
  // 10 qps, 100 bucket size.  This is only for retry speed and its only the overall factor (not per item)
  &BucketRateLimiter{Limiter: rate.NewLimiter(rate.Limit(10), 100)},
  )
}

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

సంభావ్య సమయ వ్యవధిని తగ్గించడానికి మాకు చాలా సులభంగా మరియు నొప్పిలేకుండా అనుమతించే ఏకైక ఎంపిక గరిష్ట సమయం ముగిసే పరిమితితో మా ఎక్స్‌టర్నల్-రిసైజర్ వెర్షన్‌ను ఉపయోగించడం. 5 సెకన్లలో:

workqueue.NewItemExponentialFailureRateLimiter(5*time.Millisecond, 5*time.Second)

డిస్క్‌ల ఆఫ్‌లైన్ రీసైజ్ అనేది అన్ని క్లౌడ్ ప్రొవైడర్‌ల నుండి త్వరలో అదృశ్యమయ్యే త్రోబాక్ అయినందున, అత్యవసరంగా చర్చను ప్రారంభించడం మరియు బాహ్య-పరిమాణం మార్చడం అవసరం అని మేము భావించలేదు.

ఉపయోగించడం ఎలా ప్రారంభించాలి?

డ్రైవర్‌కు కుబెర్నెట్స్ వెర్షన్ 1.15 మరియు అంతకంటే ఎక్కువ మద్దతు ఉంది. డ్రైవర్ పని చేయడానికి, ఈ క్రింది అవసరాలను తీర్చాలి:

జెండా --allow-privileged విలువకు సెట్ చేయబడింది true API సర్వర్ మరియు kubelet కోసం;
చేర్చబడింది --feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true API సర్వర్ మరియు kubelet కోసం;
మౌంట్ ప్రచారం (మౌంట్ ప్రచారం) క్లస్టర్‌లో తప్పనిసరిగా ప్రారంభించబడాలి. డాకర్‌ని ఉపయోగిస్తున్నప్పుడు, షేర్డ్ మౌంట్‌లను అనుమతించడానికి డెమోన్ తప్పనిసరిగా కాన్ఫిగర్ చేయబడాలి.

సంస్థాపనకు అవసరమైన అన్ని దశలు READMEలో వివరించబడింది. ఇన్‌స్టాలేషన్‌లో మానిఫెస్ట్‌ల నుండి కుబెర్నెట్స్‌లో వస్తువులను సృష్టించడం ఉంటుంది.

డ్రైవర్ పని చేయడానికి మీకు ఈ క్రిందివి అవసరం:

మానిఫెస్ట్‌లో డైరెక్టరీ ఐడెంటిఫైయర్‌ను పేర్కొనండి (folder-id) Yandex.Cloud (డాక్యుమెంటేషన్ చూడండి);
Yandex.Cloud APIతో పరస్పర చర్య చేయడానికి, CSI డ్రైవర్ సేవా ఖాతాను ఉపయోగిస్తుంది. మానిఫెస్ట్‌లో, సీక్రెట్ తప్పనిసరిగా పాస్ చేయాలి అధీకృత కీలు సేవా ఖాతా నుండి. డాక్యుమెంటేషన్‌లో వివరించబడింది, సేవా ఖాతాను ఎలా సృష్టించాలి మరియు కీలను ఎలా పొందాలి.

మొత్తం మీద - ప్రయత్నించండి, మరియు మేము అభిప్రాయాన్ని స్వీకరించడానికి సంతోషిస్తాము మరియు కొత్త సమస్యలుమీకు ఏవైనా సమస్యలు ఎదురైతే!

మరింత మద్దతు

తత్ఫలితంగా, మేము ఈ CSI డ్రైవర్‌ను గోలో సరదాగా రాయాలనే గొప్ప కోరికతో కాకుండా కంపెనీలో అత్యవసర అవసరం కారణంగా అమలు చేసామని గమనించదలిచాము. మా స్వంత అమలును నిర్వహించడం మాకు ఆచరణాత్మకంగా కనిపించడం లేదు, కాబట్టి Yandex ఆసక్తిని ప్రదర్శిస్తే మరియు డ్రైవర్‌కు మద్దతుని కొనసాగించాలని నిర్ణయించుకుంటే, రిపోజిటరీని వారికి బదిలీ చేయడానికి మేము సంతోషిస్తాము.

అదనంగా, Yandex బహుశా దాని నిర్వహించబడే కుబెర్నెటెస్ క్లస్టర్‌లో CSI డ్రైవర్ యొక్క స్వంత అమలును కలిగి ఉంది, దీనిని ఓపెన్ సోర్స్‌లో విడుదల చేయవచ్చు. మేము ఈ డెవలప్‌మెంట్ ఎంపికను అనుకూలమైనదిగా కూడా చూస్తాము - సంఘం నిరూపితమైన డ్రైవర్‌ను సేవా ప్రదాత నుండి ఉపయోగించగలదు మరియు మూడవ పక్ష కంపెనీ నుండి కాదు.

PS

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

మూలం: www.habr.com

Yandex.Cloud కోసం Kubernetesలో CSI డ్రైవర్‌ను అభివృద్ధి చేయడంలో మా అనుభవం