V pokračovaní nedávneho pre Yandex.Cloud zverejňujeme ďalší Open Source projekt pre tento cloud - . CCM sa vyžaduje nielen pre klaster ako celok, ale aj pre samotný ovládač CSI. Podrobnosti o jeho účele a niektorých implementačných funkciách sú pod rezom.
Úvod
Prečo je toto?
Motívy, ktoré nás viedli k vývoju CCM pre Yandex.Cloud, sa úplne zhodujú s tými, ktoré už boli opísané v CSI ovládače. Udržiavame veľa klastrov Kubernetes od rôznych poskytovateľov cloudu, na čo používame jeden nástroj. Implementuje množstvo vymožeností, ktoré „obchádzajú“ spravované riešenia týchto poskytovateľov. Áno, máme dosť špecifický prípad a potreby, ale vývoj vytvorený kvôli nim môže byť užitočný pre iných používateľov.
Čo je to vlastne CCM?
Zvyčajne na klaster pripravujeme prostredie okolo nás vonku - napríklad pomocou Terraform. Niekedy je však potrebné spravovať cloudové prostredie okolo nás z klastra. Táto možnosť je poskytnutá a je to implementovaná .
Cloud Controller Manager konkrétne poskytuje päť hlavných typov interakcie:
- prípady – implementuje vzťah 1:1 medzi objektom uzla v Kubernetes (
Node) a virtuálny počítač u poskytovateľa cloudu. Za to my:- vyplňte pole
spec.providerIDv objekteNode. Napríklad pre OpenStack CCM má toto pole nasledujúci formát:openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0. Môžete vidieť názov poskytovateľa cloudu a jedinečné UUID servera (virtuálny počítač v OpenStack) objektu; - dopĺňať
nodeInfov objekteNodeinformácie o virtuálnom stroji. Napríklad špecifikujeme typ inštancie v AWS; - Skontrolujeme prítomnosť virtuálneho počítača v cloude. Napríklad, ak objekt
Nodeprešiel do stavuNotReady, môžete skontrolovať, či virtuálny počítač u poskytovateľa cloudu vôbec existujeproviderID. Ak tam nie je, odstráňte objektNode, ktoré by inak v klastri zostali navždy;
- vyplňte pole
- Zóny – nastavuje doménu zlyhania pre objekt
Node, takže plánovač môže vybrať uzol pre modul podľa regiónov a zón v poskytovateľovi cloudu; - Load Balancer – pri vytváraní objektu
Services typomLoadBalancervytvára akýsi balancer, ktorý bude smerovať premávku zvonku do uzlov klastra. Napríklad v Yandex.Cloud môžete použiťNetworkLoadBalancerиTargetGroupna tieto účely; - Cesta – buduje sieť medzi uzlami, pretože Podľa požiadaviek Kubernetes musí mať každý modul svoju vlastnú IP adresu a musí byť schopný dosiahnuť akýkoľvek iný modul. Na tieto účely môžete použiť overlay sieť (VXLAN, GENEVE) alebo nastaviť smerovaciu tabuľku priamo vo virtuálnej sieti poskytovateľa cloudu:
- Objem – Umožňuje dynamické zoradenie FV pomocou PVC a SC. Spočiatku bola táto funkcionalita súčasťou CCM, no pre svoju veľkú komplexnosť bola presunutá do samostatného projektu Container Storage Interface (CSI). O CSI sme hovorili viac ako raz a ako už bolo spomenuté, dokonca vodič CSI.
Predtým sa všetok kód interagujúci s cloudom nachádzal v hlavnom úložisku Git projektu Kubernetes na adrese k8s.io/kubernetes/pkg/cloudprovider/providers, ale rozhodli sa to opustiť kvôli nepríjemnostiam práce s veľkou kódovou základňou. Všetky staré implementácie boli presunuté do . Pre pohodlie ďalšej podpory a vývoja boli presunuté aj všetky bežné komponenty .
Rovnako ako v prípade CSI, mnohí veľkí poskytovatelia cloudu už navrhli svoje CCM tak, aby využívali cloudy na Kubernetes. Ak dodávateľ nemá CCM, ale všetky potrebné funkcie sú dostupné cez API, potom si môžete CCM zaviesť sami.
Na napísanie vlastnej implementácie CCM stačí implementovať .
И .
Реализация
Ako si k tomu prišiel
Vývoj (alebo skôr používanie) sme začali s pre Yandex.Cloud pred rokom.
V tejto implementácii nám však chýbalo:
- autentifikácia prostredníctvom tokenu JWT IAM;
- Podpora servisného ovládača.
Po dohode s autorom (dlisin) v telegrame sme rozdelili yandex-cloud-controller-manager a pridali chýbajúce funkcie.
Kľúčové vlastnosti
V súčasnosti CCM podporuje nasledujúce rozhrania:
- prípady;
- Zóny;
- Load Balancer.
V budúcnosti, keď Yandex.Cloud začne pracovať s pokročilými možnosťami VPC, pridáme rozhranie trasy.
LoadBalanacer ako hlavná výzva
Spočiatku sme sa snažili, podobne ako iné implementácie CCM, vytvoriť pár LoadBalancer и TargetGroup pre každý Service s typom LoadBalancer. Yandex.Cloud však objavil jedno zaujímavé obmedzenie: nemôžete ho použiť TargetGroups s pretínajúcimi sa Targets (pár SubnetID - IpAddress).
Preto sa vo vnútri vytvoreného CCM spustí kontrolér, ktorý pri zmene objektov Node zhromažďuje informácie o všetkých rozhraniach na každom virtuálnom stroji, zoskupuje ich podľa ich príslušnosti k určitému NetworkID, vytvára podľa TargetGroup na NetworkIDa tiež monitoruje relevantnosť. Následne pri vytváraní objektu Service s typom LoadBalanacer jednoducho priložíme vopred vytvorenú TargetGroup k novému NetworkLoadBalanacersom.
Ako začať používať?
CCM podporuje Kubernetes verzie 1.15 a vyššie. V klastri, aby to fungovalo, vyžaduje to príznak --cloud-provider=external bola nastavená na true pre kube-apiserver, kube-controller-manager, kube-plánovač a všetky kubelety.
Všetky potrebné kroky pre samotnú inštaláciu sú popísané v . Inštalácia sa scvrkáva na vytváranie objektov v Kubernetes z manifestov.
Na používanie CCM budete tiež potrebovať:
- v manifeste identifikátor adresára (
folder-id) Yandex.Cloud; - účet služby na interakciu s rozhraním Yandex.Cloud API. V manifeste
Secretmušt zo servisného účtu. V dokumentácii , ako si vytvoriť servisný účet a získať kľúče.
Budeme radi, ak nám pošlete spätnú väzbu a ak narazíte na nejaké problémy!
Výsledky
Za posledné dva týždne sme implementovaný CCM používali v piatich klastroch Kubernetes a v nadchádzajúcom mesiaci plánujeme rozšíriť ich počet na 20. V súčasnosti neodporúčame používať CCM pre veľké a kritické inštalácie K8.
Rovnako ako v prípade CSI budeme radi, ak vývojári Yandex prevezmú vývoj a podporu tohto projektu - sme pripravení preniesť úložisko na ich žiadosť, aby sme mohli riešiť úlohy, ktoré sú pre nás relevantnejšie.
PS
Prečítajte si aj na našom blogu:
- «»;
- «»;
- «".
Zdroj: hab.com