DE102020113347A1

DE102020113347A1 - Ausführung von containerisierten prozessen innerhalb der beschränkungen der verfügbaren host-knoten

Info

Publication number: DE102020113347A1
Application number: DE102020113347.2A
Authority: DE
Inventors: Joel Baxter; Thomas A. Phelan
Original assignee: Hewlett Packard Enterprise Development LP
Current assignee: Hewlett Packard Enterprise Development LP
Priority date: 2019-07-09
Filing date: 2020-05-18
Publication date: 2021-01-14
Also published as: CN112214307A; US20210011775A1

Abstract

Die hier vorgestellte Technologie ermöglicht eine optimierte Verwaltung der Cluster-Bereitstellung auf einer Vielzahl von Host-Knoten. In einer bestimmten Ausführungsform umfasst ein Verfahren die Definition von Parametern eines Clusters zur Ausführung eines Prozesses, der in einer Vielzahl von Containern ausgeführt wird, die über einen oder mehrere der Vielzahl von Host-Knoten verteilt sind. Das Verfahren sieht ferner das Hinzufügen eines ersten Containerteils der Vielzahl von Containern zu einem ersten Host-Knotenteil der Vielzahl von Host-Knoten vor. Nach dem Hinzufügen des ersten Containerabschnitts umfasst das Verfahren die Bestimmung, dass ein verbleibender Hostknotenabschnitt der Vielzahl von Hostknoten nicht mehr der Vielzahl von Containern unterstützt, und die Anpassung der Parameter des Clusters, damit der Prozess auf dem ersten Hostknotenabschnitt ausgeführt werden kann.

Description

TECHNISCHER HINTERGRUND
Container-Orchestrierungsplattformen, wie z.B. effektiv ausgeführt, bis weitere Host-Knoten verfügbar werden.
ZUSAMMENFASSUNG
Die hier vorgestellte Technologie ermöglicht ein optimiertes Management der Cluster-Bereitstellung auf einer Vielzahl von Host-Knoten. In einer bestimmten Ausführungsform umfasst ein Verfahren die Definition von Parametern eines Clusters zur Ausführung eines Prozesses, der in einer Vielzahl von Containern ausgeführt wird, die über einen oder mehrere der Vielzahl von Host-Knoten verteilt sind. Das Verfahren sieht ferner das Hinzufügen eines ersten Containerteils der Vielzahl von Containern zu einem ersten Host-Knotenteil der Vielzahl von Host-Knoten vor Nach dem Hinzufügen des ersten Containerabschnitts umfasst das Verfahren die Bestimmung, dass ein verbleibender Hostknotenabschnitt der Vielzahl von Hostknoten nicht mehr der Vielzahl von Containern unterstützt, und die Anpassung der Parameter des Clusters, damit der Prozess auf dem ersten Hostknotenabschnitt ausgeführt werden kann.
In einigen Ausführungsformen umfasst das Verfahren nach der Anpassung der Parameter des Clusters die Bestimmung, dass der verbleibende Host-Knotenteil einen oder mehrere zusätzliche Container aus der Vielzahl von Containern unterstützt, das Hinzufügen des einen oder der mehreren zusätzlichen Container zum verbleibenden Host-Knotenteil und die Anpassung der Parameter des Clusters, damit der Prozess mit dem einen oder den mehreren zusätzlichen Containern ausgeführt werden kann. In diesen Ausführungsformen kann das Verfahren die Anpassung eines oder mehrerer anderer Prozesse auf der Mehrzahl von Host-Knotenumfassen, um Ressourcen auf dem verbleibenden Host-Knotenteil zur Unterstützung des einen oder der mehreren zusätzlichen Container verfügbar zu machen.
In einigen Ausführungsformen umfasst die Anpassung der Parameter die Neudefinition einer Größe des Clusters, die dem ersten Teil des Host-Knotens entspricht. In diesen Ausführungsformen kann die Anpassung der Parameter auch die Neukonfiguration von Containertypen des ersten Containerabschnitts umfassen, um den Prozess auf dem ersten Hostknotenabschnitt durchzuführen.
In einigen Ausführungsformen werden Container im ersten Containerabschnitt in eine oder mehrere Pods gruppiert, und das Hinzufügen des ersten Containerabschnitts umfasst das Hinzufügen von mindestens einer der einen oder mehreren Pods zu jedem Host-Knoten des ersten Host-Knotenabschnitts. In diesen Ausführungsformen kann die Anpassung der Parameter des Clusters die Anpassung der Parameter von mindestens einem Teil der einen oder mehreren Pods umfassen.
In einigen Ausführungsformen umfasst das Definieren der Parameter des Clusters das Definieren einer Größe des Clusters auf der Grundlage einer Anzahl von Host-Knoten, wobei der erste Host-Knotenteil weniger Host-Knoten als die Anzahl der Host-Knotenumfasst.
In einigen Ausführungsformen enthält ein Host-Knoten des ersten Host-Knotenteils einen Management-Container für den Cluster.
In einigen Ausführungsformen umfasst die Mehrzahl von Host-Knoten eine Mehrzahl von virtuellen Maschinen, die auf einer Mehrzahl von Host-Computersystemen ausgeführt werden.
In einer anderen Ausführungsform ist ein Gerät vorgesehen, das ein oder mehrere computerlesbare Speichermedien und ein Verarbeitungssystemumfasst, das mit dem einen oder den mehreren computerlesbaren Speichermedien operativ gekoppelt ist. Auf dem einen oder den mehreren computerlesbaren Speichermedien gespeicherte Programmbefehle, die, wenn sie vom Verarbeitungssystem gelesen und ausgeführt werden, das Verarbeitungssystem anweisen, Parameter eines Clusters zur Ausführung eines Prozesses zu definieren, der in einer Vielzahl von Containern ausgeführt wird, die über einen oder mehrere der Vielzahl von Host-Knoten verteilt sind. Die Programmanweisungen weisen das Verarbeitungssystem ferner an, einen ersten Containerteil der Vielzahl von Containern zu einem ersten Hostknotenteil der Vielzahl von Hostknoten hinzuzufügen. Nachdem der erste Containerteil hinzugefügt wurde, weisen die Programmanweisungen das Verarbeitungssystem an, zu bestimmen, dass ein verbleibender Hostknotenteil der Vielzahl von Hostknoten nicht mehr der Vielzahl von Containern unterstützt, und die Parameter des Clusters so anzupassen, dass der Prozess auf dem ersten Hostknotenteil ausgeführt werden kann.
Figurenliste

veranschaulicht eine Implementierung zur Ausführung containerisierter Prozesse innerhalb der Beschränkungen der verfügbaren Host-Knoten.
veranschaulicht ein Betriebsszenario für die Ausführung containerisierter Prozesse innerhalb der Beschränkungen der verfügbaren Host-Knoten.
veranschaulicht ein weiteres Betriebsszenario für die Ausführung containerisierter Prozesse innerhalb der Einschränkungen der verfügbaren Host-Knoten.
veranschaulicht ein weiteres Betriebsszenario für die Ausführung containerisierter Prozesse innerhalb der Einschränkungen der verfügbaren Host-Knoten.
veranschaulicht eine Hostsystem-Architektur zur Ausführung containerisierter Prozesse innerhalb der Beschränkungen der verfügbaren Host-Knoten.

DETAILLIERTE BESCHREIBUNG
Die Ausführung eines Prozesses, wie z. B. einer Anwendung, in Containern über mehrere Host-Knoten hinweg ermöglicht eine Flexibilität, die sonst für einen Rechenprozess nicht gegeben wäre. Beispielsweise kann der Prozess skaliert werden, je nachdem, wie viele Verarbeitungsressourcen für den Prozess erforderlich/gewünscht sind. Wenn mehr Ressourcen benötigt werden, können zusätzliche Container für den Prozess auf zusätzlichen Host-Knoten eingerichtet werden, um die Ressourcen bereitzustellen. Wenn ein Prozess weitere Container für den Prozess zu zusätzlichen Host-Knoten hinzufügen muss, müssen diese Host-Knoten verfügbar sein, um die zusätzlichen Container anzunehmen und auszuführen. Wenn keine oder nicht genügend Hostknoten verfügbar sind, um alle zusätzlichen Container aufzunehmen, ermöglichen es die hier aufgeführten Beispiele für die Cluster-Steuerung dem Prozess, die Ausführung auf den für den Prozess verfügbaren Hostknoten so effizient wie möglich fortzusetzen.
veranschaulicht die Implementierung 100 für die Ausführung containerisierter Prozesse innerhalb der Beschränkungen der verfügbaren Host-Knoten. Implementierung 100 umfasst Host-Knoten 101, Host-Knoten 102, Host-Knoten 103, Host-Knoten 104 und Cluster-Controller 131. Der Cluster-Controller 131 und jeder von Host-Knoten 101, Host-Knoten 102, Host-Knoten 103, Host-Knoten 104 und Host-Knoten 104 kommunizieren über eine oder mehrere physikalische und/oder logische Kommunikationsverbindungen. Die Kommunikationsverbindungen können direkte Verbindungen sein oder dazwischenliegende Netzwerke, Systeme und/oder Geräte umfassen. Ebenso können, wenn auch nicht dargestellt, Host-Knoten 101, Host-Knoten 102, Host-Knoten 103 und Host-Knoten 104 Kommunikationsverbindungen zum Austausch von Kommunikationen zwischen und/oder mit anderen Systemen enthalten, die nicht als Teil der Implementierung 100 dargestellt sind.
In diesem Beispiel verwaltet der Cluster-Controller 131 die Ausführung des Prozesses 141 auf einem Cluster von Host-Knoten. In einigen Beispielen kann der Cluster-Controller 131 auf einem Host-Knoten ausgeführt werden, anstatt als eigenständiges Computersystem implementiert zu werden. Der Hostknoten für Cluster-Controller 131 kann als Teil von Cluster 151 betrachtet werden. Der Prozess 141 wird in einer oder mehreren Instanzen eines einzelnen Containers 120 ausgeführt, wobei jede Instanz von Container 120 auf einem entsprechenden Host-Knoten ausgeführt wird. Cluster 151 umfasst daher die Instanzen von Container 120 und, optional, Cluster-Controller 131. In anderen Beispielen kann ein Prozess in einer komplexeren Weise mit Instanzen von mehr als einem Container ausgeführt werden, wobei jeder Host-Knoten mehr als einen Container darauf ausführen kann. Beispielsweise kann ein Prozess eine mehrschichtige Anwendung umfassen, wobei jede Schicht der Anwendung einen oder mehrere Container umfasst. Jeder von Host-Knoten 101, Host-Knoten 102, Host-Knoten 103 und Host-Knoten 104 kann ein physisches Computersystem (z.B. einen Server) oder eine virtuelle Maschine umfassen, die auf einem physischen Computersystem ausgeführt wird - einschließlich Kombinationen davon.
Der Cluster-Controller 131 bestimmt, wie viele Host-Knoten für Instanzen des Containers 120 erforderlich sind, damit der Prozess 141 wie in den Parametern für Cluster 151 konfiguriert ausgeführt werden kann, und steuert die Host-Knoten zur Ausführung dieser Instanzen. Der Cluster-Controller 131 führt den Vorgang 200 aus, um Instanzen des Containers 120 auf dem Hostknoten 101, dem Hostknoten 102, dem Hostknoten 103 und dem Hostknoten 104 zu instanziieren und die Konfiguration von Cluster 151 so anzupassen , dass er innerhalb der bestehenden Beschränkungen arbeitet.
veranschaulicht Operation 200 für die Ausführung containerisierter Prozesse innerhalb der Beschränkungen der verfügbaren Host-Knoten. Operation 200 umfasst den Cluster-Controller 131, der die Parameter des Clusters 151 für die Ausführung des Prozesses 141 definiert, der in einem oder mehreren Containern 120 ausgeführt wird, die über einen oder mehrere Host-Knoten verteilt sind, wie z. B. Host-Knoten 101, Host-Knoten 102, Host-Knoten 103 und Host-Knoten 104 (201). Der Cluster-Controller 131 kann die Parameter des Clusters 151 definieren, indem er die Parameter des Clusters 151 von einem Benutzer empfängt, indem er die Parameter von einem anderen System zusammen mit oder in Anweisungen zur Ausführung des Prozesses 141 (z.B. Empfang der Parameter von einer Benutzer-Workstation) empfängt, indem er einen vorbestimmten Standardsatz von Parametern verwendet (z.B. Parameter, die in den Cluster-Controller 131 für dadurch gesteuerte Prozesse programmiert sind, die sich je nach dem speziellen Prozess oder Prozesstyp unterscheiden können) oder indem er auf andere Weise definiert wird. Die Parameter können eine Anzahl von Containern 120 definieren, die den Prozess 141 ausführen, die Anzahl der Container kann ein Maximum, ein Minimum, ein Bereich oder eine genaue Anzahl sein (d.h. nicht mehr, nicht weniger), sie können eine Anzahl von Host-Knoten definieren, auf denen der Prozess 141 ausgeführt wird, die Anzahl der Host-Knoten kann auch eine minimale, maximale oder genaue Anzahl sein, sie können eine Menge von Host-Knoten-Ressourcen definieren, die für den Prozess 141 verwendet werden (z.B., CPU-Zeit, Menge des verwendeten Speichers, Netzwerkbandbreite usw.), die Menge der Host-Knotenressourcen kann auf einer Pro-Container-Basis, auf der Basis einer Gruppe von Containern (z.B. die unten besprochenen Pods) definiert werden, oder sie kann für den Prozess 141 als Ganzes definiert werden und kann ein Minimum, ein Maximum, eine Reichweite oder eine genaue Menge von Ressourcen sein, oder sie kann die Größe des Clusters 151 auf andere Weise definieren - einschließlich Kombinationen davon.
In einem Beispiel kann der Prozess 141 so konfiguriert werden, dass er in so vielen Containern ausgeführt wird, wie notwendig sind, um die aktuelle Anforderung an den Prozess 141 zu bewältigen (d.h. die Parameter geben an, dass eine unbegrenzte Anzahl von Containern und/oder Host-Knoten verwendet werden soll). In anderen Fällen kann es eine definierte Obergrenze für die Anzahl der Host-Knoten geben, die dem Prozess 141 zur Verfügung stehen, da die Rechenressourcen nicht unendlich sind. In anderen Fällen kann der Prozess 141 auf der Grundlage einer gewünschten Anzahl von Host-Knoten und/oder Containern definiert werden, die für den Prozess 141 verwendet werden sollen. Beispielsweise kann ein Benutzer Ziele für einen bestimmten Verarbeitungsauftrag festlegen, für den Prozess 141 verwendet werden soll. Diese Ziele können darin bestehen, dass der Verarbeitungsauftrag in einer bestimmten Zeitspanne oder zu einem bestimmten Preis ausgeführt werden soll (da mit der Nutzung von Rechenressourcen häufig monetäre Kosten verbunden sind). Die gewünschte Anzahl von Containern und/oder Host-Knoten, die von Prozess 141 verwendet werden sollen, würde daher vom Benutzer so festgelegt werden, dass sie diesen Zielen entspricht. In einigen Fällen kann der Benutzer möglicherweise Cluster-Controller 131 die Ziele als Konfigurationsparameter zur Verfügung stellen, und Cluster-Controller 131 wandelt diese Ziele in Größenparameter für Cluster 151 um, um diese Ziele zu erreichen.
Der Cluster-Controller 131 fügt einen ersten Teil der Container 120 zu einem ersten Teil der Host-Knoten (202) hinzu. In diesem Beispiel umfasst der erste Teil der Host-Knoten Host-Knoten 101, Host-Knoten 102, Host-Knoten 103 und Host-Knoten 104, die jeweils eine einzelne Instanz von Container 120 hosten. In anderen Beispielen kann jeder Host-Knoten unter Umständen mehr als eine Instanz von Container 120 handhaben. Ebenso kann jeder Host-Knoten, auch wenn er nicht dargestellt wird, zusätzlich zu Container 120 Container oder andere Arten von Prozessen ausführen, die nicht als Teil von Cluster 151 für Prozess 141 betrachtet werden. Um eine Instanz von Container 120 hinzuzufügen, kann der Cluster-Controller 131 Software, die Container 120 repräsentiert, an jeden Host-Knoten übertragen. Die Software kann direkt auf dem Cluster-Controller 131 oder an einem anderen Ort gespeichert werden, z.B. in einem Network Attached Storage-Repository. Im letzteren Beispiel kann der Cluster-Controller 131 anweisen, dass die Software für Container 120 direkt vom Speichersystem auf den jeweiligen Host-Knoten übertragen wird. Die Instanzen von Container 120 können den jeweiligen Host-Systemen im Wesentlichen gleichzeitig oder sequentiell hinzugefügt werden. In einigen Fällen kann der Cluster-Controller 131 Instanzen des Containers 120 auf der Grundlage der Anforderung des Prozesses 141 hinzufügen. Beispielsweise kann der Cluster-Controller 131 damit beginnen, Container 120 zum Host-Knoten 101 hinzuzufügen, die Nachfrage nach Prozess 141 zu überwachen und dann eine Instanz von Container 120 zum Host-Knoten 102 hinzuzufügen , um diese Nachfrage zu befriedigen. Wenn die Nachfrage weiter steigt, fügt Cluster-Controller 131 eine Instanz von Container 120 zum Host-Knoten 103 und dann eine weitere Instanz von Container 120 zum Host-Knoten 104 hinzu.
In diesem Beispiel ermöglichen die für Cluster 151 ermittelten Betriebsparameter, dass der Prozess 141 über die vier Container 120 auf den vier jeweiligen Host-Knoten 101-104 hinaus expandieren kann. Nachdem der erste Teil der Container 120 hinzugefügt wurde, bestimmt der Cluster-Controller 131 also, dass ein verbleibender Teil der Host-Knoten nicht mehr der Container 120 (203) unterstützen wird. Beispielsweise kann der Cluster-Controller 131 feststellen, dass die Betriebsparameter für Cluster 151 es dem Cluster 151 erlauben, mindestens bis zu einem anderen Host-Knoten 105 zu expandieren. Der Host-Knoten 105 ist jedoch entweder physisch nicht vorhanden (z. B. gibt es keinen anderen Host-Knoten, auf den Cluster-Controller 131 zugreifen kann) oder die verfügbaren Ressourcen des Host-Knotens 105 reichen nicht aus, um eine Instanz von Container 120 zu unterstützen. Cluster-Controller 131 kann den Status von Host-Knoten in Verbindung mit Cluster-Controller 131 verfolgen (z.B. kann er Informationen von jedem Host-Knoten erhalten, die Cluster-Controller 131 über den Status des Host-Knotens informieren, wie z.B. den Zustand der Ressourcen des Host-Knotens) oder er kann sich auf ein anderes System verlassen, das die Statusinformationen des Host-Knotens erhält und verwaltet. Unabhängig vom Grund für die Nichtverfügbarkeit des Hostknotens 105 (und aller zusätzlichen Hostknoten über den Hostknoten 105 hinaus) kann Cluster-Controller 131 den Cluster 151 nicht über den Hostknoten 101, Hostknoten 102, Hostknoten 103 und Hostknoten 104 hinaus erweitern , wenn er feststellt, dass der Hostknoten 105 nicht verfügbar ist.
Nachdem festgestellt wurde, dass Host-Knoten 105 nicht verfügbar ist, passt der Cluster-Controller 131 die Parameter von Cluster 151 so an, dass Prozess 141 auf Host-Knoten 101, Host-Knoten 102, Host-Knoten 103 und Host-Knoten 104 (204) ausgeführt werden kann. In einigen Fällen läuft Prozess 141 möglicherweise überhaupt nicht, bis Cluster 151 über Hostknoten 101, Hostknoten 102, Hostknoten 103 und Hostknoten 104 hinaus erweitert werden kann. Daher passt Cluster Controller 131 die Betriebsparameter von Prozess 141 an, um die Größe von Cluster 151 auf die Instanzen von Container 120, die auf Hostknoten 101, Hostknoten 102, Hostknoten 103 und Hostknoten 104 betrieben werden, neu zu definieren. Nach einer solchen Anpassung wird Prozess 141 zumindest ausgeführt, obwohl Prozess 141 auf einem kleineren Cluster als ursprünglich gewünscht läuft. In einigen Beispielen können die Betriebsparameter so angepasst werden, dass Prozess 141 effektiver auf der aktuellen Größe von Cluster 151 ausgeführt wird, selbst wenn Prozess 141 auf einer kleineren Clustergröße ausgeführt wird. Beispielsweise können die Betriebsparameter ursprünglich eine geringere Menge an Hostknoten-Verarbeitungs-/Speicherressourcen für die Verwendung durch jede Instanz von Container 120 definieren, was durch das Hinzufügen weiterer Instanzen von Container 120 berücksichtigt würde. Da jedoch der Host-Knoten 105 in diesem Beispiel nicht verfügbar ist, können die Betriebsparameter so angepasst werden, dass jede Instanz von Container 120 mehr der Ressourcen der jeweiligen Host-Knoten nutzen kann (falls diese Ressourcen verfügbar sind).
Während der Prozess 141 mit nur einem Container implementiert wird, können andere Prozesse mit mehreren Containertypen implementiert werden. So kann z.B. ein Container eines Typs einen Aspekt von Prozess 141 ausführen , während ein anderer Container eines anderen Typs einen anderen Aspekt von Prozess 141 ausführen kann (z.B. sind in den folgenden Beispielen Container verschiedener Typen in Pods organisiert, um verschiedene Ebenen der Anwendung 301 auszuführen). In solchen Beispielen kann der Cluster-Controller 131 feststellen, dass eine andere Anordnung von Containertypen einen Prozess mit mehreren Containertypen effektiver implementieren würde. Cluster-Controller 131 kann daher eine oder mehrere Instanzen eines Containertyps auf dem verfügbaren Teil der Host-Knoten entfernen und diese Instanzen durch eine oder mehrere Instanzen eines anderen Containertyps ersetzen, um die verfügbaren Ressourcen der Host-Knoten effektiver zu nutzen.
Der Cluster-Controller 131 kann weiterhin die Verfügbarkeit weiterer Host-Knoten überwachen, und falls weitere Host-Knoten verfügbar werden, kann der Cluster-Controller 131 die Betriebsparameter des Prozesses 141 erneut neu definieren, um die Größe des Clusters 151 zu erhöhen. Beispielsweise kann Hostknoten 105 verfügbar werden und die Betriebsparameter von Prozess 141 können dann angepasst werden, um die Größe von Cluster 151 auf fünf Hostknoten zu erhöhen. Der Cluster-Controller 131 würde dann eine Instanz von Container 120 zum Host-Knoten 105 in Übereinstimmung mit diesen neu angepassten Betriebsparametern hinzufügen. Cluster-Controller 131 kann dann weiterhin die Betriebsparameter von Prozess 141 neu definieren, wenn mehr Host-Knoten-Ressourcen verfügbar werden (zumindest bis die ursprünglich definierte Größe für Cluster 151 erreicht ist). Somit ist Cluster-Controller 131 in der Lage, kontinuierlich sicherzustellen, dass Prozess 141 am effektivsten arbeitet, auch wenn die Größe von Cluster 151 geringer ist als die ursprünglich von den Betriebsparametern für Prozess 141 vorgegebene Größe.
veranschaulicht das Betriebsszenario 300 für die Ausführung containerisierter Prozesse innerhalb der Beschränkungen der verfügbaren Host-Knoten. Das Betriebsszenario 300 umfasst Anwendung 301, die ein Beispiel für Prozess 141 aus den obigen Beispielen ist, Clusterparameter 302, die ein Beispiel für die Betriebsparameter für Prozess 141 auf Cluster 151 sind, und Hostknoten 401-409, die die Hostknoten sind, auf denen Anwendung 301 potenziell ausgeführt werden kann. In diesem Beispiel sind die Container, die eine Instanz von Anwendung 301 bilden, in Pod 311, Pod 312 und Pod 313 angeordnet. Pods werden von einigen Container-Orchestrierungsplattformen verwendet, um Container zu gruppieren, die auf denselben Host-Knoten ausgeführt werden müssen. So enthalten pod 311, pod 312 und pod 313 jeweils einen oder mehrere Container, die auf demselben Host-Knoten ausgeführt werden müssen. Anwendung 301 ist auch in diesem Beispiel eine mehrschichtige Anwendung. Jeder der Pods 311-313 implementiert eine entsprechende Schicht der Anwendung 301, d.h. Anwendung 301 ist eine dreischichtige Anwendung. Andere Beispiele für mehrschichtige Anwendungen können eine unterschiedliche Anzahl von Schichten enthalten. Ebenso können andere Beispiele eine oder mehrere der Schichten in mehreren Hülsen implementieren oder eine einzelne Hülse kann zumindest einen Teil von mehr als einer Schicht implementieren.
In diesem Beispiel gibt der Cluster-Parameter 302 an, dass Anwendung 301 auf sieben Host-Knoten ausgeführt werden soll, und gibt eine Menge an Ressourcen jedes Host-Knotens an, die für jede der Pods 311-313 verwendet werden soll. Die Menge der Ressourcen ist als Prozentsatz definiert, was voraussetzt, dass jeder Host-Knoten eine identische Menge an Ressourcen zuzuweisen hat, und wird auf der Grundlage der Ressourcen als Ganzes und nicht auf der Grundlage verschiedener Kategorien von Ressourcen (z. B. Verarbeitungsressourcen, Speicherressourcen usw.) definiert. Andere Beispiele können daher die Ressourcen, die jedem Pod zugewiesen werden sollen, genauer definieren, als die Cluster-Parameter 302 in diesem Beispiel definiert. Auf der Grundlage der durch Cluster-Parameter 302 definierten prozentualen Anteile der Ressourcen kann Pod 311 einen Host-Knoten mit Pod 312, aber nicht mit Pod 313 teilen, da eine gemeinsame Nutzung mit Pod 313 die Menge der auf dem Host-Knoten verwendeten Ressourcen auf über 100 % bringen würde. Ebenso kann sich Pod 313 einen Host-Knoten mit einer oder zwei Instanzen von Pod 312 teilen oder einen Host-Knoten mit einer anderen Instanz von Pod 313 (d.h. Pod 313 für eine andere Instanz von Anwendung 301) teilen. Pod 312 kann einen Host-Knoten auch mit bis zu 3 anderen Instanzen von pod 312 gemeinsam nutzen (d.h. Instanzen von pod 312 für andere Instanzen von Anwendung 301). Wenn in diesem Beispiel die Ressourcen eines der Host-Knoten 401-409 nicht von einer Instanz von pod 311, pod 312 und pod 313 verwendet werden, können diese Ressourcen von anderen Prozessen verwendet werden (d.h. die Host-Knoten 401-409 werden nicht ausschließlich zur Implementierung von Instanzen der Anwendung 301 verwendet.
veranschaulicht das Betriebsszenario 400 für die Ausführung containerisierter Prozesse innerhalb der Einschränkungen der verfügbaren Host-Knoten. Das Betriebsszenario 400 ist ein Beispiel für die Anwendung 301, die auf den Hostknoten 401-409 in Übereinstimmung mit den Clusterparametern 302 implementiert wird. Obwohl nicht dargestellt, können die Host-Knoten 401-409 über ein oder mehrere Kommunikationsnetzwerke (z.B. lokale(s) Netzwerk(e)) kommunizieren. Die Host-Knoten 401-409 hosten die Anwendung 301 und eine andere Anwendung. In diesem Beispiel wird die Anwendung 301 vom Management-Container 411 auf dem Host-Knoten 401 verwaltet, der die Implementierung von pod 311, pod 312 und pod 313 verwaltet und einen der sieben Host-Knoten verwendet, die durch die Cluster-Parameter 302 angegeben werden. Andere Beispiele zählen möglicherweise nicht den Hostknoten, der vom Management-Container 411 auf den sieben Hostknoten verwendet wird. Der Management-Container 411 befindet sich in diesem Fall allein auf dem Host-Knoten 401, kann aber in anderen Beispielen einen Host-Knoten mit einer oder mehreren Pods teilen. Der Management-Container 411 ist eine Beispielimplementierung für den Cluster-Controller 131.
Im Betriebsszenario 400 wird die Anwendung 301 durch den Management-Container 411 als eine oder mehrere Gruppen von einem Pod 311, einem Pod 312 und einem Pod 313 implementiert. Beim Erweitern der Anwendung 301 im Cluster der Host-Knoten 401-409 werden also Ressourcen in den Host-Knoten 401-409 für jeweils eine Instanz von pod 311, pod 312 und pod 313 benötigt (d.h. die Möglichkeit, nur eine oder zwei der Pods hinzuzufügen, würde die Anwendung 301 nicht erweitern, was alle drei erfordert). In anderen Beispielen kann eine Anwendung möglicherweise auf der Basis einzelner Hülsen erweitert werden. Beispielsweise kann eine Anwendung möglicherweise nur eine bestimmte Ebene erweitern, indem sie eine oder mehrere Pods hinzufügt, die diese Ebene implementieren.
Auf der Grundlage der Cluster-Parameter 302 führt der Management-Container 411 die Operation 200 aus, um eine Instanz von Pod 311 und Pod 312 zum Host-Knoten 402 hinzuzufügen, eine Instanz von Pod 311 und Pod 312 zum Host-Knoten 403 und zwei Instanzen von Pod 313 zum Host-Knoten 404. Die Host-Knoten 402-404 umfassen daher zwei Gruppen von pod 311, pod 312 und pod 313 für die Anwendung 301. Beispielsweise können Pod 311 und Pod 312 auf dem Host-Knoten 402 mit einem Pod 313 auf dem Host-Knoten 404 und Pod 311 und Pod 312 auf dem Host-Knoten 403 mit dem anderen Pod 313 auf dem Host-Knoten 404 assoziiert werden. Management-Container 411 kann einen Algorithmus verwenden, der die Pods 311-313 auf Host-Knoten auf der Grundlage der für jeden Pod erforderlichen Ressourcen, wie in Cluster-Parameter 302 definiert, am besten anpasst. Der Algorithmus hat in diesem Beispiel beispielsweise ermittelt, dass Pod 311 und Pod 312 einen Host-Knoten gemeinsam nutzen können, um die Ressourcen des Host-Knotens zu 100 % zu nutzen, und hat eine ähnliche Ermittlung in Bezug auf die beiden Instanzen von Pod 313 auf Host-Knoten 404 vorgenommen.
Management-Container 411 versucht dann, auf zwei weitere Gruppen von Pod 311, Pod 312 und Pod 313 für die Anwendung 301 zu expandieren, was dazu führen würde, dass die Cluster-Parameter 302 mit vier Gruppen über sieben Host-Knoten, einschließlich Host-Knoten 401 für Management-Container 411, erfüllt werden. Sobald der Management-Container 411 Instanzen von Pod 311 und Pod 312 zu den jeweiligen Host-Knoten 405 und 406 hinzugefügt hat, stellt der Management-Container 411 fest, dass keine Host-Knoten-Ressourcen verfügbar sind, um den Cluster für Anwendung 301 in Übereinstimmung mit Operation 200 weiter auszubauen. In diesem Beispiel läuft eine andere Anwendung auf den Host-Knoten 407-409. Diese andere Anwendung hat ihren eigenen Management-Container 412 auf dem Host-Knoten 407 und jeder der Host-Knoten 408 hostet eine Instanz von Pod 421 und Pod 422. Bei der Ausführung von Pod 421 und Pod 422 verfügen weder Host-Knoten 408 noch Host-Knoten 409 über genügend verbleibende Ressourcen, um eine Instanz von Pod 313 zu unterstützen. Daher passt der Management-Container 411 in Übereinstimmung mit Operation 200 die Cluster-Parameter 302 an, um die Anwendung 301 auf den sechs verfügbaren Host-Knoten statt auf den ursprünglich definierten sieben besser zu implementieren. Sieben Host-Knoten hätten es einem weiteren Host-Knoten ermöglicht, zwei Instanzen von Pod 313 zu unterstützen und somit die Anzahl der für Anwendung 301 laufenden Pod-Gruppen von zwei auf vier zu verdoppeln.
In diesem Fall kann der Management-Container 411 einfach die Anzahl der für die Anwendung 301 verfügbaren Host-Knoten innerhalb der Cluster-Parameter 302 auf sechs reduzieren, was einen Algorithmus auslösen kann, der die Hülsen der Anwendung 301 am besten in sechs statt der zuvor definierten sieben Host-Knoten einfügt. Beispielsweise kann der Management-Container 411 den Pod 311 vom Host-Knoten 406 entfernen und an seiner Stelle eine Instanz des Pod 313 hinzufügen, da durch das Entfernen des Pod 311 75% der Ressourcen des Host-Knotens 406 frei werden. Diese neu hinzugefügte Instanz von Pod 311 erzeugt, wenn sie mit Pod 311 und Pod 312 auf dem Host-Knoten 405 assoziiert wird, eine dritte Gruppe von Pods für Anwendung 301. Während drei Gruppen von Pods für Anwendung 301 weniger als die gewünschten vier sind, was mit den ursprünglich festgelegten sieben Host-Knoten möglich war, sind die drei Gruppen besser als die beiden Gruppen, die vorher liefen. In einigen Fällen kann der Management-Container 411 auch die verbleibenden Ressourcen auf dem Host-Knoten 406 reservieren (was 25 % der Ressourcen ausmacht, wenn Pod 312 auf dem Host-Knoten 406 verbleiben darf, obwohl er ungenutzt bleibt), so dass diese Ressourcen verwendet werden können, sobald ein siebter Host-Knoten verfügbar wird.
In einem anderen Beispiel kann die Anwendung 301 gegenüber der vom Management-Container 412 verwalteten Anwendung priorisiert werden. In diesem Fall kann der Management-Container 411 dem Management-Container 412 mitteilen, dass ein anderer Host-Knoten für Anwendung 301 erforderlich ist. Der Management-Container 412 kann dann Pod 421 und Pod 422 entweder vom Host-Knoten 408 oder vom Host-Knoten 409 entfernen . Sobald Host-Knoten 408 oder Host-Knoten 409 verfügbar wird, erweitert der Management-Container 411 den Cluster der Anwendung 301 auf diesen Host-Knoten. In einigen dieser Fälle kann der Management-Container 411 die Anzahl der Host-Knoten für die Anwendung 301 immer noch auf sechs reduzieren, während der Management-Container 411 darauf wartet, dass der Management-Container 412 den Host-Knoten 408 oder den Host-Knoten 409 verfügbar macht. Sobald Host-Knoten 408 oder Host-Knoten 409 verfügbar ist, würde der Management-Container 411 einfach die Anzahl der Host-Knoten auf sieben aktualisieren und auf den siebten Knoten erweitern.
In einem weiteren Beispiel kann der Management-Container 411 den Ressourcenbedarf zumindest eines Teils der Hülsen ändern, um mehr Hülsengruppen für die Anwendung 301 zu implementieren. Wie bereits erwähnt, hätten zum Beispiel, wenn alle sieben Host-Knoten verfügbar wären, vier Pod-Gruppen durch Management-Container 411 implementiert werden können. Management-Container 411 kann die für Pod 311, Pod 312 und Pod 313 (oder die einzelnen Container darin) erforderlichen Ressourcen so ändern, dass alle drei Pods auf jedem Host-Knoten 405 und Host-Knoten 406 laufen können, während die Ressourcenanforderungen für die Instanzen von Pod 311, Pod 312 und Pod 313 weiterhin so bleiben, wie sie ursprünglich durch die Cluster-Parameter 302 definiert wurden. Die Ressourcenanpassungen würden es daher ermöglichen, vier Gruppen von Pods für Anwendung 301 auf den sechs verfügbaren Host-Knoten laufen zu lassen, obwohl zwei dieser Pod-Gruppen mit potenziell reduzierter Kapazität laufen würden.
Es sollte verstanden werden, dass Strategien zur Optimierung der Verteilung von Pods auf weniger als eine gewünschte Anzahl von Host-Knoten, die nicht den oben beschriebenen entsprechen, auch bei der Anpassung der Clusterparameter 302 angewendet werden können.
Während in den obigen Beispielen der Management-Container 411 alle Schritte von Vorgang 200 ausführt, kann es in anderen Beispielen möglicherweise nicht möglich sein, den Management-Container 411 so zu modifizieren, dass er Vorgang 200 ausführt. In diesen Beispielen kann ein anderer Container, der auf dem Host-Knoten 401, auf einem anderen Host-Knoten (falls verfügbar) oder einem anderen System, das mit dem Management-Container 411 kommuniziert, die Operation 200 als Proxy für den Management-Container 411 ausführen. Der Proxy kann z. B. die anfänglichen Cluster-Parameter 302 empfangen und die Cluster-Parameter 302 an den Management-Container 411 übergeben. Wenn der Proxy entweder durch den Management-Container 411 oder eine andere Quelle informiert wird, dass der Cluster für die Anwendung 301 nicht auf einen siebten Knoten erweitert werden konnte, kann der Proxy die Cluster-Parameter 302 anpassen, um einen Cluster mit sechs Knoten zu definieren, und die angepassten Cluster-Parameter 302 an den Management-Container 411 als Aktualisierung der vorherigen Version der Cluster-Parameter 302 übergeben. Der Management-Container 411 kann dann die Verteilung der Instanzen von Pod 311, Pod 312 und Pod 313 für die Anwendung 301 in ähnlicher Weise wie oben beschrieben anpassen. In anderen Beispielen kann der Proxy mehr als die Größe des Clusters anpassen (z.B. kann er den Ressourcenbedarf anpassen), wie in anderen Beispielen oben beschrieben. Der Proxy ermöglicht daher die Optimierung der Cluster-Nutzung, die Operation 200 bietet, ohne den Management-Container 411 modifizieren zu müssen.
veranschaulicht die Rechnerarchitektur 500 für die Ausführung containerisierter Prozesse innerhalb der Beschränkungen der verfügbaren Host-Knoten. Die Rechenarchitektur 500 wird als Beispiel für den Host-Knoten 402 gezeigt, kann aber auch ein Beispiel für jeden der Host-Knoten 401-409 mit verschiedenen darauf laufenden Pods oder Containern oder für die Host-Knoten 101-104 mit dem darauf laufenden Container 120 sein, obwohl jedes dieser Elemente unterschiedliche Architekturen verwenden kann. Wie oben erwähnt, kann ein Host-Knoten ein physisches Computersystem oder ein virtualisiertes Computersystem sein, das auf einem physischen Computersystem ausgeführt wird. Die Rechnerarchitektur 500 ist ein Beispiel für ein physisches Computersystem, obwohl die Rechnerarchitektur 500 auf einem zugrunde liegenden physischen Computersystem virtualisiert werden könnte.
In diesem Beispiel führt das Host-Computersystem 402 den Hypervisor 541 aus, um die physischen Computing-Ressourcen 551 auf Pod 311 und Pod 312aufzuteilen. Zu den physischen Rechenressourcen 551 können Verarbeitungsressourcen (z. B. CPU-Zeit/Kerne), Speicherplatz (z. B. Platz im Arbeitsspeicher des Host-Knotens 402), Netzwerkschnittstellen (z. B. Ethernet, WiFi usw.), Benutzerschnittstellen oder jede andere Art von Ressourcen gehören, die ein physisches Rechensystem enthalten kann. In diesem Beispiel umfasst Pod 311 Container 521, Container 522 und Container 523, während Pod 312 Container 524 umfasst. Da Instanzen von Containern innerhalb eines Pods auf demselben Host-Knoten laufen müssen, laufen Container 521, Container 522 und Container 523 alle auf dem Host-Knoten 402. Auch wenn Pod 312 nur einen einzigen Container 524 enthält, ist Container 524 aus Gründen der Konsistenz mit den anderen Pods der Anwendung 301 in einem Pod organisiert. In anderen Beispielen kann der Container 524 unabhängig von einer Gondel behandelt werden. In ähnlicher Weise kann Pod 311 zwar als Pod 311 dargestellt werden, aber vom Management-Container 411 nur als Indikator dafür verwendet werden, dass Container 521, Container 522 und Container 523 auf demselben Host-Knoten laufen müssen. Wenn er auf dem Host-Knoten 402 ausgeführt wird, wird Host-Knoten 402 also möglicherweise nicht darüber informiert, dass die einzelnen Container Pod 311 bilden. Natürlich können verschiedene Container-Orchestrierungsplattformen die Host-Knoten anweisen, Pods/Container auf unterschiedliche Weise zu behandeln.
Die hierin enthaltenen Beschreibungen und Abbildungen stellen konkrete Umsetzungen der beanspruchten Erfindung(en) dar. Zum Zweck der Vermittlung erfinderischer Prinzipien wurden einige konventionelle Aspekte vereinfacht oder weggelassen. Darüber hinaus können einige Abweichungen von diesen Implementierungen geschätzt werden, die in den Anwendungsbereich der Erfindung fallen. Es kann auch geschätzt werden, dass die oben beschriebenen Merkmale auf verschiedene Weise kombiniert werden können, um mehrere Implementierungen zu bilden. Infolgedessen ist die Erfindung nicht auf die oben beschriebenen spezifischen Implementierungen beschränkt, sondern nur durch die Ansprüche und ihre Äquivalente.

Claims

Ein Verfahren zum Verwalten der Cluster-Entwicklung auf einer Vielzahl von Host-Knoten, wobei das Verfahren umfasst: Definition von Parametern eines Clusters zur Ausführung eines Prozesses, der in einer Vielzahl von Containern ausgeführt wird, die über einen oder mehrere der Vielzahl von Host-Knoten verteilt sind; Hinzufügen eines ersten Containerabschnitts aus der Vielzahl von Containern zu einem ersten Hostknotenabschnitt aus der Vielzahl von Hostknoten; nach dem Hinzufügen des ersten Containerabschnitts Bestimmung, dass ein verbleibender Host-Knotenabschnitt der Mehrzahl von Host-Knoten nicht mehr der Mehrzahl von Containern unterstützt; und Anpassung der Parameter des Clusters, damit der Prozess auf dem ersten Teil des Host-Knotens ausgeführt werden kann.
Verfahren nach Anspruch 1, weiter umfassend: nach Anpassung der Parameter des Clusters: Bestimmung, dass der verbleibende Host-Knotenteil einen oder mehrere zusätzliche Container aus der Vielzahl der Container unterstützt; Hinzufügen eines oder mehrerer zusätzlicher Container zum verbleibenden Host-Knotenteil; und Anpassung der Parameter des Clusters, damit der Prozess mit einem oder mehreren zusätzlichen Containern ausgeführt werden kann.
Verfahren nach Anspruch 1 oder 2, weiter umfassend: Anpassung eines oder mehrerer anderer Prozesse auf der Mehrzahl von Host-Knoten, um Ressourcen auf dem verbleibenden Host-Knotenteil zur Unterstützung des einen oder der mehreren zusätzlichen Container verfügbar zu machen.
Verfahren nach einem der Ansprüche 1 bis 3, wobei die Anpassung der Parameter umfasst: Neudefinition einer Größe des Clusters, die dem ersten Teil des Host-Knotens entspricht.
Verfahren nach jedem vorhergehenden Anspruch, bei der die Anpassung der Parameter weiter umfasst: Rekonfiguration von Containertypen des ersten Containerabschnitts, um den Prozess auf dem ersten Hostknotenabschnitt auszuführen.
Das Verfahren eines beliebigen vorhergehenden Anspruchs, wobei Behälter in dem ersten Behälterteil in eine oder mehrere Hülsen gruppiert werden und wobei das Hinzufügen des ersten Behälterteils umfasst: Hinzufügen von mindestens einer der einen oder mehreren Hülsen zu jedem Wirtsknoten des ersten Wirtsknotenabschnitts.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Anpassung der Parameter des Clusters umfasst: Einstellung der Parameter von mindestens einem Teil der einen oder mehreren Hülsen.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Definition der Parameter des Clusters umfasst: Definieren einer Größe des Clusters auf der Grundlage einer Anzahl von Host-Knoten, wobei der erste Host-Knotenteil weniger Host-Knoten als die Anzahl der Host-Knoten enthält.
Verfahren nach einem der vorhergehenden Ansprüche, wobei ein Host-Knoten des ersten Host-Knotenteils einen Verwaltungsknoten für den Cluster umfasst.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Vielzahl von Host-Knoten eine Vielzahl von virtuellen Maschinen umfasst, die auf einer Vielzahl von Host-Computersystemen ausgeführt werden.
Eine Vorrichtung zur Verwaltung der Cluster-Bereitstellung auf einer Vielzahl von Host-Knoten, wobei die Vorrichtung umfasst: ein oder mehrere computerlesbare Speichermedien; ein Verarbeitungssystem, das operativ mit dem einen oder mehreren computerlesbaren Speichermedien gekoppelt ist; und Programmbefehle, die auf einem oder mehreren computerlesbaren Speichermedien gespeichert sind und die, wenn sie vom Verarbeitungssystem gelesen und ausgeführt werden, das Verarbeitungssystem dorthin leiten: definieren Parameter eines Clusters für die Ausführung eines Prozesses, der in einer Vielzahl von Containern ausgeführt wird, die über einen oder mehrere der Vielzahl von Host-Knoten verteilt sind; einen ersten Containerabschnitt der Vielzahl von Containern zu einem ersten Host-Knotenabschnitt der Vielzahl von Host-Knoten hinzufügen; nachdem der erste Containerabschnitt hinzugefügt wurde,bestimmen, dass ein verbleibender Hostknotenabschnitt der Vielzahl von Hostknoten nicht mehr der Vielzahl von Containern unterstützt; und Passen Sie die Parameter des Clusters so an, dass der Prozess auf dem ersten Teil des Host-Knotens ausgeführt werden kann.
Vorrichtung nach Anspruch 11, auf den die Programmanweisungen das Verarbeitungssystem weiterleiten: nachdem angepasst wurden: bestimmen, dass der verbleibende Teil des Host-Knotens einen oder mehrere zusätzliche Container aus der Vielzahl der Container unterstützt; den einen oder mehrere zusätzliche Container zum verbleibenden Host-Knotenteil hinzufügen; und die Parameter des Clusters so anpassen, dass der Prozess mit einem oder mehreren zusätzlichen Containern ausgeführt werden kann.
Vorrichtung nach Anspruch 11 oder 12, auf den die Programmanweisungen das Verarbeitungssystem weiterleiten: einen oder mehrere andere Prozesse auf der Mehrzahl von Host-Knoten anpassen, um Ressourcen auf dem verbleibenden Host-Knotenteil zur Unterstützung des einen oder der mehreren zusätzlichen Container verfügbar zu machen.
Vorrichtung nach einem der Ansprüche 11 bis 13, bei dem zur Einstellung der Parameter die Programmanweisungen das Verarbeitungssystem anweisen: eine Größe des Clusters neu definieren, die dem ersten Teil des Host-Knotens entspricht.
Vorrichtung nach einem der Ansprüche 11 bis 14, wobei zur Einstellung der Parameter die Programmanweisungen das Verarbeitungssystem weiter anweisen: Containertypen des ersten Containerabschnitts rekonfigurieren, um den Prozess auf dem ersten Hostknotenabschnitt auszuführen.
Vorrichtung nach einem der Ansprüche 11 bis 15, wobei die Behälter im ersten Behälterteil in einer oder mehreren Hülsen gruppiert sind und wobei zum Hinzufügen des ersten Behälterteils die Programmbefehle das Verarbeitungssystem anweisen: mindestens eine der einen oder mehreren Hülsen zu jedem Wirtsknoten des ersten Wirtsknotenabschnittshinzufügen.
Vorrichtung nach Anspruch 16, auf den zur Einstellung der Parameter des Clusters die Programmanweisungen das Verarbeitungssystem lenken: die Parameter von mindestens einem Teil der einen oder mehreren Hülsen anpassen.
Vorrichtung nach einem der Ansprüche 11 bis 17, wobei die Definition der Parameter des Clusters umfasst: Definieren einer Größe des Clusters auf der Grundlage einer Anzahl von Host-Knoten, wobei der erste Host-Knotenteil weniger Host-Knoten als die Anzahl der Host-Knoten enthält.
Ein oder mehrere computerlesbare Speichermedien mit darauf gespeicherten Programmanweisungen zur Verwaltung der Cluster-Bereitstellung auf einer Vielzahl von Host-Knoten, auf die die Programmanweisungen, wenn sie von einem Verarbeitungssystem ausgeführt werden, das Verarbeitungssystem leiten: definieren Parameter eines Clusters für die Ausführung eines Prozesses, der in einer Vielzahl von Containern ausgeführt wird, die über einen oder mehrere der Vielzahl von Host-Knoten verteilt sind; einen ersten Containerabschnitt der Vielzahl von Containern zu einem ersten Host-Knotenabschnitt der Vielzahl von Host-Knoten hinzufügen; nachdem der erste Containerabschnitt hinzugefügt wurde, bestimmen, dass ein verbleibender Hostknotenabschnitt der Vielzahl von Hostknoten nicht mehr der Vielzahl von Containern unterstützt; und anpassen der Parameter des Clusters sodass der Prozess auf dem ersten Teil des Host-Knotens ausgeführt werden kann.
Das Speichermedium von Anspruch 19, auf das die Programmanweisungen das Verarbeitungssystem weiterleiten: nachdem die Parameter des Clusters angepasst wurden: bestimmen, dass der verbleibende Teil des Host-Knotens einen oder mehrere zusätzliche Container aus der Vielzahl der Container unterstützt; den einen oder mehrere zusätzliche Container zum verbleibenden Host-Knotenteil hinzufügen; und die Parameter des Clusters so anpassen, dass der Prozess mit einem oder mehreren zusätzlichen Containern ausgeführt werden kann.