કેમ છો બધા! મારું નામ પાવેલ અગાલેત્સ્કી છે. હું લામોડા ડિલિવરી સિસ્ટમ વિકસાવતી ટીમમાં ટીમ લીડ તરીકે કામ કરું છું. 2018 માં, મેં HighLoad++ કોન્ફરન્સમાં વાત કરી હતી, અને આજે હું મારા રિપોર્ટની ટ્રાન્સક્રિપ્ટ રજૂ કરવા માંગુ છું.

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

VM પર એપ્લિકેશનો જમાવવી

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

આ કેમ કરવામાં આવ્યું?

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

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

આ બધામાં આપણે શું ફાયદા જોયા?

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

પરંતુ અમે આ બધામાં ઘણી ખામીઓ પણ જોઈ:

1. ઉત્પાદન પર્યાવરણ, વિકાસ પર્યાવરણ ઉપરાંત અન્ય વાતાવરણ પણ છે. ઉદાહરણ તરીકે, qa અને પ્રીપ્રોડક્શન. તે સમયે અમારી પાસે ઘણા સર્વર અને લગભગ 60 સેવાઓ હતી. આ કારણોસર તે જરૂરી હતું દરેક સેવા માટે, તેના માટે નવીનતમ સંસ્કરણ જાળવી રાખો વર્ચ્યુઅલ મશીન. વધુમાં, જો તમે લાઈબ્રેરીઓ અપડેટ કરવા માંગતા હોવ અથવા નવી નિર્ભરતા સ્થાપિત કરવા માંગતા હો, તો તમારે આ બધા વાતાવરણમાં કરવાની જરૂર છે. તમારે તે સમયને પણ સિંક્રનાઇઝ કરવાની જરૂર છે જ્યારે તમે તમારી એપ્લિકેશનના આગલા નવા સંસ્કરણને તે સમય સાથે જમાવવા જઈ રહ્યા છો જ્યારે devops જરૂરી પર્યાવરણ સેટિંગ્સ કરે છે. આ કિસ્સામાં, એવી પરિસ્થિતિમાં પ્રવેશવું સરળ છે કે જ્યાં આપણું વાતાવરણ એક જ સમયે તમામ વાતાવરણમાં કંઈક અંશે અલગ હશે. ઉદાહરણ તરીકે, QA વાતાવરણમાં પુસ્તકાલયોના કેટલાક સંસ્કરણો હશે, અને ઉત્પાદન વાતાવરણમાં ત્યાં અલગ હશે, જે સમસ્યાઓ તરફ દોરી જશે.
2. નિર્ભરતાને અપડેટ કરવામાં મુશ્કેલી તમારી અરજી. તે તમારા પર નહીં, પરંતુ અન્ય ટીમ પર નિર્ભર છે. એટલે કે, સર્વર્સની જાળવણી કરતી ડેવોપ્સ ટીમમાંથી. તમારે તેમને યોગ્ય કાર્ય અને તમે શું કરવા માંગો છો તેનું વર્ણન આપવું જોઈએ.
3. તે સમયે, અમે અમારી પાસે રહેલા મોટા મોટા મોનોલિથ્સને પણ અલગ નાની સેવાઓમાં વિભાજીત કરવા માગતા હતા, કારણ કે અમે સમજી ગયા હતા કે તેમાં વધુ અને વધુ હશે. તે સમયે, અમારી પાસે પહેલાથી જ તેમાંથી 100 થી વધુ હતા. દરેક નવી સેવા માટે, એક અલગ નવું વર્ચ્યુઅલ મશીન બનાવવું જરૂરી હતું, જેની જાળવણી અને તૈનાત કરવાની પણ જરૂર હતી. વધુમાં, તમારે એક કારની જરૂર નથી, પરંતુ ઓછામાં ઓછી બે. આ બધામાં ઉમેરાયેલ છે QA પર્યાવરણ. આ સમસ્યાઓનું કારણ બને છે અને તમારા માટે નવી સિસ્ટમો બનાવવા અને ચલાવવાનું વધુ મુશ્કેલ બનાવે છે. જટિલ, ખર્ચાળ અને લાંબી પ્રક્રિયા.

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

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

નોમડ પર સ્વિચ કરો

નોમાડ એ HashiCorp નું ઉત્પાદન છે. તેઓ તેમના અન્ય ઉકેલો માટે પણ જાણીતા છે:

"કોન્સ્યુલ" સેવાની શોધ માટેનું સાધન છે.

"ટેરાફોર્મ" - સર્વર્સને મેનેજ કરવા માટેની સિસ્ટમ કે જે તમને રૂપરેખાંકન દ્વારા રૂપરેખાંકિત કરવાની મંજૂરી આપે છે, કહેવાતા ઇન્ફ્રાસ્ટ્રક્ચર-એ-એ-કોડ.

"અવાગ્ર" તમને ચોક્કસ રૂપરેખાંકન ફાઇલો દ્વારા સ્થાનિક રીતે અથવા ક્લાઉડમાં વર્ચ્યુઅલ મશીનો જમાવવાની પરવાનગી આપે છે.

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

તમારી સિસ્ટમને નોમાડમાં જમાવવા માટે તમારે શું કરવાની જરૂર છે?

1. સૌ પ્રથમ તમારે જરૂર છે ડોકર છબી તમારી અરજી. તમારે તેને બનાવવાની અને તેને ડોકર ઇમેજ રિપોઝીટરીમાં મૂકવાની જરૂર છે. અમારા કિસ્સામાં, આ એક આર્ટિફેક્ટરી છે - એક સિસ્ટમ જે તમને વિવિધ પ્રકારની વિવિધ કલાકૃતિઓને તેમાં દબાણ કરવાની મંજૂરી આપે છે. તે આર્કાઇવ્સ, ડોકર ઇમેજ, કંપોઝર PHP પેકેજો, NPM પેકેજો વગેરે સ્ટોર કરી શકે છે.
2. પણ જરૂરી છે રૂપરેખાંકન ફાઇલ, જે નોમડને જણાવશે કે તમે શું, ક્યાં અને કયા જથ્થામાં જમાવવા માંગો છો.

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

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

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

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

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

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

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

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

જ્યારે નોમાડ સેવા પહેલેથી જ તમારા ક્લસ્ટરમાં જમાવવામાં આવે છે, તે આના જેવું દેખાય છે.

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

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

માનવ સંસાધનોના સંદર્ભમાં સંક્રમણમાં અમને કેટલો ખર્ચ થયો?

સમગ્ર કંપનીના નોમાડમાં સંક્રમણમાં લગભગ 5-6 મહિનાનો સમય લાગ્યો. અમે સેવા-દર-સેવા ધોરણે આગળ વધ્યા, પરંતુ એકદમ ઝડપી ગતિએ. દરેક ટીમે સેવાઓ માટે પોતાના કન્ટેનર બનાવવાના હતા.

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

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

નોમડને છોડી દેવાના કારણો

નોમેડ અને ડોકરનો ઉપયોગ કરીને ડિપ્લોયમેન્ટ પર સ્વિચ કરવાથી અમને કયા ફાયદા મળ્યા છે, અન્યો વચ્ચે?

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

પરંતુ અમે કેટલાક ગેરફાયદાનો પણ સામનો કર્યો:

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

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

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

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

કુબરનેટ્સમાં સંક્રમણ

હું તમને કુબરનેટ્સની મૂળભૂત વિભાવનાઓ અને તેઓ નોમાડથી કેવી રીતે અલગ છે તે વિશે થોડું કહીશ.

સૌ પ્રથમ, કુબરનેટીસમાં સૌથી મૂળભૂત ખ્યાલ એ પોડનો ખ્યાલ છે. પોડ એક અથવા વધુ કન્ટેનરનું જૂથ છે જે હંમેશા સાથે ચાલે છે. અને તેઓ હંમેશા એક વર્ચ્યુઅલ મશીન પર સખત રીતે કામ કરે છે. તેઓ અલગ-અલગ પોર્ટ પર IP 127.0.0.1 દ્વારા એકબીજાને સુલભ છે.

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

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

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

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

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

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

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

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

હેલ્મમાં મૂળભૂત ખ્યાલો

સુકાન છે પેકેજ મેનેજર કુબરનેટ્સ માટે. તે પ્રોગ્રામિંગ ભાષાઓમાં પેકેજ મેનેજરો કેવી રીતે કાર્ય કરે છે તેના જેવું જ છે. તેઓ તમને સેવા સંગ્રહિત કરવાની મંજૂરી આપે છે, ઉદાહરણ તરીકે, ડિપ્લોયમેન્ટ nginx, ડિપ્લોયમેન્ટ php-fpm, Ingress માટે રૂપરેખા, configmaps (આ એક એન્ટિટી છે જે તમને તમારી સિસ્ટમ માટે env અને અન્ય પરિમાણો સેટ કરવાની મંજૂરી આપે છે) so- ચાર્ટ કહેવાય છે. તે જ સમયે સુકાન કુબરનેટ્સની ટોચ પર ચાલે છે. એટલે કે, આ કોઈ પ્રકારની સિસ્ટમ એક બાજુ ઊભી નથી, પરંતુ ક્યુબની અંદર શરૂ કરવામાં આવેલી બીજી સેવા છે. તમે કન્સોલ આદેશ દ્વારા તેના API દ્વારા તેની સાથે ક્રિયાપ્રતિક્રિયા કરો છો. તેની સગવડ અને સુંદરતા એ છે કે સુકાન તૂટી જાય અથવા તમે તેને ક્લસ્ટરમાંથી દૂર કરો તો પણ તમારી સેવાઓ અદૃશ્ય થઈ જશે નહીં, કારણ કે સુકાન આવશ્યકપણે સિસ્ટમ શરૂ કરવા માટે જ કામ કરે છે. કુબરનેટસ પોતે પછી કામગીરી અને સેવાઓની સ્થિતિ માટે જવાબદાર છે.

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

હેલ્મ અમારા માટે થોડા વધુ ખ્યાલો ઉમેરે છે.

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

મૂલ્યો તે ચલ છે જેનો ઉપયોગ તમે નમૂનાઓમાંથી તમારા રૂપરેખાઓ બનાવવા માટે કરવા માંગો છો.

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

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

વ્યવહારમાં, અમે નોમાડ સાથે કરતાં થોડી અલગ રીતે વસ્તુઓ કરવાનું નક્કી કર્યું. જો નોમાડમાં બંને ડિપ્લોયમેન્ટ રૂપરેખાઓ અને n-ચલો કે જે અમારી સેવાને જમાવવા માટે જરૂરી હતા તે એક રિપોઝીટરીમાં સંગ્રહિત હતા, તો અહીં અમે તેમને બે અલગ-અલગ રીપોઝીટરીઝમાં વિભાજીત કરવાનું નક્કી કર્યું છે. "ડિપ્લોય" રીપોઝીટરી જમાવટ માટે જરૂરી માત્ર n-ચલોનો સંગ્રહ કરે છે, અને "સુકાન" રીપોઝીટરી રૂપરેખાઓ અથવા ચાર્ટ્સ સ્ટોર કરે છે.

આ અમને શું આપ્યું?

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

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

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

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

તારણો

કુબરનેટ્સ સેવા નોમાડ કરતાં વધુ જટિલ લાગે છે.

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

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

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

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

સોર્સ: www.habr.com