Yandex.Cloud-നായി Kubernetes CCM (ക്ലൗഡ് കൺട്രോളർ മാനേജർ) അവതരിപ്പിക്കുന്നു

സമീപകാലത്തിന്റെ തുടർച്ചയായി CSI ഡ്രൈവർ റിലീസ് Yandex.Cloud-നായി ഞങ്ങൾ ഈ ക്ലൗഡിനായി മറ്റൊരു ഓപ്പൺ സോഴ്സ് പ്രോജക്റ്റ് പ്രസിദ്ധീകരിക്കുന്നു - ക്ലൗഡ് കൺട്രോളർ മാനേജർ. ക്ലസ്റ്ററിന് മൊത്തത്തിൽ മാത്രമല്ല, CSI ഡ്രൈവർക്കും CCM ആവശ്യമാണ്. ഇതിന്റെ ഉദ്ദേശ്യവും ചില നടപ്പാക്കൽ സവിശേഷതകളും വെട്ടിക്കുറച്ചിരിക്കുന്നു.

ആമുഖം

ഇതെന്തുകൊണ്ടാണ്?

Yandex.Cloud-നായി CCM വികസിപ്പിക്കാൻ ഞങ്ങളെ പ്രേരിപ്പിച്ച ഉദ്ദേശ്യങ്ങൾ ഇതിനകം വിവരിച്ചിരിക്കുന്നവയുമായി പൂർണ്ണമായും പൊരുത്തപ്പെടുന്നു. പ്രഖ്യാപനം CSI ഡ്രൈവർമാർ. വ്യത്യസ്‌ത ക്ലൗഡ് ദാതാക്കളിൽ നിന്നുള്ള നിരവധി കുബർനെറ്റസ് ക്ലസ്റ്ററുകൾ ഞങ്ങൾ പരിപാലിക്കുന്നു, അതിനായി ഞങ്ങൾ ഒരൊറ്റ ടൂൾ ഉപയോഗിക്കുന്നു. ഈ ദാതാക്കളുടെ നിയന്ത്രിത പരിഹാരങ്ങളെ "ബൈപാസ്" ചെയ്യുന്ന നിരവധി സൗകര്യങ്ങൾ ഇത് നടപ്പിലാക്കുന്നു. അതെ, ഞങ്ങൾക്ക് ഒരു പ്രത്യേക കേസും ആവശ്യങ്ങളും ഉണ്ട്, എന്നാൽ അവ കാരണം സൃഷ്ടിക്കപ്പെട്ട സംഭവവികാസങ്ങൾ മറ്റ് ഉപയോക്താക്കൾക്ക് ഉപയോഗപ്രദമാകും.

എന്താണ് യഥാർത്ഥത്തിൽ CCM?

സാധാരണഗതിയിൽ, ക്ലസ്റ്ററിനായി നമുക്ക് ചുറ്റുമുള്ള പരിസ്ഥിതി ഞങ്ങൾ തയ്യാറാക്കുന്നു പുറത്തുനിന്നും - ഉദാഹരണത്തിന്, Terraform ഉപയോഗിച്ച്. എന്നാൽ ചിലപ്പോൾ നമുക്ക് ചുറ്റുമുള്ള ക്ലൗഡ് പരിസ്ഥിതി കൈകാര്യം ചെയ്യേണ്ടത് ആവശ്യമാണ് ക്ലസ്റ്ററിൽ നിന്ന്. ഈ സാധ്യതയാണ് നൽകിയിരിക്കുന്നത്, അത് നടപ്പിലാക്കുന്നത് അതാണ് വേണമെങ്കില്.

പ്രത്യേകിച്ചും, ക്ലൗഡ് കൺട്രോളർ മാനേജർ അഞ്ച് പ്രധാന തരത്തിലുള്ള ഇടപെടലുകൾ നൽകുന്നു:

1. അവസരങ്ങൾ - കുബർനെറ്റസിലെ ഒരു നോഡ് ഒബ്‌ജക്‌റ്റ് തമ്മിലുള്ള 1:1 ബന്ധം നടപ്പിലാക്കുന്നു (Node) കൂടാതെ ക്ലൗഡ് പ്രൊവൈഡറിൽ ഒരു വെർച്വൽ മെഷീനും. ഇതിനായി ഞങ്ങൾ:
   • ഫീൽഡിൽ പൂരിപ്പിക്കുക spec.providerID വസ്തുവിൽ Node. ഉദാഹരണത്തിന്, OpenStack CCM-ന് ഈ ഫീൽഡിന് ഇനിപ്പറയുന്ന ഫോർമാറ്റ് ഉണ്ട്: openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0. ക്ലൗഡ് ദാതാവിന്റെ പേരും ഒബ്‌ജക്‌റ്റിന്റെ സെർവറിന്റെ (ഓപ്പൺസ്റ്റാക്കിലെ വെർച്വൽ മെഷീൻ) തനതായ യുയുഐഡിയും നിങ്ങൾക്ക് കാണാൻ കഴിയും;
   • പൂരകമാണ് nodeInfo വസ്തുവിൽ Node വെർച്വൽ മെഷീനെക്കുറിച്ചുള്ള വിവരങ്ങൾ. ഉദാഹരണത്തിന്, ഞങ്ങൾ AWS-ൽ ഉദാഹരണ തരം വ്യക്തമാക്കുന്നു;
   • ക്ലൗഡിൽ ഒരു വെർച്വൽ മെഷീന്റെ സാന്നിധ്യം ഞങ്ങൾ പരിശോധിക്കുന്നു. ഉദാഹരണത്തിന്, ഒരു വസ്തുവാണെങ്കിൽ Node ഒരു അവസ്ഥയിലേക്ക് പോയി NotReady, ക്ലൗഡ് ദാതാവിൽ വെർച്വൽ മെഷീൻ നിലവിലുണ്ടോ എന്ന് നിങ്ങൾക്ക് പരിശോധിക്കാം providerID. അത് ഇല്ലെങ്കിൽ, ഒബ്ജക്റ്റ് ഇല്ലാതാക്കുക Node, അല്ലെങ്കിൽ അത് ക്ലസ്റ്ററിൽ എന്നേക്കും നിലനിൽക്കും;
2. മേഘലകൾ - ഒബ്ജക്റ്റിനായി പരാജയ ഡൊമെയ്ൻ സജ്ജമാക്കുന്നു Node, ക്ലൗഡ് പ്രൊവൈഡറിലെ പ്രദേശങ്ങളും സോണുകളും അനുസരിച്ച് ഷെഡ്യൂളർക്ക് പോഡിനായി ഒരു നോഡ് തിരഞ്ഞെടുക്കാനാകും;
3. ലോഡ്ബാലൻസർ - ഒരു വസ്തു സൃഷ്ടിക്കുമ്പോൾ Service തരം ഉപയോഗിച്ച് LoadBalancer പുറത്ത് നിന്ന് ക്ലസ്റ്റർ നോഡുകളിലേക്ക് ട്രാഫിക്കിനെ നയിക്കുന്ന ഒരു തരം ബാലൻസർ സൃഷ്ടിക്കുന്നു. ഉദാഹരണത്തിന്, Yandex.Cloud-ൽ നിങ്ങൾക്ക് ഉപയോഗിക്കാം NetworkLoadBalancer и TargetGroup ഈ ആവശ്യങ്ങൾക്ക്;
4. വഴി - നോഡുകൾക്കിടയിൽ ഒരു നെറ്റ്‌വർക്ക് നിർമ്മിക്കുന്നു, കാരണം Kubernetes ആവശ്യകതകൾ അനുസരിച്ച്, ഓരോ പോഡിനും അതിന്റേതായ IP വിലാസം ഉണ്ടായിരിക്കുകയും മറ്റേതെങ്കിലും പോഡിൽ എത്താൻ കഴിയുകയും വേണം. ഈ ആവശ്യങ്ങൾക്ക്, നിങ്ങൾക്ക് ഒരു ഓവർലേ നെറ്റ്‌വർക്ക് (VXLAN, GENEVE) ഉപയോഗിക്കാം അല്ലെങ്കിൽ ക്ലൗഡ് ദാതാവിന്റെ വെർച്വൽ നെറ്റ്‌വർക്കിൽ നേരിട്ട് ഒരു റൂട്ടിംഗ് ടേബിൾ സജ്ജമാക്കാം:

   

5. അളവ് - പിവിസിയും എസ്‌സിയും ഉപയോഗിച്ച് പിവിയുടെ ഡൈനാമിക് ഓർഡറിംഗ് അനുവദിക്കുന്നു. തുടക്കത്തിൽ, ഈ പ്രവർത്തനം CCM-ന്റെ ഭാഗമായിരുന്നു, എന്നാൽ അതിന്റെ വലിയ സങ്കീർണ്ണത കാരണം ഇത് ഒരു പ്രത്യേക പ്രോജക്റ്റിലേക്ക് മാറ്റി, കണ്ടെയ്നർ സ്റ്റോറേജ് ഇന്റർഫേസ് (CSI). ഞങ്ങൾ ഒന്നിലധികം തവണ സിഎസ്ഐയെക്കുറിച്ച് സംസാരിച്ചു എഴുതി കൂടാതെ, ഇതിനകം സൂചിപ്പിച്ചതുപോലെ, പോലും പുറത്തിറക്കി സിഎസ്ഐ ഡ്രൈവർ.

മുമ്പ്, ക്ലൗഡുമായി സംവദിക്കുന്ന എല്ലാ കോഡുകളും കുബെർനെറ്റസ് പ്രോജക്റ്റിന്റെ പ്രധാന Git ശേഖരത്തിലാണ് സ്ഥിതി ചെയ്യുന്നത്. k8s.io/kubernetes/pkg/cloudprovider/providers, എന്നാൽ ഒരു വലിയ കോഡ് ബേസ് ഉപയോഗിച്ച് പ്രവർത്തിക്കാനുള്ള അസൗകര്യം കാരണം അവർ ഇത് ഉപേക്ഷിക്കാൻ തീരുമാനിച്ചു. പഴയ നടപ്പാക്കലുകളെല്ലാം മാറ്റി പ്രത്യേക ശേഖരം. കൂടുതൽ പിന്തുണയുടെയും വികസനത്തിന്റെയും സൗകര്യാർത്ഥം, എല്ലാ പൊതു ഘടകങ്ങളും നീക്കി പ്രത്യേക ശേഖരം.

സി‌എസ്‌ഐ പോലെ, നിരവധി വലിയ ക്ലൗഡ് ദാതാക്കളും കുബെർനെറ്റുകളിൽ ക്ലൗഡുകൾ പ്രയോജനപ്പെടുത്തുന്നതിന് അവരുടെ സിസിഎമ്മുകൾ ഇതിനകം രൂപകൽപ്പന ചെയ്തിട്ടുണ്ട്. വിതരണക്കാരന് CCM ഇല്ലെങ്കിലും ആവശ്യമായ എല്ലാ പ്രവർത്തനങ്ങളും API വഴി ലഭ്യമാണെങ്കിൽ, നിങ്ങൾക്ക് സ്വയം CCM നടപ്പിലാക്കാൻ കഴിയും.

CCM-ന്റെ സ്വന്തം നടപ്പാക്കൽ എഴുതാൻ, അത് നടപ്പിലാക്കിയാൽ മതി ആവശ്യമായ Go ഇന്റർഫേസുകൾ.

И ഇതാണ് ഞങ്ങൾക്ക് ലഭിച്ചത്.

നടപ്പാക്കൽ

നീ എങ്ങനെ ഇതിലേക്ക് വന്നു

ഞങ്ങൾ വികസനം ആരംഭിച്ചു (അല്ലെങ്കിൽ പകരം, ഉപയോഗിക്കാൻ പോലും). തയ്യാറാണ്(!) CCM ഒരു വർഷം മുമ്പ് Yandex.Cloud-നായി.

എന്നിരുന്നാലും, ഈ നടപ്പാക്കലിൽ ഞങ്ങൾക്ക് നഷ്‌ടമായി:

• JWT IAM ടോക്കൺ വഴിയുള്ള പ്രാമാണീകരണം;
• സേവന കൺട്രോളർ പിന്തുണ.

രചയിതാവുമായി ധാരണയിൽ (dlisin) ടെലിഗ്രാമിൽ, ഞങ്ങൾ yandex-Cloud-controller-manager ഫോർക്ക് ചെയ്‌ത് നഷ്‌ടമായ ഫംഗ്‌ഷനുകൾ ചേർത്തു.

പ്രധാന സവിശേഷതകൾ

നിലവിൽ, CCM ഇനിപ്പറയുന്ന ഇന്റർഫേസുകളെ പിന്തുണയ്ക്കുന്നു:

• അവസരങ്ങൾ;
• മേഘലകൾ;
• ലോഡ്ബാലൻസർ.

ഭാവിയിൽ, Yandex.Cloud വിപുലമായ VPC കഴിവുകൾ ഉപയോഗിച്ച് പ്രവർത്തിക്കാൻ തുടങ്ങുമ്പോൾ, ഞങ്ങൾ ഒരു ഇന്റർഫേസ് ചേർക്കും വഴികൾ.

LoadBalanacer പ്രധാന വെല്ലുവിളിയായി

തുടക്കത്തിൽ, മറ്റ് CCM നടപ്പിലാക്കലുകൾ പോലെ, ഒരു ജോടി സൃഷ്ടിക്കാൻ ഞങ്ങൾ ശ്രമിച്ചു LoadBalancer и TargetGroup ഏവർക്കുമായി Service തരം ഉപയോഗിച്ച് LoadBalancer. എന്നിരുന്നാലും, Yandex.Cloud രസകരമായ ഒരു പരിമിതി കണ്ടെത്തി: നിങ്ങൾക്ക് ഉപയോഗിക്കാൻ കഴിയില്ല TargetGroups വിഭജിക്കുന്ന കൂടെ Targets (ജോഡി SubnetID - IpAddress).

അതിനാൽ, സൃഷ്ടിച്ച സിസിഎമ്മിനുള്ളിൽ, ഒരു കൺട്രോളർ സമാരംഭിക്കുന്നു, അത് വസ്തുക്കൾ മാറുമ്പോൾ Node ഓരോ വെർച്വൽ മെഷീനിലെയും എല്ലാ ഇന്റർഫേസുകളെയും കുറിച്ചുള്ള വിവരങ്ങൾ ശേഖരിക്കുന്നു, അവ ചിലത് അനുസരിച്ച് ഗ്രൂപ്പുചെയ്യുന്നു NetworkID, സൃഷ്ടിക്കുന്നു TargetGroup ഓൺ NetworkID, കൂടാതെ പ്രസക്തി നിരീക്ഷിക്കുന്നു. തുടർന്ന്, ഒരു വസ്തു സൃഷ്ടിക്കുമ്പോൾ Service തരം ഉപയോഗിച്ച് LoadBalanacer ഞങ്ങൾ മുൻകൂട്ടി സൃഷ്ടിച്ചത് അറ്റാച്ചുചെയ്യുന്നു TargetGroup പുതിയതിലേക്ക് NetworkLoadBalanacer'ആം.

എങ്ങനെ ഉപയോഗിക്കാൻ തുടങ്ങും?

CCM Kubernetes പതിപ്പ് 1.15-ഉം അതിലും ഉയർന്നതും പിന്തുണയ്ക്കുന്നു. ഒരു ക്ലസ്റ്ററിൽ, അത് പ്രവർത്തിക്കുന്നതിന്, അതിന് ഫ്ലാഗ് ആവശ്യമാണ് --cloud-provider=external ആയി നിശ്ചയിച്ചിരുന്നു true kube-apiserver, kube-controller-manager, kube-scheduler, എല്ലാ kubelets-നും.

ഇൻസ്റ്റാളേഷനായി ആവശ്യമായ എല്ലാ ഘട്ടങ്ങളും വിവരിച്ചിരിക്കുന്നു വായിക്കുക. മാനിഫെസ്റ്റുകളിൽ നിന്ന് കുബർനെറ്റസിൽ ഒബ്‌ജക്‌റ്റുകൾ സൃഷ്‌ടിക്കുന്നതിലേക്ക് ഇൻസ്റ്റാളേഷൻ തിളച്ചുമറിയുന്നു.

CCM ഉപയോഗിക്കുന്നതിന് നിങ്ങൾക്ക് ഇവയും ആവശ്യമാണ്:

• സൂചിപ്പിക്കുക മാനിഫെസ്റ്റിൽ ഡയറക്‌ടറി ഐഡന്റിഫയർ (folder-id) Yandex.Cloud;
• Yandex.Cloud API-യുമായി സംവദിക്കുന്നതിനുള്ള സേവന അക്കൗണ്ട്. പ്രകടനപത്രികയിൽ Secret ആവശ്യമാണ് അംഗീകൃത കീകൾ കൈമാറുക സേവന അക്കൗണ്ടിൽ നിന്ന്. ഡോക്യുമെന്റേഷനിൽ വിവരിച്ചു, എങ്ങനെ ഒരു സേവന അക്കൗണ്ട് സൃഷ്ടിക്കുകയും കീകൾ നേടുകയും ചെയ്യാം.

നിങ്ങളുടെ ഫീഡ്‌ബാക്ക് ലഭിക്കുന്നതിൽ ഞങ്ങൾ സന്തുഷ്ടരാണ് പുതിയ പ്രശ്നങ്ങൾനിങ്ങൾക്ക് എന്തെങ്കിലും പ്രശ്നങ്ങൾ നേരിടുകയാണെങ്കിൽ!

ഫലങ്ങൾ

കഴിഞ്ഞ രണ്ടാഴ്ചയായി അഞ്ച് കുബർനെറ്റസ് ക്ലസ്റ്ററുകളിൽ ഞങ്ങൾ നടപ്പിലാക്കിയ CCM ഉപയോഗിക്കുന്നു, വരും മാസത്തിൽ അവയുടെ എണ്ണം 20 ആയി വികസിപ്പിക്കാൻ പദ്ധതിയിടുന്നു. വലുതും നിർണായകവുമായ K8s ഇൻസ്റ്റാളേഷനുകൾക്കായി CCM ഉപയോഗിക്കാൻ ഞങ്ങൾ നിലവിൽ ശുപാർശ ചെയ്യുന്നില്ല.

സി‌എസ്‌ഐയുടെ കാര്യത്തിലെന്നപോലെ, ഈ പ്രോജക്റ്റിന്റെ വികസനവും പിന്തുണയും Yandex ഡവലപ്പർമാർ ഏറ്റെടുക്കുകയാണെങ്കിൽ ഞങ്ങൾ സന്തോഷിക്കും - ഞങ്ങൾക്ക് കൂടുതൽ പ്രസക്തമായ ജോലികൾ കൈകാര്യം ചെയ്യുന്നതിനായി അവരുടെ അഭ്യർത്ഥനപ്രകാരം ശേഖരം കൈമാറാൻ ഞങ്ങൾ തയ്യാറാണ്.

പി.എസ്

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

• «Yandex.Cloud-നായി കുബർനെറ്റസിൽ ഒരു CSI ഡ്രൈവർ വികസിപ്പിക്കുന്നതിൽ ഞങ്ങളുടെ അനുഭവം";
• «ഒരു കുബർനെറ്റസ് ക്ലസ്റ്റർ തയ്യാറാക്കുന്നത് എളുപ്പവും സൗകര്യപ്രദവുമാണോ? ആഡ്-ഓപ്പറേറ്റർ പ്രഖ്യാപിക്കുന്നു";
• «കുബർനെറ്റസ് വികസിപ്പിക്കുകയും പൂരകമാക്കുകയും ചെയ്യുക (അവലോകനവും വീഡിയോ റിപ്പോർട്ടും)".

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