CPU મર્યાદા અને કુબરનેટ્સમાં આક્રમક થ્રોટલિંગ

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

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

TL; DR:
જો તમે CFS ક્વોટા બગ સાથે Linux કર્નલના સંસ્કરણનો ઉપયોગ કરી રહ્યાં હોવ તો અમે Kubernetes (અથવા Kubelet માં CFS ક્વોટાને અક્ષમ કરવા) માં CPU મર્યાદાને અક્ષમ કરવાની ભારપૂર્વક ભલામણ કરીએ છીએ. કોર માં ઉપલબ્ધ છે ગંભીર અને જાણીતા એક બગ જે અતિશય થ્રોટલિંગ અને વિલંબ તરફ દોરી જાય છે.

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

લેખનો સારાંશ:

• કન્ટેનર અને કુબરનેટ્સ વિશે થોડાક શબ્દો;
• CPU વિનંતીઓ અને મર્યાદાઓ કેવી રીતે લાગુ કરવામાં આવે છે;
• મલ્ટિ-કોર વાતાવરણમાં CPU મર્યાદા કેવી રીતે કામ કરે છે;
• CPU થ્રોટલિંગને કેવી રીતે ટ્રૅક કરવું;
• સમસ્યાનું સમાધાન અને ઘોંઘાટ.

કન્ટેનર અને કુબરનેટ્સ વિશે થોડાક શબ્દો

કુબરનેટ્સ એ ઇન્ફ્રાસ્ટ્રક્ચર વિશ્વમાં આવશ્યકપણે આધુનિક ધોરણ છે. તેનું મુખ્ય કાર્ય કન્ટેનર ઓર્કેસ્ટ્રેશન છે.

કન્ટેનર

ભૂતકાળમાં, સર્વર પર ચલાવવા માટે અમારે Java JARs/WARs, Python Eggs અથવા એક્ઝિક્યુટેબલ્સ જેવી કલાકૃતિઓ બનાવવી પડતી હતી. જો કે, તેમને કાર્ય કરવા માટે, વધારાનું કામ કરવું પડ્યું: રનટાઇમ એન્વાયર્નમેન્ટ (જાવા/પાયથોન) ઇન્સ્ટોલ કરવું, જરૂરી ફાઇલોને યોગ્ય સ્થાનો પર મૂકવી, ઑપરેટિંગ સિસ્ટમના ચોક્કસ સંસ્કરણ સાથે સુસંગતતાની ખાતરી કરવી વગેરે. બીજા શબ્દોમાં કહીએ તો, રૂપરેખાંકન વ્યવસ્થાપન પર સાવચેતીપૂર્વક ધ્યાન આપવું પડતું હતું (જે ઘણીવાર વિકાસકર્તાઓ અને સિસ્ટમ સંચાલકો વચ્ચે વિવાદનું કારણ હતું).

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

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

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

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

સામાન્ય માણસના દૃષ્ટિકોણથી કુબરનેટ્સ

કુબરનેટ્સમાં વિનંતીઓ અને મર્યાદાઓ શું છે

ઠીક છે, અમે કન્ટેનર અને કુબરનેટ્સ આવરી લીધા છે. અમે એ પણ જાણીએ છીએ કે એક જ મશીન પર બહુવિધ કન્ટેનર રહી શકે છે.

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

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

કુબરનેટ્સમાં વિનંતીઓ અને મર્યાદાઓ કેવી રીતે લાગુ કરવામાં આવે છે

કુબરનેટ્સ CPU મર્યાદાને અમલમાં મૂકવા માટે કર્નલમાં બનેલ થ્રોટલિંગ મિકેનિઝમ (ઘડિયાળના ચક્રને અવગણવા) નો ઉપયોગ કરે છે. જો એપ્લિકેશન મર્યાદા ઓળંગે છે, તો થ્રોટલિંગ સક્ષમ છે (એટલે ​​​​કે તે ઓછા CPU ચક્ર મેળવે છે). મેમરી માટેની વિનંતીઓ અને મર્યાદાઓ અલગ રીતે ગોઠવવામાં આવે છે, તેથી તે શોધવામાં સરળ છે. આ કરવા માટે, ફક્ત પોડની છેલ્લી પુનઃપ્રારંભ સ્થિતિ તપાસો: શું તે "OOMKilled" છે. CPU થ્રોટલિંગ એટલું સરળ નથી, કારણ કે K8s માત્ર ઉપયોગ દ્વારા મેટ્રિક્સ ઉપલબ્ધ કરાવે છે, cgroups દ્વારા નહીં.

CPU વિનંતી

CPU વિનંતી કેવી રીતે લાગુ કરવામાં આવે છે

સરળતા માટે, ચાલો ઉદાહરણ તરીકે 4-કોર CPU સાથે મશીનનો ઉપયોગ કરીને પ્રક્રિયા જોઈએ.

K8s સંસાધનોની ફાળવણી (મેમરી અને પ્રોસેસર) ને નિયંત્રિત કરવા માટે નિયંત્રણ જૂથ પદ્ધતિ (cgroups) નો ઉપયોગ કરે છે. તેના માટે એક અધિક્રમિક મોડેલ ઉપલબ્ધ છે: બાળકને પિતૃ જૂથની મર્યાદાઓ વારસામાં મળે છે. વિતરણ વિગતો વર્ચ્યુઅલ ફાઇલ સિસ્ટમમાં સંગ્રહિત થાય છે (/sys/fs/cgroup). પ્રોસેસરના કિસ્સામાં આ છે /sys/fs/cgroup/cpu,cpuacct/*.

K8s ફાઇલનો ઉપયોગ કરે છે cpu.share પ્રોસેસર સંસાધનો ફાળવવા. અમારા કિસ્સામાં, રૂટ સીગ્રુપને CPU સંસાધનોના 4096 શેર મળે છે - ઉપલબ્ધ પ્રોસેસર પાવરના 100% (1 કોર = 1024; આ એક નિશ્ચિત મૂલ્ય છે). રુટ જૂથમાં નોંધાયેલા વંશજોના શેરના આધારે પ્રમાણસર સંસાધનોનું વિતરણ કરે છે cpu.share, અને તેઓ, બદલામાં, તેમના વંશજો સાથે તે જ કરે છે, વગેરે. લાક્ષણિક કુબરનેટીસ નોડ પર, રુટ સીગ્રુપને ત્રણ બાળકો છે: system.slice, user.slice и kubepods. પ્રથમ બે પેટાજૂથોનો ઉપયોગ ક્રિટિકલ સિસ્ટમ લોડ અને K8 ની બહારના યુઝર પ્રોગ્રામ્સ વચ્ચે સંસાધનોનું વિતરણ કરવા માટે થાય છે. છેલ્લા એક - kubepods - પોડ્સ વચ્ચે સંસાધનોનું વિતરણ કરવા માટે કુબરનેટ્સ દ્વારા બનાવેલ.

ઉપરોક્ત આકૃતિ દર્શાવે છે કે પ્રથમ અને બીજા પેટાજૂથો દરેકને પ્રાપ્ત થયા છે 1024 ફાળવેલ કુબેરપોડ પેટાજૂથ સાથેના શેર 4096 શેર આ કેવી રીતે શક્ય છે: છેવટે, રુટ જૂથ પાસે ફક્ત ઍક્સેસ છે 4096 શેર, અને તેના વંશજોના શેરનો સરવાળો નોંધપાત્ર રીતે આ સંખ્યા કરતાં વધી ગયો છે (6144)? મુદ્દો એ છે કે મૂલ્ય તાર્કિક અર્થમાં છે, તેથી Linux શેડ્યૂલર (CFS) તેનો ઉપયોગ CPU સંસાધનોને પ્રમાણસર ફાળવવા માટે કરે છે. અમારા કિસ્સામાં, પ્રથમ બે જૂથો પ્રાપ્ત કરે છે 680 વાસ્તવિક શેર્સ (16,6 ના 4096%), અને કુબેપોડ બાકીના મેળવે છે 2736 શેર ડાઉનટાઇમના કિસ્સામાં, પ્રથમ બે જૂથો ફાળવેલ સંસાધનોનો ઉપયોગ કરશે નહીં.

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

આ મિકેનિઝમ પ્રોસેસર પાવરનું યોગ્ય વિતરણ સુનિશ્ચિત કરે છે અને ખાતરી કરે છે કે કોઈ પણ અન્ય લોકો પાસેથી સંસાધનોની "ચોરી" કરે નહીં.

CPU મર્યાદા

K8s માં મર્યાદાઓ અને વિનંતીઓના રૂપરેખાંકનો સમાન દેખાય છે તે હકીકત હોવા છતાં, તેમનું અમલીકરણ ધરમૂળથી અલગ છે: આ સૌથી ભ્રામક અને સૌથી ઓછો દસ્તાવેજીકૃત ભાગ.

K8s જોડાય છે CFS ક્વોટા મિકેનિઝમ મર્યાદા લાગુ કરવા. તેમની સેટિંગ્સ ફાઇલોમાં ઉલ્લેખિત છે cfs_period_us и cfs_quota_us cgroup ડિરેક્ટરીમાં (ફાઇલ પણ ત્યાં સ્થિત છે cpu.share).

વિપરીત cpu.share, ક્વોટા પર આધારિત છે સમયગાળો, અને ઉપલબ્ધ પ્રોસેસર પાવર પર નહીં. cfs_period_us સમયગાળો (યુગ) નો ઉલ્લેખ કરે છે - તે હંમેશા 100000 μs (100 ms) હોય છે. K8s માં આ મૂલ્ય બદલવાનો વિકલ્પ છે, પરંતુ તે હમણાં માટે માત્ર આલ્ફામાં ઉપલબ્ધ છે. શેડ્યૂલર વપરાયેલ ક્વોટાને પુનઃપ્રારંભ કરવા માટે યુગનો ઉપયોગ કરે છે. બીજી ફાઇલ cfs_quota_us, દરેક યુગમાં ઉપલબ્ધ સમય (ક્વોટા) નો ઉલ્લેખ કરે છે. નોંધ કરો કે તે માઇક્રોસેકન્ડ્સમાં પણ ઉલ્લેખિત છે. ક્વોટા યુગની લંબાઈ કરતાં વધી શકે છે; બીજા શબ્દોમાં કહીએ તો, તે 100 ms કરતા વધારે હોઈ શકે છે.

ચાલો 16-કોર મશીનો પર બે દૃશ્યો જોઈએ (ઓમિયોમાં આપણી પાસે સૌથી સામાન્ય પ્રકારનું કમ્પ્યુટર છે):

દૃશ્ય 1: 2 થ્રેડો અને 200 ms મર્યાદા. કોઈ થ્રોટલિંગ નથી

દૃશ્ય 2: 10 થ્રેડો અને 200 ms મર્યાદા. થ્રોટલિંગ 20 ms પછી શરૂ થાય છે, પ્રોસેસર સંસાધનોની ઍક્સેસ બીજા 80 ms પછી ફરી શરૂ થાય છે

ચાલો કહીએ કે તમે CPU મર્યાદા સેટ કરી છે 2 કર્નલો; Kubernetes આ મૂલ્યને 200 ms માં અનુવાદિત કરશે. આનો અર્થ એ છે કે કન્ટેનર થ્રોટલિંગ વિના મહત્તમ 200ms CPU સમયનો ઉપયોગ કરી શકે છે.

અને આ તે છે જ્યાં મજા શરૂ થાય છે. ઉપર જણાવ્યા મુજબ, ઉપલબ્ધ ક્વોટા 200 ms છે. જો તમે સમાંતર કામ કરી રહ્યા છો દસ 12-કોર મશીન પર થ્રેડો (પરિદ્રશ્ય 2 માટે ચિત્ર જુઓ), જ્યારે અન્ય તમામ પોડ્સ નિષ્ક્રિય હોય, ત્યારે ક્વોટા માત્ર 20 ms (10 * 20 ms = 200 ms થી) માં ખતમ થઈ જશે અને આ પોડના તમામ થ્રેડો અટકી જશે » (થ્રોટલ) આગામી 80 ms માટે પહેલેથી જ ઉલ્લેખ કર્યો છે શેડ્યૂલર બગ, જેના કારણે અતિશય થ્રોટલિંગ થાય છે અને કન્ટેનર હાલના ક્વોટાને પણ પૂર્ણ કરી શકતું નથી.

શીંગોમાં થ્રોટલિંગનું મૂલ્યાંકન કેવી રીતે કરવું?

ફક્ત પોડ પર લોગિન કરો અને એક્ઝિક્યુટ કરો cat /sys/fs/cgroup/cpu/cpu.stat.

• nr_periods - શેડ્યૂલર સમયગાળાની કુલ સંખ્યા;
• nr_throttled - રચનામાં થ્રોટલ્ડ સમયગાળાની સંખ્યા nr_periods;
• throttled_time — નેનોસેકન્ડમાં સંચિત થ્રોટલ સમય.

ખરેખર શું ચાલી રહ્યું છે?

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

આ વિવિધ ભૂલો તરફ દોરી જાય છે - તત્પરતા તપાસ નિષ્ફળતાઓ, કન્ટેનર ફ્રીઝ, નેટવર્ક કનેક્શન વિરામ, સેવા કૉલમાં સમય સમાપ્તિ. આ આખરે લેટન્સીમાં વધારો અને ઉચ્ચ ભૂલ દરમાં પરિણમે છે.

નિર્ણય અને પરિણામો

અહીં બધું સરળ છે. અમે CPU મર્યાદા છોડી દીધી છે અને ક્લસ્ટરમાં OS કર્નલને નવીનતમ સંસ્કરણ પર અપડેટ કરવાનું શરૂ કર્યું છે, જેમાં બગ ઠીક કરવામાં આવ્યો હતો. અમારી સેવાઓમાં ભૂલોની સંખ્યા (HTTP 5xx) તરત જ નોંધપાત્ર રીતે ઘટી ગઈ:

HTTP 5xx ભૂલો

એક જટિલ સેવા માટે HTTP 5xx ભૂલો

પ્રતિભાવ સમય p95

જટિલ સેવા વિનંતી લેટન્સી, 95મી પર્સેન્ટાઇલ

ચલાવવા નો ખર્ચ

વિતાવેલ દાખલા કલાકોની સંખ્યા

કેચ શું છે?

લેખની શરૂઆતમાં જણાવ્યા મુજબ:

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

આ રહ્યો કેચ. એક બેદરકાર કન્ટેનર મશીન પર ઉપલબ્ધ તમામ CPU સંસાધનો ખાઈ શકે છે. જો તમારી પાસે સ્માર્ટ એપ્લિકેશન સ્ટેક છે (ઉદાહરણ તરીકે, JVM, Go, Node VM યોગ્ય રીતે ગોઠવેલ છે), તો આ કોઈ સમસ્યા નથી: તમે આવી પરિસ્થિતિઓમાં લાંબા સમય સુધી કામ કરી શકો છો. પરંતુ જો એપ્લીકેશન ખરાબ રીતે ઑપ્ટિમાઇઝ કરવામાં આવી હોય અથવા બિલકુલ ઑપ્ટિમાઇઝ ન હોય તો (FROM java:latest), પરિસ્થિતિ નિયંત્રણ બહાર જઈ શકે છે. Omio પર અમારી પાસે મુખ્ય ભાષાના સ્ટેક માટે પર્યાપ્ત ડિફોલ્ટ સેટિંગ્સ સાથે સ્વચાલિત બેઝ ડોકરફાઈલ્સ છે, તેથી આ સમસ્યા અસ્તિત્વમાં નથી.

અમે મેટ્રિક્સનું નિરીક્ષણ કરવાની ભલામણ કરીએ છીએ વાપરવુ (ઉપયોગ, સંતૃપ્તિ અને ભૂલો), API વિલંબ અને ભૂલ દર. ખાતરી કરો કે પરિણામો અપેક્ષાઓને પૂર્ણ કરે છે.

સંદર્ભો

આ અમારી વાર્તા છે. નીચેની સામગ્રીએ શું થઈ રહ્યું છે તે સમજવામાં ખૂબ મદદ કરી:

• kernel.org → CFS શેડ્યૂલર;
• kernel.org → CFS બેન્ડવિડ્થ નિયંત્રણ;
• Linux કન્ટેનર શેડ્યુલિંગને સમજવું;
• Linux કન્ટેનર વિશે તમારે જે જાણવાની જરૂર છે તે બધું, ભાગ I: Linux નિયંત્રણ જૂથો અને પ્રક્રિયા અલગતા;
• કુબરનેટ્સ નિષ્ફળતા વાર્તાઓ - "cpu થ્રોટલિંગ" માટે જુઓ.

કુબરનેટ્સ બગ રિપોર્ટ્સ:

• #51135: બાંયધરીકૃત પોડ્સ માટે CPU મર્યાદા સેટ કરવાનું ટાળો;
• #67577: CFS ક્વોટા બિનજરૂરી થ્રોટલિંગ તરફ દોરી શકે છે;
• અતિશય આક્રમક CFS.

શું તમને તમારી પ્રેક્ટિસમાં સમાન સમસ્યાઓનો સામનો કરવો પડ્યો છે અથવા કન્ટેનરાઇઝ્ડ ઉત્પાદન વાતાવરણમાં થ્રોટલિંગ સંબંધિત અનુભવ છે? ટિપ્પણીઓમાં તમારી વાર્તા શેર કરો!

અનુવાદક તરફથી પીએસ

અમારા બ્લોગ પર પણ વાંચો:

• «કુબરનેટ્સમાં ઓટોસ્કેલિંગ અને સંસાધન સંચાલન (સમીક્ષા અને વિડિયો રિપોર્ટ)»;
• «કુબરનેટ્સમાં CPU મેનેજર કેવી રીતે કાર્ય કરે છે»;
• «જ્યારે તમે kubectl રન ચલાવો છો ત્યારે કુબરનેટ્સમાં શું થાય છે? ભાગ 2».

સોર્સ: www.habr.com