કુબરનેટ્સ: CPU મર્યાદાઓ દૂર કરીને તમારી સેવાઓને ઝડપી બનાવો

2016 માં પાછા અમે બફર પર કુબરનેટ્સ પર સ્વિચ કર્યું, અને હવે લગભગ 60 નોડ્સ (AWS પર) અને 1500 કન્ટેનર અમારા દ્વારા સંચાલિત k8s ક્લસ્ટર પર કામ કરી રહ્યા છે કોપ્સ. જો કે, અમે અજમાયશ અને ભૂલ દ્વારા માઇક્રોસર્વિસીસમાં ગયા, અને k8s સાથે કામ કર્યાના ઘણા વર્ષો પછી પણ અમને નવી સમસ્યાઓનો સામનો કરવો પડી રહ્યો છે. આ પોસ્ટમાં આપણે તેના વિશે વાત કરીશું પ્રોસેસરની મર્યાદાઓ: શા માટે અમને લાગ્યું કે તેઓ સારી પ્રેક્ટિસ છે અને શા માટે તેઓ એટલા સારા નથી રહ્યા.

પ્રોસેસરની મર્યાદાઓ અને થ્રોટલિંગ

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

પ્રોસેસર મર્યાદા કન્ટેનરને ચોક્કસ સમયગાળા માટે ઉપયોગ કરી શકે તેવા મહત્તમ CPU સમય પર સેટ કરે છે (ડિફોલ્ટ 100ms છે), અને કન્ટેનર આ મર્યાદાને ક્યારેય ઓળંગશે નહીં. માટે Kubernetes માં થ્રોટલિંગ કન્ટેનર અને તેને મર્યાદા ઓળંગતા અટકાવવા માટે, એક વિશિષ્ટ સાધનનો ઉપયોગ કરવામાં આવે છે CFS ક્વોટા, પરંતુ આ કૃત્રિમ CPU મર્યાદાઓ પ્રભાવને નુકસાન પહોંચાડે છે અને તમારા કન્ટેનરનો પ્રતિભાવ સમય વધારે છે.

જો આપણે પ્રોસેસરની મર્યાદા સેટ ન કરીએ તો શું થઈ શકે?

કમનસીબે, આપણે જાતે જ આ સમસ્યાનો સામનો કરવો પડ્યો. દરેક નોડમાં કન્ટેનરના સંચાલન માટે જવાબદાર પ્રક્રિયા હોય છે kubelet, અને તેણે વિનંતીઓનો જવાબ આપવાનું બંધ કરી દીધું. નોડ, જ્યારે આવું થાય છે, રાજ્યમાં જશે NotReady, અને તેમાંથી કન્ટેનર બીજે ક્યાંક રીડાયરેક્ટ કરવામાં આવશે અને નવા નોડ્સ પર સમાન સમસ્યાઓ ઊભી કરશે. ઓછામાં ઓછું કહેવા માટે, આદર્શ દૃશ્ય નથી.

થ્રોટલિંગ અને પ્રતિભાવની સમસ્યાનું અભિવ્યક્તિ

કન્ટેનર ટ્રેકિંગ માટે મુખ્ય મેટ્રિક છે trottling, તે બતાવે છે કે તમારું કન્ટેનર કેટલી વાર થ્રોટલ કરવામાં આવ્યું છે. અમે રસ સાથે કેટલાક કન્ટેનરમાં થ્રોટલિંગની હાજરીની નોંધ લીધી, પછી ભલેને પ્રોસેસરનો ભાર આત્યંતિક હોય કે ન હોય. ઉદાહરણ તરીકે, ચાલો અમારા એક મુખ્ય API પર એક નજર કરીએ:

જેમ તમે નીચે જોઈ શકો છો, અમે મર્યાદા સેટ કરી છે 800m (0.8 અથવા 80% કોર), અને શ્રેષ્ઠ પહોંચ પર ટોચના મૂલ્યો 200m (20% કોર). એવું લાગે છે કે સેવાને થ્રોટલ કરતા પહેલા અમારી પાસે હજી પણ પુષ્કળ પ્રોસેસર પાવર છે, તેમ છતાં ...

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

આનો સામનો કરીને, અમે ટૂંક સમયમાં ઘણા સંસાધનો શોધી કાઢ્યા (ગીથબ પર સમસ્યા, zadano પર રજૂઆત, omio પર પોસ્ટ કરો) થ્રોટલિંગને કારણે સેવાઓના પ્રદર્શન અને પ્રતિભાવ સમયના ઘટાડા વિશે.

નીચા CPU લોડ પર આપણે થ્રોટલિંગ કેમ જોઈએ છીએ? ટૂંકું સંસ્કરણ છે: "લિનક્સ કર્નલમાં એક બગ છે જે નિર્દિષ્ટ પ્રોસેસર મર્યાદા સાથે કન્ટેનરને બિનજરૂરી થ્રોટલિંગનું કારણ બને છે." જો તમને સમસ્યાની પ્રકૃતિમાં રસ હોય, તો તમે પ્રસ્તુતિ વાંચી શકો છો (видео и લખાણ વિકલ્પો) ડેવ ચિલુક દ્વારા.

CPU પ્રતિબંધો દૂર કરી રહ્યા છીએ (અત્યંત સાવધાની સાથે)

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

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

દબાણયુક્ત મુદ્દા પર વ્યવસાયિક પત્રવ્યવહાર.

જ્યારે પ્રતિબંધો હટાવવામાં આવે ત્યારે તમારા ગાંઠોનું રક્ષણ કેવી રીતે કરવું?

"અપ્રતિબંધિત" સેવાઓનું અલગતા:

ભૂતકાળમાં, અમે પહેલાથી જ કેટલાક ગાંઠો રાજ્યમાં આવતા જોયા છે notReady, મુખ્યત્વે ઘણી બધી સંસાધનોનો ઉપયોગ કરતી સેવાઓને કારણે.

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

યોગ્ય પ્રોસેસર અને મેમરી વિનંતી સોંપવી:

અમારો સૌથી મોટો ભય એ હતો કે પ્રક્રિયા ઘણા બધા સંસાધનોનો ઉપયોગ કરશે અને નોડ વિનંતીઓનો જવાબ આપવાનું બંધ કરશે. હવેથી (ડેટાડોગનો આભાર) અમે અમારા ક્લસ્ટર પરની તમામ સેવાઓને સ્પષ્ટપણે મોનિટર કરી શકીએ છીએ, મેં "અસંબંધિત" તરીકે નિયુક્ત કરવાની યોજના બનાવી હોય તેવા કેટલાક મહિનાના સંચાલનનું વિશ્લેષણ કર્યું. હું ફક્ત 20% ના માર્જિન સાથે મહત્તમ CPU વપરાશ સેટ કરું છું, અને આ રીતે k8s નોડને અન્ય સેવાઓ સોંપવાનો પ્રયાસ કરે તો નોડમાં જગ્યા ફાળવી.

જેમ તમે ગ્રાફમાં જોઈ શકો છો, પ્રોસેસર પરનો મહત્તમ લોડ પહોંચી ગયો છે 242m CPU કોરો (0.242 પ્રોસેસર કોરો). પ્રોસેસરની વિનંતી માટે, આ મૂલ્ય કરતાં સહેજ મોટી સંખ્યા લેવા માટે તે પૂરતું છે. કૃપા કરીને નોંધો કે સેવાઓ વપરાશકર્તા-કેન્દ્રિત હોવાથી, પીક લોડ મૂલ્યો ટ્રાફિક સાથે સુસંગત છે.

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

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

રિઝલ્ટ

છેલ્લાં કેટલાંક અઠવાડિયાંના પ્રયોગોમાંથી આ ઉત્કૃષ્ટ પરિણામો પ્રકાશિત કરવામાં મને આનંદ થાય છે; અમે બધી સંશોધિત સેવાઓમાં પ્રતિભાવમાં નોંધપાત્ર સુધારાઓ જોયા છે:

અમે અમારા હોમ પેજ પર શ્રેષ્ઠ પરિણામો પ્રાપ્ત કર્યા છે (buffer.com), ત્યાં સેવામાં વેગ આવ્યો બાવીસ વખત!

શું Linux કર્નલ બગ સુધારેલ છે?

હા, બગ પહેલાથી જ સુધારેલ છે અને ફિક્સ કર્નલમાં ઉમેરવામાં આવેલ છે વિતરણ સંસ્કરણ 4.19 અને ઉચ્ચ.

જો કે, વાંચીને github પર kubernetes સમસ્યાઓ સપ્ટેમ્બર 2020 ના બીજા માટે અમે હજુ પણ સમાન બગ સાથે કેટલાક Linux પ્રોજેક્ટના ઉલ્લેખો પર આવીએ છીએ. હું માનું છું કે કેટલાક Linux વિતરણોમાં હજુ પણ આ બગ છે અને તે માત્ર તેને ઠીક કરવા પર કામ કરી રહ્યાં છે.

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

• ડેબિયન: વિતરણના નવીનતમ સંસ્કરણમાં સંકલિત ફિક્સ, બસ્ટર, અને તદ્દન તાજી દેખાય છે (2020ગસ્ટ XNUMX). કેટલાક અગાઉના સંસ્કરણો પણ નિશ્ચિત થઈ શકે છે.
• ઉબુન્ટુ: નવીનતમ સંસ્કરણમાં સંકલિત ફિક્સ ઉબુન્ટુ ફોકલ ફોસા 20.04
• EKS ને હજુ સુધી સુધારો થયો છે ડિસેમ્બર 2019 માં. જો તમારું વર્ઝન આનાથી ઓછું છે, તો તમારે AMI અપડેટ કરવું જોઈએ.
• કોપ્સ: જૂન 2020 થી у kops 1.18+ મુખ્ય હોસ્ટ ઇમેજ ઉબુન્ટુ 20.04 હશે. જો કોપ્સનું તમારું સંસ્કરણ જૂનું છે, તો તમારે સુધારા માટે રાહ જોવી પડશે. અમે પોતે હવે રાહ જોઈ રહ્યા છીએ.
• GKE (Google Cloud): ફિક્સ ઇન્ટિગ્રેટેડ જાન્યુઆરી 2020 માં, જોકે થ્રોટલિંગ સાથે સમસ્યાઓ છે હજુ પણ અવલોકન કરવામાં આવે છે.

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

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

નિષ્કર્ષ

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

હું આશા રાખું છું કે આ પોસ્ટ તમને તમારી કન્ટેનર સિસ્ટમના પ્રદર્શનને સુધારવામાં મદદ કરશે.

PS તે લેખક વાચકો અને વિવેચકો (અંગ્રેજીમાં) સાથે પત્રવ્યવહાર કરે છે.


સોર્સ: www.habr.com