DE102021109511A1 - Container-as-a- service (caas)-controller für die überwachung von clustern und die implementierung von autoscaling-richtlinien - Google Patents

Container-as-a- service (caas)-controller für die überwachung von clustern und die implementierung von autoscaling-richtlinien Download PDF

Info

Publication number
DE102021109511A1
DE102021109511A1 DE102021109511.5A DE102021109511A DE102021109511A1 DE 102021109511 A1 DE102021109511 A1 DE 102021109511A1 DE 102021109511 A DE102021109511 A DE 102021109511A DE 102021109511 A1 DE102021109511 A1 DE 102021109511A1
Authority
DE
Germany
Prior art keywords
cluster
machine
bare metal
policy
customer
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102021109511.5A
Other languages
English (en)
Inventor
Peter Erik MELLQUIST
Bret Alan McKee
Frederick Miles Roeling
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hewlett Packard Enterprise Development LP
Original Assignee
Hewlett Packard Enterprise Development LP
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hewlett Packard Enterprise Development LP filed Critical Hewlett Packard Enterprise Development LP
Publication of DE102021109511A1 publication Critical patent/DE102021109511A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5083—Techniques for rebalancing the load in a distributed system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45541—Bare-metal, i.e. hypervisor runs directly on hardware
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5072—Grid computing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mathematical Physics (AREA)
  • Stored Programmes (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Die hier beschriebenen Ausführungsformen beziehen sich im Allgemeinen auf einen Controller eines verwalteten Containerdienstes, der eine automatische Skalierung auf der Grundlage von Bare-Metal-Maschinen ermöglicht, die innerhalb einer privaten Cloud verfügbar sind. Gemäß einem Beispiel überwacht ein CaaS-Controller eines verwalteten Containerdienstes eine Metrik eines Clusters, der im Auftrag eines Kunden innerhalb eines Container-Orchestrierungssystems bereitgestellt wird. Als Reaktion auf ein Skalierungsereignis, das für den Cluster auf der Grundlage der Überwachung und einer mit dem Cluster verbundenen Autoskalierungsrichtlinie identifiziert wird, kann ein mit der privaten Cloud verbundener BMaaS-Anbieter veranlasst werden, ein Inventar der in der privaten Cloud verfügbaren Bare-Metal-Maschinen zu erstellen. Schließlich wird ein Bare-Metal-Rechner identifiziert, der dem Cluster hinzugefügt werden soll, indem unter den Bare-Metal-Rechnern eine Auswahl getroffen wird, die auf der Autoskalierungsrichtlinie, dem Inventar und einem Best-Fit-Algorithmus basiert, der in Übereinstimmung mit einer Richtlinie konfiguriert ist, die vom oder im Namen des Kunden festgelegt wurde.

Description

  • HINTERGRUND
  • Cloud-Anbieter stellen Unternehmen und/oder Einzelpersonen Cloud-Computingbasierte Dienste und Lösungen zur Verfügung. Virtuelle Hardware, Software und Infrastruktur können gemietet und vom Anbieter verwaltet werden, um Dienste in Übereinstimmung mit einer Vielzahl von Cloud-Service-Modellen bereitzustellen, einschließlich Container as a Service (CaaS), Virtual Machine as a Service (VMaaS), Storage as a Service (STaaS) und Bare Metal as a Service (BMaaS).
  • Figurenliste
  • Die hier beschriebenen Ausführungsformen sind beispielhaft und nicht einschränkend in den Figuren der beiliegenden Zeichnungen dargestellt, in denen sich gleiche Bezugsziffern auf ähnliche Elemente beziehen.
    • 1 ist ein High-Level-Blockdiagramm, das konzeptionell eine Verteilung von Komponenten einer Systemarchitektur eines verwalteten Containerdienstes gemäß einer beispielhaften Ausführungsform darstellt.
    • 2 ist ein Blockdiagramm, das konzeptionell verschiedene Funktionseinheiten eines Container-SaaS-Portals gemäß einer beispielhaften Ausführungsform darstellt.
    • 3 ist ein Blockdiagramm, das konzeptionell verschiedene Funktionseinheiten eines CaaS-Controllers gemäß einer beispielhaften Ausführungsform darstellt.
    • 4 zeigt Daten, die mit einem Clusterelement einer Blaupausen-Metasprache oder eines Schemas gemäß einer beispielhaften Ausführungsform verbunden sind.
    • 5 zeigt Daten, die mit einem Blaupauselement einer Blaupause-Metasprache oder eines Schemas gemäß einer beispielhaften Ausführungsform verbunden sind.
    • 6 zeigt einen Cluster-Blaupause gemäß einer beispielhaften Ausführungsform.
    • 7 ist ein Flussdiagramm, das die Verarbeitung des CaaS-Controllers gemäß einer beispielhaften Ausführungsform zeigt.
    • 8 ist ein Flussdiagramm, das die Best-Fit-Verarbeitung gemäß einer beispielhaften Ausführungsform zeigt.
    • 9 ist ein Flussdiagramm, das die Best-Fit-Verarbeitung gemäß einem anderen Ausführungsbeispiel zeigt.
    • 10 ist ein High-Level-Flussdiagramm, das die automatische Skalierungsverarbeitung gemäß einer beispielhaften Ausführungsform zeigt.
    • 11 ist ein Flussdiagramm, das die Autoskalierungsverarbeitung veranschaulicht, bei der ein Bare-Metal-Rechner identifiziert wird, der zu einem Cluster hinzugefügt werden soll, in Übereinstimmung mit einer Beispielsausführungsform.
    • 12 ist ein Blockdiagramm eines Computersystems gemäß einer Ausführungsform.
  • DETAILLIERTE BESCHREIBUNG
  • Die hier beschriebenen Ausführungsformen beziehen sich im Allgemeinen auf einen Controller eines verwalteten Containerdienstes, der die automatische Skalierung auf der Grundlage von Bare-Metal-Maschinen ermöglicht, die in einer privaten Cloud verfügbar sind. In der folgenden Beschreibung werden zahlreiche spezifische Details dargelegt, um ein umfassendes Verständnis von Beispielausführungen zu ermöglichen. Einem Fachmann wird jedoch klar sein, dass die hier beschriebenen Ausführungsformen auch ohne einige dieser spezifischen Details ausgeführt werden können.
  • Praktischerweise verfügen Public Cloud-Anbieter in der Regel über praktisch unendliche Pools von Cloud-Maschinen. Daher müssen sich Public Cloud-Anbieter nicht mit einer Reihe von Problemen auseinandersetzen, die im Zusammenhang mit privaten Clouds auftreten. Beispielsweise erfordert CaaS auf Bare-Metal-Infrastruktur innerhalb einer Umgebung (z. B. in den Räumlichkeiten oder in der Colocation-Einrichtung einer Organisation, eines Unternehmens oder einer Einzelperson, die einen Kunden des Cloud-Anbieters und/oder des CaaS darstellt), die einen begrenzten Maschinenbestand in Bezug auf die Anzahl und/oder Vielfalt der Servertypen hat, etwas mehr Finesse als die einfache Erstellung einer virtuellen Maschine auf der Grundlage eines im Wesentlichen unbegrenzten Hardware-Pools. Daher sollte die automatische Skalierung der Verarbeitung in Bezug auf einen Cluster (z. B. Kubernetes oder Docker) in einer Umgebung mit begrenztem Maschineninventar eine Reihe von Kompromissen in Betracht ziehen. Wenn beispielsweise mehrere Bare-Metal-Maschinen im Inventar verfügbar sind, die über Ressourcen (z. B. in Bezug auf Prozessor, Arbeitsspeicher, Netzwerkkapazität und/oder Speicherleistung) verfügen, die über eine Maschinenspezifikation hinausgehen, die von der mit dem Cluster verbundenen Autoskalierungsrichtlinie identifiziert wurde, sollten eine oder mehrere richtlinienbasierte Einschränkungen (z. B., Eine oder mehrere richtlinienbasierte Einschränkungen (z. B. Maschinenkosten, Betriebskosten (Strom, Kühlung usw.), Leistung, Zuverlässigkeit (Verfügbarkeit), Sicherheit usw.), die vom Cloud-Anbieter und/oder einem CaaS-Benutzer oder -Administrator definiert wurden, können verwendet werden, um die beste Eignung für eine neue Maschine zu ermitteln, die dem Cluster als Ergebnis einer Scale-out- oder Scale-up-Aktion hinzugefügt werden soll. Ein ähnlicher Ansatz kann auch verwendet werden, wenn eine Maschine aus einem Cluster entfernt wird, z. B. als Reaktion auf eine Scale-in- oder Scale-down-Aktion.
  • Der Kürze halber konzentrieren sich die hier beschriebenen Ausführungsformen in erster Linie auf die Auswahl von Bare-Metal-Maschinen in einer Umgebung mit begrenztem Maschinenbestand. Die Methoden sind jedoch gleichermaßen auf die Erstellung und Verwaltung von hybriden Clustern anwendbar, die sowohl physische als auch virtuelle Infrastruktur und/oder Cluster umfassen, die öffentliche und private Clouds umfassen.
  • Terminologie
  • Die Begriffe „verbunden“ oder „gekoppelt“ und verwandte Begriffe werden in einem betrieblichen Sinn verwendet und sind nicht unbedingt auf eine direkte Verbindung oder Kopplung beschränkt. So können z. B. zwei Geräte direkt oder über ein oder mehrere zwischengeschaltete Medien oder Geräte gekoppelt sein. Ein weiteres Beispiel ist, dass Geräte so gekoppelt sein können, dass Informationen zwischen ihnen ausgetauscht werden können, ohne dass sie eine physische Verbindung miteinander haben. Auf der Grundlage der hier gegebenen Offenlegung wird ein Fachmann eine Vielzahl von Möglichkeiten erkennen, wie eine Verbindung oder Kopplung im Sinne der oben genannten Definition besteht.
  • Wenn in der Spezifikation angegeben wird, dass eine Komponente oder ein Merkmal „enthalten sein kann“, „kann“, „könnte“ oder „könnte“, ist es nicht erforderlich, dass diese bestimmte Komponente oder dieses bestimmte Merkmal enthalten ist oder das Merkmal aufweist.
  • Wie in der vorliegenden Beschreibung und in den folgenden Ansprüchen verwendet, schließt die Bedeutung von „a“, „an“ und „die“ die Pluralform ein, sofern der Kontext nicht eindeutig etwas anderes vorschreibt. Wie in der vorliegenden Beschreibung verwendet, schließt die Bedeutung von „in“ auch „in“ und „auf‟ ein, sofern der Kontext nicht eindeutig etwas anderes vorschreibt.
  • Die Bezugnahme in der Beschreibung auf „eine Ausführungsform“ oder „eine Ausführungsform“ bedeutet, dass ein bestimmtes Merkmal, eine bestimmte Struktur oder eine bestimmte Eigenschaft, die im Zusammenhang mit der Ausführungsform beschrieben wird, in mindestens einer Ausführungsform der Erfindung enthalten ist. Das Auftreten der Formulierung „in einer Ausführungsform“ an verschiedenen Stellen der Spezifikation bezieht sich nicht notwendigerweise alle auf die gleiche Ausführungsform.
  • Wie hierin verwendet, bezieht sich „Cluster-Informationen“ im Allgemeinen auf Informationen, die die für einen Cluster gewünschten Ressourcen angeben. In einigen Ausführungsformen können Cluster-Informationen eine Spezifikation von Bare-Metal-Aspekten bis hin zu Container-Anwendungsaspekten enthalten. Beispielsweise können Aspekte, die durch Cluster-Informationen spezifiziert werden, allgemeine Cluster-Parameter, Maschinentyp, Netzwerkfunktionen, Speicherspezifikationen und Dienstdefinitionen umfassen. In verschiedenen hierin beschriebenen Ausführungsformen können die Cluster-Informationen in Form eines Cluster-Blauplans dargestellt werden, der verwendet werden kann, um die Cluster-Spezifika einschließlich Rechen-, Speicher- und Netzwerkfunktionen zu definieren und wie diese zusammengesetzt werden sollen, um einen vollständigen funktionalen Cluster (z. B. Kubernetes oder Docker) zu erstellen.
  • Wie hierin verwendet, bezieht sich eine „Überschussressourcen-Metrik“ im Allgemeinen auf eine Metrik, die auf das Vorhandensein von Ressourcen hinweist, die über die für die Erfüllung der Anforderungen eines Clusters erforderlichen hinausgehen. Angenommen, ein Maschinenkandidat in einem Maschineninventar hat 10 Prozessorkerne und 1 Terabyte (TB) Speicher, dann hätte ein solcher Maschinenkandidat sowohl einen Überschuss an Verarbeitungskapazität als auch an Speicherkapazität im Vergleich zu einer neuen Cluster-Anforderung, die einen Bedarf an einer Maschine mit 2 Prozessorkernen und 128 Gigabyte (GB) Speicher anzeigt. Metriken für überschüssige Ressourcen können verwendet werden, um diese überschüssigen Ressourcen in roher Form zu quantifizieren (z. B. 8 überschüssige Prozessorkerne und 872 GB überschüssiger Speicher), oder sie können normalisiert werden (z. B..8 überschüssige Verarbeitungskapazität und .872 überschüssige Speicherkapazität).
  • 1 ist ein Blockdiagramm auf hoher Ebene, das konzeptionell eine Verteilung von Komponenten einer Systemarchitektur 100 eines verwalteten Containerdienstes gemäß einer Beispielausführungsform veranschaulicht. In verschiedenen hierin beschriebenen Ausführungsformen bietet der verwaltete Containerdienst eine Betriebssystemvirtualisierung unter Verwendung von Containern (z. B. stellt er Docker-Container und Kubernetes-Orchestrierung als Dienst bereit) unter Verwendung der Infrastruktur einer privaten Cloud eines Kunden (z. B. eines Rechenzentrums vor Ort oder einer Colocation-Einrichtung). Der verwaltete Containerdienst kann die Bereitstellung und den Betrieb von Cloud-nativen Anwendungen für eine Vielzahl von Anwendungsfällen erleichtern, einschließlich, aber nicht beschränkt auf Edge, künstliche Intelligenz/Maschinenlemen (AI/ML), High Performance Compute (HPC). Der Managed-Container-Service kann eine vollständig verwaltete Lösung bieten, bei der ein Managed-Service-Provider (MSP) CaaS-Instanzen betreibt und bei der Bereitstellung und dem Betrieb von containerbasierten Workloads der Kunden unterstützt. Gemäß einer Ausführungsform können einem SaaS-basierten Dienst (z. B. dem Container-SaaS-Portal 130) Cluster-Informationen zugeführt werden, um Cluster-Spezifika zu definieren, einschließlich Rechen-, Speicher- und Netzwerkfunktionen, und um festzulegen, wie diese zusammengesetzt werden sollen, um einen vollständigen funktionalen Cluster zu bilden, und eine Reihe von Controllern (z. B. BMaaS-Controller 166, STaaS-Controller 156, VMaaS-Controller 146 und CaaS-Controller 160) führen die Instanziierung des Clusters in Übereinstimmung mit den Cluster-Informationen durch. Der resultierende Cluster kann dann von einem Benutzer (z. B. einem der CaaS-Benutzer 102) konsumiert und von einem Clustermanager (z. B. dem Container-Cluster-Manager 170) verwaltet werden.
  • Im Kontext des vorliegenden Beispiels sind Komponenten, die sich in einer Private Cloud (z. B. in einem lokalen Rechenzentrum oder einer Colocation-Einrichtung) befinden, auf der linken Seite und Komponenten, die sich in einer Public Cloud befinden, auf der rechten Seite dargestellt. In einer Ausführungsform umfassen die Komponenten der privaten Cloud die Infrastruktur 110, den BMaaS-Controller 166, den STaaS-Controller 156, den VMaaS-Controller 146, einen Virtual Machine Manager (VMM) 147, den CaaS-Controller 160 und den Container-Cluster-Manager 170; und die Komponenten der öffentlichen Cloud umfassen ein Bare-Metal-SaaS-Portal 165, ein Storage-SaaS-Portal 155 und das Container-SaaS-Portal 130.
  • Gemäß einer Ausführungsform stellt das Container-SaaS-Portal 130 ein webbasiertes Portal in Form eines in der Cloud gehosteten mandantenfähigen Dienstes dar, der die Erstellung eines physischen Clusters, eines virtuellen Clusters oder eines hybriden Clusters auf der Grundlage von Cluster-Informationen, z. B. in Form von Cluster-Blueprints 105, ermöglicht, die vordefiniert oder von einem CaaS-Administrator 101 und/oder CaaS-Benutzern 102 erstellt werden können. In einer Ausführungsform erleichtert die Verwendung von Cluster-Blueprints 105 die Erstellung eines kompletten funktionalen Clusters durch einen Benutzer, einschließlich Rechen-, Netzwerk- und Speicherressourcen sowie einer Reihe von Anwendungen, die durch einfaches Referenzieren eines vorhandenen Blueprints bereitgestellt werden. Ein Katalog von Blueprints kann zur Verfügung gestellt werden, damit ein Benutzer einen Blueprint aus dem Katalog auswählen kann, der seinen Anforderungen entspricht. So kann es beispielsweise vordefinierte Blueprints geben, die die Erstellung von Clustern für künstliche Intelligenz/Maschinenlemen (AI/ML) ermöglichen, sowie andere vordefinierte Blueprints für allgemeine Compute-Cluster. Ein nicht einschränkendes Beispiel für einen Cluster-Blaupause wird im Folgenden unter Bezugnahme auf 6 beschrieben.
  • Im weiteren Verlauf des vorliegenden Beispiels können der CaaS-Administrator 101 und die CaaS-Benutzer 102 das Container-SaaS-Portal 130 nutzen, um verschiedene Life-Cycle-Management-(LCM)-Operationen in Bezug auf Cluster (z. B. Kubernetes oder Docker) durchzuführen, die auf der Infrastruktur 110 basieren, die physische und/oder virtuelle Infrastruktur umfassen kann, einschließlich Netzwerkinfrastruktur 111, Speicherinfrastruktur 112 und Recheninfrastruktur 113. Die LCM-Vorgänge können die anfängliche Erstellung von Rechenclustem, die Änderung von Clustern, bei der Infrastruktur zu einem Cluster hinzugefügt oder aus ihm entfernt wird, Cluster-Updates, bei denen bestehende Infrastruktur geändert werden kann, und die Zerstörung eines Clusters umfassen. In einer Ausführungsform unterstützen die vom Container-SaaS-Portal 130 bereitgestellten Anwendungsprogrammierschnittstellen (z. B. Representational State Transfer (REST)-APIs) vollständige LCM-Operationen auf Clustern und basieren auf der OpenAPI (Swagger)-Definition. Der Status von Cluster-LCM-Operationen kann z. B. über das Container-SaaS-Portal 130 oder über die Kubernetes-Kommandozeile nachverfolgt werden. Das Container-SaaS-Portal 130 kann auch REST verwenden, um mit anderen Diensten (z. B. dem Bare-Metal-SaaS-Portal 165, dem Storage-SaaS-Portal 155 und dem VM-SaaS-Portal 145) zu kommunizieren, von denen es abhängt, um Informationen über die Infrastruktur 110 zu erhalten und/oder um verschiedene Aufgaben im Zusammenhang mit den LCM-Operationen zu implementieren. Weitere Einzelheiten zu einem nicht einschränkenden Beispiel des Container-SaaS-Portals 130 werden im Folgenden unter Bezugnahme auf 2 beschrieben.
  • Das Bare-Metal-SaaS-Portal 165 kann ein webbasiertes Portal in Form eines in der Cloud gehosteten Dienstes eines bestimmten BMaaS-Anbieters (der derselbe oder ein anderer Anbieter als der Cloud-Anbieter sein kann) darstellen, das mit dem BMaaS-Controller 166 interagiert, um verschiedene Aspekte der Instanziierung des Clusters auszuführen. Beispielsweise kann der BMaaS-Controller 166 verwendet werden, um die entsprechende Firmware und Software auf einer Bare-Metal-Maschine zu installieren, die vom CaaS-Controller 160 zur Aufnahme in einen Cluster ausgewählt wurde.
  • In ähnlicher Weise können das Storage-SaaS-Portal 155 und das VM-SaaS-Portal 145 webbasierte Portale der jeweiligen STaaS- und VMaaS-Anbieter darstellen, die vom Kunden genutzt werden und die zur Verbindung mit der Infrastruktur 110 über den STaaS-Controller 156 bzw. den VMaaS-Controller 146 verwendet werden. In einer Ausführungsform kann der VMaaS-Controller 146 den VMM 147 nutzen, um Control-Plane-Knoten geeigneter Größe zu erstellen, um eine Container-Control-Plane für den angeforderten Cluster auszuführen. Zu den Vorteilen des von der Systemarchitektur 100 implementierten mehrschichtigen Ansatzes gehört, dass das Container-SaaS-Portal 130 auf anderen „as a Service“-Angeboten (z. B. BMaaS, STaaS und VMaaS) des Cloud-Anbieters oder eines Drittanbieters aufgebaut werden kann, was die Erweiterbarkeit um andere Angebote (z. B. Netzwerk und Rechenleistung) erleichtert und die Erstellung von Mehrwertdiensten auf CaaS oder Kubernetes as a Service (KaaS) ermöglicht. Je nach Bedarf der jeweiligen Implementierung können mehr oder weniger Arten von Infrastrukturen oder Anbietern unterstützt werden, zum Beispiel durch Hinzufügen oder Entfernen von entsprechenden SaaS-Portalen und zugehörigen Controllern.
  • Im Kontext des vorliegenden Beispiels läuft der CaaS-Controller 160 vor Ort und wird durch das Container-SaaS-Portal 130 gesteuert. In einer Ausführungsform kann der CaaS-Controller 160 ein Kubernetes-Cluster sein und kann über kubectl-API-Aufrufe gesteuert werden, die vom Container-SaaS-Portal 130 aufgerufen werden. In einem solchen Szenario ist der CaaS-Controller 160 effektiv ein Bootstrap-Cluster, mit dem Zielcluster (z. B. Cluster 120) erstellt und verwaltet werden können. In einigen Ausführungsformen können einer oder mehrere der BMaaS-Controller 166, der STaaS-Controller 156 und der VMaaS-Controller 146 ebenfalls in den Bootstrap-Cluster integriert werden, z. B. unter Verwendung „kube-nativer“ Methoden. Weitere Einzelheiten zu einem nicht einschränkenden Beispiel des CaaS-Controllers 160 werden im Folgenden unter Bezugnahme auf 3 beschrieben.
  • Der Container-Cluster-Manager 170 kann für die Installation eines Container-Orchestrierungssystems auf neu bereitgestellten Knoten verantwortlich sein. In einer Ausführungsform umfasst der Container-Cluster-Manager 170 eine „Kubernetes Engine“ (z. B. Hewlett Packard Enterprise (HPE) Container Platform, Rancher Kubernetes Engine (RKE), Loodse Kubermatic Container Engine, Google Kubernetes Engine (GKE), Kubernetes + Cluster API oder andere), um Kubernetes zu installieren und einen Cluster zu erstellen. Nachdem der Cluster erstellt wurde, kann der CaaS-Controller 160 den Zustand des Clusters überwachen und bei Bedarf korrigierend eingreifen. Wenn beispielsweise eine Maschine auf eine Weise ausfällt, die nicht repariert werden kann, kann eine andere Maschine zugewiesen, bereitgestellt und dem Cluster hinzugefügt werden, um die ausgefallene Maschine zu ersetzen.
  • Die verschiedenen Portale (z. B. Bare-Metal-SaaS-Portal 165, Storage-SaaS-Portal 155, VM-SaaS-Portal und Container-SaaS-Portal 130) und Controller (z. B. BMaaS-Controller 166, STaaS-Controller 156, VMaaS-Controller 146 und CaaS-Controller 160) und die von ihnen ausgeführte Funktionalität können durch Hardware, Software, Firmware und/oder eine Kombination davon implementiert werden. Beispielsweise können die Portale und Controller in Form von ausführbaren Anweisungen implementiert sein, die auf einem maschinenlesbaren Medium gespeichert sind und von einer Verarbeitungsressource (z. B. einem Mikrocontroller, einem Mikroprozessor, Zentraleinheitskern(en), einer anwendungsspezifischen integrierten Schaltung (ASIC), einem Field Programmable Gate Array (FPGA) und dergleichen) und/oder in Form anderer Arten von elektronischen Schaltungen ausgeführt werden.
  • Während der Einfachheit halber verschiedene Beispiele mit Bezug auf einen einzelnen Kunden oder einen einzelnen Kundenstandort (z. B. ein lokales Rechenzentrum oder eine Colocation-Einrichtung) beschrieben werden, ist es zu verstehen, dass die verschiedenen hier beschriebenen Portale mit Controllern interagieren können, die mit mehreren Kunden verbunden und/oder über mehrere Standorte verteilt sind. Obwohl im vorliegenden Beispiel die Controller und SaaS-Portale auf eine bestimmte Art und Weise zwischen der Private Cloud und der Public Cloud verteilt sind, können diese Komponenten je nach der jeweiligen Implementierung auch anders verteilt sein. Zum Beispiel können einer oder mehrere der Controller (z. B. der CaaS-Controller 160) innerhalb einer Public Cloud bereitgestellt werden. Auch können die gleichen oder unterschiedliche Systemarchitekturen (z. B. die Systemarchitektur 100) für einen oder mehrere Kunden des Cloud-Anbieters implementiert sein. Es wird weiterhin in Betracht gezogen, dass verschiedene Komponenten der Systemarchitektur von denselben oder verschiedenen Anbietern oder Dienstanbietern implementiert werden können. Beispielsweise kann ein Cloud-Anbieter, der über ein oder mehrere bestehende „as a Service“-Angebote verfügt, solche bestehenden Angebote nutzen und/oder auf Dienste von Drittanbietern zurückgreifen.
  • 2 ist ein Blockdiagramm, das konzeptionell verschiedene Funktionseinheiten eines Container-SaaS-Portals 230 gemäß einem Ausführungsbeispiel illustriert. Im Kontext des vorliegenden Beispiels umfasst das Container-SaaS-Portal 230 eine Benutzeroberfläche 232, einen CaaS-REST-API-Server 235, einen CaaS-Worker 236 und eine CaaS-Ressourcen-Datenbank 234. In einer Ausführungsform stellen die Benutzerschnittstelle 232 und der CaaS-REST-API-Server 235 eine Northbound-Schnittstelle (oder ein Frontend) für die Annahme von REST-Anfragen dar, um Create-, Read-, Update- und Delete-Operationen (CRUD) auf Clustern in Übereinstimmung mit Cluster-Blaupausen 205 durchzuführen und sie in der CaaS-Ressourcen-Datenbank 234 zu persistieren. Beispielsweise kann der CaaS-REST-API-Server 235 Self-Service-APIs für Benutzer (z. B. CaaS-Benutzer 102) bereitstellen, um ihre eigenen Cluster (z. B. Kubernetes-Cluster) zu erstellen, und Administrator-APIs für CaaS-Administratoren (z. B. CaaS-Administrator 101), um Cluster zu erstellen und Benutzergruppen zuzuweisen.
  • Gemäß einer Ausführungsform kann die Trennung von Belangen und die Skalierung durch die Implementierung eines Backends in Form von einem oder mehreren Workern (z. B. dem CaaS-Worker 236) des Container-SaaS-Portals 230 adressiert werden, die dafür verantwortlich sind, dass über die REST-Schnittstelle des Container-SaaS-Portals 230 angeforderte Operationen realisiert werden. Im Kontext des vorliegenden Beispiels wird ein interner Interprozessorkommunikations-(IPC)-Mechanismus (z. B. gRPC Remote Procedure Call (gRPC)) verwendet, um zwischen dem Frontend und dem Backend zu kommunizieren, und der CaaS-Worker 236 kann Informationen zu Cluster-Anfragen an den CaaS-Controller (z. B. CaaS-Controller 160) über kubectl over Remote Data Access (RDA) kommunizieren.
  • In einer Ausführungsform kann die rollenbasierte Zugriffskontrolle (RBAC), die z. B. vom Identitätsanbieter 210 unterstützt wird, verwendet werden, um die Bedürfnisse verschiedener Benutzer-Personas sicher zu berücksichtigen. Auf diese Weise kann beispielsweise eine Trennung erreicht werden zwischen (i) Cloud-Provider-Betriebs- oder Verwaltungspersonal (z. B. CaaS-Administrator 101), das das Container-SaaS-Portal 230 für den Betrieb und die Verwaltung der verwalteten Container-Umgebungen der Kunden nutzt, und (ii) Selbstbedienungs-Benutzern (z. B. CaaS-Benutzer 102) der Kunden (Mieter) des Container-SaaS-Portals 230 für CaaS und/oder KaaS.
  • 3 ist ein Blockdiagramm, das konzeptionell verschiedene Funktionseinheiten eines CaaS-Controllers 360 gemäß einem Ausführungsbeispiel darstellt. Im Kontext des vorliegenden Beispiels umfasst der CaaS-Controller 360 einen API-Server 360, einen Cluster-Controller 362, Container-Cluster-Manager-Schnittstellen 363a-n, einen Maschinen-Controller 364 und verschiedene Provider-Schnittstellen 365a-n. Der CaaS-Controller 360 und die vom CaaS-Controller 360 ausgeführten Funktionen können durch Hardware, Software, Firmware und/oder eine Kombination davon implementiert werden. Beispielsweise kann der CaaS-Controller 360 in Form von ausführbaren Anweisungen implementiert sein, die auf einem maschinenlesbaren Medium gespeichert sind und von einer Verarbeitungsressource (z. B. einem Mikrocontroller, einem Mikroprozessor, Zentraleinheitskern(en), einer anwendungsspezifischen integrierten Schaltung (ASIC), einem Field Programmable Gate Array (FPGA) und dergleichen) und/oder in Form anderer Arten von elektronischen Schaltungen ausgeführt werden.
  • Gemäß einer Ausführungsform beinhaltet die Erstellung eines Clusters die Auswahl oder Eingabe von Cluster-Informationen 305 (z. B. in Form eines Cluster-Blauplans (z. B. Cluster-Blauplan 105)) über ein CaaS SaaS-Portal (z. B. Container SaaS-Portal 130). Das CaaS-SaaS-Portal kann den CaaS-Controller 360 über API-Aufrufe (z. B. kubectl API-Aufrufe) an den API-Server 370 steuern. Im vorliegenden Beispiel stellt der API-Server 370 benutzerdefinierte Ressourcendefinitionen (Custom Resource Definitions, CRDs) (z. B. Cluster-CRD(s) 372 und Maschinen-CRD(s)) für verschiedene Objekte bereit, die vom verwalteten Containerdienst unterstützt werden, darunter z. B. ein Cluster, eine Maschine, ein Maschinensatz und ein Maschineneinsatz. Abhängig von der jeweiligen Implementierung können die CRDs auf Kubernetes-Community-„Cluster API“-CRDs basieren.
  • Cluster-Objekte können eine High-Level-Beschreibung ihrer jeweiligen Cluster bereitstellen, einschließlich einer Internet Protocol (IP)-Adresse, Domain Name Service (DNS)-Informationen und dergleichen. In einer Ausführungsform sind Maschinenobjekte unabhängig von physischen oder virtuellen Maschinen und enthalten anbieterspezifische Details für die gewünschten Maschinen. Maschinensatzobjekte können unterstützt werden, um die Spezifikation eines Satzes von mehreren Maschinen zu ermöglichen. Maschinenbereitstellungsobjekte können verwendet werden, um Upgrades zu automatisieren.
  • Als Reaktion auf die Cluster-CRD(s) 372 kann der Cluster-Controller 362 Cluster-Operationen an eine geeignete Container-Cluster-Manager-Schnittstelle 363a-n leiten. Abhängig von einer Clusterspezifikation, die in den Cluster-Informationen 305 angegeben ist, kann der Cluster-Controller 362 beispielsweise die Container-Cluster-Manager-Schnittstelle 363a verwenden, um mit einer RKE-Kubernetes-Distribution zu interagieren, oder die Container-Cluster-Manager-Schnittstelle 363n, um mit einem anderen Typ von Kubernetes-Engine zu interagieren.
  • In ähnlicher Weise kann die Maschinensteuerung 364 für die Weiterleitung von Maschinenoperationen an eine geeignete Provider-Schnittstelle 365a-n verantwortlich sein. Abhängig von einer in den Clusterinformationen 305 angegebenen Maschinenspezifikation kann die Maschinensteuerung 364 die BM-Provider-Schnittstelle 365a verwenden, um mit einem BMaaS-Provider zu interagieren (z. B. über BMaaS-APIs, die mit einem Bare-Metal-SaaS-Portal (z. B. Bare-Metal-SaaS-Portal 165) verbunden sind), und die VM-Provider-Schnittstelle 365n, um mit einem VMaaS-Provider zu interagieren (z. B. über VMaaS-APIs, die mit einem VM-SaaS-Portal (z. B. VM-SaaS-Portal 145) verbunden sind). Beispielsweise kann der Maschinen-Controller 364 Terraform-Provider für die Infrastruktur (z. B. BMaaS, VMaaS oder beliebige IaaS) und Ansible-Playbooks zur Verwaltung der installierten Betriebssystemkomponenten (z. B. Docker, Agenten, Basiskonfigurationen und anfängliche Helm-Diagramme) verwenden.
  • 4 zeigt Daten, die mit einem Clusterelement 400 einer Blueprint-Metasprache oder eines Schemas gemäß einer beispielhaften Ausführungsform verbunden sind. In verschiedenen hier beschriebenen Ausführungsformen können deklarative Modelle für Cluster-LCM unter Verwendung von Cluster-Blueprints (z. B. Cluster-Blueprints 105 oder 205) verwendet werden. In einer Ausführungsform wird eine Blueprint-Metasprache (z. B., JavaScript Object Notation (JSON), YAML Ain't Markup Language (YAML) und/oder die Terraform-Sprache) oder ein Schema (i) den Cluster Blueprint, (ii) Maschinen Blueprints, die verschiedene Arten von Rechenressourcen definieren, die als Teil des Cluster Blueprints verwendet werden sollen; (iii) Netzwerk Blueprints, die Netzwerktopologien und -funktionen für den Cluster definieren; (iv) Speicher Blueprints, die Speicher definieren, der innerhalb des Clusters verwendet werden soll; und (v) Service Blueprints, die Dienste definieren, die auf einem neu erstellten Cluster vorinstalliert werden sollen.
  • Im Kontext des vorliegenden Beispiels umfasst das Clusterelement 400 eine ID, einen Namen, eine BlueprintID, ein createdDate, ein lastUpdateDate und einen Status. Die ID kann eine Zeichenfolge sein, die einen eindeutigen Bezeichner (z. B. einen Universally Unique Identifier (UUID)) für den Cluster darstellt. Der Name kann eine Zeichenkette sein, die einen vom Benutzer zugewiesenen Namen für den Cluster darstellt, der z. B. im Katalog angezeigt werden kann. Die blueprintID kann eine Zeichenkette sein, die einen eindeutigen Bezeichner (z. B. eine UUID) für ein mit dem Cluster verbundenes Blueprint-Element darstellt. Das createdDate kann das Datum und die Uhrzeit angeben, zu der der Cluster erstellt wurde, und kann in Form eines Strings dargestellt werden. Das lastUpdateDate kann das Datum und die Uhrzeit angeben, zu der der Cluster zuletzt aktualisiert wurde, und kann in Form einer Zeichenfolge dargestellt werden. Der Status, der z. B. von einem CaaS-Controller (z. B. CaaS-Controller 160) überwacht und aktualisiert wird, kann aus einer vordefinierten Menge von Aufzählungswerten ausgewählt werden (z. B. ausstehend, bereit, Fehler oder offline) und kann in Form eines Strings dargestellt werden.
  • 5 zeigt Daten, die mit einem Blueprint-Element 500 einer Blueprint-Metasprache oder eines Blueprint-Schemas gemäß einer beispielhaften Ausführungsform verbunden sind. Das Blueprint-Element 500 kann den gewünschten Cluster deklarativ beschreiben, z. B. einschließlich Master- und Worker-Knotengrößen, Mengen und Qualitätsattributen (z. B. Verfügbarkeit und Leistung). Cluster-Blaupausen können auch die erforderlichen Speicher- und Netzwerkmerkmale sowie andere kuratierte Dienste für die Bereitstellung definieren, z. B. Cluster- und Workload-Beobachtungsdienste. Abhängig von der jeweiligen Implementierung können Cluster-Blaupausen auch dienstspezifische Darstellungen des gewünschten Zustands sowie andere bekannte Darstellungen (z. B. Terraform-Infrastrukturpläne) enthalten.
  • Im Kontext des vorliegenden Beispiels umfasst das Blueprint-Element 500 eine ID, einen Namen, eine Version, eine k8sVersion, ein createdDate, ein lastUpdateDate, eine Maschinenspezifikation, eine Clusterspezifikation, eine Speicherspezifikation und Informationen zu den gewünschten Master- und Worker-Knoten. Wie oben unter Bezugnahme auf das ClusterElement beschrieben, kann die ID eine Zeichenkette sein, die einen eindeutigen Bezeichner (z. B. eine UUID) für den Blueprint darstellt. Der Name kann eine Zeichenkette sein, die einen vom Benutzer zugewiesenen Namen für den Blueprint darstellt, der z. B. im Katalog angezeigt werden kann. Das createdDate kann das Datum und die Uhrzeit angeben, zu der der Blueprint erstellt wurde und kann in Form eines Strings dargestellt werden. Das lastUpdateDate kann das Datum und die Uhrzeit angeben, zu der der Bauplan zuletzt aktualisiert wurde, und kann in Form einer Zeichenkette dargestellt werden. Die Maschinenspezifikation kann Informationen enthalten, die den Provider für die gewünschte Maschine angeben. Die Cluster-Spezifikation kann Informationen enthalten, die auf den gewünschten Container-Cluster-Manager (z. B. Container-Cluster-Manager 170) hinweisen, z. B. die gewünschte Kubernetes-Engine. Die Speicherspezifikation kann Informationen enthalten, die einen Typ der Speicherinfrastruktur (z. B. Speicherinfrastruktur 112) angeben, die im Cluster verwendet werden soll.
  • 6 zeigt einen Cluster-Blaupause 605 gemäß einer Beispielausführungsform. Im Kontext des vorliegenden Beispiels definiert die Cluster-Blaupause 605 einen über RKE zu erstellenden Kubernetes-Cluster mit einem kleinen Master-Knoten und einem mittleren Bare-Metal-basierten Worker-Knoten.
  • Die verschiedenen hierin beschriebenen Portale und Steuerungen und die unten unter Bezugnahme auf die Flussdiagramme der 7-9 können in Form von ausführbaren Anweisungen implementiert werden, die auf einem maschinenlesbaren Medium gespeichert sind und von einer Verarbeitungsressource (z. B. einem Mikrocontroller, einem Mikroprozessor, Kern(en) einer zentralen Verarbeitungseinheit, einer anwendungsspezifischen integrierten Schaltung (ASIC), einem feldprogrammierbaren Gate-Array (FPGA) und dergleichen) und/oder in Form anderer Arten von elektronischen Schaltungen ausgeführt werden. Beispielsweise kann die Verarbeitung durch ein oder mehrere virtuelle oder physische Computersysteme verschiedener Formen durchgeführt werden, wie z. B. das mit Bezug auf 10 unten beschriebene Computersystem.
  • 7 ist ein Flussdiagramm, das die CaaS-Controller-Verarbeitung gemäß einer beispielhaften Ausführungsform illustriert. Im Kontext des vorliegenden Beispiels kann ein Cloud-Anbieter von einem bestimmten Kunden oder von mehreren Kunden beauftragt worden sein, einen verwalteten Containerdienst bereitzustellen und zu unterstützen, der z. B. seine private Cloud-Infrastruktur einschließlich Bare-Metal-Servern nutzt.
  • In Block 710 werden Cluster-Informationen, die mit einer Anforderung zur Erstellung eines Container-Clusters im Namen eines Kunden verbunden sind, von einem CaaS-Controller empfangen. Gemäß einer Ausführungsform läuft der CaaS-Controller (z. B. CaaS-Controller 160) innerhalb der privaten Cloud eines Kunden, z. B. auf einer On-Premises-Infrastruktur oder einer Infrastruktur innerhalb einer vom Kunden genutzten Colocation-Einrichtung. Der CaaS-Controller kann die Cluster-Informationen in Form einer Cluster-Blaupause (z. B. Cluster-Blaupause 105) von einem Container-SaaS-Portal (z. B. Container-SaaS-Portal 130) erhalten, das in der gleichen oder einer anderen privaten oder öffentlichen Cloud wie der CaaS-Controller läuft. Abhängig von der jeweiligen Implementierung können die Cluster-Informationen den gewünschten Cluster deklarativ beschreiben. Beispielsweise kann ein Cluster-Blaupause von einem CaaS-Benutzer (z. B. CaaS-Benutzer 102) aus einem vordefinierten Satz von Cluster-Blaupausen ausgewählt werden, die über eine Benutzerschnittstelle (z. B. Benutzerschnittstelle 232) präsentiert werden, wobei die ausgewählte Cluster-Blaupause Master- und Worker-Knotengrößen, Mengen und Qualitätsattribute (z. B. Verfügbarkeit und/oder Leistung) enthält. Cluster-Blaupausen können auch die gewünschten Speicher- und Netzwerkmerkmale sowie andere kuratierte Dienste definieren, die bereitgestellt werden sollen, z. B. Cluster- und Workload-Beobachtungsdienste. Cluster-Blaupausen können auch systemspezifische Darstellungen des gewünschten Zustands sowie andere bekannte Darstellungen (z. B. Terraform-Infrastrukturpläne) enthalten.
  • In Block 720 wird ein Inventar von Bare-Metal-Maschinen, die in einer privaten Cloud des Kunden verfügbar sind, über einen BMaaS-Anbieter empfangen. Gemäß einer Ausführungsform enthält das Inventar Echtzeitinformationen, die auf entsprechende Ressourcen (z. B. eine Anzahl von Prozessorkernen, eine Menge an Speicher, Netzwerkkapazität und/oder Speicherleistung) für eine oder mehrere Arten von Infrastruktur (z. B. Infrastruktur 110), einschließlich eines Satzes von Bare-Metal-Maschinen, hinweisen, die derzeit verfügbar sind (z. B. derzeit nicht zur Verwendung durch einen anderen Cluster bereitgestellt werden), um in Verbindung mit der Unterstützung des verwalteten Containerdienstes verwendet zu werden. Abhängig von der jeweiligen Implementierung kann das Inventar vom BMaaS-Anbieter durch den CaaS-Controller direkt (z. B. über ein Bare-Metal-SaaS-Portal des BMaaS-Anbieters) oder indirekt (z. B. über das CaaS-Portal) angefordert werden.
  • In verschiedenen Ausführungsformen kann das Inventar Metadaten oder andere Informationen, die mit den verfügbaren Bare-Metal-Maschinen verbunden sind, enthalten oder anderweitig darauf abgebildet werden, um die Maschinenauswahl zu priorisieren, zu leiten, zu lenken oder anderweitig zu beeinflussen, z. B. durch Optimierung, Minimierung oder Maximierung verschiedener Faktoren oder Bedingungen, Kosten, Stromverbrauch, Wärme, Leistung, Sicherheit, Zuverlässigkeit usw.) in Form von relativen oder absoluten Metriken/Bewertungen oder rohen oder normalisierten Daten.
  • In Block 730 wird eine Bare-Metal-Maschine für den Cluster identifiziert, basierend auf dem in Block 720 empfangenen Inventar, den in Block 710 empfangenen Cluster-Informationen und einem Best-Fit-Algorithmus, der in Übereinstimmung mit einer vom Kunden oder im Namen des Kunden festgelegten Richtlinie konfiguriert ist. Obwohl der Kunde über eine Vielzahl von Bare-Metal-Maschinenkonfigurationen verfügt, ist es unwahrscheinlich, dass der Kunde über eine ausreichende Anzahl solcher Konfigurationen verfügt, um den Bereich aller potenziellen Cluster-Anforderungen genau abzudecken. Nehmen wir als Beispiel an, dass der verwaltete Containerdienst vier aufgezählte Größen (Small, Medium, Large, Extra Large) für vier Ressourcen verwendet: Prozessor, Arbeitsspeicher, Netzwerkkapazität und Speicherleistung. In diesem Beispiel gibt es 256 Kombinationen der Ressourcen, aber es ist unwahrscheinlich, dass der Kunde 256 verschiedene Maschinenkonfigurationen zur Auswahl hat, und die Anzahl der Möglichkeiten wächst sehr schnell, wenn die aufgezählten Kategorien zunehmen und/oder wenn Ressourcen hinzugefügt werden. Da es für einen Kunden unpraktisch ist, zu versuchen, Bare-Metal-Maschinenkonfigurationen zu haben, die jede mögliche Maschinenspezifikation erfüllen, die von einem CaaS-Benutzer gewünscht wird, ist es wünschenswert, einen Maschinenauswahlprozess zu haben, um die Auswahl einer geeigneten Maschine aus dem verfügbaren Bestand zu erleichtern, um die Anforderung des Benutzers zu erfüllen. Während zum Beispiel eine Anzahl der verfügbaren Maschinen über ausreichende Ressourcen verfügen kann, um die von der Benutzeranforderung angegebenen Bedürfnisse zu erfüllen, können einige der Maschinen eine oder mehrere Arten von Ressourcen haben, die über die vom gewünschten Cluster benötigten hinausgehen, oder wahrscheinlich benötigt werden, um andere Clusteranforderungen zu bedienen. Als solche bieten die hier beschriebenen Ausführungsformen einen richtlinienbasierten Ansatz, der es dem Cloud-Anbieter und/oder dem Kunden ermöglicht, eine oder mehrere Prioritäten für die Maschinenauswahl zu formulieren, die als Teil eines Best-Fit-Algorithmus angewendet werden. Nicht einschränkende Beispiele für die Best-Fit-Verarbeitung, die Teil des Best-Fit-Algorithmus sein kann, werden im Folgenden unter Bezugnahme auf die 8 und 9 beschrieben.
  • Im Zusammenhang mit verschiedenen hier beschriebenen Beispielen kann der CaaS-Benutzer den gewünschten Cluster in einer Form spezifizieren, in der die Ressourcen auf einem einigermaßen hohen Niveau beschrieben werden. Obwohl es möglich ist, dass der Benutzer eine Maschine mit Einzelheiten spezifiziert, z. B. ein bestimmtes Modell eines bestimmten Herstellers mit einem bestimmten Prozessortyp, einer bestimmten Menge an Speicher und einem bestimmten Typ von Grafikverarbeitungseinheit (GPU), ist es typischerweise effizienter für einen Benutzer, eine Maschine basierend auf etwas Abstrakterem zu spezifizieren. Abhängig von der Art und Weise, wie die Maschinen kategorisiert sind, kann eine interne Abbildung dieser Kategorien (z. B. Größen) auf die dem Benutzer präsentierte Realität als Teil des Maschinenauswahlprozesses verwendet werden.
  • 8 ist ein Flussdiagramm, das die Best-Fit-Verarbeitung in Übereinstimmung mit einem Ausführungsbeispiel zeigt. In Block 810 wird ein Satz von Kandidatenmaschinen auf der Grundlage des Inventars erstellt. Gemäß einer Ausführungsform ist der Satz von Kandidatenmaschinen eine Teilmenge der verfügbaren Bare-Metal-Maschinen im Inventar, die über ausreichende Ressourcen verfügen, um die Cluster-Anforderung zu erfüllen. Das heißt, dass jeder Kandidat im Kandidatensatz über Ressourcen verfügt, die gleich oder größer sind als die in der Anforderung angegebenen. Die Identifizierung des Kandidatensatzes kann die Verwendung einer internen Zuordnung von Maschinenkategorien zu entsprechenden Ressourcenbereichen beinhalten, um eine Cluster-Anforderung, die in Form einer Maschinenkategorie ausgedrückt wird, in explizite Ressourcenmengen zu transformieren. Dann kann für jede verfügbare Maschine im Inventar die Menge jedes Ressourcentyps, die zur Erfüllung der Anforderung benötigt wird, mit den entsprechenden Mengen jedes Ressourcentyps der Maschinenkonfiguration verglichen werden, um zu bestimmen, ob die verfügbare Maschine zum Kandidatensatz hinzugefügt werden soll.
  • In Block 820 wird eine Metrik für den Ressourcenüberschuss für jede Kandidatenmaschine in der Menge der Kandidatenmaschinen berechnet. Gemäß einer Ausführungsform kann die Überschuss-Ressourcen-Metrik gleichzeitig mit der Identifizierung des Kandidatensatzes berechnet werden. Alternativ kann die Überschuss-Ressourcen-Metrik durchgeführt werden, nachdem der Kandidatensatz vervollständigt wurde. Die Berechnung kann beinhalten, dass die Menge an Ressourcen, die benötigt wird, um die Anfrage zu erfüllen, von denjenigen subtrahiert wird, die als Teil einer bestimmten Maschinenkonfiguration verfügbar sind, und dass die Ergebnisse für jeden Ressourcentyp zu einer einzigen Metrik für den Ressourcenüberschuss aggregiert oder gemittelt werden. Alternativ kann die Metrik für den Ressourcenüberschuss aus mehreren Komponenten bestehen - eine für jeden Ressourcentyp.
  • In Block 830 wird eine Bare-Metal-Maschine in der Menge der Kandidatenmaschinen mit der Überschussressourcen-Metrik, die die geringste Menge an überschüssigen Ressourcen anzeigt, für den Cluster ausgewählt.
  • 9 ist ein Flussdiagramm, das die Best-Fit-Verarbeitung gemäß einer anderen Beispielsausführungsform veranschaulicht. Im Kontext des vorliegenden Beispiels wird davon ausgegangen, dass zusätzliche Informationen zur Unterstützung des Maschinenauswahlprozesses verfügbar sind. Beispielsweise können Informationen bezüglich einer Lebensdauer der Cluster-Anforderung als Teil der Cluster-Anforderung enthalten sein oder auf der Grundlage historischer Daten gelernt werden. Zusätzlich können Informationen, die eine Wahrscheinlichkeitsmetrik auf der Maschinenebene oder der Ressourcenebene quantifizieren, die eine Wahrscheinlichkeit angibt, dass eine Maschine oder Ressource benötigt wird, um eine nachfolgende Anforderung während der Lebensdauer zu erfüllen, in die Bestandsliste aufgenommen oder auf der Grundlage historischer Daten gelernt werden. Die Blöcke 910 und 920 können wie oben unter Bezugnahme auf 8 beschrieben sein. In Block 930 wird die Bare-Metal-Maschine aus dem Satz von Kandidatenmaschinen ausgewählt, die eine Überschussressourcen-Metrik aufweisen, die die geringste Menge an überschüssigen Ressourcen anzeigt und die auch die Wahrscheinlichkeit minimiert, dass die überschüssigen Ressourcen benötigt werden, um eine andere Anforderung während der Lebensdauer der Anforderung zu erfüllen. Gemäß einer Ausführungsform beinhaltet diese Minimierung die Minimierung der Summe der Wahrscheinlichkeitsmetriken der überschüssigen Ressourcen der ausgewählten Bare-Metal-Maschine. In alternativen Ausführungsformen kann die Minimierung auf Maschinenebene durchgeführt werden, um die Wahrscheinlichkeit zu minimieren, dass die ausgewählte Maschine während der Lebensdauer der Anforderung zur Erfüllung einer anderen Anforderung benötigt wird.
  • Der Kürze halber wurden oben mit Bezug auf 8 und 9 einige Beispiele für einen Ansatz zur Maschinenauswahl gegeben, aber Fachleute werden verstehen, dass die Anwendbarkeit der hier beschriebenen Methoden über diese speziellen Beispiele hinausgeht. Beispielsweise können in dem Maße, in dem Metadaten oder Informationen zu Bare-Metal-Maschinen verfügbar sind, die auf ihren relativen Stromverbrauch, ihre Sicherheit, Zuverlässigkeit und/oder andere Faktoren hinweisen, die als Grundlage für die Priorisierung der Maschinenauswahl wünschenswert sein können, solche Metadaten oder Informationen vom Maschinenauswahlprozess berücksichtigt werden. Darüber hinaus können in einigen Ausführungsformen maschinelles Lernen und/oder Big-Data-Analysen durch den CaaS-Controller verwendet werden, um Muster und/oder Wahrscheinlichkeiten von Cluster-Anforderungen für Benutzer, Arbeitslasten, Maschinen und/oder Ressourcen aufzudecken. Da der Anbieter den Standort verwaltet und daher unter anderem Einblick in die Benutzer, die von bestimmten Benutzern im Laufe der Zeit gestellten Cluster-Anforderungen, den Maschinenbedarf und die Nutzung im Laufe der Zeit sowie in die auf der Private-Cloud-Infrastruktur ausgeführten Daten hat, können historische Daten allein oder in Kombination mit maschinellem Lernen verwendet werden, um den Maschinenauswahlprozess zu unterstützen. Beispielsweise kann das verwaltete CaaS-System „lernen“, dass ein bestimmter Benutzer häufig größere Maschinen anfordert, als für die betreffende Arbeitslast erforderlich sind, und als Ergebnis kann das verwaltete CaaS-System eine Maschine zuweisen, die etwas kleiner ist als von dem bestimmten Benutzer angefordert. In ähnlicher Weise kann das verwaltete CaaS-System ein Muster beobachten, dass ein bestimmter Benutzer dazu neigt, unterdimensionierte Maschinen anzufordern, und dem bestimmten Benutzer proaktiv die Option anbieten, eine größere Maschine zu wählen. Alternativ oder zusätzlich kann das verwaltete CaaS-System Maschinen- und/oder Ressourcennachfrage-/Nutzungsmuster berücksichtigen, um die Zuweisung von Maschinen in einer Weise zu optimieren, die die Wahrscheinlichkeit der Maschinenverfügbarkeit für die erwarteten Arbeitslastanforderungen und damit die Rentabilität des verwalteten CaaS für den Cloud-Anbieter erhöht.
  • Weitere Beispiele für die Maschinenauswahl sind unter anderem:
    • • Verwendung von Informationen über die Sicherheitsschwachstellen bestimmter Maschinenkonfigurationen, Betriebssysteme, Anwendungsprogramme und/oder Kombinationen davon, um den Prozess der Maschinenauswahl zu steuern
    • • Einsatz von maschinellem Lernen zur Optimierung von Maschinenkonfigurationen, Betriebssystemparametern, Anwendungsprogrammen und/oder Kombinationen davon für häufig beobachtete Arbeitslasten
    • • Verwendung von Merkmalen, die sich auf die Verfügbarkeit auswirken, wie z. B. die Sicherstellung, dass Maschinen, die Redundanz bieten, über unabhängige Stromanschlüsse und Netzwerkpfade verfügen
    • • Sicherstellen, dass Arbeitslasten, die viel Strom benötigen, auf Maschinen an Orten mit günstiger Kühlung platziert werden (z. B. Platzieren von Jobs, die wahrscheinlich heiß laufen, auf Maschinen, die sich direkt über den Lüftungsöffnungen der Klimaanlage befinden)
    • • Verwendung von Leistungsmerkmalen zur Optimierung der Leistung der zugewiesenen Ressourcen. Wenn beispielsweise im Rechenzentrum Netzwerke mit mehreren Geschwindigkeiten vorhanden sind, wird sichergestellt, dass Arbeitslasten, die eine erhebliche Netzwerkbandbreite erfordern, auf Hochgeschwindigkeitsnetzwerken zugewiesen werden.
    • • Betriebskosten - einige Maschinen benötigen mehr Strom und Kühlung, um die gleiche Arbeit zu verrichten. Für Arbeitslasten, die viel Strom benötigen, sollten Sie diese auf Maschinen platzieren, die einen geringeren Strombedarf haben.
    • • Zuverlässigkeit - Einige Maschinen haben eine bessere Erfolgsbilanz
    • • Überkapazitäten - Wenn bestimmte Workloads eher wachsen als andere, können potenzielle zukünftige Störungen vermieden werden, indem diese Workloads auf größere Maschinen gelegt werden.
  • 10 ist ein High-Level-Flussdiagramm, das die Autoskalierungsverarbeitung gemäß einem Ausführungsbeispiel zeigt. Im Kontext des vorliegenden Beispiels können Cloud-Bursting- oder Workload-Shifting-Techniken verwendet werden, um die Handhabung verschiedener Autoskalierungsaktionen zu erleichtern (z. B., Skalieren nach außen, um eine Komponente zu einem Cluster hinzuzufügen, um die Last auf mehr Komponenten zu verteilen, Skalieren nach oben, um eine Komponente des Clusters zu vergrößern oder zu beschleunigen, damit die Komponente mehr Last bewältigen kann, Skalieren nach innen, um eine Komponente aus einem Cluster zu entfernen, um die Last auf weniger Komponenten zu verteilen, und Skalieren nach unten, um eine Komponente des Clusters zu verkleinern oder zu verlangsamen, damit die Komponente kostengünstiger weniger Last bewältigen kann). In einer Ausführungsform kann eine Autoskalierungsrichtlinie zum Zeitpunkt der Clustererstellung als Teil der Clusterinformationen (z. B. Cluster Blueprint 105) bereitgestellt werden und kann Bedingungen (z. B. Obergrenzen und/oder Untergrenzen für metrische Werte oder Statistiken und entsprechende Zeiträume) zum Auslösen entsprechender Autoskalierungsaktionen (z. B. Verkleinern oder Vergrößern der Maschineninstanzen eines Clusters um einen bestimmten Betrag) festlegen. In einer Ausführungsform kann eine Autoskalierungsrichtlinie eine Regel (z. B. einen bedingten Ausdruck) und eine entsprechende Autoskalierungsaktion enthalten, die ausgeführt wird, wenn die Regel erfüllt ist (z. B. wenn der bedingte Ausdruck wahr ist). Beispielsweise kann eine Autoskalierungsrichtlinie für einen bestimmten Cluster angeben, dass ein zusätzlicher kleiner Bare-Metal-Rechner zum Cluster hinzugefügt werden soll, wenn eine Zentraleinheit (CPU) eines vorhandenen Bare-Metal-Rechners im Cluster eine durchschnittliche Auslastung von 90 % über einen Zeitraum von einer Stunde überschreitet. Fachleute wissen, dass Momentanwerte von Metriken oder verschiedene andere Statistiken (z. B. Mittelwert, Maximum, Minimum, Standardabweichung, Perzentile o. Ä.) für Metriken verwendet werden können, um Richtlinien für die automatische Skalierung zu definieren.
  • In Block 1010 werden verschiedene Metriken im Zusammenhang mit dem Betrieb von Clustern überwacht. Gemäß einer Ausführungsform ruft ein CaaS-Controller (z. B. CaaS-Controller 160) regelmäßig Metriken (z. B. Auslastung der Verarbeitungsressourcen, Auslastung der Zentraleinheit (CPU), Auslastung der grafischen Verarbeitungseinheit (GPU), Speicherauslastung, ein- und/oder ausgehender Netzwerkverkehr, Eingabe-/Ausgabeoperationen pro Sekunde (IOPs), Rohgeschwindigkeit, Latenz, Redundanz, Festplatten-Eingabe/Ausgabe (E/A) und Transaktionsanzahl) vom Container-Orchestrierungssystem (z. B., Kubernetes, Docker Swarm o. ä.), in dem die Cluster laufen, über einen geeigneten Container-Cluster-Manager (z. B. Container-Cluster-Manager 170). Alternativ kann der Container-Cluster-Manager solche Metriken periodisch an den CaaS-Controller pushen.
  • Im Entscheidungsblock 1020 wird bestimmt, ob eine Autoskalierungsrichtlinie ausgelöst wurde. Gemäß einer Ausführungsform wird die Autoskalierungsrichtlinie mit Bezug auf die in Block 1010 erhaltenen Metriken bewertet. Zum Beispiel kann ein geeigneter Wert oder ein statistisches Maß in Bezug auf geeignete Metriken verwendet werden, um eine oder mehrere Regeln der Autoskalierungsrichtlinie zu bewerten. Wenn eine Regel erfüllt ist (z. B. wenn der bedingte Ausdruck wahr ist), wird die Verarbeitung mit dem Entscheidungsblock 1030 fortgesetzt; andernfalls führt die Verarbeitung in einer Schleife zurück zu Block 1010, um die Überwachung fortzusetzen.
  • Im Entscheidungsblock 1030 wird eine Autoskalierungsaktion identifiziert. Gemäß einer Ausführungsform kann es sich bei der Autoskalierungsaktion um eine der folgenden Aktionen handeln: „Scale out“, „Scale up“, „Scale down“ oder „Scale in“. Wenn die Autoskalierungsaktion, die der Regel entspricht, für die festgestellt wurde, dass sie erfüllt ist, „Scale out“ ist, wird die Verarbeitung im Kontext des vorliegenden Beispiels mit Block 1040 fortgesetzt. Wenn die entsprechende Autoskalierungsaktion „Vergrößern“ ist, wird die Verarbeitung mit Block 1050 fortgesetzt. Wenn die Regel eine Autoskalierungsaktion „scale down“ auslöst, wird die Verarbeitung mit Block 1060 fortgesetzt. Wenn die entsprechende Autoskalierungsaktion „scale in“ ist, wird die Verarbeitung mit Block 1070 fortgesetzt.
  • In Block 1040 wird eine neue Maschine, die dem Cluster hinzugefügt werden soll, identifiziert. Gemäß einer Ausführungsform identifiziert die Scale-Out-Aktion einen Typ und eine Menge von Maschinen, die dem fraglichen Cluster hinzugefügt werden sollen. Unter der Annahme, dass es sich um eine Bare-Metal-Maschine handelt, die dem Cluster hinzugefügt werden soll, kann auf der Grundlage des Typs und der Menge der Bare-Metal-Maschinen, die hinzugefügt werden sollen, ein Maschinenauswahlprozess durchgeführt werden, um die neue(n) Maschine(n) zu identifizieren. Nicht einschränkende Beispiele für Maschinenauswahlprozesse, die verwendet werden können, wurden oben unter Bezugnahme auf die 8 und 9 beschrieben. Gemäß einer Ausführungsform kann eine Scale-Out-Aktion Cloud-Bursting oder Workload-Shifting beinhalten, um Bedarfsspitzen zu bewältigen. Beispielsweise kann eine Arbeitslast in einer privaten Cloud eines Kunden ausgeführt werden und bei Bedarf in eine öffentliche Cloud ausgelagert werden, um Bedarfsspitzen zu bewältigen, die über diejenigen hinausgehen, die mit der Infrastruktur vor Ort (z. B. Infrastruktur 110) befriedigt werden können. Auf diese Weise kann den Kunden des verwalteten Containerdienstes bei Bedarf flexible Kapazität zur Verfügung gestellt werden.
  • In Block 1050 wird eine vorhandene Maschine im Cluster identifiziert, die durch eine „größere“ Maschine ersetzt werden soll. Gemäß einer Ausführungsform kann die vorhandene Maschine eine Maschine sein, die eine Ressource enthält, deren Metrik(en) die Scale-up-Aktion ausgelöst hat/haben. Zum Beispiel kann eine vorhandene „kleine“ Maschine durch eine Maschine der nächsthöheren Größe (z. B. eine „mittlere“ Maschine) ersetzt werden. Wenn die Maschine, die die Ressource enthält, deren Metrik(en) die Skalierungsaktion ausgelöst hat/haben, bereits die größte verfügbare Maschinengröße ist, kann alternativ eine andere Maschine (z. B. eine „kleine“ oder „mittlere“ Maschine) innerhalb des Clusters zum Ersetzen identifiziert werden. In einigen Ausführungsformen, wie oben unter Bezugnahme auf die Handhabung einer Scale-Out-Aktion beschrieben, kann eine Scale-Up-Aktion das Ersetzen einer privaten Cloud-Infrastruktur (z. B. einer Bare-Metal-Maschine vor Ort) durch eine physische oder virtuelle Maschine in einer öffentlichen Cloud beinhalten. In anderen Beispielen können der vorhandene Rechner und der „größere“ Rechner beide Bare-Metal-Rechner im lokalen Infrastrukturbestand sein.
  • In Block 1060 wird eine vorhandene Maschine im Cluster identifiziert, die durch eine „kleinere“ Maschine ersetzt werden soll. Gemäß einer Ausführungsform kann die vorhandene Maschine eine Maschine sein, die eine Ressource enthält, deren Metrik(en) die Verkleinerungsaktion ausgelöst haben. Zum Beispiel kann eine vorhandene „große“ Maschine durch eine Maschine der nächstkleineren Größe (z. B. eine „mittlere“ Maschine) ersetzt werden. Wenn die Maschine, die die Ressource enthält, deren Metrik(en) die Verkleinerungsaktion ausgelöst hat/haben, bereits die kleinste verfügbare Maschinengröße ist, kann alternativ eine andere Maschine (z. B. eine „mittlere“ Maschine) innerhalb des Clusters zum Ersetzen identifiziert werden. In einigen Ausführungsformen kann der Vorzug gegeben werden, zuerst die Auslastung der öffentlichen Cloud-Infrastruktur zu reduzieren. Eine Verkleinerungsaktion kann beispielsweise das Ersetzen einer physischen oder virtuellen Maschine in einer öffentlichen Cloud durch eine private Cloud-Infrastruktur (z. B. eine Bare-Metal-Maschine, die sich vor Ort befindet) umfassen. In anderen Beispielen können der vorhandene Rechner und der „kleinere“ Rechner beide Bare-Metal-Rechner im lokalen Infrastrukturbestand sein.
  • In Block 1070 wird eine Maschine identifiziert, die aus dem Cluster entfernt werden soll. Gemäß einer Ausführungsform identifiziert die Waage in Aktion einen Typ und eine Menge von Maschinen, die aus dem betreffenden Cluster entfernt werden sollen. Unter der Annahme, dass es sich um eine Bare-Metal-Maschine handelt, die aus dem Cluster entfernt werden soll, kann auf der Grundlage des Typs und der Menge der zu entfernenden Bare-Metal-Maschinen ein Maschinenauswahlprozess ähnlich dem oben unter Bezugnahme auf die 8 und 9 beschrieben ist, verwendet werden, um z. B. eine zu entfernende Maschine zu identifizieren, die zu einer Minimierung der überschüssigen Ressourcen der verbleibenden Maschinen im Cluster führt. Gemäß einer Ausführungsform kann eine Skalierungsmaßnahme die Umkehrung des Cloud-Bursting oder der Arbeitslastverschiebung beinhalten, die zuvor zur Bewältigung von Bedarfsspitzen durchgeführt wurde. Beispielsweise kann nach einer Nachfragespitze die Nutzung der öffentlichen Cloud-Infrastruktur durch den Cluster zunächst reduziert werden, bevor die private Cloud-Infrastruktur (z. B. eine Bare-Metal-Maschine, die sich vor Ort befindet) reduziert wird. Auf diese Weise kann der Cloud-Anbieter die tatsächliche Nutzung der Public-Cloud-Infrastruktur durch einen Kunden messen und dem Kunden nur das in Rechnung stellen, was er verbraucht, und so flexible und bedarfsgerechte Kapazitäten bereitstellen, wenn in der Private Cloud des Kunden nicht genügend Ressourcen verfügbar sind.
  • Zusätzlich oder alternativ zu den verschiedenen hier beschriebenen Optimierungen, maschinellen Lern- und Big-Data-Analyseansätzen kann in einigen Ausführungsformen die Identifizierung einer neuen Bare-Metal-Maschine, die zu einem Cluster hinzugefügt werden soll (z. B., als Reaktion auf eine Scale-Out- oder Scale-Up-Aktion, die die Identifizierung einer neuen Maschine zum Hinzufügen zu einem Cluster oder zum Ersetzen einer vorhandenen „kleineren“ Maschine in einem Cluster erfordert), können maschinelles Lernen oder Big-Data-Analysen verwendet werden, um auf intelligente Weise eine bestimmte Maschinenkonfiguration (aus den begrenzten Maschinen, die im Bestand verfügbar sind) auszuwählen, die nachweislich eine gute Leistung für die betreffende Arbeitslast erbringt. In ähnlicher Weise kann bei einer Vergrößerungs- oder Verkleinerungsaktion, bei der eine vorhandene Maschine innerhalb eines Clusters zum Entfernen oder Ersetzen durch eine „kleinere“ Maschine identifiziert werden muss, die Identifizierung der vorhandenen Maschine, die aus dem Cluster entfernt werden soll, beispielsweise die Identifizierung einer bestimmten Maschinenkonfiguration beinhalten, die für die betreffende(n) Arbeitslast(en) nicht so gut funktioniert wie andere Maschinen im Cluster.
  • Während das obige Beispiel im Kontext der „automatischen Skalierung“ beschrieben wird, sind die hier beschriebenen Methoden auch auf die „automatische Platzierung“ anwendbar. So kann z. B. bei der Bewertung, ob Arbeit von einer Maschine (M1), die aus einem oder mehreren Gründen nicht die effizienteste für die betreffende Arbeit ist, auf eine andere (M2) verlagert werden soll, die als besser für die betreffende Arbeit angesehen wird, eine Kopie der auf M1 laufenden Instanzen auf M2 hochgefahren und dann M1 heruntergefahren werden.
  • Während das obige Beispiel mit Bezug auf verschiedene Metriken im Zusammenhang mit der Infrastruktur beschrieben wird, werden Fachleute verstehen, dass eine Vielzahl anderer Metriken aus der Umgebung ebenfalls verwendet werden können. Beispielsweise können die verschiedenen Metriken, die mit dem Betrieb von Clustern verbunden sind, die im Entscheidungsblock 1020 ausgewertet werden, neben anderen möglichen Metriken die Temperatur, die Kühlkosten (Maschinen in der Nähe von Lüftungsöffnungen könnten billiger zu kühlen sein als solche, die weit entfernt sind) und/oder den Stromverbrauch (einige Maschinentypen benötigen weniger Strom pro Arbeitseinheit), die Stromkosten (eine große Installation könnte mehr als eine Stromquelle haben) umfassen.
  • Zur Veranschaulichung eines konkreten Beispiels, wie richtlinienbasierte Einschränkungen die automatische Skalierung beeinflussen können, betrachten wir eine Autoskalierungsrichtlinie, die angibt, dass ein „großer“ Arbeitsknoten hinzugefügt werden sollte, wenn die CPU-Auslastung eines vorhandenen Arbeitsknotens über einen Zeitraum von einer Stunde mehr als 70 % beträgt und eine richtlinienbasierte Einschränkung, die mit dem Cluster verbunden ist, den Wunsch nach einer Minimierung der Stromkosten ausdrückt. Wenn in einem solchen Szenario die automatische Skalierungsrichtlinie ausgelöst wird, um den Cluster zu skalieren, kann bei der Bewertung von Kandidatenrechnern für den neuen Arbeitsknoten, der dem Cluster hinzugefügt werden soll, eine bestimmte Energiequelle berücksichtigt werden, die mit den Kandidatenrechnern verbunden ist. Ähnliche richtlinienbasierte Einschränkungen können für Scale-Up-, Scale-In- und/oder Scale-Down-Aktionen in Betracht gezogen werden.
  • 11 ist ein Flussdiagramm, das die automatische Skalierungsverarbeitung veranschaulicht, bei der eine Bare-Metal-Maschine identifiziert wird, die zu einem Cluster hinzugefügt werden soll, in Übereinstimmung mit einer Beispielsausführungsform. In Block 1110 wird eine Metrik überwacht, die mit dem Betrieb eines Clusters verbunden ist, der im Auftrag eines Kunden innerhalb eines Container-Orchestrierungssystems bereitgestellt wird. Nicht einschränkende Beispiele für die Metrik umfassen die Auslastung der Zentraleinheit (CPU), die Speicherauslastung, den eingehenden und/oder ausgehenden Netzwerkverkehr, die Latenz, die Festplatten-Eingabe/Ausgabe (E/A) und die Transaktionsanzahl. Abhängig von der jeweiligen Implementierung kann die Metrik von einem CaaS-Controller (z. B. CaaS-Controller 160) periodisch oder bei Bedarf von dem Container-Orchestrierungssystem (z. B. Kubernetes, Docker Swarm o. Ä.) abgerufen werden, in dem der betreffende Cluster über einen geeigneten Container-Cluster-Manager (z. B. Container-Cluster-Manager 170) ausgeführt wird. Alternativ kann der Container-Cluster-Manager eine solche Metrik an den CaaS-Controller senden.
  • In Block 1120 wird als Reaktion auf ein Skalierungsereignis, das für den Cluster auf der Grundlage der Überwachung und einer dem Cluster zugeordneten Autoskalierungsrichtlinie identifiziert wird, ein BMaaS-Controller, der in einer privaten Cloud des Kunden läuft, veranlasst, ein Inventar der in der privaten Cloud verfügbaren Bare-Metal-Maschinen zu erstellen oder zu aktualisieren. Gemäß einer Ausführungsform enthält das Inventar Echtzeitinformationen, die die jeweiligen Ressourcen (z. B. eine Anzahl von Prozessorkernen, eine Menge an Arbeitsspeicher, Netzwerkkapazität und/oder Speicherleistung) für eine oder mehrere Arten von Infrastruktur (z. B. Infrastruktur 110), einschließlich eines Satzes von Bare-Metal-Maschinen, anzeigen, die derzeit verfügbar sind (z. B. derzeit nicht zur Verwendung durch einen anderen Cluster bereitgestellt werden), um in Verbindung mit der Unterstützung des verwalteten Containerdienstes verwendet zu werden. Abhängig von der jeweiligen Implementierung kann das Inventar von einem BMaaS-Anbieter durch den CaaS-Controller direkt (z. B. über ein Bare-Metal-SaaS-Portal des BMaaS-Anbieters) oder indirekt (z. B. über das CaaS-Portal) angefordert werden.
  • In Block 1130 wird eine Bare-Metal-Maschine identifiziert, die dem Cluster hinzugefügt werden soll, und zwar auf der Grundlage des in Block 1120 empfangenen Inventars, der betreffenden Autoskalierungsrichtlinie und eines Best-Fit-Algorithmus, der in Übereinstimmung mit einer vom Kunden oder im Namen des Kunden festgelegten Richtlinie konfiguriert wurde. Gemäß einer Ausführungsform werden der Typ und die Anzahl der Maschinen, die dem Cluster hinzugefügt werden sollen, durch die ausgelöste Autoskalierungsregel der Autoskalierungsrichtlinie bestimmt. Alternativ kann der Typ der hinzuzufügenden Maschine so ausgewählt werden, dass er mit anderen vorhandenen Maschinen, die bereits Teil des Clusters sind, konsistent ist. Obwohl der Kunde vermutlich eine Vielzahl von Bare-Metal-Maschinenkonfigurationen in seiner privaten Cloud hat, ist es unwahrscheinlich, dass der Kunde eine ausreichende Anzahl solcher Konfigurationen hat, um den Bereich aller potenziellen Cluster-Anforderungen genau abdecken zu können. Daher bieten die hier beschriebenen Ausführungsformen einen richtlinienbasierten Ansatz, der es dem Cloud-Anbieter und/oder dem Kunden ermöglicht, eine oder mehrere Prioritäten für die Maschinenauswahl anzugeben, die als Teil eines Best-Fit-Algorithmus angewendet werden. Nicht einschränkende Beispiele für die Best-Fit-Verarbeitung, die Teil des Best-Fit-Algorithmus sein kann, sind oben unter Bezugnahme auf 8 und 9 beschrieben.
  • Die hier beschriebenen Ausführungsformen umfassen verschiedene Schritte, von denen Beispiele oben beschrieben wurden. Wie weiter unten beschrieben, können diese Schritte von Hardware-Komponenten ausgeführt werden oder in maschinenausführbaren Befehlen verkörpert sein, die verwendet werden können, um einen mit den Befehlen programmierten Allzweck- oder Spezialprozessor zu veranlassen, die Schritte auszuführen. Alternativ können zumindest einige Schritte durch eine Kombination aus Hardware, Software und/oder Firmware ausgeführt werden.
  • Hierin beschriebene Ausführungsformen können als Computerprogrammprodukt bereitgestellt werden, das ein maschinenlesbares Speichermedium umfassen kann, auf dem Anweisungen greifbar verkörpert sind, die zur Programmierung eines Computers (oder anderer elektronischer Geräte) zur Durchführung eines Prozesses verwendet werden können. Das maschinenlesbare Medium kann unter anderem Festplattenlaufwerke, Magnetbänder, Disketten, optische Platten, Compact-Disc-Festwertspeicher (CD-ROMs) und magneto-optische Platten, Halbleiterspeicher, wie ROMs, PROMs RAMs (Random Access Memories), PROMs (Programmable Read-Only Memories), EPROMs (Erasable PROMs), EEPROMs (Electrically Erasable PROMs), Flash-Speicher, magnetische oder optische Karten oder andere Arten von Medien/Maschinen-lesbaren Medien, die zum Speichern von elektronischen Befehlen geeignet sind (z.g., Computerprogrammiercode, wie z. B. Software oder Firmware).
  • Verschiedene hierin beschriebene Verfahren können durch die Kombination eines oder mehrerer maschinenlesbarer Speichermedien, die den Code gemäß den hierin beschriebenen Beispielausführungen enthalten, mit geeigneter Standard-Computerhardware zur Ausführung des darin enthaltenen Codes durchgeführt werden. Eine Vorrichtung zum Ausführen verschiedener hierin beschriebener Beispielausführungen kann ein oder mehrere Rechenelemente oder Computer (oder einen oder mehrere Prozessoren innerhalb eines einzelnen Computers) und Speichersysteme umfassen, die Computerprogramm(e), die gemäß verschiedenen hierin beschriebenen Verfahren codiert sind, enthalten oder über ein Netzwerk darauf zugreifen, und die Verfahrensschritte verschiedener hierin beschriebener Beispielausführungen können durch Module, Routinen, Unterprogramme oder Unterteile eines Computerprogrammprodukts ausgeführt werden.
  • 12 ist ein Blockdiagramm eines Computersystems in Übereinstimmung mit einer Ausführungsform. In dem in 12 dargestellten Beispiel umfasst das Computersystem 1200 eine Verarbeitungsressource 1210, die mit einem nicht-transitorischen, maschinenlesbaren Medium 1220 gekoppelt ist, das mit Befehlen zur Durchführung einer Private-Cloud-Gateway-Erstellungsverarbeitung kodiert ist. Die Verarbeitungsressource 1210 kann einen Mikrocontroller, einen Mikroprozessor, (einen) Zentralverarbeitungseinheitenkern(e), einen ASIC, einen FPGA und/oder ein anderes Hardwaregerät umfassen, das zum Abrufen und/oder Ausführen von Anweisungen vom maschinenlesbaren Medium 1220 geeignet ist, um die Funktionen in Bezug auf verschiedene hier beschriebene Beispiele auszuführen. Zusätzlich oder alternativ kann die Verarbeitungsressource 1210 eine elektronische Schaltung zur Ausführung der Funktionalität der hier beschriebenen Anweisungen enthalten.
  • Das maschinenlesbare Medium 1220 kann ein beliebiges Medium sein, das zum Speichern von ausführbaren Anweisungen geeignet ist. Nicht einschränkende Beispiele für ein maschinenlesbares Medium 1220 sind RAM, ROM, EEPROM, Flash-Speicher, ein Festplattenlaufwerk, eine optische Platte oder Ähnliches. Das maschinenlesbare Medium 1220 kann innerhalb des Computersystems 1200 angeordnet sein, wie in 12 gezeigt, in welchem Fall die ausführbaren Anweisungen als „installiert“ oder „eingebettet“ in das Computersystem 1200 angesehen werden können. Alternativ kann das maschinenlesbare Medium 1220 ein tragbares (z. B. externes) Speichermedium sein und kann Teil eines „Installationspakets“ sein. Die auf dem maschinenlesbaren Medium 1220 gespeicherten Anweisungen können nützlich sein, um zumindest einen Teil der hier beschriebenen Verfahren zu implementieren.
  • Im Kontext des vorliegenden Beispiels ist das maschinenlesbare Medium 1220 mit einem Satz von ausführbaren Anweisungen 1230-1250 kodiert. Es versteht sich, dass ein Teil oder die Gesamtheit der ausführbaren Anweisungen und/oder elektronischen Schaltungen, die in einem Block enthalten sind, in alternativen Implementierungen in einem anderen, in den Figuren dargestellten Block oder in einem anderen, nicht dargestellten Block enthalten sein können.
  • Anweisungen 1230 veranlassen die Verarbeitungsressource 1210 bei der Ausführung, eine Metrik zu überwachen, die mit dem Betrieb eines Clusters verbunden ist, der im Auftrag eines Kunden innerhalb eines Container-Orchestrierungssystems bereitgestellt wird. In einer Ausführungsform können die Anweisungen 1230 im Allgemeinen den Anweisungen zur Ausführung von Block 1110 von 11 entsprechen.
  • Anweisungen 1240 veranlassen bei der Ausführung die Verarbeitungsressource 1210, als Reaktion auf ein Skalierungsereignis, das für den Cluster auf der Grundlage der Überwachung und einer dem Cluster zugeordneten Autoskalierungsrichtlinie identifiziert wird, einen BMaaS-Controller, der in einer privaten Cloud des Kunden läuft, zu veranlassen, ein Inventar der in der privaten Cloud verfügbaren Bare-Metal-Maschinen zu erstellen. In einer Ausführungsform können die Anweisungen 1240 allgemein den Anweisungen zur Durchführung von Block 1120 von 11 entsprechen.
  • Anweisungen 1250 veranlassen die Verarbeitungsressource 1210 bei der Ausführung, eine Bare-Metal-Maschine zu identifizieren, die dem Cluster hinzugefügt werden soll, und zwar auf der Grundlage des Inventars, der betreffenden Autoskalierungsrichtlinie und eines Best-Fit-Algorithmus, der gemäß einer vom Kunden festgelegten Richtlinie konfiguriert ist. In einer Ausführungsform können die Anweisungen 1250 allgemein den Anweisungen zur Durchführung des Blocks 1130 von 11 entsprechen.
  • In der vorstehenden Beschreibung sind zahlreiche Details aufgeführt, um ein Verständnis des hier offengelegten Gegenstands zu ermöglichen. Die Implementierung kann jedoch auch ohne einige oder alle dieser Details durchgeführt werden. Andere Implementierungen können Modifikationen und Variationen von den oben beschriebenen Details enthalten. Es ist beabsichtigt, dass die folgenden Ansprüche solche Modifikationen und Variationen abdecken.

Claims (20)

  1. Ein System, das Folgendes umfasst: eine Verarbeitungsressource; und ein nicht-transitorisches, computerlesbares Medium, das mit der Verarbeitungsressource gekoppelt ist und in dem Anweisungen gespeichert sind, die, wenn sie von der Verarbeitungsressource ausgeführt werden, die Verarbeitungsressource dazu veranlassen: eine Metrik zu überwachen, die mit dem Betrieb eines Clusters verbunden ist, der im Auftrag eines Kunden eines verwalteten Containerdienstes innerhalb eines Container-Orchestrierungssystems eingesetzt wird; als Reaktion auf ein Skalierungsereignis, das für den Cluster auf der Grundlage der Überwachung und einer mit dem Cluster assoziierten Autoskalierungsrichtlinie identifiziert wird, einen mit der privaten Cloud assoziierten Bare-Metal-as-a-Service (BMaaS)-Anbieter veranlassen, ein Inventar einer Vielzahl von in der privaten Cloud verfügbaren Bare-Metal-Maschinen zu erstellen; und Identifizieren eines Bare-Metal-Rechners, der dem Cluster hinzugefügt werden soll, durch Auswahl aus der Vielzahl von Bare-Metal-Rechnern auf der Grundlage der Autoskalierungsrichtlinie, des Inventars und eines Best-Fit-Algorithmus, der in Übereinstimmung mit einer Richtlinie konfiguriert ist, die vom oder im Namen des Kunden festgelegt wurde.
  2. Das System nach Anspruch 1, wobei die Anweisungen ferner die Verarbeitungsressource veranlassen, die Autoskalierungsrichtlinie als Teil einer Definition des Clusters von einem Benutzer des Kunden zu empfangen, wobei die Definition des Clusters Informationen bezüglich einer Maschinenkonfiguration enthält, die von dem Cluster verwendet werden soll.
  3. Das System nach Anspruch 1, wobei das Skalierungsereignis das Auslösen einer Scale-out-Aktion einer Regel der Autoskalierungsrichtlinie umfasst.
  4. Das System nach Anspruch 1, wobei die Anweisungen ferner die Verarbeitungsressource veranlassen, dem Kunden eine flexible Kapazität durch Verwendung von Cloud-Bursting oder Workload-Shifting bereitzustellen, wenn die mit dem Cluster verbundene Nachfrage eine Kapazität der privaten Cloud übersteigt.
  5. Das System nach Anspruch 1, wobei die Richtlinie ein Ziel der Minimierung überschüssiger Ressourcen der Mehrzahl von Bare-Metal-Maschinen ausdrückt, wobei das Inventar Informationen enthält, die einen Wert jeder Ressource für jede der Mehrzahl von Bare-Metal-Maschinen quantifizieren, und wobei die Befehle ferner den Prozessor veranlassen: eine Teilmenge der Vielzahl von Bare-Metal-Maschinen identifizieren, die einen Typ und eine Menge von Ressourcen aufweisen, die eine durch die Autoskalierungsrichtlinie identifizierte Maschinenspezifikation erfüllen; für jede Maschine in der Teilmenge, Berechnen einer Überschuss-Ressourcen-Metrik basierend auf einer Menge von Ressourcen der Maschine, die über die Ressourcen hinausgehen, die erforderlich sind, um die Maschinenspezifikation zu erfüllen; und Auswahl einer Maschine aus der Untergruppe, deren Ressourcenüberschuss-Metrik die geringste Menge an überschüssigen Ressourcen anzeigt, als bestimmte Bare-Metal-Maschine.
  6. Das System nach Anspruch 1, wobei die Anweisungen ferner die Verarbeitungsressource veranlassen, den BMaaS-Anbieter aufzufordern, das Inventar über ein BMaaS-Portal zu erstellen, das dem BMaaS-Anbieter zugeordnet ist.
  7. Das System nach Anspruch 6, wobei die Bereitstellung des Clusters als Reaktion auf eine über ein Container-as-a-Service (CaaS)-Portal empfangene Anforderung erfolgte.
  8. Das System nach Anspruch 7, wobei das CaaS-Portal und das BMaaS-Portal innerhalb einer öffentlichen Cloud betreibbar sind.
  9. Das System nach Anspruch 1, wobei das System einen CaaS-Controller umfasst, der innerhalb der öffentlichen Cloud betrieben werden kann.
  10. Das System nach Anspruch 1, wobei das System einen CaaS-Controller umfasst, der innerhalb der privaten Cloud betrieben werden kann.
  11. Ein nicht-transitorisches maschinenlesbares Medium, das Befehle speichert, die, wenn sie von einer Verarbeitungsressource eines Computersystems ausgeführt werden, die Verarbeitungsressource dazu veranlassen: eine Metrik zu überwachen, die mit dem Betrieb eines Clusters verbunden ist, der im Auftrag eines Kunden eines verwalteten Containerdienstes innerhalb eines Container-Orchestrierungssystems eingesetzt wird; als Reaktion auf ein Skalierungsereignis, das für den Cluster auf der Grundlage der Überwachung und einer mit dem Cluster assoziierten Autoskalierungsrichtlinie identifiziert wird, einen mit der privaten Cloud assoziierten Bare-Metal-as-a-Service (BMaaS)-Anbieter veranlassen, ein Inventar einer Vielzahl von in der privaten Cloud verfügbaren Bare-Metal-Maschinen zu erstellen; und Identifizieren eines Bare-Metal-Rechners, der dem Cluster hinzugefügt werden soll, durch Auswahl aus der Vielzahl von Bare-Metal-Rechnern auf der Grundlage der Autoskalierungsrichtlinie, des Inventars und eines Best-Fit-Algorithmus, der in Übereinstimmung mit einer Richtlinie konfiguriert ist, die vom oder im Namen des Kunden festgelegt wurde.
  12. Das nicht-transitorische maschinenlesbare Medium nach Anspruch 11, wobei die Anweisungen ferner die Verarbeitungsressource veranlassen, die Autoskalierungsrichtlinie als Teil einer Definition des Clusters von einem Benutzer des Kunden zu empfangen, wobei die Definition des Clusters Informationen bezüglich einer Maschinenkonfiguration enthält, die von dem Cluster verwendet werden soll.
  13. Das nicht-transitorische maschinenlesbare Medium nach Anspruch 11, wobei das Skalierungsereignis das Auslösen einer Scale-Out-Aktion einer Regel der Autoskalierungsrichtlinie umfasst.
  14. Das nicht-transitorische maschinenlesbare Medium nach Anspruch 13, wobei die Anweisungen ferner die Verarbeitungsressource veranlassen, dem Kunden flexible Kapazität durch Verwendung von Cloud-Bursting oder Workload-Shifting bereitzustellen, wenn die mit dem Cluster verbundene Nachfrage eine Kapazität der privaten Cloud übersteigt.
  15. Das nicht-transitorische maschinenlesbare Medium nach Anspruch 11, wobei die Richtlinie ein Ziel der Minimierung überschüssiger Ressourcen der Mehrzahl von Bare-Metal-Maschinen ausdrückt, wobei das Inventar Informationen enthält, die einen Wert jeder Ressource für jede der Mehrzahl von Bare-Metal-Maschinen quantifizieren, und wobei die Anweisungen ferner den Prozessor dazu veranlassen: eine Teilmenge der Vielzahl von Bare-Metal-Maschinen identifizieren, die einen Typ und eine Menge von Ressourcen aufweisen, die eine durch die Autoskalierungsrichtlinie identifizierte Maschinenspezifikation erfüllen; für jede Maschine in der Teilmenge, Berechnen einer Überschuss-Ressourcen-Metrik basierend auf einer Menge von Ressourcen der Maschine, die über die Ressourcen hinausgehen, die erforderlich sind, um die Maschinenspezifikation zu erfüllen; und Auswahl einer Maschine aus der Untergruppe, deren Ressourcenüberschuss-Metrik die geringste Menge an überschüssigen Ressourcen anzeigt, als bestimmte Bare-Metal-Maschine.
  16. Das nicht-transitorische maschinenlesbare Medium nach Anspruch 11, wobei die Anweisungen ferner die Verarbeitungsressource veranlassen, den BMaaS-Anbieter aufzufordern, das Inventar über ein BMaaS-Portal zu erstellen, das mit dem BMaaS-Anbieter verbunden ist.
  17. Ein Verfahren, das Folgendes umfasst: Überwachung, durch eine Verarbeitungsressource eines Container-as-a-Service (CaaS)-Controllers eines verwalteten Containerdienstes, einer Metrik, die mit dem Betrieb eines Clusters verbunden ist, der im Auftrag eines Kunden des verwalteten Containerdienstes innerhalb eines Container-Orchestrierungssystems eingesetzt wird; als Reaktion auf ein Skalierungsereignis, das für den Cluster auf der Grundlage der Überwachung und einer mit dem Cluster assoziierten Autoskalierungsrichtlinie identifiziert wird, Bewirken durch die Verarbeitungsressource, dass ein mit der privaten Wolke assoziierter Bare-Metal-as-a-Service (BMaaS)-Anbieter ein Inventar einer Vielzahl von in der privaten Wolke verfügbaren Bare-Metal-Maschinen erstellt; und Identifizieren einer Bare-Metal-Maschine, die dem Cluster hinzugefügt werden soll, durch die Verarbeitungsressource, indem unter der Vielzahl von Bare-Metal-Maschinen auf der Grundlage der Autoskalierungsrichtlinie, des Inventars und eines Best-Fit-Algorithmus, der gemäß einer vom Kunden oder im Namen des Kunden festgelegten Richtlinie konfiguriert wurde, ausgewählt wird.
  18. Verfahren nach Anspruch 17, ferner umfassend das Empfangen der Autoskalierungsrichtlinie durch die Verarbeitungsressource als Teil einer Definition des Clusters von einem Benutzer des Kunden, wobei die Definition des Clusters Informationen bezüglich einer Maschinenkonfiguration enthält, die von dem Cluster verwendet werden soll.
  19. Verfahren nach Anspruch 17, wobei das Skalierungsereignis das Auslösen einer Scale-Out-Aktion einer Regel der Autoskalierungsrichtlinie umfasst.
  20. Verfahren nach Anspruch 17, das ferner umfasst, dass durch die Verarbeitungsressource veranlasst wird, dass dem Kunden flexible Kapazität unter Verwendung von Cloud-Bursting oder Workload-Shifting bereitgestellt wird, wenn die mit dem Cluster verbundene Nachfrage eine Kapazität der privaten Cloud übersteigt.
DE102021109511.5A 2020-06-22 2021-04-15 Container-as-a- service (caas)-controller für die überwachung von clustern und die implementierung von autoscaling-richtlinien Pending DE102021109511A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16/908,042 US11301276B2 (en) 2020-06-22 2020-06-22 Container-as-a-service (CaaS) controller for monitoring clusters and implemeting autoscaling policies
US16908042 2020-06-22

Publications (1)

Publication Number Publication Date
DE102021109511A1 true DE102021109511A1 (de) 2021-12-23

Family

ID=78823274

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102021109511.5A Pending DE102021109511A1 (de) 2020-06-22 2021-04-15 Container-as-a- service (caas)-controller für die überwachung von clustern und die implementierung von autoscaling-richtlinien

Country Status (3)

Country Link
US (3) US11301276B2 (de)
CN (1) CN113900767B (de)
DE (1) DE102021109511A1 (de)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11301276B2 (en) 2020-06-22 2022-04-12 Hewlett Packard Enterprise Development Lp Container-as-a-service (CaaS) controller for monitoring clusters and implemeting autoscaling policies
US11625256B2 (en) 2020-06-22 2023-04-11 Hewlett Packard Enterprise Development Lp Container-as-a-service (CAAS) controller for selecting a bare-metal machine of a private cloud for a cluster of a managed container service
US20220027778A1 (en) * 2020-07-22 2022-01-27 International Business Machines Corporation Runtime environment determination for software containers
US20220066904A1 (en) * 2020-08-28 2022-03-03 Red Hat, Inc. Simulating containerized clusters
KR20230069088A (ko) * 2020-09-18 2023-05-18 지티이 코포레이션 컨테이너 클러스터 관리 방법 및 그 시스템
US11550633B2 (en) * 2020-10-31 2023-01-10 Nutanix, Inc. Intra-footprint computing cluster bring-up
US11900172B2 (en) 2021-07-30 2024-02-13 Nutanix, Inc. Computing cluster bring-up on public cloud infrastructure using expressed intents
KR102553084B1 (ko) * 2021-12-30 2023-07-07 아콘소프트 주식회사 엣지 클라우드 구성요소의 고속 설치가 가능한 엣지 클라우드 구축 시스템 및 방법
CN114584559A (zh) * 2022-03-07 2022-06-03 浪潮云信息技术股份公司 一种实现声明式管理容器云的方法及装置
CN116225624B (zh) * 2023-05-09 2023-06-30 江苏博云科技股份有限公司 基于kubernets的裸机管理方法、系统和装置
CN117743181A (zh) * 2023-12-25 2024-03-22 杭州云掣科技有限公司 一种构建可观测控制面的系统

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10411975B2 (en) 2013-03-15 2019-09-10 Csc Agility Platform, Inc. System and method for a cloud computing abstraction with multi-tier deployment policy
US9769085B2 (en) 2012-05-04 2017-09-19 Citrix Systems, Inc. Systems and methods for adaptive application provisioning
US9363190B2 (en) 2013-07-31 2016-06-07 Manjrasoft Pty. Ltd. System, method and computer program product for energy-efficient and service level agreement (SLA)-based management of data centers for cloud computing
JP2015149578A (ja) 2014-02-06 2015-08-20 株式会社日立製作所 運用管理装置
US9606826B2 (en) * 2014-08-21 2017-03-28 International Business Machines Corporation Selecting virtual machines to be migrated to public cloud during cloud bursting based on resource usage and scaling policies
US9848041B2 (en) * 2015-05-01 2017-12-19 Amazon Technologies, Inc. Automatic scaling of resource instance groups within compute clusters
US10162682B2 (en) 2016-02-16 2018-12-25 Red Hat, Inc. Automatically scaling up physical resources in a computing infrastructure
WO2017200878A1 (en) * 2016-05-17 2017-11-23 Amazon Technologies, Inc. Versatile autoscaling
US10230662B2 (en) * 2016-05-20 2019-03-12 Mitel Networks, Inc. Hybrid cloud deployment for hybrid unified communications
WO2018053717A1 (en) 2016-09-21 2018-03-29 Accenture Global Solutions Limited Dynamic resource allocation for application containers
US10379835B2 (en) 2016-12-19 2019-08-13 International Business Machines Corporation Optimized creation of distributed storage and distributed processing clusters on demand
JP6878910B2 (ja) 2017-01-25 2021-06-02 富士通株式会社 管理装置、管理方法、およびプログラム
US20190122156A1 (en) 2017-10-20 2019-04-25 International Business Machines Corporation Orchestration Engine Blueprint Milestones
CN110502349A (zh) 2018-05-16 2019-11-26 北京理工大学 一种构建云端容器应用的编排方法
CN114880078A (zh) 2018-06-05 2022-08-09 华为技术有限公司 管理容器服务的方法和装置
US10972449B1 (en) 2018-06-28 2021-04-06 Amazon Technologies, Inc. Communication with components of secure environment
US10846122B2 (en) 2018-09-19 2020-11-24 Google Llc Resource manager integration in cloud computing environments
US20190097900A1 (en) 2018-11-26 2019-03-28 Bryan J. Rodriguez Zero-configuration cluster and provisioning pipeline for heterogeneous computing nodes
US10860362B2 (en) 2019-01-09 2020-12-08 Vmware, Inc. Methods and apparatus to deploy a hybrid workload domain
US11392843B2 (en) 2019-04-01 2022-07-19 Accenture Global Solutions Limited Utilizing a machine learning model to predict a quantity of cloud resources to allocate to a customer
US11425025B2 (en) 2019-11-27 2022-08-23 Telefonaktiebolaget L M Ericsson (Publ) Method for providing a low-latency, distributed, multi-user application through an edge cloud platform
US10992540B1 (en) 2020-05-19 2021-04-27 Cisco Technology, Inc. Determining formal models using weighting factors for computing elements in multi-cloud environments
US11301276B2 (en) 2020-06-22 2022-04-12 Hewlett Packard Enterprise Development Lp Container-as-a-service (CaaS) controller for monitoring clusters and implemeting autoscaling policies

Also Published As

Publication number Publication date
US20230359476A1 (en) 2023-11-09
US11989574B2 (en) 2024-05-21
CN113900767B (zh) 2023-05-02
US11301276B2 (en) 2022-04-12
US20220222095A1 (en) 2022-07-14
CN113900767A (zh) 2022-01-07
US20210397465A1 (en) 2021-12-23

Similar Documents

Publication Publication Date Title
DE102021109511A1 (de) Container-as-a- service (caas)-controller für die überwachung von clustern und die implementierung von autoscaling-richtlinien
DE102021109774A1 (de) Container-as-a-service (CAAS)-Controller für die Auswahl einer Bare-Metal-Maschine einer privaten Cloud für einen Cluster eines verwalteten Containerdienstes
DE112021006130T5 (de) Automatisierte orchestrierung von containern durch bewerten von mikrodiensten
DE112020000629T5 (de) Vereinheitlichte und automatisierte installation, einsatz, konfiguration und verwaltung von softwaredefinierten speicheranlagen
DE112011100094T5 (de) Verfahren und System zum Abstrahieren eines auf nichtfunktionalen Anforderungen beruhenden Einsatzes von virtuellen Maschinen
DE112011103522T5 (de) Erstellung eines Multidimensionalen Modells von Software-Angeboten
DE102015105884A1 (de) Zuverlässige und deterministische Live-Migration von virtuellen Maschinen
DE112012000444T5 (de) Ermitteln einer optimalen Datenverarbeitungsumgebung zum Ausführen eines Abbildes
DE112021000390T5 (de) Anpassen der leistung eines datenverarbeitungssystems
DE112021002820T5 (de) Dynamische automatisierung einer auswahl von pipeline-artefakten
DE112021005586T5 (de) Automatisches skalieren einer abfrage-steuerungsroutine für arbeitslasten im bereich big data auf unternehmensebene
DE112021005636T5 (de) Migrieren von komplexen legacy-anwendungen
DE112020003744T5 (de) Durch dienstqualitätskriterien vorgegebenes automatisiertes betriebsdatenmanagement
DE102021127324A1 (de) Planung von aufträgen auf grafischen verarbeitungseinheiten
DE112022002615T5 (de) Kontinuierliche funktionsfähigkeit und integrität von anwendungen während eines migrationsvorgangs
DE112018004415B4 (de) Optimierung von cloud-ressourcen bei operationen in mehrstufigem speicher auf richtliniengrundlage
DE112021005927T5 (de) Patchen von arbeitsabläufen
DE102021122508A1 (de) Ausgleichen von grossrechner- und verteilten arbeitslasten auf der grundlage von leistung und kosten
DE112021003499T5 (de) Skalierbare operatoren für eine automatische verwaltung von arbeitslasten in hybriden cloud-umgebungen
DE112019002052T5 (de) Datenschutzsensibilisierung bei der bereitstellung von arbeitslasten
DE102021127323A1 (de) Verwaltung der Bereitstellung von Workloads
DE112021004577T5 (de) Verwalten eines aufgabenablaufs in einer edge-datenverarbeitungsumgebung
DE112020005326T5 (de) Erzeugen eines skalierungsplans für externe systeme während eines cloud-tenant-onboardings/offboardings
DE102021129637A1 (de) Verteiltes stream-computing mit mehreren umgebungen
DE102022108636A1 (de) Lebenszyklusmanagement für workloads in heterogenen infrastrukturen

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R081 Change of applicant/patentee

Owner name: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP, SPR, US

Free format text: FORMER OWNER: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP, HOUSTON, TX, US

R016 Response to examination communication