ડેટાબેઝ ક્લસ્ટરના સંચાલન માટે કુબરનેટ્સમાં ઓપરેટર. વ્લાદિસ્લાવ ક્લિમેન્કો (અલ્ટિનિટી, 2019)

અહેવાલ કુબરનેટ્સમાં ઓપરેટર વિકસાવવા, તેના આર્કિટેક્ચર અને મૂળભૂત ઓપરેટિંગ સિદ્ધાંતોની રચનાના વ્યવહારુ મુદ્દાઓને સમર્પિત છે.

અહેવાલના પ્રથમ ભાગમાં અમે વિચારણા કરીશું:

• કુબરનેટ્સમાં ઓપરેટર શું છે અને તેની શા માટે જરૂર છે;
• ઓપરેટર જટિલ સિસ્ટમોના સંચાલનને બરાબર કેવી રીતે સરળ બનાવે છે;
• ઓપરેટર શું કરી શકે અને શું ન કરી શકે.

આગળ, ચાલો ઓપરેટરની આંતરિક રચનાની ચર્ચા કરવા આગળ વધીએ. ચાલો ઓપરેટરના આર્કિટેક્ચર અને ઓપરેશનને સ્ટેપ બાય સ્ટેપ જોઈએ. ચાલો તેને વિગતવાર જોઈએ:

• ઓપરેટર અને કુબરનેટ્સ વચ્ચેની ક્રિયાપ્રતિક્રિયા;
• ઓપરેટર કયા કાર્યો કરે છે અને તે કુબરનેટ્સને કયા કાર્યો સોંપે છે.

ચાલો કુબરનેટ્સમાં શાર્ડ્સ અને ડેટાબેઝ પ્રતિકૃતિઓનું સંચાલન કરીએ તે જોઈએ.
આગળ, અમે ડેટા સ્ટોરેજ મુદ્દાઓની ચર્ચા કરીશું:

• ઑપરેટરના દૃષ્ટિકોણથી પર્સિસ્ટન્ટ સ્ટોરેજ સાથે કેવી રીતે કામ કરવું;
• સ્થાનિક સ્ટોરેજનો ઉપયોગ કરવાની મુશ્કેલીઓ.

અહેવાલના અંતિમ ભાગમાં, અમે એપ્લિકેશનના વ્યવહારુ ઉદાહરણો પર વિચાર કરીશું ક્લિકહાઉસ-ઓપરેટર એમેઝોન અથવા ગૂગલ ક્લાઉડ સેવા સાથે. અહેવાલ ક્લિકહાઉસ માટે ઓપરેટરના વિકાસ અને સંચાલન અનુભવના ઉદાહરણ પર આધારિત છે.

વિડિઓ:

મારું નામ વ્લાદિસ્લાવ ક્લિમેન્કો છે. આજે હું ઓપરેટરના વિકાસ અને સંચાલનના અમારા અનુભવ વિશે વાત કરવા માંગતો હતો, અને આ ડેટાબેઝ ક્લસ્ટરોનું સંચાલન કરવા માટે એક વિશિષ્ટ ઓપરેટર છે. દાખ્લા તરીકે હાઉસ-ઓપરેટર પર ક્લિક કરો ક્લિકહાઉસ ક્લસ્ટરનું સંચાલન કરવા માટે.

શા માટે અમારી પાસે ઓપરેટર અને ક્લિકહાઉસ વિશે વાત કરવાની તક છે?

• અમે ક્લિકહાઉસને સમર્થન અને વિકાસ કરીએ છીએ.
• આ ક્ષણે, અમે ક્લિકહાઉસના વિકાસમાં ધીમે ધીમે અમારું યોગદાન આપવાનો પ્રયાસ કરી રહ્યા છીએ. અને ક્લિકહાઉસમાં થયેલા ફેરફારોની માત્રાની દ્રષ્ટિએ અમે યાન્ડેક્ષ પછી બીજા ક્રમે છીએ.
• અમે ક્લિકહાઉસ ઇકોસિસ્ટમ માટે વધારાના પ્રોજેક્ટ્સ કરવાનો પ્રયાસ કરી રહ્યા છીએ.

હું તમને આમાંથી એક પ્રોજેક્ટ વિશે જણાવવા માંગુ છું. આ કુબરનેટ્સ માટે ક્લિકહાઉસ-ઓપરેટર વિશે છે.

મારા અહેવાલમાં હું બે વિષયો પર સ્પર્શ કરવા માંગુ છું:

• પહેલો વિષય એ છે કે અમારા ક્લિકહાઉસ ડેટાબેઝ મેનેજમેન્ટ ઓપરેટર કુબરનેટ્સમાં કેવી રીતે કાર્ય કરે છે.
• બીજો વિષય એ છે કે કોઈપણ ઓપરેટર કેવી રીતે કાર્ય કરે છે, એટલે કે તે કુબરનેટ્સ સાથે કેવી રીતે ક્રિયાપ્રતિક્રિયા કરે છે.

જો કે, આ બે પ્રશ્નો મારા સમગ્ર અહેવાલમાં છેદશે.

હું જે કહેવાનો પ્રયાસ કરી રહ્યો છું તે સાંભળવામાં કોને રસ હશે?

• જેઓ ઓપરેટરો ચલાવે છે તેમના માટે તે સૌથી વધુ રસ ધરાવશે.
• અથવા જેઓ તે આંતરિક રીતે કેવી રીતે કાર્ય કરે છે, ઓપરેટર કુબરનેટ્સ સાથે કેવી રીતે ક્રિયાપ્રતિક્રિયા કરે છે અને કઈ મુશ્કેલીઓ દેખાઈ શકે છે તે સમજવા માટે જેઓ પોતાનું બનાવવા માંગે છે.

આજે આપણે શું ચર્ચા કરીશું તે શ્રેષ્ઠ રીતે સમજવા માટે, કુબરનેટ્સ કેવી રીતે કાર્ય કરે છે તે જાણવું અને કેટલીક મૂળભૂત ક્લાઉડ તાલીમ લેવી એ એક સારો વિચાર છે.

ક્લિકહાઉસ શું છે? આ વિશ્લેષણાત્મક પ્રશ્નોની ઓનલાઈન પ્રક્રિયા માટે વિશિષ્ટ સુવિધાઓ સાથેનો સ્તંભાકાર ડેટાબેઝ છે. અને તે સંપૂર્ણપણે ઓપન સોર્સ છે.

અને આપણા માટે માત્ર બે જ બાબતો જાણવી જરૂરી છે. તમારે જાણવાની જરૂર છે કે આ એક ડેટાબેઝ છે, તેથી હું તમને જે કહીશ તે લગભગ કોઈપણ ડેટાબેઝને લાગુ પડશે. અને હકીકત એ છે કે ક્લિકહાઉસ ડીબીએમએસ ખૂબ સારી રીતે સ્કેલ કરે છે, લગભગ રેખીય માપનીયતા આપે છે. અને તેથી, ક્લસ્ટર સ્ટેટ એ ક્લિકહાઉસ માટે કુદરતી સ્થિતિ છે. અને કુબરનેટ્સમાં ક્લિકહાઉસ ક્લસ્ટરને કેવી રીતે સેવા આપવી તેની ચર્ચા કરવામાં અમને સૌથી વધુ રસ છે.

તેની ત્યાં શા માટે જરૂર છે? શા માટે આપણે તેને જાતે ચલાવવાનું ચાલુ રાખી શકતા નથી? અને જવાબો અંશતઃ તકનીકી અને અંશતઃ સંસ્થાકીય છે.

• વ્યવહારમાં, અમે વધુને વધુ એવી પરિસ્થિતિનો સામનો કરી રહ્યા છીએ જ્યાં મોટી કંપનીઓમાં લગભગ તમામ ઘટકો પહેલેથી જ કુબરનેટ્સમાં છે. ડેટાબેઝ બહાર રહે છે.
• અને પ્રશ્ન વધુને વધુ પૂછવામાં આવે છે: "શું આ અંદર મૂકી શકાય છે?" તેથી, મોટી કંપનીઓ તેમના ડેટા વેરહાઉસને ઝડપથી સંચાલિત કરવામાં સક્ષમ થવા માટે મેનેજમેન્ટનું મહત્તમ એકીકરણ પ્રાપ્ત કરવાનો પ્રયાસ કરી રહી છે.
• અને આ ખાસ કરીને મદદ કરે છે જો તમને નવી જગ્યાએ એ જ વસ્તુનું પુનરાવર્તન કરવાની મહત્તમ તકની જરૂર હોય, એટલે કે મહત્તમ પોર્ટેબિલિટી.

તે કેટલું સરળ કે મુશ્કેલ છે? આ, અલબત્ત, હાથ દ્વારા કરી શકાય છે. પરંતુ તે એટલું સરળ નથી, કારણ કે અમારી પાસે કુબરનેટ્સનું સંચાલન કરવાની વધારાની જટિલતા છે, પરંતુ તે જ સમયે ક્લિકહાઉસની વિશિષ્ટતાઓ સુપરઇમ્પોઝ કરવામાં આવી છે. અને આવા એકત્રીકરણ પરિણામો.

અને આ બધું મળીને ટેક્નૉલૉજીનો એકદમ મોટો સેટ આપે છે, જેનું સંચાલન કરવું ખૂબ મુશ્કેલ બની જાય છે, કારણ કે કુબરનેટ્સ તેના પોતાના રોજિંદા મુદ્દાઓને ઑપરેશનમાં લાવે છે, અને ક્લિકહાઉસ રોજિંદા ઑપરેશનમાં તેની પોતાની સમસ્યાઓ લાવે છે. ખાસ કરીને જો અમારી પાસે ઘણા ક્લિકહાઉસ છે, અને અમારે તેમની સાથે સતત કંઈક કરવાની જરૂર છે.

ગતિશીલ રૂપરેખાંકન સાથે, ClickHouse માં ઘણી બધી સમસ્યાઓ છે જે DevOps પર સતત લોડ બનાવે છે:

• જ્યારે આપણે ક્લિકહાઉસમાં કંઈક બદલવા માંગીએ છીએ, ઉદાહરણ તરીકે, પ્રતિકૃતિ અથવા શાર્ડ ઉમેરો, તો આપણે ગોઠવણીનું સંચાલન કરવાની જરૂર છે.
• પછી ડેટા સ્કીમા બદલો, કારણ કે ક્લિકહાઉસ પાસે ચોક્કસ શાર્ડિંગ પદ્ધતિ છે. ત્યાં તમારે ડેટા ડાયાગ્રામ મૂકવાની, ગોઠવણીઓ મૂકવાની જરૂર છે.
• તમારે મોનિટરિંગ સેટ કરવાની જરૂર છે.
• નવા શાર્ડ માટે, નવી પ્રતિકૃતિઓ માટે લોગ એકત્રિત કરી રહ્યા છીએ.
• પુનઃસંગ્રહની કાળજી લો.
• અને પુનઃપ્રારંભ કરો.

આ નિયમિત કાર્યો છે જેનો હું ખરેખર ઉપયોગ સરળ બનાવવા માંગુ છું.

કુબરનેટ્સ પોતે ઓપરેશનમાં સારી રીતે મદદ કરે છે, પરંતુ મૂળભૂત સિસ્ટમ વસ્તુઓ પર.

કુબરનેટ્સ વસ્તુઓની સુવિધા અને સ્વચાલિત કરવામાં સારી છે જેમ કે:

• પુન: પ્રાપ્તિ.
• પુનઃપ્રારંભ.
• સ્ટોરેજ સિસ્ટમ મેનેજમેન્ટ.

તે સારું છે, તે સાચી દિશા છે, પરંતુ તે ડેટાબેઝ ક્લસ્ટરને કેવી રીતે ચલાવવું તે વિશે સંપૂર્ણપણે અજાણ છે.

અમને વધુ જોઈએ છે, અમે ઈચ્છીએ છીએ કે આખો ડેટાબેઝ કુબરનેટ્સમાં કામ કરે.

હું એક મોટું જાદુઈ લાલ બટન જેવું કંઈક મેળવવા માંગુ છું જેને તમે દબાવો છો અને રોજિંદા કાર્યો સાથેનું એક ક્લસ્ટર કે જેને હલ કરવાની જરૂર છે તે તેના સમગ્ર જીવનચક્ર દરમિયાન તૈનાત અને જાળવવામાં આવે છે. Kubernetes માં ClickHouse ક્લસ્ટર.

અને અમે એક ઉકેલ લાવવાનો પ્રયાસ કર્યો જે કામને સરળ બનાવવામાં મદદ કરશે. આ Altinity થી Kubernetes માટે ક્લિકહાઉસ-ઓપરેટર છે.

ઑપરેટર એ એક પ્રોગ્રામ છે જેનું મુખ્ય કાર્ય અન્ય પ્રોગ્રામ્સનું સંચાલન કરવાનું છે, એટલે કે તે મેનેજર છે.

અને તે વર્તનની પેટર્ન ધરાવે છે. તમે વિષય વિસ્તાર વિશે આ કોડીફાઇડ જ્ઞાન કહી શકો છો.

અને તેનું મુખ્ય કાર્ય DevOps નું જીવન સરળ બનાવવાનું અને માઈક્રોમેનેજમેન્ટ ઘટાડવાનું છે, જેથી તે (DevOps) પહેલેથી જ ઉચ્ચ-સ્તરની શરતોમાં વિચારે, એટલે કે, જેથી તે (DevOps) માઈક્રોમેનેજમેન્ટમાં સામેલ ન થાય, જેથી તે રૂપરેખાંકિત ન થાય. બધી વિગતો જાતે.

અને માત્ર ઓપરેટર એક રોબોટિક સહાયક છે જે માઇક્રોટાસ્ક સાથે કામ કરે છે અને DevOps ને મદદ કરે છે.

તમારે ઓપરેટરની શા માટે જરૂર છે? તે ખાસ કરીને બે ક્ષેત્રોમાં સારું પ્રદર્શન કરે છે:

• જ્યારે ક્લીકહાઉસ સાથે ડીલ કરનાર નિષ્ણાત પાસે પૂરતો અનુભવ નથી, પરંતુ તેને પહેલાથી જ ક્લિકહાઉસનું સંચાલન કરવાની જરૂર છે, ત્યારે ઑપરેટર ઑપરેશનની સુવિધા આપે છે અને તમને તે બધું કેવી રીતે કાર્ય કરે છે તે વિશે વધુ વિગતમાં ગયા વિના, વધુ જટિલ રૂપરેખાંકન સાથે ક્લિકહાઉસ ક્લસ્ટરનું સંચાલન કરવાની મંજૂરી આપે છે. અંદર તમે તેને માત્ર ઉચ્ચ સ્તરીય કાર્યો આપો, અને તે કાર્ય કરે છે.
• અને બીજું કાર્ય જેમાં તે શ્રેષ્ઠ પ્રદર્શન કરે છે તે છે જ્યારે મોટી સંખ્યામાં લાક્ષણિક કાર્યોને સ્વચાલિત કરવું જરૂરી છે. સિસ્ટમ સંચાલકો પાસેથી માઇક્રોટાસ્ક દૂર કરે છે.

જેઓ હમણાં જ તેમની મુસાફરી શરૂ કરી રહ્યા છે અથવા જેમને ઘણું ઓટોમેશન કરવાની જરૂર છે તેમને આની સૌથી વધુ જરૂર છે.

ઑપરેટર-આધારિત અભિગમ અન્ય સિસ્ટમોથી કેવી રીતે અલગ છે? સુકાન છે. તે ક્લિકહાઉસ ઇન્સ્ટોલ કરવામાં પણ મદદ કરે છે; તમે સુકાન ચાર્ટ દોરી શકો છો, જે આખા ક્લિકહાઉસ ક્લસ્ટરને પણ ઇન્સ્ટોલ કરશે. તો પછી ઓપરેટર અને સમાન વચ્ચે શું તફાવત છે, ઉદાહરણ તરીકે, હેલ્મ?

મુખ્ય મૂળભૂત તફાવત એ છે કે હેલ્મ પેકેજ મેનેજમેન્ટ છે અને ઓપરેટર એક પગલું આગળ જાય છે. આ સમગ્ર જીવન ચક્ર માટે આધાર છે. આ ફક્ત ઇન્સ્ટોલેશન જ નથી, આ રોજિંદા કાર્યો છે જેમાં સ્કેલિંગ, શાર્ડિંગ, એટલે કે જીવન ચક્ર દરમિયાન કરવાની જરૂર હોય તે બધું (જો જરૂરી હોય તો, પછી કાઢી નાખવું પણ) નો સમાવેશ થાય છે - આ બધું ઓપરેટર દ્વારા નક્કી કરવામાં આવે છે. તે સમગ્ર સોફ્ટવેર જીવનચક્રને સ્વચાલિત અને જાળવવાનો પ્રયાસ કરે છે. પ્રસ્તુત કરાયેલા અન્ય ઉકેલોથી આ તેનો મૂળભૂત તફાવત છે.

તે પ્રારંભિક ભાગ હતો, ચાલો આગળ વધીએ.

અમે અમારા ઓપરેટરને કેવી રીતે બનાવી શકીએ? અમે ક્લિકહાઉસ ક્લસ્ટરને એક સંસાધન તરીકે મેનેજ કરવા માટે સમસ્યાનો સંપર્ક કરવાનો પ્રયાસ કરી રહ્યા છીએ.

અહીં આપણી પાસે ચિત્રની ડાબી બાજુએ ઇનપુટ ડેટા છે. આ ક્લસ્ટર સ્પષ્ટીકરણ સાથે YAML છે, જે ક્લાસિક રીતે ક્યુબેક્ટલ દ્વારા કુબરનેટ્સને પસાર કરવામાં આવે છે. ત્યાં અમારા ઓપરેટર તેને ઉપાડે છે અને તેનો જાદુ કરે છે. અને આઉટપુટ પર આપણને નીચેની સ્કીમ મળે છે. આ કુબરનેટ્સમાં ક્લિકહાઉસનું અમલીકરણ છે.

અને પછી આપણે ધીમે ધીમે જોશું કે ઓપરેટર બરાબર કેવી રીતે કાર્ય કરે છે, કયા લાક્ષણિક કાર્યો હલ કરી શકાય છે. અમે ફક્ત સામાન્ય કાર્યોને ધ્યાનમાં લઈશું કારણ કે અમારી પાસે મર્યાદિત સમય છે. અને ઑપરેટર નક્કી કરી શકે તે બધું જ ચર્ચા કરવામાં આવશે નહીં.

ચાલો પ્રેક્ટિસથી શરૂઆત કરીએ. અમારો પ્રોજેક્ટ સંપૂર્ણપણે ઓપન સોર્સ છે, તેથી તમે જોઈ શકો છો કે તે GitHub પર કેવી રીતે કાર્ય કરે છે. અને તમે એ વિચારણાઓથી આગળ વધી શકો છો કે જો તમે તેને ફક્ત લોન્ચ કરવા માંગતા હો, તો તમે ક્વિક સ્ટાર્ટ ગાઈડથી શરૂઆત કરી શકો છો.

જો તમે વિગતવાર સમજવા માંગતા હો, તો અમે દસ્તાવેજીકરણને વધુ કે ઓછા યોગ્ય સ્વરૂપમાં જાળવવાનો પ્રયાસ કરીએ છીએ.

ચાલો વ્યવહારુ સમસ્યાથી શરૂઆત કરીએ. પ્રથમ કાર્ય, જ્યાં આપણે બધા શરૂ કરવા માંગીએ છીએ, તે પ્રથમ ઉદાહરણને કોઈક રીતે ચલાવવાનું છે. હું ઑપરેટરનો ઉપયોગ કરીને ક્લિકહાઉસ કેવી રીતે લૉન્ચ કરી શકું, ભલે મને ખરેખર ખબર ન હોય કે તે કેવી રીતે કાર્ય કરે છે? અમે મેનિફેસ્ટો લખી રહ્યા છીએ, કારણ કે... k8s સાથેનો તમામ સંચાર મેનિફેસ્ટ દ્વારા સંચાર છે.

આ એક જટિલ મેનિફેસ્ટો છે. આપણે લાલ રંગમાં જે હાઇલાઇટ કર્યું છે તેના પર આપણે ધ્યાન કેન્દ્રિત કરવાની જરૂર છે. અમે ઑપરેટરને ડેમો નામનું ક્લસ્ટર બનાવવા માટે કહીએ છીએ.

આ હમણાં માટે મૂળભૂત ઉદાહરણો છે. હજુ સુધી સ્ટોરેજનું વર્ણન કરવામાં આવ્યું નથી, પરંતુ અમે થોડા સમય પછી સ્ટોરેજ પર પાછા આવીશું. હમણાં માટે, અમે ક્લસ્ટરના વિકાસની ગતિશીલતાનું અવલોકન કરીશું.

અમે આ મેનિફેસ્ટો બનાવ્યો છે. અમે તેને અમારા ઓપરેટરને ખવડાવીએ છીએ. તેણે કામ કર્યું, તેણે જાદુ કર્યો.

અમે કન્સોલ જોઈએ છીએ. ત્રણ ઘટકો રસ ધરાવે છે: એક પોડ, બે સેવાઓ અને એક સ્ટેટફુલસેટ.

ઓપરેટરે કામ કર્યું છે, અને આપણે જોઈ શકીએ છીએ કે તેણે બરાબર શું બનાવ્યું છે.

તે આના જેવું કંઈક બનાવે છે. અમારી પાસે દરેક પ્રતિકૃતિ માટે સ્ટેટફુલસેટ, પોડ, કોન્ફિગમેપ, સમગ્ર ક્લસ્ટર માટે કોન્ફિગમેપ છે. ક્લસ્ટરમાં પ્રવેશ બિંદુ તરીકે સેવાઓ જરૂરી છે.

સેવાઓ કેન્દ્રીય લોડ બેલેન્સર સેવા છે અને તેનો ઉપયોગ દરેક પ્રતિકૃતિ માટે, દરેક શાર્ડ માટે પણ થઈ શકે છે.

અમારું મૂળભૂત ક્લસ્ટર કંઈક આના જેવું લાગે છે. તે એક જ નોડમાંથી છે.

ચાલો આગળ જઈએ અને વસ્તુઓને જટિલ બનાવીએ. આપણે ક્લસ્ટરને શાર્ડ કરવાની જરૂર છે.

અમારા કાર્યો વધી રહ્યા છે, ગતિશીલતા શરૂ થઈ રહી છે. અમે એક શાર્ડ ઉમેરવા માંગીએ છીએ. અમે વિકાસને અનુસરીએ છીએ. અમે અમારા સ્પેસિફિકેશન બદલી રહ્યા છીએ. અમે સૂચવીએ છીએ કે અમને બે શાર્ડ જોઈએ છે.

આ એ જ ફાઇલ છે જે સિસ્ટમની વૃદ્ધિ સાથે ગતિશીલ રીતે વિકાસ પામે છે. સ્ટોરેજ નંબર, સ્ટોરેજ વિશે આગળ ચર્ચા કરવામાં આવશે, આ એક અલગ વિષય છે.

અમે YAML ઓપરેટરને ફીડ કરીએ છીએ અને જુઓ કે શું થાય છે.

ઓપરેટરે વિચાર્યું અને નીચેની સંસ્થાઓ બનાવી. અમારી પાસે પહેલેથી જ બે પોડ્સ, ત્રણ સેવાઓ અને અચાનક, 2 સ્ટેટફુલસેટ્સ છે. શા માટે 2 સ્ટેટફુલસેટ્સ?

ડાયાગ્રામ પર તે આના જેવું હતું - આ અમારી પ્રારંભિક સ્થિતિ છે, જ્યારે અમારી પાસે એક પોડ હતો.

તે આના જેવું બન્યું. અત્યાર સુધી બધું સરળ છે, તે ડુપ્લિકેટ કરવામાં આવ્યું છે.

અને શા માટે ત્યાં બે સ્ટેટફુલસેટ્સ બન્યા? અહીં આપણે કુબરનેટ્સમાં શીંગોનું સંચાલન કેવી રીતે કરવામાં આવે છે તે પ્રશ્ન પર વિષયાંતર કરવાની અને ચર્ચા કરવાની જરૂર છે.

સ્ટેટફુલસેટ નામનો એક ઑબ્જેક્ટ છે જે તમને ટેમ્પલેટમાંથી પોડ્સનો સેટ બનાવવા માટે પરવાનગી આપે છે. અહીં મુખ્ય પરિબળ ટેમ્પલેટ છે. અને તમે એક સ્ટેટફુલસેટમાં એક ટેમ્પલેટનો ઉપયોગ કરીને ઘણા પોડ્સ લોન્ચ કરી શકો છો. અને અહીંનો મુખ્ય વાક્ય "એક નમૂના માટે ઘણા પોડ્સ" છે.

અને આખા ક્લસ્ટરને એક સ્ટેટફુલસેટમાં પેક કરીને બનાવવાની મોટી લાલચ હતી. તે કામ કરશે, તેની સાથે કોઈ સમસ્યા નથી. પરંતુ એક ચેતવણી છે. જો આપણે વિજાતીય ક્લસ્ટરને એસેમ્બલ કરવા માંગીએ છીએ, એટલે કે, ક્લિકહાઉસના ઘણા સંસ્કરણોમાંથી, તો પછી પ્રશ્નો ઉભા થવાનું શરૂ થાય છે. હા, સ્ટેટફુલસેટ રોલિંગ અપડેટ કરી શકે છે, અને ત્યાં તમે નવું વર્ઝન રોલ આઉટ કરી શકો છો, સમજાવો કે તમારે એક જ સમયે ઘણા બધા નોડ્સ કરતાં વધુ પ્રયાસ કરવાની જરૂર નથી.

પરંતુ જો આપણે કાર્યને એક્સ્ટ્રાપોલેટ કરીએ અને કહીએ કે અમે સંપૂર્ણપણે વિજાતીય ક્લસ્ટર બનાવવા માંગીએ છીએ અને અમે રોલિંગ અપડેટનો ઉપયોગ કરીને જૂના સંસ્કરણમાંથી નવા સંસ્કરણમાં બદલવા માંગતા નથી, પરંતુ અમે ફક્ત બંને દ્રષ્ટિએ વિજાતીય ક્લસ્ટર બનાવવા માંગીએ છીએ. ક્લિકહાઉસના વિવિધ સંસ્કરણો અને વિવિધ સ્ટોરેજની દ્રષ્ટિએ. અમે ઇચ્છીએ છીએ કે, ઉદાહરણ તરીકે, અલગ ડિસ્ક પર કેટલીક પ્રતિકૃતિઓ બનાવવા માટે, ધીમી ડિસ્ક પર, સામાન્ય રીતે, સંપૂર્ણપણે વિજાતીય ક્લસ્ટર બનાવવા માટે. અને હકીકત એ છે કે સ્ટેટફુલસેટ એક નમૂનામાંથી પ્રમાણિત ઉકેલ બનાવે છે, આ કરવા માટે કોઈ રીત નથી.

થોડો વિચાર કર્યા પછી નક્કી થયું કે આ રીતે કરીશું. અમારી પાસે દરેક પ્રતિકૃતિ તેના પોતાના સ્ટેટફુલસેટમાં છે. આ ઉકેલમાં કેટલીક ખામીઓ છે, પરંતુ વ્યવહારમાં તે બધું ઓપરેટર દ્વારા સંપૂર્ણપણે સમાવિષ્ટ છે. અને ત્યાં ઘણા બધા ફાયદા છે. અમે ઇચ્છીએ છીએ તે ચોક્કસ ક્લસ્ટર બનાવી શકીએ છીએ, ઉદાહરણ તરીકે, એકદમ વિજાતીય. તેથી, એક ક્લસ્ટરમાં કે જેમાં અમારી પાસે એક પ્રતિકૃતિ સાથે બે શાર્ડ છે, અમારી પાસે 2 સ્ટેટફુલસેટ્સ અને 2 પોડ્સ ચોક્કસપણે હશે કારણ કે અમે વિજાતીય ક્લસ્ટર બનાવવા માટે સક્ષમ થવા માટે ઉપર જણાવેલ કારણો માટે આ અભિગમ પસંદ કર્યો છે.

ચાલો વ્યવહારિક સમસ્યાઓ પર પાછા ફરીએ. અમારા ક્લસ્ટરમાં અમારે વપરાશકર્તાઓને ગોઠવવાની જરૂર છે, એટલે કે. તમારે કુબરનેટ્સમાં ક્લિકહાઉસની કેટલીક ગોઠવણી કરવાની જરૂર છે. ઓપરેટર આ માટે તમામ શક્યતાઓ પૂરી પાડે છે.

અમને જે જોઈએ છે તે અમે સીધા YAML માં લખી શકીએ છીએ. બધા રૂપરેખાંકન વિકલ્પો આ YAML થી સીધા જ ક્લિકહાઉસ રૂપરેખાઓમાં મેપ કરવામાં આવે છે, જે પછી સમગ્ર ક્લસ્ટરમાં વિતરિત કરવામાં આવે છે.

તમે તેને આ રીતે લખી શકો છો. આ ઉદાહરણ તરીકે છે. પાસવર્ડ એન્ક્રિપ્ટ કરી શકાય છે. સંપૂર્ણપણે બધા ક્લિકહાઉસ રૂપરેખાંકન વિકલ્પો સપોર્ટેડ છે. અહીં માત્ર એક ઉદાહરણ છે.

ક્લસ્ટર રૂપરેખાંકનને ConfigMap તરીકે વિતરિત કરવામાં આવે છે. વ્યવહારમાં, ConfigMap અપડેટ તરત થતું નથી, તેથી જો ક્લસ્ટર મોટું હોય, તો રૂપરેખાંકનને આગળ વધારવાની પ્રક્રિયામાં થોડો સમય લાગે છે. પરંતુ આ બધું વાપરવા માટે ખૂબ અનુકૂળ છે.

ચાલો કાર્યને જટિલ બનાવીએ. ક્લસ્ટરનો વિકાસ થઈ રહ્યો છે. અમે ડેટાની નકલ કરવા માંગીએ છીએ. એટલે કે, અમારી પાસે પહેલાથી જ બે શાર્ડ્સ છે, દરેકમાં એક પ્રતિકૃતિ છે, અને વપરાશકર્તાઓ રૂપરેખાંકિત છે. અમે વધી રહ્યા છીએ અને પ્રતિકૃતિ કરવા માંગીએ છીએ.

પ્રતિકૃતિ માટે આપણને શું જોઈએ છે?

અમને ઝૂકીપરની જરૂર છે. ક્લિકહાઉસમાં, ઝૂકીપરનો ઉપયોગ કરીને પ્રતિકૃતિ બનાવવામાં આવે છે. ZooKeeper જરૂરી છે જેથી અલગ-અલગ ક્લિકહાઉસ પ્રતિકૃતિઓ કયા ક્લિકહાઉસ પર કયા ડેટા બ્લોક્સ છે તે અંગે સર્વસંમતિ ધરાવે છે.

ZooKeeper નો ઉપયોગ કોઈપણ કરી શકે છે. જો એન્ટરપ્રાઇઝ પાસે બાહ્ય ઝૂકીપર હોય, તો તેનો ઉપયોગ કરી શકાય છે. જો નહીં, તો તમે તેને અમારા રિપોઝીટરીમાંથી ઇન્સ્ટોલ કરી શકો છો. ત્યાં એક ઇન્સ્ટોલર છે જે આ આખી વસ્તુને સરળ બનાવે છે.

અને સમગ્ર સિસ્ટમની ક્રિયાપ્રતિક્રિયા આકૃતિ આ રીતે બહાર આવે છે. અમારી પાસે એક પ્લેટફોર્મ તરીકે Kubernetes છે. તે ક્લિકહાઉસ ઓપરેટરને એક્ઝિક્યુટ કરે છે. મેં અહીં ZooKeeper ને ચિત્રિત કર્યું. અને ઓપરેટર ClickHouse અને ZooKeeper બંને સાથે સંપર્ક કરે છે. એટલે કે, ક્રિયાપ્રતિક્રિયા પરિણામો.

અને આ બધું ક્લિકહાઉસ માટે k8s માં ડેટાની સફળતાપૂર્વક નકલ કરવા માટે જરૂરી છે.

ચાલો હવે કાર્યને જ જોઈએ, પ્રતિકૃતિ માટેનું મેનિફેસ્ટ કેવું દેખાશે.

અમે અમારા મેનિફેસ્ટમાં બે વિભાગો ઉમેરી રહ્યા છીએ. પહેલું એ છે કે ઝૂકીપર ક્યાંથી મેળવવું, જે કુબરનેટ્સની અંદર અથવા બાહ્ય હોઈ શકે છે. આ માત્ર એક વર્ણન છે. અને અમે પ્રતિકૃતિઓ ઓર્ડર કરીએ છીએ. તે. અમને બે પ્રતિકૃતિ જોઈએ છે. કુલ મળીને, આપણી પાસે આઉટપુટ પર 4 શીંગો હોવા જોઈએ. અમને સ્ટોરેજ વિશે યાદ છે, તે થોડી વાર પછી પાછું આવશે. સંગ્રહ એ એક અલગ વાર્તા છે.

તે આના જેવું હતું.

તે આના જેવું બને છે. પ્રતિકૃતિઓ ઉમેરવામાં આવે છે. 4 થી એક ફિટ નથી, અમે માનીએ છીએ કે તેમાંના ઘણા ત્યાં હોઈ શકે છે. અને બાજુમાં ZooKeeper ઉમેરવામાં આવે છે. યોજનાઓ વધુ જટિલ બની રહી છે.

અને આગામી કાર્ય ઉમેરવાનો સમય છે. અમે પર્સિસ્ટન્ટ સ્ટોરેજ ઉમેરીશું.

પર્સિસ્ટન્ટ સ્ટોરેજ માટે અમારી પાસે વિવિધ વિકલ્પો છે.

જો આપણે ક્લાઉડ પ્રદાતામાં ચાલી રહ્યા છીએ, ઉદાહરણ તરીકે, એમેઝોન, ગૂગલનો ઉપયોગ કરીને, તો પછી ક્લાઉડ સ્ટોરેજનો ઉપયોગ કરવાની એક મોટી લાલચ છે. તે ખૂબ અનુકૂળ છે, તે સારું છે.

અને બીજો વિકલ્પ છે. આ સ્થાનિક સંગ્રહ માટે છે, જ્યારે અમારી પાસે દરેક નોડ પર સ્થાનિક ડિસ્ક હોય છે. આ વિકલ્પ અમલમાં મૂકવો વધુ મુશ્કેલ છે, પરંતુ તે જ સમયે તે વધુ ઉત્પાદક છે.

ચાલો જોઈએ કે ક્લાઉડ સ્ટોરેજ વિશે આપણી પાસે શું છે.

ફાયદા છે. તે રૂપરેખાંકિત કરવા માટે ખૂબ જ સરળ છે. અમે ફક્ત ક્લાઉડ પ્રદાતા પાસેથી ઓર્ડર આપીએ છીએ કે કૃપા કરીને અમને આવા અને આવા વર્ગના આવા અને આવા ક્ષમતાનો સંગ્રહ આપો. વર્ગો પ્રદાતાઓ દ્વારા સ્વતંત્ર રીતે સુનિશ્ચિત કરવામાં આવે છે.

અને એક ખામી છે. કેટલાક માટે, આ બિન-જટિલ ખામી છે. અલબત્ત, કામગીરીની કેટલીક સમસ્યાઓ હશે. તે વાપરવા માટે ખૂબ જ અનુકૂળ અને વિશ્વસનીય છે, પરંતુ કેટલાક સંભવિત પ્રદર્શન ખામીઓ છે.

અને કારણ કે ક્લિકહાઉસ ખાસ કરીને ઉત્પાદકતા પર ધ્યાન કેન્દ્રિત કરે છે, કોઈ એવું પણ કહી શકે છે કે તે જે કરી શકે છે તે બધું જ સ્ક્વિઝ કરે છે, તેથી જ ઘણા ગ્રાહકો મહત્તમ ઉત્પાદકતાને સ્ક્વિઝ કરવાનો પ્રયાસ કરે છે.

અને તેમાંથી સૌથી વધુ મેળવવા માટે, અમને સ્થાનિક સ્ટોરેજની જરૂર છે.

કુબરનેટ્સ કુબરનેટ્સમાં સ્થાનિક સ્ટોરેજનો ઉપયોગ કરવા માટે ત્રણ એબ્સ્ટ્રેક્શન પ્રદાન કરે છે. આ:

• ખાલી ડીર
• હોસ્ટપાથ.
• સ્થાનિક

ચાલો જોઈએ કે તેઓ કેવી રીતે અલગ પડે છે અને તેઓ કેવી રીતે સમાન છે.

પ્રથમ, ત્રણેય અભિગમોમાં અમારી પાસે સંગ્રહ છે - આ સ્થાનિક ડિસ્ક છે જે સમાન ભૌતિક k8s નોડ પર સ્થિત છે. પરંતુ તેમની પાસે કેટલાક તફાવતો છે.

ચાલો સૌથી સરળ સાથે શરૂ કરીએ, એટલે કે ખાલી ડીર. વ્યવહારમાં આ શું છે? અમારા સ્પષ્ટીકરણમાં, અમે કન્ટેનરાઇઝેશન સિસ્ટમ (મોટાભાગે ડોકર) ને સ્થાનિક ડિસ્ક પરના ફોલ્ડરની ઍક્સેસ પ્રદાન કરવા માટે કહીએ છીએ.

વ્યવહારમાં, ડોકર તેના પોતાના માર્ગો સાથે ક્યાંક એક અસ્થાયી ફોલ્ડર બનાવે છે અને તેને લાંબી હેશ કહે છે. અને તેને ઍક્સેસ કરવા માટે ઇન્ટરફેસ પ્રદાન કરે છે.

પ્રદર્શન મુજબ આ કેવી રીતે કાર્ય કરશે? આ સ્થાનિક ડિસ્ક ઝડપે કામ કરશે, એટલે કે. આ તમારા સ્ક્રૂની સંપૂર્ણ ઍક્સેસ છે.

પરંતુ આ કિસ્સામાં તેની ખામી છે. આ બાબતમાં પર્સિસ્ટન્ટ તદ્દન શંકાસ્પદ છે. પ્રથમ વખત ડોકર કન્ટેનર સાથે ફરે છે, પર્સિસ્ટન્ટ ખોવાઈ જાય છે. જો કુબરનેટ્સ કોઈ કારણોસર આ પોડને બીજી ડિસ્ક પર ખસેડવા માંગે છે, તો ડેટા ખોવાઈ જશે.

આ અભિગમ પરીક્ષણો માટે સારો છે, કારણ કે તે પહેલાથી જ સામાન્ય ગતિ દર્શાવે છે, પરંતુ કંઈક ગંભીર માટે આ વિકલ્પ યોગ્ય નથી.

તેથી ત્યાં બીજો અભિગમ છે. આ હોસ્ટપાથ છે. જો તમે પહેલાની સ્લાઈડ અને આ સ્લાઈડ જુઓ, તો તમે માત્ર એક જ તફાવત જોઈ શકશો. અમારું ફોલ્ડર ડોકરથી સીધા કુબરનેટ્સ નોડ પર ખસેડ્યું. તે અહીં થોડું સરળ છે. અમે સ્થાનિક ફાઇલ સિસ્ટમ પર સીધા જ પાથનો ઉલ્લેખ કરીએ છીએ જ્યાં અમે અમારો ડેટા સંગ્રહિત કરવા માંગીએ છીએ.

આ પદ્ધતિના ફાયદા છે. આ પહેલેથી જ એક વાસ્તવિક પર્સિસ્ટન્ટ છે, અને તે ક્લાસિક છે. અમે અમુક સરનામાં પર ડિસ્ક પર ડેટા રેકોર્ડ કરીશું.

ગેરફાયદા પણ છે. આ મેનેજમેન્ટની જટિલતા છે. અમારા કુબરનેટ્સ પોડને બીજા ભૌતિક નોડમાં ખસેડવા માંગે છે. અને આ તે છે જ્યાં DevOps રમતમાં આવે છે. તેણે આખી સિસ્ટમને યોગ્ય રીતે સમજાવવું જોઈએ કે આ શીંગો ફક્ત તે જ ગાંઠો પર ખસેડી શકાય છે કે જેના પર તમે આ પાથ સાથે કંઈક માઉન્ટ કર્યું છે, અને એક સમયે એક કરતાં વધુ નોડ નહીં. તે તદ્દન મુશ્કેલ છે.

ખાસ કરીને આ હેતુઓ માટે, અમે આ બધી જટિલતાને છુપાવવા માટે અમારા ઑપરેટરમાં નમૂનાઓ બનાવ્યાં છે. અને તમે ખાલી કહી શકો છો: "હું દરેક ભૌતિક નોડ માટે અને આવા અને આવા માર્ગ સાથે ક્લિકહાઉસનો એક દાખલો રાખવા માંગુ છું."

પરંતુ માત્ર આપણે જ આ જરૂરિયાતની જરૂર નથી, તેથી કુબરનેટ્સના સજ્જનો પોતે પણ સમજે છે કે લોકો ભૌતિક ડિસ્કની ઍક્સેસ મેળવવા માંગે છે, તેથી તેઓ ત્રીજું સ્તર પ્રદાન કરે છે.

તે સ્થાનિક કહેવાય છે. અગાઉની સ્લાઇડથી વ્યવહારીક રીતે કોઈ તફાવત નથી. ફક્ત તે પહેલા જ મેન્યુઅલી પુષ્ટિ કરવી જરૂરી હતી કે અમે આ પોડ્સ નોડથી નોડમાં સ્થાનાંતરિત કરી શકતા નથી, કારણ કે તે સ્થાનિક ભૌતિક ડિસ્કના અમુક પાથ સાથે જોડાયેલા હોવા જોઈએ, પરંતુ હવે આ બધું જ્ઞાન કુબરનેટ્સમાં જ સમાવિષ્ટ છે. અને તે રૂપરેખાંકિત કરવા માટે ખૂબ સરળ હોવાનું બહાર આવ્યું છે.

ચાલો આપણી વ્યવહારિક સમસ્યા પર પાછા ફરીએ. ચાલો YAML ટેમ્પ્લેટ પર પાછા ફરીએ. અહીં અમારી પાસે વાસ્તવિક સ્ટોરેજ છે. અમે તેના પર પાછા આવ્યા છીએ. અમે k8s ની જેમ ક્લાસિક VolumeClaim ટેમ્પલેટ સેટ કર્યું છે. અને અમે વર્ણન કરીએ છીએ કે અમને કયા પ્રકારનો સંગ્રહ જોઈએ છે.

આ પછી, k8s સ્ટોરેજ માટે વિનંતી કરશે. તે અમને સ્ટેટફુલસેટમાં ફાળવશે. અને અંતે તે ક્લિકહાઉસના નિકાલ પર રહેશે.

અમારી પાસે આ યોજના હતી. અમારું પર્સિસ્ટન્ટ સ્ટોરેજ લાલ હતું, જે એવું લાગતું હતું કે તે કરવાની જરૂર છે.

અને તે લીલો થઈ જાય છે. હવે k8s ક્લસ્ટર સ્કીમ પર ક્લિકહાઉસ સંપૂર્ણપણે આખરીકૃત થઈ ગયું છે. અમારી પાસે શાર્ડ્સ, પ્રતિકૃતિઓ, ઝૂકીપર છે, અમારી પાસે એક વાસ્તવિક પર્સિસ્ટન્ટ છે, જે એક યા બીજી રીતે લાગુ કરવામાં આવે છે. આ યોજના પહેલેથી જ સંપૂર્ણ રીતે કાર્યરત છે.

અમે જીવવાનું ચાલુ રાખીએ છીએ. અમારું ક્લસ્ટર વિકસી રહ્યું છે. અને એલેક્સી પ્રયાસ કરે છે, અને ક્લિકહાઉસનું નવું સંસ્કરણ પ્રકાશિત કરે છે.

એક વ્યવહારુ કાર્ય ઉદ્ભવે છે - અમારા ક્લસ્ટર પર ક્લિકહાઉસના નવા સંસ્કરણનું પરીક્ષણ કરવું. અને, સ્વાભાવિક રીતે, તમે આ બધું બહાર લાવવા માંગતા નથી; તમે દૂરના ખૂણામાં ક્યાંક એક પ્રતિકૃતિમાં નવું સંસ્કરણ મૂકવા માંગો છો, અને કદાચ એક નવું સંસ્કરણ નહીં, પરંતુ એક સાથે બે, કારણ કે તે વારંવાર બહાર આવે છે.

આ વિશે આપણે શું કહી શકીએ?

અહીં આપણી પાસે આવી જ તક છે. આ પોડ નમૂનાઓ છે. તમે લખી શકો છો કે અમારું ઓપરેટર તમને વિજાતીય ક્લસ્ટર બનાવવા માટે સંપૂર્ણપણે પરવાનગી આપે છે. તે. રૂપરેખાંકિત કરો, એક સમૂહમાં તમામ પ્રતિકૃતિઓથી શરૂ કરીને, દરેક વ્યક્તિગત પ્રતિકૃતિ સાથે સમાપ્ત થાય છે, અમને કયું સંસ્કરણ ક્લિકહાઉસ જોઈએ છે, અમને કયું સંસ્કરણ સંગ્રહ જોઈએ છે. અમને જોઈતી રૂપરેખાંકન સાથે અમે ક્લસ્ટરને સંપૂર્ણ રીતે ગોઠવી શકીએ છીએ.

ચાલો અંદર થોડા ઊંડા જઈએ. આ પહેલાં, અમે ક્લિકહાઉસની વિશિષ્ટતાઓના સંબંધમાં ક્લિકહાઉસ-ઓપરેટર કેવી રીતે કાર્ય કરે છે તે વિશે વાત કરી હતી.

હવે હું સામાન્ય રીતે કોઈપણ ઓપરેટર કેવી રીતે કાર્ય કરે છે, તેમજ તે K8s સાથે કેવી રીતે ક્રિયાપ્રતિક્રિયા કરે છે તે વિશે થોડાક શબ્દો કહેવા માંગુ છું.

ચાલો પહેલા K8s સાથે વાતચીત કરીએ. જ્યારે આપણે kubectl અરજી કરીએ ત્યારે શું થાય છે? અમારા ઑબ્જેક્ટ્સ API દ્વારા etcd માં દેખાય છે.

ઉદાહરણ તરીકે, મૂળભૂત કુબરનેટ્સ ઑબ્જેક્ટ્સ: પોડ, સ્ટેટફુલસેટ, સેવા, અને તેથી વધુ સૂચિની નીચે.

તે જ સમયે, હજી સુધી ભૌતિક કંઈ થતું નથી. આ ઑબ્જેક્ટ્સને ક્લસ્ટરમાં ભૌતિક બનાવવું આવશ્યક છે.

આ હેતુ માટે, એક નિયંત્રક દેખાય છે. કંટ્રોલર એ ખાસ k8s ઘટક છે જે આ વર્ણનોને સાકાર કરી શકે છે. તે જાણે છે કે શારીરિક રીતે કેવી રીતે અને શું કરવું. તે જાણે છે કે કન્ટેનર કેવી રીતે ચલાવવું, સર્વરને કામ કરવા માટે ત્યાં શું ગોઠવવાની જરૂર છે.

અને તે K8s માં આપણા પદાર્થોને સાકાર કરે છે.

પરંતુ અમે ફક્ત પોડ્સ અને સ્ટેટફુલસેટ્સ સાથે જ સંચાલન કરવા માંગીએ છીએ, અમે એક ક્લિકહાઉસ ઇન્સ્ટોલેશન બનાવવા માંગીએ છીએ, એટલે કે ક્લિકહાઉસ પ્રકારનો એક ઑબ્જેક્ટ, તેની સાથે સંપૂર્ણ રીતે કામ કરવા માટે. અત્યાર સુધી આવી કોઈ શક્યતા નથી.

પરંતુ K8s પાસે નીચેની સરસ વસ્તુ છે. અમે ઇચ્છીએ છીએ કે અમારી પાસે આ જટિલ એન્ટિટી જેવું ક્યાંક હોય જેમાં અમારા ક્લસ્ટરને પોડ્સ અને સ્ટેટફુલસેટથી એસેમ્બલ કરવામાં આવે.

અને આ માટે શું કરવાની જરૂર છે? પ્રથમ, કસ્ટમ રિસોર્સ ડેફિનેશન ચિત્રમાં આવે છે. તે શુ છે? આ K8s માટેનું વર્ણન છે, કે તમારી પાસે એક વધુ ડેટા પ્રકાર હશે, કે અમે પોડ, સ્ટેટફુલસેટમાં કસ્ટમ સ્ત્રોત ઉમેરવા માંગીએ છીએ, જે અંદરથી જટિલ હશે. આ ડેટા સ્ટ્રક્ચરનું વર્ણન છે.

અમે તેને ત્યાં kubectl apply દ્વારા પણ મોકલીએ છીએ. કુબરનેટ્સે ખુશીથી તે લીધું.

અને હવે અમારા સ્ટોરેજમાં, etcd માં ઑબ્જેક્ટ પાસે ClickHouseInstallation નામના કસ્ટમ સ્ત્રોતને રેકોર્ડ કરવાની તક છે.

પરંતુ હવે આગળ કંઈ થશે નહીં. એટલે કે, જો આપણે હવે YAML ફાઇલ બનાવીએ કે જે આપણે શાર્ડ્સ અને પ્રતિકૃતિઓનું વર્ણન કરતાં જોઈએ છીએ અને કહીએ છીએ કે “kubectl apply,” તો Kubernetes તેને સ્વીકારશે, તેને etcd માં મૂકશે અને કહેશે: “સારું, પણ મને ખબર નથી કે શું કરવું. તેની સાથે. ક્લિકહાઉસ ઇન્સ્ટોલેશન કેવી રીતે જાળવવું તે મને ખબર નથી."

તદનુસાર, નવા ડેટા પ્રકારને સેવા આપવા માટે કુબરનેટ્સને મદદ કરવા માટે અમને કોઈની જરૂર છે. ડાબી બાજુએ અમારી પાસે મૂળ કુબરનેટ્સ નિયંત્રક છે જે મૂળ ડેટા પ્રકારો સાથે કામ કરે છે. અને જમણી બાજુએ આપણી પાસે કસ્ટમ કંટ્રોલર હોવું જોઈએ જે કસ્ટમ ડેટા પ્રકારો સાથે કામ કરી શકે.

અને બીજી રીતે તેને ઓપરેટર કહેવામાં આવે છે. મેં તેને ખાસ કરીને અહીં કુબરનેટ્સ તરીકે સામેલ કર્યું છે, કારણ કે તે K8 ની બહાર પણ ચલાવી શકાય છે. મોટેભાગે, અલબત્ત, બધા ઓપરેટરો કુબરનેટ્સમાં ચલાવવામાં આવે છે, પરંતુ તેને બહાર ઊભા રહેવાથી કંઈપણ અટકાવતું નથી, તેથી અહીં તેને ખાસ બહાર ખસેડવામાં આવે છે.

અને બદલામાં, કસ્ટમ કંટ્રોલર, જેને ઓપરેટર તરીકે પણ ઓળખવામાં આવે છે, તે API દ્વારા કુબરનેટ્સ સાથે ક્રિયાપ્રતિક્રિયા કરે છે. તે પહેલાથી જ જાણે છે કે API સાથે કેવી રીતે ક્રિયાપ્રતિક્રિયા કરવી. અને તે પહેલેથી જ જાણે છે કે આપણે કસ્ટમ સ્ત્રોતમાંથી જટિલ સર્કિટને કેવી રીતે સાકાર કરવી. આ ઓપરેટર શું કરે છે તે બરાબર છે.

ઓપરેટર કેવી રીતે કામ કરે છે? ચાલો તે કેવી રીતે કરે છે તે જોવા માટે જમણી બાજુએ જોઈએ. ચાલો જાણીએ કે ઓપરેટર આ બધું કેવી રીતે સાકાર કરે છે અને K8s સાથે કેવી રીતે વધુ ક્રિયાપ્રતિક્રિયા થાય છે.

ઓપરેટર એક પ્રોગ્રામ છે. તેણી ઘટના લક્ષી છે. ઓપરેટર Kubernetes API નો ઉપયોગ કરીને ઇવેન્ટ્સમાં સબ્સ્ક્રાઇબ કરે છે. Kubernetes API માં એન્ટ્રી પોઈન્ટ છે જ્યાં તમે ઇવેન્ટ્સ માટે સબ્સ્ક્રાઇબ કરી શકો છો. અને જો K8s માં કંઈક બદલાય છે, તો કુબરનેટ્સ દરેકને ઇવેન્ટ્સ મોકલે છે, એટલે કે. જેણે પણ આ API પોઈન્ટ પર સબ્સ્ક્રાઇબ કર્યું છે તેને સૂચનાઓ પ્રાપ્ત થશે.

ઑપરેટર ઇવેન્ટ્સ માટે સબ્સ્ક્રાઇબ કરે છે અને અમુક પ્રકારની પ્રતિક્રિયા કરવી આવશ્યક છે. તેનું કાર્ય ઉભરતી ઘટનાઓનો જવાબ આપવાનું છે.

ઇવેન્ટ્સ ચોક્કસ અપડેટ્સ દ્વારા જનરેટ થાય છે. ClickHouseInstallation ના વર્ણન સાથેની અમારી YAML ફાઇલ આવે છે. તે kubectl apply દ્વારા etcd પર ગયો. ત્યાં એક ઇવેન્ટ ટ્રિગર થઈ, અને પરિણામે આ ઇવેન્ટ ક્લિકહાઉસ-ઓપરેટર પર આવી. ઓપરેટરને આ વર્ણન મળ્યું. અને તેણે કંઈક કરવું જોઈએ. જો ClickHouseInstallation ઑબ્જેક્ટ માટે અપડેટ આવી ગયું હોય, તો તમારે ક્લસ્ટર અપડેટ કરવાની જરૂર છે. અને ઑપરેટરનું કાર્ય ક્લસ્ટરને અપડેટ કરવાનું છે.

તે શુ કરી રહ્યો છે? પ્રથમ, આપણે આ અપડેટ સાથે શું કરીશું તે માટે એક એક્શન પ્લાન તૈયાર કરવાની જરૂર છે. અપડેટ્સ ખૂબ નાના હોઈ શકે છે, એટલે કે. YAML એક્ઝેક્યુશનમાં નાનું છે, પરંતુ ક્લસ્ટર પર ખૂબ મોટા ફેરફારો કરી શકે છે. તેથી, ઓપરેટર એક યોજના બનાવે છે, અને પછી તે તેને વળગી રહે છે.

આ યોજના અનુસાર, તે શીંગો, સેવાઓને સાકાર કરવા માટે આ રચનાને અંદરથી રાંધવાનું શરૂ કરે છે, એટલે કે. તેનું મુખ્ય કાર્ય શું છે તે કરો. કુબરનેટ્સમાં ક્લિકહાઉસ ક્લસ્ટર કેવી રીતે બનાવવું તે આ રીતે છે.

હવે આવી એક રસપ્રદ વાતને સ્પર્શ કરીએ. આ કુબરનેટ્સ અને ઓપરેટર વચ્ચેની જવાબદારીનું વિભાજન છે, એટલે કે. કુબરનેટ્સ શું કરે છે, ઓપરેટર શું કરે છે અને તેઓ એકબીજા સાથે કેવી રીતે ક્રિયાપ્રતિક્રિયા કરે છે.

કુબરનેટ્સ સિસ્ટમ વસ્તુઓ માટે જવાબદાર છે, એટલે કે. ઑબ્જેક્ટના મૂળભૂત સમૂહ માટે કે જેને સિસ્ટમ-સ્કોપ તરીકે અર્થઘટન કરી શકાય છે. કુબરનેટ્સ જાણે છે કે પોડ્સ કેવી રીતે લોંચ કરવું, કન્ટેનર કેવી રીતે ફરીથી શરૂ કરવું, વોલ્યુમ કેવી રીતે માઉન્ટ કરવું, ConfigMap સાથે કેવી રીતે કામ કરવું, એટલે કે. દરેક વસ્તુ જેને સિસ્ટમ કહી શકાય.

ઓપરેટરો ડોમેન્સમાં કાર્ય કરે છે. દરેક ઓપરેટર તેના પોતાના વિષય વિસ્તાર માટે બનાવવામાં આવે છે. અમે તે ક્લિકહાઉસ માટે કર્યું.

અને ઓપરેટર વિષય વિસ્તારના સંદર્ભમાં ચોક્કસ રીતે ક્રિયાપ્રતિક્રિયા કરે છે, જેમ કે પ્રતિકૃતિ ઉમેરવી, ડાયાગ્રામ બનાવવો, મોનિટરિંગ સેટ કરવું. આ વિભાજનમાં પરિણમે છે.

જ્યારે આપણે એડ પ્રતિકૃતિ ક્રિયા કરીએ છીએ ત્યારે જવાબદારીનું આ વિભાજન કેવી રીતે થાય છે તેનું એક વ્યવહારુ ઉદાહરણ જોઈએ.

ઓપરેટરને એક કાર્ય પ્રાપ્ત થાય છે - એક પ્રતિકૃતિ ઉમેરવા માટે. ઓપરેટર શું કરે છે? ઓપરેટર ગણતરી કરશે કે એક નવો સ્ટેટફુલસેટ બનાવવાની જરૂર છે, જેમાં આવા અને આવા નમૂનાઓ, વોલ્યુમ ક્લેમનું વર્ણન કરવું આવશ્યક છે.

તેણે તે બધું તૈયાર કર્યું અને તેને K8s પર મોકલ્યું. તે કહે છે કે તેને ConfigMap, StatefulSet, વોલ્યુમની જરૂર છે. કુબરનેટ્સ કાર્યરત છે. તે મૂળભૂત એકમોને સાકાર કરે છે જેની સાથે તે કાર્ય કરે છે.

અને પછી ક્લિકહાઉસ-ઓપરેટર ફરીથી રમતમાં આવે છે. તેની પાસે પહેલેથી જ ભૌતિક પોડ છે જેના પર તે પહેલેથી જ કંઈક કરી શકે છે. અને ક્લિકહાઉસ-ઓપરેટર ફરીથી ડોમેન શરતોમાં કામ કરે છે. તે. ખાસ કરીને ક્લિકહાઉસ, ક્લસ્ટરમાં પ્રતિકૃતિનો સમાવેશ કરવા માટે, તમારે પહેલા, આ ક્લસ્ટરમાં અસ્તિત્વમાં છે તે ડેટા સ્કીમાને રૂપરેખાંકિત કરવી આવશ્યક છે. અને, બીજું, આ પ્રતિકૃતિને મોનિટરિંગમાં શામેલ કરવી આવશ્યક છે જેથી કરીને તે સ્પષ્ટ રીતે શોધી શકાય. ઓપરેટર પહેલાથી જ આને ગોઠવે છે.

અને તે પછી જ ક્લિકહાઉસ પોતે જ રમતમાં આવે છે, એટલે કે. અન્ય ઉચ્ચ સ્તરની એન્ટિટી. આ પહેલેથી જ ડેટાબેઝ છે. તેનું પોતાનું ઉદાહરણ છે, બીજી રૂપરેખાંકિત પ્રતિકૃતિ કે જે ક્લસ્ટરમાં જોડાવા માટે તૈયાર છે.

તે તારણ આપે છે કે પ્રતિકૃતિ ઉમેરતી વખતે અમલ અને જવાબદારીના વિભાજનની સાંકળ ખૂબ લાંબી છે.

અમે અમારા વ્યવહારુ કાર્યો ચાલુ રાખીએ છીએ. જો તમારી પાસે પહેલેથી જ ક્લસ્ટર છે, તો તમે રૂપરેખાંકન સ્થાનાંતરિત કરી શકો છો.

અમે તેને બનાવ્યું છે જેથી તમે વર્તમાન xml માં પેસ્ટ કરી શકો, જેને ClickHouse સમજે છે.

તમે ક્લિકહાઉસને ફાઇન-ટ્યુન કરી શકો છો. હોસ્ટપાથ, સ્થાનિક સ્ટોરેજને સમજાવતી વખતે મેં જે વાત કરી હતી તે જસ્ટ ઝોન્ડ ડિપ્લોયમેન્ટ છે. આ રીતે ઝોન્ડ ડિપ્લોયમેન્ટ યોગ્ય રીતે કરવું.

આગામી વ્યવહારુ કાર્ય મોનીટરીંગ છે.

જો અમારું ક્લસ્ટર બદલાય છે, તો અમારે સમયાંતરે મોનિટરિંગ ગોઠવવાની જરૂર છે.

ચાલો ડાયાગ્રામ જોઈએ. આપણે અહીં લીલા તીરો જોઈ લીધા છે. હવે ચાલો લાલ તીરો જોઈએ. આ રીતે અમે અમારા ક્લસ્ટરને મોનિટર કરવા માંગીએ છીએ. ક્લિકહાઉસ ક્લસ્ટરમાંથી મેટ્રિક્સ પ્રોમિથિયસમાં અને પછી ગ્રાફનામાં કેવી રીતે આવે છે.

મોનીટરીંગ કરવામાં મુશ્કેલી શું છે? શા માટે આને અમુક પ્રકારની સિદ્ધિ તરીકે રજૂ કરવામાં આવે છે? મુશ્કેલી ગતિશીલતામાં રહેલી છે. જ્યારે અમારી પાસે એક ક્લસ્ટર હોય અને તે સ્થિર હોય, ત્યારે અમે એક વાર મોનિટરિંગ સેટ કરી શકીએ છીએ અને હવે ચિંતા નહીં કરીએ.

પરંતુ જો આપણી પાસે ઘણાં બધાં ક્લસ્ટરો છે, અથવા કંઈક સતત બદલાતું રહે છે, તો પ્રક્રિયા ગતિશીલ છે. અને સતત દેખરેખને ફરીથી ગોઠવવું એ સંસાધનો અને સમયનો બગાડ છે, એટલે કે. પણ માત્ર આળસ. આ સ્વચાલિત હોવું જરૂરી છે. મુશ્કેલી પ્રક્રિયાની ગતિશીલતામાં રહેલી છે. અને ઓપરેટર આને ખૂબ સારી રીતે સ્વચાલિત કરે છે.

અમારા ક્લસ્ટરનો વિકાસ કેવી રીતે થયો? શરૂઆતમાં તે એવો હતો.

પછી તે આના જેવો હતો.

અંતે, તે આના જેવો બન્યો.

અને મોનીટરીંગ ઓપરેટર દ્વારા આપોઆપ કરવામાં આવે છે. પ્રવેશનો સિંગલ પોઇન્ટ.

અને બહાર નીકળતી વખતે આપણે ગ્રાફના ડેશબોર્ડ પર નજર કરીએ છીએ કે આપણા ક્લસ્ટરનું જીવન અંદર કેવી રીતે ઉકળી રહ્યું છે.

માર્ગ દ્વારા, Grafana ડેશબોર્ડ પણ સીધા સ્ત્રોત કોડમાં અમારા ઓપરેટર સાથે વિતરિત કરવામાં આવે છે. તમે કનેક્ટ કરી શકો છો અને ઉપયોગ કરી શકો છો. અમારા DevOps એ મને આ સ્ક્રીનશોટ આપ્યો.

આપણે આગળ ક્યાં જવું ગમશે? આ:

• પરીક્ષણ ઓટોમેશન વિકસાવો. મુખ્ય કાર્ય એ નવા સંસ્કરણોનું સ્વચાલિત પરીક્ષણ છે.
• અમે ખરેખર ZooKeeper સાથે એકીકરણને સ્વચાલિત કરવા માંગીએ છીએ. અને ZooKeeper-operator સાથે સંકલન કરવાની યોજના છે. તે. ZooKeeper માટે ઓપરેટર લખવામાં આવ્યું છે અને તે તાર્કિક છે કે બે ઓપરેટરો વધુ અનુકૂળ ઉકેલ બનાવવા માટે એકીકૃત થવાનું શરૂ કરે છે.
• અમે વધુ જટિલ મહત્વપૂર્ણ સંકેતો કરવા માંગીએ છીએ.
• મેં લીલા રંગમાં પ્રકાશિત કર્યું છે કે અમે ટેમ્પલેટ્સના વારસાની નજીક આવી રહ્યા છીએ - થઈ ગયું છે, એટલે કે ઑપરેટરના આગામી પ્રકાશન સાથે અમારી પાસે ટેમ્પ્લેટ્સનો વારસો પહેલેથી જ હશે. આ એક શક્તિશાળી સાધન છે જે તમને ટુકડાઓમાંથી જટિલ રૂપરેખાંકનો બનાવવા માટે પરવાનગી આપે છે.
• અને અમે જટિલ કાર્યોનું ઓટોમેશન ઈચ્છીએ છીએ. મુખ્ય એક રી-શેર્ડિંગ છે.

ચાલો કેટલાક મધ્યવર્તી પરિણામો લઈએ.

પરિણામે આપણને શું મળે છે? અને તે કરવું યોગ્ય છે કે નહીં? શું ડેટાબેઝને કુબરનેટ્સમાં ખેંચવાનો પ્રયાસ કરવો અને સામાન્ય રીતે ઓપરેટર અને ખાસ કરીને એલિટનીટી ઓપરેટરનો ઉપયોગ કરવો જરૂરી છે?

આઉટપુટ પર આપણને મળે છે:

• રૂપરેખાંકન, જમાવટ અને જાળવણીનું નોંધપાત્ર સરળીકરણ અને ઓટોમેશન.
• તરત જ બિલ્ટ-ઇન મોનિટરિંગ.
• અને જટિલ પરિસ્થિતિઓ માટે ઉપયોગમાં લેવા માટે તૈયાર કોડિફાઇડ નમૂનાઓ. પ્રતિકૃતિ ઉમેરવા જેવી ક્રિયા મેન્યુઅલી કરવાની જરૂર નથી. ઓપરેટર આ કરે છે.

માત્ર એક છેલ્લો પ્રશ્ન બાકી છે. અમારી પાસે પહેલેથી જ Kubernetes, વર્ચ્યુઅલાઈઝેશનમાં ડેટાબેઝ છે. આવા સોલ્યુશનના પ્રદર્શન વિશે શું, ખાસ કરીને કારણ કે ક્લિકહાઉસ પ્રભાવ માટે ઑપ્ટિમાઇઝ કરવામાં આવ્યું છે?

જવાબ એ છે કે બધું સારું છે! હું વિગતમાં નહીં જઈશ; આ એક અલગ અહેવાલનો વિષય છે.

પરંતુ TSBS જેવા પ્રોજેક્ટ છે. તેનું મુખ્ય કાર્ય શું છે? આ ડેટાબેઝ પરફોર્મન્સ ટેસ્ટ છે. ગરમ સાથે ગરમ, નરમને નરમ સાથે સરખાવવાનો આ પ્રયાસ છે.

તે કેવી રીતે કામ કરે છે? એક ડેટા સેટ જનરેટ થાય છે. પછી ડેટાનો આ સેટ ટેસ્ટના સમાન સેટનો ઉપયોગ કરીને વિવિધ ડેટાબેઝ પર ચલાવવામાં આવે છે. અને દરેક ડેટાબેઝ તે કેવી રીતે જાણે છે તે રીતે એક સમસ્યા હલ કરે છે. અને પછી તમે પરિણામોની તુલના કરી શકો છો.

તે પહેલાથી જ ડેટાબેઝના વિશાળ સમૂહને સપોર્ટ કરે છે. મેં ત્રણ મુખ્ય ઓળખી કાઢ્યા છે. આ:

• ટાઇમસ્કેલડીબી.
• InfluxDB.
• ક્લિક હાઉસ.

અન્ય સમાન ઉકેલ સાથે પણ સરખામણી કરવામાં આવી હતી. રેડશિફ્ટ સાથે સરખામણી. સરખામણી એમેઝોન પર કરવામાં આવી હતી. ક્લિકહાઉસ પણ આ બાબતમાં દરેકથી આગળ છે.

મેં જે કહ્યું તેનાથી કયા તારણો કાઢી શકાય?

• કુબરનેટ્સમાં ડીબી શક્ય છે. કદાચ કોઈપણ શક્ય છે, પરંતુ એકંદરે એવું લાગે છે કે તે શક્ય છે. Kubernetes માં ClickHouse અમારા ઓપરેટરની મદદથી ચોક્કસપણે શક્ય છે.
• ઑપરેટર પ્રક્રિયાઓને સ્વચાલિત કરવામાં મદદ કરે છે અને ખરેખર જીવન સરળ બનાવે છે.
• પ્રદર્શન સામાન્ય છે.
• અને તે અમને લાગે છે કે આનો ઉપયોગ કરી શકાય છે અને થવો જોઈએ.

ઓપન સોર્સ - અમારી સાથે જોડાઓ!

મેં પહેલેથી જ કહ્યું છે તેમ, ઓપરેટર સંપૂર્ણપણે ઓપન સોર્સ પ્રોડક્ટ છે, તેથી જો મહત્તમ સંખ્યામાં લોકો તેનો ઉપયોગ કરે તો તે ખૂબ જ સારું રહેશે. અમારી સાથ જોડાઓ! અમે તમારા બધા માટે રાહ જોઈ રહ્યા છીએ!

સૌનો આભાર!

પ્રશ્નો

રિપોર્ટ માટે આભાર! મારું નામ એન્ટોન છે. હું SEMrush થી છું. હું આશ્ચર્ય પામી રહ્યો છું કે લોગીંગ સાથે શું થઈ રહ્યું છે. અમે મોનિટરિંગ વિશે સાંભળીએ છીએ, પરંતુ લૉગિંગ વિશે કંઈ નથી, જો આપણે સમગ્ર ક્લસ્ટર વિશે વાત કરીએ. ઉદાહરણ તરીકે, અમે હાર્ડવેર પર ક્લસ્ટર ઉભા કર્યા છે. અને અમે કેન્દ્રિય લોગીંગનો ઉપયોગ કરીએ છીએ, તેમને પ્રમાણભૂત માધ્યમોનો ઉપયોગ કરીને સામાન્ય ઢગલામાં એકત્રિત કરીએ છીએ. અને પછી ત્યાંથી આપણને રુચિ હોય તેવો ડેટા મળે છે.

સારો પ્રશ્ન, એટલે કે ટુડો લિસ્ટમાં લોગ ઇન કરવું. અમારા ઑપરેટર હજી સુધી આને સ્વચાલિત કરતું નથી. તે હજી પણ વિકાસ કરી રહ્યું છે, પ્રોજેક્ટ હજી તદ્દન નાનો છે. અમે લોગીંગની જરૂરિયાત સમજીએ છીએ. આ પણ ખૂબ જ મહત્વનો વિષય છે. અને તે કદાચ દેખરેખ કરતાં ઓછું મહત્વનું નથી. પરંતુ અમલીકરણ માટેની સૂચિમાં પ્રથમ મોનિટરિંગ હતું. લોગીંગ હશે. સ્વાભાવિક રીતે, અમે ક્લસ્ટરના જીવનના તમામ પાસાઓને સ્વચાલિત કરવાનો પ્રયાસ કરીએ છીએ. તેથી, જવાબ એ છે કે આ ક્ષણે ઓપરેટર, કમનસીબે, આ કેવી રીતે કરવું તે જાણતું નથી, પરંતુ તે યોજનાઓમાં છે, અમે તે કરીશું. જો તમે જોડાવા માંગતા હો, તો વિનંતી કરો, કૃપા કરીને.

નમસ્તે! રિપોર્ટ માટે આભાર! મારી પાસે પર્સિસ્ટન્ટ વોલ્યુમ્સ સંબંધિત પ્રમાણભૂત પ્રશ્ન છે. જ્યારે આપણે આ ઓપરેટર સાથે રૂપરેખાંકન બનાવીએ છીએ, ત્યારે ઓપરેટર કઈ રીતે નક્કી કરે છે કે કયા નોડ પર આપણી પાસે ચોક્કસ ડિસ્ક અથવા ફોલ્ડર જોડાયેલ છે? આપણે પહેલા તેને સમજાવવું જોઈએ કે કૃપા કરીને આ ગાંઠો પર અમારું ક્લિકહાઉસ મૂકો જેની પાસે ડિસ્ક છે?

જ્યાં સુધી હું સમજું છું, આ પ્રશ્ન સ્થાનિક સ્ટોરેજનું ચાલુ છે, ખાસ કરીને તેનો હોસ્ટપાથ ભાગ. આ સમગ્ર સિસ્ટમને સમજાવવા જેવું છે કે પોડને આવા અને આવા નોડ પર લોન્ચ કરવાની જરૂર છે, જેની સાથે અમારી પાસે ભૌતિક રીતે જોડાયેલ ડિસ્ક છે, જે આવા અને આવા પાથ સાથે માઉન્ટ થયેલ છે. આ એક આખો વિભાગ છે જેને મેં ખૂબ જ ઉપરછલ્લી રીતે સ્પર્શ કર્યો છે કારણ કે ત્યાં જવાબ ઘણો મોટો છે.

સંક્ષિપ્તમાં તે આના જેવો દેખાય છે. સ્વાભાવિક રીતે, આપણે આ વોલ્યુમોની જોગવાઈ કરવાની જરૂર છે. આ ક્ષણે, સ્થાનિક સ્ટોરેજમાં કોઈ ગતિશીલ જોગવાઈ નથી, તેથી DevOps એ ડિસ્ક પોતે જ, આ વોલ્યુમોને કાપી નાખવી જોઈએ. અને તેઓએ કુબરનેટ્સની જોગવાઈને સમજાવવી જોઈએ કે તમારી પાસે આવા અને આવા વર્ગના પર્સિસ્ટન્ટ વોલ્યુમો હશે, જે આવા અને આવા નોડ્સ પર સ્થિત છે. પછી તમારે કુબરનેટ્સને સમજાવવાની જરૂર પડશે કે આવા અને આવા સ્થાનિક સ્ટોરેજ ક્લાસની જરૂર હોય તેવા પોડ્સને લેબલનો ઉપયોગ કરીને ફક્ત આવા અને આવા નોડ્સ તરફ નિર્દેશિત કરવાની જરૂર છે. આ હેતુઓ માટે, ઑપરેટર પાસે અમુક પ્રકારનું લેબલ અને હોસ્ટ ઇન્સ્ટન્સ દીઠ એક અસાઇન કરવાની ક્ષમતા હોય છે. અને તે તારણ આપે છે કે પોડ્સને કુબરનેટ્સ દ્વારા ફક્ત નોડ્સ પર જ ચલાવવા માટે રૂટ કરવામાં આવશે જે સરળ શબ્દોમાં જરૂરિયાતો, લેબલોને પૂર્ણ કરે છે. એડમિનિસ્ટ્રેટર્સ જાતે જ લેબલ્સ અને પ્રોવિઝન ડિસ્ક અસાઇન કરે છે. અને પછી તે ભીંગડા કરે છે.

અને તે ત્રીજો વિકલ્પ છે, સ્થાનિક, જે આને થોડું સરળ બનાવવામાં મદદ કરે છે. મેં પહેલેથી જ ભાર મૂક્યો છે તેમ, ટ્યુનિંગ પર આ ઉદ્યમી કાર્ય છે, જે આખરે મહત્તમ પ્રદર્શન મેળવવામાં મદદ કરે છે.

મારે આને લગતો બીજો પ્રશ્ન છે. કુબરનેટ્સને એવી રીતે ડિઝાઇન કરવામાં આવી હતી કે આપણે નોડ ગુમાવીએ કે નહીં તેનાથી અમને કોઈ ફરક પડતો નથી. આ કિસ્સામાં આપણે શું કરવું જોઈએ જો આપણે નોડ ગુમાવ્યો હોય જ્યાં આપણો શાર્ડ અટકી ગયો હોય?

હા, કુબરનેટસ શરૂઆતમાં એવું હતું કે અમારી શીંગો સાથેનો અમારો સંબંધ ઢોર જેવો છે, પરંતુ અહીં અમારી સાથે દરેક ડિસ્ક પાલતુ જેવી બની જાય છે. એવી સમસ્યા છે કે આપણે ફક્ત તેમને ફેંકી શકતા નથી. અને કુબરનેટસનો વિકાસ એ દિશામાં જઈ રહ્યો છે કે તેને સંપૂર્ણપણે કાઢી નાખવામાં આવેલ સંસાધનની જેમ દાર્શનિક રીતે તેની સારવાર કરવી અશક્ય છે.

હવે એક વ્યવહારુ પ્રશ્ન માટે. જો તમે નોડ ગુમાવ્યો હોય જેના પર ડિસ્ક હતી તો શું કરવું? અહીં ઉચ્ચ કક્ષાએથી સમસ્યાનું નિરાકરણ કરવામાં આવી રહ્યું છે. ક્લિકહાઉસના કિસ્સામાં, અમારી પાસે પ્રતિકૃતિઓ છે જે ઉચ્ચ સ્તરે કાર્ય કરે છે, એટલે કે. ક્લિકહાઉસ સ્તરે.

પરિણામી સ્વભાવ શું છે? ડેટા ખોવાઈ ન જાય તેની ખાતરી કરવા માટે DevOps જવાબદાર છે. તેણે પ્રતિકૃતિને યોગ્ય રીતે સેટ કરવી જોઈએ અને ખાતરી કરવી જોઈએ કે પ્રતિકૃતિ ચાલી રહી છે. ક્લિકહાઉસ સ્તર પરની પ્રતિકૃતિમાં ડુપ્લિકેટ ડેટા હોવો આવશ્યક છે. આ એવી સમસ્યા નથી કે જે ઓપરેટર ઉકેલે છે. અને તે સમસ્યા નથી કે જે કુબરનેટ્સ પોતે ઉકેલે છે. આ ક્લિકહાઉસ સ્તર પર છે.

જો તમારી આયર્ન નોડ પડી જાય તો શું કરવું? અને તે તારણ આપે છે કે તમારે બીજું ઇન્સ્ટોલ કરવું પડશે, તેના પર ડિસ્કને યોગ્ય રીતે જોગવાઈ કરવી પડશે અને લેબલ્સ લાગુ કરવું પડશે. અને તે પછી, તે જરૂરિયાતોને પૂર્ણ કરશે કે કુબરનેટ્સ તેના પર ઇન્સ્ટન્સ પોડ લોન્ચ કરી શકે છે. કુબરનેટ્સ તેને લોન્ચ કરશે. તમારી શીંગોની સંખ્યા નિર્દિષ્ટ સંખ્યાને પહોંચી વળવા માટે પૂરતી નથી. તે મેં બતાવેલ ચક્રમાંથી પસાર થશે. અને ઉચ્ચતમ સ્તર પર, ક્લિકહાઉસ સમજી જશે કે અમે પ્રતિકૃતિ દાખલ કરી છે, તે હજુ પણ ખાલી છે અને અમારે તેમાં ડેટા ટ્રાન્સફર કરવાનું શરૂ કરવાની જરૂર છે. તે. આ પ્રક્રિયા હજી સારી રીતે સ્વચાલિત નથી.

રિપોર્ટ માટે આભાર! જ્યારે તમામ પ્રકારની બીભત્સ વસ્તુઓ થાય છે, ઓપરેટર ક્રેશ થાય છે અને પુનઃપ્રારંભ થાય છે, અને તે ક્ષણે ઘટનાઓ આવે છે, શું તમે કોઈક રીતે આને હેન્ડલ કરો છો?

જો ઓપરેટર ક્રેશ થાય અને પુનઃપ્રારંભ થાય તો શું થશે, ખરું?

હા. અને તે જ ક્ષણે ઘટનાઓ આવી.

આ કિસ્સામાં શું કરવું તે કાર્ય આંશિક રીતે ઓપરેટર અને કુબરનેટ્સ વચ્ચે વહેંચાયેલું છે. કુબરનેટસમાં બનેલી ઘટનાને ફરીથી ચલાવવાની ક્ષમતા છે. તે રિપ્લે કરે છે. અને ઑપરેટરનું કાર્ય એ સુનિશ્ચિત કરવાનું છે કે જ્યારે ઇવેન્ટ લોગ તેના પર ફરીથી ચલાવવામાં આવે છે, ત્યારે આ ઇવેન્ટ્સ અયોગ્ય છે. અને જેથી એક જ ઘટનાનું વારંવાર બનવું આપણી સિસ્ટમને તોડે નહીં. અને અમારા ઓપરેટર આ કાર્યનો સામનો કરે છે.

નમસ્તે! રિપોર્ટ માટે આભાર! દિમિત્રી ઝવ્યાલોવ, કંપની સ્મેડોવા. શું ઓપરેટરમાં હેપ્રોક્સી સાથે રૂપરેખાંકિત કરવાની ક્ષમતા ઉમેરવાની યોજના છે? મને સ્ટાન્ડર્ડ સિવાયના અન્ય બેલેન્સરમાં રસ હશે, જેથી તે સ્માર્ટ હોય અને સમજે કે ક્લિકહાઉસ ખરેખર ત્યાં છે.

શું તમે પ્રવેશ વિશે વાત કરો છો?

હા, Ingress ને haproxy થી બદલો. હેપ્રોક્સીમાં તમે ક્લસ્ટરની ટોપોલોજીનો ઉલ્લેખ કરી શકો છો જ્યાં તેની પ્રતિકૃતિઓ છે.

અમે હજી સુધી તેના વિશે વિચાર્યું નથી. જો તમને તેની જરૂર હોય અને તે શા માટે જરૂરી છે તે સમજાવી શકો, તો તેનો અમલ કરવો શક્ય બનશે, ખાસ કરીને જો તમે ભાગ લેવા માંગતા હોવ. વિકલ્પ પર વિચાર કરવામાં અમને આનંદ થશે. ટૂંકો જવાબ ના છે, અમારી પાસે હાલમાં આવી કાર્યક્ષમતા નથી. ટિપ માટે આભાર, અમે આ બાબતની તપાસ કરીશું. અને જો તમે ઉપયોગના કેસને પણ સમજાવો અને વ્યવહારમાં તે શા માટે જરૂરી છે, ઉદાહરણ તરીકે, GitHub પર મુદ્દાઓ બનાવો, તો તે સરસ રહેશે.

પહેલેથી જ છે.

દંડ. અમે કોઈપણ સૂચનો માટે ખુલ્લા છીએ. અને હેપ્રોક્સી ટુડો લિસ્ટમાં ઉમેરવામાં આવે છે. ટુડો લિસ્ટ વધી રહ્યું છે, હજુ સંકોચાઈ રહ્યું નથી. પરંતુ આ સારું છે, તેનો અર્થ એ કે ઉત્પાદન માંગમાં છે.

સોર્સ: www.habr.com