വെർഫിലേക്കുള്ള 3-വേ ലയനം: "സ്റ്റിറോയിഡുകളിൽ" ഹെൽമിനൊപ്പം കുബർനെറ്റസിലേക്ക് വിന്യാസം

ഞങ്ങൾ (ഞങ്ങൾ മാത്രമല്ല) വളരെക്കാലമായി കാത്തിരിക്കുന്നത് സംഭവിച്ചു: വെർഫ്, ഞങ്ങളുടെ ഓപ്പൺ സോഴ്‌സ് യൂട്ടിലിറ്റി ആപ്ലിക്കേഷനുകൾ നിർമ്മിക്കുന്നതിനും അവ കുബർനെറ്റുകളിലേക്ക് എത്തിക്കുന്നതിനും, ഇപ്പോൾ 3-വേ ലയന പാച്ചുകൾ ഉപയോഗിച്ച് മാറ്റങ്ങൾ പ്രയോഗിക്കുന്നതിനെ പിന്തുണയ്ക്കുന്നു! ഇതിനുപുറമെ, ഈ ഉറവിടങ്ങൾ പുനർനിർമ്മിക്കാതെ തന്നെ നിലവിലുള്ള K8s ഉറവിടങ്ങൾ ഹെൽം റിലീസുകളിലേക്ക് സ്വീകരിക്കാൻ സാധിക്കും.

ഇത് വളരെ ചെറുതാണെങ്കിൽ, ഞങ്ങൾ ഇടുന്നു WERF_THREE_WAY_MERGE=enabled — നമുക്ക് വിന്യാസം ലഭിക്കുന്നു kubectl apply", നിലവിലുള്ള ഹെൽം 2 ഇൻസ്റ്റാളേഷനുകളുമായി പൊരുത്തപ്പെടുന്നു കൂടാതെ കുറച്ചുകൂടി.

എന്നാൽ നമുക്ക് സിദ്ധാന്തത്തിൽ നിന്ന് ആരംഭിക്കാം: കൃത്യമായി എന്താണ് 3-വേ-ലയന പാച്ചുകൾ, അവ സൃഷ്ടിക്കുന്നതിനുള്ള സമീപനം ആളുകൾ എങ്ങനെയാണ് കൊണ്ടുവന്നത്, കുബർനെറ്റസ് അടിസ്ഥാനമാക്കിയുള്ള ഇൻഫ്രാസ്ട്രക്ചറിലുള്ള CI/CD പ്രക്രിയകളിൽ അവ പ്രധാനമായിരിക്കുന്നത് എന്തുകൊണ്ട്? അതിനുശേഷം, വെർഫിൽ 3-വേ-മെർജ് എന്താണെന്നും ഡിഫോൾട്ടായി ഏതൊക്കെ മോഡുകളാണ് ഉപയോഗിക്കുന്നതെന്നും അത് എങ്ങനെ കൈകാര്യം ചെയ്യാമെന്നും നോക്കാം.

എന്താണ് ഒരു 3-വഴി ലയന പാച്ച്?

അതിനാൽ, YAML മാനിഫെസ്റ്റുകളിൽ വിവരിച്ചിരിക്കുന്ന ഉറവിടങ്ങൾ കുബെർനെറ്റുകളാക്കി മാറ്റുന്നതിനുള്ള ചുമതലയിൽ നിന്ന് നമുക്ക് ആരംഭിക്കാം.

ഉറവിടങ്ങളുമായി പ്രവർത്തിക്കാൻ, Kubernetes API ഇനിപ്പറയുന്ന അടിസ്ഥാന പ്രവർത്തനങ്ങൾ വാഗ്ദാനം ചെയ്യുന്നു: സൃഷ്ടിക്കുക, പാച്ച് ചെയ്യുക, മാറ്റിസ്ഥാപിക്കുക, ഇല്ലാതാക്കുക. അവരുടെ സഹായത്തോടെ ക്ലസ്റ്ററിലേക്ക് വിഭവങ്ങളുടെ സൗകര്യപ്രദമായ തുടർച്ചയായ റോൾഔട്ട് നിർമ്മിക്കേണ്ടത് ആവശ്യമാണെന്ന് അനുമാനിക്കപ്പെടുന്നു. എങ്ങനെ?

kubectl നിർബന്ധിത കമാൻഡുകൾ

കുബെർനെറ്റസിലെ ഒബ്‌ജക്‌റ്റുകൾ കൈകാര്യം ചെയ്യുന്നതിനുള്ള ആദ്യ സമീപനം, ആ ഒബ്‌ജക്റ്റുകൾ സൃഷ്‌ടിക്കാനും പരിഷ്‌ക്കരിക്കാനും ഇല്ലാതാക്കാനും kubectl നിർബന്ധിത കമാൻഡുകൾ ഉപയോഗിക്കുക എന്നതാണ്. ലളിതമായി പറഞ്ഞാൽ:

• ടീം kubectl run നിങ്ങൾക്ക് വിന്യാസമോ ജോലിയോ പ്രവർത്തിപ്പിക്കാൻ കഴിയും:

  kubectl run --generator=deployment/apps.v1 DEPLOYMENT_NAME --image=IMAGE

• ടീം kubectl scale - പകർപ്പുകളുടെ എണ്ണം മാറ്റുക:

  kubectl scale --replicas=3 deployment/mysql

• അതുപോലെ.

ഈ സമീപനം ഒറ്റനോട്ടത്തിൽ സൗകര്യപ്രദമാണെന്ന് തോന്നിയേക്കാം. എന്നിരുന്നാലും പ്രശ്നങ്ങൾ ഉണ്ട്:

1. ഇത് ബുദ്ധിമുട്ടാണ് യാന്ത്രികമാക്കുക.
2. എങ്ങനെ കോൺഫിഗറേഷൻ പ്രതിഫലിപ്പിക്കുക Git-ൽ? ക്ലസ്റ്ററിൽ സംഭവിക്കുന്ന മാറ്റങ്ങൾ എങ്ങനെ അവലോകനം ചെയ്യാം?
3. എങ്ങനെ നൽകാം പുനരുൽപാദനക്ഷമത പുനരാരംഭിക്കുമ്പോൾ കോൺഫിഗറേഷനുകൾ?
4. പങ്ക് € |

ആപ്ലിക്കേഷനും ഇൻഫ്രാസ്ട്രക്ചറും കോഡായി സംഭരിക്കുന്നതിന് ഈ സമീപനം അനുയോജ്യമല്ലെന്ന് വ്യക്തമാണ് (IaC; അല്ലെങ്കിൽ പോലും. GitOps കൂടുതൽ ആധുനികമായ ഒരു ഓപ്ഷനായി, കുബർനെറ്റസ് ആവാസവ്യവസ്ഥയിൽ ജനപ്രീതി നേടുന്നു). അതിനാൽ, ഈ കമാൻഡുകൾക്ക് kubectl-ൽ കൂടുതൽ വികസനം ലഭിച്ചില്ല.

പ്രവർത്തനങ്ങൾ സൃഷ്ടിക്കുക, നേടുക, മാറ്റിസ്ഥാപിക്കുക, ഇല്ലാതാക്കുക

പ്രാഥമിക കൂടെ സൃഷ്ടി ഇത് ലളിതമാണ്: പ്രവർത്തനത്തിലേക്ക് മാനിഫെസ്റ്റ് അയയ്ക്കുക create kube api, ഉറവിടം സൃഷ്ടിച്ചു. മാനിഫെസ്റ്റിന്റെ YAML പ്രാതിനിധ്യം Git-ൽ സംഭരിക്കാനും കമാൻഡ് ഉപയോഗിച്ച് സൃഷ്ടിക്കാനും കഴിയും kubectl create -f manifest.yaml.

С നീക്കംചെയ്യുന്നു ലളിതവും: അതേ പകരം വയ്ക്കുക manifest.yaml Git-ൽ നിന്ന് ടീമിലേക്ക് kubectl delete -f manifest.yaml.

പ്രവർത്തനം replace റിസോഴ്സ് പുനർനിർമ്മിക്കാതെ തന്നെ പുതിയൊരെണ്ണം ഉപയോഗിച്ച് റിസോഴ്സ് കോൺഫിഗറേഷൻ പൂർണ്ണമായും മാറ്റിസ്ഥാപിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു. ഇതിനർത്ഥം ഒരു റിസോഴ്‌സിൽ മാറ്റം വരുത്തുന്നതിന് മുമ്പ്, പ്രവർത്തനത്തിനൊപ്പം നിലവിലെ പതിപ്പ് അന്വേഷിക്കുന്നത് യുക്തിസഹമാണ് get, അത് മാറ്റി ഓപ്പറേഷൻ ഉപയോഗിച്ച് അപ്ഡേറ്റ് ചെയ്യുക replace. kube apiserver നിർമ്മിച്ചിരിക്കുന്നത് ശുഭാപ്തിവിശ്വാസമുള്ള ലോക്കിംഗ് കൂടാതെ, ശസ്ത്രക്രിയയ്ക്കു ശേഷമാണെങ്കിൽ get വസ്തു മാറി, പിന്നെ പ്രവർത്തനം replace അത് പ്രവർത്തിക്കില്ല.

Git-ൽ കോൺഫിഗറേഷൻ സംഭരിക്കാനും മാറ്റിസ്ഥാപിക്കുക ഉപയോഗിച്ച് അപ്ഡേറ്റ് ചെയ്യാനും, നിങ്ങൾ പ്രവർത്തനം നടത്തേണ്ടതുണ്ട് get, Git-ൽ നിന്നുള്ള കോൺഫിഗറേഷൻ ഞങ്ങൾക്ക് ലഭിച്ചവയുമായി ലയിപ്പിച്ച് എക്സിക്യൂട്ട് ചെയ്യുക replace. സ്ഥിരസ്ഥിതിയായി, kubectl നിങ്ങളെ കമാൻഡ് ഉപയോഗിക്കാൻ മാത്രമേ അനുവദിക്കൂ kubectl replace -f manifest.yamlഎവിടെ manifest.yaml — ഇതിനകം പൂർണ്ണമായി തയ്യാറാക്കിയ (ഞങ്ങളുടെ കാര്യത്തിൽ, ലയിപ്പിച്ച) മാനിഫെസ്റ്റ് ഇൻസ്റ്റാൾ ചെയ്യേണ്ടതുണ്ട്. ഉപയോക്താവിന് ലയന മാനിഫെസ്റ്റുകൾ നടപ്പിലാക്കേണ്ടതുണ്ടെന്ന് ഇത് മാറുന്നു, ഇത് ഒരു നിസ്സാര കാര്യമല്ല...

എന്നതും ശ്രദ്ധിക്കേണ്ടതാണ് manifest.yaml കൂടാതെ Git-ൽ സംഭരിച്ചിരിക്കുന്നു, ഒരു ഒബ്‌ജക്റ്റ് സൃഷ്‌ടിക്കണോ അപ്‌ഡേറ്റ് ചെയ്യേണ്ടതുണ്ടോ എന്ന് ഞങ്ങൾക്ക് മുൻകൂട്ടി അറിയാൻ കഴിയില്ല - ഇത് ഉപയോക്തൃ സോഫ്‌റ്റ്‌വെയർ ചെയ്യണം.

ആകെ: നമുക്ക് ഒരു തുടർച്ചയായ റോൾഔട്ട് നിർമ്മിക്കാൻ കഴിയുമോ? കോഡ്, സൗകര്യപ്രദമായ CI/CD എന്നിവയ്‌ക്കൊപ്പം ഇൻഫ്രാസ്ട്രക്ചർ കോൺഫിഗറേഷൻ Git-ൽ സംഭരിച്ചിട്ടുണ്ടെന്ന് ഉറപ്പാക്കിക്കൊണ്ട് സൃഷ്‌ടിക്കുക, മാറ്റിസ്ഥാപിക്കുക, ഇല്ലാതാക്കുക എന്നിവ മാത്രം ഉപയോഗിക്കുകയാണോ?

തത്വത്തിൽ, നമുക്ക് കഴിയും ... ഇതിനായി നിങ്ങൾ ലയന പ്രവർത്തനം നടപ്പിലാക്കേണ്ടതുണ്ട് മാനിഫെസ്റ്റോകളും ചില തരത്തിലുള്ള ബൈൻഡിംഗും:

• ക്ലസ്റ്ററിലെ ഒരു വസ്തുവിന്റെ സാന്നിധ്യം പരിശോധിക്കുന്നു,
• പ്രാരംഭ വിഭവ സൃഷ്ടി നടത്തുന്നു,
• അത് അപ്ഡേറ്റ് ചെയ്യുകയോ ഇല്ലാതാക്കുകയോ ചെയ്യുന്നു.

അപ്ഡേറ്റ് ചെയ്യുമ്പോൾ, അത് ശ്രദ്ധിക്കുക ഉറവിടം മാറിയിരിക്കാം അവസാനം മുതൽ get ശുഭാപ്തിവിശ്വാസമുള്ള ലോക്കിംഗിന്റെ കേസ് സ്വയമേവ കൈകാര്യം ചെയ്യുക - ആവർത്തിച്ചുള്ള അപ്‌ഡേറ്റ് ശ്രമങ്ങൾ നടത്തുക.

എന്നിരുന്നാലും, ഉറവിടങ്ങൾ അപ്‌ഡേറ്റ് ചെയ്യുന്നതിനുള്ള മറ്റൊരു മാർഗം kube-apiserver വാഗ്ദാനം ചെയ്യുമ്പോൾ എന്തുകൊണ്ട് വീൽ വീണ്ടും കണ്ടുപിടിക്കണം: പ്രവർത്തനം patch, വിവരിച്ച ചില പ്രശ്‌നങ്ങളിൽ നിന്ന് ഉപയോക്താവിന് ആശ്വാസം നൽകുന്നതെന്താണ്?

തുണിത്തുണ്ട്

ഇപ്പോൾ നമ്മൾ പാച്ചുകളിലേക്ക് പോകുന്നു.

കുബെർനെറ്റസിലെ നിലവിലുള്ള ഒബ്‌ജക്‌റ്റുകളിൽ മാറ്റങ്ങൾ പ്രയോഗിക്കുന്നതിനുള്ള പ്രാഥമിക മാർഗമാണ് പാച്ചുകൾ. ഓപ്പറേഷൻ patch ഇത് ഇതുപോലെ പ്രവർത്തിക്കുന്നു:

• kube-apiserver ഉപയോക്താവിന് JSON ഫോമിൽ ഒരു പാച്ച് അയച്ച് ഒബ്‌ജക്റ്റ് വ്യക്തമാക്കേണ്ടതുണ്ട്,
• കൂടാതെ apiserver തന്നെ വസ്തുവിന്റെ നിലവിലെ അവസ്ഥ കൈകാര്യം ചെയ്യുകയും ആവശ്യമായ രൂപത്തിലേക്ക് കൊണ്ടുവരുകയും ചെയ്യും.

ഈ സാഹചര്യത്തിൽ ശുഭാപ്തിവിശ്വാസമുള്ള ലോക്കിംഗ് ആവശ്യമില്ല. ഈ പ്രവർത്തനം മാറ്റിസ്ഥാപിക്കുന്നതിനേക്കാൾ കൂടുതൽ ഡിക്ലറേറ്റീവ് ആണ്, ആദ്യം ഇത് വിപരീതമായി തോന്നാമെങ്കിലും.

ഈ രീതിയിൽ:

• ഒരു ഓപ്പറേഷൻ ഉപയോഗിച്ച് create Git-ൽ നിന്നുള്ള മാനിഫെസ്റ്റ് അനുസരിച്ച് ഞങ്ങൾ ഒരു വസ്തു സൃഷ്ടിക്കുന്നു,
• സഹായത്തോടെ delete - ഒബ്ജക്റ്റ് ഇനി ആവശ്യമില്ലെങ്കിൽ ഇല്ലാതാക്കുക,
• സഹായത്തോടെ patch - ഞങ്ങൾ ഒബ്ജക്റ്റ് മാറ്റുന്നു, അത് Git-ൽ വിവരിച്ചിരിക്കുന്ന രൂപത്തിലേക്ക് കൊണ്ടുവരുന്നു.

എന്നിരുന്നാലും, ഇത് ചെയ്യുന്നതിന്, നിങ്ങൾ സൃഷ്ടിക്കേണ്ടതുണ്ട് ശരിയായ പാച്ച്!

ഹെൽം 2-ൽ പാച്ചുകൾ എങ്ങനെ പ്രവർത്തിക്കുന്നു: 2-വേ-മെർജ്

നിങ്ങൾ ആദ്യം ഒരു റിലീസ് ഇൻസ്റ്റാൾ ചെയ്യുമ്പോൾ, ഹെൽം പ്രവർത്തനം നടത്തുന്നു create ചാർട്ട് ഉറവിടങ്ങൾക്കായി.

ഓരോ റിസോഴ്സിനും ഒരു ഹെൽം റിലീസ് അപ്ഡേറ്റ് ചെയ്യുമ്പോൾ:

• മുമ്പത്തെ ചാർട്ടിൽ നിന്നുള്ള റിസോഴ്സ് പതിപ്പും നിലവിലെ ചാർട്ട് പതിപ്പും തമ്മിലുള്ള പാച്ച് പരിഗണിക്കുന്നു,
• ഈ പാച്ച് പ്രയോഗിക്കുന്നു.

ഞങ്ങൾ ഇതിനെ പാച്ച് എന്ന് വിളിക്കും 2-വേ ലയന പാച്ച്, കാരണം അതിന്റെ സൃഷ്ടിയിൽ 2 മാനിഫെസ്റ്റോകൾ ഉൾപ്പെടുന്നു:

• മുമ്പത്തെ പതിപ്പിൽ നിന്നുള്ള ഉറവിട മാനിഫെസ്റ്റ്,
• നിലവിലെ ഉറവിടത്തിൽ നിന്നുള്ള ഉറവിടം മാനിഫെസ്റ്റ്.

പ്രവർത്തനം നീക്കം ചെയ്യുമ്പോൾ delete kube apiserver-ൽ, മുമ്പത്തെ പതിപ്പിൽ പ്രഖ്യാപിച്ചിട്ടുള്ളതും എന്നാൽ നിലവിലുള്ളതിൽ പ്രഖ്യാപിച്ചിട്ടില്ലാത്തതുമായ ഉറവിടങ്ങൾക്കായി വിളിക്കുന്നു.

2-വേ ലയന പാച്ച് സമീപനത്തിന് ഒരു പ്രശ്നമുണ്ട്: ഇത് നയിക്കുന്നു ക്ലസ്റ്ററിലെ ഉറവിടത്തിന്റെയും Git-ലെ മാനിഫെസ്റ്റിന്റെയും യഥാർത്ഥ അവസ്ഥയുമായി സമന്വയമില്ല.

ഒരു ഉദാഹരണം ഉപയോഗിച്ച് പ്രശ്നത്തിന്റെ ചിത്രീകരണം

• Git-ൽ, ഒരു ചാർട്ട് ഒരു മാനിഫെസ്റ്റ് സംഭരിക്കുന്നു, അതിൽ ഫീൽഡ് image വിന്യാസം പ്രധാനമാണ് ubuntu:18.04.
• ഉപയോക്താവ് വഴി kubectl edit ഈ ഫീൽഡിന്റെ മൂല്യം മാറ്റി ubuntu:19.04.
• ഹെൽം ചാർട്ട് വീണ്ടും വിന്യസിക്കുമ്പോൾ ഒരു പാച്ച് സൃഷ്ടിക്കുന്നില്ല, കാരണം വയലാണ് image റിലീസിന്റെ മുൻ പതിപ്പിലും നിലവിലെ ചാർട്ടിലും സമാനമാണ്.
• വീണ്ടും വിന്യാസത്തിന് ശേഷം image അവശേഷിക്കുന്നു ubuntu:19.04, ചാർട്ട് പറയുന്നുണ്ടെങ്കിലും ubuntu:18.04.

ഞങ്ങൾക്ക് ഡീസിൻക്രൊണൈസേഷൻ ലഭിച്ചു, പ്രഖ്യാപനം നഷ്ടപ്പെട്ടു.

എന്താണ് സമന്വയിപ്പിച്ച വിഭവം?

പൊതുവായി പറഞ്ഞാൽ പൂർത്തിയായി ഒരു റണ്ണിംഗ് ക്ലസ്റ്ററിലെ റിസോഴ്സ് മാനിഫെസ്റ്റും Git-ൽ നിന്നുള്ള മാനിഫെസ്റ്റും തമ്മിൽ ഒരു പൊരുത്തം നേടുക അസാധ്യമാണ്. കാരണം ഒരു യഥാർത്ഥ മാനിഫെസ്റ്റിൽ സേവന വ്യാഖ്യാനങ്ങൾ/ലേബലുകൾ, അധിക കണ്ടെയ്‌നറുകൾ, മറ്റ് ഡാറ്റ എന്നിവ ഉണ്ടായിരിക്കാം, അത് ചില കൺട്രോളറുകൾ ഊർജ്ജസ്വലമായി ഉറവിടത്തിൽ നിന്ന് ചേർക്കുകയും നീക്കം ചെയ്യുകയും ചെയ്യുന്നു. ഈ ഡാറ്റ Git-ൽ സൂക്ഷിക്കാൻ ഞങ്ങൾക്ക് കഴിയില്ല, ആഗ്രഹിക്കുന്നില്ല. എന്നിരുന്നാലും, Git-ൽ ഞങ്ങൾ വ്യക്തമായി വ്യക്തമാക്കിയ ഫീൽഡുകൾ റോൾഔട്ടിൽ ഉചിതമായ മൂല്യങ്ങൾ സ്വീകരിക്കണമെന്ന് ഞങ്ങൾ ആഗ്രഹിക്കുന്നു.

ഇത് വളരെ പൊതുവായി മാറുന്നു സമന്വയിപ്പിച്ച റിസോഴ്സ് റൂൾ: ഒരു റിസോഴ്സ് പുറത്തിറക്കുമ്പോൾ, Git-ൽ നിന്നുള്ള മാനിഫെസ്റ്റിൽ വ്യക്തമായി വ്യക്തമാക്കിയിട്ടുള്ള (അല്ലെങ്കിൽ മുമ്പത്തെ പതിപ്പിൽ വ്യക്തമാക്കിയതും ഇപ്പോൾ ഇല്ലാതാക്കിയവയും) ആ ഫീൽഡുകൾ മാത്രമേ നിങ്ങൾക്ക് മാറ്റാനോ ഇല്ലാതാക്കാനോ കഴിയൂ.

3-വേ ലയന പാച്ച്

മുഖ്യ ആശയം 3-വേ ലയന പാച്ച്: പ്രവർത്തിക്കുന്ന ക്ലസ്റ്ററിൽ നിന്നുള്ള മാനിഫെസ്റ്റിന്റെ നിലവിലെ പതിപ്പ് കണക്കിലെടുത്ത് Git-ൽ നിന്നുള്ള മാനിഫെസ്റ്റിന്റെ അവസാന പ്രയോഗിച്ച പതിപ്പിനും Git-ൽ നിന്നുള്ള മാനിഫെസ്റ്റിന്റെ ടാർഗെറ്റ് പതിപ്പിനും ഇടയിൽ ഒരു പാച്ച് സൃഷ്ടിക്കുക. തത്ഫലമായുണ്ടാകുന്ന പാച്ച് സമന്വയിപ്പിച്ച റിസോഴ്സ് നിയമത്തിന് അനുസൃതമായിരിക്കണം:

• ടാർഗെറ്റ് പതിപ്പിലേക്ക് ചേർത്ത പുതിയ ഫീൽഡുകൾ ഒരു പാച്ച് ഉപയോഗിച്ച് ചേർക്കുന്നു;
• അവസാനം പ്രയോഗിച്ച പതിപ്പിൽ മുമ്പ് നിലവിലുണ്ടായിരുന്നതും ടാർഗെറ്റ് പതിപ്പിൽ നിലവിലില്ലാത്തതുമായ ഫീൽഡുകൾ ഒരു പാച്ച് ഉപയോഗിച്ച് പുനഃസജ്ജമാക്കുന്നു;
• മാനിഫെസ്റ്റിന്റെ ടാർഗെറ്റ് പതിപ്പിൽ നിന്ന് വ്യത്യസ്തമായ ഒബ്‌ജക്റ്റിന്റെ നിലവിലെ പതിപ്പിലെ ഫീൽഡുകൾ പാച്ച് ഉപയോഗിച്ച് അപ്‌ഡേറ്റ് ചെയ്യുന്നു.

ഈ തത്വത്തിലാണ് ഇത് പാച്ചുകൾ സൃഷ്ടിക്കുന്നത് kubectl apply:

• മാനിഫെസ്റ്റിന്റെ അവസാന പ്രയോഗിച്ച പതിപ്പ് ഒബ്‌ജക്റ്റിന്റെ വ്യാഖ്യാനത്തിൽ സംഭരിച്ചിരിക്കുന്നു,
• ടാർഗെറ്റ് - നിർദ്ദിഷ്ട YAML ഫയലിൽ നിന്ന് എടുത്തത്,
• നിലവിലുള്ളത് ഒരു റണ്ണിംഗ് ക്ലസ്റ്ററിൽ നിന്നുള്ളതാണ്.

ഇപ്പോൾ ഞങ്ങൾ സിദ്ധാന്തം ക്രമീകരിച്ചു, ഞങ്ങൾ വെർഫിൽ എന്താണ് ചെയ്തതെന്ന് നിങ്ങളോട് പറയാൻ സമയമായി.

വെർഫിൽ മാറ്റങ്ങൾ പ്രയോഗിക്കുന്നു

മുമ്പ്, ഹെൽം 2 പോലെ വെർഫ്, 2-വേ-മെർജ് പാച്ചുകൾ ഉപയോഗിച്ചിരുന്നു.

പാച്ച് നന്നാക്കുക

ഒരു പുതിയ തരം പാച്ചുകളിലേക്ക് മാറുന്നതിന് - 3-വേ-ലയനം - ഞങ്ങൾ ആദ്യമായി അവതരിപ്പിച്ചത് പാച്ചുകൾ നന്നാക്കുക.

വിന്യസിക്കുമ്പോൾ, ഒരു സ്റ്റാൻഡേർഡ് 2-വേ-മെർജ് പാച്ച് ഉപയോഗിക്കുന്നു, എന്നാൽ werf അധികമായി ഒരു പാച്ച് സൃഷ്ടിക്കുന്നു, അത് ഉറവിടത്തിന്റെ യഥാർത്ഥ അവസ്ഥയെ Git-ൽ എഴുതിയിരിക്കുന്നതുമായി സമന്വയിപ്പിക്കും (മുകളിൽ വിവരിച്ച അതേ സമന്വയിപ്പിച്ച റിസോഴ്സ് റൂൾ ഉപയോഗിച്ചാണ് അത്തരമൊരു പാച്ച് സൃഷ്ടിക്കുന്നത്) .

ഒരു ഡീസിൻക്രൊണൈസേഷൻ സംഭവിക്കുകയാണെങ്കിൽ, വിന്യാസത്തിന്റെ അവസാനം ഉപയോക്താവിന് അനുബന്ധ സന്ദേശവും ഒരു പാച്ചും അടങ്ങിയ ഒരു മുന്നറിയിപ്പ് ലഭിക്കും, അത് റിസോഴ്‌സ് ഒരു സമന്വയിപ്പിച്ച ഫോമിലേക്ക് കൊണ്ടുവരാൻ പ്രയോഗിക്കണം. ഈ പാച്ച് ഒരു പ്രത്യേക വ്യാഖ്യാനത്തിലും രേഖപ്പെടുത്തിയിട്ടുണ്ട് werf.io/repair-patch. ഇത് ഉപയോക്താവിന്റെ കൈകളാണെന്ന് അനുമാനിക്കപ്പെടുന്നു сам ഈ പാച്ച് പ്രയോഗിക്കും: werf ഇത് പ്രയോഗിക്കില്ല.

റിപ്പയർ പാച്ചുകൾ സൃഷ്ടിക്കുന്നത് ഒരു താൽക്കാലിക നടപടിയാണ്, ഇത് 3-വേ-മെർജ് തത്വത്തെ അടിസ്ഥാനമാക്കി പാച്ചുകൾ സൃഷ്ടിക്കുന്നത് യഥാർത്ഥത്തിൽ പരിശോധിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു, എന്നാൽ ഈ പാച്ചുകൾ സ്വയമേവ പ്രയോഗിക്കരുത്. ഇപ്പോൾ, ഈ ഓപ്പറേറ്റിംഗ് മോഡ് സ്ഥിരസ്ഥിതിയായി പ്രവർത്തനക്ഷമമാക്കിയിരിക്കുന്നു.

പുതിയ റിലീസുകൾക്ക് മാത്രം 3-വേ-മെർജ് പാച്ച്

1 ഡിസംബർ 2019 മുതൽ, വെർഫിന്റെ ബീറ്റ, ആൽഫ പതിപ്പുകൾ ആരംഭിക്കുന്നു സ്ഥിരസ്ഥിതിയായി വെർഫിലൂടെ പുറത്തിറക്കിയ പുതിയ ഹെൽം റിലീസുകളിൽ മാത്രം മാറ്റങ്ങൾ പ്രയോഗിക്കുന്നതിന് പൂർണ്ണമായ 3-വേ-മെർജ് പാച്ചുകൾ ഉപയോഗിക്കുക. നിലവിലുള്ള റിലീസുകൾ 2-വേ-മെർജ് + റിപ്പയർ പാച്ചുകൾ ഉപയോഗിക്കുന്നത് തുടരും.

സജ്ജീകരിക്കുന്നതിലൂടെ ഈ ഓപ്പറേറ്റിംഗ് മോഡ് വ്യക്തമായി പ്രവർത്തനക്ഷമമാക്കാനാകും WERF_THREE_WAY_MERGE_MODE=onlyNewReleases ഇപ്പോൾ.

അഭിപായപ്പെടുക: ഈ സവിശേഷത വെർഫിൽ നിരവധി പതിപ്പുകളിൽ പ്രത്യക്ഷപ്പെട്ടു: ആൽഫ ചാനലിൽ ഇത് പതിപ്പിനൊപ്പം തയ്യാറായി v1.0.5-alpha.19, ഒപ്പം ബീറ്റ ചാനലിൽ - കൂടെ v1.0.4-beta.20.

എല്ലാ റിലീസുകൾക്കുമായി 3-വേ-മെർജ് പാച്ച്

ഡിസംബർ 15, 2019 മുതൽ, എല്ലാ റിലീസുകളിലും മാറ്റങ്ങൾ വരുത്തുന്നതിന് werf-ന്റെ ബീറ്റ, ആൽഫ പതിപ്പുകൾ സ്ഥിരസ്ഥിതിയായി പൂർണ്ണമായ 3-വഴി ലയന പാച്ചുകൾ ഉപയോഗിക്കാൻ തുടങ്ങുന്നു.

സജ്ജീകരിക്കുന്നതിലൂടെ ഈ ഓപ്പറേറ്റിംഗ് മോഡ് വ്യക്തമായി പ്രവർത്തനക്ഷമമാക്കാനാകും WERF_THREE_WAY_MERGE_MODE=enabled ഇപ്പോൾ.

റിസോഴ്സ് ഓട്ടോസ്കേലിംഗ് ഉപയോഗിച്ച് എന്തുചെയ്യണം?

കുബെർനെറ്റസിൽ 2 തരം ഓട്ടോസ്കെയിലിംഗ് ഉണ്ട്: HPA (തിരശ്ചീനം), VPA (ലംബം).

തിരശ്ചീന സ്വപ്രേരിതമായി പകർപ്പുകളുടെ എണ്ണം തിരഞ്ഞെടുക്കുന്നു, ലംബമായ - വിഭവങ്ങളുടെ എണ്ണം. പകർപ്പുകളുടെ എണ്ണവും ഉറവിട ആവശ്യകതകളും റിസോഴ്‌സ് മാനിഫെസ്റ്റിൽ വ്യക്തമാക്കിയിട്ടുണ്ട് (റിസോഴ്‌സ് മാനിഫെസ്റ്റ് കാണുക). spec.replicas അഥവാ spec.containers[].resources.limits.cpu, spec.containers[].resources.limits.memory и другие).

പ്രശ്നം: ഒരു ഉപയോക്താവ് ഒരു ചാർട്ടിൽ ഒരു റിസോഴ്‌സ് കോൺഫിഗർ ചെയ്‌താൽ അത് ഉറവിടങ്ങൾക്കായുള്ള ചില മൂല്യങ്ങൾ വ്യക്തമാക്കുന്നു അല്ലെങ്കിൽ ഈ റിസോഴ്‌സിനായി ഓട്ടോസ്‌കെയിലറുകൾ പ്രവർത്തനക്ഷമമാക്കിയിട്ടുണ്ടെങ്കിൽ, ഓരോ വിന്യാസത്തിലും വെർഫ് ഈ മൂല്യങ്ങൾ ചാർട്ട് മാനിഫെസ്റ്റിൽ എഴുതിയിരിക്കുന്നതിലേക്ക് പുനഃസജ്ജമാക്കും. .

പ്രശ്നത്തിന് രണ്ട് പരിഹാരങ്ങളുണ്ട്. ആരംഭിക്കുന്നതിന്, ചാർട്ട് മാനിഫെസ്റ്റിൽ സ്വയമേവയുള്ള മൂല്യങ്ങൾ വ്യക്തമായി വ്യക്തമാക്കുന്നത് ഒഴിവാക്കുന്നതാണ് നല്ലത്. ചില കാരണങ്ങളാൽ ഈ ഓപ്ഷൻ അനുയോജ്യമല്ലെങ്കിൽ (ഉദാഹരണത്തിന്, പ്രാരംഭ റിസോഴ്സ് പരിധികളും ചാർട്ടിലെ പകർപ്പുകളുടെ എണ്ണവും സജ്ജീകരിക്കുന്നത് സൗകര്യപ്രദമാണ്), തുടർന്ന് വെർഫ് ഇനിപ്പറയുന്ന വ്യാഖ്യാനങ്ങൾ വാഗ്ദാനം ചെയ്യുന്നു:

• werf.io/set-replicas-only-on-creation=true
• werf.io/set-resources-only-on-creation=true

അത്തരമൊരു വ്യാഖ്യാനം നിലവിലുണ്ടെങ്കിൽ, ഓരോ വിന്യാസത്തിലും അനുബന്ധ മൂല്യങ്ങൾ വെർഫ് പുനഃസജ്ജമാക്കില്ല, പക്ഷേ ഉറവിടം തുടക്കത്തിൽ സൃഷ്ടിക്കുമ്പോൾ മാത്രമേ അവ സജ്ജീകരിക്കൂ.

കൂടുതൽ വിവരങ്ങൾക്ക്, പദ്ധതി ഡോക്യുമെന്റേഷൻ കാണുക HPA и വി.പി.എ.

3-വേ-മെർജ് പാച്ച് ഉപയോഗിക്കുന്നത് നിരോധിക്കുക

ഒരു എൻവയോൺമെന്റ് വേരിയബിൾ ഉപയോഗിച്ച് വെർഫിൽ പുതിയ പാച്ചുകൾ ഉപയോഗിക്കുന്നത് ഉപയോക്താവിന് നിലവിൽ നിരോധിക്കാം WERF_THREE_WAY_MERGE_MODE=disabled. എന്നിരുന്നാലും, ആരംഭിക്കുന്നു 1 മാർച്ച് 2020 മുതൽ ഈ നിരോധനം ബാധകമാകില്ല. കൂടാതെ 3-വേ-മെർജ് പാച്ചുകൾ മാത്രമേ ഉപയോഗിക്കാനാകൂ.

വെർഫിലെ വിഭവങ്ങളുടെ ദത്തെടുക്കൽ

3-വേ-മെർജ് പാച്ചുകൾ ഉപയോഗിച്ച് മാറ്റങ്ങൾ പ്രയോഗിക്കുന്ന രീതി മാസ്റ്റേഴ്സ് ചെയ്യുന്നത്, ഹെൽം റിലീസിലേക്ക് ക്ലസ്റ്ററിൽ നിലവിലുള്ള വിഭവങ്ങൾ സ്വീകരിക്കുന്നത് പോലുള്ള ഒരു സവിശേഷത ഉടനടി നടപ്പിലാക്കാൻ ഞങ്ങളെ അനുവദിച്ചു.

ഹെൽം 2-ന് ഒരു പ്രശ്‌നമുണ്ട്: ആദ്യം മുതൽ ഈ റിസോഴ്‌സ് പുനർനിർമ്മിക്കാതെ നിങ്ങൾക്ക് ഇതിനകം തന്നെ ക്ലസ്റ്ററിൽ നിലവിലുള്ള ചാർട്ട് മാനിഫെസ്റ്റുകളിലേക്ക് ഒരു ഉറവിടം ചേർക്കാൻ കഴിയില്ല (കാണുക. #6031, #3275). റിലീസിനായി നിലവിലുള്ള വിഭവങ്ങൾ സ്വീകരിക്കാൻ ഞങ്ങൾ വെർഫിനെ പഠിപ്പിച്ചു. ഇത് ചെയ്യുന്നതിന്, റണ്ണിംഗ് ക്ലസ്റ്ററിൽ നിന്നുള്ള ഉറവിടത്തിന്റെ നിലവിലെ പതിപ്പിൽ നിങ്ങൾ ഒരു വ്യാഖ്യാനം ഇൻസ്റ്റാൾ ചെയ്യേണ്ടതുണ്ട് (ഉദാഹരണത്തിന്, ഉപയോഗിക്കുന്നത് kubectl edit):

"werf.io/allow-adoption-by-release": RELEASE_NAME

ഇപ്പോൾ വിഭവം ചാർട്ടിൽ വിവരിക്കേണ്ടതുണ്ട്, അടുത്ത തവണ werf ഉചിതമായ പേരിൽ ഒരു റിലീസ് വിന്യസിക്കുമ്പോൾ, നിലവിലുള്ള ഉറവിടം ഈ റിലീസിലേക്ക് സ്വീകരിക്കുകയും അതിന്റെ നിയന്ത്രണത്തിൽ തുടരുകയും ചെയ്യും. മാത്രമല്ല, റിലീസിനായി ഒരു റിസോഴ്‌സ് സ്വീകരിക്കുന്ന പ്രക്രിയയിൽ, അതേ 3-വേ-മെർജ് പാച്ചുകളും സമന്വയിപ്പിച്ച റിസോഴ്‌സ് റൂളും ഉപയോഗിച്ച്, റണ്ണിംഗ് ക്ലസ്റ്ററിൽ നിന്ന് ചാർട്ടിൽ വിവരിച്ചിരിക്കുന്ന അവസ്ഥയിലേക്ക് റിസോഴ്‌സിന്റെ നിലവിലെ അവസ്ഥ വെർഫ് കൊണ്ടുവരും.

അഭിപായപ്പെടുക: ക്രമീകരണം WERF_THREE_WAY_MERGE_MODE വിഭവങ്ങൾ സ്വീകരിക്കുന്നതിനെ ബാധിക്കില്ല - ദത്തെടുക്കലിന്റെ കാര്യത്തിൽ, ഒരു 3-വേ-ലയന പാച്ച് എപ്പോഴും ഉപയോഗിക്കുന്നു.

വിശദാംശങ്ങൾ - ഇൻ പ്രമാണീകരണം.

നിഗമനങ്ങളും ഭാവി പദ്ധതികളും

ഈ ലേഖനത്തിന് ശേഷം 3-വേ-മെർജ് പാച്ചുകൾ എന്താണെന്നും അവ എന്തിനാണ് അവയിലേക്ക് വന്നതെന്നും കൂടുതൽ വ്യക്തമാകുമെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു. വെർഫ് പ്രോജക്റ്റിന്റെ വികസനത്തിന്റെ പ്രായോഗിക വീക്ഷണകോണിൽ നിന്ന്, ഹെൽം പോലുള്ള വിന്യാസം മെച്ചപ്പെടുത്തുന്നതിനുള്ള മറ്റൊരു ചുവടുവയ്പ്പായിരുന്നു അവ നടപ്പിലാക്കുന്നത്. കോൺഫിഗറേഷൻ സിൻക്രൊണൈസേഷനിലെ പ്രശ്‌നങ്ങളെക്കുറിച്ച് നിങ്ങൾക്ക് ഇപ്പോൾ മറക്കാൻ കഴിയും, ഹെൽം 2 ഉപയോഗിക്കുമ്പോൾ പലപ്പോഴും ഇത് ഉയർന്നുവരുന്നു. അതേ സമയം, ഇതിനകം ഡൗൺലോഡ് ചെയ്‌ത കുബർനെറ്റസ് ഉറവിടങ്ങൾ സ്വീകരിക്കുന്നതിനുള്ള ഒരു പുതിയ ഉപയോഗപ്രദമായ സവിശേഷത ഹെൽം റിലീസിലേക്ക് ചേർത്തു.

Go ടെംപ്ലേറ്റുകളുടെ ഉപയോഗം പോലെയുള്ള ചില പ്രശ്‌നങ്ങളും വെല്ലുവിളികളും ഹെൽം പോലുള്ള വിന്യാസങ്ങളിൽ ഇപ്പോഴും ഉണ്ട്, ഞങ്ങൾ അത് തുടർന്നും പരിഹരിക്കും.

റിസോഴ്‌സ് അപ്‌ഡേറ്റ് രീതികളെയും ദത്തെടുക്കലിനെയും കുറിച്ചുള്ള വിവരങ്ങളും ഇവിടെ കാണാം ഈ ഡോക്യുമെന്റേഷൻ പേജ്.

ഹെൽം 3

പ്രത്യേകം ശ്രദ്ധിക്കേണ്ടതാണ് വിട്ടയച്ചു കഴിഞ്ഞ ദിവസം ഹെൽമിന്റെ ഒരു പുതിയ പ്രധാന പതിപ്പ് - v3 - അത് 3-വേ-മെർജ് പാച്ചുകൾ ഉപയോഗിക്കുകയും ടില്ലറിനെ ഒഴിവാക്കുകയും ചെയ്യുന്നു. ഹെൽമിന്റെ പുതിയ പതിപ്പ് ആവശ്യമാണ് കുടിയേറ്റം നിലവിലുള്ള ഇൻസ്റ്റലേഷനുകൾ പുതിയ റിലീസ് സ്റ്റോറേജ് ഫോർമാറ്റിലേക്ക് പരിവർത്തനം ചെയ്യുന്നതിനായി.

വെർഫ്, അതിന്റെ ഭാഗമായി, നിലവിൽ ടില്ലർ ഉപയോഗിക്കുന്നത് ഒഴിവാക്കി, 3-വേ-മെർജിലേക്ക് മാറി, ചേർത്തു വളരെ കൂടുതൽ, നിലവിലുള്ള ഹെൽം 2 ഇൻസ്റ്റാളേഷനുകളുമായി പൊരുത്തപ്പെടുന്ന സമയത്ത് (മൈഗ്രേഷൻ സ്ക്രിപ്റ്റുകളൊന്നും എക്സിക്യൂട്ട് ചെയ്യേണ്ടതില്ല). അതിനാൽ, വെർഫ് ഹെൽം 3-ലേക്ക് മാറുന്നതുവരെ, ഹെൽം 3-നേക്കാൾ ഹെൽം 2-ന്റെ പ്രധാന ഗുണങ്ങൾ വെർഫ് ഉപയോക്താക്കൾക്ക് നഷ്‌ടമാകില്ല (വെർഫിനും അവയുണ്ട്).

എന്നിരുന്നാലും, ഹെൽം 3 കോഡ്ബേസിലേക്ക് വെർഫ് മാറുന്നത് അനിവാര്യമാണ്, അത് സമീപഭാവിയിൽ സംഭവിക്കും. ഇത് വെർഫ് 1.1 അല്ലെങ്കിൽ വെർഫ് 1.2 ആയിരിക്കും (ഇപ്പോൾ, വെർഫിന്റെ പ്രധാന പതിപ്പ് 1.0 ആണ്; വെർഫ് പതിപ്പിംഗ് ഉപകരണത്തെക്കുറിച്ചുള്ള കൂടുതൽ വിവരങ്ങൾക്ക്, കാണുക ഇവിടെ). ഈ സമയത്ത്, ഹെൽം 3 ന് സ്ഥിരത കൈവരിക്കാൻ സമയമുണ്ടാകും.

പി.എസ്

ഞങ്ങളുടെ ബ്ലോഗിലും വായിക്കുക:

• വെർഫിലെ പുതുമകളെക്കുറിച്ചുള്ള കുറിപ്പുകളുടെ ഒരു പരമ്പര:
  • «സങ്കീർണ്ണമായ ഹെൽം ചാർട്ടുകൾ പുറത്തിറക്കാൻ വെർഫ് ഉപയോഗിക്കുന്നു";
  • «വെർഫിലെ മോണോറെപ്പോ, മൾട്ടിറെപ്പോ എന്നിവയ്ക്കുള്ള പിന്തുണയും ഡോക്കർ രജിസ്ട്രിയും ഇതുമായി എന്താണ് ചെയ്യേണ്ടത്";
  • «നിങ്ങൾക്ക് ഇപ്പോൾ ഒരു സാധാരണ ഡോക്കർ ഫയൽ ഉപയോഗിച്ച് വെർഫിൽ ഡോക്കർ ഇമേജുകൾ നിർമ്മിക്കാം".
• «werf - കുബർനെറ്റസിലെ CI / CD-യ്ക്കുള്ള ഞങ്ങളുടെ ഉപകരണം (അവലോകനവും വീഡിയോ റിപ്പോർട്ടും)";
• «werf, GitLab CI എന്നിവ ഉപയോഗിച്ച് ഒരേ തരത്തിലുള്ള മൈക്രോസർവീസുകൾ നിർമ്മിക്കുകയും വിന്യസിക്കുകയും ചെയ്യുക";
• «ഹെൽം 3 അവതരിപ്പിക്കുന്നു".

അവലംബം: www.habr.com