Kubernetes પર પ્રથમ એપ્લિકેશન જમાવતી વખતે પાંચ ચૂકી જાય છે

એરિસ-ડ્રીમર દ્વારા નિષ્ફળ

ઘણા લોકો માને છે કે એપ્લિકેશનને કુબરનેટ્સ પર સ્થાનાંતરિત કરવા માટે તે પૂરતું છે (ક્યાં તો હેલ્મનો ઉપયોગ કરીને અથવા મેન્યુઅલી) અને તેઓ ખુશ થશે. પરંતુ તે એટલું સરળ નથી.

ટીમ Mail.ru ક્લાઉડ સોલ્યુશન્સ DevOps એન્જિનિયર જુલિયન ગિન્ડીના લેખનો અનુવાદ કર્યો. સ્થળાંતર પ્રક્રિયા દરમિયાન તેની કંપનીને જે મુશ્કેલીઓ આવી તે તે શેર કરે છે જેથી કરીને તમે સમાન રેક પર પગ ન મૂકો.

પગલું એક: પોડ વિનંતીઓ અને મર્યાદાઓ સેટ કરવી

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

પોડ વિનંતીઓ - આ મુખ્ય મૂલ્ય છે જેનો ઉપયોગ શેડ્યૂલર દ્વારા પોડને શ્રેષ્ઠ રીતે કરવા માટે કરવામાં આવે છે.

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

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

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

પોડ મર્યાદા - આ પોડ માટે સ્પષ્ટ મર્યાદા છે. તે સંસાધનોની મહત્તમ રકમનું પ્રતિનિધિત્વ કરે છે જે ક્લસ્ટર કન્ટેનરને ફાળવશે.

ફરીથી, થી સત્તાવાર દસ્તાવેજીકરણ: જો કન્ટેનરમાં 4 GiB મેમરી મર્યાદા સેટ હોય, તો કુબેલેટ (અને કન્ટેનર રનટાઇમ) તેને લાગુ કરશે. રનટાઇમ કન્ટેનરને ઉલ્લેખિત સંસાધન મર્યાદા કરતાં વધુ ઉપયોગ કરવાની મંજૂરી આપતું નથી. ઉદાહરણ તરીકે, જ્યારે કન્ટેનરમાં પ્રક્રિયા મંજૂર મેમરીની માત્રા કરતાં વધુ ઉપયોગ કરવાનો પ્રયાસ કરે છે, ત્યારે સિસ્ટમ કર્નલ "મેમરી બહાર" (OOM) ભૂલ સાથે પ્રક્રિયાને સમાપ્ત કરે છે.

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

આદર્શરીતે, અમે ઇચ્છીએ છીએ કે પોડની સંસાધન આવશ્યકતાઓ સિસ્ટમમાં અન્ય પ્રક્રિયાઓમાં દખલ કર્યા વિના પ્રક્રિયાના જીવનચક્રમાં બદલાય - તે મર્યાદા નક્કી કરવાનો ધ્યેય છે.

કમનસીબે, હું કયા મૂલ્યો સેટ કરવા તે અંગે ચોક્કસ સૂચનાઓ આપી શકતો નથી, પરંતુ આપણે પોતે નીચેના નિયમોનું પાલન કરીએ છીએ:

1. લોડ ટેસ્ટિંગ ટૂલનો ઉપયોગ કરીને, અમે ટ્રાફિકના બેઝલાઇન લેવલનું અનુકરણ કરીએ છીએ અને પોડ રિસોર્સિસ (મેમરી અને પ્રોસેસર)ના ઉપયોગનું નિરીક્ષણ કરીએ છીએ.
2. અમે પોડ વિનંતીઓને મનસ્વી રીતે નીચા મૂલ્ય પર સેટ કરીએ છીએ (વિનંતીઓના મૂલ્ય કરતાં લગભગ 5 ગણી સંસાધન મર્યાદા સાથે) અને અવલોકન કરીએ છીએ. જ્યારે વિનંતીઓ ખૂબ ઓછી હોય છે, ત્યારે પ્રક્રિયા શરૂ થઈ શકતી નથી, ઘણીવાર રહસ્યમય ગો રનટાઈમ ભૂલોનું કારણ બને છે.

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

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

પગલું બે: જીવંતતા અને તત્પરતા પરીક્ષણો ગોઠવો

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

જીવંતતા કન્ટેનર ચાલી રહ્યું છે કે કેમ તે બતાવે છે. જો તે નિષ્ફળ જાય, તો કુબેલેટ કન્ટેનરને મારી નાખે છે અને તેના માટે પુનઃપ્રારંભ નીતિ સક્ષમ છે. જો કન્ટેનર લાઇવનેસ પ્રોબથી સજ્જ નથી, તો ડિફોલ્ટ સ્થિતિ સફળ થશે - આ તે છે જે તે કહે છે કુબરનેટ્સ દસ્તાવેજીકરણ.

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

જો તમે દર સેકન્ડે ચલાવવાનો વિકલ્પ સેટ કરો છો, તો આ પ્રતિ સેકન્ડમાં 1 વિનંતી ઉમેરશે, તેથી ધ્યાન રાખો કે આ ટ્રાફિકને હેન્ડલ કરવા માટે વધારાના સંસાધનોની જરૂર પડશે.

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

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

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

રેડીનેસ પ્રોબ્સ વધુ સંસાધનોનો ઉપયોગ કરે છે કારણ કે તેઓ બેકએન્ડ પર એવી રીતે મોકલવા જોઈએ કે જે સૂચવે છે કે એપ્લિકેશન વિનંતીઓ સ્વીકારવા માટે તૈયાર છે.

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

જો તમે તમારી અરજીની તૈયારીને ચકાસવા માટે ડેટાબેઝની ક્વેરી કરવાનું નક્કી કરો છો, તો ખાતરી કરો કે તે શક્ય તેટલું સસ્તું છે. ચાલો આ વિનંતી લઈએ:

SELECT small_item FROM table LIMIT 1

કુબરનેટ્સમાં આપણે આ બે મૂલ્યોને કેવી રીતે ગોઠવીએ છીએ તેનું ઉદાહરણ અહીં છે:

livenessProbe: 
 httpGet:   
   path: /api/liveness    
   port: http 
readinessProbe:  
 httpGet:    
   path: /api/readiness    
   port: http  periodSeconds: 2

તમે કેટલાક વધારાના રૂપરેખાંકન વિકલ્પો ઉમેરી શકો છો:

• initialDelaySeconds - કન્ટેનરની શરૂઆત અને નમૂનાઓની શરૂઆત વચ્ચે કેટલી સેકન્ડ પસાર થશે.
• periodSeconds - નમૂના રન વચ્ચે રાહ અંતરાલ.
• timeoutSeconds - સેકન્ડની સંખ્યા કે જેના પછી એકમને કટોકટી ગણવામાં આવે છે. નિયમિત સમયસમાપ્તિ.
• failureThreshold - પુનઃપ્રારંભ સિગ્નલ પોડ પર મોકલવામાં આવે તે પહેલાં પરીક્ષણ નિષ્ફળતાઓની સંખ્યા.
• successThreshold — પોડ તૈયાર સ્થિતિમાં જાય તે પહેલાં સફળ ચકાસણીઓની સંખ્યા (નિષ્ફળતા પછી, જ્યારે પોડ શરૂ થાય અથવા પુનઃપ્રાપ્ત થાય).

પગલું ત્રણ: પોડ માટે ડિફોલ્ટ નેટવર્ક નીતિઓ સેટ કરવી

કુબરનેટ્સ પાસે "ફ્લેટ" નેટવર્ક ટોપોગ્રાફી છે; ડિફૉલ્ટ રૂપે, બધા પોડ્સ એકબીજા સાથે સીધો સંચાર કરે છે. કેટલાક કિસ્સાઓમાં આ ઇચ્છનીય નથી.

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

ઉદાહરણ તરીકે, નીચે એક સરળ નીતિ છે જે ચોક્કસ નેમસ્પેસ માટે આવતા તમામ ટ્રાફિકને નકારે છે:

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:  
 name: default-deny-ingress
spec:  
 podSelector: {}  
 policyTypes:  
   - Ingress

આ રૂપરેખાંકનનું વિઝ્યુલાઇઝેશન:

(https://miro.medium.com/max/875/1*-eiVw43azgzYzyN1th7cZg.gif)
વિગતોમાં અહીં.

પગલું ચાર: હુક્સ અને ઇનિટ કન્ટેનરનો ઉપયોગ કરીને કસ્ટમ વર્તન

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

સાથે ખાસ મુશ્કેલીઓ ઊભી થઈ Nginx. અમે નોંધ્યું છે કે જ્યારે આ પોડ્સ ક્રમિક રીતે જમાવવામાં આવ્યા હતા, ત્યારે સક્રિય કનેક્શન્સ સફળતાપૂર્વક પૂર્ણ થાય તે પહેલાં છોડી દેવામાં આવ્યા હતા.

ઑનલાઇન વ્યાપક સંશોધન પછી, તે તારણ આપે છે કે કુબરનેટ્સ પોડને સમાપ્ત કરતા પહેલા Nginx કનેક્શન્સ સમાપ્ત થવાની રાહ જોતા નથી. પ્રી-સ્ટોપ હૂકનો ઉપયોગ કરીને, અમે નીચેની કાર્યક્ષમતા લાગુ કરી અને ડાઉનટાઇમથી સંપૂર્ણપણે છુટકારો મેળવ્યો:

lifecycle: 
 preStop:
   exec:
     command: ["/usr/local/bin/nginx-killer.sh"]

પરંતુ nginx-killer.sh:

#!/bin/bash
sleep 3
PID=$(cat /run/nginx.pid)
nginx -s quit
while [ -d /proc/$PID ]; do
   echo "Waiting while shutting down nginx..."
   sleep 10
done

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

અન્ય સામાન્ય યોજના એ છે કે ઇનિટ કન્ટેનરમાં રહસ્યોને ઍક્સેસ કરવી જે મુખ્ય મોડ્યુલને તે ઓળખપત્રો પ્રદાન કરે છે, જે મુખ્ય એપ્લિકેશન મોડ્યુલમાંથી જ રહસ્યોની અનધિકૃત ઍક્સેસને અટકાવે છે.

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

પગલું પાંચ: કર્નલ રૂપરેખાંકિત કરી રહ્યા છીએ

છેલ્લે, ચાલો વધુ અદ્યતન તકનીક વિશે વાત કરીએ.

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

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

initContainers:
  - name: sysctl
     image: alpine:3.10
     securityContext:
         privileged: true
      command: ['sh', '-c', "sysctl -w net.core.somaxconn=32768"]

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

અંતમા

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

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

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

હંમેશા તમારી જાતને આ પ્રશ્નો પૂછો:

1. એપ્લિકેશન્સ કેટલા સંસાધનોનો ઉપયોગ કરે છે અને આ વોલ્યુમ કેવી રીતે બદલાશે?
2. વાસ્તવિક સ્કેલિંગ જરૂરિયાતો શું છે? એપ્લિકેશન સરેરાશ કેટલો ટ્રાફિક હેન્ડલ કરશે? પીક ટ્રાફિક વિશે શું?
3. સેવાને કેટલી વાર આડા સ્કેલ કરવાની જરૂર પડશે? ટ્રાફિક મેળવવા માટે નવા પોડ્સને કેટલી ઝડપથી ઓનલાઈન લાવવાની જરૂર છે?
4. શીંગો કેવી રીતે યોગ્ય રીતે બંધ થાય છે? શું આ બિલકુલ જરૂરી છે? શું ડાઉનટાઇમ વિના જમાવટ પ્રાપ્ત કરવી શક્ય છે?
5. તમે સુરક્ષા જોખમોને કેવી રીતે ઘટાડી શકો છો અને કોઈપણ ચેડા કરાયેલા પોડ્સથી થતા નુકસાનને કેવી રીતે મર્યાદિત કરી શકો છો? શું કોઈપણ સેવાઓ પાસે પરવાનગીઓ અથવા ઍક્સેસ છે જેની તેમને જરૂર નથી?

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

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

બીજું શું વાંચવું:

1. ઉત્પાદન વાતાવરણમાં કન્ટેનર અને કુબરનેટ્સ ચલાવવા માટેની શ્રેષ્ઠ પદ્ધતિઓ અને શ્રેષ્ઠ પ્રયાસો.
2. કુબરનેટ્સ માટે 90+ ઉપયોગી સાધનો: જમાવટ, સંચાલન, દેખરેખ, સુરક્ષા અને વધુ.
3. ટેલિગ્રામમાં કુબરનેટ્સની આસપાસ અમારી ચેનલ.

સોર્સ: www.habr.com