Quelle｜KubeAdmiral Open-Source-Community
Projektadresse: https://github.com/kubewharf/kubeadmiral
Seit seiner Veröffentlichung als Open Source im Jahr 2014 hat sich Kubernetes zum De-facto-Standard für Orchestrierungs- und Planungssysteme entwickelt und bietet Entwicklern großen Komfort. Da immer mehr Unternehmen Cloud-nativ einsetzen, beschleunigt sich der Umfang der globalen Cloud-Infrastruktur immer noch. Der 5.000-Knoten-Einzelcluster der Kubernetes-Community-Version ist nicht mehr in der Lage, groß angelegte Anwendungsszenarien auf Unternehmensebene zu erfüllen. Immer mehr Unternehmen entscheiden sich für die Verwendung einer Multi-Cloud-Architektur, um ihre Anforderungen zu erfüllen. Angesichts der Anforderungen an Kostensenkung und Effizienzsteigerung, Remote-Disaster-Recovery und Umgebungsisolierung wird die Notwendigkeit einer Multi-Cluster-Verwaltung immer offensichtlicher.
Hintergrund
Mit der rasanten Geschäftsentwicklung ist auch die Anzahl der Kubernetes-Cluster innerhalb von ByteDance weiter gewachsen. Die Anzahl der Cluster liegt bei über 500 und die Anzahl der Anwendungskopien liegt zwischen 0 und 20.000.
In der Anfangszeit verfügte jeder Geschäftsbereich von Byte aus Isolations- und Sicherheitsgründen über exklusive Cluster. Diese exklusiven Cluster führten zu Ressourceninseln, die sich letztendlich auf die elastische Effizienz der Ressourcen auswirkten. Dies spiegelt sich erstens in der Notwendigkeit wider, unabhängige Puffer für jeden Geschäftsbereich vorzuhalten; zweitens ist das Unternehmen stark an den Cluster gebunden, das Unternehmen ist sich der großen Anzahl von Clustern bewusst und weist der Anwendung auch Ressourcen zwischen den Clustern zu muss das Unternehmen und die Cluster im Hinblick auf die Betriebsressourcen genau kennen, was letztendlich zu einem langsamen Ressourcenaustausch zwischen verschiedenen Geschäftsbereichen, einer geringen Automatisierungseffizienz und suboptimalen Bereitstellungsraten führt. Daher müssen wir eine Föderation einführen, die Bindungsbeziehung zwischen Anwendungen und Clustern entkoppeln, die Ressourcen jedes Geschäftsbereichs bündeln, Puffer reduzieren und die Automatisierungseffizienz von Ressourcen verbessern.
Da Multi-Cloud und Hybrid-Cloud zunehmend zu Mainstream-Formen in der Branche werden und Kubernetes zu einem Cloud-nativen Betriebssystem wird, werden verschiedene Infrastrukturen weiter abstrahiert und standardisiert, um einheitlichere Standardschnittstellen für Anwendungen bereitzustellen. Auf dieser Grundlage hoffen wir, die Föderation als Basis des Cloud-nativen Systems in verteilten Cloud-Szenarien einzuführen, einen einheitlichen Plattformeingang für Anwendungen bereitzustellen, die Fähigkeit zur Verteilung von Anwendungen über Cluster hinweg zu verbessern und bei der Verteilung und Planung von Anwendungen übergreifend gute Arbeit zu leisten Cluster und verwalten Sie mehrere Cloud-Infrastrukturen in nativen Szenarien.
KubeFed V2-Byte-Implementierung
Angesichts der Herausforderungen, die das Multi-Cluster-Management mit sich bringt, begann das Infrastrukturteam 2019 mit dem Aufbau einer Cluster-Föderation auf Basis der Community KubeFed V2 . KubeFed V2 unterscheidet zwischen Master-Clustern und Mitgliedsclustern. Benutzer erstellen „Föderationsobjekte“ im Master-Cluster, und mehrere KubeFed-Controller verteilen Ressourcen auf Mitgliedscluster basierend auf Föderationsobjekten. Das Verbundobjekt verfügt über drei Felder: Vorlage (Objektvorlage), Platzierung (Zielcluster) und Überschreibungen (Clusterdifferenzierung), um den Bereitstellungsstatus des Objekts anzugeben. Sie können beispielsweise ein FederatedDeployment wie unten gezeigt im Master-Cluster für die Bereitstellungsverteilung erstellen:
apiVersion: types.kubefed.k8s.io/v1beta1
kind: FederatedDeployment
metadata:
name: test-deployment
namespace: test-namespace
spec:
template: # 定义 Deployment 的所有內容，可理解成 Deployment 与 Pod template 之间的关联。
metadata:
labels:
app: nginx
spec:
...
placement:
# 分发到指定的两个集群中
clusters:
- name: cluster1
- name: cluster2
overrides:
# 在cluster2中修改副本数为5
- clusterName: cluster2
clusterOverrides:
- path: spec.replicas
value: 5
Für Bereitstellungen und ReplicaSets ermöglicht KubeFed auch die Angabe erweiterter Replikatverteilungsstrategien über ReplicaSchedulingPreference (RSP). Benutzer können die Gewichtung sowie die minimale und maximale Anzahl von Replikaten jedes Clusters auf RSP konfigurieren, und der RSP-Controller berechnet automatisch die Platzierung und überschreibt Felder und aktualisiert FederatedDeployment oder FederatedReplicaSet.
Bildquelle: https://www.kubernetes.org.cn/5702.html
Bei der Implementierung stellten wir jedoch fest, dass KubeFed die Anforderungen der Produktionsumgebung nicht erfüllen konnte:
- Geringe Ressourcenauslastung – KubeFeds Replikationsplanungsrichtlinie RSP kann nur statische Gewichtungen für jeden Mitgliedscluster festlegen und kann nicht flexibel auf Änderungen der Clusterressourcen reagieren, was zu ungleichmäßigen Bereitstellungsniveaus verschiedener Mitgliedscluster führt.
- Änderungen verlaufen nicht reibungslos genug: Beim Hoch- oder Herunterskalieren kommt es häufig zu einer ungleichmäßigen Verteilung der Instanzen, was zu eingeschränkten Disaster-Recovery-Funktionen führt.
- Semantische Einschränkungen bei der Planung – nur gute Unterstützung für zustandslose Ressourcen, unzureichende Unterstützung für verschiedene Ressourcen wie zustandsbehaftete Dienste und Jobs und schlechte Planungsskalierbarkeit.
- Die Zugriffskosten sind hoch – sie müssen durch die Erstellung von Verbundobjekten verteilt werden, sie sind nicht mit nativen APIs kompatibel und Benutzer und die obere Plattform müssen ihre Nutzungsgewohnheiten vollständig ändern.
Mit der Weiterentwicklung der Infrastruktur von Bytedance haben wir gleichzeitig höhere Anforderungen an Effizienz, Skalierbarkeit, Leistung und Kosten gestellt, da Geschäftsszenarien wie zustandsbehaftete Dienste, Speicher, Offline-Betrieb und maschinelles Lernen zunehmend Cloud-nativ umfassen und vielfältige Funktionen unterstützen Clusterübergreifende Orchestrierungs- und Planungsfunktionen in speziellen Szenarien werden immer wichtiger. Aus diesem Grund haben wir Ende 2021 ein Cluster-Föderationssystem der neuen Generation KubeAdmiral auf Basis von KubeFed v2 entwickelt.
Evolution der KubeAdmiral-Architektur
Der Name KubeAdmiral leitet sich von Admiral (ausgesprochen [ˈædm(ə)rəl]) ab, was ursprünglich Flottenkommandant bedeutet. Das Hinzufügen des Präfixes Kube(rnetes) bedeutet, dass das Tool über leistungsstarke Kubernetes-Multi-Cluster-Orchestrierungs- und Planungsfunktionen verfügt.
KubeAdmiral unterstützt die native Kubernetes-API, bietet ein umfangreiches und skalierbares Planungsframework und optimiert sorgfältig den Planungsalgorithmus und den Verteilungsprozess. Einige bemerkenswerte Funktionen werden im Folgenden ausführlich beschrieben:
1. Umfangreiche Multi-Cluster-Planungsfunktionen
Der Scheduler ist die Kernkomponente des Verbundsystems. Er ist für die Zuweisung von Ressourcen an Mitgliedscluster verantwortlich. Im Replikatplanungsszenario ist er auch für die Berechnung der Replikate verantwortlich, die jeder Cluster verdient , Ressourceneffizienz, wichtige Merkmale wie Stabilität.
KubeFed stellt den RSP-Scheduler für die Replikatplanung bereit, seine Anpassungsfähigkeit und Skalierbarkeit ist jedoch unzureichend. Um sein Verhalten zu ändern, muss der Code geändert werden. Gleichzeitig fehlt ihm die Unterstützung für zustandsbehaftete Dienste , Jobressourcen usw.
KubeAdmiral führt eine umfassendere Planungssemantik ein, unterstützt eine flexiblere Clusterauswahl durch Labels, Flecken usw., bietet zustandsbehaftete Ressourcenplanungsfunktionen vom Jobtyp und führt Optimierungen wie die Abhängigkeitsverfolgungsplanung ein. Die Semantik der Planung kann wie unten gezeigt über das PropagationPolicy-Objekt konfiguriert werden:
apiVersion: core.kubeadmiral.io/v1alpha1
kind: PropagationPolicy
metadata:
name: mypolicy
namespace: default
spec:
# 提供多种集群选择方式，最终结果取交集
placement: # 手动指定集群与权重
- cluster: Cluster-01
preferences:
weight: 40
- cluster: Cluster-02
preferences:
weight: 30
- cluster: Cluster-03
preferences:
weight: 40
clusterSelector: # 类似Pod.Spec.NodeSelector，通过label过滤集群
IPv6: "true"
clusterAffinity: # 类似Pod.Spec.NodeAffinity，通过label过滤集群，语法比clusterSelector更加灵活
- matchExpressions:
- key: region
operator: In
values:
- beijing
tolerations: # 通过污点过滤集群
- key: "key1"
operator: "Equal"
value: "value1"
effect: "NoSchedule"
schedulingMode: Divide # 是否为副本数调度
stickyCluster: false # 仅在首次调度，适合有状态服务或作业类服务
maxClusters: 1 # 最多可分发到多少个子集群，适合有状态服务或作业类服务
disableFollowerScheduling: false # 是否开启依赖调度
Gleichzeitig kann OverridePolicy für Ressourcen verwendet werden, die für verschiedene Cluster geplant sind, um anhand von Clusternamen oder -bezeichnungen zu unterscheiden:
apiVersion: core.kubeadmiral.io/v1alpha1
kind: OverridePolicy
metadata:
name: example
namespace: default
spec:
# 最终匹配的集群是所有rule匹配集群的交集
overrideRules:
- targetClusters:
# 通过名称匹配集群
clusters:
- member1
- member2
# 通过标签selector匹配集群
clusterSelector:
region: beijing
az: zone1
# 通过基于标签的affinity匹配集群
clusterAffinity:
- matchExpressions:
- key: region
operator: In
values:
- beijing
- key: provider
operator: In
values:
- volcengine
# 在匹配的集群中，使用jsonpatch语法修改第一个容器的镜像
overriders:
jsonpatch:
- path: "/spec/template/spec/containers/0/image"
operator: replace
value: "nginx:test"
2. Die Planungsmöglichkeiten können erweitert werden
KubeAdmiral bezieht sich auf das Design von Kube-Scheduler und bietet ein erweiterbares Planungs-Framework. Es abstrahiert die Planungslogik in vier Schritte: Filtern, Bewerten, Auswählen und Replikat, und verwendet mehrere relativ unabhängige Plug-Ins, um seine Logik in jedem Schritt zu implementieren. Fast jedes Feld in der in der Abbildung oben gezeigten PropagaionPolicy wird durch ein unabhängiges integriertes Planungs-Plug-In implementiert. Die Plug-Ins stören sich nicht gegenseitig und der Scheduler ruft die erforderlichen Plug-Ins für die globale Orchestrierung auf.
Darüber hinaus unterstützt der KubeAdmiral-Planer auch die Interaktion mit externen Plug-Ins über das HTTP-Protokoll. Benutzer können benutzerdefinierte Planungslogik schreiben und bereitstellen, um den Anforderungen des Zugriffs auf das interne System des Unternehmens für die Planung gerecht zu werden. Das integrierte Plug-in implementiert allgemeinere Funktionen und ergänzt das externe Plug-in. Benutzer können die Planungslogik mit minimalen Kosten und ohne Änderung der Verbundsteuerungsebene erweitern und sich bei der Planung auf die leistungsstarke Multi-Cluster-Verteilungsfunktion von KubeAdmiral verlassen Ergebnisse effektiv.
3. Automatische Migration, wenn die Anwendungsplanung fehlschlägt
Für von Replikaten geplante Ressourcen berechnet KubeAdmiral, wie viele Replikate jeder Mitgliedscluster verdient, überschreibt die Anzahl der Replikatfelder und stellt sie dann jedem Mitgliedscluster zur Verfügung. Dieser Prozess wird als föderierte Planung bezeichnet. Der Scheduler weist den der Ressource entsprechenden Pod dem entsprechenden Knoten zu. Dieser Prozess wird zur Single-Cluster-Planung.
Nachdem Ressourcen ausgegeben wurden, kann die Einzelclusterplanung manchmal fehlschlagen, weil der Knoten offline ist, nicht genügend Ressourcen vorhanden sind, die Knotenaffinität nicht erfüllt ist usw. Wenn dies nicht behoben wird, sind die verfügbaren Geschäftsinstanzen geringer als erwartet. KubeAdmiral bietet die Funktion der automatischen Migration, wenn die Planung fehlschlägt. Wenn sie aktiviert ist, kann sie nicht planbare Replikate in Mitgliedsclustern identifizieren und sie zu Clustern migrieren, die redundante Replikate aufnehmen können, wodurch ein Ressourcenumsatz in mehreren Clustern realisiert wird.
Beispielsweise werden den drei Clustern A, B und C 6 Kopien mit gleichem Gewicht zugewiesen. Nach der anfänglichen Föderationsplanung werden jedem Cluster 2 Kopien zugewiesen. Wenn zwei Kopien in Cluster C nicht in einem einzelnen Cluster geplant werden können, migriert KubeAdmiral sie automatisch nach A und B.
| Cluster | A | B | C |
|---|---|---|---|
| Gewichte | 1 | 1 | 1 |
| Anzahl der ersten föderierten Planungsinstanzen | 2 | 2 | 2 |
| Replikate, die nicht in einem einzelnen Cluster geplant werden können | 0 | 0 | 2 |
| Anzahl der föderierten Planungsinstanzen nach der automatischen Migration | 3 | 3 | 0 |
4. Planen Sie Ressourcen dynamisch basierend auf den Cluster-Wasserständen
In einer Multi-Cluster-Umgebung ändern sich die Ressourcenniveaus jedes Clusters dynamisch, wenn Maschinen online und offline gehen. Wenn man sich nur auf die von KubeFed RSP bereitgestellten statischen Gewichtungsplanungsreplikate verlässt, kann dies leicht zu ungleichmäßigen Cluster-Wasserniveaus führen Bei Service-Upgrades treten offenbar Probleme auf, und Cluster-Ressourcen mit einer geringen Bereitstellungsrate können nicht vollständig genutzt werden. In diesem Zusammenhang führt KubeAdmiral eine dynamische Gewichtsplanung basierend auf dem Cluster-Wasserstand ein. Es berechnet die verfügbare Menge, indem es die Gesamtressourcenmenge und -nutzung jedes Clusters erfasst und die verfügbare Ressourcenmenge als Gewicht der Kopierplanung verwendet, um letztendlich einen Lastausgleich zu erreichen Die Bereitstellungsrate aller Mitgliedscluster liegt bei über 95 %.
5. Verbesserung des Kopierzuteilungsalgorithmus
Der Kopiezuordnungsalgorithmus von KubeFed führt häufig dazu, dass die Anzahl der Instanzen beim Hoch- oder Herunterskalieren von den Erwartungen abweicht, zum Beispiel:
30 Instanzen sind auf drei Mitgliedscluster A, B und C verteilt. Im Fall von rsp.rebalance = false möchte der Benutzer auf 15 Instanzen herunterskalieren:
Vor dem Schrumpfen:
| Cluster | A | B | C |
|---|---|---|---|
| Gewichte | 10 | 10 | 10 |
| Anzahl der Instanzen | 15 | 15 | 0 |
Nach dem Schrumpfen:
| Cluster | A | B | C |
|---|---|---|---|
| Gewichte | 10 | 10 | 10 |
| Anzahl der Instanzen | 15 | 0 | 0 |
Der Grund für dieses Phänomen liegt darin, dass der Replikationsalgorithmus von KubeFed zunächst die Anzahl der derzeit im Cluster vorhandenen Instanzen zuweist und dann die verbleibenden Instanzen entsprechend der Gewichtung jedes Clusters zuweist Dies führt zu einer gravierenden Abweichung zwischen Instanzverteilung und Gewicht.
KubeAdmiral optimiert den Kopieralgorithmus von KubeFed, um die endgültige Verteilung so nah wie möglich an einer Gewichtsverteilung zu machen und gleichzeitig sicherzustellen, dass es während der Expansion und Kontraktion nicht zu unerwarteten Migrationen kommt. Am Beispiel einer Skalierung von 30 auf 15 Instanzen sieht der vereinfachte Algorithmusprozess wie folgt aus:
- aktuelle Verteilung = [15, 15, 0], Replikate insgesamt: 30
- gewünschte Verteilung = [5, 5, 5], Replikate insgesamt: 15
- Distanz = gewünscht – aktuell = [-10, -10, 5], Gesamtdistanz: 15
- Entfernen Sie für schrumpfende Szenarien den positiven Term Abstand = [-10, -10, 0]
- Unter Verwendung der Entfernung als Gewicht die Differenz neu verteilen 15: [-7, -8, 0]
- Endgültiges Planungsergebnis: [-7, -8, 0] + [15, 15, 0] -> [8, 7, 0]
| Cluster | A | B | C |
|---|---|---|---|
| Gewichte | 10 | 10 | 10 |
| Anzahl der Instanzen | 8 | 7 | 0 |
6. Unterstützen Sie native Ressourcen
Im Gegensatz zu KubeFed, bei dem Benutzer eine völlig inkompatible neue API verwenden müssen, geht KubeAdmiral auf die Nutzungsgewohnheiten von Kubernetes-Single-Cluster-Benutzern ein und bietet Unterstützung für native Kubernetes-APIs. Nachdem Benutzer native Ressourcen erstellt haben (z. B. Bereitstellung), konvertiert der Federate Controller diese automatisch in föderierte interne Objekte zur Verwendung durch andere Controller. Benutzer können schnell von einem einzelnen Cluster zu einer Multi-Cluster-Architektur migrieren und den Komfort mehrerer Cluster mit einem genießen niedrige Schwelle.
KubeAdmiral hört hier nicht auf. In einem einzelnen Cluster aktualisiert der native Controller von Kubernetes den Status einiger Ressourcen, um ihren aktuellen Status widerzuspiegeln. Benutzer oder Systeme der oberen Ebene verlassen sich häufig auf den Status, um Informationen wie den Bereitstellungsstatus und den Gesundheitsstatus anzuzeigen. In mehreren Clustern ist der Status der Ressourcen auf mehrere Cluster verteilt. Um den globalen Status anzuzeigen, müssen Benutzer den Status der Ressourcen in jedem Cluster einzeln anzeigen, was zu Problemen wie fragmentierten Ansichten und geringer Betriebs- und Wartungseffizienz führt. Um dieses Problem zu lösen und native Ressourcen nahtlos zu unterstützen, bietet KubeAdmiral Statusaggregationsfunktionen, die den Status von Ressourcen in mehreren Mitgliedsclustern zusammenführen und integrieren und sie in native Ressourcen zurückschreiben, sodass Benutzer nicht auf Multi achten müssen -Cluster-Topologie Der Status der Ressourcen im gesamten Verbund kann auf einen Blick beobachtet werden.
Gegenwart und Zukunft
KubeAdmiral ist seit vielen Jahren bei Byte aktiv und unterstützt die TCE-Plattform der Byte Group. Es verwaltet mehr als 210.000 Maschinen und mehr als 10 Millionen Pods und hat viele wertvolle Ressourcen gesammelt praktische Erfahrung. . Um der Community etwas zurückzugeben, wurde KubeAdmiral offiziell als Open Source auf GitHub bereitgestellt. Gleichzeitig entwickelt Volcano Engine ein neues Multi-Cloud- und Multi-Cluster-Verwaltungsmodell auf Unternehmensebene basierend auf KubeAdmiral – der Distributed Cloud Native Platform (DCP). Bleiben Sie also auf dem Laufenden.
Mit Blick auf die Zukunft planen wir, uns in folgenden Aspekten weiterzuentwickeln:
- Verbessern Sie weiterhin die Orchestrierungs- und Planungsfunktionen von zustandsbehafteten, auftragsbezogenen und anderen Ressourcen und entwickeln Sie erweiterte Funktionen wie automatische Migration und Preisvergleichsplanung, um dem Aufkommen der Multi-Cloud- und Multi-Cluster-Ära des Batch-Computing gerecht zu werden.
- Verbessern Sie das Benutzererlebnis und stellen Sie sofort einsatzbereite Lösungen bereit, um die kognitive Belastung der Benutzer weiter zu reduzieren.
- Verbessern Sie die Beobachtbarkeit, optimieren Sie Protokoll- und Überwachungsindikatoren und verbessern Sie die Interpretierbarkeit des Planers.
- Entdecken Sie Funktionen wie Ein-Klick-Föderation und Multi-Cluster-Migration, um das Potenzial der Multi-Cluster-Architektur voll auszuschöpfen.
Multi-Cluster-Orchestrierung und -Planung sind nicht einfach. Ein universelles und vollständiges Multi-Cluster-Verbundsystem muss in verschiedenen Szenarien verbessert werden. Wir freuen uns darauf, dass weitere Freunde der KubeAdmiral-Community beitreten und geben Sie uns verschiedene Anregungen!
GitHub: https://github.com/kubewharf/kubeadmiral
Fellow Chicken „Open-Source“ -Deepin-IDE und endlich Bootstrapping erreicht! Guter Kerl, Tencent hat Switch wirklich in eine „denkende Lernmaschine“ verwandelt. Tencent Clouds Fehlerüberprüfung und Situationserklärung vom 8. April RustDesk-Remote-Desktop-Startup-Rekonstruktion Web-Client WeChats Open-Source-Terminaldatenbank basierend auf SQLite WCDB leitete ein großes Upgrade ein TIOBE April-Liste: PHP fiel auf ein Allzeittief, Fabrice Bellard, der Vater von FFmpeg, veröffentlichte das Audiokomprimierungstool TSAC , Google veröffentlichte ein großes Codemodell, CodeGemma , wird es dich umbringen? Es ist so gut, dass es Open Source ist – ein Open-Source-Bild- und Poster-Editor-Tool