En daŭrigo al la lastatempa por Yandex.Cloud ni publikigas alian Malfermfontan projekton por ĉi tiu nubo - . CCM estas postulata ne nur por la areto kiel tutaĵo, sed ankaŭ por la CSI-ŝoforo mem. Detaloj pri ĝia celo kaj kelkaj efektivigfunkcioj estas sub la tranĉo.
Enkonduko
Kial ĉi tio estas?
La motivoj, kiuj instigis nin evoluigi CCM por Yandex.Cloud tute koincidas kun tiuj jam priskribitaj en CSI-ŝoforoj. Ni konservas multajn Kubernetes-grupojn de malsamaj nubaj provizantoj, por kiuj ni uzas ununuran ilon. Ĝi efektivigas multajn oportunojn "preterirante" la administritajn solvojn de ĉi tiuj provizantoj. Jes, ni havas sufiĉe specifan kazon kaj bezonojn, sed la evoluoj kreitaj pro ili povas esti utilaj al aliaj uzantoj.
Kio ĝuste estas CCM?
Tipe, ni preparas la medion ĉirkaŭ ni por la areto de ekstere - ekzemple uzante Terraform. Sed foje necesas administri la nuban medion ĉirkaŭ ni de areto. Ĉi tiu ebleco estas disponigita, kaj ĝi estas tio, kio estas efektivigita .
Specife, Cloud Controller Manager disponigas kvin ĉefajn specojn de interagado:
- ekzemplojn – efektivigas 1:1 rilaton inter noda objekto en Kubernetes (
Node) kaj virtuala maŝino en la nuba provizanto. Por tio ni:- plenigu la kampon
spec.providerIDen la objektoNode. Ekzemple, por OpenStack CCM ĉi tiu kampo havas la sekvan formaton:openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0. Vi povas vidi la nomon de la nuba provizanto kaj la unikan UUID de la servilo (virtuala maŝino en OpenStack) de la objekto; - komplemento
nodeInfoen la objektoNodeinformoj pri la virtuala maŝino. Ekzemple, ni specifas instantan tipon en AWS; - Ni kontrolas la ĉeeston de virtuala maŝino en la nubo. Ekzemple, se objekto
Nodeiris en statonNotReady, vi povas kontroli ĉu la virtuala maŝino entute ekzistas en la nuba provizanto perproviderID. Se ĝi ne estas tie, forigu la objektonNode, kiu alie restus en la areto por ĉiam;
- plenigu la kampon
- zonoj – fiksas la malsukcesan domajnon por la objekto
Node, por ke la planisto povas elekti nodon por la Pod laŭ la regionoj kaj zonoj en la nuba provizanto; - LoadBalancer – kiam oni kreas objekton
Servicekun tipoLoadBalancerkreas specon de balancilo, kiu direktos trafikon de ekstere al la aretnodoj. Ekzemple, en Yandex.Cloud vi povas uziNetworkLoadBalancerиTargetGrouppor ĉi tiuj celoj; - Itinero – konstruas reton inter nodoj, ĉar Laŭ Kubernetes postuloj, ĉiu pod devas havi sian propran IP-adreson kaj povi atingi ajnan alian podon. Por ĉi tiuj celoj, vi povas uzi reton (VXLAN, GENEVE) aŭ agordi tabelon de vojigo rekte en la virtuala reto de la nuba provizanto:
- volumo – Permesas dinamikan ordigon de PV uzante PVC kaj SC. Komence, ĉi tiu funkcieco estis parto de CCM, sed pro sia granda komplekseco ĝi estis movita al aparta projekto, Container Storage Interface (CSI). Ni parolis pri CSI pli ol unufoje kaj, kiel jam dirite, eĉ CSI-ŝoforo.
Antaŭe, ĉiu kodo interaganta kun la nubo troviĝis en la ĉefa Git-deponejo de la projekto Kubernetes ĉe k8s.io/kubernetes/pkg/cloudprovider/providers, sed ili decidis forlasi ĉi tion pro la malkomforto labori kun granda kodbazo. Ĉiuj malnovaj efektivigoj estis movitaj al . Por la oportuno de plia subteno kaj evoluo, ĉiuj komunaj komponentoj ankaŭ estis movitaj al .
Kiel ĉe CSI, multaj grandaj nubaj provizantoj jam desegnis siajn CCM-ojn por utiligi nubojn sur Kubernetes. Se la provizanto ne havas CCM, sed ĉiuj necesaj funkcioj disponeblas per API, tiam vi povas efektivigi CCM mem.
Por skribi vian propran efektivigon de CCM, sufiĉas efektivigi .
И .
Реализация
Kiel vi venis al ĉi tio
Ni komencis disvolvi (aŭ pli ĝuste, eĉ uzi) per por Yandex.Cloud antaŭ unu jaro.
Tamen, en ĉi tiu efektivigo ni mankis:
- aŭtentigo per JWT IAM-ĵetono;
- Serva regilo subteno.
En konsento kun la aŭtoro (dlisin) en Telegramo, ni forkigis yandex-cloud-controller-manager kaj aldonis la mankantajn funkciojn.
Ŝlosilaj trajtoj
Nuntempe, CCM subtenas la sekvajn interfacojn:
- ekzemplojn;
- zonoj;
- LoadBalancer.
Estonte, kiam Yandex.Cloud komencos labori kun altnivelaj VPC-kapabloj, ni aldonos interfacon Vojoj.
LoadBalanacer kiel ĉefa defio
Komence, ni provis, kiel aliaj CCM-efektivigoj, krei paron da LoadBalancer и TargetGroup por ĉiuj Service kun tipo LoadBalancer. Tamen, Yandex.Cloud malkovris unu interesan limigon: vi ne povas uzi TargetGroups kun intersekciĝo Targets (paro SubnetID - IpAddress).
Tial, ene de la kreita CCM, regilo estas lanĉita, kiu, kiam objektoj ŝanĝiĝas Node kolektas informojn pri ĉiuj interfacoj sur ĉiu virtuala maŝino, grupigas ilin laŭ ilia aparteno al iuj NetworkID, kreas per TargetGroup sur NetworkID, kaj ankaŭ monitoras gravecon. Poste, kiam oni kreas objekton Service kun tipo LoadBalanacer ni simple alfiksas antaŭkreitan TargetGroup al nova NetworkLoadBalanacer'estas.
Kiel ekuzi?
CCM subtenas Kubernetes-version 1.15 kaj pli altan. En areto, por ke ĝi funkciu, ĝi postulas ke la flago --cloud-provider=external estis fiksita al true por kube-apiserver, kube-controller-manager, kube-scheduler kaj ĉiuj kubeletoj.
Ĉiuj necesaj paŝoj por la instalado mem estas priskribitaj en . Instalado resumas al kreado de objektoj en Kubernetes el manifestoj.
Por uzi CCM vi ankaŭ bezonos:
- en la manifesto la dosieruja identigilo (
folder-id) Yandex.Cloud; - servokonto por interagado kun la Yandex.Cloud API. En la manifesto
Secretestas necesa de la servokonto. En la dokumentado , kiel krei servokonton kaj akiri ŝlosilojn.
Ni ĝojos ricevi viajn komentojn kaj se vi renkontas problemojn!
Rezultoj
Ni uzis la efektivigitan CCM en kvin Kubernetes-aretoj dum la lastaj du semajnoj kaj planas vastigi ilian nombron al 20 en la venonta monato. Ni nuntempe ne rekomendas uzi CCM por grandaj kaj kritikaj instalaĵoj de K8s.
Kiel en la kazo de CSI, ni ĝojos se Yandex-programistoj okupas la disvolviĝon kaj subtenon de ĉi tiu projekto - ni pretas translokigi la deponejon laŭ ilia peto por trakti taskojn, kiuj estas pli rilataj al ni.
PS
Legu ankaŭ en nia blogo:
- «»;
- «»;
- «".
fonto: www.habr.com