કુબરનેટ્સની યોગ્ય સરખામણી લાગુ કરો, બદલો અને પેચ કરો

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

જો Google પર શોધો વાક્ય "kubernetes લાગુ vs બદલો" સ્થિત છે સ્ટેકઓવરફ્લોને જવાબ આપો, જે યોગ્ય નથી. જ્યારે શોધ "kubernetes લાગુ વિ પેચ" માટે પ્રથમ લિંક દસ્તાવેજીકરણ છે kubectl patch, જેમાં સરખામણીનો સમાવેશ થતો નથી apply и patch. આ લેખ વિવિધ વિકલ્પો, તેમજ દરેક એકના યોગ્ય ઉપયોગને જોશે.

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

કુબરનેટ્સ CLI

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

દરેકને આદેશો ખબર નથી patch и replace. ટીમ patch તમને સંસાધન સ્પષ્ટીકરણનો ભાગ બદલવાની પરવાનગી આપે છે, ફક્ત આદેશ વાક્ય પર બદલાયેલ ભાગ પ્રદાન કરે છે. ટીમ replace જેવું જ કામ કરે છે edit, પરંતુ બધું મેન્યુઅલી કરવાની જરૂર છે: તમારે સંસાધન સ્પષ્ટીકરણનું વર્તમાન સંસ્કરણ ડાઉનલોડ કરવાની જરૂર છે, ઉદાહરણ તરીકે, ઉપયોગ કરીને kubectl get -o yaml, તેને સંપાદિત કરો, પછી ઉપયોગ કરો replace બદલાયેલ સ્પષ્ટીકરણ અનુસાર સંસાધનને અપડેટ કરવા. ટીમ replace જો સંસાધન વાંચવા અને બદલવાની વચ્ચે કોઈ ફેરફાર થયો હોય તો તે કામ કરશે નહીં.

કુબરનેટ્સ API

તમે કદાચ પદ્ધતિઓથી પરિચિત છો CoreV1().Pods().Update(), replaceNamespacedService અથવા patch_namespaced_deployment, જો તમે ક્લસ્ટરો સાથે મારફતે કામ કરો છો Kubernetes API માટે ક્લાયંટ લાઇબ્રેરી અમુક પ્રોગ્રામિંગ ભાષાનો ઉપયોગ કરીને. લાઇબ્રેરી પદ્ધતિઓનો ઉપયોગ કરીને HTTP વિનંતીઓ દ્વારા આ પદ્ધતિઓનું સંચાલન કરે છે PUT и PATCH... જેમાં update и replace ઉપયોગ કરો PUTઅને patch, ભલે તે ગમે તેટલું તુચ્છ હોય, ઉપયોગ કરે છે PATCH.

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

મૂળભૂત રીતે પેચ

શ્રેષ્ઠ ઉપયોગ patch, જો તમે સંસાધનને અપડેટ કરવા માંગો છો. આ રીતે બંને ક્લાયંટ લાઇબ્રેરીઓ Kubernetes API અને ટોચ પર કાર્ય કરે છે kubectl (આશ્ચર્યજનક નથી, કારણ કે તે ક્લાયંટ લાઇબ્રેરી માટે રેપર છે, આશરે અનુવાદક).

વ્યૂહાત્મક રીતે કામ કરો

તમામ ટીમો kubectl apply, edit и patch પદ્ધતિનો ઉપયોગ કરો PATCH હાલના સંસાધનને અપડેટ કરવા માટે HTTP વિનંતીઓમાં. જો તમે આદેશોના અમલીકરણમાં વધુ વિગતવાર તપાસ કરો છો, તો તે બધા અભિગમનો ઉપયોગ કરે છે વ્યૂહાત્મક-મર્જ પેચિંગ સંસાધનોને અપડેટ કરવા માટે, આદેશ હોવા છતાં patch અન્ય અભિગમોનો ઉપયોગ કરી શકે છે (નીચે આના પર વધુ). વ્યૂહાત્મક-મર્જ પેચિંગ અભિગમ હાલના સ્પષ્ટીકરણ સાથે પૂરા પાડવામાં આવેલ સ્પષ્ટીકરણને મર્જ કરીને "તેને યોગ્ય રીતે મેળવવા" પ્રયાસ કરે છે. વધુ વિશિષ્ટ રીતે, તે ઑબ્જેક્ટ અને એરે બંનેને જોડવાનો પ્રયાસ કરે છે, જેનો અર્થ છે કે ફેરફારો ઉમેરણ હોય છે. ઉદાહરણ તરીકે, આદેશ ચલાવો patch પોડ કન્ટેનર સ્પેસિફિકેશનમાં નવા એન્વાયર્નમેન્ટ વેરીએબલ સાથે, તે એન્વાયર્નમેન્ટ વેરીએબલને હાલના એન્વાયર્નમેન્ટ વેરીએબલ્સમાં ઓવરરાઈટ કરવાને બદલે ઉમેરવાનું કારણ બને છે. આ અભિગમનો ઉપયોગ કરીને દૂર કરવા માટે, તમારે પ્રદાન કરેલ સ્પષ્ટીકરણમાં પરિમાણ મૂલ્યને નલ કરવા દબાણ કરવું આવશ્યક છે. કઈ ટીમો kubectl શું અપડેટ કરવા માટે ઉપયોગ કરવો શ્રેષ્ઠ છે?

જો તમે ઉપયોગ કરીને તમારા સંસાધનો બનાવો અને મેનેજ કરો kubectl apply, અપડેટ કરતી વખતે તેનો હંમેશા ઉપયોગ કરવો વધુ સારું છે kubectl applyમાટે kubectl રૂપરેખાંકનનું સંચાલન કરી શકે છે અને એપ્લિકેશનથી એપ્લિકેશનમાં વિનંતી કરેલ ફેરફારોને યોગ્ય રીતે ટ્રૅક કરી શકે છે. ફાયદો હંમેશા ઉપયોગ કરો apply તે એ છે કે તે અગાઉ લાગુ કરેલ સ્પષ્ટીકરણનો ટ્રૅક રાખે છે, જ્યારે સ્પષ્ટીકરણ ગુણધર્મો અને એરે ઘટકોને સ્પષ્ટ રીતે દૂર કરવામાં આવે છે ત્યારે તે જાણવાની મંજૂરી આપે છે. આ તમને ઉપયોગ કરવાની મંજૂરી આપે છે apply ગુણધર્મો અને એરે તત્વોને દૂર કરવા માટે, જ્યારે સામાન્ય વ્યૂહાત્મક મર્જ કામ કરશે નહીં. ટીમો edit и patch તે નોંધો અપડેટ કરશો નહીં kubectl apply તેના ફેરફારોને ટ્રૅક કરવા માટે ઉપયોગ કરે છે, તેથી કોઈપણ ફેરફારો કે જે ટ્રૅક કરવામાં આવે છે અને કુબરનેટ્સ API દ્વારા કરવામાં આવે છે, પરંતુ આદેશો દ્વારા કરવામાં આવે છે. edit и patch, અનુગામી આદેશો માટે અદ્રશ્ય applyતે છે apply જો તેઓ ઇનપુટ સ્પષ્ટીકરણમાં દેખાતા ન હોય તો પણ તેમને દૂર કરતું નથી apply (દસ્તાવેજ કહે છે કે edit и patch ઉપયોગમાં લેવાતી નોંધોને અપડેટ કરો apply, પરંતુ વ્યવહારમાં - ના).

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

ક્લાયંટ લાઇબ્રેરીમાં અપડેટ પદ્ધતિઓનો અમલ કરવા માટે કે જે ઉપરના આદેશોની જેમ જ વર્તે છે kubectl, વિનંતીઓમાં સેટ કરવી જોઈએ content-type в application/strategic-merge-patch+json. જો તમે સ્પેસિફિકેશનમાં પ્રોપર્ટીઝને દૂર કરવા માંગો છો, તો તમારે સ્પષ્ટપણે તેમના મૂલ્યોને સમાન રીતે નલ પર સેટ કરવાની જરૂર છે. kubectl patch. જો તમારે એરે તત્વોને દૂર કરવાની જરૂર હોય, તો તમારે અપડેટ સ્પષ્ટીકરણમાં મર્જ નિર્દેશોનો સમાવેશ કરવો જોઈએ અથવા અપડેટ્સ માટે અલગ અભિગમનો ઉપયોગ કરવો જોઈએ.

અપડેટ્સ માટે અન્ય અભિગમો

કુબરનેટ્સ બે અન્ય અપડેટ અભિગમોને સમર્થન આપે છે: JSON મર્જ પેચ и JSON પેચ. JSON મર્જ પેચ અભિગમ ઇનપુટ તરીકે આંશિક કુબરનેટ્સ સ્પષ્ટીકરણ લે છે અને વ્યૂહાત્મક-મર્જ પેચિંગ અભિગમ જેવા મર્જિંગ ઑબ્જેક્ટ્સને સપોર્ટ કરે છે. બંને વચ્ચેનો તફાવત એ છે કે તે પોડ સ્પષ્ટીકરણમાં કન્ટેનર એરે સહિત માત્ર એરે રિપ્લેસમેન્ટને સપોર્ટ કરે છે. આનો અર્થ એ છે કે JSON મર્જ પેચનો ઉપયોગ કરતી વખતે, તમારે કોઈપણ કન્ટેનરની કોઈપણ મિલકતમાં ફેરફાર થવાના કિસ્સામાં તમામ કન્ટેનર માટે સંપૂર્ણ સ્પષ્ટીકરણો પ્રદાન કરવાની જરૂર છે. તેથી આ અભિગમ BOM માં એરેમાંથી તત્વોને દૂર કરવા માટે ઉપયોગી છે. આદેશ વાક્ય પર તમે JSON મર્જ પેચનો ઉપયોગ કરીને પસંદ કરી શકો છો kubectl patch --type=merge. Kubernetes API સાથે કામ કરતી વખતે, તમારે વિનંતી પદ્ધતિનો ઉપયોગ કરવો જોઈએ PATCH અને સ્થાપન content-type в application/merge-patch+json.

JSON પેચ અભિગમ, સંસાધનનું આંશિક સ્પષ્ટીકરણ પ્રદાન કરવાને બદલે, તમે એરે તરીકે સંસાધનમાં કરવા માંગો છો તે ફેરફારો પ્રદાન કરવાનો ઉપયોગ કરે છે, જેમાં એરેનું દરેક ઘટક સંસાધનમાં કરવામાં આવતા ફેરફારનું વર્ણન રજૂ કરે છે. આ અભિગમ એ ફેરફારોને વ્યક્ત કરવાની વધુ લવચીક અને શક્તિશાળી રીત છે, પરંતુ આંશિક સંસાધન સ્પષ્ટીકરણ મોકલવાને બદલે અલગ, બિન-કુબરનેટ્સ ફોર્મેટમાં કરવામાં આવતા ફેરફારોને સૂચિબદ્ધ કરવાના ખર્ચે. IN kubectl તમે ઉપયોગ કરીને JSON પેચ પસંદ કરી શકો છો kubectl patch --type=json. Kubernetes API નો ઉપયોગ કરતી વખતે, આ અભિગમ વિનંતી પદ્ધતિનો ઉપયોગ કરીને કાર્ય કરે છે PATCH અને સ્થાપન content-type в application/json-patch+json.

અમને આત્મવિશ્વાસની જરૂર છે - રિપ્લેસનો ઉપયોગ કરો

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

• A અને B એ API માંથી સ્ત્રોતની વર્તમાન સ્થિતિ મેળવે છે
• દરેક સ્થાનિક રીતે કાઉન્ટરને એક વડે વધારીને અને "અપડેટ-બાય" નોંધમાં અનુક્રમે "A" અથવા "B" ઉમેરીને સ્પષ્ટીકરણને અપડેટ કરે છે.
• અને તે સંસાધનને થોડી ઝડપથી અપડેટ કરે છે
• B સંસાધનને અપડેટ કરે છે

પરિણામે, અપડેટ A ખોવાઈ ગયું છે. છેલ્લું ઓપરેશન patch જીતે છે, કાઉન્ટર બેને બદલે એકથી વધે છે, અને "અપડેટ-બાય" નોંધની કિંમત "B" સાથે સમાપ્ત થાય છે અને તેમાં "A" નથી. ચાલો ઉપરની સરખામણી કરીએ કે જ્યારે અભિગમનો ઉપયોગ કરીને અપડેટ કરવામાં આવે ત્યારે શું થાય છે replace:

• A અને B એ API માંથી સ્ત્રોતની વર્તમાન સ્થિતિ મેળવે છે
• દરેક સ્થાનિક રીતે કાઉન્ટરને એક વડે વધારીને અને "અપડેટ-બાય" નોંધમાં અનુક્રમે "A" અથવા "B" ઉમેરીને સ્પષ્ટીકરણને અપડેટ કરે છે.
• અને તે સંસાધનને થોડી ઝડપથી અપડેટ કરે છે
• B સંસાધનને અપડેટ કરવાનો પ્રયાસ કરે છે, પરંતુ અપડેટને API દ્વારા નકારવામાં આવે છે કારણ કે સંસાધન સંસ્કરણ સ્પષ્ટીકરણમાં છે replace કુબરનેટ્સમાં સંસાધનના વર્તમાન સંસ્કરણ સાથે મેળ ખાતું નથી કારણ કે સંસાધનનું સંસ્કરણ A ના રિપ્લેસ ઓપરેશન દ્વારા વધારવામાં આવ્યું હતું.

ઉપરોક્ત કિસ્સામાં, B એ સંસાધનને ફરીથી મેળવવું પડશે, નવા રાજ્યમાં ફેરફારો કરવા પડશે અને ફરીથી પ્રયાસ કરવો પડશે replace. આનાથી કાઉન્ટર બેથી વધશે અને "અપડેટ-બાય" નોટમાં અંતે "AB" નો સમાવેશ થશે.

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

$ kubectl get deployment my-deployment -o json 
    | jq '.spec.template.spec.containers[0].env[1].value = "new value"' 
    | kubectl replace -f -

તે નોંધવું યોગ્ય છે કે નીચેના બે આદેશો, ક્રમિક રીતે ચલાવવામાં આવે છે, સફળતાપૂર્વક અમલ કરશે, કારણ કે deployment.yaml મિલકત સમાવતું નથી .metadata.resourceVersion

$ kubectl create -f deployment.yaml
$ kubectl replace -f deployment.yaml

આ ઉપર જે કહેવામાં આવ્યું હતું તેનાથી વિરોધાભાસી લાગશે, એટલે કે. "ઉમેરીને resourceVersion સ્પષ્ટીકરણ મેટાડેટામાં." શું તે કહેવું ખોટું છે? ના, તે નથી, કારણ કે જો kubectl નોટિસ કે જે તમે ઉલ્લેખિત નથી resourceVersion, તે તેને સંસાધનમાંથી વાંચશે અને તેને તમે ઉલ્લેખિત સ્પષ્ટીકરણમાં ઉમેરશે, અને પછી જ તેને અમલમાં મૂકશે. replace. કારણ કે જો તમે પરમાણુ પર આધાર રાખતા હોવ તો આ સંભવિત જોખમી છે, જાદુ સંપૂર્ણપણે બાજુ પર કામ કરે છે kubectl, API સાથે કામ કરતી ક્લાયંટ લાઇબ્રેરીઓનો ઉપયોગ કરતી વખતે તમારે તેના પર આધાર રાખવો જોઈએ નહીં. આ કિસ્સામાં તમારે વર્તમાન સંસાધન સ્પષ્ટીકરણ વાંચવું પડશે, તેને અપડેટ કરવું પડશે અને પછી એક્ઝિક્યુટ કરવું પડશે PUT વિનંતી

તમે પેચ કરી શકતા નથી - અમે બદલીએ છીએ

કેટલીકવાર તમારે કેટલાક ફેરફારો કરવાની જરૂર છે જે API દ્વારા નિયંત્રિત કરી શકાતી નથી. આ કિસ્સાઓમાં, તમે સંસાધનને કાઢી નાખીને અને ફરીથી બનાવીને તેને બદલવાની ફરજ પાડી શકો છો. આનો ઉપયોગ કરીને કરવામાં આવે છે kubectl replace --force. આદેશને ચલાવવાથી તરત જ સંસાધનો દૂર થાય છે અને પછી તેમને પૂરા પાડવામાં આવેલ સ્પષ્ટીકરણમાંથી ફરીથી બનાવે છે. API માં કોઈ "ફોર્સ રિપ્લેસ" હેન્ડલર નથી, અને API દ્વારા આમ કરવા માટે, તમારે બે કામગીરી કરવાની જરૂર છે. પ્રથમ તમારે તેના માટે સેટ કરીને સંસાધનને કાઢી નાખવાની જરૂર છે gracePeriodSeconds શૂન્ય (0) થી અને propagationPolicy "બેકગ્રાઉન્ડ" માં અને પછી ઇચ્છિત સ્પષ્ટીકરણ સાથે આ સંસાધનને ફરીથી બનાવો.

ચેતવણી: આ અભિગમ સંભવિત જોખમી છે અને તે અવ્યાખ્યાયિત સ્થિતિ તરફ દોરી શકે છે.

સર્વર બાજુ પર અરજી કરો

ઉપર સૂચવ્યા મુજબ, કુબરનેટ્સ ડેવલપર્સ તર્કના અમલીકરણ પર કામ કરી રહ્યા છે apply થી kubectl Kubernetes API માં. તર્કશાસ્ત્ર apply Kubernetes 1.18 મારફતે ઉપલબ્ધ છે kubectl apply --server-side અથવા પદ્ધતિનો ઉપયોગ કરીને API દ્વારા PATCH с content-type application/apply-patch+YAML.

નોંધ: JSON પણ માન્ય YAML છે, તેથી તમે સ્પષ્ટીકરણને JSON તરીકે મોકલી શકો છો content-type હશે application/apply-patch+yaml.

તે તર્ક ઉપરાંત kubectl API દ્વારા દરેક માટે ઉપલબ્ધ બને છે, apply સર્વર બાજુ પર, સ્પષ્ટીકરણમાંના ક્ષેત્રો માટે કોણ જવાબદાર છે તેનો ટ્રૅક રાખે છે, આમ તેના સંઘર્ષ-મુક્ત સંપાદન માટે સુરક્ષિત બહુવિધ ઍક્સેસની મંજૂરી આપે છે. બીજા શબ્દોમાં કહીએ તો, જો apply સર્વર બાજુ પર વધુ વ્યાપક બનશે, એક સાર્વત્રિક સુરક્ષિત સંસાધન સંચાલન ઇન્ટરફેસ વિવિધ ક્લાયન્ટ્સ માટે દેખાશે, ઉદાહરણ તરીકે, kubectl, Pulumi અથવા Terraform, GitOps, તેમજ ક્લાયન્ટ લાઇબ્રેરીઓનો ઉપયોગ કરીને સ્વ-લિખિત સ્ક્રિપ્ટો.

પરિણામો

હું આશા રાખું છું કે ક્લસ્ટરોમાં સંસાધનોને અપડેટ કરવાની વિવિધ રીતોની આ ટૂંકી ઝાંખી તમારા માટે મદદરૂપ હતી. તે જાણવું સારું છે કે તે ફક્ત લાગુ વિરુદ્ધ બદલો નથી; લાગુ કરો, સંપાદિત કરો, પેચ કરો અથવા બદલો નો ઉપયોગ કરીને સંસાધનને અપડેટ કરવું શક્ય છે. છેવટે, સૈદ્ધાંતિક રીતે, દરેક અભિગમનો તેનો પોતાનો વિસ્તાર છે. પરમાણુ ફેરફારો માટે, બદલો પ્રાધાન્યક્ષમ છે; અન્યથા, તમારે અરજી દ્વારા વ્યૂહાત્મક-મર્જ પેચનો ઉપયોગ કરવો જોઈએ. ઓછામાં ઓછું, હું અપેક્ષા રાખું છું કે તમે સમજો કે "kubernetes apply vs replace" માટે શોધ કરતી વખતે તમે Google અથવા StackOerflow પર વિશ્વાસ કરી શકતા નથી. ઓછામાં ઓછું આ લેખ વર્તમાન જવાબને બદલે ત્યાં સુધી.

સોર્સ: www.habr.com