ડોમક્લિક પર કુબરનેટ્સ: 1000 માઇક્રો સર્વિસિસના ક્લસ્ટરનું સંચાલન કરીને શાંતિથી કેવી રીતે સૂવું

મારું નામ વિક્ટર યાગોફારોવ છે, અને હું ઓપ્સ (ઓપરેશન્સ) ટીમમાં ટેક્નિકલ ડેવલપમેન્ટ મેનેજર તરીકે ડોમક્લિક ખાતે કુબરનેટ્સ પ્લેટફોર્મ વિકસાવી રહ્યો છું. હું તમને અમારી Dev <-> Ops પ્રક્રિયાઓની રચના વિશે, રશિયામાં સૌથી મોટા k8s ક્લસ્ટરોમાંના એકના સંચાલનની વિશેષતાઓ વિશે તેમજ અમારી ટીમ વાપરે છે તે DevOps/SRE પ્રેક્ટિસ વિશે જણાવવા માંગુ છું.

ટીમ ઑપ્સ

ઓપ્સ ટીમમાં હાલમાં 15 લોકો છે. તેમાંથી ત્રણ ઓફિસ માટે જવાબદાર છે, બે અલગ-અલગ ટાઈમ ઝોનમાં કામ કરે છે અને રાત્રે સહિત ઉપલબ્ધ છે. આમ, ઑપ્સમાંથી કોઈ વ્યક્તિ હંમેશા મોનિટર પર હોય છે અને કોઈપણ જટિલતાની ઘટનાનો જવાબ આપવા માટે તૈયાર હોય છે. અમારી પાસે નાઇટ શિફ્ટ નથી, જે અમારી માનસિકતાને સાચવે છે અને દરેકને પૂરતી ઊંઘ લેવાની તક આપે છે અને માત્ર કોમ્પ્યુટર પર જ નવરાશનો સમય પસાર કરવાની તક આપે છે.

દરેક વ્યક્તિ પાસે અલગ-અલગ ક્ષમતાઓ હોય છે: નેટવર્કર્સ, DBAs, ELK સ્ટેક નિષ્ણાતો, Kubernetes એડમિન્સ/ડેવલપર્સ, મોનિટરિંગ, વર્ચ્યુઅલાઈઝેશન, હાર્ડવેર નિષ્ણાતો વગેરે. એક વસ્તુ દરેકને એક કરે છે - દરેક વ્યક્તિ અમુક અંશે આપણામાંના કોઈપણને બદલી શકે છે: ઉદાહરણ તરીકે, k8s ક્લસ્ટરમાં નવા નોડ્સ દાખલ કરો, PostgreSQL અપડેટ કરો, CI/CD + Ansible પાઇપલાઇન લખો, Python/Bash/Go માં કંઈક સ્વચાલિત કરો, એક ભાગ જોડો DPC ને હાર્ડવેરનું. કોઈપણ ક્ષેત્રમાં મજબૂત ક્ષમતાઓ પ્રવૃત્તિની દિશા બદલવામાં અને કોઈ અન્ય ક્ષેત્રમાં પંપ શરૂ કરવામાં દખલ કરતી નથી. ઉદાહરણ તરીકે, મને પોસ્ટગ્રેએસક્યુએલ નિષ્ણાત તરીકે એક કંપનીમાં નોકરી મળી, અને હવે મારી જવાબદારીનું મુખ્ય ક્ષેત્ર કુબરનેટ્સ ક્લસ્ટર્સ છે. ટીમમાં, કોઈપણ વૃદ્ધિ માત્ર આવકાર્ય છે અને ખભાની ભાવના ખૂબ વિકસિત છે.

માર્ગ દ્વારા, અમે શિકાર કરીએ છીએ. ઉમેદવારો માટેની આવશ્યકતાઓ ખૂબ પ્રમાણભૂત છે. મારા માટે અંગત રીતે, તે મહત્વનું છે કે વ્યક્તિ ટીમમાં બંધબેસે છે, બિન-વિરોધાભાસી છે, પણ તેના દૃષ્ટિકોણનો બચાવ કેવી રીતે કરવો તે પણ જાણે છે, વિકાસ કરવા માંગે છે અને કંઈક નવું કરવામાં, તેના વિચારો પ્રદાન કરવામાં ડરતો નથી. ઉપરાંત, સ્ક્રિપ્ટીંગ ભાષાઓમાં પ્રોગ્રામિંગ કુશળતા, Linux અને અંગ્રેજીની મૂળભૂત બાબતોનું જ્ઞાન જરૂરી છે. અંગ્રેજીની જરૂર એટલા માટે છે કે ફૅકૅપના કિસ્સામાં વ્યક્તિ 10 મિનિટમાં નહીં પણ 10 સેકન્ડમાં સમસ્યાનો ઉકેલ ગૂગલ કરી શકે. લિનક્સનું ઊંડું જ્ઞાન ધરાવતા નિષ્ણાતો સાથે, હવે તે ખૂબ જ મુશ્કેલ છે: રમુજી, પરંતુ ત્રણમાંથી બે ઉમેદવારો પ્રશ્નનો જવાબ આપી શકતા નથી “લોડ એવરેજ શું છે? તેમાં શું સમાયેલું છે? ”, અને પ્રશ્ન“ સિશ પ્રોગ્રામમાંથી કોર ડમ્પ કેવી રીતે એકત્રિત કરવો” એ સુપરહ્યુમન્સની દુનિયામાંથી કંઈક માનવામાં આવે છે ... અથવા ડાયનાસોર. આપણે આને સહન કરવું પડશે, કારણ કે સામાન્ય રીતે લોકોએ અન્ય ક્ષમતાઓ ખૂબ વિકસિત કરી છે, અને અમે Linux શીખવીશું. "મેઘની આધુનિક દુનિયામાં DevOps એન્જિનિયરને આ બધું જાણવાની જરૂર કેમ છે" પ્રશ્નનો જવાબ લેખના અવકાશની બહાર છોડવો પડશે, પરંતુ ત્રણ શબ્દોમાં: આ બધું જરૂરી છે.

સાધનો આદેશ

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

ઑપ્સ ટીમ વિકાસકર્તાઓ માટે પાઇપલાઇન્સ લખતી નથી, પરંતુ તેમને લેખિતમાં કોઈપણ મુદ્દા પર સલાહ આપી શકે છે (કેટલાક પાસે હજી પણ હેલ્મ 3 છે).

DevOps

DevOps માટે, અમે તેને આના જેવું જોઈએ છીએ:

દેવ ટીમો કોડ લખે છે, તેને કોન્ફર ટુ dev -> qa/stage -> prod દ્વારા રોલઆઉટ કરે છે. કોડ ધીમું ન થાય અને ભૂલો ન થાય તેની ખાતરી કરવાની જવાબદારી દેવ અને ઑપ્સ ટીમની છે. દિવસના સમયે, ઑપ્સ ટીમના ફરજ અધિકારીએ તેમની અરજી સાથે કોઈ ઘટનાનો જવાબ આપવો જોઈએ, અને સાંજે અને રાત્રે, ડ્યુટી એડમિન (ઓપ્સ) એ ડેવલપરને જગાડવો જોઈએ જો તે ખાતરીપૂર્વક જાણતો હોય કે સમસ્યા નથી. ઈન્ફ્રાસ્ટ્રક્ચરમાં. મોનિટરિંગમાં તમામ મેટ્રિક્સ અને ચેતવણીઓ આપમેળે અથવા અર્ધ-સ્વચાલિત રીતે દેખાય છે.

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

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

માર્ગ દ્વારા, અમારી પાસે મોનોલિથ બિલકુલ નથી, ફક્ત માઇક્રોસર્વિસિસ છે. તેમની સંખ્યા અત્યાર સુધી prod k900s ક્લસ્ટરમાં 1000 અને 8 ની વચ્ચે વધઘટ થાય છે, જો સંખ્યા દ્વારા માપવામાં આવે તો જમાવટ. શીંગોની સંખ્યા 1700 અને 2000 ની વચ્ચે વધઘટ થાય છે. પ્રોડ ક્લસ્ટરમાં શીંગો હવે 2000 ની આસપાસ છે.

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

સંસાધન વ્યવસ્થાપન

મોનીટરીંગ

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

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

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

"ક્યુબ" માં ટીમ સંસાધનો

ઉદાહરણો સાથે આગળ વધતા પહેલા, તે સમજાવવા યોગ્ય છે કે અમારી પાસે કેવી રીતે સંસાધન ફાળવણી છે સૂક્ષ્મ સેવાઓ.

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

ટીમ દીઠ સંસાધન ફાળવણીનું ઉદાહરણ:

namespaces:

  chat-team:
    pods: 23
    limits:
      cpu: 11
      memory: 20Gi
    requests:
      cpu: 11
      memory: 20Gi

વિનંતીઓ અને મર્યાદાઓ

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

આ પરિસ્થિતિમાંથી બહાર નીકળવાનો સાચો રસ્તો એ છે કે વાસ્તવિક સંસાધન વપરાશને જોવો અને વિનંતી કરેલ રકમ (વિનંતી) સાથે તેની તુલના કરવી.

ઉપરોક્ત સ્ક્રીનશોટ દર્શાવે છે કે "વિનંતી કરેલ" (વિનંતી કરેલ) CPU એ થ્રેડોની વાસ્તવિક સંખ્યા માટે પસંદ કરેલ છે, અને મર્યાદાઓ CPU થ્રેડોની વાસ્તવિક સંખ્યા કરતાં વધી શકે છે =)

હવે ચાલો અમુક નેમસ્પેસ પર નજીકથી નજર કરીએ (મેં નેમસ્પેસ ક્યુબ-સિસ્ટમ પસંદ કર્યું - "ક્યુબ" ના ઘટકો માટે સિસ્ટમ નેમસ્પેસ) અને ખરેખર ઉપયોગમાં લેવાયેલ પ્રોસેસર સમય અને વિનંતી કરેલ મેમરીનો ગુણોત્તર જુઓ:

તે સ્પષ્ટ છે કે સિસ્ટમ સેવાઓ માટે વાસ્તવમાં ઉપયોગમાં લેવાતા કરતાં ઘણી વધુ મેમરી અને CPU આરક્ષિત છે. ક્યુબે-સિસ્ટમના કિસ્સામાં, આ વાજબી છે: એવું બન્યું કે ટોચ પરના nginx પ્રવેશ નિયંત્રક અથવા નોડેલોકલ્ડન્સ CPU પર આરામ કરે છે અને ઘણી બધી RAM ખાય છે, તેથી અહીં આવા માર્જિન વાજબી છે. વધુમાં, અમે છેલ્લા 3 કલાક માટે ચાર્ટ પર આધાર રાખી શકતા નથી: મોટા સમયગાળા દરમિયાન ઐતિહાસિક મેટ્રિક્સ જોવા માટે તે ઇચ્છનીય છે.

"ભલામણો" ની સિસ્ટમ વિકસાવવામાં આવી હતી. ઉદાહરણ તરીકે, અહીં તમે જોઈ શકો છો કે "મર્યાદા" (ઉપરની મંજૂરીવાળી પટ્ટી) વધારવામાં કયા સંસાધનો વધુ સારા રહેશે જેથી કરીને "થ્રોટલિંગ" ન થાય: તે ક્ષણ જ્યારે પોડ પહેલાથી જ ફાળવેલ સમય ક્વોન્ટમ માટે CPU અથવા મેમરી ખર્ચી ચૂક્યું હોય. અને તે "અનફ્રોઝન" થાય ત્યાં સુધી રાહ જોઈ રહ્યું છે:

અને અહીં એવી શીંગો છે જેણે તેમની ભૂખને મધ્યમ કરવી જોઈએ:

પર થ્રોટલિંગ + મોનિટરિંગ સંસાધનો, તમે એક કરતાં વધુ લેખ લખી શકો છો, તેથી ટિપ્પણીઓમાં પ્રશ્નો પૂછો. થોડા શબ્દોમાં, હું કહી શકું છું કે આવા મેટ્રિક્સને સ્વચાલિત કરવાનું કાર્ય ખૂબ જ મુશ્કેલ છે અને "વિન્ડો" ફંક્શન્સ અને "CTE" પ્રોમિથિયસ / વિક્ટોરિયામેટ્રિક્સ (આ શરતો અવતરણ ચિહ્નોમાં છે, કારણ કે ત્યાં ખૂબ જ સમય અને સંતુલિત કાર્યની જરૂર છે. PromQL માં આના જેવું લગભગ કંઈ નથી, અને તમારે ટેક્સ્ટની ઘણી સ્ક્રીનો પર ડરામણી પ્રશ્નોને ફેન્સિંગ કરવી પડશે અને તેમને ઑપ્ટિમાઇઝ કરવી પડશે).

પરિણામે, વિકાસકર્તાઓ પાસે "ક્યુબ" માં તેમની નેમસ્પેસને મોનિટર કરવા માટેના સાધનો છે અને તેઓ ક્યાં અને કયા સમયે કઈ એપ્લિકેશન સંસાધનોને "કટ" કરી શકે છે અને કયા પોડ્સને આખી રાત આખા CPU આપી શકાય તે પસંદ કરવામાં સક્ષમ છે.

પદ્ધતિઓ

હવે જેવી કંપનીમાં ફેશનેબલ, અમે DevOps- અને એસ.આર.ઇ.- પ્રેક્ટિશનર જ્યારે કોઈ કંપની પાસે 1000 માઇક્રોસર્વિસિસ હોય, લગભગ 350 ડેવલપર્સ અને સમગ્ર ઇન્ફ્રાસ્ટ્રક્ચર માટે 15 એડમિન હોય, ત્યારે તમારે "ફેશનેબલ" બનવું પડશે: આ બધા "બઝવર્ડ્સ" પાછળ દરેક વસ્તુ અને દરેક વસ્તુને સ્વચાલિત કરવાની તાત્કાલિક જરૂર છે, અને એડમિન્સને અડચણ ન હોવી જોઈએ. પ્રક્રિયાઓમાં.

ઑપ્સ તરીકે, અમે સેવાઓના પ્રતિભાવ સમય અને તેમની ભૂલોથી સંબંધિત વિકાસકર્તાઓ માટે વિવિધ મેટ્રિક્સ અને ડેશબોર્ડ પ્રદાન કરીએ છીએ.

અમે પદ્ધતિઓનો ઉપયોગ કરીએ છીએ જેમ કે: RED, વાપરવુ и ગોલ્ડન સિગ્નલ્સતેમને એકસાથે જોડીને. અમે ડેશબોર્ડ્સની સંખ્યા ઘટાડવાનો પ્રયાસ કરીએ છીએ જેથી એક નજરમાં તે સ્પષ્ટ થાય કે કઈ સેવા હાલમાં અધોગતિ કરી રહી છે (ઉદાહરણ તરીકે, પ્રતિ સેકન્ડ પ્રતિસાદ કોડ્સ, 99મી પર્સન્ટાઇલ પર પ્રતિસાદ સમય), વગેરે. જેમ જેમ સામાન્ય ડેશબોર્ડ્સ માટે કેટલાક નવા મેટ્રિક્સ જરૂરી બને છે, અમે તરત જ તેમને દોરીએ છીએ અને ઉમેરીએ છીએ.

મેં હવે એક મહિનાથી ગ્રાફિક્સ દોર્યા નથી. આ સંભવતઃ એક સારો સંકેત છે: તેનો અર્થ એ છે કે મોટાભાગની "ઇચ્છાઓ" પહેલેથી જ અમલમાં મૂકવામાં આવી છે. એવું બન્યું કે એક અઠવાડિયા માટે મેં દિવસમાં ઓછામાં ઓછો એક વખત નવો ચાર્ટ દોર્યો.

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

અમલીકરણ સેવા મેશ નજીકમાં છે અને દરેક માટે જીવન ખૂબ સરળ બનાવવું જોઈએ, ટૂલ્સના સહકર્મીઓ પહેલાથી જ અમૂર્ત "સ્વસ્થ વ્યક્તિનો ઈસ્ટિયો" અમલમાં મૂકવાની નજીક છે: દરેક HTTP (ઓ) વિનંતીનું જીવન ચક્ર મોનિટરિંગમાં દેખાશે, અને ઇન્ટરસર્વિસ (અને માત્ર નહીં) ક્રિયાપ્રતિક્રિયામાં "કયા તબક્કે બધું તૂટી ગયું" તે સમજવું હંમેશા શક્ય બનશે. DomClick હબના સમાચાર માટે સબ્સ્ક્રાઇબ કરો. =)

કુબરનેટ્સ ઇન્ફ્રાસ્ટ્રક્ચર સપોર્ટ

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

બધા k8s ક્લસ્ટરો માટેની અપગ્રેડ પ્રક્રિયા આના જેવી દેખાય છે:

• લો કુબેસ્પ્રે સાઉથબ્રિજથી, અમારી શાખા, મર્જિમ સાથે તપાસ કરો.
• માટે અપડેટ રોલઆઉટ કરી રહ્યું છે તણાવ- "ક્યુબ".
• અમે એક સમયે એક નોડ અપડેટ કરીએ છીએ (જવાબદારમાં આ "સીરીયલ: 1" છે) દેવ- "ક્યુબ".
• અપડેટ કરી રહ્યું છે પ્રોડ શનિવારે સાંજે, એક સમયે એક નોડ.

ભવિષ્યમાં બદલવાની યોજના છે કુબેસ્પ્રે કંઈક ઝડપી અને પર જાઓ kubeadm.

કુલ મળીને, અમારી પાસે ત્રણ "ક્યુબ્સ" છે: સ્ટ્રેસ, દેવ અને પ્રોડ. અમે બીજું લોન્ચ કરવાની યોજના બનાવીએ છીએગરમ સ્ટેન્ડબાય) પ્રોડ- બીજા ડેટા સેન્ટરમાં "ક્યુબ". તણાવ и દેવ વર્ચ્યુઅલ મશીનોમાં રહે છે (સ્ટ્રેસ માટે oVirt અને દેવ માટે VMWare ક્લાઉડ). પ્રોડ- "ક્યુબ" "બેર મેટલ" (બેર મેટલ) પર રહે છે: આ 32 CPU થ્રેડો, 64-128 GB મેમરી અને 300 GB SSD RAID 10 સાથે સમાન ગાંઠો છે - તેમાંથી કુલ 50 છે. ત્રણ "પાતળા" ગાંઠો "માસ્ટર" ને સમર્પિત છે પ્રોડ- "ક્યુબા": 16 GB મેમરી, 12 CPU થ્રેડો.

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

CI/CD ક્યુબિક અને અન્ય ઇન્ફ્રાસ્ટ્રક્ચર ઘટકો માટે અમે અલગ GIT સર્વર, હેલ્મ 3 નો ઉપયોગ કરીએ છીએ અણુ), જેનકિન્સ, એન્સિબલ અને ડોકર. અમને ફીચર શાખાઓ ગમે છે અને એક જ રીપોઝીટરીમાંથી વિવિધ વાતાવરણમાં જમાવટ કરીએ છીએ.

નિષ્કર્ષ

આ રીતે, સામાન્ય શબ્દોમાં, DomClick પરની DevOps પ્રક્રિયા ઑપરેશન એન્જિનિયરની બાજુથી જેવી દેખાય છે. લેખ મારી અપેક્ષા કરતાં ઓછો ટેકનિકલ હતો: તેથી, Habré પરના DomClick સમાચારને અનુસરો: કુબરનેટ્સ અને વધુ વિશે વધુ "હાર્ડકોર" લેખો હશે.

સોર્સ: www.habr.com