ፍላንት ለኩበርኔትስ ክፍት ምንጭ መሳሪያዎች በመልቀቅ አስተዋጾውን እያሰፋ መሆኑን ስንገልጽ በደስታ ነው።
ነገር ግን ወደ ትግበራ ዝርዝሮች ከመቀጠልዎ በፊት, Yandex ቀድሞውኑ አገልግሎት ሲኖረው ይህ ለምን እንደሚያስፈልግ ጥያቄውን እንመልስ
መግቢያ
ይህ ለምን ሆነ?
በኩባንያችን ውስጥ ኩበርኔትስን በምርት ውስጥ ከተጠቀምንበት ጊዜ ጀምሮ (ማለትም ለብዙ ዓመታት) የራሳችንን መሳሪያ (ዴክሃውስ) እያዘጋጀን ነበር ፣ በነገራችን ላይ በቅርቡ እንደ ክፍት ምንጭ ፕሮጀክት ለማቅረብ አቅደናል ። . በእሱ እርዳታ ሁሉንም ክላስተሮቻችንን አንድ ወጥ በሆነ መልኩ እናዋቅራለን እና እናዋቅራለን፣ እና በአሁኑ ጊዜ ከ100 በላይ የሚሆኑት በተለያዩ የሃርድዌር ውቅሮች እና በሁሉም የሚገኙ የደመና አገልግሎቶች አሉ።
የዴክ ሃውስን የሚጠቀሙ ዘለላዎች ለስራ አስፈላጊ የሆኑ ሁሉም ክፍሎች አሏቸው፡- ሚዛን ሰጭዎች፣ ምቹ በሆኑ ገበታዎች መከታተል፣ መለኪያዎች እና ማንቂያዎች፣ ሁሉንም ዳሽቦርዶች ለመድረስ የተጠቃሚ ማረጋገጫ በውጫዊ አቅራቢዎች እና የመሳሰሉት። እንዲህ ዓይነቱን "የተጨመረው" ክላስተር በሚተዳደር መፍትሄ ውስጥ መጫን ምንም ፋይዳ የለውም, ምክንያቱም ይህ ብዙውን ጊዜ የማይቻል ነው ወይም ግማሹን ክፍሎች ማሰናከል አስፈላጊ ነው.
NB: ይህ የእኛ ተሞክሮ ነው፣ እና እሱ በጣም የተለየ ነው። ሁሉም ዝግጁ የሆኑ መፍትሄዎችን ከመጠቀም ይልቅ የኩበርኔትስ ስብስቦችን በራሳቸው ማሰማራት እንዳለበት በምንም መንገድ አንጠቁም። በነገራችን ላይ Kubernetes ን ከ Yandex ለማስኬድ እውነተኛ ልምድ የለንም እና በዚህ ጽሑፍ ውስጥ የዚህን አገልግሎት ምንም ዓይነት ግምገማ አንሰጥም.
ምንድን ነው እና ለማን?
ስለዚህ ፣ በ Kubernetes ውስጥ ስለ ማከማቻ ዘመናዊ አቀራረብ አስቀድመን ተናግረናል-
በአሁኑ ጊዜ ብዙ ትላልቅ የደመና አገልግሎት አቅራቢዎች የደመና ዲስኮችን በ Kubernetes ውስጥ ቀጣይነት ያለው የድምጽ መጠን ለመጠቀም ሾፌሮችን አዘጋጅተዋል። አቅራቢው እንደዚህ አይነት አሽከርካሪ ከሌለው, ነገር ግን ሁሉም አስፈላጊ ተግባራት በኤፒአይ በኩል ይሰጣሉ, ከዚያ ምንም ነገር ሾፌሩን እራስዎ ከመተግበሩ አይከለክልዎትም. በ Yandex.Cloud የተከሰተው ይሄ ነው።
ለልማት መሰረት አድርገን ነው የወሰድነው Operation
የረጅም ጊዜ ስራዎችን ሁኔታ ለመከታተል (ለምሳሌ አዲስ ዲስክ መፍጠር). ከYandex.Cloud API ጋር ለመገናኘት ተጠቀም
የተከናወነው ሥራ ውጤት
ትግበራ
ዋና ዋና ባህሪዎች ፡፡
በአሁኑ ጊዜ አሽከርካሪው የሚከተሉትን ተግባራት ይደግፋል:
- በክላስተር ውስጥ ባሉ አንጓዎች ቶፖሎጂ መሠረት በሁሉም የክላስተር ዞኖች ውስጥ ዲስኮች ማዘዝ;
- ቀደም ሲል የታዘዙ ዲስኮችን ማስወገድ;
- ከመስመር ውጭ የዲስኮች መጠን (Yandex.Cloud
አትደግፉ ወደ ቨርቹዋል ማሽኑ የተጫኑትን ዲስኮች መጨመር). በተቻለ መጠን ህመም አልባ ለማድረግ አሽከርካሪው እንዴት መቀየር እንዳለበት መረጃ ለማግኘት ከታች ይመልከቱ።
ለወደፊቱ, የዲስክ ቅጽበተ-ፎቶዎችን ለመፍጠር እና ለማጥፋት ድጋፍን ተግባራዊ ለማድረግ አቅደናል.
ዋናው ችግር እና እንዴት ማሸነፍ እንደሚቻል
በ Yandex.Cloud API ውስጥ ዲስኮችን በእውነተኛ ጊዜ የመጨመር ችሎታ አለመኖር ለ PV (የቋሚ መጠን) የመጠን ማስተካከያ ሥራን የሚያወሳስብ ውስንነት ነው-በዚህ ሁኔታ ዲስኩን የሚጠቀም የመተግበሪያ ፖድ ማቆም አስፈላጊ ነው ፣ እና ይሄ የእረፍት ጊዜ መተግበሪያዎችን ሊያስከትል ይችላል.
እንደ 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 ጋር አይገናኝም፣ ነገር ግን በጎን መኪና ኮንቴይነሮች ለተላኩለት የጂአርፒሲ ጥሪዎች ብቻ ምላሽ ይሰጣል። የቅርብ ጊዜ
እየተገነቡ ነው። በኩበርኔትስ ማህበረሰብ.
በእኛ ሁኔታ (CSI ፕለጊን) ፣ ዲስኩን የመጨመር ተግባር ይህንን ይመስላል።
- የgRPC ጥሪ እንቀበላለን።
ControllerExpandVolume
; - ዲስኩን በኤፒአይ ውስጥ ለመጨመር እየሞከርን ነው, ነገር ግን ዲስኩ ስለተጫነ ቀዶ ጥገናውን ማከናወን የማይቻልበት ሁኔታ ላይ ስህተት እንቀበላለን;
- የዲስክ መለያውን በካርታው ውስጥ እናከማቻለን, ይህም የመጨመር ክዋኔው መከናወን ያለበትን ዲስኮች ይዟል. ከታች, በአጭሩ, ይህንን ካርታ እንደ እንጠራዋለን
volumeResizeRequired
; - ዲስኩን የሚጠቀመውን ፖድ በእጅ ያስወግዱት. ኩበርኔትስ እንደገና ያስጀምረዋል። ዲስኩ ለመሰካት ጊዜ እንዳይኖረው (
ControllerPublishVolume
) ለመጫን በሚሞከርበት ጊዜ የመጨመር ሥራውን ከማጠናቀቅዎ በፊት የተሰጠው ዲስክ አሁንም እንደገባ እናረጋግጣለን።volumeResizeRequired
እና ስህተት መመለስ; - የሲኤስአይ ሹፌሩ የመጠን ማስተካከያውን እንደገና ለማስፈጸም ይሞክራል። ክዋኔው ስኬታማ ከሆነ ዲስኩን ያስወግዱት።
volumeResizeRequired
; - ምክንያቱም የዲስክ መታወቂያ ጠፍቷል
volumeResizeRequired
,ControllerPublishVolume
በተሳካ ሁኔታ ያልፋል, ዲስኩ ተጭኗል, ፖድ ይጀምራል.
ሁሉም ነገር በቂ ቀላል ይመስላል, ግን እንደ ሁልጊዜም ወጥመዶች አሉ. ዲስኮችን ያሰፋዋል
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+ ደቂቃዎች እንዲራዘም ሊያደርግ ይችላል, ስለዚህም, ተዛማጅ ፖድ አይገኝም.
የመቀነስ ጊዜያችንን በቀላሉ እና ያለ ህመም እንድንቀንስ የፈቀደልን ብቸኛው አማራጭ የኛን የውጭ መጠን ማስተካከያ ከፍተኛ የጊዜ ገደብ መጠቀም ነው።
workqueue.NewItemExponentialFailureRateLimiter(5*time.Millisecond, 5*time.Second)
ከመስመር ውጭ የዲስክ መጠን መቀየር ከሁሉም የደመና አቅራቢዎች በቅርብ ጊዜ ውስጥ የሚጠፋ ውርወራ ስለሆነ ውይይት መጀመር እና ውጫዊ ሪሴዘርን ማስተካከል አስፈላጊ እንደሆነ አልቆጠርንም።
መጠቀም እንዴት ይጀምራል?
አሽከርካሪው በ Kubernetes ስሪት 1.15 እና ከዚያ በላይ ይደገፋል። አሽከርካሪው እንዲሰራ የሚከተሉት መስፈርቶች መሟላት አለባቸው።
- ሰንደቅ
--allow-privileged
ወደ ዋጋ ተዘጋጅቷልtrue
ለኤፒአይ አገልጋይ እና kubelet; - ተካትቷል።
--feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true
ለኤፒአይ አገልጋይ እና kubelet; - ተራራ ስርጭት (
ተራራ ስርጭት ) በክላስተር ላይ መንቃት አለበት። Docker በሚጠቀሙበት ጊዜ ዴሞን የጋራ መጋጠሚያዎችን ለመፍቀድ መዋቀር አለበት።
ለመጫኑ ሁሉም አስፈላጊ ደረጃዎች
አሽከርካሪው እንዲሰራ የሚከተሉትን ያስፈልግዎታል:
- በአንጸባራቂው ውስጥ የማውጫ መለያውን ይግለጹ (
folder-id
Yandex.Cloud (ሰነዶችን ይመልከቱ ); - ከ Yandex.Cloud API ጋር መስተጋብር ለመፍጠር የCSI ነጂው የአገልግሎት መለያ ይጠቀማል። በአንጸባራቂው ውስጥ ምስጢር መተላለፍ አለበት።
የተፈቀዱ ቁልፎች ከአገልግሎት መለያው. በሰነዱ ውስጥተገል describedል የአገልግሎት መለያ እንዴት መፍጠር እና ቁልፎችን ማግኘት እንደሚቻል።
ሁሉም በሁሉም -
ተጨማሪ ድጋፍ
በውጤቱም፣ ይህንን የሲኤስአይ ሹፌር ተግባራዊ ያደረግነው በ Go ውስጥ ማመልከቻዎችን ለመጻፍ ካለው ከፍተኛ ፍላጎት ሳይሆን በድርጅቱ ውስጥ ባለው አጣዳፊ ፍላጎት መሆኑን ማስተዋል እንፈልጋለን። የራሳችንን አተገባበር ማቆየት ለእኛ ተግባራዊ አይመስልም, ስለዚህ Yandex ፍላጎት ካሳየ እና ነጂውን መደገፉን ለመቀጠል ከወሰነ, ማከማቻውን ወደ እነርሱ ለማስተላለፍ ደስተኞች ነን.
በተጨማሪም Yandex ምናልባት በክፍት ምንጭ ውስጥ ሊለቀቅ በሚችለው በሚተዳደረው የኩበርኔትስ ክላስተር ውስጥ የ CSI ሾፌር የራሱ አተገባበር አለው። ይህንን የልማት አማራጭ እንደ አዋጭ ነው የምንመለከተው - ህብረተሰቡ ከሶስተኛ ወገን ኩባንያ ሳይሆን ከአገልግሎት ሰጪው የተረጋገጠ አሽከርካሪ መጠቀም ይችላል።
PS
በብሎጋችን ላይ ያንብቡ፡-
- «
ለ Kubernetes ማከማቻ የድምጽ መጠን ተሰኪዎች፡ ከFlexvolume እስከ CSI "; - «
የመያዣ ማከማቻ በይነገጽን እንረዳለን (በኩበርኔትስ ብቻ ሳይሆን) "; - «
የኩበርኔትስ ክላስተር ለማዘጋጀት ቀላል እና ምቹ ነው? አድዶን ኦፕሬተርን ማስታወቅ "; - «
Kubernetes ማስፋፋት እና ማሟያ (የግምገማ እና የቪዲዮ ዘገባ) ».
ምንጭ: hab.com