🥇Introductie van Kubernetes CCM (Cloud Controller Manager) voor Yandex.Cloud

In vervolg op de recente CSI-stuurprogramma release voor Yandex.Cloud publiceren we nog een Open Source-project voor deze cloud - Cloudcontrollerbeheerder. CCM is niet alleen vereist voor het cluster als geheel, maar ook voor het CSI-stuurprogramma zelf. Details over het doel ervan en enkele implementatiefuncties staan onder de snede.

Introductie

Waarom is dit?

De motieven die ons ertoe brachten CCM voor Yandex.Cloud te ontwikkelen, vallen volledig samen met de motieven die al zijn beschreven in Aankondiging CSI-chauffeurs. Wij onderhouden veel Kubernetes-clusters van verschillende cloudproviders, waarvoor we één tool gebruiken. Het implementeert tal van gemakken waarbij de beheerde oplossingen van deze providers worden “omzeild”. Ja, we hebben een vrij specifiek geval en behoeften, maar de ontwikkelingen die daardoor ontstaan, kunnen nuttig zijn voor andere gebruikers.

Wat is CCM precies?

Normaal gesproken bereiden we de omgeving om ons heen voor op het cluster van buitenaf - bijvoorbeeld met behulp van Terraform. Maar soms is het nodig om de cloudomgeving om ons heen te beheren uit cluster. Deze mogelijkheid wordt geboden en deze wordt ook geïmplementeerd CCM.

Concreet biedt Cloud Controller Manager vijf hoofdtypen interactie:

Gevallen – implementeert een 1:1-relatie tussen een knooppuntobject in Kubernetes (Node) en een virtuele machine in de cloudprovider. Hiervoor:
- vul het veld in spec.providerID in het voorwerp Node. Voor OpenStack CCM heeft dit veld bijvoorbeeld het volgende formaat: openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0. U ziet de naam van de cloudprovider en de unieke UUID van de server (virtuele machine in OpenStack) van het object;
- aanvulling nodeInfo in het voorwerp Node informatie over de virtuele machine. We specificeren bijvoorbeeld het instantietype in AWS;
- We controleren de aanwezigheid van een virtuele machine in de cloud. Bijvoorbeeld als een object Node in een staat terechtkwam NotReady, kunt u controleren of de virtuele machine überhaupt bestaat in de cloudprovider door providerID. Als het er niet is, verwijdert u het object Node, die anders voor altijd in het cluster zouden blijven;
Zones – stelt het foutdomein voor het object in Node, zodat de planner een knooppunt voor de Pod kan selecteren op basis van de regio's en zones in de cloudprovider;
Load Balancer – bij het maken van een object Service met soort LoadBalancer creëert een soort balancer die verkeer van buitenaf naar de clusterknooppunten leidt. In Yandex.Cloud kunt u bijvoorbeeld gebruiken NetworkLoadBalancer и TargetGroup voor deze doeleinden;
weg – bouwt een netwerk tussen knooppunten, omdat Volgens de vereisten van Kubernetes moet elke pod zijn eigen IP-adres hebben en elke andere pod kunnen bereiken. Voor deze doeleinden kunt u een overlay-netwerk (VXLAN, GENEVE) gebruiken of een routeringstabel rechtstreeks in het virtuele netwerk van de cloudprovider instellen:
Volume – Maakt dynamisch bestellen van PV mogelijk met behulp van PVC en SC. Aanvankelijk was deze functionaliteit onderdeel van CCM, maar vanwege de grote complexiteit werd deze verplaatst naar een apart project, Container Storage Interface (CSI). We hebben het meer dan eens over CSI gehad писали en, zoals al gezegd, zelfs vrijgelaten CSI-chauffeur.

Voorheen bevond alle code die met de cloud communiceerde zich in de hoofdopslagplaats van Git van het Kubernetes-project op k8s.io/kubernetes/pkg/cloudprovider/providers, maar ze besloten hiervan af te zien vanwege het ongemak van het werken met een grote codebasis. Alle oude implementaties zijn verplaatst naar aparte opslagplaats. Voor het gemak van verdere ondersteuning en ontwikkeling zijn ook alle gemeenschappelijke componenten verplaatst naar aparte opslagplaats.

Net als bij CSI hebben veel grote cloudproviders hun CCM's al ontworpen om gebruik te maken van clouds op Kubernetes. Indien de leverancier niet over CCM beschikt, maar alle benodigde functionaliteiten via API beschikbaar zijn, dan kunt u CCM zelf implementeren.

Om uw eigen implementatie van CCM te schrijven, volstaat het om te implementeren vereiste Go-interfaces.

И dit is wat we kregen.

uitvoering

Hoe ben je zover gekomen

We zijn begonnen met de ontwikkeling (of beter gezegd, het gebruik ervan). klaar(!) CCM voor Yandex.Cloud een jaar geleden.

In deze implementatie misten we echter:

authenticatie via JWT IAM-token;
Ondersteuning van servicecontrollers.

In overleg met de auteur (dlisin) in Telegram hebben we yandex-cloud-controller-manager geforkt en de ontbrekende functies toegevoegd.

Belangrijkste kenmerken

Momenteel ondersteunt CCM de volgende interfaces:

Gevallen;
Zones;
Load Balancer.

Wanneer Yandex.Cloud in de toekomst gaat werken met geavanceerde VPC-mogelijkheden, zullen we een interface toevoegen routes.

LoadBalanacer als belangrijkste uitdaging

In eerste instantie probeerden we, net als andere CCM-implementaties, een paar te maken LoadBalancer и TargetGroup voor iedereen Service met soort LoadBalancer. Yandex.Cloud ontdekte echter één interessante beperking: je kunt er geen gebruik van maken TargetGroups met kruisen Targets (paar SubnetID - IpAddress).

Daarom wordt binnen de gecreëerde CCM een controller gelanceerd, die wanneer objecten verandert Node verzamelt informatie over alle interfaces op elke virtuele machine en groepeert deze op basis van hun lidmaatschap NetworkID, gemaakt door TargetGroup op NetworkID, en bewaakt ook de relevantie. Vervolgens bij het maken van een object Service met soort LoadBalanacer we voegen eenvoudigweg een vooraf gemaakt bestand toe TargetGroup naar nieuw NetworkLoadBalanacer'ben.

Hoe begin je het te gebruiken?

CCM ondersteunt Kubernetes versie 1.15 en hoger. Om in een cluster te kunnen werken, is de vlag vereist --cloud-provider=external was ingesteld true voor kube-apiserver, kube-controller-manager, kube-scheduler en alle kubelets.

Alle noodzakelijke stappen voor de installatie zelf worden beschreven in README. Installatie komt neer op het maken van objecten in Kubernetes op basis van manifesten.

Om CCM te gebruiken heeft u ook het volgende nodig:

specificeren in het manifest de directory-ID (folder-id) Yandex.Cloud;
serviceaccount voor interactie met de Yandex.Cloud API. In het manifest Secret noodzakelijk geautoriseerde sleutels overdragen van het serviceaccount. In de documentatie beschreven, hoe u een serviceaccount kunt maken en sleutels kunt verkrijgen.

Wij ontvangen graag uw feedback en nieuwe problemenals u problemen ondervindt!

Resultaten van

We hebben de geïmplementeerde CCM de afgelopen twee weken in vijf Kubernetes-clusters gebruikt en zijn van plan hun aantal de komende maand uit te breiden naar twintig. Momenteel raden we het gebruik van CCM af voor grote en kritische K20s-installaties.

Net als in het geval van CSI zullen we blij zijn als Yandex-ontwikkelaars de ontwikkeling en ondersteuning van dit project op zich nemen - we zijn bereid om de repository op hun verzoek over te dragen om taken uit te voeren die voor ons relevanter zijn.

Introductie van Kubernetes CCM (Cloud Controller Manager) voor Yandex.Cloud