Tęsiant naujausią „Yandex.Cloud“ skelbiame kitą atvirojo kodo projektą šiam debesiui – . CCM reikalingas ne tik visam klasteriui, bet ir pačiai CSI tvarkyklei. Išsami informacija apie jo paskirtį ir kai kurias įgyvendinimo ypatybes pateikiama toliau.
įvedimas
Kodėl tai?
Motyvai, paskatinę mus sukurti CCM skirtą Yandex.Cloud, visiškai sutampa su jau aprašytais CSI tvarkyklės. Mes prižiūrime daug Kubernetes klasterių iš skirtingų debesų tiekėjų, kuriems naudojame vieną įrankį. Ji įgyvendina daugybę patogumų, „aplenkdama“ šių tiekėjų valdomus sprendimus. Taip, mes turime gana specifinį atvejį ir poreikius, tačiau dėl jų sukurti patobulinimai gali būti naudingi kitiems vartotojams.
Kas tiksliai yra CCM?
Paprastai klasteriui ruošiame mus supančią aplinką iš lauko - pavyzdžiui, naudojant Terraform. Tačiau kartais reikia tvarkyti mus supančią debesų aplinką iš klasterio. Tokia galimybė suteikiama ir ji įgyvendinama .
Tiksliau, „Cloud Controller Manager“ teikia penkis pagrindinius sąveikos tipus:
- Egzemplioriai – įgyvendina 1:1 santykį tarp mazgo objekto Kubernetes (
Node) ir virtualią mašiną debesies paslaugų teikėje. Tam mes:- užpildykite laukelį
spec.providerIDobjekteNode. Pavyzdžiui, OpenStack CCM šis laukas yra tokio formato:openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0. Galite matyti debesies teikėjo pavadinimą ir unikalų objekto serverio (virtualios mašinos OpenStack) UUID; - papildyti
nodeInfoobjekteNodeinformacija apie virtualią mašiną. Pavyzdžiui, mes nurodome egzemplioriaus tipą AWS; - Mes patikriname, ar debesyje yra virtuali mašina. Pavyzdžiui, jei objektas
Nodepateko į būsenąNotReady, galite patikrinti, ar virtualioji mašina iš viso egzistuoja debesies paslaugų teikėjeproviderID. Jei jo nėra, ištrinkite objektąNode, kuris kitu atveju liktų klasteryje amžinai;
- užpildykite laukelį
- zonos – nustato objekto gedimo sritį
Node, kad planuotojas galėtų pasirinkti Pod mazgą pagal debesies teikėjo regionus ir zonas; - „LoadBalancer“ – kuriant objektą
Servicesu tipuLoadBalancersukuria tam tikrą balansavimo priemonę, kuri nukreips srautą iš išorės į klasterio mazgus. Pavyzdžiui, Yandex.Cloud galite naudotiNetworkLoadBalancerиTargetGroupšiems tikslams; - Maršrutas – sukuria tinklą tarp mazgų, nes Pagal „Kubernetes“ reikalavimus, kiekvienas blokas turi turėti savo IP adresą ir turėti galimybę pasiekti bet kurį kitą bloką. Šiems tikslams galite naudoti perdangos tinklą (VXLAN, GENEVE) arba nustatyti maršruto parinkimo lentelę tiesiai debesies teikėjo virtualiame tinkle:
- Talpa – Leidžia dinamiškai užsisakyti PV naudojant PVC ir SC. Iš pradžių ši funkcija buvo CCM dalis, tačiau dėl didelio sudėtingumo ji buvo perkelta į atskirą projektą „Container Storage Interface“ (CSI). Apie CSI kalbėjome ne kartą ir, kaip jau minėta, net CSI vairuotojas.
Anksčiau visas su debesimi sąveikaujantis kodas buvo pagrindinėje Kubernetes projekto Git saugykloje adresu k8s.io/kubernetes/pkg/cloudprovider/providers, tačiau jie nusprendė to atsisakyti dėl nepatogumų dirbant su didele kodų baze. Visi seni diegimai buvo perkelti į . Tolesnės paramos ir plėtros patogumui taip pat buvo perkelti visi bendri komponentai .
Kaip ir CSI atveju, daugelis didelių debesų paslaugų teikėjų jau sukūrė savo CCM, kad panaudotų debesis Kubernetes. Jei tiekėjas neturi CCM, bet visos reikalingos funkcijos pasiekiamos per API, tuomet CCM galite įdiegti patys.
Norėdami parašyti savo CCM įgyvendinimą, pakanka įdiegti .
И .
Vykdymas
Kaip tu prie to atėjai
Mes pradėjome kurti (tiksliau, net naudoti) su „Yandex.Cloud“ prieš metus.
Tačiau šiame įgyvendinime mums trūko:
- autentifikavimas naudojant JWT IAM prieigos raktą;
- Serviso valdiklio palaikymas.
Sutinkant su autoriumi (dlisin) Telegramoje sujungėme yandex-cloud-controller-manager ir pridėjome trūkstamas funkcijas.
Pagrindinės savybės
Šiuo metu CCM palaiko šias sąsajas:
- Egzemplioriai;
- zonos;
- „LoadBalancer“.
Ateityje, kai „Yandex.Cloud“ pradės dirbti su išplėstinėmis VPC galimybėmis, pridėsime sąsają maršrutai.
„LoadBalanacer“ kaip pagrindinis iššūkis
Iš pradžių, kaip ir kiti CCM diegimai, bandėme sukurti porą LoadBalancer и TargetGroup kiekvienam Service su tipu LoadBalancer. Tačiau „Yandex.Cloud“ atrado vieną įdomų apribojimą: jūs negalite naudoti TargetGroups su susikertančiais Targets (pora SubnetID - IpAddress).
Todėl sukurto CCM viduje paleidžiamas valdiklis, kuris pasikeitus objektams Node renka informaciją apie visas sąsajas kiekvienoje virtualioje mašinoje, sugrupuoja jas pagal priklausymą tam tikrai NetworkID, kuria pagal TargetGroup apie NetworkID, taip pat stebi aktualumą. Vėliau, kuriant objektą Service su tipu LoadBalanacer tiesiog pridedame iš anksto sukurtą TargetGroup į naujus NetworkLoadBalanacer'esu.
Kaip pradėti vartoti?
CCM palaiko Kubernetes 1.15 ir naujesnę versiją. Klasteryje, kad jis veiktų, reikalinga vėliava --cloud-provider=external buvo nustatytas true kube-apiserver, kube-controller-manager, kube-scheduler ir visi kubeletai.
Visi reikalingi žingsniai pačiam diegimui aprašyti . Diegimas apsiriboja objektų kūrimu Kubernetes iš manifestų.
Norėdami naudoti CCM, jums taip pat reikės:
- manifeste katalogo identifikatorius (
folder-id) Yandex.Cloud; - paslaugos paskyra, skirta sąveikai su Yandex.Cloud API. Manifeste
Secretturi iš paslaugų sąskaitos. Dokumentacijoje , kaip susikurti paslaugos paskyrą ir gauti raktus.
Mums bus malonu gauti jūsų atsiliepimus ir jei susidursite su problemomis!
rezultatai
Per pastarąsias dvi savaites naudojome įdiegtą CCM penkiuose „Kubernetes“ klasteriuose ir artimiausią mėnesį planuojame jų skaičių padidinti iki 20. Šiuo metu nerekomenduojame naudoti CCM didelėms ir svarbioms K8 instalijoms.
Kaip ir CSI atveju, džiaugsimės, jei „Yandex“ kūrėjai imsis šio projekto kūrimo ir palaikymo – jų prašymu esame pasirengę perkelti saugyklą, kad galėtume atlikti mums aktualesnes užduotis.
PS
Taip pat skaitykite mūsų tinklaraštyje:
- «»;
- «»;
- «".
Šaltinis: www.habr.com