કુબરનેટ્સમાં ઓટોસ્કેલિંગ અને સંસાધન સંચાલન (સમીક્ષા અને વિડિયો રિપોર્ટ)

27 એપ્રિલે કોન્ફરન્સમાં હડતાલ 2019, "DevOps" વિભાગના ભાગ રૂપે, "કુબરનેટ્સમાં ઓટોસ્કેલિંગ અને સંસાધન સંચાલન" અહેવાલ આપવામાં આવ્યો હતો. તે તમારી એપ્લીકેશનની ઉચ્ચ ઉપલબ્ધતાને સુનિશ્ચિત કરવા અને શ્રેષ્ઠ પ્રદર્શનને સુનિશ્ચિત કરવા માટે તમે K8s નો ઉપયોગ કેવી રીતે કરી શકો તે વિશે વાત કરે છે.

પરંપરા દ્વારા, અમે પ્રસ્તુત કરવા માટે ઉત્સુક છીએ અહેવાલનો વિડિયો (44 મિનિટ, લેખ કરતાં વધુ માહિતીપ્રદ) અને ટેક્સ્ટ સ્વરૂપમાં મુખ્ય સારાંશ. જાઓ!

ચાલો અહેવાલ શબ્દના વિષયનું શબ્દ દ્વારા વિશ્લેષણ કરીએ અને અંતથી શરૂ કરીએ.

ક્યુબર્નેટિસ

ચાલો કહીએ કે અમારી પાસે અમારા હોસ્ટ પર ડોકર કન્ટેનર છે. શેના માટે? પુનરાવર્તિતતા અને અલગતાની ખાતરી કરવા માટે, જે બદલામાં સરળ અને સારી જમાવટ માટે પરવાનગી આપે છે, CI/CD. અમારી પાસે કન્ટેનરવાળા આવા ઘણા વાહનો છે.

આ કિસ્સામાં કુબરનેટ્સ શું પ્રદાન કરે છે?

1. અમે આ મશીનો વિશે વિચારવાનું બંધ કરીએ છીએ અને "ક્લાઉડ" સાથે કામ કરવાનું શરૂ કરીએ છીએ. કન્ટેનરનું ક્લસ્ટર અથવા શીંગો (કંટેનરોના જૂથો).
2. તદુપરાંત, અમે વ્યક્તિગત શીંગો વિશે પણ વિચારતા નથી, પરંતુ વધુ વ્યવસ્થા કરીએ છીએоમોટા જૂથો. આવા ઉચ્ચ સ્તરીય આદિમ અમને કહેવાની મંજૂરી આપો કે ચોક્કસ વર્કલોડ ચલાવવા માટે એક નમૂનો છે, અને તેને ચલાવવા માટે અહીં જરૂરી સંખ્યામાં દાખલાઓ છે. જો આપણે પછીથી ટેમ્પલેટ બદલીએ, તો તમામ ઉદાહરણો બદલાઈ જશે.
3. ની મદદ સાથે ઘોષણાત્મક API ચોક્કસ આદેશોનો ક્રમ ચલાવવાને બદલે, અમે "વિશ્વનું માળખું" (YAML માં) નું વર્ણન કરીએ છીએ, જે કુબરનેટ્સ દ્વારા બનાવવામાં આવ્યું છે. અને ફરીથી: જ્યારે વર્ણન બદલાશે, ત્યારે તેનું વાસ્તવિક પ્રદર્શન પણ બદલાશે.

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

સી.પી.યુ

ચાલો સર્વર પર nginx, php-fpm અને mysql ચલાવીએ. આ સેવાઓમાં વાસ્તવમાં હજી પણ વધુ પ્રક્રિયાઓ ચાલતી હશે, જેમાંથી દરેકને કમ્પ્યુટિંગ સંસાધનોની જરૂર છે:

(સ્લાઇડ પરના નંબરો "પોપટ" છે, કમ્પ્યુટિંગ પાવર માટેની દરેક પ્રક્રિયાની અમૂર્ત જરૂરિયાત)

આની સાથે કામ કરવાનું સરળ બનાવવા માટે, પ્રક્રિયાઓને જૂથોમાં જોડવાનું તાર્કિક છે (ઉદાહરણ તરીકે, તમામ nginx પ્રક્રિયાઓને એક જૂથ "nginx" માં). આ કરવાની એક સરળ અને સ્પષ્ટ રીત એ છે કે દરેક જૂથને કન્ટેનરમાં મૂકવું:

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

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

ચાલો આ પ્રક્રિયાઓ માટેની CPU આવશ્યકતાઓ પર પાછા જઈએ, અને હવે પ્રક્રિયાઓના જૂથો માટે:

(હું પુનરાવર્તન કરું છું કે બધી સંખ્યાઓ સંસાધનોની જરૂરિયાતની અમૂર્ત અભિવ્યક્તિ છે)

તે જ સમયે, CPU પાસે ચોક્કસ મર્યાદિત સંસાધન છે (ઉદાહરણમાં આ 1000 છે), જેનો દરેકને અભાવ હોઈ શકે છે (તમામ જૂથોની જરૂરિયાતોનો સરવાળો 150+850+460=1460 છે). આ કિસ્સામાં શું થશે?

કર્નલ સંસાધનોનું વિતરણ કરવાનું શરૂ કરે છે અને તે દરેક જૂથને સમાન પ્રમાણમાં સંસાધનો આપીને "વાજબી રીતે" કરે છે. પરંતુ પ્રથમ કિસ્સામાં, તેમાં જરૂર કરતાં વધુ છે (333>150), તેથી વધારાનું (333-150=183) અનામતમાં રહે છે, જે અન્ય બે કન્ટેનર વચ્ચે સમાનરૂપે વિતરિત થાય છે:

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

ચાલો બીજા કન્ટેનર (php-fpm) માં સંસાધનોની અછતનો કેસ જોઈએ. બધા કન્ટેનર સંસાધનો પ્રક્રિયાઓ વચ્ચે સમાનરૂપે વિતરિત કરવામાં આવે છે. પરિણામે, માસ્ટર પ્રક્રિયા સારી રીતે કાર્ય કરે છે, પરંતુ બધા કામદારો ધીમી પડી જાય છે, તેઓને જે જોઈએ છે તેના અડધા કરતાં પણ ઓછું પ્રાપ્ત કરે છે:

આ રીતે CFS શેડ્યૂલર કામ કરે છે. અમે કન્ટેનરને સોંપેલ વજનને આગળ કહીશું વિનંતીઓ. આ શા માટે છે - આગળ જુઓ.

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

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

ચાલો Linux કર્નલ અને CPU સાથેની તેની ક્રિયાપ્રતિક્રિયા પર પાછા જઈએ - એકંદર ચિત્ર નીચે મુજબ છે:

cgroup પાસે બે સેટિંગ્સ છે - આવશ્યકપણે આ બે સરળ "ટ્વિસ્ટ" છે જે તમને નિર્ધારિત કરવા દે છે:

1. કન્ટેનર (વિનંતીઓ) માટે વજન છે શેર;
2. કન્ટેનર કાર્યો પર કામ કરવા માટેના કુલ CPU સમયની ટકાવારી (મર્યાદા) છે ક્વોટા.

CPU ને કેવી રીતે માપવું?

ત્યાં વિવિધ માર્ગો છે:

1. શું પોપટ, કોઈ જાણતું નથી - તમારે દર વખતે વાટાઘાટો કરવાની જરૂર છે.
2. વ્યાજ સ્પષ્ટ, પરંતુ સંબંધિત: 50 કોરો અને 4 કોરો સાથે સર્વરનો 20% સંપૂર્ણપણે અલગ વસ્તુઓ છે.
3. તમે પહેલેથી જ ઉલ્લેખિત લોકોનો ઉપયોગ કરી શકો છો વજન, જે Linux જાણે છે, પરંતુ તે સંબંધિત પણ છે.
4. માં કમ્પ્યુટિંગ સંસાધનોને માપવાનો સૌથી પર્યાપ્ત વિકલ્પ છે સેકન્ડ. તે. પ્રોસેસર સમયની સેકન્ડમાં વાસ્તવિક સમયની સેકન્ડની તુલનામાં: પ્રોસેસર સમયનો 1 સેકન્ડ પ્રતિ 1 વાસ્તવિક સેકન્ડ આપવામાં આવ્યો હતો - આ એક સંપૂર્ણ CPU કોર છે.

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

ચાલો 3 CPU કોરોવાળા સર્વર સાથેના એક સરળ ઉદાહરણને ધ્યાનમાં લઈએ, જ્યાં ત્રણ પોડ્સને વજન (500, 1000 અને 1500) આપવામાં આવશે જે તેમને ફાળવવામાં આવેલા કોરોના અનુરૂપ ભાગોમાં સરળતાથી રૂપાંતરિત થાય છે (0,5, 1 અને 1,5).

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

કુબરનેટ્સ અને સીપીયુ સંસાધનો

કુબરનેટ્સમાં, CPU સંસાધનો સામાન્ય રીતે માપવામાં આવે છે મિલિઆડ્રેક્સ, એટલે કે 0,001 કોરોને આધાર વજન તરીકે લેવામાં આવે છે. (Linux/cgroups પરિભાષામાં સમાન વસ્તુને CPU શેર કહેવામાં આવે છે, જો કે, વધુ સ્પષ્ટ રીતે, 1000 millicores = 1024 CPU શેર.) K8s એ સુનિશ્ચિત કરે છે કે તે સર્વર પર તમામ પોડ્સના વજનના સરવાળા માટે CPU સંસાધનો કરતાં વધુ પોડ્સ મૂકતું નથી.

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

જો શું થશે નથી વિનંતિ ઉલ્લેખિત છે (એટલે ​​​​કે પોડમાં તેને જરૂરી કોરોની નિર્ધારિત સંખ્યા નથી)? ચાલો જાણીએ કે કુબરનેટ્સ સામાન્ય રીતે સંસાધનોની ગણતરી કેવી રીતે કરે છે.

પોડ માટે, તમે બંને વિનંતીઓ (CFS શેડ્યૂલર) અને મર્યાદા (ટ્રાફિક લાઇટ યાદ રાખો?) નો ઉલ્લેખ કરી શકો છો:

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

મેમરી

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

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

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

ચાલો CPU ના QoS વર્ગો પર પાછા ફરીએ અને oom_score_adj મૂલ્યો સાથે સામ્યતા દોરીએ જે પોડ્સ માટે મેમરી વપરાશની પ્રાથમિકતાઓ નક્કી કરે છે:

• પોડ માટે સૌથી નીચું oom_score_adj મૂલ્ય - -998 - મતલબ કે આવા પોડને છેલ્લે મારવા જોઈએ, આ ખાતરી આપી.
• સૌથી વધુ - 1000 - છે ઉત્તમ પ્રયત્ન, આવી શીંગો પહેલા મારી નાખવામાં આવે છે.
• બાકીના મૂલ્યોની ગણતરી કરવા માટે (વિસ્ફોટ કરી શકાય તેવું) એક સૂત્ર છે, જેનો સાર એ હકીકત પર ઉકળે છે કે પોડ જેટલા વધુ સંસાધનોની વિનંતી કરે છે, તે મારવાની શક્યતા ઓછી છે.

બીજો "ટ્વિસ્ટ" - limit_in_bytes - મર્યાદા માટે. તેની સાથે, બધું સરળ છે: અમે ફક્ત જારી કરેલી મેમરીની મહત્તમ રકમ અસાઇન કરીએ છીએ, અને અહીં (સીપીયુથી વિપરીત) તેને (મેમરી) કેવી રીતે માપવું તે અંગે કોઈ પ્રશ્ન નથી.

કુલ

Kubernetes માં દરેક પોડ આપવામાં આવે છે requests и limits - CPU અને મેમરી માટે બંને પરિમાણો:

1. વિનંતીઓના આધારે, કુબરનેટ્સ શેડ્યૂલર કામ કરે છે, જે સર્વર્સ વચ્ચે પોડ્સનું વિતરણ કરે છે;
2. બધા પરિમાણોના આધારે, પોડનો QoS વર્ગ નક્કી કરવામાં આવે છે;
3. CPU વિનંતીઓના આધારે સંબંધિત વજનની ગણતરી કરવામાં આવે છે;
4. CFS શેડ્યૂલર CPU વિનંતીઓના આધારે ગોઠવાયેલ છે;
5. OOM કિલર મેમરી વિનંતીઓના આધારે ગોઠવેલ છે;
6. "ટ્રાફિક લાઇટ" CPU મર્યાદાના આધારે ગોઠવેલ છે;
7. મેમરી મર્યાદાના આધારે, સીગ્રુપ માટે મર્યાદા ગોઠવેલ છે.

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

ઓટોસ્કેલિંગ

K8s ક્લસ્ટર-ઓટોસ્કેલર

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

આ કુબરનેટીસ ક્લસ્ટરનું ઓટોસ્કેલિંગ છે, જે સરસ કામ કરે છે (અમારા અનુભવમાં). જો કે, અન્યત્રની જેમ, અહીં પણ કેટલીક ઘોંઘાટ છે...

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

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

• આ સર્વર પર નવા પોડ્સ મોકલવા પર પ્રતિબંધ મૂકશે;
• સર્વર પર હાલના પોડ્સ કાઢી નાખશે.

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

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

MongoDB શકવું મૃત્યુ પામે છે કારણ કે તેને કોરમની જરૂર છે: ત્રણ ઇન્સ્ટોલેશનના ક્લસ્ટર માટે, ઓછામાં ઓછા બે કાર્ય કરવું આવશ્યક છે. જો કે, આ નથી થઈ રહ્યું - માટે આભાર PodDisruptionBudget. આ પરિમાણ કાર્યકારી શીંગોની ન્યૂનતમ આવશ્યક સંખ્યા નક્કી કરે છે. એ જાણીને કે MongoDB પોડમાંથી એક હવે કામ કરતું નથી, અને જોવું કે PodDisruptionBudget MongoDB માટે સેટ કરેલ છે minAvailable: 2, Kubernetes તમને પોડ કાઢી નાખવાની મંજૂરી આપશે નહીં.

બોટમ લાઇન: જ્યારે ક્લસ્ટર રીલીઝ થાય ત્યારે પોડ્સની હિલચાલ (અને હકીકતમાં, પુનઃનિર્માણ) યોગ્ય રીતે કાર્ય કરવા માટે, પોડડિસ્રપ્શનબજેટને ગોઠવવું જરૂરી છે.

આડી સ્કેલિંગ

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

આજે કુબરનેટ્સમાં આ જાતે કરવાની જરૂર નથી: માપેલા લોડ સૂચકાંકોના મૂલ્યોના આધારે પોડ્સની સંખ્યામાં આપોઆપ વધારો/ઘટાડો ગોઠવવામાં આવે છે.

અહીં મુખ્ય પ્રશ્નો છે: બરાબર શું માપવું и કેવી રીતે અર્થઘટન કરવું પ્રાપ્ત મૂલ્યો (પોડ્સની સંખ્યા બદલવાનો નિર્ણય લેવા માટે). તમે ઘણું માપી શકો છો:

તકનીકી રીતે આ કેવી રીતે કરવું - મેટ્રિક્સ વગેરે એકત્રિત કરો. - મેં તેના વિશે અહેવાલમાં વિગતવાર વાત કરી મોનિટરિંગ અને કુબરનેટ્સ. અને શ્રેષ્ઠ પરિમાણો પસંદ કરવા માટેની મુખ્ય સલાહ છે પ્રયોગ!

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

તેના બદલે એક નિષ્કર્ષ

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

વિડિઓઝ અને સ્લાઇડ્સ

પ્રદર્શનમાંથી વિડિઓ (44 મિનિટ):

અહેવાલની રજૂઆત:

PS

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

• «કુબરનેટ્સનું વિસ્તરણ અને પૂરક» (આન્દ્રે પોલોવોવ; 8 એપ્રિલ, 2019 સેન્ટ હાઈલોડ++ પર);
• «ડેટાબેસેસ અને કુબરનેટ્સ» (દિમિત્રી સ્ટોલ્યારોવ; હાઇલોડ++ પર નવેમ્બર 8, 2018);
• «મોનિટરિંગ અને કુબરનેટ્સ» (દિમિત્રી સ્ટોલ્યારોવ; રૂટકોન્ફ ખાતે 28 મે, 2018);
• «કુબરનેટ્સ અને ગિટલેબ સાથે CI/CD શ્રેષ્ઠ વ્યવહારો» (દિમિત્રી સ્ટોલ્યારોવ; હાઇલોડ++ પર નવેમ્બર 7, 2017);
• «નાના પ્રોજેક્ટ્સમાં કુબરનેટ્સ સાથેનો અમારો અનુભવ» (દિમિત્રી સ્ટોલ્યારોવ; રૂટકોન્ફ ખાતે જૂન 6, 2017).

સોર્સ: www.habr.com