Yntroduksje fan Kubernetes CCM (Cloud Controller Manager) foar Yandex.Cloud

Yn ferfolch op de resinte CSI stjoerprogramma release foar Yandex.Cloud publisearje wy in oar Open Source-projekt foar dizze wolk - Cloud Controller Manager. CCM is net allinich nedich foar it kluster as gehiel, mar ek foar de CSI-bestjoerder sels. Details oer it doel en guon ymplemintaasjefunksjes binne ûnder de besuniging.

Ynlieding

Wêrom is dit?

De motiven dy't ús oantrún hawwe om CCM foar Yandex.Cloud te ûntwikkeljen falle folslein oerien mei dy al beskreaun yn oankundiging CSI bestjoerders. Wy ûnderhâlde in protte Kubernetes-klusters fan ferskate wolkproviders, wêrfoar wy ien ark brûke. It ymplementearret tal fan gemak "omgean" de beheare oplossingen fan dizze providers. Ja, wy hawwe in nochal spesifike saak en behoeften, mar de ûntjouwings makke fanwegen harren kinne nuttich wêze foar oare brûkers.

Wat is krekt CCM?

Typysk meitsje wy de omjouwing om ús hinne foar it kluster fan bûten ôf - bygelyks Terraform brûke. Mar soms is d'r needsaak om de wolkomjouwing om ús hinne te behearjen út kluster. Dizze mooglikheid wurdt foarsjoen, en it is it dat wurdt útfierd TLC.

Spesifyk biedt Cloud Controller Manager fiif haadtypen fan ynteraksje:

1. instances - implementeart in 1:1 relaasje tusken in knooppuntobjekt yn Kubernetes (Node) en in firtuele masine yn 'e wolkprovider. Foar dit wy:
   • folje it fjild yn spec.providerID yn it objekt Node. Bygelyks, foar OpenStack CCM hat dit fjild it folgjende formaat: openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0. Jo kinne de namme fan 'e wolkprovider sjen en de unike UUID fan' e tsjinner (firtuele masine yn OpenStack) fan it objekt;
   • oanfolling nodeInfo yn it objekt Node ynformaasje oer de firtuele masine. Bygelyks, wy spesifisearje eksimplaar type yn AWS;
   • Wy kontrolearje de oanwêzigens fan in firtuele masine yn 'e wolk. Bygelyks, as in foarwerp Node gie yn in steat NotReady, kinne jo kontrolearje oft de firtuele masine bestiet hielendal yn 'e wolk provider troch providerID. As it der net is, wiskje it objekt Node, dy't oars foar altyd yn 'e kluster bliuwe soe;
2. sônes - stelt it mislearre domein yn foar it objekt Node, sadat de planner in knooppunt foar de Pod selektearje kin neffens de regio's en sônes yn 'e wolkprovider;
3. LoadBalancer - by it meitsjen fan in objekt Service mei type LoadBalancer makket in soarte fan balancer dy't ferkear fan bûten nei de klusterknooppunten sil rjochtsje. Bygelyks, yn Yandex.Cloud kinne jo brûke NetworkLoadBalancer и TargetGroup foar dizze doelen;
4. Rûte - bout in netwurk tusken knopen, omdat Neffens Kubernetes-easken moat elke pod in eigen IP-adres hawwe en elke oare pod kinne berikke. Foar dizze doelen kinne jo in overlay-netwurk (VXLAN, GENEVE) brûke of in routingtabel direkt yn it firtuele netwurk fan 'e wolkprovider ynstelle:

   

5. Folume - Stelt dynamyske oardering fan PV mooglik mei PVC en SC. Yn earste ynstânsje wie dizze funksjonaliteit diel fan CCM, mar troch syn grutte kompleksiteit waard it ferpleatst nei in apart projekt, Container Storage Interface (CSI). Wy hawwe it mear as ien kear oer CSI skreaun en, lykas al neamd, sels frijlitten CSI bestjoerder.

Earder wie alle koade dy't ynteraksje mei de wolk yn it haad Git-repository fan it Kubernetes-projekt by k8s.io/kubernetes/pkg/cloudprovider/providers, mar se besletten dit te ferlitten fanwegen it ûngemak fan wurkjen mei in grutte koadebasis. Alle âlde ymplemintaasjes binne ferpleatst nei apart repository. Foar it gemak fan fierdere stipe en ûntwikkeling, alle mienskiplike komponinten waarden ek ferpleatst nei apart repository.

Lykas by CSI, hawwe in protte grutte wolkeproviders har CCM's al ûntworpen om wolken op Kubernetes te benutten. As de leveransier gjin CCM hat, mar alle nedige funksjes binne beskikber fia API, dan kinne jo sels CCM útfiere.

Om jo eigen ymplemintaasje fan CCM te skriuwen, is it genôch om te ymplementearjen fereaske Go-ynterfaces.

И dit is wat wy krigen.

Ymplemintaasje

Hoe binne jo hjir op kommen

Wy begûn ûntwikkeling (of leaver, sels gebrûk) mei klear(!) CCM foar Yandex.Cloud in jier lyn.

Yn dizze ymplemintaasje misten wy lykwols:

• autentikaasje fia JWT IAM token;
• Service controller stipe.

Yn oerienstimming mei de skriuwer (diel) yn Telegram forkearden wy yandex-cloud-controller-manager en tafoege de ûntbrekkende funksjes.

Main Features

Op it stuit stipet CCM de folgjende ynterfaces:

• instances;
• sônes;
• LoadBalancer.

Yn 'e takomst, as Yandex.Cloud begjint te wurkjen mei avansearre VPC-mooglikheden, sille wy in ynterface tafoegje Routes.

LoadBalanacer as wichtichste útdaging

Yn it earstoan besochten wy, lykas oare CCM-ymplemintaasjes, in pear te meitsjen LoadBalancer и TargetGroup foar eltse Service mei type LoadBalancer. Yandex.Cloud ûntduts lykwols ien nijsgjirrige beheining: jo kinne net brûke TargetGroups mei krusing Targets (pear SubnetID - IpAddress).

Dêrom wurdt binnen de oanmakke CCM in controller lansearre, dy't as objekten feroarje Node sammelet ynformaasje oer alle ynterfaces op elke firtuele masine, groepearret se neffens harren hearre ta bepaalde NetworkID, skept troch TargetGroup op NetworkID, en ek kontrolearret relevânsje. Dêrnei, by it meitsjen fan in objekt Service mei type LoadBalanacer wy hechtsje gewoan in pre-makke TargetGroup oan nij NetworkLoadBalanacer'bin.

Hoe kinne jo it begjinne te brûken?

CCM stipet Kubernetes ferzje 1.15 en heger. Yn in kluster, foar it te wurkjen, it fereasket dat de flagge --cloud-provider=external waard ynsteld op true foar kube-apiserver, kube-controller-manager, kube-scheduler en alle kubelets.

Alle nedige stappen foar de ynstallaasje sels wurde beskreaun yn README. Ynstallaasje komt del op it meitsjen fan objekten yn Kubernetes út manifesten.

Om CCM te brûken sille jo ek nedich wêze:

• oanwize yn it manifest de map identifier (folder-id) Yandex.Cloud;
• tsjinst account foar ynteraksje mei de Yandex.Cloud API. Yn it manifest Secret is nedich oerdracht autorisearre kaaien út de tsjinst account. Yn de dokumintaasje beskriuwe, hoe meitsje in tsjinst account en krije kaaien.

Wy sille bliid te ûntfangen jo feedback en nije sakenas jo problemen tsjinkomme!

Resultaten

Wy hawwe de ôfrûne twa wiken de ymplementearre CCM brûkt yn fiif Kubernetes-klusters en binne fan plan om har oantal yn 'e kommende moanne út te wreidzjen nei 20. Wy riede op it stuit net oan om CCM te brûken foar grutte en krityske K8s-ynstallaasjes.

Lykas yn it gefal fan CSI, sille wy bliid wêze as Yandex-ûntwikkelders de ûntwikkeling en stipe fan dit projekt oernimme - wy binne ree om it repository op har fersyk oer te dragen om te gean mei taken dy't mear relevant binne foar ús.

PS

Lês ek op ús blog:

• «Us ûnderfining yn it ûntwikkeljen fan in CSI-bestjoerder yn Kubernetes foar Yandex.Cloud";
• «Is it maklik en handich om in Kubernetes-kluster te meitsjen? Addon-operator oankundigje";
• «Kubernetes útwreidzje en oanfolje (oersjoch en fideorapport)".

Boarne: www.habr.com