Ipinapakilala ang Kubernetes CCM (Cloud Controller Manager) para sa Yandex.Cloud

Sa pagpapatuloy sa kamakailang Paglabas ng driver ng CSI para sa Yandex.Cloud naglalathala kami ng isa pang Open Source na proyekto para sa cloud na ito - Tagapamahala ng Cloud Controller. Kinakailangan ang CCM hindi lamang para sa cluster sa kabuuan, kundi pati na rin para sa driver ng CSI mismo. Ang mga detalye tungkol sa layunin nito at ilang tampok sa pagpapatupad ay nasa ilalim ng hiwa.

Pagpapakilala

Bakit ito?

Ang mga motibo na nag-udyok sa amin na bumuo ng CCM para sa Yandex.Cloud ay ganap na tumutugma sa mga inilarawan na sa anunsyo Mga driver ng CSI. Nagpapanatili kami ng maraming Kubernetes cluster mula sa iba't ibang cloud provider, kung saan gumagamit kami ng iisang tool. Nagpapatupad ito ng maraming kaginhawahan na "pag-bypass" sa mga pinamamahalaang solusyon ng mga provider na ito. Oo, mayroon kaming isang partikular na kaso at pangangailangan, ngunit ang mga pag-unlad na ginawa dahil sa mga ito ay maaaring maging kapaki-pakinabang sa ibang mga gumagamit.

Ano nga ba ang CCM?

Karaniwan, inihahanda natin ang kapaligiran sa ating paligid para sa kumpol mula sa labas - halimbawa, gamit ang Terraform. Ngunit kung minsan ay may pangangailangan na pamahalaan ang kapaligiran ng ulap sa paligid natin mula sa kumpol. Ang posibilidad na ito ay ibinigay, at ito ang ipinatupad CCM.

Sa partikular, ang Cloud Controller Manager ay nagbibigay ng limang pangunahing uri ng pakikipag-ugnayan:

1. Halimbawa – nagpapatupad ng 1:1 na relasyon sa pagitan ng node object sa Kubernetes (Node) at isang virtual machine sa cloud provider. Para dito kami:
   • punan ang patlang spec.providerID sa bagay Node. Halimbawa, para sa OpenStack CCM ang field na ito ay may sumusunod na format: openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0. Makikita mo ang pangalan ng cloud provider at ang natatanging UUID ng server (virtual machine sa OpenStack) ng object;
   • pandagdag nodeInfo sa bagay Node impormasyon tungkol sa virtual machine. Halimbawa, tinukoy namin ang uri ng instance sa AWS;
   • Sinusuri namin ang presensya ng isang virtual machine sa cloud. Halimbawa, kung ang isang bagay Node napunta sa isang estado NotReady, maaari mong suriin kung umiiral ang virtual machine sa cloud provider sa pamamagitan ng providerID. Kung wala ito doon, tanggalin ang bagay Node, na kung hindi man ay mananatili sa kumpol magpakailanman;
2. zone – nagtatakda ng domain ng kabiguan para sa bagay Nodeupang ang scheduler ay makapili ng node para sa Pod ayon sa mga rehiyon at zone sa cloud provider;
3. LoadBalancer – kapag lumilikha ng isang bagay Service may uri LoadBalancer lumilikha ng isang uri ng balancer na magdidirekta ng trapiko mula sa labas patungo sa mga cluster node. Halimbawa, sa Yandex.Cloud maaari mong gamitin NetworkLoadBalancer и TargetGroup para sa mga layuning ito;
4. Ruta – bubuo ng network sa pagitan ng mga node, dahil Ayon sa mga kinakailangan ng Kubernetes, ang bawat pod ay dapat magkaroon ng sarili nitong IP address at maabot ang anumang iba pang pod. Para sa mga layuning ito, maaari kang gumamit ng overlay network (VXLAN, GENEVE) o magtakda ng routing table nang direkta sa virtual network ng cloud provider:

   

5. Dami – Pinapayagan ang dynamic na pag-order ng PV gamit ang PVC at SC. Sa una, ang functionality na ito ay bahagi ng CCM, ngunit dahil sa sobrang kumplikado nito ay inilipat ito sa isang hiwalay na proyekto, Container Storage Interface (CSI). Napag-usapan namin ang tungkol sa CSI nang higit sa isang beses nagsulat at, gaya ng nabanggit na, kahit na pinakawalan driver ng CSI.

Dati, lahat ng code na nakikipag-ugnayan sa cloud ay matatagpuan sa pangunahing Git repository ng proyekto ng Kubernetes sa k8s.io/kubernetes/pkg/cloudprovider/providers, ngunit nagpasya silang iwanan ito dahil sa abala ng pagtatrabaho sa isang malaking base ng code. Ang lahat ng mga lumang pagpapatupad ay inilipat sa hiwalay na imbakan. Para sa kaginhawahan ng karagdagang suporta at pag-unlad, ang lahat ng mga karaniwang bahagi ay inilipat din sa hiwalay na imbakan.

Tulad ng sa CSI, maraming malalaking cloud provider ang nagdisenyo na ng kanilang mga CCM para magamit ang mga ulap sa Kubernetes. Kung ang supplier ay walang CCM, ngunit ang lahat ng mga kinakailangang function ay magagamit sa pamamagitan ng API, pagkatapos ay maaari mong ipatupad ang CCM sa iyong sarili.

Upang magsulat ng iyong sariling pagpapatupad ng CCM, ito ay sapat na upang ipatupad kinakailangang mga interface ng Go.

И ito ang nakuha namin.

Pagpapatupad

Paano ka napunta sa ganito

Sinimulan namin ang pag-unlad (o sa halip, kahit na gamitin) sa handa(!) CCM para sa Yandex.Cloud isang taon na ang nakalipas.

Gayunpaman, sa pagpapatupad na ito kami ay nawawala:

• pagpapatunay sa pamamagitan ng JWT IAM token;
• Suporta sa controller ng serbisyo.

Sang-ayon sa may-akda (dlisin) sa Telegram, na-forked namin ang yandex-cloud-controller-manager at idinagdag ang mga nawawalang function.

Pangunahing mga tampok

Sa kasalukuyan, sinusuportahan ng CCM ang mga sumusunod na interface:

• Halimbawa;
• zone;
• LoadBalancer.

Sa hinaharap, kapag nagsimulang magtrabaho ang Yandex.Cloud sa mga advanced na kakayahan ng VPC, magdaragdag kami ng interface ruta.

LoadBalanacer bilang pangunahing hamon

Sa una, sinubukan namin, tulad ng iba pang mga pagpapatupad ng CCM, upang lumikha ng isang pares ng LoadBalancer и TargetGroup para sa lahat Service may uri LoadBalancer. Gayunpaman, natuklasan ng Yandex.Cloud ang isang kawili-wiling limitasyon: hindi mo magagamit TargetGroups may intersecting Targets (pares SubnetID - IpAddress).

Samakatuwid, sa loob ng nilikha na CCM, ang isang controller ay inilunsad, na, kapag nagbago ang mga bagay Node nangongolekta ng impormasyon tungkol sa lahat ng mga interface sa bawat virtual machine, pinapangkat ang mga ito ayon sa kanilang pag-aari sa tiyak NetworkID, nilikha ni TargetGroup sa NetworkID, at sinusubaybayan din ang kaugnayan. Kasunod nito, kapag lumilikha ng isang bagay Service may uri LoadBalanacer nag-attach lang kami ng pre-created TargetGroup sa bago NetworkLoadBalanacer'am.

Paano simulan ang paggamit nito?

Sinusuportahan ng CCM ang bersyon 1.15 at mas mataas ng Kubernetes. Sa isang kumpol, para gumana ito, kailangan nito ang bandila --cloud-provider=external ay nakatakda sa true para sa kube-apiserver, kube-controller-manager, kube-scheduler at lahat ng kubelets.

Ang lahat ng kinakailangang hakbang para sa pag-install mismo ay inilarawan sa README. Nagsisimula ang pag-install sa paggawa ng mga bagay sa Kubernetes mula sa mga manifest.

Upang magamit ang CCM kakailanganin mo rin:

• ituro sa manifest ang directory identifier (folder-id) Yandex.Cloud;
• service account para sa pakikipag-ugnayan sa Yandex.Cloud API. Sa manifesto Secret dapat ilipat ang mga awtorisadong susi mula sa account ng serbisyo. Sa dokumentasyon inilarawan, kung paano gumawa ng account ng serbisyo at kumuha ng mga susi.

Ikalulugod naming matanggap ang iyong feedback at mga bagong isyukung nakatagpo ka ng anumang mga problema!

Mga resulta ng

Ginagamit namin ang ipinatupad na CCM sa limang kumpol ng Kubernetes sa nakalipas na dalawang linggo at plano naming palawakin ang kanilang bilang sa 20 sa darating na buwan. Sa kasalukuyan, hindi namin inirerekomenda ang paggamit ng CCM para sa malaki at kritikal na mga pag-install ng K8.

Tulad ng kaso ng CSI, matutuwa kami kung gagawin ng mga developer ng Yandex ang pagbuo at suporta ng proyektong ito - handa kaming ilipat ang repositoryo sa kanilang kahilingan upang harapin ang mga gawain na mas nauugnay sa amin.

PS

Basahin din sa aming blog:

• «Ang aming karanasan sa pagbuo ng isang CSI driver sa Kubernetes para sa Yandex.Cloud";
• «Madali ba at maginhawang maghanda ng Kubernetes cluster? Inanunsyo ang addon-operator";
• «Pagpapalawak at pagpupuno sa Kubernetes (pagsusuri at ulat ng video)'.

Pinagmulan: www.habr.com