🥇 Bekendstelling van Kubernetes CCM (Cloud Controller Manager) vir Yandex.Cloud

In voortsetting van die onlangse CSI bestuurder vrystelling vir Yandex.Cloud publiseer ons nog 'n oopbronprojek vir hierdie wolk - Wolkbeheerderbestuurder. CCM word nie net vir die groep as 'n geheel vereis nie, maar ook vir die CSI-bestuurder self. Besonderhede oor die doel daarvan en sommige implementeringskenmerke is onder die knie.

Inleiding

Hoekom is dit?

Die motiewe wat ons aangespoor het om CCM vir Yandex.Cloud te ontwikkel, stem heeltemal ooreen met dié wat reeds beskryf is in aankondiging CSI-bestuurders. Ons onderhou baie Kubernetes-klusters van verskillende wolkverskaffers, waarvoor ons 'n enkele instrument gebruik. Dit implementeer talle geriewe wat die bestuurde oplossings van hierdie verskaffers “omseil”. Ja, ons het 'n taamlik spesifieke geval en behoeftes, maar die ontwikkelings wat daardeur geskep word, kan nuttig wees vir ander gebruikers.

Wat presies is CCM?

Tipies berei ons die omgewing rondom ons voor vir die groepering van buite - byvoorbeeld deur Terraform te gebruik. Maar soms is dit nodig om die wolkomgewing rondom ons te bestuur van cluster. Hierdie moontlikheid word verskaf, en dit is dit wat geïmplementeer word CCM.

Spesifiek, Cloud Controller Manager bied vyf hooftipes interaksie:

gevalle – implementeer 'n 1:1 verhouding tussen 'n nodus voorwerp in Kubernetes (Node) en 'n virtuele masjien in die wolkverskaffer. Hiervoor:
- vul die veld in spec.providerID in die voorwerp Node. Byvoorbeeld, vir OpenStack CCM het hierdie veld die volgende formaat: openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0. U kan die naam van die wolkverskaffer en die unieke UUID van die bediener (virtuele masjien in OpenStack) van die voorwerp sien;
- aanvul nodeInfo in die voorwerp Node inligting oor die virtuele masjien. Byvoorbeeld, ons spesifiseer instansie tipe in AWS;
- Ons kyk na die teenwoordigheid van 'n virtuele masjien in die wolk. Byvoorbeeld, as 'n voorwerp Node in 'n toestand gegaan NotReady, kan jy kyk of die virtuele masjien enigsins in die wolkverskaffer bestaan deur providerID. As dit nie daar is nie, verwyder die voorwerp Node, wat andersins vir altyd in die tros sou bly;
sones – stel die mislukkingsdomein vir die objek Node, sodat die skeduleerder 'n nodus vir die Pod kan kies volgens die streke en sones in die wolkverskaffer;
LoadBalancer – wanneer 'n voorwerp geskep word Service met tipe LoadBalancer skep 'n soort balanseerder wat verkeer van buite na die cluster nodusse sal lei. Byvoorbeeld, in Yandex.Cloud wat jy kan gebruik NetworkLoadBalancer и TargetGroup vir hierdie doeleindes;
Route – bou 'n netwerk tussen nodusse, want Volgens Kubernetes-vereistes moet elke peul sy eie IP-adres hê en enige ander peul kan bereik. Vir hierdie doeleindes kan u 'n oorlegnetwerk (VXLAN, GENEVE) gebruik of 'n roeteringtabel direk in die virtuele netwerk van die wolkverskaffer opstel:
Deel - Laat dinamiese ordening van PV toe met behulp van PVC en SC. Aanvanklik was hierdie funksionaliteit deel van CCM, maar weens die groot kompleksiteit daarvan is dit na 'n aparte projek, Container Storage Interface (CSI) geskuif. Ons het al meer as een keer oor CSI gepraat писали en, soos reeds genoem, selfs vrygelaat CSI bestuurder.

Voorheen was alle kode wat met die wolk in wisselwerking was geleë in die hoof Git-bewaarplek van die Kubernetes-projek by k8s.io/kubernetes/pkg/cloudprovider/providers, maar hulle het besluit om dit te laat vaar weens die ongerief om met 'n groot kodebasis te werk. Alle ou implementerings is geskuif na aparte bewaarplek. Vir die gerief van verdere ondersteuning en ontwikkeling is alle gemeenskaplike komponente ook verskuif na aparte bewaarplek.

Soos met CSI, het baie groot wolkverskaffers reeds hul CCM's ontwerp om wolke op Kubernetes te benut. As die verskaffer nie CCM het nie, maar al die nodige funksies is via API beskikbaar, dan kan jy self CCM implementeer.

Om jou eie implementering van CCM te skryf, is dit genoeg om te implementeer vereiste Go-koppelvlakke.

И dit is wat ons gekry het.

Implementering

Hoe het jy hiertoe gekom

Ons het begin ontwikkeling (of eerder, selfs gebruik) met gereed(!) CCM vir Yandex.Cloud 'n jaar gelede.

In hierdie implementering het ons egter ontbreek:

verifikasie via JWT IAM-token;
Diensbeheerderondersteuning.

In ooreenstemming met die skrywer (dlisin) in Telegram het ons yandex-wolk-beheerder-bestuurder gevurk en die ontbrekende funksies bygevoeg.

Belangrike kenmerke

Tans ondersteun CCM die volgende koppelvlakke:

gevalle;
sones;
LoadBalancer.

In die toekoms, wanneer Yandex.Cloud met gevorderde VPC-vermoëns begin werk, sal ons 'n koppelvlak byvoeg roetes.

LoadBalanacer as hoofuitdaging

Aanvanklik het ons, soos ander CCM-implementerings, probeer om 'n paar te skep LoadBalancer и TargetGroup vir elke Service met tipe LoadBalancer. Yandex.Cloud het egter een interessante beperking ontdek: jy kan nie gebruik nie TargetGroups met kruising Targets (paar SubnetID - IpAddress).

Daarom word 'n beheerder binne die geskepde CCM geloods, wat wanneer voorwerpe verander Node versamel inligting oor alle koppelvlakke op elke virtuele masjien, groepeer hulle volgens hul behoort aan sekere NetworkID, skep deur TargetGroup op NetworkID, en monitor ook relevansie. Vervolgens, wanneer 'n voorwerp geskep word Service met tipe LoadBalanacer ons heg eenvoudig 'n voorafgeskepte aan TargetGroup na nuut NetworkLoadBalanacer'is.

Hoe om te begin gebruik?

CCM ondersteun Kubernetes weergawe 1.15 en hoër. In 'n cluster, vir dit om te werk, dit vereis dat die vlag --cloud-provider=external ingestel is true vir kube-apiserver, kube-beheerder-bestuurder, kube-skeduleerder en alle kubelets.

Alle nodige stappe vir die installasie self word beskryf in README. Installasie kom daarop neer om voorwerpe in Kubernetes uit manifeste te skep.

Om CCM te gebruik sal jy ook nodig hê:

uitwys in die manifes die gids identifiseerder (folder-id) Yandex.Wolk;
diensrekening vir interaksie met die Yandex.Cloud API. In die manifes Secret is nodig oordra gemagtigde sleutels vanaf die diensrekening. In die dokumentasie beskryf, hoe om 'n diensrekening te skep en sleutels te kry.

Ons sal bly wees om jou terugvoer te ontvang en nuwe kwessiesas jy enige probleme ondervind!

Resultate van

Ons het die afgelope twee weke die geïmplementeerde CCM in vyf Kubernetes-klusters gebruik en beplan om hul getal tot 20 in die komende maand uit te brei. Ons beveel tans nie aan om CCM vir groot en kritieke K8s-installasies te gebruik nie.

Soos in die geval van CSI, sal ons bly wees as Yandex-ontwikkelaars die ontwikkeling en ondersteuning van hierdie projek oorneem - ons is gereed om die bewaarplek op hul versoek oor te dra om take te hanteer wat vir ons meer relevant is.

Bekendstelling van Kubernetes CCM (Cloud Controller Manager) vir Yandex.Cloud