Í framhaldi af sl fyrir Yandex.Cloud erum við að gefa út annað Open Source verkefni fyrir þetta ský - . CCM er ekki aðeins krafist fyrir þyrpinguna í heild, heldur einnig fyrir CSI ökumanninn sjálfan. Upplýsingar um tilgang þess og suma útfærslueiginleika eru undir skurðinum.
Inngangur
Hvers vegna er þetta?
Ástæðurnar sem urðu til þess að við þróuðum CCM fyrir Yandex.Cloud eru algjörlega í samræmi við þær sem þegar hefur verið lýst í CSI bílstjóri. Við höldum úti mörgum Kubernetes klösum frá mismunandi skýjaveitum, sem við notum eitt tól fyrir. Það útfærir fjölmörg þægindi „framhjá“ stýrðum lausnum þessara veitenda. Já, við höfum frekar sérstakt tilvik og þarfir, en þróunin sem skapast vegna þeirra getur verið gagnleg fyrir aðra notendur.
Hvað nákvæmlega er CCM?
Venjulega undirbúum við umhverfið í kringum okkur fyrir klasann utan frá - til dæmis með því að nota Terraform. En stundum er þörf á að stjórna skýjaumhverfinu í kringum okkur úr klasa. Þessi möguleiki er veittur og það er hann sem er útfærður .
Nánar tiltekið býður Cloud Controller Manager upp á fimm megingerðir af samskiptum:
- Dæmi – útfærir 1:1 samband milli hnúthluts í Kubernetes (
Node) og sýndarvél í skýjaveitunni. Fyrir þetta:- fylltu út reitinn
spec.providerIDí hlutnumNode. Til dæmis, fyrir OpenStack CCM hefur þessi reitur eftirfarandi snið:openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0. Þú getur séð nafn skýjaveitunnar og einstakt UUID netþjónsins (sýndarvél í OpenStack) hlutarins; - viðbót
nodeInfoí hlutnumNodeupplýsingar um sýndarvélina. Til dæmis tilgreinum við tilvikstegund í AWS; - Við athugum tilvist sýndarvélar í skýinu. Til dæmis ef hlutur
Nodefór í ríkiNotReady, þú getur athugað hvort sýndarvélin sé til í skýjaveitunni með því aðproviderID. Ef það er ekki til staðar skaltu eyða hlutnumNode, sem annars væri í þyrpingunni að eilífu;
- fylltu út reitinn
- Zones – stillir bilunarlénið fyrir hlutinn
Node, svo að tímaáætlunarmaðurinn geti valið hnút fyrir Pod í samræmi við svæði og svæði í skýjaveitunni; - LoadBalancer - þegar hlutur er búinn til
Servicemeð gerðLoadBalancerbýr til eins konar jafnvægisbúnað sem mun beina umferð utan frá að klasahnútunum. Til dæmis, í Yandex.Cloud sem þú getur notaðNetworkLoadBalancerиTargetGroupí þessum tilgangi; - Route – byggir upp net milli hnúta, vegna þess Samkvæmt kröfum Kubernetes verður hver pod að hafa sína eigin IP tölu og geta náð í hvaða annan pod sem er. Í þessum tilgangi geturðu notað yfirborðsnet (VXLAN, GENEVE) eða stillt leiðartöflu beint á sýndarnet skýjaveitunnar:
- Volume - Leyfir kraftmikla röðun á PV með PVC og SC. Upphaflega var þessi virkni hluti af CCM, en vegna þess hversu flókin hún er var hún færð yfir í sérstakt verkefni, Container Storage Interface (CSI). Við höfum talað um CSI oftar en einu sinni og eins og áður hefur komið fram, jafnvel CSI bílstjóri.
Áður var allur kóði í samskiptum við skýið staðsettur í aðal Git geymslu Kubernetes verkefnisins kl. k8s.io/kubernetes/pkg/cloudprovider/providers, en þeir ákváðu að hætta við þetta vegna óþæginda við að vinna með stóran kóðagrunn. Allar gamlar útfærslur hafa verið færðar til . Til þæginda fyrir frekari stuðning og þróun voru allir sameiginlegir þættir einnig færðir til .
Eins og með CSI, hafa margir stórir skýjafyrirtæki þegar hannað CCM til að nýta ský á Kubernetes. Ef birgirinn er ekki með CCM, en allar nauðsynlegar aðgerðir eru tiltækar í gegnum API, þá geturðu innleitt CCM sjálfur.
Til að skrifa þína eigin útfærslu á CCM er nóg að innleiða .
И .
Framkvæmd
Hvernig komstu að þessu
Við byrjuðum þróun (eða öllu heldur, jafnvel notkun) með fyrir Yandex.Cloud fyrir ári síðan.
Hins vegar vantaði okkur í þessa útfærslu:
- auðkenning í gegnum JWT IAM tákn;
- Stuðningur við þjónustustjóra.
Í samráði við höfund (dlisin) í Telegram gafluðum við yandex-cloud-controller-manager og bættum við aðgerðunum sem vantar.
Helstu eiginleikar
Eins og er styður CCM eftirfarandi viðmót:
- Dæmi;
- Zones;
- LoadBalancer.
Í framtíðinni, þegar Yandex.Cloud byrjar að vinna með háþróaða VPC getu, munum við bæta við viðmóti Routes.
LoadBalanacer sem aðaláskorun
Upphaflega reyndum við, eins og aðrar CCM útfærslur, að búa til par af LoadBalancer и TargetGroup fyrir hvert Service með gerð LoadBalancer. Hins vegar uppgötvaði Yandex.Cloud eina áhugaverða takmörkun: þú getur ekki notað TargetGroups með skerandi Targets (par SubnetID - IpAddress).
Þess vegna, inni í búinu CCM, er stjórnandi hleypt af stokkunum, sem, þegar hlutir breytast Node safnar upplýsingum um öll viðmót á hverri sýndarvél, flokkar þau eftir tilheyrandi tilteknum NetworkID, skapar af TargetGroup á NetworkID, og fylgist einnig með mikilvægi. Í kjölfarið, þegar þú býrð til hlut Service með gerð LoadBalanacer við hengjum einfaldlega fyrirfram búið til TargetGroup til nýrra NetworkLoadBalanacer'am.
Hvernig á að byrja að nota?
CCM styður Kubernetes útgáfu 1.15 og nýrri. Í klasa, til að það virki, krefst það að fáninn --cloud-provider=external var sett á true fyrir kube-apiserver, kube-controller-manager, kube-scheduler og alla kubelets.
Öllum nauðsynlegum skrefum fyrir uppsetninguna sjálfa er lýst í . Uppsetning snýst um að búa til hluti í Kubernetes úr upplýsingaskrám.
Til að nota CCM þarftu einnig:
- í upplýsingaskránni er möppuauðkenni (
folder-id) Yandex.Cloud; - þjónustureikning fyrir samskipti við Yandex.Cloud API. Í stefnuskránni
Secretnauðsynlegt af þjónustureikningnum. Í skjölunum , hvernig á að búa til þjónustureikning og fá lykla.
Við munum vera ánægð að fá álit þitt og ef þú lendir í einhverjum vandræðum!
Niðurstöður
Við höfum notað innleidda CCM í fimm Kubernetes þyrpingum undanfarnar tvær vikur og ætlum að fjölga þeim í 20 á næsta mánuði. Eins og er mælum við ekki með því að nota CCM fyrir stórar og mikilvægar K8s uppsetningar.
Eins og í tilfelli CSI, munum við vera ánægð ef Yandex verktaki tekur að sér þróun og stuðning við þetta verkefni - við erum tilbúin að flytja geymsluna að þeirra beiðni til að takast á við verkefni sem skipta okkur meira máli.
PS
Lestu líka á blogginu okkar:
- «»;
- «»;
- «'.
Heimild: www.habr.com