K8S મલ્ટિક્લસ્ટર જર્ની

હે હબર!

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

શરૂ કરવા માટે, શું ચર્ચા કરવામાં આવશે તેની વધુ સારી સમજણ માટે અમે તમને કેટલાક નંબરો ઑફર કરીએ છીએ:

• અમારા વિકાસ વિભાગમાં 100+ લોકોનો સમાવેશ થાય છે, જેમાં સ્વ-પર્યાપ્ત QA, DevOps અને સ્ક્રમ પ્રક્રિયાઓ સાથે 10 થી વધુ વિવિધ ટીમોનો સમાવેશ થાય છે. વિકાસ સ્ટેક - Python, PHP, C++, Java અને Golang. 
• પરીક્ષણ અને ઉત્પાદન વાતાવરણનું કદ લગભગ 2000 કન્ટેનર છે. તેઓ તેમના પોતાના વર્ચ્યુઅલાઈઝેશન પર અને VMware હેઠળ Rancher v1.6 ચલાવી રહ્યાં છે. 

પ્રોત્સાહન

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

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

અમે IaC ધોરણોને અનુસરવા અને, જો જરૂરી હોય તો, કોઈપણ ભૌગોલિક સ્થાનમાં અને વિક્રેતા લૉક વિના ઝડપથી ક્ષમતા પ્રાપ્ત કરવા માગીએ છીએ, અને તેને ઝડપથી છોડી દેવા પણ સક્ષમ છીએ.

પ્રથમ પગલાં

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

આગળ ક્લસ્ટરો બનાવવા માટે એક સાધન પસંદ કરવાનો પ્રશ્ન આવ્યો. અમે સૌથી વધુ લોકપ્રિય ઉકેલોની તુલના કરી: કોપ્સ, કુબેસ્પ્રે, કુબેડમ.

શરૂ કરવા માટે, kubeadm અમને "સાયકલ" ના શોધકની જેમ ખૂબ જટિલ રસ્તો લાગતો હતો અને કોપ્સ પાસે પૂરતી લવચીકતા નહોતી.

અને વિજેતા હતા:

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

પ્રથમ સમસ્યાઓ

કુબસ્પ્રે કયા પર બનેલ છે તે જવાબ આપવા યોગ્ય છે, તે એક એવું સાધન નથી જે તમને IaC ને અનુસરવાની મંજૂરી આપે છે: નોડ્સને કમિશનિંગ/ડિકમિશન કરતી વખતે, કંઈક સતત ખોટું થતું હતું અને અમુક પ્રકારના હસ્તક્ષેપની આવશ્યકતા હતી, અને જ્યારે વિવિધ OS નો ઉપયોગ કરવામાં આવે છે, ત્યારે પ્લેબુક અલગ રીતે વર્તે છે. અલગ રીતે . જેમ જેમ ક્લસ્ટરમાં ટીમો અને નોડ્સની સંખ્યા વધતી ગઈ તેમ, અમે નોંધવાનું શરૂ કર્યું કે પ્લેબુક પૂર્ણ થવામાં વધુ અને વધુ સમય લઈ રહી છે, અને પરિણામે, અમારો રેકોર્ડ 3,5 કલાકનો હતો, તમારું શું? 🙂

અને એવું લાગે છે કે kubespray માત્ર જવાબ આપી શકાય તેવું છે, અને બધું પ્રથમ નજરમાં સ્પષ્ટ છે, પરંતુ:

પ્રવાસની શરૂઆતમાં, કાર્ય ફક્ત AWS અને વર્ચ્યુઅલાઈઝેશન પર ક્ષમતાઓ શરૂ કરવાનું હતું, પરંતુ તે પછી, ઘણી વાર થાય છે, જરૂરિયાતો બદલાઈ ગઈ.
 


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

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

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

કેવી રીતે બનવું?

ઉપરોક્ત અને ટીમોની વધુ સ્વતંત્ર બનવાની ઇચ્છાઓને ધ્યાનમાં રાખીને, અમે એક સરળ નિષ્કર્ષ કાઢ્યો: એક ટીમ - એક ક્લસ્ટર. 

તેથી અમને બીજું મળ્યું:

અને પછી ત્રીજું ક્લસ્ટર: 

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

સંપૂર્ણ કુબરનેટ્સ આવશે! આ એક પ્રકારનું મલ્ટિકુબરનેટ્સ છે, તે તારણ આપે છે. 

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

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

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

વર્ઝન રેન્ચર 2.2 પહેલાથી જ વધુ કાર્યક્ષમ દેખાવ ધરાવતું હતું અને અગાઉના વર્ઝનની સાથે, તેમાં ઘણી બધી રસપ્રદ સુવિધાઓ હતી, જેમ કે ઘણા બાહ્ય પ્રદાતાઓ સાથે સંકલન, અધિકારોના વિતરણનો એક બિંદુ અને kubeconfig ફાઇલો, એક kubectl લોંચ કરવું. UI, નેસ્ટેડ નેમસ્પેસ ઉર્ફ પ્રોજેક્ટ્સમાં તમારા અધિકારો સાથેની છબી. 

રેન્ચર 2 ની આસપાસ પહેલેથી જ એક સમુદાય પણ રચાયો હતો, અને તેને સંચાલિત કરવા માટે HashiCorp Terraform નામનું પ્રદાતા બનાવવામાં આવ્યું હતું, જેણે અમને બધું એકસાથે રાખવામાં મદદ કરી.

શું થયું

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

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

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

આ લેખ A. Antipov, A. Ganush, Platform Engineers દ્વારા લખવામાં આવ્યો હતો. 

સોર્સ: www.habr.com