Aféierung Kubernetes CCM (Cloud Controller Manager) fir Yandex.Cloud

An der Fortsetzung vun de rezenten CSI Driver Verëffentlechung fir Yandex.Cloud publizéieren mir en aneren Open Source Projet fir dës Wollek - Cloud Controller Manager. CCM ass net nëmme fir de Cluster als Ganzt erfuerderlech, awer och fir den CSI Chauffer selwer. Detailer iwwer säin Zweck an e puer Implementéierungsfeatures sinn ënner dem Schnëtt.

Aféierung

Firwat ass dat?

D'Motiver, déi eis gefuerdert hunn, CCM fir Yandex.Cloud z'entwéckelen, stëmmen komplett mat deenen, déi scho beschriwwe sinn an Ukënnegung CSI Chauffeuren. Mir erhalen vill Kubernetes Cluster vu verschiddene Cloud Ubidder, fir déi mir en eenzegt Tool benotzen. Et implementéiert vill Komfort "contournéiert" déi verwaltete Léisunge vun dësen Ubidder. Jo, mir hunn e zimlech spezifesche Fall a Bedierfnesser, awer d'Entwécklungen, déi wéinst hinnen erstallt goufen, kënne fir aner Benotzer nëtzlech sinn.

Wat ass genau CCM?

Typesch preparéiere mir d'Ëmwelt ronderëm eis fir de Cluster vu baussen - zum Beispill, benotzt Terraform. Awer heiansdo gëtt et e Besoin fir d'Wollekëmfeld ronderëm eis ze managen vum Cluster. Dës Méiglechkeet gëtt zur Verfügung gestallt, an et ass et déi ëmgesat gëtt CCM.

Speziell, Cloud Controller Manager bitt fënnef Haaptarten vun Interaktioun:

1. Instanzen - implementéiert eng 1:1 Relatioun tëscht engem Nodeobjekt a Kubernetes (Node) an eng virtuell Maschinn am Cloud Provider. Fir dëst mir:
   • fëllt am Feld spec.providerID am Objet Node. Zum Beispill, fir OpenStack CCM huet dëst Feld de folgenden Format: openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0. Dir kënnt den Numm vum Cloud Provider an déi eenzegaarteg UUID vum Server (virtuell Maschinn an OpenStack) vum Objet gesinn;
   • ergänzen nodeInfo am Objet Node Informatiounen iwwer déi virtuell Maschinn. Zum Beispill spezifizéiere mir Instanztyp an AWS;
   • Mir kontrolléieren d'Präsenz vun enger virtueller Maschinn an der Wollek. Zum Beispill, wann en Objet Node an e Staat gaangen NotReady, Dir kënnt kontrolléieren ob déi virtuell Maschinn iwwerhaapt am Cloud Provider existéiert duerch providerID. Wann et net do ass, läschen den Objet Node, déi soss fir ëmmer am Stärekoup bleiwen;
2. Zonen - setzt d'Feeler Domain fir den Objet Node, sou datt de Scheduler e Node fir de Pod auswielen kann no de Regiounen an Zonen am Cloud Provider;
3. LoadBalancer - wann Dir en Objet erstellt Service mat Typ LoadBalancer schaaft eng Zort Balancer, deen den Traffic vu baussen op d'Clusterknoten dirigéiert. Zum Beispill, an Yandex.Cloud kënnt Dir benotzen NetworkLoadBalancer и TargetGroup fir dës Zwecker;
4. Route - baut en Netz tëscht Wirbelen, well Laut Kubernetes Ufuerderunge muss all Pod seng eege IP Adress hunn a kënnen all aner Pod erreechen. Fir dës Zwecker kënnt Dir en Iwwerlagernetz benotzen (VXLAN, GENEVE) oder e Routing-Table direkt am virtuelle Netzwierk vum Cloud Provider setzen:

   

5. Volume - Erlaabt dynamesch Uerdnung vu PV mat PVC a SC. Am Ufank war dës Funktionalitéit Deel vun CCM, awer wéinst senger grousser Komplexitéit gouf se an e separaten Projet geplënnert, Container Storage Interface (CSI). Mir hunn iwwer CSI méi wéi eemol geschwat geschriwwen an, wéi scho gesot, souguer entlooss CSI Chauffer.

Virdru war all Code, deen mat der Wollek interagéiert, am Haapt Git Repository vum Kubernetes Projet um k8s.io/kubernetes/pkg/cloudprovider/providers, awer si hunn decidéiert dëst opzeginn wéinst der Onbequemlechkeet fir mat enger grousser Codebasis ze schaffen. All al Implementatioune goufen geplënnert getrennte Repository. Fir d'Kamoudheet vun weider Ënnerstëtzung an Entwécklung, all gemeinsam Komponente goufen och geplënnert getrennte Repository.

Wéi mat CSI, hu vill grouss Cloud Provider schonn hir CCMs entwéckelt fir Wolleken op Kubernetes ze leeschten. Wann de Fournisseur keng CCM huet, awer all déi néideg Funktiounen iwwer API verfügbar sinn, da kënnt Dir CCM selwer implementéieren.

Fir Är eege Ëmsetzung vun CCM ze schreiwen, ass et genuch fir ëmzesetzen néideg Go Schnëttplazen.

И dat ass wat mir kruten.

Ëmsetzung

Wéi bass du dozou komm

Mir ugefaang Entwécklung (oder éischter, souguer benotzen) mat prett (!) CCM fir Yandex.Cloud virun engem Joer.

Wéi och ëmmer, an dëser Ëmsetzung hu mir gefeelt:

• Authentifikatioun iwwer JWT IAM Token;
• Service Controller Ënnerstëtzung.

Am Accord mam Auteur (dlisin) am Telegram hu mir de Yandex-Cloud-Controller-Manager geflunn an déi fehlend Funktiounen bäigefüügt.

Schlëssel Features

De Moment ënnerstëtzt CCM déi folgend Interfaces:

• Instanzen;
• Zonen;
• LoadBalancer.

An Zukunft, wann Yandex.Cloud ufänkt mat fortgeschrattenen VPC Fäegkeeten ze schaffen, addéiere mir en Interface Routes.

LoadBalanacer als Haaptfuerderung

Am Ufank hu mir probéiert, wéi aner CCM Implementatiounen, e Paar ze kreéieren LoadBalancer и TargetGroup fir jiddereen Service mat Typ LoadBalancer. Wéi och ëmmer, Yandex.Cloud entdeckt eng interessant Begrenzung: Dir kënnt net benotzen TargetGroups mat Kräizung Targets (paar SubnetID - IpAddress).

Dofir gëtt bannent der erstallt CCM e Controller gestart, deen, wann d'Objete änneren, Node sammelt Informatiounen iwwer all Schnëttplazen op all virtuell Maschinn, Gruppen hinnen no hirem gehéiert zu bestëmmte NetworkID, kreéiert duerch TargetGroup op NetworkID, an iwwerwaacht och d'Relevanz. Duerno, wann Dir en Objet erstellt Service mat Typ LoadBalanacer mir befestegt einfach eng Pre-geschaf TargetGroup zu neier NetworkLoadBalanacer'am.

Wéi ufänken ze benotzen?

CCM ënnerstëtzt Kubernetes Versioun 1.15 a méi héich. An engem Cluster, fir et ze schaffen, et verlaangt, datt de Fändel --cloud-provider=external opgestallt gouf true fir kube-apiserver, kube-controller-manager, kube-scheduler an all kubelets.

All néideg Schrëtt fir d'Installatioun selwer sinn beschriwwen an README. D'Installatioun geet erof op d'Erstelle vun Objeten an Kubernetes aus Manifestatiounen.

Fir CCM ze benotzen braucht Dir och:

• uginn am Manifest de Verzeechnes Identifizéierer (folder-id) Yandex.Cloud;
• Service Kont fir Interaktioun mat der Yandex.Cloud API. Am Manifest Secret ass néideg Transfermaart autoriséiert Schlësselen vum Service Kont. An der Dokumentatioun beschriwwen, wéi een e Servicekonto erstellt a Schlëssele kritt.

Mir wäerten frou Äre Feedback ze kréien an nei Problemerwann Dir Problemer stousse!

Resultater

Mir hunn den implementéierten CCM a fënnef Kubernetes Cluster an de leschten zwou Wochen benotzt a plangen hir Zuel op 20 am kommende Mount auszebauen. Mir recommandéieren de Moment net CCM fir grouss a kritesch K8s Installatiounen ze benotzen.

Wéi am Fall vun CSI wäerte mir frou sinn wann Yandex Entwéckler d'Entwécklung an d'Ënnerstëtzung vun dësem Projet iwwerhuelen - mir si prett de Repository op hir Ufro ze transferéieren fir mat Aufgaben ze këmmeren déi eis méi relevant sinn.

PS

Liest och op eisem Blog:

• «Eis Erfahrung an der Entwécklung vun engem CSI Chauffer zu Kubernetes fir Yandex.Cloud";
• «Ass et einfach a praktesch e Kubernetes Cluster ze preparéieren? Annoncéieren Addon-Operateur";
• «Kubernetes ausbauen an ergänzen (Iwwerpréiwung a Videobericht)".

Source: will.com