નવ કુબરનેટ્સ પ્રદર્શન ટિપ્સ

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

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

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

1. ટીમ અને એપ્લિકેશન સંસાધનોનો ટ્રૅક રાખો

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

resources:
   requests:
     memory: 2Gi
     cpu: 250m
   limits:
     memory: 4Gi
     cpu: 500m

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

વધુમાં, મદદ સાથે limitranges તમે શરૂઆતમાં કન્ટેનર માટે સંસાધન મૂલ્યો સેટ કરી શકો છો - ન્યૂનતમ, મહત્તમ અને ડિફોલ્ટ:

➜  ~ kubectl describe limitranges --namespace ops
Name:       limit-range
Namespace:  ops
Type        Resource           Min   Max   Default Request  Default Limit  Max Limit/Request Ratio
----        --------           ---   ---   ---------------  -------------  -----------------------
Container   cpu                50m   10    100m             100m           2
Container   ephemeral-storage  12Mi  8Gi   128Mi            4Gi            -
Container   memory             64Mi  40Gi  128Mi            128Mi          2

નેમસ્પેસ સંસાધનોને મર્યાદિત કરવાનું યાદ રાખો જેથી કરીને એક આદેશ ક્લસ્ટરના તમામ સંસાધનો લઈ ન શકે:

➜  ~ kubectl describe resourcequotas --namespace ops
Name:                   resource-quota
Namespace:              ops
Resource                Used          Hard
--------                ----          ----
limits.cpu              77250m        80
limits.memory           124814367488  150Gi
pods                    31            45
requests.cpu            53850m        80
requests.memory         75613234944   150Gi
services                26            50
services.loadbalancers  0             0
services.nodeports      0             0

જેમ તમે વર્ણનમાંથી જોઈ શકો છો resourcequotas, જો ops આદેશ અન્ય 10 સીપીયુનો વપરાશ કરશે તેવા પોડ્સને જમાવવા માંગે છે, તો શેડ્યૂલર તેને કરવાની મંજૂરી આપશે નહીં અને ભૂલ રજૂ કરશે:

Error creating: pods "nginx-proxy-9967d8d78-nh4fs" is forbidden: exceeded quota: resource-quota, requested: limits.cpu=5,requests.cpu=5, used: limits.cpu=77250m,requests.cpu=53850m, limited: limits.cpu=10,requests.cpu=10

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

2. શ્રેષ્ઠ ફાઇલ સ્ટોરેજ પસંદ કરો

અહીં હું સતત વોલ્યુમો અને કુબરનેટ્સ વર્કર નોડ્સની ડિસ્ક સબસિસ્ટમના વિષય પર સ્પર્શ કરવા માંગુ છું. હું આશા રાખું છું કે કોઈ પણ ઉત્પાદનમાં HDD પર "ક્યુબ" નો ઉપયોગ કરતું નથી, પરંતુ કેટલીકવાર નિયમિત SSD પણ પહેલાથી જ પૂરતું નથી. અમે એવી સમસ્યાનો સામનો કરવો પડ્યો કે લોગ્સ I/O ઑપરેશન્સ દ્વારા ડિસ્કને મારી નાખે છે, અને અહીં ઘણા બધા ઉકેલો નથી:

• ઉચ્ચ-પ્રદર્શન SSDs નો ઉપયોગ કરો અથવા NVMe પર સ્વિચ કરો (જો તમે તમારું પોતાનું હાર્ડવેર મેનેજ કરો છો).

• લોગીંગનું સ્તર ઘટાડવું.

• પોડ્સનું "સ્માર્ટ" સંતુલન કરો જે ડિસ્ક પર બળાત્કાર કરે છે (podAntiAffinity).

ઉપરનો સ્ક્રીનશોટ બતાવે છે કે ડિસ્ક સાથે nginx-ingress-controller હેઠળ શું થાય છે જ્યારે access_logs લોગિંગ સક્ષમ હોય (~12k logs/sec). આવી સ્થિતિ, અલબત્ત, આ નોડ પરની તમામ એપ્લિકેશનોના અધોગતિ તરફ દોરી શકે છે.

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

3. ઑપ્ટિમાઇઝ છબીઓ બનાવો

કન્ટેનર-ઑપ્ટિમાઇઝ કરેલી છબીઓનો ઉપયોગ કરવો શ્રેષ્ઠ છે જેથી કરીને કુબરનેટ્સ તેમને વધુ ઝડપથી આનયન કરી શકે અને વધુ અસરકારક રીતે ચલાવી શકે. 

ઑપ્ટિમાઇઝેશનનો અર્થ એ છે કે છબીઓ:

• ફક્ત એક જ એપ્લિકેશન ધરાવે છે અથવા ફક્ત એક જ કાર્ય કરે છે;

• નાના કદ, કારણ કે મોટી છબીઓ નેટવર્ક પર વધુ ખરાબ રીતે પ્રસારિત થાય છે;

• આરોગ્ય અને તત્પરતાના અંતિમ બિંદુઓ છે જેનો ઉપયોગ ડાઉનટાઇમની સ્થિતિમાં પગલાં લેવા માટે કુબરનેટ્સ કરી શકે છે;

• કન્ટેનર-ફ્રેંડલી ઓપરેટિંગ સિસ્ટમ્સનો ઉપયોગ કરો (જેમ કે આલ્પાઇન અથવા કોરઓએસ) જે રૂપરેખાંકન ભૂલો માટે વધુ પ્રતિરોધક છે;

• મલ્ટી-સ્ટેજ બિલ્ડ્સનો ઉપયોગ કરો જેથી તમે માત્ર સંકલિત એપ્લિકેશનો જ જમાવી શકો અને સાથેના સ્ત્રોતોને નહીં.

ત્યાં ઘણા સાધનો અને સેવાઓ છે જે તમને ફ્લાય પર છબીઓ તપાસવા અને ઑપ્ટિમાઇઝ કરવાની મંજૂરી આપે છે. તેમને હંમેશા અદ્યતન અને સુરક્ષિત રાખવું મહત્વપૂર્ણ છે. પરિણામે, તમે મેળવો છો:

1. સમગ્ર ક્લસ્ટર પર નેટવર્ક લોડ ઘટાડ્યો.

2. કન્ટેનર સ્ટાર્ટઅપનો સમય ઘટ્યો.

3. તમારી આખી ડોકર રજિસ્ટ્રીનું નાનું કદ.

4. DNS કેશનો ઉપયોગ કરો

જો આપણે ઉચ્ચ લોડ વિશે વાત કરીએ, તો ક્લસ્ટરની DNS સિસ્ટમને ટ્યુન કર્યા વિના, જીવન ખૂબ જ ખરાબ છે. એક સમયે, Kubernetes વિકાસકર્તાઓ તેમના kube-dns સોલ્યુશનને ટેકો આપતા હતા. તે આપણા દેશમાં પણ લાગુ કરવામાં આવ્યું હતું, પરંતુ આ સૉફ્ટવેર ખાસ કરીને ટ્યુન કર્યું નથી અને જરૂરી પ્રદર્શન આપ્યું નથી, તેમ છતાં, એવું લાગે છે કે કાર્ય સરળ છે. પછી કોર્ડન્સ દેખાયા, જેના પર અમે સ્વિચ કર્યું અને દુઃખ જાણતા નહોતા, પાછળથી તે K8s માં ડિફોલ્ટ DNS સેવા બની. અમુક સમયે, અમે DNS સિસ્ટમમાં 40 હજાર આરપીએસ સુધી વધ્યા, અને આ ઉકેલ પણ પૂરતો ન હતો. પરંતુ, એક નસીબદાર તક દ્વારા, Nodelocaldns બહાર આવ્યા, ઉર્ફ નોડ સ્થાનિક કેશ, ઉર્ફ નોડલોકલ DNScache.

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

5. શીંગોને આડા અને ઊભી રીતે આપમેળે સ્કેલ કરો

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

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

https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231 પરથી લેવામાં આવેલી છબી

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

ઉદાહરણ તરીકે, અહીં લાક્ષણિક પોડ સેટિંગ્સ છે:

resources:
   requests:
     memory: 250Mi
     cpu: 200m
   limits:
     memory: 500Mi
     cpu: 350m

ભલામણ એન્જિન નક્કી કરે છે કે તમારી એપ્લિકેશનને યોગ્ય રીતે ચલાવવા માટે 300m CPU અને 500Miની જરૂર છે. તમને આ સેટિંગ્સ મળશે:

resources:
   requests:
     memory: 500Mi
     cpu: 300m
   limits:
     memory: 1000Mi
     cpu: 525m

ઉપર જણાવ્યા મુજબ, મેનિફેસ્ટમાં વિનંતીઓ/મર્યાદાના ગુણોત્તરના આધારે આ પ્રમાણસર સ્કેલિંગ છે:

• CPU: 200m → 300m: ગુણોત્તર 1:1.75;

• મેમરી: 250Mi → 500Mi: 1:2 રેશિયો.

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

https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231 પરથી લેવામાં આવેલી છબી

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

6. નોડ એફિનિટી અને પોડ એફિનિટી વિશે ભૂલશો નહીં

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

જો તમારી પાસે ગણતરી-સઘન કામગીરી માટે યોગ્ય ગાંઠો હોય, તો મહત્તમ કાર્યક્ષમતા માટે, યોગ્ય નોડ્સ સાથે એપ્લિકેશનને બાંધવું વધુ સારું છે. આ કરવા માટે, ઉપયોગ કરો nodeSelector નોડ લેબલ સાથે.

ધારો કે તમારી પાસે બે ગાંઠો છે: એક સાથે CPUType=HIGHFREQ અને મોટી સંખ્યામાં ઝડપી કોરો, અન્ય સાથે MemoryType=HIGHMEMORY વધુ મેમરી અને ઝડપી કામગીરી. નોડને પોડ ડિપ્લોયમેન્ટ સોંપવાનો સૌથી સહેલો રસ્તો છે HIGHFREQવિભાગમાં ઉમેરીને spec આના જેવો પસંદગીકાર:

…
nodeSelector:
	CPUType: HIGHFREQ

આ કરવા માટે વધુ ખર્ચાળ અને વિશિષ્ટ રીતનો ઉપયોગ કરવો છે nodeAffinity ક્ષેત્રમાં affinity ઓ spec. ત્યાં બે વિકલ્પો છે:

• requiredDuringSchedulingIgnoredDuringExecution: હાર્ડ સેટિંગ (શેડ્યુલર ફક્ત ચોક્કસ નોડ્સ પર જ પોડ્સ જમાવશે (અને બીજે ક્યાંય નહીં));

• preferredDuringSchedulingIgnoredDuringExecution: સોફ્ટ સેટિંગ (શેડ્યુલર ચોક્કસ નોડ્સ પર જમાવટ કરવાનો પ્રયાસ કરશે, અને જો તે નિષ્ફળ જાય, તો તે આગામી ઉપલબ્ધ નોડ પર જમાવટ કરવાનો પ્રયાસ કરશે).

તમે નોડ લેબલ્સનું સંચાલન કરવા માટે ચોક્કસ સિન્ટેક્સનો ઉલ્લેખ કરી શકો છો, ઉદાહરણ તરીકે, In, NotIn, Exists, DoesNotExist, Gt અથવા Lt. જો કે, યાદ રાખો કે લેબલોની લાંબી સૂચિમાં જટિલ પદ્ધતિઓ જટિલ પરિસ્થિતિઓમાં નિર્ણય લેવાની પ્રક્રિયાને ધીમું કરશે. બીજા શબ્દોમાં કહીએ તો, વધુ જટિલ ન કરો.

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

В podAffinity ક્ષેત્રો affinity ઓ spec ના કિસ્સામાં સમાન ક્ષેત્રો ઉપલબ્ધ છે nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution и preferredDuringSchedulingIgnoredDuringExecution. ફરક માત્ર એટલો જ છે matchExpressions પોડ્સને નોડ સાથે જોડશે જે તે લેબલ સાથે પહેલેથી જ પોડ ચલાવી રહ્યું છે.

વધુ કુબરનેટ્સ એક ક્ષેત્ર પ્રદાન કરે છે podAntiAffinity, જે, તેનાથી વિપરિત, ચોક્કસ પોડ્સ સાથે નોડ સાથે પોડને બાંધતું નથી.

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

7. કલંક અને સહનશીલતા

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

કલંકની પદ્ધતિ - પ્રતિબંધિત નિયમો - આમાં મદદ કરે છે. ઉદાહરણ તરીકે, તમે ચોક્કસ નોડ્સને અમુક પરિસ્થિતિઓમાં પોડ્સ ચલાવવાથી રોકી શકો છો. ચોક્કસ નોડ પર કલંક લાગુ કરવા માટે, વિકલ્પનો ઉપયોગ કરો taint kubectl માં. કી અને મૂલ્યનો ઉલ્લેખ કરો અને પછી કલંક કરો NoSchedule અથવા NoExecute:

$ kubectl taint nodes node10 node-role.kubernetes.io/ingress=true:NoSchedule

તે નોંધવું પણ યોગ્ય છે કે કલંક પદ્ધતિ ત્રણ મુખ્ય અસરોને સમર્થન આપે છે: NoSchedule, NoExecute и PreferNoSchedule.

• NoSchedule એટલે કે જ્યાં સુધી પોડ સ્પષ્ટીકરણમાં અનુરૂપ એન્ટ્રી ન હોય ત્યાં સુધી tolerations, તે નોડ પર જમાવી શકાતું નથી (આ ઉદાહરણમાં node10).

• PreferNoSchedule - સરળ સંસ્કરણ NoSchedule. આ કિસ્સામાં, શેડ્યૂલર એવા પોડ્સની ફાળવણી ન કરવાનો પ્રયાસ કરશે કે જેમાં મેચિંગ એન્ટ્રી નથી. tolerations નોડ દીઠ, પરંતુ આ સખત મર્યાદા નથી. જો ક્લસ્ટરમાં કોઈ સંસાધનો ન હોય, તો પછી શીંગો આ નોડ પર જમાવટ કરવાનું શરૂ કરશે.

• NoExecute - આ અસર પોડ્સને તાત્કાલિક ખાલી કરવા માટે ટ્રિગર કરે છે જેમાં મેચિંગ એન્ટ્રી નથી tolerations.

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

પોડ સ્પેક કેવો દેખાશે તે અહીં છે:

spec:
   tolerations:
     - key: "node-role.kubernetes.io/ingress"
        operator: "Equal"
        value: "true"
        effect: "NoSchedule"

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

8. પોડ ડિપ્લોયમેન્ટ પ્રાધાન્યતા સેટ કરો

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

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

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 99999
globalDefault: false
description: "This priority class should be used for very important pods only"

અમે બનાવીએ છીએ PriorityClass, તેને નામ, વર્ણન અને મૂલ્ય આપો. ઉચ્ચ value, ઉચ્ચ અગ્રતા. મૂલ્ય કોઈપણ 32-બીટ પૂર્ણાંક 1 કરતાં ઓછું અથવા તેની બરાબર હોઈ શકે છે. ઉચ્ચ મૂલ્યો મિશન-ક્રિટીકલ સિસ્ટમ પોડ્સ માટે આરક્ષિત છે, જે સામાન્ય રીતે પૂર્વેમ્પ્ટ કરી શકાતા નથી. ખાલી કરાવવાની પ્રક્રિયા ત્યારે જ થશે જ્યારે ઉચ્ચ-પ્રાયોરિટી પોડમાં ક્યાંય ફરવાનું ન હોય, તો ચોક્કસ નોડમાંથી કેટલાક પોડ્સ ખાલી કરવામાં આવશે. જો આ મિકેનિઝમ તમારા માટે ખૂબ કઠોર છે, તો પછી તમે વિકલ્પ ઉમેરી શકો છો preemptionPolicy: Never, અને પછી કોઈ પૂર્વગ્રહ રહેશે નહીં, પોડ કતારમાં પ્રથમ હશે અને તેના માટે મફત સંસાધનો શોધવા માટે શેડ્યૂલરની રાહ જુઓ.

આગળ, અમે એક પોડ બનાવીએ છીએ, જેમાં આપણે નામનો ઉલ્લેખ કરીએ છીએ priorityClassName:

apiVersion: v1
kind: Pod
metadata:
  name: static-web
  labels:
    role: myrole
 spec:
  containers:
    - name: web
      image: nginx
      ports:
        - name: web
          containerPort: 80
          protocol: TCP
  priorityClassName: high-priority
          

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

આમ, જો જરૂરી હોય તો, તમે નિર્ણાયક સેવાઓ, જેમ કે nginx-ingress-controller, coredns, વગેરેને જમાવવાની કાર્યક્ષમતા વધારી શકો છો.

9. તમારા ETCD ક્લસ્ટરને ઑપ્ટિમાઇઝ કરો

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

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

જો આપણે સેવા સેટ કરવા વિશે વાત કરીએ, તો ત્યાં થોડી ભલામણો છે:

1. ક્લસ્ટરના કદના આધારે સારા હાર્ડવેર રાખો (તમે વાંચી શકો છો અહીં).

2. જો તમે DC ની જોડી અથવા તમારા નેટવર્ક અને ડિસ્ક વચ્ચે ક્લસ્ટર ફેલાવ્યું હોય તો થોડા પરિમાણોને ટ્વીક કરો (તમે વાંચી શકો છો) અહીં).

નિષ્કર્ષ

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

સોર્સ: www.habr.com