V návaznosti na nedávné pro Yandex.Cloud publikujeme další Open Source projekt pro tento cloud - . CCM je vyžadován nejen pro cluster jako celek, ale také pro samotný ovladač CSI. Podrobnosti o jeho účelu a některých funkcích implementace jsou pod řezem.
úvod
Proč je to?
Motivy, které nás vedly k vývoji CCM pro Yandex.Cloud, se zcela shodují s těmi, které již byly popsány v CSI ovladače. Udržujeme mnoho clusterů Kubernetes od různých poskytovatelů cloudu, pro které používáme jediný nástroj. Implementuje řadu vymožeností, které „obcházejí“ řízená řešení těchto poskytovatelů. Ano, máme poměrně specifický případ a potřeby, ale vývoj vytvořený kvůli nim může být užitečný pro ostatní uživatele.
Co je to vlastně CCM?
Obvykle na cluster připravujeme prostředí kolem nás z vnějšku - například pomocí Terraformu. Někdy je ale potřeba spravovat cloudové prostředí kolem nás z clusteru. Tato možnost je poskytována a je implementována .
Cloud Controller Manager konkrétně poskytuje pět hlavních typů interakce:
- Instance – implementuje vztah 1:1 mezi objektem uzlu v Kubernetes (
Node) a virtuální počítač u poskytovatele cloudu. Za to my:- vyplňte pole
spec.providerIDv objektuNode. Například pro OpenStack CCM má toto pole následující formát:openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0. Můžete vidět název poskytovatele cloudu a jedinečné UUID serveru (virtuální počítač v OpenStack) objektu; - doplněk
nodeInfov objektuNodeinformace o virtuálním stroji. Například uvedeme typ instance v AWS; - Kontrolujeme přítomnost virtuálního stroje v cloudu. Například pokud objekt
Nodepřešel do stavuNotReady, můžete zkontrolovat, zda virtuální počítač u poskytovatele cloudu vůbec existujeproviderID. Pokud tam není, odstraňte objektNode, které by jinak v klastru zůstaly navždy;
- vyplňte pole
- Zóny – nastavuje doménu selhání pro objekt
Node, takže plánovač může vybrat uzel pro Pod podle regionů a zón u poskytovatele cloudu; - LoadBalancer – při vytváření objektu
Services typemLoadBalancervytváří jakýsi balancer, který bude směrovat provoz zvenčí do uzlů clusteru. Například v Yandex.Cloud můžete použítNetworkLoadBalancerиTargetGrouppro tyto účely; - Trasa – buduje síť mezi uzly, protože Podle požadavků Kubernetes musí mít každý modul svou vlastní IP adresu a musí být schopen dosáhnout na jakýkoli jiný modul. Pro tyto účely můžete použít překryvnou síť (VXLAN, GENEVE) nebo nastavit směrovací tabulku přímo ve virtuální síti poskytovatele cloudu:
- Hlasitost – Umožňuje dynamické řazení FV pomocí PVC a SC. Zpočátku byla tato funkcionalita součástí CCM, ale kvůli své velké složitosti byla přesunuta do samostatného projektu, Container Storage Interface (CSI). O CSI jsme mluvili více než jednou a jak již bylo zmíněno, dokonce CSI ovladač.
Dříve byl veškerý kód interagující s cloudem umístěn v hlavním úložišti Git projektu Kubernetes na adrese k8s.io/kubernetes/pkg/cloudprovider/providers, ale rozhodli se od toho upustit kvůli nepohodlnosti práce s velkou kódovou základnou. Všechny staré implementace byly přesunuty . Pro pohodlí další podpory a vývoje byly také přesunuty všechny běžné komponenty .
Stejně jako u CSI, mnoho velkých poskytovatelů cloudu již navrhlo své CCM tak, aby využívalo cloudy na Kubernetes. Pokud dodavatel nemá CCM, ale všechny potřebné funkce jsou dostupné přes API, pak si můžete CCM zavést sami.
K napsání vlastní implementace CCM stačí implementovat .
И .
uskutečnění
Jak jsi k tomu přišel
Vývoj (nebo spíše používání) jsme začali s pro Yandex.Cloud před rokem.
V této implementaci nám však chybělo:
- autentizace prostřednictvím tokenu JWT IAM;
- Podpora servisního ovladače.
Po dohodě s autorem (dlisin) v Telegramu jsme forkovali yandex-cloud-controller-manager a přidali chybějící funkce.
Klíčové vlastnosti
V současné době CCM podporuje následující rozhraní:
- Instance;
- Zóny;
- LoadBalancer.
V budoucnu, až Yandex.Cloud začne pracovat s pokročilými možnostmi VPC, přidáme rozhraní trasy.
LoadBalanacer jako hlavní výzva
Zpočátku jsme se snažili, stejně jako ostatní implementace CCM, vytvořit pár LoadBalancer и TargetGroup pro každého Service s typem LoadBalancer. Yandex.Cloud však objevil jedno zajímavé omezení: nemůžete použít TargetGroups s protínající se Targets (pár SubnetID - IpAddress).
Proto se uvnitř vytvořeného CCM spustí řadič, který při změně objektů Node shromažďuje informace o všech rozhraních na každém virtuálním počítači, seskupuje je podle jejich příslušnosti k určitému NetworkID, vytváří podle TargetGroup na NetworkIDa také sleduje relevanci. Následně při vytváření objektu Service s typem LoadBalanacer jednoduše přiložíme předem vytvořený TargetGroup k novému NetworkLoadBalanacer'dopoledne.
Jak ho začít používat?
CCM podporuje Kubernetes verze 1.15 a vyšší. V clusteru, aby fungoval, vyžaduje příznak --cloud-provider=external byla nastavena na true pro kube-apiserver, kube-controller-manager, kube-scheduler a všechny kubelety.
Všechny potřebné kroky pro samotnou instalaci jsou popsány v . Instalace se scvrkává na vytváření objektů v Kubernetes z manifestů.
K použití CCM budete také potřebovat:
- v manifestu identifikátor adresáře (
folder-id) Yandex.Cloud; - servisní účet pro interakci s rozhraním Yandex.Cloud API. V manifestu
Secretnutný ze servisního účtu. V dokumentaci , jak si vytvořit servisní účet a získat klíče.
Budeme rádi za vaši zpětnou vazbu a pokud narazíte na nějaké problémy!
Výsledky
Implementované CCM jsme během posledních dvou týdnů používali v pěti clusterech Kubernetes a plánujeme jejich počet v nadcházejícím měsíci rozšířit na 20. V současné době nedoporučujeme používat CCM pro velké a kritické instalace K8.
Stejně jako v případě CSI budeme rádi, pokud vývoj a podporu tohoto projektu převezmou vývojáři Yandexu - jsme připraveni na jejich žádost převést úložiště, abychom mohli řešit úkoly, které jsou pro nás relevantnější.
PS
Přečtěte si také na našem blogu:
- «";
- «";
- «".
Zdroj: www.habr.com