የውሂብ ጎታ ስብስቦችን ለማስተዳደር በኩበርኔትስ ውስጥ ኦፕሬተር። ቭላዲላቭ ክሊሜንኮ (አልቲኒቲ፣ 2019)

ሪፖርቱ በኩበርኔትስ ውስጥ ኦፕሬተርን ለማዳበር ፣ የሕንፃውን ንድፍ እና መሰረታዊ የአሠራር መርሆችን ለመቅረጽ በተግባራዊ ጉዳዮች ላይ ያተኮረ ነው።

በሪፖርቱ የመጀመሪያ ክፍል ላይ እንመለከታለን፡-

• በኩበርኔትስ ውስጥ ኦፕሬተር ምንድን ነው እና ለምን ያስፈልጋል;
• ኦፕሬተሩ ውስብስብ ስርዓቶችን እንዴት በትክክል ማስተዳደርን ቀላል ያደርገዋል;
• ኦፕሬተሩ የሚችለውን እና ኦፕሬተሩ የማይችለውን.

በመቀጠል, ስለ ኦፕሬተሩ ውስጣዊ መዋቅር ወደ መወያየት እንሂድ. የኦፕሬተሩን አርክቴክቸር እና አሠራር ደረጃ በደረጃ አስቡበት። በዝርዝር እንመርምር፡-

• በኦፕሬተሩ እና በኩበርኔትስ መካከል ያለው ግንኙነት;
• ኦፕሬተሩ ምን ተግባራትን እንደሚፈጽም እና ወደ ኩበርኔትስ ምን እንደሚወክለው.

በ Kubernetes ውስጥ ሻርዶችን እና የውሂብ ጎታ ቅጂዎችን ማስተዳደርን ያስቡበት።
በመቀጠል፣ የውሂብ ማከማቻ ጉዳዮችን እንነጋገራለን፡-

• ከኦፕሬተር እይታ ከቋሚ ማከማቻ ጋር እንዴት እንደሚሠራ;
• የአካባቢ ማከማቻ አጠቃቀም ችግሮች።

በሪፖርቱ የመጨረሻ ክፍል የመተግበሪያውን ተግባራዊ ምሳሌዎች እንመለከታለን ክሊክ ሃውስ ኦፕሬተር በአማዞን ወይም በጎግል ክላውድ አገልግሎት። ሪፖርቱ በኦፕሬተሩ ለ ClickHouse ልማት እና የስራ ልምድ ምሳሌ ላይ የተመሠረተ ነው።

ቪዲዮ

ስሜ ቭላዲላቭ ክሊሜንኮ ነው። ዛሬ ኦፕሬተርን በማዘጋጀት እና በማንቀሳቀስ ስለ ልምዳችን ማውራት ፈልጌ ነበር ፣ እና ይህ የውሂብ ጎታ ስብስቦችን ለማስተዳደር ልዩ ኦፕሬተር ነው። ለምሳሌ ClickHouse-ከዋኝ የ ClickHouse ክላስተርን ለማስተዳደር።

ስለ ኦፕሬተር እና ክሊክ ሃውስ የመናገር እድል ለምን ይኖረናል?

• ClickHouseን እንደግፋለን እና እናዳብራለን።
• በአሁኑ ጊዜ፣ ለክሊክ ሃውስ ልማት ቀስ በቀስ የበኩላችንን አስተዋጽኦ ለማድረግ እየሞከርን ነው። እና እኛ በ ClickHouse ውስጥ ከተደረጉ ለውጦች መጠን አንፃር ከ Yandex በኋላ ሁለተኛው ነን።
• ለ ClickHouse ሥነ ምህዳር ተጨማሪ ፕሮጀክቶችን ለመስራት እየሞከርን ነው።

ከእነዚህ ፕሮጀክቶች ውስጥ ስለ አንዱ ማውራት እፈልጋለሁ. ይህ ስለ ክሊክሃውስ-ኦፕሬተር ለኩበርኔትስ ነው።

በሪፖርቴ ውስጥ ሁለት ርዕሰ ጉዳዮችን መንካት እፈልጋለሁ።

• የመጀመሪያው ርዕስ የኛ ClickHouse ዳታቤዝ ኦፕሬተር በኩበርኔትስ እንዴት እንደሚሰራ ነው።
• ሁለተኛው ርዕስ ማንኛውም ኦፕሬተር እንዴት እንደሚሰራ ማለትም ከኩበርኔትስ ጋር እንዴት እንደሚገናኝ ነው.

ሆኖም፣ እነዚህ ሁለት ጥያቄዎች በሪፖርቴ ጊዜ ሁሉ ይገናኛሉ።

እኔ ለማለት የፈለግኩትን ለመስማት ፍላጎት ያለው ማን ነው?

• በጣም የሚስቡት ኦፕሬተሮችን የሚበዘብዙ ይሆናሉ.
• ወይም በውስጡ እንዴት እንደሚሰራ ለመረዳት, ኦፕሬተሩ ከ Kubernetes ጋር እንዴት እንደሚገናኝ እና ምን አይነት ወጥመዶች ሊታዩ እንደሚችሉ ለመረዳት የራሳቸውን ለመሥራት ለሚፈልጉ.

ዛሬ የምንወያይበትን በደንብ ለመረዳት ኩበርኔትስ እንዴት እንደሚሰራ ማወቅ እና በCloud ኮምፒውተር ላይ መሰረታዊ ዳራ ቢኖረን ጥሩ ነው።

ClickHouse ምንድን ነው? ይህ በመስመር ላይ የትንታኔ መጠይቆች ሂደት ውስጥ የተወሰኑ ነገሮች ያለው የአምድ ዳታቤዝ ነው። እና ሙሉ በሙሉ ክፍት ምንጭ ነው.

እና ማወቅ ያለብን ሁለት ነገሮችን ብቻ ነው። ይህ የመረጃ ቋት መሆኑን ማወቅ አለብህ፣ስለዚህ የምነግርህ ነገር ለማንኛውም የውሂብ ጎታ ተፈጻሚ ይሆናል። እና የ ClickHouse DBMS ሚዛኖች በጣም ጥሩ መሆናቸው ልኬቱን ወደ መስመራዊ ያደርገዋል። እና ስለዚህ፣ የክላስተር ሁኔታ ለ ClickHouse ተፈጥሯዊ ሁኔታ ነው። እና በኩበርኔትስ ውስጥ የክሊክሃውስ ክላስተርን እንዴት ማገልገል እንዳለብን ለመወያየት በጣም ፍላጎት አለን።

ለምን እዚያ ያስፈልገዋል? ለምን በራሳችን መስራቱን መቀጠል አንችልም? እና መልሶች በከፊል ቴክኒካዊ እና ከፊል ድርጅታዊ ናቸው.

• በተግባር ፣ እኛ ብዙ እና ብዙ ጊዜ በትልልቅ ኩባንያዎች ውስጥ ሁሉም አካላት ቀድሞውኑ በኩበርኔትስ ውስጥ ያሉበት ሁኔታ ያጋጥመናል። የውሂብ ጎታዎች ውጭ ይቆዩ።
• እና ብዙ እና ብዙ ጊዜ ጥያቄው ይጠየቃል: "ውስጥ ሊቀመጥ ይችላል?". ስለዚህ ትላልቅ ኩባንያዎች የመረጃ መጋዘኖቻቸውን በፍጥነት ማስተዳደር እንዲችሉ ከፍተኛውን የአመራር ውህደት ለማምረት እየሞከሩ ነው.
• እና ይሄ በተለይ በአዲስ ቦታ ላይ ተመሳሳይ ነገር ለመድገም ከፍተኛውን እድል ከፈለጉ ያግዛል ይህም ከፍተኛው ተንቀሳቃሽነት ነው.

ምን ያህል ቀላል ወይም ከባድ ነው? ይህ በእርግጥ በእጅ ሊሠራ ይችላል. ግን ይህ በጣም ቀላል አይደለም ፣ ምክንያቱም Kubernetes እራሱን የማስተዳደር ውስብስብነት እንጨምራለን ፣ ግን በተመሳሳይ ጊዜ የ ClickHouse ልዩ ነገሮች ተጭነዋል። እና እንደዚህ አይነት ስብስብ ይወጣል.

እና ሁሉም በአንድ ላይ ፣ ይህ በትክክል ለማስተዳደር በጣም አስቸጋሪ እየሆነ የመጣውን ትልቅ የቴክኖሎጂ ስብስብ ይሰጣል ፣ ምክንያቱም ኩበርኔትስ የዕለት ተዕለት ጉዳዮቹን ወደ ሥራ ስለሚያመጣ እና ClickHouse ጉዳዮቹን ወደ ዕለታዊ ሥራው ያመጣል። በተለይም ብዙ ClickHouses ካሉን እና ከእነሱ ጋር አንድ ነገር ያለማቋረጥ ማድረግ አለብን።

ከተለዋዋጭ ውቅረት ጋር ClickHouse በDevOps ላይ የማያቋርጥ ጭነት የሚፈጥሩ በጣም ብዙ ቁጥር ያላቸው ጉዳዮች አሉት።

• በ ClickHouse ውስጥ የሆነ ነገር መለወጥ ስንፈልግ፣ ለምሳሌ ቅጂ፣ ሻርድ ጨምር፣ ከዚያ አወቃቀሩን ማስተዳደር አለብን።
• ከዚያ የዳታውን እቅድ ይቀይሩ፣ ምክንያቱም ClickHouse የተወሰነ የሻርዲንግ ዘዴ አለው። እዚያም የውሂቡን እቅድ ማውጣት, አወቃቀሮችን መዘርጋት አስፈላጊ ነው.
• ክትትልን ማዘጋጀት ያስፈልግዎታል.
• የምዝግብ ማስታወሻዎች ስብስብ ለአዲስ ሻርዶች፣ ለአዲስ ቅጂዎች።
• ማገገሚያውን ይንከባከቡ.
• እና እንደገና አስጀምር.

በሥራ ላይ ማመቻቸት የምፈልጋቸው እነዚህ መደበኛ ሥራዎች ናቸው።

Kubernetes እራሱ በስራ ላይ በጣም ይረዳል, ነገር ግን በመሠረታዊ የስርዓት ነገሮች ላይ.

ኩበርኔትስ እንደሚከተሉት ያሉ ነገሮችን በማመቻቸት እና በራስ ሰር በማዘጋጀት ጥሩ ነው።

• መልሶ ማግኘት.
• እንደገና ጀምር.
• የማከማቻ አስተዳደር.

ያ ጥሩ ነው፣ ትክክለኛው አቅጣጫ ነው፣ ግን የውሂብ ጎታ ክላስተር እንዴት እንደሚሰራ ሙሉ በሙሉ ንክኪ የለውም።

የበለጠ እፈልጋለሁ, ሙሉውን የውሂብ ጎታ በኩበርኔትስ ውስጥ እንዲሰራልን እፈልጋለሁ.

እርስዎ የሚጫኑትን እንደ አንድ ትልቅ አስማታዊ ቀይ ቁልፍ ያለ ነገር ማግኘት እፈልጋለሁ እና እርስዎ መፍታት በሚፈልጉ የዕለት ተዕለት ተግባራት በጠቅላላው የህይወት ኡደት ውስጥ የተዘረጋ እና የሚቆይ ክላስተር አለዎት። የ ClickHouse ክላስተር በኩበርኔትስ።

እና ስራውን ለማመቻቸት የሚረዳ መፍትሄ ለማዘጋጀት ሞክረናል. ይህ የKubernetes ከ Altinity የ ClickHouse-ኦፕሬተር ነው።

ኦፕሬተር ዋናው ሥራው ሌሎች ፕሮግራሞችን ማስተዳደር ማለትም ሥራ አስኪያጅ ነው.

እና የባህሪ ቅጦችን ይዟል። ስለ ርዕሰ ጉዳዩ አካባቢ የተቀናጀ እውቀት ብለው ሊጠሩት ይችላሉ።

እና ዋናው ስራው ለዴቭኦፕስ ህይወትን ቀላል ማድረግ እና ማይክሮ ማኔጅመንትን በመቀነስ እሱ (ዴቭኦፕስ) ቀድሞውኑ በከፍተኛ ደረጃ ያስባል ፣ ማለትም እሱ (ዴቭኦፕስ) ማይክሮማኔጅ እንዳያደርግ ፣ ሁሉንም በእጅ እንዳያዋቅር። ዝርዝሮች.

እና ኦፕሬተሩ ብቻ ከማይክሮ ስራዎች ጋር የሚታገል እና DevOpsን የሚረዳ ሮቦት ረዳት ነው።

ኦፕሬተር ለምን ያስፈልጋል? እሱ በሁለት ዘርፎች የላቀ ነው።

• የ ClickHouse ልዩ ባለሙያተኛ በቂ ልምድ ከሌለው ፣ ግን ክሊክ ሃውስን ለመስራት ቀድሞውኑ አስፈላጊ ከሆነ ኦፕሬተሩ ክዋኔውን ያመቻቻል እና የክሊክ ሃውስ ክላስተርን ውስብስብ በሆነ ውቅር እንዲሰሩ ይፈቅድልዎታል ፣ ሁሉም በ ውስጥ እንዴት እንደሚሰራ ብዙ ዝርዝር ውስጥ አይገቡም። . አንተ ብቻ እሱን ከፍተኛ ደረጃ ተግባራትን መስጠት, እና ይሰራል.
• እና እራሱን በደንብ የሚያሳየው ሁለተኛው ተግባር ብዙ ቁጥር ያላቸው የተለመዱ ተግባራትን በራስ-ሰር ማድረግ አስፈላጊ በሚሆንበት ጊዜ ነው. ማይክሮ ተግባሮችን ከ sysadmins ያስወግዳል።

ይህ በጣም የሚያስፈልገው ጉዟቸውን ገና በጀመሩት ወይም ብዙ አውቶሜሽን መስራት በሚያስፈልጋቸው ነው።

በኦፕሬተር-ተኮር አቀራረብ እና በሌሎች ስርዓቶች መካከል ያለው ልዩነት ምንድነው? ሄልምም አለ. እንዲሁም ClickHouseን ለመጫን ይረዳል, የhelm ቻርቶችን መሳል ይችላሉ, ይህም ሙሉውን የ ClickHouse ክላስተር እንኳን ይጭናል. ታዲያ በኦፕሬተሩ እና ከተመሳሳይ ለምሳሌ በሄልም መካከል ያለው ልዩነት ምንድነው?

ዋናው መሠረታዊ ልዩነት Helm ስለ ጥቅል አስተዳደር ነው, እና ኦፕሬተሩ አንድ እርምጃ ወደፊት ይሄዳል. ይህ የጠቅላላው የሕይወት ዑደት ድጋፍ ነው. ይህ መጫን ብቻ አይደለም, እነዚህ የእለት ተእለት ስራዎችን ማቃለልን, ማረም, ማለትም በህይወት ዑደቱ ወቅት መደረግ ያለባቸው ነገሮች ሁሉ (አስፈላጊ ከሆነ, መወገድም) - ይህ ሁሉ በኦፕሬተሩ ይወሰናል. ሙሉውን የሶፍትዌር የሕይወት ዑደት በራስ ሰር ለመስራት እና ለማገልገል ይሞክራል። ይህ ከሌሎች ከሚቀርቡት መፍትሄዎች መሠረታዊ ልዩነቱ ነው.

የመግቢያው ክፍል ያ ነበር፣ እንቀጥል።

ኦፕሬተራችንን እንዴት እንገነባለን? የ ClickHouse ክላስተርን እንደ አንድ ግብአት ለማስተዳደር ጉዳዩን ለመቅረብ እየሞከርን ነው።

እዚህ በስዕሉ በግራ በኩል የግቤት ውሂብ አለን. ይህ YAML ከክላስተር ስፔስፊኬሽን ጋር ነው፣ እሱም በክላስተር በkubectl ወደ Kubernetes የሚያልፍ። እዚያም የእኛ ኦፕሬተር ያነሳዋል, አስማቱን ይሠራል. እና በውጤቱም, እንዲህ አይነት እቅድ እናገኛለን. ይህ በኩበርኔትስ ውስጥ የ ClickHouse ትግበራ ነው።

እና ከዚያም ኦፕሬተሩ እንዴት እንደሚሰራ, ምን አይነት የተለመዱ ተግባራትን መፍታት እንደሚቻል ቀስ በቀስ እንመለከታለን. የተለመዱ ተግባራትን ብቻ እንመለከታለን, ምክንያቱም የተወሰነ ጊዜ ስላለን. እና ኦፕሬተሩ ሊወስነው ስለሚችለው ነገር ሁሉ አይነገርም.

ከልምምድ እንጀምር። የእኛ ፕሮጀክት ሙሉ በሙሉ ክፍት ምንጭ ነው፣ ስለዚህ በ GitHub ላይ እንዴት እንደሚሰራ ማየት ይችላሉ። እና ከግምቶች መቀጠል ይችላሉ ፣ ለመጀመር ከፈለጉ ፣ ከዚያ በፈጣን ጅምር መመሪያ መጀመር ይችላሉ።

በዝርዝር ለመረዳት ከፈለጉ ሰነዶቹን በበለጠ ወይም ባነሰ መልኩ ለማቆየት እንሞክራለን.

በተግባራዊ ችግር እንጀምር። ሁላችንም ልንጀምር የምንፈልገው የመጀመሪያው ተግባር የመጀመሪያውን ምሳሌ በሆነ መንገድ ማስኬድ ነው። እንዴት እንደሚሰራ እንኳን ሳያውቅ በኦፕሬተር እርዳታ ClickHouseን እንዴት ማስጀመር ይቻላል? ማኒፌስቶ እየጻፍን ነው፣ ምክንያቱም ሁሉም ከ k8s ጋር የሚደረግ ግንኙነት በማንፀባረቅ በኩል ነው.

እንደዚህ ያለ ውስብስብ ማኒፌስቶ እዚህ አለ. በቀይ ያደምቅነው ትኩረት ልንሰጠው የሚገባን ነው። ማሳያ የሚባል ክላስተር እንዲፈጥር ኦፕሬተሩን እንጠይቃለን።

በአሁኑ ጊዜ እነዚህ መሠረታዊ ምሳሌዎች ናቸው. ማከማቻ ገና አልተገለጸም፣ ነገር ግን ትንሽ ቆይተን ወደ ማከማቻ እንመለሳለን። ለአሁን፣ የክላስተር እድገትን በተለዋዋጭነት እናስተውላለን።

ይህንን ማኒፌስቶ ፈጠርን። ወደ ኦፕሬተራችን እንመግባለን። ሰርቷል፣ አስማት አደረገ።

ኮንሶሉን እንመለከታለን. ሶስት አካላት ትኩረት የሚስቡ ናቸው - እነዚህ ፖድ ፣ ሁለት አገልግሎት-ሀ ፣ ስቴትፉል ሴት ናቸው።

ኦፕሬተሩ ሰርቷል, እና በትክክል ምን እንደፈጠረ ማየት እንችላለን.

እሱ እንደዚህ ያለ ነገር ይፈጥራል. ለእያንዳንዱ ቅጂ StatefulSet፣ Pod፣ ConfigMap፣ ConfigMap ለጠቅላላው ዘለላ አለን። የግድ አገልግሎቶች ወደ ክላስተር መግቢያ ነጥብ።

አገልግሎቶቹ ማእከላዊ የሎድ ባላንስ አገልግሎት ናቸው እና ለእያንዳንዱ ቅጂ፣ ለእያንዳንዱ ሻርድ ይቻላል።

የእኛ የመሠረት ክላስተር እንደዚህ ያለ ነገር ይመስላል። እሱ ከአንድ አንጓ ነው.

ወደ ፊት እንሂድ፣ ውስብስብ እናደርጋለን። ክላስተርን መቆራረጥ ያስፈልግዎታል.

ተግባሮቻችን እያደጉ ናቸው, ተለዋዋጭነት እየተጀመረ ነው. ሸርጣን መጨመር እንፈልጋለን. ልማቱን እንከተላለን። የእኛን ዝርዝር መግለጫ እንለውጣለን. ሁለት ጥራጊዎች እንደምንፈልግ እንጠቁማለን.

ከስርአቱ እድገት ጋር በተለዋዋጭነት የምናዳብረው ያው ፋይል ነው። ምንም ማከማቻ የለም, ማከማቻ ተጨማሪ ውይይት ይደረጋል, ይህ የተለየ ጉዳይ ነው.

የ YAML ኦፕሬተርን እንመግባለን እና ምን እንደሚፈጠር እንመለከታለን።

ኦፕሬተሩ አስቦ የሚከተሉትን አካላት ሠራ። አስቀድመን ሁለት ፖዶች፣ ሶስት አገልግሎቶች እና፣ በድንገት፣ 2 StatefulSets አሉን። ለምን 2 StatefulSets?

በሥዕላዊ መግለጫው ላይ እንደዚህ ነበር - ይህ የእኛ የመጀመሪያ ሁኔታ ነው ፣ አንድ ፖድ በነበረን ጊዜ።

እንዲህ ሆነ። እስካሁን ድረስ ሁሉም ነገር ቀላል ነው, ተባዝቷል.

እና ለምን StatefulSet ሁለት ሆነ? እዚህ በኩበርኔትስ ውስጥ Pods እንዴት እንደሚተዳደሩ የሚለውን ጥያቄ መፈተሽ እና መወያየት አለብን።

ከአብነት የPods ስብስብ እንዲሰሩ የሚያስችልዎ StatefulSet የሚባል ነገር አለ። እዚህ ያለው ቁልፍ ነገር አብነት ነው። እና በአንድ አብነት መሰረት ብዙ ፖዶችን በአንድ StatefulSet ውስጥ ማሄድ ይችላሉ። እና እዚህ ያለው ቁልፍ ሐረግ "አንድ አብነት ብዙ Pods" ነው.

እና መላውን ስብስብ ወደ አንድ StatefulSet በማሸግ ለማድረግ ታላቅ ​​ፈተና ነበር። ይሰራል, በውስጡ ምንም ችግር የለም. ግን አንድ ማስጠንቀቂያ አለ. የተለያዩ ክላስተርን ማለትም ከበርካታ የ ClickHouse ስሪቶች መሰብሰብ ከፈለግን ጥያቄዎቻችን ይጀምራሉ። አዎ፣ StatefulSet የሚንከባለል ማሻሻያ ማድረግ ይችላል፣ ግን እዚያ አዲስ ስሪት መልቀቅ ይችላሉ፣ በተመሳሳይ ጊዜ ከብዙ አንጓዎች በላይ መሞከር እንደሚያስፈልግዎ ያብራሩ።

ነገር ግን ስራውን ከገለፅነው እና ሙሉ ለሙሉ የተለያየ ክላስተር ለመስራት እንፈልጋለን እና ከአሮጌው ስሪት ወደ አዲስ ስሪት መቀየር አንፈልግም ነገር ግን በተለያዩ ስሪቶች ውስጥ ሁለቱንም የተለያየ ክላስተር መፍጠር እንፈልጋለን. የ ClickHouse እና ከተለያዩ ማከማቻ አንፃር። ለምሳሌ ፣በተለያዩ ዲስኮች ላይ ፣በዝግታ ፣በአጠቃላይ ፣የተለያየ ክላስተር ሙሉ በሙሉ ለመገንባት አንዳንድ ቅጂዎችን ለመስራት እንፈልጋለን። እና StatefulSet ከአንድ አብነት ወጥቶ ደረጃውን የጠበቀ መፍትሄ በማድረጉ ምክንያት ይህንን ለማድረግ ምንም መንገድ የለም።

ትንሽ ካሰብን በኋላ እንዲህ እንድናደርግ ተወሰነ። እያንዳንዱ ቅጂ በራሱ StatefulSet ውስጥ አለን። የዚህ መፍትሔ አንዳንድ ድክመቶች አሉ, ነገር ግን በተግባር ሁሉም ኦፕሬተሩን ሙሉ በሙሉ ያጠቃልላል. እና ብዙ ጥቅሞች አሉት. እኛ የምንፈልገውን ያህል ሙሉ በሙሉ እንደዚህ ያለ ስብስብ መገንባት እንችላለን ፣ ለምሳሌ ፣ ፍጹም የተለያዩ። ስለዚህ፣ አንድ ቅጂ ያላቸው ሁለት ሻርዶች ባሉንበት ክላስተር ውስጥ፣ 2 StatefulSets እና 2 Pods በትክክል ይኖረናል ምክንያቱም ከላይ በተጠቀሱት ምክንያቶች የተለያየ ክላስተር የመገንባት ችሎታ ስላለን ነው።

ወደ ተግባራዊ ተግባራት እንመለስ። በእኛ ክላስተር ውስጥ ተጠቃሚዎችን ማዋቀር ያስፈልገናል, ማለትም. በ Kubernetes ውስጥ የ ClickHouse ውቅር ማድረግ ያስፈልግዎታል። ኦፕሬተሩ ለዚህ ሁሉንም እድሎች ያቀርባል.

የምንፈልገውን በቀጥታ በ YAML መጻፍ እንችላለን። ሁሉም የማዋቀሪያ አማራጮች በቀጥታ ከዚህ YAML ወደ ClickHouse ውቅሮች ተቀርፀዋል፣ እነዚህም በክላስተር ውስጥ በሙሉ ይሰራጫሉ።

እንዲሁም እንደዚህ መጻፍ ይችላሉ. ይህ ለአብነት ነው። የይለፍ ቃሉ መመስጠር ይችላል። በፍፁም ሁሉም የ ClickHouse ውቅር አማራጮች ይደገፋሉ። እዚህ አንድ ምሳሌ ብቻ ነው።

የክላስተር ውቅር እንደ ConfigMap ተሰራጭቷል። በተግባር ፣ የ ConfigMap ዝመና ወዲያውኑ አይከሰትም ፣ ስለሆነም ትልቅ ክላስተር ካለ ፣ ከዚያ አወቃቀሩን የመግፋት ሂደት የተወሰነ ጊዜ ይወስዳል። ግን ይህ ሁሉ ለመጠቀም በጣም ምቹ ነው።

ስራውን እናወሳስበዋለን። ክላስተር በማደግ ላይ ነው። ውሂብ ማባዛት እንፈልጋለን። ማለትም፣ አስቀድመን ሁለት ሻርዶች አሉን፣ እያንዳንዳቸው አንድ ቅጂ፣ ተጠቃሚዎች ተዋቅረዋል። እያደግን ነው እና እንደገና ለመድገም እንፈልጋለን.

ለመድገም ምን ያስፈልገናል?

Zoo ጠባቂ እንፈልጋለን። በ ClickHouse ውስጥ፣ ማባዛት የተገነባው ZooKeeperን በመጠቀም ነው። የተለያዩ የ ClickHouse ቅጂዎች በየትኛው ክሊክ ሃውስ ላይ የውሂብ እገዳዎች እንዳሉ መግባባት እንዲኖራቸው ZooKeeper ያስፈልጋል።

ZooKeeper በማንኛውም ሰው መጠቀም ይችላል። አንድ ኢንተርፕራይዝ የውጪ ZooKeeper ካለው፣ ከዚያም መጠቀም ይቻላል። ካልሆነ ከማከማቻችን መጫን ይችላሉ። ይህን ሁሉ ነገር ቀላል የሚያደርግ ጫኝ አለ።

እና የአጠቃላይ ስርዓቱ የግንኙነት መርሃ ግብር እንደዚህ ይሆናል። ኩበርኔትስ እንደ መድረክ አለን። የ ClickHouse ኦፕሬተርን ያስፈጽማል. በሥዕሉ ላይ የገለጽኩት ZooKeeper እና ኦፕሬተሩ ከሁለቱም ClickHouse እና ZooKeeper ጋር ይገናኛል። ማለትም መስተጋብር ተገኝቷል።

እና ይህ ሁሉ ለ ClickHouse ውሂብን ወደ k8s በተሳካ ሁኔታ ለመድገም አስፈላጊ ነው።

አሁን ተግባሩን ራሱ እንይ፣ የማባዛት አንጸባራቂ እንዴት እንደሚመስል።

ወደ መግለጫችን ሁለት ክፍሎችን እንጨምራለን. የመጀመሪያው ZooKeeper የት እንደሚገኝ ነው፣ ይህም በኩበርኔትስ ውስጥም ሆነ ውጫዊ ሊሆን ይችላል። ይህ መግለጫ ብቻ ነው። እና ቅጂዎችን እናዛለን። እነዚያ። ሁለት ቅጂዎችን እንፈልጋለን. በጠቅላላው, በውጤቱ ላይ 4 ፓዶች ሊኖረን ይገባል. ስለ ማከማቻ እናስታውሳለን, ትንሽ ወደ ፊት ይመለሳል. ማከማቻ የተለየ ዘፈን ነው።

እንዲህ ነበር.

እንዲህ ይሆናል። ቅጂዎች ተጨምረዋል. 4ኛው አልመጣም, ብዙዎቹ ሊኖሩ እንደሚችሉ እናምናለን. እና ZooKeeper በጎን በኩል ተጨምሯል። ቅጦች ይበልጥ ውስብስብ እየሆኑ መጥተዋል.

እና የሚቀጥለውን ተግባር ለመጨመር ጊዜው አሁን ነው. ቀጣይነት ያለው ማከማቻ እንጨምራለን.

ለቋሚ ማከማቻ፣ የተለያዩ አማራጮች አለን።

በደመና አቅራቢ ውስጥ እየሄድን ከሆነ ለምሳሌ Amazon, Google ን በመጠቀም, የደመና ማከማቻን ለመጠቀም ትልቅ ፈተና አለ. በጣም ምቹ ነው, ጥሩ ነው.

እና ሁለተኛ አማራጭ አለ. በእያንዳንዱ መስቀለኛ መንገድ ላይ የአካባቢ ዲስኮች ሲኖረን ይህ ለአካባቢ ማከማቻ ነው። ይህ አማራጭ ለመተግበር በጣም ከባድ ነው, ግን በተመሳሳይ ጊዜ የበለጠ ውጤታማ ነው.

የደመና ማከማቻን በተመለከተ ምን እንዳለን እንይ።

ብቃቶች አሉ። ለማዋቀር በጣም ቀላል ነው። በቀላሉ ከደመና አቅራቢው እናዝዛለን እባክዎን እንደዚህ እና እንደዚህ ያለ አቅም ፣ እንደዚህ እና እንደዚህ ያለ ክፍል። ክፍሎች ራሳቸውን ችለው በአቅራቢዎች ይሳሉ።

እና ጉድለት አለ. ለአንዳንዶች ይህ የማይተች ጉድለት ነው። እርግጥ ነው, አንዳንድ የአፈፃፀም ተደራቢዎች ይኖራሉ. ለመጠቀም በጣም ምቹ, አስተማማኝ ነው, ነገር ግን በአፈፃፀም ውስጥ አንዳንድ እምቅ ድክመቶች አሉ.

እና ጀምሮ ClickHouse በአፈጻጸም ላይ ያተኩራል፣ የሚቻለውን ሁሉ ይጨምቃል ማለት ትችላለህ፣ ስለዚህ ብዙ ደንበኞች ከፍተኛውን አፈጻጸም ለመጭመቅ ይሞክራሉ።

እና ምርጡን ለማግኘት የአካባቢ ማከማቻ ያስፈልገናል።

Kubernetes በ Kubernetes ውስጥ የአካባቢ ማከማቻ ለመጠቀም ሶስት ማጠቃለያዎችን ያቀርባል። ይህ፡-

• ባዶ ዲር
• HostPath
• አካባቢያዊ

እንዴት እንደሚለያዩ፣ እንዴት እንደሚመሳሰሉ አስቡ።

በመጀመሪያ ፣ በሦስቱም አቀራረቦች ፣ ማከማቻ አለን - እነዚህ በተመሳሳይ አካላዊ k8s መስቀለኛ መንገድ ላይ የሚገኙ አካባቢያዊ ዲስኮች ናቸው። ግን አንዳንድ ልዩነቶች አሏቸው.

በጣም ቀላል በሆነው ማለትም ባዶ ዲር እንጀምር። በተግባር ምንድነው? በአካባቢያዊ ዲስክ ላይ ያለ አቃፊ መዳረሻ እንዲሰጠን የመያዣ ስርዓቱን (ብዙውን ጊዜ ዶከር) ከእኛ ዝርዝር መግለጫ የምንጠይቀው እኛ ነን።

በተግባር, ዶከር በራሱ መንገድ የሆነ ቦታ ጊዜያዊ አቃፊ ይፈጥራል, ረጅም ሃሽ ይለዋል. እና እሱን ለመድረስ በይነገጽ ያቀርባል።

ከአፈጻጸም አንፃር እንዴት ይሠራል? ይህ በአካባቢው ዲስክ ፍጥነት ይሰራል, ማለትም. ይህ ወደ የእርስዎ screw ሙሉ መዳረሻ ነው።

ግን ይህ ጉዳይ የራሱ ጉድለት አለው. በዚህ ጉዳይ ላይ ዘላቂነት በጣም አጠራጣሪ ነው. የመትከያው የመጀመሪያ እንቅስቃሴ ከእቃ መያዣዎች ጋር, የማያቋርጥ ጠፍቷል. Kubernetes በሆነ ምክንያት ይህንን ፖድ ወደ ሌላ ዲስክ ለማንቀሳቀስ ከፈለገ ውሂቡ ይጠፋል።

ይህ አቀራረብ ለሙከራዎች ጥሩ ነው, ምክንያቱም ቀድሞውኑ መደበኛውን ፍጥነት ያሳያል, ነገር ግን ይህ አማራጭ ለከባድ ነገር ተስማሚ አይደለም.

ስለዚህ, ሁለተኛ አቀራረብ አለ. ይህ hostPath ነው። የቀደመውን ስላይድ እና ይህንን ከተመለከቱ, አንድ ልዩነት ብቻ ነው ማየት የሚችሉት. የእኛ አቃፊ መትከያውን በቀጥታ ወደ Kubernetes መስቀለኛ መንገድ ትቶ ወጥቷል። እዚህ ትንሽ ፈጣን ነው። ውሂባችንን ለማከማቸት የምንፈልግበትን መንገድ በቀጥታ በአካባቢያዊ የፋይል ስርዓት ላይ እንጽፋለን.

ይህ ዘዴ ጥቅሞች አሉት. ይህ ቀድሞውንም እውነተኛ ዘላቂ፣ እና ክላሲክ ነው። በእኛ ዲስክ ላይ, ውሂብ ወደ አንዳንድ አድራሻ ይጻፋል.

ጉዳቶችም አሉ. ይህ የአስተዳደር ውስብስብነት ነው። የእኛ ኩበርኔትስ ፖዱን ወደ ሌላ አካላዊ መስቀለኛ መንገድ ማንቀሳቀስ ይፈልጉ ይሆናል። DevOps የሚጫወተው እዚህ ላይ ነው። በነዚህ ዱካዎች ላይ አንድ ነገር ወደተሰቀለበት እና በአንድ ጊዜ ከአንድ በላይ መስቀለኛ መንገድ እንዳይኖር እነዚህን ፓዶች ወደ እንደዚህ ያሉ አንጓዎች ብቻ ማንቀሳቀስ እንደሚችሉ ለመላው ስርዓቱ በትክክል ማስረዳት አለበት። በቂ ከባድ ነው።

በተለይም ለእነዚህ አላማዎች, ይህንን ሁሉ ውስብስብነት ለመደበቅ በኦፕሬተራችን ውስጥ አብነቶችን አዘጋጅተናል. እና እንዲህ ማለት ትችላለህ፡- "በአንድ አካላዊ መስቀለኛ መንገድ እና በእንደዚህ አይነት መንገድ የ ClickHouse አንድ ምሳሌ እንዲኖረኝ እፈልጋለሁ።"

ነገር ግን ይህ ፍላጎት ለእኛ ብቻ አይደለም, ስለዚህ የኩበርኔትስ ጨዋዎች እራሱ ሰዎች አካላዊ ዲስኮች ማግኘት እንደሚፈልጉ ይገነዘባሉ, ስለዚህ ሶስተኛ ደረጃ ይሰጣሉ.

አካባቢያዊ ይባላል። ከቀዳሚው ስላይድ በተግባር ምንም ልዩነት የለም። ቀደም ሲል ብቻ እነዚህን እንክብሎች ከኖድ ወደ መስቀለኛ መንገድ ማስተላለፍ እንደማንችል በእጃችን ማከናወን አስፈላጊ ነበር, ምክንያቱም በእንደዚህ አይነት እና በእንደዚህ አይነት መንገድ በአካባቢው አካላዊ ዲስክ ላይ መያያዝ አለባቸው, እና አሁን ይህ ሁሉ እውቀት በኩበርኔትስ እራሱ ውስጥ ተካትቷል. እና ለማዋቀር በጣም ቀላል ይሆናል።

ወደ ተግባራዊ ተግባራችን እንመለስ። ወደ YAML አብነት እንመለስ። እዚህ እውነተኛ ማከማቻ አለን። ወደዚህ ተመልሰናል። ክላሲክ VolumeClaim አብነት እንደ k8s አዘጋጅተናል። እና ምን አይነት ማከማቻ እንደምንፈልግ እንገልፃለን.

ከዚያ በኋላ k8s ማከማቻ ይጠይቃል። በ StatefulSet ውስጥ ለእኛ ይመድቡ። እና በመጨረሻ ፣ በ ClickHouse አጠቃቀም ላይ ይወጣል።

እንዲህ ዓይነት ዕቅድ ነበረን. የእኛ የማያቋርጥ ማከማቻ ቀይ ነበር፣ ይህም መደረግ እንዳለበት የሚጠቁም ይመስላል።

እና አረንጓዴ ይለወጣል. አሁን በk8s ክላስተር እቅድ ላይ ያለው ClickHouse ሙሉ በሙሉ ተጠናቅቋል። ሻርዶች፣ ቅጂዎች፣ ZooKeeper አሉን፣ በአንድ ወይም በሌላ መንገድ የሚተገበር እውነተኛ ዘላቂነት አለን:: ዕቅዱ ቀድሞውኑ ሙሉ በሙሉ ሥራ ላይ ውሏል።

መኖራችንን እንቀጥላለን። የእኛ ስብስብ እያደገ ነው። እና አሌክሲ አዲስ የ ClickHouse ስሪት እየሞከረ እና እየለቀቀ ነው።

አንድ ተግባራዊ ተግባር ይነሳል - አዲሱን የ ClickHouse ስሪት በእኛ ክላስተር ላይ ለመሞከር። እና በእርግጥ, ሁሉንም መልቀቅ አልፈልግም, አዲስ እትም በሩቅ ጥግ ላይ በአንድ ቅጂ ውስጥ ማስቀመጥ እፈልጋለሁ, ወይም ምናልባት አንድ አዲስ ስሪት ላይሆን ይችላል, ነገር ግን ሁለት በአንድ ጊዜ, ምክንያቱም ብዙ ጊዜ ስለሚወጡ.

ስለዚህ ጉዳይ ምን ማለት እንችላለን?

እዚህ እንደዚህ ያለ እድል አለን. እነዚህ የፖድ አብነቶች ናቸው። ቀለም መቀባት ይችላሉ, የእኛ ኦፕሬተር ሙሉ በሙሉ የተለያየ ክላስተር እንዲገነቡ ይፈቅድልዎታል. እነዚያ። ማዋቀር፣ በቡድን ካሉት ቅጂዎች ሁሉ ጀምሮ፣ በእያንዳንዱ የግል ቅጂ ያበቃል፣ የትኛውን ክሊክ ሃውስ እንፈልጋለን፣ የትኛውን ስሪት ማከማቻ እንፈልጋለን። እኛ በሚያስፈልገን መልኩ ክላስተርን ሙሉ በሙሉ ማዋቀር እንችላለን።

ትንሽ ወደ ውስጥ እንግባ። ከዚያ በፊት፣ ከ ClickHouse ልዩ ነገሮች ጋር በተያያዘ የ ClickHouse-operator እንዴት እንደሚሰራ ተነጋግረናል።

አሁን ማንኛውም ኦፕሬተር በአጠቃላይ እንዴት እንደሚሰራ እና ከ K8s ጋር እንዴት እንደሚገናኝ ጥቂት ቃላት ማለት እፈልጋለሁ.

ለመጀመር ከK8s ጋር ያለውን ግንኙነት አስቡበት። kubectl ስናመልከት ምን ይሆናል? በኤፒአይ በኩል፣ እቃዎቻችን በ etcd ውስጥ ይታያሉ።

ለምሳሌ, መሰረታዊ የኩበርኔትስ እቃዎች: ፖድ, ስቴትፉል ሴት, አገልግሎት እና የመሳሰሉት በዝርዝሩ ውስጥ.

ሆኖም ፣ ምንም አካላዊ ነገር እስካሁን እየተፈጠረ አይደለም። እነዚህ ነገሮች በክላስተር ውስጥ መሆን አለባቸው.

ተቆጣጣሪው የሚመጣው እዚህ ነው። ተቆጣጣሪው እነዚህን መግለጫዎች ተግባራዊ ሊያደርግ የሚችል ልዩ k8s አካል ነው. በአካል እንዴት እና ምን ማድረግ እንዳለበት ያውቃል. ኮንቴይነሮችን እንዴት እንደሚሰራ ያውቃል, አገልጋዩ እንዲሰራ እዚያ ምን ማዋቀር እንዳለበት.

እና ዕቃዎቻችንን በK8s ውስጥ ያስገባል።

ነገር ግን መስራት የምንፈልገው በፖድስ፣ StatefulSets ብቻ ሳይሆን፣ በአጠቃላይ አብሮ ለመስራት ClickHouseInstallation፣ ማለትም የ ClickHouse አይነት ነገር መፍጠር እንፈልጋለን። እስካሁን ድረስ እንዲህ ዓይነት ዕድል የለም.

ግን K8s ሌላ ጥሩ ነገር አለው። የእኛ ክላስተር ከፖድ እና StatefulSet የሚሰበሰብበት እንደዚህ ያለ ውስብስብ አካል የሆነ ቦታ እንዲኖረን እንፈልጋለን።

እና ለዚህ ምን መደረግ አለበት? በመጀመሪያ፣ ብጁ መገልገያ ፍቺ ወደ ቦታው ይገባል። ምንድን ነው? ይህ የK8 ዎች መግለጫ ወደ ፖድ ልንጨምር የምንፈልገው ሌላ የውሂብ አይነት እንዲኖርዎት ነው StatefulSet , በውስጡ ውስብስብ የሆነ ብጁ ምንጭ። ይህ የውሂብ መዋቅር መግለጫ ነው.

እንዲሁም በ kubectl apply በኩል ወደዚያ እንልካለን። ኩበርኔትስ በደስታ ወሰደው።

እና አሁን በእኛ ማከማቻ ውስጥ፣ በ etcd ውስጥ ያለው ነገር ClickHouseInstallation የሚባል ብጁ ግብዓት የመፃፍ እድል አለው።

አሁን ግን ሌላ ምንም ነገር አይሆንም። ይኸውም አሁን የተመለከትነውን የ YAML ፋይል ከሻርድ መግለጫ ጋር ከገለፅን እና “kubectl apply” ብንል ኩበርኔትስ ተቀብሎ ወዘተ ያስገባል እና “በጣም ጥሩ ነው ግን አላውቅም። ምን ማድረግ እንዳለበት. ClickHouseInstallationን እንዴት ማቆየት እንዳለብኝ አላውቅም።

በዚህ መሠረት ኩበርኔትስ አዲሱን የውሂብ አይነት እንዲያገለግል የሚረዳ ሰው እንፈልጋለን። በግራ በኩል ከክምችት ውሂብ አይነቶች ጋር የሚሰራ የአክሲዮን Kubernetes መቆጣጠሪያ አለን። እና በቀኝ በኩል ከብጁ የውሂብ አይነቶች ጋር መስራት የሚችል ብጁ መቆጣጠሪያ ሊኖረን ይገባል.

እና በሌላ መንገድ ኦፕሬተር ይባላል. እኔ በተለይ ለኩበርኔትስ እዚህ አውጥቼዋለሁ፣ ምክንያቱም ከK8s ውጭም ሊፈጸም ይችላል። በጣም ብዙ ጊዜ ፣ ​​በእርግጥ ፣ ሁሉም መግለጫዎች በኩበርኔትስ ውስጥ ይከናወናሉ ፣ ግን ምንም ነገር ከውጭ መቆምን የሚከለክለው የለም ፣ ስለሆነም እዚህ በልዩ ሁኔታ ይወጣል ።

እና አስቀድሞ፣ በተራው፣ ኦፕሬተር በመባል የሚታወቀው ብጁ ተቆጣጣሪ፣ ከ Kubernetes ጋር በኤፒአይ በኩል ይገናኛል። ከኤፒአይ ጋር እንዴት እንደሚገናኝ አስቀድሞ ያውቃል። እና እኛ ከብጁ መገልገያ ልንሰራው የምንፈልገውን ውስብስብ እቅድ እንዴት ተግባራዊ ማድረግ እንደሚቻል አስቀድሞ ያውቃል። ኦፕሬተሩ በትክክል የሚያደርገው ይህ ነው።

ኦፕሬተሩ እንዴት ነው የሚሰራው? እንዴት እንደሚሰራ ለማየት ትክክለኛውን ጎን እንይ. ኦፕሬተሩ ይህንን ሁሉ እንዴት እንደሚያከናውን እና ከ K8s ጋር ተጨማሪ መስተጋብር እንዴት እንደሚከናወን እናገኛለን ።

ኦፕሬተሩ ፕሮግራሙ ነው። እሷ ክስተት ተኮር ነች። ኦፕሬተሩ ኩበርኔትስ ኤፒአይን በመጠቀም ለክስተቶች ይመዘገባል። የኩበርኔትስ ኤፒአይ ለክስተቶች መመዝገብ የምትችልባቸው የመግቢያ ነጥቦች አሉት። እና በ K8s ውስጥ የሆነ ነገር ከተቀየረ, ከዚያ Kubernetes ለሁሉም ሰው ክስተቶችን ይልካል, ማለትም. ለዚህ ኤፒአይ ነጥብ የተመዘገቡ ማሳወቂያዎች ይደርሳቸዋል።

ኦፕሬተሩ ለክስተቶች ተመዝግቧል፣ እና አንድ ዓይነት ምላሽ ማድረግ አለበት። የእሱ ተግባር ለሚከሰቱ ክስተቶች ምላሽ መስጠት ነው.

ክስተቶች የሚመነጩት በአንዳንድ ዝማኔዎች ነው። የእኛ YAML ፋይል ከ ClickHouseInstallation መግለጫ ጋር ይመጣል። በ kubectl apply ወደ etcd ሄዷል። አንድ ክስተት እዚያ ሠርቷል፣ በውጤቱም ይህ ክስተት ወደ ClickHouse-operator መጣ። ኦፕሬተሩ ይህንን መግለጫ ተቀብሏል. እና አንድ ነገር ማድረግ አለበት. አንድ ዝማኔ ወደ ClickHouseInstallation ነገር ከመጣ፣እንግዲህ ክላስተርን ማዘመን አለብህ። እና የኦፕሬተሩ ተግባር ክላስተር ማዘመን ነው።

ምን እያደረገ ነው? በመጀመሪያ፣ በዚህ ማሻሻያ ምን እንደምናደርግ የድርጊት መርሃ ግብር ማዘጋጀት አለብን። ዝማኔዎች በጣም ትንሽ ሊሆኑ ይችላሉ, ማለትም. በ YAML አፈፃፀም ውስጥ ትንሽ ነገር ግን በክላስተር ላይ በጣም ትልቅ ለውጥ ሊያመጣ ይችላል። ስለዚህ ኦፕሬተሩ እቅድ ያወጣል, ከዚያም እሱ በጥብቅ ይከተላል.

እሱ ይጀምራል, በዚህ እቅድ መሰረት, ይህንን መዋቅር ወደ ውስጥ ለማፍላት ፖድ, አገልግሎቶችን, ማለትም. ዋና ሥራው የሆነውን ለማድረግ. በኩበርኔትስ ውስጥ የክሊክሃውስ ክላስተር እንደመገንባት ነው።

አሁን እንደዚህ አይነት አስደሳች ነገር እንነካ። ይህ በኩበርኔትስ እና በኦፕሬተሩ መካከል ያለው የኃላፊነት ክፍፍል ነው, ማለትም. Kubernetes ምን እንደሚሰራ, ኦፕሬተሩ ምን እንደሚሰራ እና እንዴት እርስ በርስ እንደሚገናኙ.

ኩበርኔትስ ለሥርዓት ነገሮች ተጠያቂ ነው, ማለትም. እንደ የስርዓተ-ወሰን ሊተረጎሙ ለሚችሉ መሠረታዊ ነገሮች ስብስብ. ኩበርኔትስ ፖድስን እንዴት እንደሚጀምር፣ እንዴት ኮንቴይነሮችን እንደገና ማስጀመር እንደሚቻል፣ ጥራዞችን እንዴት እንደሚሰካ፣ ከ ConfigMap ጋር እንዴት እንደሚሰራ፣ ማለትም እንዴት እንደሚሰራ ያውቃል። ስርዓት ተብሎ ሊጠራ የሚችል ማንኛውም ነገር.

ኦፕሬተሮች በርዕሰ ጉዳይ ላይ ይሰራሉ. እያንዳንዱ ኦፕሬተር የተሰራው ለርዕሰ-ጉዳዩ አካባቢ ነው. ለ ClickHouse አደረግን.

እና ኦፕሬተሩ ከርዕሰ-ጉዳዩ አንፃር በትክክል መስተጋብር ይፈጥራል ፣ ለምሳሌ ቅጂ ማከል ፣ እቅድ ማውጣት ፣ ክትትልን ማቋቋም። እንደዚህ ያለ መለያየት አለ.

ተጨማሪ ግልባጭ ድርጊት ስናደርግ ይህ የጭንቀት መለያየት እንዴት እንደሚከሰት የሚያሳይ ተግባራዊ ምሳሌን እንመልከት።

ስራው ወደ ኦፕሬተሩ ይመጣል - ቅጂ ለመጨመር. ኦፕሬተሩ ምን እየሰራ ነው? ኦፕሬተሩ አዲስ StatefulSet ማድረግ አስፈላጊ መሆኑን ያሰላል ፣ በዚህ ውስጥ እንደዚህ ያሉ እና እንደዚህ ያሉ አብነቶችን ፣ የይገባኛል ጥያቄን መግለጽ አስፈላጊ ነው።

ሁሉንም አዘጋጅቶ ወደ K8s አስተላልፏል። እሱ ConfigMap፣ StatefulSet፣ Volume እንደሚያስፈልገው ይናገራል። ኩበርኔትስ እየሰራ ነው። እሱ የሚሠራባቸውን መሠረታዊ ክፍሎችን ይሠራል.

እና ከዚያ ClickHouse-operator እንደገና ወደ ጨዋታ ይመጣል። እሱ ቀድሞውኑ የሆነ ነገር ማድረግ የሚችሉበት አካላዊ ፖድ አለው። እና ClickHouse-operator ከርዕሰ-ጉዳዩ አንፃር እንደገና ይሰራል። እነዚያ። በተለይ ClickHouse፣ አንድ ቅጂ በክላስተር ውስጥ ለማካተት፣ በመጀመሪያ፣ በዚህ ክላስተር ውስጥ ያለውን የውሂብ እቅድ ማዋቀር አለብዎት። እና፣ በሁለተኛ ደረጃ፣ ይህ አስተያየት በክትትል ውስጥ መካተት አለበት፣ ስለዚህም በግልፅ ፈልጎ ማግኘት ይችላል። ኦፕሬተሩ አስቀድሞ አዘጋጅቶታል።

እና ከዚያ በኋላ ብቻ ClickHouse ራሱ ወደ ጨዋታው ይመጣል፣ ማለትም። ሌላ ከፍተኛ ደረጃ አካል. እሱ አስቀድሞ የውሂብ ጎታ ነው። የራሱ ምሳሌ አለው፣ ቀጣዩ የተዋቀረ ቅጂ፣ እሱም ክላስተርን ለመቀላቀል ዝግጁ ነው።

ቅጂ ሲጨመር የአፈፃፀም እና የኃላፊነት መለያየት ሰንሰለቱ በቂ ርዝመት አለው.

ተግባራዊ ተግባሮቻችንን እንቀጥላለን. ክላስተር አስቀድሞ ካለ፣ ውቅሩን ማዛወር ይችላሉ።

ወደ ነባሩ xml ለማለፍ እንዲቻል ነው ያደረግነው፣ ይህም ClickHouse ይረዳል።

ClickHouseን ማስተካከል ትችላለህ። የዞን ማሰማራት የhostPathን፣ የአካባቢ ማከማቻን ሳብራራ የተናገርኩት ነው። የዞን ማሰማራትን በትክክል እንዴት ማድረግ እንደሚቻል ይህ ነው።

ቀጣዩ ተግባራዊ ተግባር ክትትል ነው.

የእኛ ክላስተር ከተቀየረ ክትትልን በየጊዜው ማዋቀር አለብን።

ሥዕላዊ መግለጫውን እንመልከት። አረንጓዴ ቀስቶችን እዚህ አስቀድመን ተመልክተናል. አሁን ቀይ ቀስቶችን እንይ. የእኛን ክላስተር መከታተል የምንፈልገው በዚህ መንገድ ነው። ከ ClickHouse ክላስተር እንዴት ሜትሪክስ ወደ Prometheus እና ከዚያም ወደ ግራፋና እንደሚገባ።

የመከታተል ችግር ምንድነው? ለምንድነው ይህ እንደ አንድ ዓይነት ስኬት የቀረበው? ችግሩ በተለዋዋጭ ሁኔታ ውስጥ ነው። አንድ ዘለላ ሲኖረን እና የማይንቀሳቀስ ከሆነ፣ አንዴ ክትትልን ማቀናበር ትችላላችሁ እና ከእንግዲህ አትቸገሩ።

ነገር ግን ብዙ ዘለላዎች ካሉን ወይም የሆነ ነገር በየጊዜው እየተለወጠ ከሆነ ሂደቱ ተለዋዋጭ ነው። እና ክትትልን በየጊዜው እንደገና ማዋቀር የሀብት እና ጊዜ ማባከን ነው; ሰነፍ እንኳን። ይህ በራስ-ሰር መደረግ አለበት። ችግሩ በሂደቱ ተለዋዋጭነት ላይ ነው. እና ኦፕሬተሩ ይህንን በደንብ በራስ-ሰር ያደርገዋል።

የእኛ ስብስብ እንዴት ሊዳብር ቻለ? መጀመሪያ ላይ እንዲህ ነበር.

ከዚያም እሱ እንደዚህ ነበር.

በመጨረሻ እንዲህ ሆነ።

እና ቁጥጥር በራስ-ሰር በኦፕሬተሩ ይከናወናል. ነጠላ የመግቢያ ነጥብ።

እና የኛ ክላስተር ህይወት በውስጣችን እንዴት እንደሚፈላ፣ በግራፋና ዳሽቦርድ ውስጥ ያለውን መውጫ ብቻ እንመለከታለን።

በነገራችን ላይ የግራፋና ዳሽቦርድ ከኦፕሬተራችን ጋር በቀጥታ በምንጭ ኮድ ተሰራጭቷል። መገናኘት እና መጠቀም ይችላሉ። ይህ ቅጽበታዊ ገጽ እይታ የተሰጠኝ በእኛ DevOps ነው።

ቀጥሎ የት መሄድ እንፈልጋለን? ይህ፡-

• የሙከራ አውቶማቲክን ያዳብሩ። ዋናው ተግባር የአዳዲስ ስሪቶችን በራስ-ሰር መሞከር ነው.
• እኛ ደግሞ ከ ZooKeeper ጋር ውህደቱን በራስ ሰር መስራት እንፈልጋለን። እና ከ ZooKeeper-operator ጋር ለመዋሃድ አቅዷል። እነዚያ። አንድ ኦፕሬተር ለ ZooKeeper ተጽፏል፣ እና ሁለቱ ኦፕሬተሮች የበለጠ ምቹ መፍትሄ ለመገንባት መዋሃድ መጀመራቸው ምክንያታዊ ነው።
• የበለጠ ውስብስብ የህይወት ምርመራዎችን ማድረግ እንፈልጋለን.
• በመንገዳችን ላይ የአብነት ውርስ እንዳለን በአረንጓዴ ገለጽኩ - ተከናውኗል፣ ማለትም በሚቀጥለው ኦፕሬተር መለቀቅ፣ የአብነት ውርስ ይኖረናል። ይህ ከቁራጮች ውስጥ ውስብስብ ውቅሮችን እንዲገነቡ የሚያስችልዎ ኃይለኛ መሳሪያ ነው.
• እና ውስብስብ ስራዎችን በራስ ሰር መስራት እንፈልጋለን. ዋናው ዳግመኛ-sharding ነው.

አንዳንድ መካከለኛ ውጤቶችን እናድርግ.

በውጤቱ ምን እናገኛለን? እና ዋጋ ያለው ነው ወይስ አይደለም? ዳታቤዙን ወደ Kubernetes ለመጎተት መሞከር እና ኦፕሬተሩን በአጠቃላይ እና በተለይም የ Alitnity ኦፕሬተርን ለመተግበር መሞከር ያስፈልገኛልን?

በውጤቱ ላይ እኛ እናገኛለን-

• ውቅረትን፣ ማሰማራትን እና ጥገናን በሚያስደንቅ ሁኔታ ቀለል ያድርጉት እና በራስ-ሰር ያድርጉ።
• ወዲያውኑ አብሮ የተሰራ ክትትል.
• እና ለአገልግሎት ዝግጁ የሆኑ የተቀዱ አብነቶች ለተወሳሰቡ ሁኔታዎች። ቀድሞውንም የዓይነቱ ተግባር ቅጂን ለመጨመር በእጅ መከናወን አያስፈልገውም። ይህ በኦፕሬተሩ ይከናወናል.

የመጨረሻው ጥያቄ ብቻ ይቀራል። አስቀድመን በ Kubernetes, ቨርቹዋልላይዜሽን ውስጥ የውሂብ ጎታ አለን. በተለይ ClickHouse ለአፈጻጸም የተመቻቸ ስለሆነ የዚህ ዓይነቱ መፍትሔ አፈጻጸምስ?

መልሱ ሁሉም ነገር ደህና ነው! በዝርዝር አልገለጽም, ይህ የተለየ ዘገባ ርዕስ ነው.

ግን እንደ TSBS ያለ ፕሮጀክት አለ. ዋና ሥራው ምንድን ነው? ይህ የውሂብ ጎታ አፈጻጸም ፈተና ነው። ይህ ሙቀትን ከሞቃት ፣ ለስላሳ እና ለስላሳ ለማነፃፀር የሚደረግ ሙከራ ነው።

እንዴት ነው የሚሰራው? አንድ የውሂብ ስብስብ ይፈጠራል። ከዚያ ይህ በተመሳሳይ የሙከራ ስብስብ ላይ ያለው የውሂብ ስብስብ በተለያዩ የውሂብ ጎታዎች ላይ ይሰራል. እና እያንዳንዱ የውሂብ ጎታ አንድ ችግር በሚችለው መንገድ ይፈታል. እና ከዚያ ውጤቱን ማወዳደር ይችላሉ.

እሱ አስቀድሞ ብዙ የውሂብ ጎታዎችን ይደግፋል። ሦስት ዋና ዋናዎቹን ለይቻለሁ። ይህ፡-

• timescaledb.
• InfluxDB
• ጠቅታ ቤት.

ከሌላ ተመሳሳይ መፍትሄ ጋር ንፅፅር ተደረገ። ከ RedShift ጋር ማወዳደር። ንጽጽሩ የተደረገው በአማዞን ላይ ነው። ClickHouse እንዲሁ በዚህ ጉዳይ ላይ ከሁሉም ሰው ቀድሞ ነው።

ከተናገርኩት ምን መደምደሚያ ላይ መድረስ ይቻላል?

• DB በ Kubernetes ይቻላል. ምናልባት, ማንኛውንም ነገር ማድረግ ይችላሉ, ግን በአጠቃላይ እርስዎ የሚችሉት ይመስላል. ክሊክ ሃውስ በኩበርኔትስ በእርግጠኝነት የሚቻለው በእኛ ኦፕሬተር እገዛ ነው።
• ኦፕሬተሩ ሂደቶችን በራስ-ሰር ለማድረግ ይረዳል እና ህይወትን በእውነት ያቃልላል።
• አፈጻጸሙ የተለመደ ነው።
• እና፣ ጥቅም ላይ መዋል የሚችል እና ያለበት መስሎናል።

ክፍት ምንጭ - ይቀላቀሉን!

እንዳልኩት ኦፕሬተሩ ሙሉ ለሙሉ ክፍት የሆነ ምርት ነው, ስለዚህ ከፍተኛው የሰዎች ቁጥር ቢጠቀሙበት በጣም ጥሩ ይሆናል. አሁን ይቀላቀሉ! ሁላችሁንም እንጠብቃለን!

አመሰግናለሁ!

ጥያቄዎች

ለሪፖርቱ እናመሰግናለን! ስሜ አንቶን ነው። እኔ ከሴምሩሽ ነኝ። የምዝግብ ማስታወሻው ምን እንደሆነ እያሰብኩኝ ነው። ስለክትትል እንሰማለን, ነገር ግን ስለ ምዝግብ ማስታወሻ ምንም የለም, ስለ ሙሉ ክላስተር ከተነጋገርን. ለምሳሌ በሃርድዌር ላይ ክላስተር አለን። እና የተማከለ ምዝግብ ማስታወሻን እንጠቀማለን, በመደበኛ ዘዴዎች በጋራ ክምር ውስጥ እንሰበስባለን. እና ከዚያ እኛን የሚስብ መረጃ እናገኛለን።

ጥሩ ጥያቄ፣ ማለትም ወደ ተግባር ዝርዝር ውስጥ መግባት። የእኛ ኦፕሬተር ይህንን እስካሁን በራስ ሰር አያደርገውም። አሁንም እያደገ ነው, ፕሮጀክቱ ገና በጣም ወጣት ነው. የምዝግብ ማስታወሻ አስፈላጊነት ተረድተናል። ይህ ደግሞ በጣም አስፈላጊ ርዕስ ነው. እና ምናልባት ከክትትል ያነሰ አስፈላጊ አይደለም. ነገር ግን በመጀመሪያ ለትግበራው ዝርዝር ውስጥ ክትትል ነበር. ምዝግብ ማስታወሻ ይኖራል። በተፈጥሮ፣ ሁሉንም የክላስተር ህይወት ገፅታዎችን በራስ ሰር ለመስራት እየሞከርን ነው። ስለዚህ, መልሱ በአሁኑ ጊዜ ኦፕሬተሩ, በሚያሳዝን ሁኔታ, ይህንን እንዴት ማድረግ እንዳለበት አያውቅም, ነገር ግን በእቅዶች ውስጥ ነው, እኛ እናደርጋለን. መቀላቀል ከፈለጉ እባክዎን ጥያቄን ይጎትቱ።

ሀሎ! ለሪፖርቱ እናመሰግናለን! ከቋሚ ጥራዞች ጋር የተያያዘ መደበኛ ጥያቄ አለኝ። ከዚህ ኦፕሬተር ጋር ውቅር ስንፈጥር ኦፕሬተሩ በየትኛው መስቀለኛ መንገድ ላይ አንዳንድ ዲስክ ወይም አቃፊ እንዳለን እንዴት ይወስናል? በመጀመሪያ እኛ ለእሱ ማስረዳት አለብን ፣ እባክዎን የእኛን ClickHouse በትክክል በእነዚህ አንጓዎች ላይ ዲስክ ባላቸው ኖዶች ላይ ያኑሩ?

እኔ እስከገባኝ ድረስ፣ ይህ ጥያቄ የአካባቢያዊ ማከማቻ ቀጣይነት ነው፣ በተለይም የአስተናጋጁ ፓዝ ክፍል። ልክ እንደዚህ እና እንደዚህ ባሉ መንገዶች ላይ የተገጠመ አካላዊ የተገናኘ ዲስክ ያለንበት ፖድ በእንደዚህ አይነት እና በእንደዚህ አይነት መስቀለኛ መንገድ ላይ በትክክል እንዲነሳ አስፈላጊ መሆኑን ለጠቅላላው ስርዓት ማስረዳት ነው. ይህ በጣም ላዩን የነካሁት ሙሉ ክፍል ነው፣ ምክንያቱም መልሱ በጣም ትልቅ ነው።

ባጭሩ ይህን ይመስላል። እርግጥ ነው፣ እነዚህን ጥራዞች ማዘጋጀት አለብን። በአሁኑ ጊዜ በአካባቢያዊ ማከማቻ ውስጥ ምንም ተለዋዋጭ አቅርቦት የለም, ስለዚህ DevOps ዲስኮችን እራሳቸው መቁረጥ አለባቸው, እነዚህ ጥራዞች እዚህ አሉ. እና የኩበርኔትስ አቅርቦትን ማብራራት አለባቸው ፣ እንደዚህ ባሉ እና እንደዚህ ባሉ አንጓዎች ላይ የሚገኘው እንደዚህ ያሉ እና እንደዚህ ያሉ ክፍሎች የማያቋርጥ ጥራዞች ይኖሩዎታል። ከዚያም ለኩበርኔትስ እንዲህ አይነት እና እንደዚህ ያለ የአካባቢ ማከማቻ ክፍል የሚያስፈልጋቸው ፖድዎች በእንደዚህ አይነት እና በመሳሰሉት አንጓዎች ላይ ብቻ በተሰየመ መለያዎች መሰረት መርሐግብር እንደሚያስፈልግ ማስረዳት አስፈላጊ ይሆናል. ለእነዚህ ዓላማዎች፣ ኦፕሬተሩ አንድ ዓይነት መለያ እና በአስተናጋጅ ምሳሌ የመመደብ ችሎታ አለው። እና በቀላል አገላለጽ መስፈርቶችን ፣ መለያዎችን በሚያሟሉ አንጓዎች ላይ ብቻ እንዲሰሩ ፖዶች በኩበርኔትስ ይመራሉ ። አስተዳዳሪዎች መለያዎችን ይመድባሉ, በእጅ የዲስክ አቅርቦትን ይሠራሉ. እና ከዚያም ይመዝናል.

እና ሶስተኛው አማራጭ አካባቢያዊ ብቻ ትንሽ ቀላል ለማድረግ ይረዳል. አስቀድሜ እንደገለጽኩት፣ ይህ በጣም አድካሚ የማስተካከል ስራ ነው፣ ይህም በመጨረሻ ከፍተኛ አፈፃፀም ለማግኘት ይረዳል።

ከዚህ ጋር የተያያዘ ሁለተኛ ጥያቄ አለኝ። ኩበርኔትስ የተፀነሰው መስቀለኛ መንገድ ብንጠፋም ባይጠፋንም ምንም በማይሆን መልኩ ነው። ሸርተቴ ያለበትን መስቀለኛ መንገድ ከጠፋን በዚህ ጉዳይ ላይ ምን ማድረግ አለብን?

አዎን ኩበርኔትስ መጀመሪያ ላይ ከፖሳዎቻችን ጋር ያለን ግንኙነት እንደ ከብቶች ነው, ነገር ግን እዚህ እያንዳንዱ ዲስክ እንደ የቤት እንስሳ ይሆናል. ዝም ብለን ልንጥላቸው የማንችለው እንዲህ ያለ ችግር አለ። እና የኩበርኔትስ እድገት ሙሉ በሙሉ በፍልስፍና ማከም ወደማይቻልበት አቅጣጫ እየሄደ ነው ፣ እንደ ሙሉ በሙሉ የተጣለ ሀብት።

አሁን ተግባራዊ ጥያቄ. ዲስኩ ያለበትን መስቀለኛ መንገድ ከጠፋ ምን ማድረግ ይኖርብሃል? እዚህ ችግሩ በከፍተኛ ደረጃ ተፈትቷል. በ ClickHouse ሁኔታ, በከፍተኛ ደረጃ የሚሰሩ ቅጂዎች አሉን, ማለትም. በ ClickHouse ደረጃ.

ዝንባሌው ምንድን ነው? DevOps ውሂብ እንዳይጠፋ የማረጋገጥ ኃላፊነት አለበት። ማባዛትን በትክክል ማዋቀር እና ማባዛት እየሰራ መሆኑን ማረጋገጥ አለበት። በ ClickHouse ደረጃ ላይ ባለው ቅጂ ውሂቡ መባዛት አለበት። ይህ ኦፕሬተሩ የሚፈታው ተግባር አይደለም. እና ኩበርኔትስ ራሱ የሚፈታው ተግባር አይደለም. ይህ በ ClickHouse ደረጃ ላይ ነው።

የብረት ኖድዎ ከወደቀ ምን ማድረግ አለበት? እና ሁለተኛውን ማስቀመጥ, ዲስኩን በትክክል በእሱ ላይ ማንቀሳቀስ, መለያዎችን መተግበር አስፈላጊ ይሆናል. እና ከዚያ በኋላ Kubernetes በላዩ ላይ የፖድ ምሳሌን ማስኬድ የሚችሉትን መስፈርቶች ያሟላል። ኩበርኔትስ ያስነሳዋል። የእርስዎ የፖድ ቁጥር ለተጠቀሰው ብቻ በቂ አይደለም። ባሳየሁት ዑደት ውስጥ ያልፋል። እና በከፍተኛ ደረጃ ፣ ClickHouse አንድ ቅጂ እንደገባን ይገነዘባል ፣ አሁንም ባዶ ነው እና ውሂብ ወደ እሱ ማስተላለፍ መጀመር አለብን። እነዚያ። ይህ ሂደት አሁንም በደካማ አውቶማቲክ ነው.

ለሪፖርቱ እናመሰግናለን! ሁሉም አይነት አስጸያፊ ነገሮች ሲከሰቱ ኦፕሬተሩ ተሰናክሎ እንደገና ይጀምራል፣ እና በዚያ ቅጽበት ክስተቶች ይመጣሉ፣ ይህን በሆነ መንገድ ያስተናግዳሉ?

ኦፕሬተሩ ከተሰናከለ እና እንደገና ከጀመረ ምን ይከሰታል፣ አዎ?

አዎ. እና በዚያን ጊዜ ክስተቶች መጡ.

በዚህ ጉዳይ ላይ ምን ማድረግ እንዳለበት ተግባር በኦፕሬተሩ እና በኩበርኔትስ መካከል በከፊል ተከፋፍሏል. ኩበርኔትስ የተከሰተውን ክስተት እንደገና የማጫወት ችሎታ አለው። በድጋሚ ይጫወትበታል። እና የኦፕሬተሩ ተግባር የክስተቱ ምዝግብ ማስታወሻ በላዩ ላይ ሲጫወት እነዚህ ክስተቶች ኃይለኛ መሆናቸውን ማረጋገጥ ነው። እናም የአንድ አይነት ክስተት ዳግም መከሰት ስርዓታችንን ለኛ እንዳይሰብርን። እና የእኛ ኦፕሬተር ይህንን ተግባር ይቋቋማል.

ሀሎ! ለሪፖርቱ እናመሰግናለን! Dmitry Zavialov, ኩባንያ ስሜዶቭ. ከሃፕሮክሲ ጋር የማበጀት አማራጮችን ወደ ኦፕሬተሩ ለመጨመር ታቅዷል? ብልህ እንዲሆን እና ClickHouse እውን መሆኑን እንዲረዳ አንዳንድ ሌላ ሚዛን ሰጪ ከመደበኛው ሌላ አስደሳች ነው።

ስለ Ingress እያወሩ ነው?

አዎ ኢንግረስን በሃፕሮክሲ ይተኩ። በሃፕሮክሲ ውስጥ፣ ክላስተር ቶፖሎጂ ቅጂዎች ባሉበት ቦታ መግለጽ ይችላሉ።

እስካሁን ድረስ አላሰብነውም። ከፈለግክ እና ለምን እንደሚያስፈልግ ማስረዳት ከቻልክ በተለይ መሳተፍ የምትፈልግ ከሆነ እሱን ተግባራዊ ማድረግ ትችላለህ። ምርጫውን ስናስብ ደስተኞች ነን። መልሱ አጭሩ አይደለም፣ በአሁኑ ጊዜ እንደዚህ አይነት ተግባር የለንም። ስለ ጠቃሚ ምክር እናመሰግናለን፣ ይህንን እንመለከታለን። እና የአጠቃቀም ጉዳይን እና ለምን በተግባር እንደሚያስፈልግ ካብራሩ ፣ ለምሳሌ ፣ በ GitHub ላይ ጉዳዮችን ይፍጠሩ ፣ ከዚያ በጣም ጥሩ ይሆናል።

አስቀድሞ አለው።

ጥሩ። ለማንኛውም ጥቆማ ክፍት ነን። እና ሃፕሮክሲ በተግባራዊ ዝርዝር ውስጥ ተቀምጧል። የቶዶ ዝርዝር እያደገ ነው፣ ገና እየቀነሰ አይደለም። ግን ይህ ጥሩ ነው, ምርቱ በፍላጎት ላይ ነው ማለት ነው.

ምንጭ: hab.com