Einführung von Kubernetes CCM (Cloud Controller Manager) für Yandex.Cloud

In Fortsetzung der jüngsten CSI-Treiberversion Für Yandex.Cloud veröffentlichen wir ein weiteres Open-Source-Projekt für diese Cloud – Cloud Controller Manager. CCM ist nicht nur für den Cluster als Ganzes erforderlich, sondern auch für den CSI-Treiber selbst. Details zu seinem Zweck und einigen Implementierungsfunktionen sind unten aufgeführt.

Einführung

Warum ist das so?

Die Beweggründe, die uns dazu veranlasst haben, CCM für Yandex.Cloud zu entwickeln, stimmen vollständig mit den bereits beschriebenen überein Bekanntmachung CSI-Treiber. Wir betreuen viele Kubernetes-Cluster verschiedener Cloud-Anbieter, für die wir ein einziges Tool nutzen. Es implementiert zahlreiche Annehmlichkeiten und „umgeht“ die verwalteten Lösungen dieser Anbieter. Ja, wir haben einen eher spezifischen Fall und Bedarf, aber die daraus resultierenden Entwicklungen können für andere Benutzer nützlich sein.

Was genau ist CCM?

Normalerweise bereiten wir die Umgebung um uns herum auf den Cluster vor von außen - zum Beispiel mit Terraform. Aber manchmal besteht die Notwendigkeit, die Cloud-Umgebung um uns herum zu verwalten aus dem Cluster. Diese Möglichkeit ist gegeben und wird auch umgesetzt CCM.

Konkret bietet Cloud Controller Manager fünf Haupttypen der Interaktion:

1. Instanzen – implementiert eine 1:1-Beziehung zwischen einem Knotenobjekt in Kubernetes (Node) und eine virtuelle Maschine beim Cloud-Anbieter. Dafür haben wir:
   • Füllen Sie das Feld aus spec.providerID im Objekt Node. Für OpenStack CCM hat dieses Feld beispielsweise das folgende Format: openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0. Sie können den Namen des Cloud-Anbieters und die eindeutige UUID des Servers (virtuelle Maschine in OpenStack) des Objekts sehen;
   • ergänzen nodeInfo im Objekt Node Informationen zur virtuellen Maschine. Beispielsweise geben wir den Instanztyp in AWS an;
   • Wir prüfen das Vorhandensein einer virtuellen Maschine in der Cloud. Zum Beispiel, wenn ein Objekt Node ging in einen Staat NotReadykönnen Sie prüfen, ob die virtuelle Maschine beim Cloud-Anbieter überhaupt vorhanden ist providerID. Wenn es nicht vorhanden ist, löschen Sie das Objekt Node, der andernfalls für immer im Cluster verbleiben würde;
2. Zonen – legt die Fehlerdomäne für das Objekt fest Node, damit der Planer einen Knoten für den Pod entsprechend den Regionen und Zonen im Cloud-Anbieter auswählen kann;
3. Lastenausgleicher – beim Erstellen eines Objekts Service mit Typ LoadBalancer erstellt eine Art Balancer, der den Datenverkehr von außen zu den Clusterknoten leitet. Sie können beispielsweise Yandex.Cloud verwenden NetworkLoadBalancer и TargetGroup für diese Zwecke;
4. Straße – baut ein Netzwerk zwischen Knoten auf, weil Gemäß den Kubernetes-Anforderungen muss jeder Pod eine eigene IP-Adresse haben und jeden anderen Pod erreichen können. Für diese Zwecke können Sie ein Overlay-Netzwerk (VXLAN, GENEVE) verwenden oder eine Routing-Tabelle direkt im virtuellen Netzwerk des Cloud-Anbieters festlegen:

   

5. Volume – Ermöglicht die dynamische Bestellung von PV mithilfe von PVC und SC. Ursprünglich war diese Funktionalität Teil von CCM, wurde aber aufgrund ihrer großen Komplexität in ein separates Projekt, Container Storage Interface (CSI), verschoben. Wir haben mehr als einmal über CSI gesprochen schrieb und, wie bereits erwähnt, sogar freigegeben CSI-Treiber.

Zuvor befand sich der gesamte Code, der mit der Cloud interagierte, im Haupt-Git-Repository des Kubernetes-Projekts unter k8s.io/kubernetes/pkg/cloudprovider/providers, aber sie beschlossen, dies aufzugeben, da die Arbeit mit einer großen Codebasis unpraktisch war. Alle alten Implementierungen wurden verschoben separates Repository. Zur Erleichterung der weiteren Unterstützung und Entwicklung wurden auch alle gängigen Komponenten verschoben separates Repository.

Wie bei CSI haben viele große Cloud-Anbieter ihre CCMs bereits so konzipiert, dass sie Clouds auf Kubernetes nutzen. Wenn der Lieferant nicht über CCM verfügt, aber alle notwendigen Funktionen per API verfügbar sind, dann können Sie CCM selbst implementieren.

Um Ihre eigene CCM-Implementierung zu schreiben, reicht es aus, sie zu implementieren erforderliche Go-Schnittstellen.

И Das haben wir bekommen.

Implementierung

Wie bist du dazu gekommen?

Wir haben mit der Entwicklung (oder besser gesagt sogar der Nutzung) begonnen fertig(!) CCM für Yandex.Cloud vor einem Jahr.

Allerdings fehlten uns in dieser Umsetzung:

• Authentifizierung über JWT IAM-Token;
• Unterstützung für Service-Controller.

Im Einvernehmen mit dem Autor (dlisin) In Telegram haben wir den Yandex-Cloud-Controller-Manager geforkt und die fehlenden Funktionen hinzugefügt.

Основные возможности

Derzeit unterstützt CCM die folgenden Schnittstellen:

• Instanzen;
• Zonen;
• Lastenausgleicher.

Wenn Yandex.Cloud in Zukunft mit erweiterten VPC-Funktionen arbeitet, werden wir eine Schnittstelle hinzufügen Routen.

LoadBalanacer als größte Herausforderung

Zunächst haben wir versucht, wie bei anderen CCM-Implementierungen ein Paar zu erstellen LoadBalancer и TargetGroup für jeden Service mit Typ LoadBalancer. Yandex.Cloud hat jedoch eine interessante Einschränkung festgestellt: Sie können es nicht verwenden TargetGroups mit Kreuzung Targets (Paar SubnetID - IpAddress).

Daher wird innerhalb des erstellten CCM ein Controller gestartet, der bei Objektänderungen reagiert Node sammelt Informationen über alle Schnittstellen auf jeder virtuellen Maschine und gruppiert sie entsprechend ihrer Zugehörigkeit zu bestimmten NetworkID, erstellt von TargetGroup auf NetworkIDund überwacht auch die Relevanz. Anschließend beim Erstellen eines Objekts Service mit Typ LoadBalanacer Wir fügen einfach eine vorgefertigte Datei bei TargetGroup zu neuen NetworkLoadBalanacer'Bin.

Wie fange ich an, es zu verwenden?

CCM unterstützt Kubernetes Version 1.15 und höher. Damit es in einem Cluster funktioniert, ist das Flag erforderlich --cloud-provider=external eingestellt wurde true für kube-apiserver, kube-controller-manager, kube-scheduler und alle kubelets.

Alle notwendigen Schritte zur Installation selbst sind in beschrieben README. Bei der Installation geht es darum, aus Manifesten Objekte in Kubernetes zu erstellen.

Um CCM nutzen zu können, benötigen Sie außerdem:

• angeben im Manifest die Verzeichniskennung (folder-id) Yandex.Cloud;
• Dienstkonto für die Interaktion mit der Yandex.Cloud-API. Im Manifest Secret notwendig autorisierte Schlüssel übertragen vom Dienstkonto. In der Dokumentation beschrieben, wie man ein Dienstkonto erstellt und Schlüssel erhält.

Wir freuen uns über Ihr Feedback und neue Themenwenn Sie auf Probleme stoßen!

Ergebnisse

Wir nutzen das implementierte CCM in den letzten zwei Wochen in fünf Kubernetes-Clustern und planen, deren Anzahl im kommenden Monat auf 20 zu erweitern. Wir empfehlen derzeit nicht, CCM für große und kritische K8-Installationen zu verwenden.

Wie im Fall von CSI würden wir uns freuen, wenn Yandex-Entwickler die Entwicklung und Unterstützung dieses Projekts übernehmen würden – wir sind bereit, das Repository auf ihren Wunsch zu übertragen, um für uns relevantere Aufgaben zu erledigen.

PS

Lesen Sie auch auf unserem Blog:

• «Unsere Erfahrung bei der Entwicklung eines CSI-Treibers in Kubernetes für Yandex.Cloud";
• «Ist es einfach und bequem, einen Kubernetes-Cluster vorzubereiten? Ankündigung des Addon-Betreibers";
• «Kubernetes erweitern und ergänzen (Rezension und Videobericht)".

Source: habr.com