U nastavku do nedavno za Yandex.Cloud objavljujemo još jedan projekat otvorenog koda za ovaj oblak - . CCM je potreban ne samo za klaster u cjelini, već i za sam CSI drajver. Detalji o njegovoj namjeni i nekim karakteristikama implementacije su ispod reza.
Uvod
Zašto je ovo?
Motivi koji su nas potaknuli da razvijemo CCM za Yandex.Cloud potpuno se poklapaju s onima koji su već opisani u CSI drajveri. Održavamo mnogo Kubernetes klastera različitih dobavljača oblaka, za koje koristimo jedan alat. Implementira brojne pogodnosti "zaobilazeći" upravljana rješenja ovih provajdera. Da, imamo prilično specifičan slučaj i potrebe, ali razvoji stvoreni zbog njih mogu biti korisni drugim korisnicima.
Šta je zapravo CCM?
Obično pripremamo okruženje oko nas za klaster spolja - na primjer, korištenjem Terraforma. Ali ponekad postoji potreba za upravljanjem okruženjem u oblaku oko nas iz klastera. Ova mogućnost je pružena, a ona se i sprovodi .
Konkretno, Cloud Controller Manager pruža pet glavnih tipova interakcije:
- slučajevima – implementira odnos 1:1 između objekta čvora u Kubernetesu (
Node) i virtuelnu mašinu u provajderu oblaka. Za ovo mi:- popunite polje
spec.providerIDu objektuNode. Na primjer, za OpenStack CCM ovo polje ima sljedeći format:openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0. Možete vidjeti ime dobavljača oblaka i jedinstveni UUID servera (virtuelne mašine u OpenStack-u) objekta; - dopuna
nodeInfou objektuNodeinformacije o virtuelnoj mašini. Na primjer, specificiramo tip instance u AWS-u; - Provjeravamo prisustvo virtuelne mašine u oblaku. Na primjer, ako je objekt
Nodeprešao u stanjeNotReady, možete provjeriti postoji li virtuelna mašina uopšte u cloud provajderuproviderID. Ako ga nema, izbrišite objekatNode, koji bi inače zauvijek ostao u klasteru;
- popunite polje
- zone – postavlja domenu greške za objekt
Node, tako da planer može odabrati čvor za Pod prema regijama i zonama u provajderu oblaka; - LoadBalancer – prilikom kreiranja objekta
Servicesa tipomLoadBalancerstvara neku vrstu balansera koji će usmjeriti promet izvana na čvorove klastera. Na primjer, u Yandex.Cloud možete koristitiNetworkLoadBalancerиTargetGroupza ove svrhe; - ruta – gradi mrežu između čvorova, jer Prema Kubernetes zahtjevima, svaki pod mora imati svoju IP adresu i biti u mogućnosti doći do bilo kojeg drugog poda. U ove svrhe možete koristiti preklapajuću mrežu (VXLAN, GENEVE) ili postaviti tabelu rutiranja direktno u virtuelnu mrežu provajdera u oblaku:
- zapremina – Omogućava dinamičko naručivanje PV-a koristeći PVC i SC. U početku je ova funkcionalnost bila dio CCM-a, ali je zbog svoje velike složenosti prebačena u poseban projekat, Container Storage Interface (CSI). Razgovarali smo o CSI više puta i, kao što je već pomenuto, čak CSI drajver.
Ranije je sav kod koji je u interakciji s oblakom bio smješten u glavnom Git spremištu Kubernetes projekta na adresi k8s.io/kubernetes/pkg/cloudprovider/providers, ali su to odlučili napustiti zbog neugodnosti rada s velikom bazom koda. Sve stare implementacije su premještene na . Radi pogodnosti dalje podrške i razvoja, premještene su i sve zajedničke komponente .
Kao i kod CSI-ja, mnogi veliki dobavljači oblaka su već dizajnirali svoje CCM-ove da iskoriste oblake na Kubernetes-u. Ako dobavljač nema CCM, ali su sve potrebne funkcije dostupne preko API-ja, onda možete sami implementirati CCM.
Da biste napisali vlastitu implementaciju CCM-a, dovoljno je implementirati .
И .
Реализация
Kako ste došli do ovoga?
Počeli smo razvoj (tačnije, čak i korištenje) s za Yandex.Cloud prije godinu dana.
Međutim, u ovoj implementaciji nam je nedostajalo:
- autentifikacija putem JWT IAM tokena;
- Podrška za servisni kontroler.
U dogovoru sa autorom (dlisin) u Telegramu smo račvalili yandex-cloud-controller-manager i dodali funkcije koje nedostaju.
Ključne karakteristike
Trenutno, CCM podržava sljedeća sučelja:
- slučajevima;
- zone;
- LoadBalancer.
U budućnosti, kada Yandex.Cloud počne da radi sa naprednim VPC mogućnostima, dodaćemo interfejs rute.
LoadBalanacer kao glavni izazov
U početku smo pokušali, kao i druge CCM implementacije, stvoriti par LoadBalancer и TargetGroup za svaki Service sa tipom LoadBalancer. Međutim, Yandex.Cloud je otkrio jedno zanimljivo ograničenje: ne možete koristiti TargetGroups sa ukrštanjem Targets (par SubnetID - IpAddress).
Stoga se unutar kreiranog CCM-a pokreće kontroler, koji pri promjeni objekata Node prikuplja informacije o svim interfejsima na svakoj virtuelnoj mašini, grupiše ih prema njihovoj pripadnosti određenim NetworkID, kreira TargetGroup na NetworkID, a također prati relevantnost. Nakon toga, prilikom kreiranja objekta Service sa tipom LoadBalanacer jednostavno prilažemo unaprijed kreiranu TargetGroup do novih NetworkLoadBalanacer'am.
Kako početi koristiti?
CCM podržava Kubernetes verziju 1.15 i noviju. U klasteru, da bi funkcionisao, potrebna mu je zastavica --cloud-provider=external je postavljeno na true za kube-apiserver, kube-controller-manager, kube-scheduler i sve kubelete.
Svi potrebni koraci za samu instalaciju opisani su u . Instalacija se svodi na kreiranje objekata u Kubernetesu iz manifesta.
Za korištenje CCM-a trebat će vam i:
- u manifestu identifikator direktorija (
folder-id) Yandex.Cloud; - servisni nalog za interakciju sa Yandex.Cloud API-jem. U manifestu
Secretje neophodno sa servisnog računa. U dokumentaciji , kako kreirati servisni nalog i dobiti ključeve.
Bit će nam drago primiti vaše povratne informacije i , ako naiđete na bilo kakve probleme!
Ishodi
Koristili smo implementirani CCM u pet Kubernetes klastera u protekle dvije sedmice i planiramo da proširimo njihov broj na 20 u narednom mjesecu. Trenutno ne preporučujemo korištenje CCM-a za velike i kritične K8s instalacije.
Kao iu slučaju CSI, bit će nam drago ako Yandex programeri preuzmu razvoj i podršku ovog projekta - spremni smo prenijeti spremište na njihov zahtjev kako bismo se bavili zadacima koji su nam relevantniji.
PS
Pročitajte i na našem blogu:
- «»;
- «»;
- «".
izvor: www.habr.com