ഒരു കണ്ടെയ്നർ വിന്യസിക്കുന്നത് ലളിതമാണ്. പത്ത് വിന്യസിക്കുന്നത് കൈകാര്യം ചെയ്യാൻ എളുപ്പമാണ്. എന്നാൽ ഡസൻ കണക്കിന് മെഷീനുകളിൽ നൂറുകണക്കിന് കണ്ടെയ്നറുകൾ പ്രവർത്തിപ്പിക്കുമ്പോൾ, മാനുവൽ മാനേജ്മെന്റ് പ്രയാസകരമാവുക മാത്രമല്ല, അസാധ്യമായി മാറുകയും ചെയ്യുന്നു. ഏത് കണ്ടെയ്നർ എവിടെയാണെന്ന് നിങ്ങൾക്ക് കണ്ടെത്താൻ കഴിയില്ല. ഒരു സെർവർ പ്രവർത്തനരഹിതമായാൽ, ആരെങ്കിലും അത് പുനരാരംഭിക്കുന്നത് വരെ നിങ്ങളുടെ ആപ്ലിക്കേഷൻ അപ്രത്യക്ഷമാകും. പുതിയ ഇൻസ്റ്റൻസുകൾ സജ്ജമാക്കുന്നതിന് മുമ്പ് തന്നെ ട്രാഫിക് വർദ്ധനവ് നിങ്ങളുടെ സംവിധാനത്തെ തളർത്തും. ഇവിടെയാണ് കുബർനെറ്റസ് (Kubernetes) പ്രസക്തമാകുന്നത്. ഇത് വെറുമൊരു DevOps ടൂൾ മാത്രമല്ല. ഇത് കണ്ടെയ്നർ മാനേജ്മെന്റിനെ ഒരു സ്ക്രിപ്റ്റിംഗ് വ്യായാമമായി കാണുന്നതിന് പകരം ഒരു കൺട്രോൾ പ്രോബ്ലം ആയി കാണുന്ന ഒരു ഓർക്കസ്ട്രേഷൻ ലെയറാണ്.
സ്ക്രിപ്റ്റുകൾ എപ്പോഴെങ്കിലും പരാജയപ്പെടുന്നത് എന്തുകൊണ്ട്
മിക്ക ടീമുകളും ഷെൽ സ്ക്രിപ്റ്റുകളോ അടിസ്ഥാന ഓട്ടോമേഷനോ ഉപയോഗിച്ചാണ് തുടങ്ങുന്നത്. ഇമേജുകൾ പൾ ചെയ്യാനും, കണ്ടെയ്നറുകൾ തുടങ്ങാനും, ലോഗുകൾ നിരീക്ഷിക്കാനും, പരാജയപ്പെട്ട പ്രോസസ്സുകൾ പുനരാരംഭിക്കാനും അവർ കമാൻഡുകൾ എഴുതുന്നു. ഒരു പ്രൂഫ് ഓഫ് കോൺസെപ്റ്റിന് (proof of concept) ഈ രീതി ഫലപ്രദമാണ്. എന്നാൽ യഥാർത്ഥ ലോകത്തെ ലോഡുകൾ വരുമ്പോൾ ഇത് തകരാറിലാകും. മൈക്രോസർവീസുകൾ വിവിധ ഹോസ്റ്റുകളിൽ പരസ്പരം ആശയവിനിമയം നടത്തുന്നു, പ്രത്യേക എൻവയോൺമെന്റ് വേരിയബിളുകളെ ആശ്രയിക്കുന്നു, കണ്ടെയ്നർ റീസ്റ്റാർട്ട് ചെയ്യുമ്പോഴും നിലനിൽക്കുന്ന പെർസിസ്റ്റന്റ് സ്റ്റോറേജ് ആവശ്യപ്പെടുന്നു, കൂടാതെ പതിപ്പുകൾക്കിടയിൽ (versions) സ്ഥിരമായ നെറ്റ്വർക്കിംഗ് പ്രതീക്ഷിക്കുന്നു. ഒരു വെർച്വൽ മെഷീൻ അപ്രത്യക്ഷമാകുമ്പോൾ ഒരു സ്ക്രിപ്റ്റിന് വർക്ക്ലോഡ് സ്വയമേവ പുനർക്രമീകരിക്കാൻ കഴിയില്ല. ക്രാഷ് ലൂപ്പിൽ കുടുങ്ങിക്കിടക്കുന്നവയെ ഒഴിവാക്കി, ആരോഗ്യകരമായ ഇൻസ്റ്റൻസുകൾക്കിടയിൽ നെറ്റ്വർക്ക് ട്രാഫിക് വിതരണം ചെയ്യാനും ഇതിന് കഴിയില്ല. ഈ തീരുമാനങ്ങൾ എടുക്കുന്നതിനുള്ള ഉത്തരവാദിത്തം ക്ലസ്റ്ററിന് തന്നെ നൽകിക്കൊണ്ട് കുബർനെറ്റസ് ഇത് പരിഹരിക്കുന്നു. നിങ്ങൾ എന്താണ് ആഗ്രഹിക്കുന്നത് എന്ന് വിവരിച്ചാൽ മതി, സിസ്റ്റം ആ അവസ്ഥ (state) നിരന്തരം നിലനിർത്തുന്നു.
ഇത് നിങ്ങൾക്ക് നൽകുന്ന മൂന്ന് കാര്യങ്ങൾ
മാനുവൽ രീതിയിലുള്ള പ്രശ്നപരിഹാരത്തിന് പകരം ഓട്ടോമേറ്റഡ് വിശ്വാസ്യത നൽകുന്ന മൂന്ന് പ്രധാന കഴിവുകൾ കുബർനെറ്റസ് വാഗ്ദാനം ചെയ്യുന്നു.
High availability എന്നാൽ നിങ്ങളുടെ ഇൻഫ്രാസ്ട്രക്ചറിന്റെ ഭാഗങ്ങൾ പരാജയപ്പെട്ടാലും നിങ്ങളുടെ ആപ്ലിക്കേഷനുകൾ ഓൺലൈനിൽ തന്നെയായിരിക്കും എന്നാണ് അർത്ഥം. ഒരു കണ്ടെയ്നർ ക്രാഷ് ആയാൽ, സെക്കൻഡുകൾക്കുള്ളിൽ കുബർനെറ്റസ് അത് മാറ്റിസ്ഥാപിക്കുന്നു. ഒരു വർക്കർ നോഡ് പൂർണ്ണമായും പ്രവർത്തനരഹിതമായാൽ, ഷെഡ്യൂളർ ആ മാറ്റം ശ്രദ്ധിക്കുകയും ബാധിക്കപ്പെട്ട വർക്ക്ലോഡുകളെ ക്ലസ്റ്ററിലെ മറ്റ് ആരോഗ്യകരമായ മെഷീനുകളിലേക്ക് മാറ്റുകയും ചെയ്യുന്നു. നിങ്ങൾ നിർവചിച്ച അവസ്ഥ (desired state) സിസ്റ്റം നിരന്തരം നിരീക്ഷിക്കുകയും മനുഷ്യ ഇടപെടലില്ലാതെ വ്യതിയാനങ്ങൾ തിരുത്തുകയും ചെയ്യുന്നു.
Scalability എന്നാൽ നിങ്ങളുടെ ഉപയോക്താക്കൾക്കൊപ്പം നിങ്ങളുടെ ആപ്ലിക്കേഷനുകളും വളരുന്നു എന്നാണ് അർത്ഥം. വെറും രണ്ട് മണിക്കൂർ നീളുന്ന ട്രാഫിക് പീക്കിനെ നേരിടാൻ മാത്രം ഇരുപത് സെർവറുകൾ സജ്ജമാക്കുന്നതിന് പകരം, CPU ഉപയോഗം അല്ലെങ്കിൽ റിക്വസ്റ്റ് ലേറ്റൻസി (request latency) പോലുള്ള പ്രധാനപ്പെട്ട മെട്രിക്സുകൾ നിങ്ങൾ നിർവചിക്കുന്നു. പരിധി ലംഘിക്കുമ്പോൾ കൂടുതൽ കണ്ടെയ്നർ ഇൻസ്റ്റൻസുകൾ ചേർക്കാൻ ക്ലസ്റ്ററിനെ അനുവദിക്കുന്നു. ആവശ്യം കുറയുമ്പോൾ റീപ്ലിക്ക (replica) എണ്ണം വീണ്ടും കുറയുന്നു. നിങ്ങൾക്ക് ആവശ്യമുള്ളപ്പോൾ, ആവശ്യമുള്ളത്ര മാത്രം നിങ്ങൾ പണം നൽകുന്നു.
Disaster recovery എന്നാൽ ഒരു ക്രാഷിന് ശേഷം നിങ്ങളുടെ ഡാറ്റയും കോൺഫിഗറേഷനും തിരികെ ലഭിക്കും എന്നാണ് അർത്ഥം. കുബർനെറ്റസ് ക്ലസ്റ്ററിന്റെ മുഴുവൻ അവസ്ഥയും ഒരു ഡിസ്ട്രിബ്യൂട്ടഡ് കീ-വാല്യൂ സ്റ്റോറിൽ (distributed key-value store) സൂക്ഷിക്കുന്നു. ഒരു വലിയ പരാജയം കാരണം വർക്കർ നോഡുകളോ അല്ലെങ്കിൽ കൺട്രോൾ പ്ലെയിനിന്റെ ഭാഗമോ നഷ്ടപ്പെട്ടാലും, ആ സ്റ്റോർ ചെയ്ത അവസ്ഥ ഉപയോഗിച്ച് നിങ്ങളുടെ വർക്ക്ലോഡുകളെ കൃത്യമായി പുനർനിർമ്മിക്കാൻ സിസ്റ്റത്തിന് കഴിയും. ഓർക്കസ്ട്രേറ്റർ എങ്ങനെയുള്ളതായിരിക്കണം എന്ന് ഓർമ്മിച്ചുവെക്കുന്നതിനാൽ നിങ്ങളുടെ ഡാറ്റ തിരികെ ലഭിക്കുന്നു.
സെറ്റപ്പ്: ബുദ്ധിയും കരുത്തും (Brains and Muscle)
ഒരു കുബർനെറ്റസ് ക്ലസ്റ്ററിന് രണ്ട് അടിസ്ഥാന റോളുകൾ ഉണ്ട്; അവയെ ബുദ്ധിയെന്നും (brain) കരുത്തെന്നും (muscle) വിശേഷിപ്പിക്കാം. ഈ ഉപമ പ്രായോഗികമായി വളരെ അനുയോജ്യമാണ്.
Master Node ആണ് ബുദ്ധി. ഇത് നിങ്ങളുടെ ഉപഭോക്താക്കൾ ഉപയോഗിക്കുന്ന ആപ്ലിക്കേഷനുകൾ പ്രവർത്തിപ്പിക്കുന്നില്ല. പകരം, ടാസ്ക്കുകൾ ഷെഡ്യൂൾ ചെയ്യാനും ക്ലസ്റ്റർ അവസ്ഥ നിയന്ത്രിക്കാനും മാറ്റങ്ങളോട് പ്രതികരിക്കാനും ആവശ്യമായ കൺട്രോൾ പ്ലെയിൻ ഘടകങ്ങൾ ഇത് ഹോസ്റ്റ് ചെയ്യുന്നു. നിങ്ങൾ ഒരു കമാൻഡ് നൽകുകയോ ഒരു കോൺഫിഗറേഷൻ ഫയൽ സമർപ്പിക്കുകയോ ചെയ്യുമ്പോൾ, വർക്ക്ലോഡ് എവിടെയായിരിക്കണം, അത് ആരോഗ്യകരമാണോ, അത് ശരിയല്ലെങ്കിൽ എന്തുചെയ്യണം എന്നിവ മാസ്റ്റർ നോഡ് തീരുമാനിക്കുന്നു.
Worker Nodes ആണ് കരുത്ത്. ഓരോ വർക്കറും മാസ്റ്ററുമായി ആശയവിനിമയം നടത്തുന്ന ഒരു ലൈറ്റ് വെയ്റ്റ് ഏജന്റിനെ പ്രവർത്തിപ്പിക്കുന്നു, കൂടാതെ യഥാർത്ഥ പോഡുകൾ (pods) പ്രവർത്തിപ്പിക്കാൻ ഒരു കണ്ടെയ്നർ റൺടൈം ഉപയോഗിക്കുന്നു. നിങ്ങളുടെ ആപ്ലിക്കേഷൻ കോഡ് CPU-വും മെമ്മറിയും ഉപയോഗിക്കുന്നത് ഈ നോഡുകളിലാണ്. കൂടുതൽ വർക്കർ നോഡുകൾ ചേർക്കുന്നതിലൂടെ നിങ്ങളുടെ ക്ലസ്റ്ററിന്റെ ശേഷി വർദ്ധിപ്പിക്കാം. റിഡൻഡൻസിക്ക് (redundancy) വേണ്ടി കൂടുതൽ മാസ്റ്റർ നോഡുകൾ ചേർക്കുന്നതിലൂടെ ഹാർഡ്വെയർ പരാജയങ്ങളെ പ്രതിരോധിക്കാൻ കൺട്രോൾ പ്ലെയിനിനെ പ്രാപ്തമാക്കാം.
പോഡുകൾ, കണ്ടെയ്നറുകൾ, സർവീസുകൾ
കുബർനെറ്റുമായി പ്രവർത്തിക്കാൻ, സോഫ്റ്റ്വെയർ എങ്ങനെ പാക്കേജ് ചെയ്യുന്നുവെന്നും എങ്ങനെ ലഭ്യമാക്കുന്നുവെന്നും നിർവചിക്കുന്ന മൂന്ന് പദങ്ങൾ നിങ്ങൾ മനസ്സിലാക്കേണ്ടതുണ്ട്.
Containers എന്നത് നിങ്ങളുടെ ആപ്ലിക്കേഷനും അതിന്റെ ഡിപെൻഡൻസികൾ (dependencies), ലൈബ്രറികൾ, കോൺഫിഗറേഷൻ എന്നിവയും ഒരുമിച്ച് പാക്കേജ് ചെയ്യുന്ന സംവിധാനമാണ്. ഇത് സോഫ്റ്റ്വെയറിനെ അടിസ്ഥാന ഹോസ്റ്റിൽ നിന്ന് വേർതിരിക്കുന്നു, അതിനാൽ ഡെവലപ്മെന്റ്, സ്റ്റേജിംഗ്, പ്രൊഡക്ഷൻ എന്നിവയിൽ ഒരേപോലെ പ്രവർത്തിക്കുന്നുവെന്ന് ഇത് ഉറപ്പാക്കുന്നു.
Pods ആണ് Kubernetes-ലെ ഏറ്റവും ചെറിയ വിന്യസിക്കാവുന്ന (deployable) യൂണിറ്റ്. വിഭവങ്ങൾ (resources) പങ്കിടേണ്ട ഒന്നോ അതിലധികമോ കണ്ടെയ്നറുകളെ ഒരു പോഡ് പൊതിയുന്നു. അവ ഒരേ നെറ്റ്വർക്ക് നെയിംസ്പേസും (network namespace) ഒരേ ലോക്കൽ സ്റ്റോറേജ് വോള്യങ്ങളും ഉപയോഗിക്കുന്നു. ഇത് പ്രധാനമാണ്: നിങ്ങൾ ഒരു കണ്ടെയ്നറിനെ നേരിട്ട് വിന്യസിക്കുന്നില്ല. പകരം അതിനെ ഉൾക്കൊള്ളുന്ന ഒരു പോഡ് ആണ് വിന്യസിക്കുന്നത്. പോഡുകൾ മനഃപൂർവ്വം താൽക്കാലികമായി (ephemeral) രൂപകൽപ്പന ചെയ്തവയാണ്. സാഹചര്യങ്ങൾ മാറുന്നതിനനുസരിച്ച് അവ നിർമ്മിക്കപ്പെടുകയും നശിപ്പിക്കപ്പെടുകയും മാറ്റപ്പെടുകയും ചെയ്യുന്നു. അവയുടെ ആയുസ്സ് രൂപകൽപ്പനയിൽ തന്നെ ഡൈനാമിക് ആണ്.
Services നിലനിൽക്കുന്നത് പോഡുകൾ താൽക്കാലികമായതുകൊണ്ടാണ് (transient). ഓരോ തവണ ഒരു പോഡ് റീസ്റ്റാർട്ട് ചെയ്യുമ്പോഴും അതിന് പുതിയൊരു ഇന്റേണൽ IP അഡ്രസ് ലഭിക്കാൻ സാധ്യതയുണ്ട്. നിങ്ങളുടെ ആപ്ലിക്കേഷന്റെ മറ്റ് ഭാഗങ്ങൾ ഈ മാറിക്കൊണ്ടിരിക്കുന്ന അഡ്രസുകളിലേക്ക് നേരിട്ട് ബന്ധപ്പെടാൻ ശ്രമിച്ചാൽ അവ നിരന്തരം തകരാറിലാകും. ഒരു സർവീസ് നിങ്ങളുടെ പോഡുകൾക്ക് സ്ഥിരമായ ഒരു IP അഡ്രസ്സും DNS പേരും നൽകുന്നു. ഇത് ഒരു സ്ഥിരമായ പ്രവേശന കവാടമായി (front door) പ്രവർത്തിക്കുകയും, അതിന്റെ സെലക്ടറിന് (selector) അനുയോജ്യമായ എല്ലാ ആരോഗ്യകരമായ പോഡുകളിലേക്കും വരുന്ന റിക്വസ്റ്റുകളെ ലോഡ്-ബാലൻസ് ചെയ്യുകയും ചെയ്യുന്നു. ഇത് ഓരോ കണ്ടെയ്നറുകളുടെയും ജീവിതചക്രത്തിലെ (life cycle) അനിശ്ചിതത്വങ്ങളിൽ നിന്ന് നിങ്ങളുടെ ക്ലയന്റുകളെ വേർപെടുത്തുന്നു.
വലിയ തോതിലുള്ള Kubernetes: നെറ്റ്ഫ്ലിക്സ് ഉദാഹരണം
നെറ്റ്ഫ്ലിക്സ് അതിന്റെ കണ്ടന്റ് ഡെലിവറി നെറ്റ്വർക്ക് (content delivery network) നിയന്ത്രിക്കാൻ Kubernetes ഉപയോഗിക്കുന്നു. ഈ ഇൻഫ്രാസ്ട്രക്ചർ ലോകമെമ്പാടുമുള്ള ദശലക്ഷക്കണക്കിന് കാഴ്ചക്കാർക്ക് ഒരേസമയം വീഡിയോ സ്ട്രീമുകൾ എത്തിക്കുന്നു. ഒരു പ്രശസ്തമായ ഷോ പുറത്തിറങ്ങുകയും ഡിമാൻഡ് വർദ്ധിക്കുകയും ചെയ്യുമ്പോൾ, ഉപയോക്താക്കൾക്ക് അടുത്തായി വീഡിയോ സെഗ്മെന്റുകൾ സംഭരിക്കുന്ന കാഷെ നോഡുകളെ (cache nodes) ക്ലസ്റ്റർ വിപുലീകരിക്കുന്നു (scales out). ഒരു റീജിയണൽ നോഡ് പരാജയപ്പെട്ടാൽ, ട്രാഫിക് സ്വയമേവ റീറൂട്ട് ചെയ്യപ്പെടുന്നു. ഇതിന്റെ ഫലമായി, ഒരു എഞ്ചിനീയർക്ക് അടിയന്തരമായി അറിയിപ്പ് നൽകേണ്ട ആവശ്യം ഇല്ലാതെ തന്നെ ദശലക്ഷക്കണക്കിന് ആളുകൾക്ക് സിനിമകൾ തടസ്സമില്ലാതെ കാണാൻ സാധിക്കുന്നു. ഓർക്കസ്ട്രേറ്റർ (orchestrator) ഈ വിപുലീകരണവും പരാജയങ്ങളും കൈകാര്യം ചെയ്യുന്നതിനാൽ സേവനം തടസ്സമില്ലാതെ തുടരുന്നു.
തുടക്കം: YAML, JSON, കൂടാതെ API Server
Kubernetes ഉപയോഗിച്ചു തുടങ്ങുക എന്നാൽ ഇംപറേറ്റീവ് ക്ലിക്ക്-ഓപ്സ് (imperative click-ops) ഉപേക്ഷിക്കുകയും ഡിക്ലറേറ്റീവ് കോൺഫിഗറേഷൻ (declarative configuration) സ്വീകരിക്കുകയും ചെയ്യുക എന്നാണ് അർത്ഥം. നിങ്ങൾക്ക് എന്താണോ വേണ്ടത് അത് YAML അല്ലെങ്കിൽ JSON ഫയലുകളിൽ നിങ്ങൾ എഴുതുന്നു. കണ്ടെയ്നർ ഇമേജ് മുതൽ റെപ്ലിക്കകളുടെ എണ്ണം, എക്സ്പോസ്ഡ് പോർട്ടുകൾ, എൻവയോൺമെന്റ് വേരിയബിളുകൾ, സ്റ്റോറേജ് മൗണ്ടുകൾ എന്നിവയെല്ലാം ഈ മാനിഫെസ്റ്റുകൾ (manifests) വിവരിക്കുന്നു. നിങ്ങളുടെ ഫയൽ തയ്യാറായുകഴിഞ്ഞാൽ, അത് മാസ്റ്റർ നോഡിലെ API സെർവറിലേക്ക് അയക്കുന്നു. കൺട്രോൾ പ്ലെയിൻ (control plane) ആ ഡിക്ലറേഷൻ സ്വീകരിക്കുകയും അത് ക്ലസ്റ്റർ സ്റ്റേറ്റ് ഡാറ്റാബേസിൽ സംഭരിക്കുകയും ചെയ്യുന്നു, തുടർന്ന് നിങ്ങളുടെ വിവരണത്തിന് അനുസൃതമായ രീതിയിൽ കാര്യങ്ങൾ നടപ്പിലാക്കാൻ തുടങ്ങുന്നു. അതിന്റെ ജോലി എങ്ങനെ ചെയ്യണമെന്ന് നിങ്ങൾ Kubernetes-നോട് കൃത്യമായി പറയുന്നില്ല. അന്തിമ ഫലം എന്തായിരിക്കണം എന്ന് നിങ്ങൾ പറയുന്നു, അത് ചെയ്യേണ്ട ഘട്ടങ്ങൾ അത് സ്വയം കണ്ടെത്തുന്നു.
യഥാർത്ഥ നേട്ടം
Kubernetes പഠിച്ചെടുക്കാൻ സമയമെടുക്കും. തുടക്കത്തിൽ ഇതിലെ പദാവലികൾ (terminology) സങ്കീർണ്ണമായി തോന്നാം. ഇതിൽ നിരവധി ഘടകങ്ങളുണ്ട്, കൂടാതെ ഒരു ഡിസ്ട്രിബ്യൂട്ടഡ് സിസ്റ്റം (distributed system) ഡിബഗ് ചെയ്യുന്നത് ഒരു സിംഗിൾ സെർവറിനേക്കാൾ പ്രയാസകരമാണ്. എന്നാൽ ഇതിന്റെ ഫലം പ്രവർത്തനപരമായ സമാധാനമാണ് (operational calm). നിങ്ങൾ ഓരോ മെഷീനുകളെയും പ്രത്യേകം ശ്രദ്ധിക്കേണ്ടി വരുന്നില്ല. പുലർച്ചെ 3 മണിക്ക് ഉണ്ടാകുന്ന തകരാറുകളിൽ സ്റ്റാർട്ടപ്പ് സ്ക്രിപ്റ്റുകൾ പ്രവർത്തിക്കുമെന്ന് നിങ്ങൾ പ്രാർത്ഥിക്കേണ്ടി വരുന്നില്ല. നോഡുകൾ പരാജയപ്പെട്ടേക്കാം എന്ന് മുൻകൂട്ടി കണ്ട്, പരാജയങ്ങളെ നേരിടാൻ പാകത്തിൽ ഡിസൈൻ ചെയ്യാൻ നിങ്ങൾ തുടങ്ങുന്നു, കൂടാതെ നിങ്ങളുടെ ആപ്ലിക്കേഷൻ സുരക്ഷിതമായി നിലനിർത്താൻ ഓർക്കസ്ട്രേറ്ററെ വിശ്വസിക്കുകയും ചെയ്യുന്നു. ഒന്നും തകരാറിലാകാതിരിക്കാൻ പ്രത്യാശിക്കുന്നതിൽ നിന്ന്, തകരാറുകൾ കൈകാര്യം ചെയ്യാൻ സിസ്റ്റത്തിന് കഴിയുമെന്ന് ഉറപ്പിച്ചു പറയുന്നതിലേക്കുള്ള ആ മാനസികാവസ്ഥാ മാറ്റമാണ് ഈ പരിശ്രമത്തെ അർത്ഥവത്താക്കുന്നത്.
Source: What Is Kubernetes? Kubernetes Explained in 15 Mins
Optional learning community: GyaanSetu AI on Telegram