કુબરનેટ્સમાં એપ્લિકેશન વિકસાવવા માટેની આવશ્યકતાઓ

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

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

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

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

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

જો હું જેની વાત કરીશ તેના પ્લાન મુજબ બોલીએ તો તે આના જેવું લાગે છે, કૌંસમાં લખેલું છે (TL;DR) - “ખૂબ લાંબું; વાંચશો નહીં". મારી આજની પ્રસ્તુતિ અનંત યાદીઓનો સમાવેશ કરશે.

વાસ્તવમાં, જ્યારે આવી પ્રસ્તુતિઓ બનાવવામાં આવે ત્યારે મને પોતાને ગમતું નથી, પરંતુ આ એક એવો વિષય છે કે જ્યારે હું આ પ્રસ્તુતિ તૈયાર કરી રહ્યો હતો, ત્યારે મને આ માહિતીને અલગ રીતે કેવી રીતે ગોઠવવી તે ખરેખર સમજાયું ન હતું.

કારણ કે, મોટાભાગે, આ માહિતી “ctrl+c, ctrl+v” છે, અન્ય વસ્તુઓની સાથે, DevOps વિભાગમાં અમારા વિકીમાંથી, જ્યાં અમે વિકાસકર્તાઓ માટેની આવશ્યકતાઓ લખી છે: “ગાય્સ, જેથી અમે તમારી એપ્લિકેશનને આમાં લૉન્ચ કરીએ. કુબરનેટ્સ, તે આના જેવું હોવું જોઈએ."

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

હવે આપણે શું જોવા જઈ રહ્યા છીએ:

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

લોગ્સ

હું લૉગ્સથી શરૂ કરવાનું સૂચન કરું છું - જ્યાં આ લૉગ્સને કુબરનેટ્સમાં ખસેડવાની જરૂર છે. હવે તમે Kubernetes માં એક એપ્લિકેશન લોન્ચ કરી છે. ક્લાસિક્સ મુજબ, અગાઉની એપ્લિકેશનો હંમેશા ફાઇલમાં ક્યાંક લોગ લખતી હતી. ખરાબ એપ્લીકેશનોએ એપ્લીકેશન લોંચ કરનાર ડેવલપરની હોમ ડાયરેક્ટરીમાં ફાઈલ પર લોગ લખ્યા છે. સારી એપ્લિકેશનોએ ફાઇલમાં ક્યાંક લોગ લખ્યા છે /var/log.

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

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

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

અહીં સવાલ એ ઊભો થાય છે કે આ લોગ્સ સાથે તમે આગળ શું કરશો? સૌથી સહેલો રસ્તો સ્પષ્ટ છે, અમારી પાસે કરવાની ક્ષમતા છે kubectl logs અને આ "પોડ્સ" ના આ લોગ જુઓ. પરંતુ, સંભવતઃ, આ ખૂબ સારો વિકલ્પ નથી - લોગ સાથે કંઈક બીજું કરવાની જરૂર છે.

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

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

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

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

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

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

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

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

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

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

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

રૂપરેખાંકન

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

ડોકર, મારા મતે, ધોરણો વિશે છે. અને વ્યવહારીક રીતે દરેક વસ્તુ માટે ધોરણો છે: તમારી એપ્લિકેશન બનાવવા માટેના ધોરણો, તમારી એપ્લિકેશન ઇન્સ્ટોલ કરવા માટેના ધોરણો.

અને આ વસ્તુ - અમે પહેલા તેનો ઉપયોગ કર્યો હતો, તે ફક્ત કન્ટેનરના આગમન સાથે ખાસ કરીને લોકપ્રિય બની હતી - આ વસ્તુને ENV (પર્યાવરણ) વેરીએબલ્સ કહેવામાં આવે છે, એટલે કે, તમારી ઓપરેટિંગ સિસ્ટમમાં રહેલા પર્યાવરણીય ચલો. તમારી એપ્લિકેશનને ગોઠવવાની આ સામાન્ય રીતે એક આદર્શ રીત છે, કારણ કે જો તમારી પાસે JAVA, Python, Go, Perl, God forbid માં એપ્લિકેશન્સ છે અને તે બધા ડેટાબેઝ હોસ્ટ, ડેટાબેઝ વપરાશકર્તા, ડેટાબેઝ પાસવર્ડ વેરીએબલ વાંચી શકે છે, તો તે આદર્શ છે. તમારી પાસે એ જ રીતે ડેટાબેઝ પ્લાનમાં ચાર અલગ-અલગ ભાષાઓમાં એપ્લિકેશન ગોઠવેલી છે. ત્યાં કોઈ વધુ અલગ રૂપરેખાઓ નથી.

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

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

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

એકમાત્ર પ્રશ્ન એ છે કે રૂપરેખાઓ તમે જે વિચારો છો તે નથી. Config.pi એ રૂપરેખા નથી કે જે વાપરવા માટે અનુકૂળ હોય. અથવા તમારા પોતાના ફોર્મેટમાં કેટલીક રૂપરેખા, વૈકલ્પિક રીતે ભેટમાં - આ પણ તે રૂપરેખા નથી જે મારો મતલબ છે.

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

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

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

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

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

સ્વાસ્થ્ય તપાસ

આગળનો મુદ્દો આરોગ્ય તપાસ નામની આ વસ્તુ છે. સામાન્ય રીતે, આરોગ્ય તપાસ એ ફક્ત તપાસ કરે છે કે તમારી એપ્લિકેશન કામ કરી રહી છે. તે જ સમયે, અમે મોટાભાગે કેટલીક વેબ એપ્લિકેશનો વિશે વાત કરીએ છીએ, જેના માટે, તે મુજબ, આરોગ્ય તપાસના દૃષ્ટિકોણથી (અહીં અને આગળ અનુવાદ ન કરવું વધુ સારું છે) આ કેટલાક વિશિષ્ટ URL હશે, જેની તેઓ પ્રક્રિયા કરે છે. ધોરણ, તેઓ સામાન્ય રીતે કરે છે /health.

આ URL ને ઍક્સેસ કરતી વખતે, તે મુજબ, અમારી એપ્લિકેશન કહે છે કે "હા, ઠીક છે, મારી સાથે બધું સારું છે, 200" અથવા "ના, મારી સાથે બધું બરાબર નથી, લગભગ 500." તદનુસાર, જો અમારી એપ્લિકેશન http નથી, વેબ એપ્લિકેશન નથી, તો અમે હવે અમુક પ્રકારના ડિમન વિશે વાત કરી રહ્યા છીએ, અમે આરોગ્ય તપાસ કેવી રીતે કરવી તે શોધી શકીએ છીએ. એટલે કે, તે જરૂરી નથી, જો એપ્લિકેશન http નથી, તો પછી બધું આરોગ્ય તપાસ વિના કાર્ય કરે છે અને આ કોઈપણ રીતે કરી શકાતું નથી. તમે સમયાંતરે ફાઇલમાં કેટલીક માહિતી અપડેટ કરી શકો છો, તમે તમારા ડિમન માટે અમુક વિશેષ આદેશ સાથે આવી શકો છો, જેમ કે, daemon status, જે કહેશે "હા, બધું બરાબર છે, ડિમન કામ કરી રહ્યું છે, તે જીવંત છે."

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

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

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

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

અને અહીં એક મહત્વપૂર્ણ મુદ્દો છે જેનો હું ઉલ્લેખ કરવા માંગુ છું: વ્યવહારિક દૃષ્ટિકોણથી, તૈયારી પરીક્ષણનો ઉપયોગ સામાન્ય રીતે વધુ વખત થાય છે અને જીવંતતા પરીક્ષણ કરતાં વધુ વખત જરૂરી છે. એટલે કે, તત્પરતા અને જીવંતતા પરીક્ષણો બંનેને વિચાર્યા વગર જાહેર કરવું, કારણ કે કુબરનેટ્સ તે કરી શકે છે, અને ચાલો તે જે કરી શકે તે બધું વાપરીએ, એ બહુ સારો વિચાર નથી. હું શા માટે સમજાવીશ. કારણ કે પરીક્ષણમાં પોઈન્ટ નંબર બે એ છે કે તમારી સ્વાસ્થ્ય તપાસમાં અંતર્ગત સેવા તપાસવી એ સારો વિચાર છે. આનો અર્થ એ છે કે જો તમારી પાસે વેબ એપ્લિકેશન છે જે કેટલીક માહિતી આપે છે, જે બદલામાં, કુદરતી રીતે, ક્યાંકથી લેવી આવશ્યક છે. ડેટાબેઝમાં, ઉદાહરણ તરીકે. સારું, તે આ REST API માં આવતી માહિતીને સમાન ડેટાબેઝમાં સાચવે છે. પછી, તે મુજબ, જો તમારી હેલ્થચેક ફક્ત સંપર્ક કરેલ સ્લેશહેલ્થની જેમ જવાબ આપે છે, તો એપ્લિકેશન કહે છે "200, ઠીક છે, બધું સારું છે," અને તે જ સમયે તમારી એપ્લિકેશનનો ડેટાબેઝ અપ્રાપ્ય છે, અને હેલ્થચેક એપ્લિકેશન કહે છે કે "200, ઠીક છે, બધું બરાબર છે. ” - આ ખરાબ સ્વાસ્થ્ય તપાસ છે. આ રીતે કામ કરવું જોઈએ એવું નથી.

એટલે કે, તમારી અરજી, જ્યારે તેની પાસે કોઈ વિનંતી આવે છે /health, તે ફક્ત પ્રતિસાદ આપતું નથી, “200, OK”, તે સૌપ્રથમ, ઉદાહરણ તરીકે, ડેટાબેઝમાં જાય છે, તેની સાથે કનેક્ટ થવાનો પ્રયાસ કરે છે, ત્યાં કંઈક ખૂબ જ મૂળભૂત કરે છે, જેમ કે એક પસંદ કરો, ફક્ત તપાસે છે કે તેમાં કનેક્શન છે. ડેટાબેઝ અને તમે ડેટાબેઝને ક્વેરી કરી શકો છો. જો આ બધું સફળ થયું, તો જવાબ છે "200, ઠીક છે." જો તે સફળ ન થાય, તો તે કહે છે કે એક ભૂલ છે, ડેટાબેઝ અનુપલબ્ધ છે.

તેથી, આ સંદર્ભમાં, હું ફરીથી રેડીનેસ/લાઇવનેસ ટેસ્ટ પર પાછો ફરું છું - શા માટે તમને મોટે ભાગે રેડીનેસ ટેસ્ટની જરૂર છે, પરંતુ જીવંતતા પરીક્ષણ પ્રશ્નમાં છે. કારણ કે જો તમે આરોગ્ય તપાસનું બરાબર વર્ણન કરો જેમ મેં હમણાં કહ્યું છે, તો તે બહાર આવશે કે તે દાખલાના ભાગમાં ઉપલબ્ધ નથી.в или со всех instanceડેટાબેઝમાં, ઉદાહરણ તરીકે. જ્યારે તમે તત્પરતા પરીક્ષણ જાહેર કર્યું, ત્યારે અમારી આરોગ્ય તપાસો નિષ્ફળ થવા લાગી, અને તે મુજબ તમામ એપ્લિકેશનો કે જેમાંથી ડેટાબેઝ ઍક્સેસિબલ નથી, તે ફક્ત સંતુલિત થવાથી બંધ કરવામાં આવે છે અને હકીકતમાં ફક્ત ઉપેક્ષિત સ્થિતિમાં "હેંગ" થાય છે અને તેમના ડેટાબેઝની રાહ જુઓ. કામ

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

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

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

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

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

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

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

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

જો બધું બરાબર ચાલ્યું હોય, તો પછી બેસોમા જવાબ સાથે જવાબ આપો. સૈદ્ધાંતિક રીતે, કોઈપણ બે-સોમો જવાબ તમને અનુકૂળ રહેશે. જો તમે રાગસી સારી રીતે વાંચો છો અને જાણો છો કે કેટલીક પ્રતિભાવ સ્થિતિઓ અન્ય કરતા અલગ છે, તો યોગ્ય સાથે જવાબ આપો: 204, 5, 10, 15, ગમે તે હોય. જો તે ખૂબ સારું ન હોય, તો ફક્ત "બે શૂન્ય શૂન્ય." જો બધું ખરાબ થઈ જાય અને આરોગ્ય તપાસનો જવાબ ન આવે તો કોઈપણ પાંચસો સાથે જવાબ આપો. ફરીથી, જો તમે કેવી રીતે પ્રતિસાદ આપવો તે સમજો છો, તો કેવી રીતે વિવિધ પ્રતિભાવ સ્થિતિઓ એકબીજાથી અલગ છે. જો તમે સમજી શકતા નથી, તો જો કંઈક ખોટું થાય તો સ્વાસ્થ્ય તપાસનો જવાબ આપવા માટે 502 તમારો વિકલ્પ છે.

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

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

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

આગળ, એપ્લિકેશનો લોંચ કરતી વખતે અમારી પાસે એક પીડાદાયક સમસ્યાઓ પણ છે.

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

આકર્ષક શટડાઉન

સામાન્ય રીતે, ગ્રેસફુલ શટડાઉન શું છે અને તેની શા માટે જરૂર છે? આ તે છે જ્યારે તમારી એપ્લિકેશન કોઈ કારણસર ક્રેશ થાય છે, તમારે કરવાની જરૂર છે app stop - અથવા તમે, ઉદાહરણ તરીકે, ઑપરેટિંગ સિસ્ટમ તરફથી સિગ્નલ પ્રાપ્ત કરો છો, તમારી એપ્લિકેશને તેને સમજવું જોઈએ અને તેના વિશે કંઈક કરવું જોઈએ. સૌથી ખરાબ પરિસ્થિતિ, અલબત્ત, જ્યારે તમારી એપ્લિકેશનને SIGTERM પ્રાપ્ત થાય છે અને તે "SIGTERM, ચાલો અટકીએ, કામ કરીએ, કંઈ ન કરીએ" જેવું હોય છે. આ એકદમ ખરાબ વિકલ્પ છે.

લગભગ સમાન રીતે ખરાબ વિકલ્પ એ છે કે જ્યારે તમારી એપ્લિકેશન SIGTERM મેળવે છે અને "તેઓએ કહ્યું segterm, તેનો અર્થ એ છે કે અમે સમાપ્ત થઈ રહ્યા છીએ, મેં જોયું નથી, મને કોઈ વપરાશકર્તા વિનંતીઓ ખબર નથી, મને ખબર નથી કે કયા પ્રકારની વિનંતીઓ પર હું હમણાં કામ કરી રહ્યો છું, તેઓએ SIGTERM કહ્યું, તેનો અર્થ એ કે અમે સમાપ્ત કરી રહ્યાં છીએ " આ પણ ખરાબ વિકલ્પ છે.

કયો વિકલ્પ સારો છે? પ્રથમ બિંદુ એ કામગીરીની પૂર્ણતાને ધ્યાનમાં લેવાનું છે. જો તમારા સર્વરને SIGTERM પ્રાપ્ત થાય તો તે શું કરે છે તે ધ્યાનમાં લેવા માટે એક સારો વિકલ્પ છે.

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

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

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

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

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

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

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

સંપત્તિ

ખરેખર, અહીં હું તમને એક સીધી વાર્તા કહીશ. ફરીથી વાસ્તવિક જીવનમાંથી. સંસાધનો વિશે મેં ક્યારેય સાંભળ્યું છે તે સૌથી ખરાબ વસ્તુ.

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

શા માટે સંસાધનોની જરૂર છે? કુબરનેટ્સમાં 2 પ્રકારના સંસાધનો છે. કેટલાકને વિનંતીઓ કહેવામાં આવે છે, અન્યને મર્યાદા કહેવામાં આવે છે. સંસાધનો દ્વારા આપણે સમજીશું કે મૂળભૂત રીતે હંમેશા ફક્ત બે મૂળભૂત પ્રતિબંધો છે. એટલે કે, કુબરનેટ્સમાં ચાલતા કન્ટેનર માટે CPU સમય મર્યાદા અને RAM મર્યાદા.

મર્યાદા તમારી એપ્લિકેશનમાં સંસાધનનો ઉપયોગ કેવી રીતે કરી શકાય તેની ઉપરની મર્યાદા મૂકે છે. એટલે કે, તે મુજબ, જો તમે મર્યાદામાં 1GB RAM કહો છો, તો તમારી એપ્લિકેશન 1GB થી વધુ રેમનો ઉપયોગ કરી શકશે નહીં. અને જો તે અચાનક ઇચ્છે છે અને આ કરવાનો પ્રયાસ કરે છે, તો ઓમ કિલર નામની પ્રક્રિયા, મેમરીની બહાર, એટલે કે, આવીને તમારી એપ્લિકેશનને મારી નાખશે - એટલે કે, તે ફક્ત પુનઃપ્રારંભ થશે. CPU ના આધારે એપ્લિકેશનો પુનઃપ્રારંભ થશે નહીં. સીપીયુના સંદર્ભમાં, જો કોઈ એપ્લિકેશન મર્યાદામાં નિર્દિષ્ટ કરતાં વધુ ઉપયોગ કરવાનો પ્રયાસ કરે છે, તો સીપીયુ ફક્ત સખત રીતે પસંદ કરવામાં આવશે. આ પુનઃપ્રારંભ તરફ દોરી જતું નથી. આ મર્યાદા છે - આ ઉપલી મર્યાદા છે.

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

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

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

માહિતી સંગ્રાહક

અમારો આગળનો મુદ્દો ડેટા સ્ટોરેજ વિશે છે. તેમની સાથે શું કરવું અને સામાન્ય રીતે, કુબરનેટ્સમાં દ્રઢતા સાથે શું કરવું?

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

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

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

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

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

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

અમે Ceph પર કોર્સ કરીશું, તમે કરી શકો છો પ્રોગ્રામથી પોતાને પરિચિત કરો અને અરજી સબમિટ કરો.

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

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

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

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

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

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

ક્લાઉડનેટીવનેસ

અને અંતિમ સબટોપિક એ છે કે Cloudnative શું છે. તેની શા માટે જરૂર છે? ક્લાઉડનેટીવનેસ અને તેથી વધુ.

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

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

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

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

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

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

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

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

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

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

સોર્સ: www.habr.com