Prezantimi i Kubernetes CCM (Menaxheri i Kontrolluesit të Cloud) për Yandex.Cloud

Në vazhdim të fundit Lëshimi i shoferit CSI për Yandex.Cloud ne po publikojmë një projekt tjetër me burim të hapur për këtë re - Menaxheri i Kontrolluesit në renë kompjuterike. CCM kërkohet jo vetëm për grupin në tërësi, por edhe për vetë drejtuesin e CSI. Detajet rreth qëllimit të tij dhe disa veçorive të zbatimit janë në prerje.

Paraqitje

Pse eshte kjo?

Motivet që na shtynë të zhvillojmë CCM për Yandex.Cloud përputhen plotësisht me ato të përshkruara tashmë në shpallje Drejtues CSI. Ne mirëmbajmë shumë grupime Kubernetes nga ofrues të ndryshëm cloud, për të cilët përdorim një mjet të vetëm. Ai zbaton lehtësira të shumta duke "anashkaluar" zgjidhjet e menaxhuara të këtyre ofruesve. Po, ne kemi një rast dhe nevoja mjaft specifike, por zhvillimet e krijuara për shkak të tyre mund të jenë të dobishme për përdoruesit e tjerë.

Çfarë është saktësisht CCM?

Në mënyrë tipike, ne përgatisim mjedisin rreth nesh për grupin nga jashte - për shembull, duke përdorur Terraform. Por ndonjëherë ekziston nevoja për të menaxhuar mjedisin cloud rreth nesh nga grupi. Kjo mundësi ofrohet, dhe është ajo që zbatohet CCM.

Në mënyrë të veçantë, Cloud Controller Manager ofron pesë lloje kryesore të ndërveprimit:

1. raste – zbaton një marrëdhënie 1:1 midis një objekti nyje në Kubernetes (Node) dhe një makinë virtuale në ofruesin e cloud. Për këtë ne:
   • plotësoni fushën spec.providerID në objekt Node. Për shembull, për OpenStack CCM kjo fushë ka formatin e mëposhtëm: openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0. Ju mund të shihni emrin e ofruesit të cloud dhe UUID-në unike të serverit (makinë virtuale në OpenStack) të objektit;
   • plotësojnë nodeInfo në objekt Node informacion rreth makinës virtuale. Për shembull, ne specifikojmë llojin e shembullit në AWS;
   • Ne kontrollojmë praninë e një makine virtuale në re. Për shembull, nëse një objekt Node shkoi në një gjendje NotReady, mund të kontrolloni nëse makina virtuale ekziston fare në ofruesin e resë kompjuterike duke providerID. Nëse nuk është aty, fshini objektin Node, e cila përndryshe do të mbetej përgjithmonë në grup;
2. zonat – vendos domenin e dështimit për objektin Node, në mënyrë që planifikuesi të mund të zgjedhë një nyje për Pod sipas rajoneve dhe zonave në ofruesin e resë kompjuterike;
3. LoadBalancer – kur krijoni një objekt Service me llojin LoadBalancer krijon një lloj balancuesi që do të drejtojë trafikun nga jashtë në nyjet e grupimit. Për shembull, në Yandex.Cloud mund të përdorni NetworkLoadBalancer и TargetGroup për këto qëllime;
4. Rrugë – ndërton një rrjet ndërmjet nyjeve, sepse Sipas kërkesave të Kubernetes, çdo pod duhet të ketë adresën e vet IP dhe të jetë në gjendje të arrijë çdo pod tjetër. Për këto qëllime, mund të përdorni një rrjet mbivendosje (VXLAN, GENEVE) ose të vendosni një tabelë rrugëtimi direkt në rrjetin virtual të ofruesit të cloud:

   

5. Vëllim – Lejon renditjen dinamike të PV duke përdorur PVC dhe SC. Fillimisht, ky funksionalitet ishte pjesë e CCM, por për shkak të kompleksitetit të tij të madh u zhvendos në një projekt të veçantë, Ndërfaqja e ruajtjes së kontejnerëve (CSI). Ne kemi folur për CSI më shumë se një herë писали dhe, siç u përmend tashmë, madje lëshuar Shofer CSI.

Më parë, i gjithë kodi që ndërvepronte me cloud ishte i vendosur në depon kryesore Git të projektit Kubernetes në k8s.io/kubernetes/pkg/cloudprovider/providers, por ata vendosën ta braktisin këtë për shkak të shqetësimit të punës me një bazë të madhe kodi. Të gjitha implementimet e vjetra janë zhvendosur në depo e veçantë. Për lehtësinë e mbështetjes dhe zhvillimit të mëtejshëm, të gjithë komponentët e përbashkët u zhvendosën gjithashtu në depo e veçantë.

Ashtu si me CSI, shumë ofrues të mëdhenj cloud kanë krijuar tashmë CCM-të e tyre për të shfrytëzuar retë në Kubernetes. Nëse furnizuesi nuk ka CCM, por të gjitha funksionet e nevojshme janë të disponueshme përmes API, atëherë mund ta zbatoni vetë CCM.

Për të shkruar zbatimin tuaj të CCM, mjafton të zbatoni ndërfaqet e nevojshme Go.

И kjo është ajo që kemi marrë.

Zbatimi

Si erdhët në këtë

Ne filluam zhvillimin (ose më mirë, edhe përdorimin) me gati(!) CCM për Yandex.Cloud një vit më parë.

Megjithatë, në këtë zbatim na mungonte:

• vërtetimi me anë të tokenit JWT IAM;
• Mbështetja e kontrolluesit të shërbimit.

Në marrëveshje me autorin (dlisin) në Telegram, ne forkuam yandex-cloud-controller-manager dhe shtuam funksionet që mungojnë.

Karakteristikat kryesore

Aktualisht, CCM mbështet ndërfaqet e mëposhtme:

• raste;
• zonat;
• LoadBalancer.

Në të ardhmen, kur Yandex.Cloud të fillojë të punojë me aftësi të përparuara VPC, ne do të shtojmë një ndërfaqe rrugët.

LoadBalanacer si sfida kryesore

Fillimisht, ne u përpoqëm, si zbatimet e tjera CCM, të krijonim një palë LoadBalancer и TargetGroup per secilin Service me llojin LoadBalancer. Sidoqoftë, Yandex.Cloud zbuloi një kufizim interesant: nuk mund ta përdorni TargetGroups me kryqëzim Targets (çift SubnetID - IpAddress).

Prandaj, brenda CCM-së së krijuar, lëshohet një kontrollues, i cili, kur objektet ndryshojnë Node mbledh informacion për të gjitha ndërfaqet në secilën makinë virtuale, i grupon ato sipas përkatësisë së tyre në disa NetworkID, krijon nga TargetGroup mbi NetworkID, dhe gjithashtu monitoron rëndësinë. Më pas, kur krijoni një objekt Service me llojin LoadBalanacer ne thjesht bashkangjisim një të krijuar paraprakisht TargetGroup te reja NetworkLoadBalanacer'jam.

Si të filloni të përdorni?

CCM mbështet Kubernetes versionin 1.15 dhe më të lartë. Në një grup, që ai të funksionojë, kërkon që flamuri --cloud-provider=external ishte vendosur në true për kube-apiserver, kube-controller-manager, kube-scheduler dhe të gjitha kubelet.

Të gjithë hapat e nevojshëm për vetë instalimin janë përshkruar në README. Instalimi zbret në krijimin e objekteve në Kubernetes nga manifestet.

Për të përdorur CCM do t'ju duhet gjithashtu:

• tregojnë në manifest identifikuesin e drejtorisë (folder-id) Yandex.Cloud;
• llogaria e shërbimit për ndërveprim me API Yandex.Cloud. Në manifest Secret është e nevojshme transferoni çelësat e autorizuar nga llogaria e shërbimit. Në dokumentacion përshkruar, si të krijoni një llogari shërbimi dhe të merrni çelësat.

Do të jemi të lumtur të marrim komentet tuaja dhe çështje të rejanëse hasni ndonjë problem!

Rezultatet e

Ne kemi përdorur CCM-në e implementuar në pesë grupe Kubernetes gjatë dy javëve të fundit dhe planifikojmë ta zgjerojmë numrin e tyre në 20 në muajin e ardhshëm. Aktualisht nuk rekomandojmë përdorimin e CCM për instalime të mëdha dhe kritike të K8.

Ashtu si në rastin e CSI, do të jemi të lumtur nëse zhvilluesit e Yandex marrin përsipër zhvillimin dhe mbështetjen e këtij projekti - ne jemi të gatshëm të transferojmë depon me kërkesën e tyre në mënyrë që të merremi me detyra që janë më të rëndësishme për ne.

PS

Lexoni edhe në blogun tonë:

• «Përvoja jonë në zhvillimin e një drejtuesi CSI në Kubernetes për Yandex.Cloud"?
• «A është e lehtë dhe e përshtatshme për të përgatitur një grup Kubernetes? Njoftimi i operatorit shtesë"?
• «Zgjerimi dhe plotësimi i Kubernetes (rishikim dhe raport video)'.

Burimi: www.habr.com