കുബർനെറ്റുകളുടെ ശരിയായ താരതമ്യം പ്രയോഗിക്കുക, മാറ്റിസ്ഥാപിക്കുക, പാച്ച് ചെയ്യുക

ഉറവിടങ്ങൾ അപ്‌ഡേറ്റ് ചെയ്യുന്നതിന് Kubernetes-ന് നിരവധി ഓപ്ഷനുകൾ ഉണ്ട്: പ്രയോഗിക്കുക, എഡിറ്റ് ചെയ്യുക, പാച്ച് ചെയ്യുക, മാറ്റിസ്ഥാപിക്കുക. ഓരോരുത്തരും എന്താണ് ചെയ്യുന്നതെന്നും എപ്പോൾ ഉപയോഗിക്കണമെന്നും ആശയക്കുഴപ്പമുണ്ട്. നമുക്ക് അത് കണ്ടുപിടിക്കാം.

ആണെങ്കിൽ ഗൂഗിളിൽ തിരയുക "kubernetes apply vs replace" എന്ന വാചകം സ്ഥിതിചെയ്യുന്നു StackOverflow എന്നതിനുള്ള മറുപടി, അത് ശരിയല്ല. തിരയുമ്പോൾ "kubernetes apply vs pach" എന്നതിനായുള്ള ഡോക്യുമെന്റേഷനാണ് ആദ്യ ലിങ്ക് 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 വഴിയുള്ള ക്ലസ്റ്ററുകളിലും പ്രവർത്തിക്കുന്നു. മറ്റൊരു വാക്കിൽ, kubectlGo ഭാഷയ്‌ക്കായുള്ള ക്ലയന്റ് ലൈബ്രറിയുടെ മുകളിലുള്ള ഒരു റാപ്പറാണ്, ഇത് സാധാരണ 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. ഉദാഹരണത്തിന്, നിങ്ങൾക്ക് ഒന്നിലധികം ഉറവിടങ്ങൾ അപ്‌ഡേറ്റ് ചെയ്‌ത കൗണ്ടറുള്ള ഒരു കോൺഫിഗ്‌മാപ്പ് ഉണ്ടെങ്കിൽ, രണ്ട് ഉറവിടങ്ങൾ ഒരേ സമയം കൗണ്ടർ അപ്‌ഡേറ്റ് ചെയ്യുന്നില്ലെന്ന് ഉറപ്പാക്കണം, ഇത് അപ്‌ഡേറ്റ് നഷ്‌ടപ്പെടുന്നതിന് കാരണമാകുന്നു. പ്രദർശിപ്പിക്കുന്നതിന്, സമീപനം ഉപയോഗിച്ച് സംഭവങ്ങളുടെ ഒരു ക്രമം സങ്കൽപ്പിക്കുക patch:

• API-യിൽ നിന്ന് A, B എന്നിവ വിഭവത്തിന്റെ നിലവിലെ അവസ്ഥ നേടുന്നു
• കൌണ്ടർ ഒന്നായി വർദ്ധിപ്പിച്ചുകൊണ്ട് ഓരോന്നും പ്രാദേശികമായി സ്പെസിഫിക്കേഷൻ അപ്ഡേറ്റ് ചെയ്യുന്നു കൂടാതെ "അപ്ഡേറ്റ്-ബൈ" നോട്ടിൽ യഥാക്രമം "എ" അല്ലെങ്കിൽ "ബി" ചേർക്കുകയും ചെയ്യുന്നു.
• കൂടാതെ ഇത് റിസോഴ്‌സ് അൽപ്പം വേഗത്തിൽ അപ്‌ഡേറ്റ് ചെയ്യുന്നു
• ബി ഉറവിടം അപ്ഡേറ്റ് ചെയ്യുന്നു

തൽഫലമായി, അപ്‌ഡേറ്റ് എ നഷ്‌ടമായി. അവസാന പ്രവർത്തനം patch വിജയിക്കുന്നു, കൌണ്ടർ രണ്ടിന് പകരം ഒന്നായി വർദ്ധിപ്പിച്ചു, കൂടാതെ "അപ്‌ഡേറ്റ്-ബൈ" നോട്ടിന്റെ മൂല്യം "ബി" ൽ അവസാനിക്കുകയും "എ" അടങ്ങിയിട്ടില്ല. അപ്‌ഡേറ്റുകൾ അപ്‌ഡേറ്റ് ചെയ്യുമ്പോൾ എന്താണ് സംഭവിക്കുന്നതെന്ന് മുകളിൽ പറഞ്ഞവയുമായി താരതമ്യം ചെയ്യാം replace:

• API-യിൽ നിന്ന് A, B എന്നിവ വിഭവത്തിന്റെ നിലവിലെ അവസ്ഥ നേടുന്നു
• കൌണ്ടർ ഒന്നായി വർദ്ധിപ്പിച്ചുകൊണ്ട് ഓരോന്നും പ്രാദേശികമായി സ്പെസിഫിക്കേഷൻ അപ്ഡേറ്റ് ചെയ്യുന്നു കൂടാതെ "അപ്ഡേറ്റ്-ബൈ" നോട്ടിൽ യഥാക്രമം "എ" അല്ലെങ്കിൽ "ബി" ചേർക്കുകയും ചെയ്യുന്നു.
• കൂടാതെ ഇത് റിസോഴ്‌സ് അൽപ്പം വേഗത്തിൽ അപ്‌ഡേറ്റ് ചെയ്യുന്നു
• B റിസോഴ്സ് അപ്ഡേറ്റ് ചെയ്യാൻ ശ്രമിക്കുന്നു, പക്ഷേ റിസോഴ്സ് പതിപ്പ് സ്പെസിഫിക്കേഷനിലായതിനാൽ അപ്ഡേറ്റ് API നിരസിച്ചു replace എയുടെ റീപ്ലേസ് ഓപ്പറേഷൻ വഴി റിസോഴ്സിന്റെ പതിപ്പ് വർദ്ധിപ്പിച്ചതിനാൽ കുബർനെറ്റസിലെ റിസോഴ്സിന്റെ നിലവിലെ പതിപ്പുമായി പൊരുത്തപ്പെടുന്നില്ല.

മുകളിൽ പറഞ്ഞ സാഹചര്യത്തിൽ, 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 "പശ്ചാത്തലത്തിൽ" തുടർന്ന് ആവശ്യമുള്ള സ്പെസിഫിക്കേഷൻ ഉപയോഗിച്ച് ഈ റിസോഴ്സ് വീണ്ടും സൃഷ്ടിക്കുക.

മുന്നറിയിപ്പ്: ഈ സമീപനം അപകടസാധ്യതയുള്ളതും നിർവചിക്കപ്പെടാത്ത അവസ്ഥയിലേക്ക് നയിച്ചേക്കാം.

സെർവർ വശത്ത് പ്രയോഗിക്കുക

മുകളിൽ സൂചിപ്പിച്ചതുപോലെ, Kubernetes ഡവലപ്പർമാർ യുക്തി നടപ്പിലാക്കാൻ പ്രവർത്തിക്കുന്നു 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