કુબરનેટ્સનો ઉપયોગ કરતી વખતે 10 સામાન્ય ભૂલો

નૉૅધ. અનુવાદ: આ લેખના લેખકો નાની ચેક કંપની, પાઇપટેલના એન્જિનિયરો છે. તેઓ કુબરનેટ્સ ક્લસ્ટરોના સંચાલનને લગતી ખૂબ જ દબાવનારી સમસ્યાઓ અને ગેરસમજોની [ક્યારેક મામૂલી, પરંતુ હજુ પણ] અદ્ભુત સૂચિને એકસાથે મૂકવામાં વ્યવસ્થાપિત થયા.

કુબરનેટ્સનો ઉપયોગ કરવાના વર્ષોમાં, અમે મોટી સંખ્યામાં ક્લસ્ટરો સાથે કામ કર્યું છે (વ્યવસ્થાપિત અને વ્યવસ્થાપિત બંને - GCP, AWS અને Azure પર). સમય જતાં, અમે નોંધવાનું શરૂ કર્યું કે કેટલીક ભૂલો સતત પુનરાવર્તિત થાય છે. જો કે, આમાં કોઈ શરમ નથી: અમે તેમાંના મોટા ભાગના જાતે કર્યા છે!

લેખમાં સૌથી સામાન્ય ભૂલો છે અને તેને કેવી રીતે સુધારવી તેનો પણ ઉલ્લેખ છે.

1. સંસાધનો: વિનંતીઓ અને મર્યાદાઓ

આ આઇટમ ચોક્કસપણે નજીકના ધ્યાન અને સૂચિમાં પ્રથમ સ્થાનને પાત્ર છે.

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

ઉત્તમ પ્રયત્ન (અત્યંત નથી ભલામણ કરેલ):

resources: {}

અત્યંત ઓછી CPU વિનંતી (અત્યંત નથી ભલામણ કરેલ):

   resources:
      Requests:
        cpu: "1m"

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

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

શું તમે આ બનવાની સંભાવનાને ઘટાડવા માંગો છો? મેમરીની વધુ ફાળવણી કરશો નહીં અને મેમરી વિનંતીને મર્યાદા પર સેટ કરીને ગેરંટીડ QoS (સેવાની ગુણવત્તા) નો ઉપયોગ કરશો નહીં (નીચેના ઉદાહરણ તરીકે). આ વિશે વધુ વાંચો હેનિંગ જેકોબ્સ પ્રસ્તુતિઓ (મુખ્ય ઈજનેર ઝાલેન્ડો).

છલકાતું (OOM માર્યા જવાની ઉચ્ચ તક):

   resources:
      requests:
        memory: "128Mi"
        cpu: "500m"
      limits:
        memory: "256Mi"
        cpu: 2

ખાતરી આપી:

   resources:
      requests:
        memory: "128Mi"
        cpu: 2
      limits:
        memory: "128Mi"
        cpu: 2

સંસાધનો સેટ કરતી વખતે સંભવિત રૂપે શું મદદ કરશે?

ની મદદ સાથે મેટ્રિક્સ-સર્વર તમે પોડ્સ (અને તેમની અંદરના કન્ટેનર) દ્વારા વર્તમાન CPU સંસાધન વપરાશ અને મેમરી વપરાશ જોઈ શકો છો. મોટે ભાગે, તમે પહેલેથી જ તેનો ઉપયોગ કરી રહ્યાં છો. ફક્ત નીચેના આદેશો ચલાવો:

kubectl top pods
kubectl top pods --containers
kubectl top nodes

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

વર્ટિકલ પોડ ઓટોસ્કેલર તે માટે પરવાનગી આપે છે સ્વચાલિત આ પ્રક્રિયા. તે CPU અને મેમરી વપરાશ ઇતિહાસને ટ્રેક કરે છે અને આ માહિતીના આધારે નવી વિનંતીઓ અને મર્યાદાઓ સેટ કરે છે.

કમ્પ્યુટિંગ પાવરનો અસરકારક રીતે ઉપયોગ કરવો એ સરળ કાર્ય નથી. તે બધા સમય ટેટ્રિસ રમવા જેવું છે. જો તમે નીચા સરેરાશ વપરાશ (~10% કહો) સાથે કમ્પ્યુટ પાવર માટે ખૂબ જ ચૂકવણી કરી રહ્યાં છો, તો અમે AWS Fargate અથવા Virtual Kubelet પર આધારિત ઉત્પાદનો જોવાની ભલામણ કરીએ છીએ. તેઓ સર્વરલેસ/પે-પ્રતિ-ઉપયોગ બિલિંગ મોડલ પર બનેલ છે, જે આવી પરિસ્થિતિઓમાં સસ્તું હોઈ શકે છે.

2. જીવંતતા અને તત્પરતા ચકાસણીઓ

મૂળભૂત રીતે, કુબરનેટ્સમાં જીવંતતા અને તત્પરતા તપાસો સક્ષમ નથી. અને કેટલીકવાર તેઓ તેમને ચાલુ કરવાનું ભૂલી જાય છે ...

પરંતુ જીવલેણ ભૂલના કિસ્સામાં તમે સેવા પુનઃપ્રારંભ કેવી રીતે કરી શકો? અને લોડ બેલેન્સરને કેવી રીતે ખબર પડે છે કે પોડ ટ્રાફિક સ્વીકારવા માટે તૈયાર છે? અથવા તે વધુ ટ્રાફિકને નિયંત્રિત કરી શકે છે?

આ પરીક્ષણો ઘણીવાર એકબીજા સાથે મૂંઝવણમાં હોય છે:

• જીવંતતા — “સર્વાઇવબિલિટી” ચેક, જે નિષ્ફળ જાય તો પોડને ફરીથી શરૂ કરે છે;
• તત્પરતા - તૈયારીની તપાસ, જો તે નિષ્ફળ જાય, તો તે કુબરનેટ્સ સેવામાંથી પોડને ડિસ્કનેક્ટ કરે છે (આનો ઉપયોગ કરીને તપાસ કરી શકાય છે. kubectl get endpoints) અને જ્યાં સુધી આગલી તપાસ સફળતાપૂર્વક પૂર્ણ ન થાય ત્યાં સુધી ટ્રાફિક તેના પર પહોંચતો નથી.

આ બંને ચેક પોડના સમગ્ર જીવન ચક્ર દરમિયાન કરવામાં આવે છે. તે ખૂબ જ મહત્વપૂર્ણ છે.

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

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

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

જ્યારે સામાન્ય અવલંબન નિષ્ફળ જાય ત્યારે બંને પ્રકારની તપાસો નિષ્ફળ ન થવી જોઈએ, અન્યથા આ તમામ શીંગોની કાસ્કેડિંગ (હિમપ્રપાત જેવી) નિષ્ફળતા તરફ દોરી જશે. બીજા શબ્દો માં, તમારી જાતને નુકસાન ન કરો.

3. દરેક HTTP સેવા માટે લોડબેલેન્સર

મોટે ભાગે, તમારી પાસે તમારા ક્લસ્ટરમાં HTTP સેવાઓ છે જેને તમે બહારની દુનિયામાં ફોરવર્ડ કરવા માંગો છો.

જો તમે સેવા તરીકે ખોલો છો type: LoadBalancer, તેના નિયંત્રક (સેવા પ્રદાતા પર આધાર રાખીને) બાહ્ય લોડબેલેન્સર પ્રદાન કરશે અને વાટાઘાટ કરશે (જરૂરી નથી કે L7 પર ચાલતું હોય, પરંતુ L4 પર પણ), અને આ કિંમતને અસર કરી શકે છે (બાહ્ય સ્થિર IPv4 સરનામું, કમ્પ્યુટિંગ પાવર, પ્રતિ-સેકન્ડ બિલિંગ. ) મોટી સંખ્યામાં આવા સંસાધનો બનાવવાની જરૂરિયાતને કારણે.

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

અન્ય ઇન્ટ્રા-ક્લસ્ટર (માઇક્રો) સેવાઓ કે જે એકબીજા સાથે ક્રિયાપ્રતિક્રિયા કરે છે તે સેવાઓનો ઉપયોગ કરીને "સંચાર" કરી શકે છે. ક્લસ્ટરઆઈપી અને DNS મારફતે બિલ્ટ-ઇન સર્વિસ ડિસ્કવરી મિકેનિઝમ. ફક્ત તેમના સાર્વજનિક DNS/IP નો ઉપયોગ કરશો નહીં, કારણ કે આ લેટન્સીને અસર કરી શકે છે અને ક્લાઉડ સેવાઓની કિંમતમાં વધારો કરી શકે છે.

4. ક્લસ્ટરની વિશેષતાઓને ધ્યાનમાં લીધા વિના ઓટોસ્કેલિંગ

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

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

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

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

5. IAM/RBAC ક્ષમતાઓની અવગણના

માટે સતત રહસ્યો સાથે IAM વપરાશકર્તાઓનો ઉપયોગ કરવાથી સાવચેત રહો મશીનો અને એપ્લિકેશન. ભૂમિકાઓ અને સેવા ખાતાઓનો ઉપયોગ કરીને અસ્થાયી ઍક્સેસ ગોઠવો (સેવા ખાતાઓ).

અમે ઘણીવાર એ હકીકતનો સામનો કરીએ છીએ કે એપ્લિકેશન રૂપરેખાંકનમાં ઍક્સેસ કી (અને રહસ્યો) હાર્ડકોડ કરેલી છે, તેમજ ક્લાઉડ IAM ની ઍક્સેસ હોવા છતાં રહસ્યોના પરિભ્રમણને અવગણવામાં આવે છે. જ્યાં યોગ્ય હોય ત્યાં વપરાશકર્તાઓને બદલે IAM ભૂમિકાઓ અને સેવા ખાતાઓનો ઉપયોગ કરો.

kube2iam વિશે ભૂલી જાઓ અને સર્વિસ એકાઉન્ટ્સ માટે સીધા IAM ભૂમિકાઓ પર જાઓ (જેમાં વર્ણવેલ છે સમાન નામની નોંધ સ્ટેપન વ્રાની):

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/my-app-role
  name: my-serviceaccount
  namespace: default

એક ટીકા. એટલું મુશ્કેલ નથી, ખરું ને?

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

6. શીંગો માટે સ્વચાલિત એન્ટિ-એફિનિટી પર આધાર રાખશો નહીં

કલ્પના કરો કે તમારી પાસે નોડ પર કેટલાક જમાવટની ત્રણ પ્રતિકૃતિઓ છે. નોડ પડે છે, અને તેની સાથે બધી પ્રતિકૃતિઓ. અપ્રિય પરિસ્થિતિ, અધિકાર? પરંતુ શા માટે બધી પ્રતિકૃતિઓ એક જ નોડ પર હતી? શું કુબરનેટ્સ ઉચ્ચ ઉપલબ્ધતા (HA) પ્રદાન કરવા માટે નથી?!

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

// опущено для краткости
      labels:
        app: zk
// опущено для краткости
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: "app"
                    operator: In
                    values:
                    - zk
              topologyKey: "kubernetes.io/hostname"

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

અહીં અમે વાત કરી રહ્યા છીએ podAntiAffinity વિવિધ ગાંઠો પર: topologyKey: "kubernetes.io/hostname", - અને વિવિધ ઉપલબ્ધતા ઝોન વિશે નહીં. સંપૂર્ણ સુવિધાયુક્ત HA ને અમલમાં મૂકવા માટે, તમારે આ વિષયમાં વધુ ઊંડો અભ્યાસ કરવો પડશે.

7. PodDisruption Budgets ને અવગણવું

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

PDB તમને નોડ્સના અભાવને કારણે સેવામાં આવતા વિક્ષેપોને ટાળવા માટે પરવાનગી આપે છે:

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: zookeeper

આ ઉદાહરણમાં, તમે, ક્લસ્ટરના વપરાશકર્તા તરીકે, એડમિન્સને જણાવો છો: "અરે, મારી પાસે ઝૂકીપર સેવા છે, અને તમે ગમે તે કરો છો, હું આ સેવાની ઓછામાં ઓછી 2 પ્રતિકૃતિઓ હંમેશા ઉપલબ્ધ રાખવા માંગુ છું."

તમે આ વિશે વધુ વાંચી શકો છો અહીં.

8. એક સામાન્ય ક્લસ્ટરમાં બહુવિધ વપરાશકર્તાઓ અથવા વાતાવરણ

કુબરનેટ નામની જગ્યાઓ (નેમસ્પેસ) મજબૂત ઇન્સ્યુલેશન પ્રદાન કરશો નહીં.

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

જેમને એક જ ક્લસ્ટરમાં બંને પ્રકારના વર્કલોડને જોડવાની જરૂર છે તેઓએ જટિલતાનો સામનો કરવો પડશે. જો આવી કોઈ જરૂરિયાત ન હોય, અને તમે તેને ધરાવી શકો છો વધુ એક ક્લસ્ટર (કહો, સાર્વજનિક વાદળમાં), તો તે કરવું વધુ સારું છે. આ ઇન્સ્યુલેશનનું ઘણું ઊંચું સ્તર પ્રાપ્ત કરશે.

9. બાહ્ય ટ્રાફિક નીતિ: ક્લસ્ટર

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

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

બીજી બાજુ, જો ચોક્કસ કુબરનેટ્સ સેવામાં નીતિ સેટ હોય externalTrafficPolicy: Local, પછી નોડપોર્ટ ફક્ત તે નોડ્સ પર જ ખુલે છે જ્યાં જરૂરી પોડ્સ ખરેખર ચાલી રહ્યા છે. બાહ્ય લોડ બેલેન્સરનો ઉપયોગ કરતી વખતે જે રાજ્યને તપાસે છે (સ્વાસ્થ્ય તપાસ) અંતિમ બિંદુઓ (તે કેવી રીતે કરે છે AWS ELB), તેમણે માત્ર જરૂરી નોડ્સ પર જ ટ્રાફિક મોકલશે, જે વિલંબ, કમ્પ્યુટિંગ જરૂરિયાતો, બહાર નીકળવાના બિલો પર ફાયદાકારક અસર કરશે (અને સામાન્ય જ્ઞાન તે જ સૂચવે છે).

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

В આ પ્રકાશન તમે externalTrafficPolicy, તેના ફાયદા અને ગેરફાયદા વિશે વધુ જાણી શકો છો.

10. ક્લસ્ટરો સાથે જોડાયેલા ન થાઓ અને નિયંત્રણ પ્લેનનો દુરુપયોગ કરશો નહીં

પહેલાં, સર્વરને યોગ્ય નામોથી કૉલ કરવાનો રિવાજ હતો: એન્ટોન, HAL9000 અને Colossus... આજે તેઓ રેન્ડમલી જનરેટ થયેલ ઓળખકર્તાઓ દ્વારા બદલવામાં આવ્યા છે. જો કે, આદત રહી, અને હવે યોગ્ય નામો ક્લસ્ટરોમાં જાય છે.

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

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

બીજી બાજુ, તમારે તેને ચાલાકીથી દૂર ન થવું જોઈએ. સમય સાથે નિયંત્રણ સ્તર ધીમું થઈ શકે છે. મોટે ભાગે, આ મોટી સંખ્યામાં ઑબ્જેક્ટ્સને ફેરવ્યા વિના બનાવવામાં આવી હોવાને કારણે છે (ડિફૉલ્ટ સેટિંગ્સ સાથે હેલ્મનો ઉપયોગ કરતી વખતે એક સામાન્ય પરિસ્થિતિ, જેના કારણે configmaps/સિક્રેટ્સમાં તેની સ્થિતિ અપડેટ થતી નથી - પરિણામે, હજારો ઑબ્જેક્ટ્સ એકઠા થાય છે. કંટ્રોલ લેયર) અથવા kube-api ઑબ્જેક્ટ્સના સતત સંપાદન સાથે (ઓટોમેટિક સ્કેલિંગ માટે, CI/CD માટે, મોનિટરિંગ માટે, ઇવેન્ટ લૉગ્સ, કંટ્રોલર્સ વગેરે).

વધુમાં, અમે સંચાલિત કુબરનેટ્સ પ્રદાતા સાથેના SLA/SLO કરારો તપાસવાની અને ગેરંટીઓ પર ધ્યાન આપવાની ભલામણ કરીએ છીએ. વિક્રેતા ખાતરી આપી શકે છે નિયંત્રણ સ્તર ઉપલબ્ધતા (અથવા તેના પેટા ઘટકો), પરંતુ તમે તેને મોકલેલી વિનંતીઓના p99 વિલંબથી નહીં. બીજા શબ્દોમાં કહીએ તો, તમે દાખલ કરી શકો છો kubectl get nodes, અને 10 મિનિટ પછી જ જવાબ મેળવો, અને આ સેવા કરારની શરતોનું ઉલ્લંઘન હશે નહીં.

11. બોનસ: નવીનતમ ટેગનો ઉપયોગ કરીને

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

ઇસીઆર ઇમેજ ટૅગ્સની અપરિવર્તનક્ષમતા જાળવી રાખે છે; અમે ભલામણ કરીએ છીએ કે તમે તમારી જાતને આ નોંધપાત્ર સુવિધાથી પરિચિત કરો.

સારાંશ

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

માં વિવિધ ટીમોના અસફળ અનુભવોથી તમે પરિચિત થઈ શકો છો વાર્તાઓનો આ સંગ્રહ હેનિંગ જેકોબ્સ દ્વારા.

આ લેખમાં આપવામાં આવેલી ભૂલોની યાદીમાં ઉમેરવા ઈચ્છતા લોકો અમારો Twitter પર સંપર્ક કરી શકે છે (@મેરેકબાર્ટિક, @MstrsObserver).

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

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

• «કુબરનેટ્સ ક્લસ્ટર્સની રચના: કેટલા હોવા જોઈએ?»;
• «કુબરનેટ્સમાં સુરક્ષાનું એબીસી: પ્રમાણીકરણ, અધિકૃતતા, ઓડિટીંગ»;
• «કુબરનેટ્સમાં ઓટોસ્કેલિંગ અને રિસોર્સ મેનેજમેન્ટ"(સમીક્ષા અને વિડિયો રિપોર્ટ);
• «કુબરનેટ્સમાં રૂપરેખા નકશા: જાણવા યોગ્ય ઘોંઘાટ».

સોર્સ: www.habr.com