Yandex.Cloud साठी Kubernetes CCM (क्लाउड कंट्रोलर मॅनेजर) सादर करत आहे

अलीकडील सुरू ठेवत CSI ड्रायव्हर रिलीझ Yandex.Cloud साठी आम्ही या क्लाउडसाठी दुसरा मुक्त स्रोत प्रकल्प प्रकाशित करत आहोत - क्लाउड कंट्रोलर व्यवस्थापक. CCM केवळ संपूर्ण क्लस्टरसाठीच नाही तर CSI ड्रायव्हरसाठी देखील आवश्यक आहे. त्याच्या उद्देशाबद्दल तपशील आणि काही अंमलबजावणी वैशिष्ट्ये कट अंतर्गत आहेत.

परिचय

हे का?

ज्या हेतूने आम्हाला Yandex.Cloud साठी CCM विकसित करण्यास प्रवृत्त केले ते आधीच वर्णन केलेल्या हेतूंशी पूर्णपणे जुळतात. घोषणा CSI ड्रायव्हर्स. आम्ही वेगवेगळ्या क्लाउड प्रदात्यांकडून अनेक कुबर्नेट्स क्लस्टर्स राखतो, ज्यासाठी आम्ही एकच टूल वापरतो. हे या प्रदात्यांच्या व्यवस्थापित उपायांना "बायपास" करून असंख्य सोयी लागू करते. होय, आमच्याकडे एक विशिष्ट केस आणि गरजा आहेत, परंतु त्यांच्यामुळे तयार केलेले विकास इतर वापरकर्त्यांसाठी उपयुक्त असू शकतात.

CCM म्हणजे नक्की काय?

सामान्यतः, आपण आपल्या सभोवतालचे वातावरण क्लस्टरसाठी तयार करतो बाहेरून - उदाहरणार्थ, टेराफॉर्म वापरणे. परंतु कधीकधी आपल्या सभोवतालच्या ढगांचे वातावरण व्यवस्थापित करण्याची आवश्यकता असते क्लस्टर पासून. ही शक्यता प्रदान केली जाते आणि तीच अंमलात आणली जाते CCM.

विशेषतः, क्लाउड कंट्रोलर मॅनेजर पाच मुख्य प्रकारचे परस्परसंवाद प्रदान करतो:

1. उदाहरणे - कुबर्नेट्समधील नोड ऑब्जेक्ट दरम्यान 1:1 संबंध लागू करते (Node) आणि क्लाउड प्रदाता मध्ये एक आभासी मशीन. यासाठी आम्ही:
   • फील्ड भरा spec.providerID ऑब्जेक्ट मध्ये Node. उदाहरणार्थ, OpenStack CCM साठी या फील्डमध्ये खालील स्वरूप आहे: openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0. तुम्ही क्लाउड प्रदात्याचे नाव आणि ऑब्जेक्टचे सर्व्हरचे अद्वितीय UUID (ओपनस्टॅकमधील व्हर्च्युअल मशीन) पाहू शकता;
   • पूरक nodeInfo ऑब्जेक्ट मध्ये Node आभासी मशीन बद्दल माहिती. उदाहरणार्थ, आम्ही AWS मध्ये उदाहरण प्रकार निर्दिष्ट करतो;
   • आम्ही क्लाउडमध्ये व्हर्च्युअल मशीनची उपस्थिती तपासतो. उदाहरणार्थ, एखादी वस्तू असल्यास Node राज्यात गेले NotReady, तुम्ही क्लाउड प्रदात्यामध्ये व्हर्च्युअल मशीन अस्तित्वात आहे की नाही हे तपासू शकता providerID. ते नसल्यास, ऑब्जेक्ट हटवा Node, जे अन्यथा क्लस्टरमध्ये कायमचे राहील;
2. झोन - ऑब्जेक्टसाठी अपयश डोमेन सेट करते Node, जेणेकरुन शेड्युलर क्लाउड प्रदात्यामधील प्रदेश आणि झोननुसार पॉडसाठी नोड निवडू शकेल;
3. लोड बॅलन्सर - एखादी वस्तू तयार करताना Service प्रकारासह LoadBalancer एक प्रकारचा बॅलन्सर तयार करतो जो बाहेरून क्लस्टर नोड्सकडे रहदारी निर्देशित करेल. उदाहरणार्थ, Yandex.Cloud मध्ये आपण वापरू शकता NetworkLoadBalancer и TargetGroup या हेतूंसाठी;
4. मार्ग - नोड्स दरम्यान नेटवर्क तयार करते, कारण कुबर्नेट्सच्या आवश्यकतांनुसार, प्रत्येक पॉडचा स्वतःचा IP पत्ता असणे आवश्यक आहे आणि इतर कोणत्याही पॉडपर्यंत पोहोचण्यास सक्षम असणे आवश्यक आहे. या हेतूंसाठी, तुम्ही ओव्हरले नेटवर्क (VXLAN, GENEVE) वापरू शकता किंवा क्लाउड प्रदात्याच्या आभासी नेटवर्कमध्ये थेट राउटिंग टेबल सेट करू शकता:

   

5. खंड - PVC आणि SC वापरून PV च्या डायनॅमिक ऑर्डरिंगला अनुमती देते. सुरुवातीला, ही कार्यक्षमता CCM चा भाग होती, परंतु त्याच्या मोठ्या गुंतागुंतीमुळे ते कंटेनर स्टोरेज इंटरफेस (CSI) या वेगळ्या प्रकल्पात हलविण्यात आले. आम्ही CSI बद्दल एकापेक्षा जास्त वेळा बोललो आहोत लिहिले आणि, आधीच नमूद केल्याप्रमाणे, अगदी सोडले CSI चालक.

पूर्वी, क्लाउडशी संवाद साधणारे सर्व कोड कुबेरनेट प्रकल्पाच्या मुख्य गिट भांडारात स्थित होते. k8s.io/kubernetes/pkg/cloudprovider/providers, परंतु मोठ्या कोड बेससह काम करण्याच्या गैरसोयीमुळे त्यांनी हे सोडून देण्याचा निर्णय घेतला. सर्व जुनी अंमलबजावणी येथे हलविण्यात आली आहे स्वतंत्र भांडार. पुढील समर्थन आणि विकासाच्या सोयीसाठी, सर्व सामान्य घटक देखील येथे हलविले गेले स्वतंत्र भांडार.

CSI प्रमाणेच, अनेक मोठ्या क्लाउड प्रदात्यांनी त्यांचे CCM आधीच Kubernetes वर ढगांचा लाभ घेण्यासाठी डिझाइन केलेले आहेत. जर पुरवठादाराकडे CCM नसेल, परंतु सर्व आवश्यक कार्ये API द्वारे उपलब्ध असतील, तर तुम्ही स्वतः CCM लागू करू शकता.

CCM ची आपली स्वतःची अंमलबजावणी लिहिण्यासाठी, अंमलबजावणी करणे पुरेसे आहे आवश्यक गो इंटरफेस.

И हे आम्हाला मिळाले.

अंमलबजावणी

हे कसे आले

आम्ही विकास (किंवा त्याऐवजी, अगदी वापरणे) सुरू केले तयार(!) CCM Yandex.Cloud साठी एक वर्षापूर्वी.

तथापि, या अंमलबजावणीमध्ये आम्ही गहाळ होतो:

• JWT IAM टोकनद्वारे प्रमाणीकरण;
• सेवा नियंत्रक समर्थन.

लेखकाशी सहमत (dlisin) टेलीग्राममध्ये, आम्ही यांडेक्स-क्लाउड-कंट्रोलर-मॅनेजरला फोर्क केले आणि गहाळ कार्ये जोडली.

मुख्य वैशिष्ट्ये

सध्या, 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 पर्यंत वाढवण्याची योजना आहे. आम्ही सध्या मोठ्या आणि गंभीर K8 च्या स्थापनेसाठी CCM वापरण्याची शिफारस करत नाही.

सीएसआयच्या बाबतीत, यांडेक्स विकसकांनी या प्रकल्पाचा विकास आणि समर्थन घेतल्यास आम्हाला आनंद होईल - आमच्यासाठी अधिक संबंधित कार्ये हाताळण्यासाठी आम्ही त्यांच्या विनंतीनुसार भांडार हस्तांतरित करण्यास तयार आहोत.

PS

आमच्या ब्लॉगवर देखील वाचा:

• «Yandex.Cloud साठी Kubernetes मध्ये CSI ड्राइव्हर विकसित करण्याचा आमचा अनुभव";
• «कुबर्नेट्स क्लस्टर तयार करणे सोपे आणि सोयीचे आहे का? अॅडऑन-ऑपरेटरची घोषणा करत आहे";
• «कुबर्नेट्सचा विस्तार आणि पूरक (पुनरावलोकन आणि व्हिडिओ अहवाल)».

स्त्रोत: www.habr.com