-
Stand der Technik
-
Bei der Speicherung von Unternehmensdaten kann sich Clustering auf die physische Verbindung unabhängiger Rechenknoten (Server) und eine Steuerungsfunktion zur Steuerung der Verwaltung von Knoten des Clusters beziehen. Die Steuerungsfunktion kann Workloads auf jeden Knoten verteilen, die Übertragung von Workloads zwischen Knoten verwalten oder beides. Ein solches Clustering kann ein gemeinsam genutztes Speichersystem zusammen mit einem Mechanismus zum Duplizieren der Daten in dem Speichersystem umfassen, das direkt an jeden Knoten angeschlossen ist, der verwendet werden kann. Gängige Speicherclusteranwendungen bieten Failover-Funktionen für kritische Prozesse und ermöglichen den Lastenausgleich für Hochleistungsprozesse. Die Containerisierung von Vorgängen kann eine Virtualisierungsmethode auf Betriebssystemebene sein, mit der verteilte Vorgänge bereitgestellt und ausgeführt werden, ohne dass für jeden Vorgang eine gesamte virtuelle Maschine (VM) gestartet wird. Mehrere isolierte Vorgänge werden auf einem einzelnen Host ausgeführt und greifen auf denselben Betriebssystemkernel zu. Beispielsweise kann Container Linux (früher CoreOS Linux) eines der ersten Container-Betriebssysteme sein, die für Container entwickelt wurden. Software-Container sind eine Form der Betriebssystemvirtualisierung, bei der der ausgeführte Container minimale Betriebssystemressourcen, Arbeitsspeicher und Dienste zum Ausführen eines Vorgangs enthält. Systeme der eingangs genannten Art sind beispielsweise aus den Druckschriften
EP 2 742 401 B1 ,
US 2009/0 217 072 A1 ,
US 2013/0 297 668 A1 und
US 2008/0 201 414 A1 bekannt.
-
Figurenliste
-
- 1 ist ein schematisches Diagramm eines beispielhaften Behälterverwaltungssystems, das mit der vorliegenden Offenbarung übereinstimmt.
- 2 ist ein schematisches Diagramm einer beispielhaften Operation einer Hibernator-Bereitstellung eines Containerverwaltungssystems in Übereinstimmung mit der vorliegenden Offenbarung.
- 3A ist ein schematisches Diagramm einer beispielhaften Übertragung einer Anwendung von einem aktiven Zustand in einen inaktiven Zustand in Übereinstimmung mit der vorliegenden Offenbarung.
- 3B ist ein schematisches Diagramm einer beispielhaften Übertragung einer Anwendung von einem inaktiven Zustand in einen aktiven Zustand in Übereinstimmung mit der vorliegenden Offenbarung.
- 4 ist ein Flussdiagramm eines beispielhaften Verfahrens zum Übertragen einer Anwendung von einem aktiven Zustand in einen inaktiven Zustand in Übereinstimmung mit der vorliegenden Offenbarung.
- 5 ist ein Flussdiagramm eines beispielhaften Verfahrens zum Übertragen einer Anwendung von einem aktiven Zustand in einen inaktiven Zustand in Übereinstimmung mit der vorliegenden Offenbarung.
- 6 ist ein Flussdiagramm eines beispielhaften Verfahrens zum Übertragen einer Anwendung von einem inaktiven Zustand in einen aktiven Zustand, das mit der vorliegenden Offenbarung übereinstimmt.
-
Detaillierte Beschreibung
-
Die Erfindung ist in den unabhängigen Ansprüchen angegeben. Vorteilhafte Weiterbildungen sind den Unteransprüchen zu entnehmen. Ein Betriebssystem für Rechenzentren, wie beispielsweise ein Kubernetes-Containerverwaltungssystem, kann ein kostenloses Open-Source-Containerverwaltungssystem enthalten, das Mechanismen zum Bereitstellen, Verwalten und Skalieren von Containerverwaltungssystemen bereitstellt. Solche Systeme sind auf soll eine Plattform für die Automatisierung von Bereitstellung bieten , Skalierung und den Betrieb von Anwendungen im gesamten Cluster von Hosts und eine Befehlszeilenschnittstelle (CLI) verwenden , die für die Ausführung von Befehlen gegen Cluster innerhalb des Container - Management - System ermöglicht. Es können Befehle definiert werden, mit denen die CLI zum Verwalten eines Clusters erstellt und Informationen aus den Befehlen gesammelt werden können, damit Clusterressourcen oder -dienste erstellt, gruppiert, aktualisiert und / oder gelöscht werden können. Auf diese Weise definiert ein Containerverwaltungssystem set eine Reihe von Bausteinen oder Grundelementen , die gemeinsam Mechanismen wie die CLI bereitstellen, die Vorgänge bereitstellen, warten und skalieren.
-
Das Container-Management-System ist erweiterbar, um unterschiedlichen Workloads gerecht zu werden. Diese Erweiterbarkeit wird zum großen Teil durch eine Anwendungsprogrammierschnittstelle (API) bereitgestellt, die von internen Komponenten sowie von Erweiterungen und Containern verwendet wird, die auf dem Containerverwaltungssystem ausgeführt werden.
-
Die grundlegende Planungseinheit eines Containerverwaltungssystems ist ein Pod, der durch Gruppieren von containerisierten Komponenten eine höhere Abstraktionsebene hinzufügt. Ein Pod besteht aus einem oder mehreren Containern, die sich am Hostcomputer befinden sollen und Ressourcen gemeinsam nutzen können. Jeder Pod im Container - Management - System ist eine zugewiesen einzigartige IP -Adresse innerhalb eines Clusters von Hülsen, die die Anwendungen Verwendung Ports ermöglicht und gleichzeitig das Risiko von Konflikten zu minimieren. Ein Pod kann ein Volume definieren, z. B. ein lokales Festplattenverzeichnis oder eine Netzwerkfestplatte, und es den Containern im Pod zugänglich machen. Pods können manuell über die API. Verwaltet werden , oder ihre Verwaltung kann an einen Controller delegiert werden.
-
Ferner kann ein Containerverwaltungssystem eine tragbare, erweiterbare Open-Source-Plattform zum Verwalten von containerisierten Workloads und Diensten enthalten, um eine containerzentrierte Verwaltungsumgebung bereitzustellen und die Computer-, Netzwerk- und Speicherinfrastruktur für Benutzer-Workloads zu koordinieren. Ein Containerverwaltungssystem kann das Zuweisen einer eindeutigen IP zu jedem Container in einem Containerverwaltungssystem umfassen, die von jedem anderen Container innerhalb eines Hostclusters adressiert werden kann. Alle Operationen und Kommunikationen zwischen Komponenten und externen Benutzerbefehle verwenden gegenständliche Zustandstransfer (REST) aus Befehle übertragen über eine Anwendungsprogrammschnittstelle (API). Ein API-Server empfängt die übertragenen REST-Befehle. Folglich wird jedes Objekt in der Containerverwaltungssystemplattform als API-Objekt behandelt und verfügt über einen entsprechenden Eintrag für die API. API-Objekte werden verwendet, um den Status eines Clusters zu beschreiben, einschließlich applications der Anwendungen oder anderer Workloads, die ausgeführt werden sollen, der verwendeten Container-Images, der Anzahl der Replikate, des Status der Knoten, der verfügbaren Netzwerk- und Festplattenressourcen und so weiter. Der Status wird durch Erstellen von Objekten mithilfe der API festgelegt, normalerweise über die Befehlszeilenschnittstelle. Die API kann auch direkt verwendet werden, um mit dem Cluster zu interagieren und einen gewünschten Status festzulegen oder zu ändern.
-
Ein Containerverwaltungscluster stellt Anwendungen auf Knoten des Clusters basierend auf den Planungsrichtlinien des Clusters bereit. Während eine große Anzahl von Anwendungen in einem Cluster von Pods bereitgestellt wird, werden einige Anwendungen je nach Datenverfügbarkeit möglicherweise nur regelmäßig (z. B. täglich, wöchentlich) ausgeführt. In Zeiten der Nichtbenutzung verbrauchen die Anwendungen jedoch weiterhin Ressourcen (z. B. CPU, Speicher usw.), was zu einer ineffizienten Ressourcennutzung und erhöhten Ressourcenkosten sowie zu einer verringerten Systemleistung und erhöhten Skalierungsproblemen in Umgebungen mit festen Bedingungen führen kann Ressourcen.
-
Daher bezieht sich die vorliegende Offenbarung auf die Verwendung einer Hibernator-Bereitstellung, die als ein oder mehrere Mikrodienste implementiert ist und die Anwendungen auf einem Cluster eines Containerverwaltungssystems überwacht, um diejenigen Anwendungen zu bestimmen, die eine für die Anwendung definierte Semantik „Ruhezustand bei Inaktivität“ enthalten und Versetzen der Anwendung in einen Ruhezustand oder inaktiven Zustand, wenn die Bereitstellung des Ruhezustands feststellt, dass die Anwendung für einen vorbestimmten Zeitraum, wie beispielsweise zehn (10) Minuten, keine Datenpakete auf dem Service-Port empfängt. Während sich die Anwendung im Ruhezustand befindet, leitet die Hibernator-Bereitstellung den Datenverkehr über den Service-Port der Hibernated-Anwendung an die Hibernator-Bereitstellung weiter. Die Hibernator-Bereitstellung überwacht den Service-Port im Namen der Ruhezustand-Anwendung. Wenn die Hibernator-Bereitstellung ein eingehendes Paket am Port der Hibernated-Anwendung empfängt, speichert die Hibernator-Bereitstellung das eingehende Paket oder die eingehenden Pakete zwischen und entfernt die Ruhezustand-Anwendung aus dem Ruhezustand. Sobald die im Ruhezustand befindliche Anwendung aus dem Ruhezustand entfernt wurde, wird der Verkehrsfluss für die Anwendung fortgesetzt und die zwischengespeicherten Datenpakete an die Anwendung weitergeleitet, um die Verarbeitung der Anwendung fortzusetzen.
-
Die Figuren hier folgen einer Nummerierungskonvention, bei der die erste Ziffer der Zeichnungsfigurennummer entspricht und die verbleibenden Ziffern ein Element oder eine Komponente in der Zeichnung identifizieren. Beispielsweise bezieht sich die Referenznummer 216 auf das Element „216“ in 2, und ein analoges Element kann durch die Referenznummer 316 in 3B identifiziert werden. Analoge Elemente in einer Figur können mit einem Bindestrich und einer zusätzlichen Ziffer oder einem zusätzlichen Buchstaben referenziert werden. Siehe zum Beispiel die Elemente 120-1 und 112-N in . Auf solche analogen Elemente kann im Allgemeinen ohne Bindestrich und zusätzliche Ziffer oder Buchstaben verwiesen werden. Beispielsweise können die Elemente 121-1 und 121-N gemeinsam als 121 bezeichnet werden. Elemente, die in den verschiedenen Figuren hier gezeigt sind, können hinzugefügt, ausgetauscht und / oder eliminiert werden, um eine Anzahl zusätzlicher Beispiele der Offenbarung bereitzustellen. Darüber hinaus sollen der Anteil und der relative Maßstab der in den Figuren angegebenen Elemente die Beispiele der Offenbarung veranschaulichen und sollten nicht in einem einschränkenden Sinne verstanden werden.
-
1 ist ein schematisches Diagramm eines Behälterverwaltungssystems 100, das mit einem Beispiel der vorliegenden Offenbarung übereinstimmt. Wie in dem Beispiel von 1 dargestellt, kann ein Containerverwaltungssystem gemäß der vorliegenden Offenbarung einen Hauptknoten 102, der für die Verwaltung des Containerverwaltungssystems 100 verantwortlich ist, und mehrere Arbeiterknoten 104-1, ..., 104- umfassen. N (im Folgenden zusammenfassend als Arbeiterknoten 104 bezeichnet), innerhalb dessen die Dienste des Containerverwaltungssystems 100 arbeiten, um eine angeforderte Anwendung auszuführen. Beispiele für solche angeforderten Anwendungen können Vorgänge wie das Erstellen einer Bereitstellung, das Löschen der Bereitstellung, das Aktualisieren der Bereitstellung usw. sein. Während der Kürze halber zwei Arbeiterknoten 104 in 1 dargestellt sind, versteht es sich, dass das Containerverwaltungssystem 100 mehr als zwei Arbeiterknoten 104 (z. B. N Anzahl von Arbeiterknoten 104) enthalten kann, die für einen Cluster von Arbeitern sind Knoten 104.
-
Der Master - Knoten 102 kann der Zugangspunkt aller Verwaltungsaufgaben für den Container - Management - System 100 sein , und ein verantwortlich sein kann 104 oder mehr Arbeiter Knoten für orchestriert, in dem die Dienste des Behälters Verwaltungssystem 100 eine Anwendung zum Erzeugen befinden. Der Masterknoten 102 enthält einen API-Server 106, der sowohl den internen als auch den externen Schnittstellenzugriff auf das Containerverwaltungssystem über den Masterknoten 102 bereitstellt. Der API - Server 106 empfängt Befehle, wie gegenständlicher Zustandstransfer (REST) Befehle bekannt ist, aus einer Befehlszeile (CL) Schnittstellenwerkzeug 108, wie beispielsweise eine kubectl Befehlszeilenschnittstelle, zum Beispiel. Die REST-Befehle bieten eine Reihe von Architekturbeschränkungen, die bei Anwendung als Ganzes die Skalierbarkeit von Komponenteninteraktionen, die Allgemeingültigkeit von Schnittstellen, die unabhängige Bereitstellung von Komponenten und Zwischenkomponenten hervorheben. Der API-Server 106 verarbeitet die REST-Befehlsanforderungen, validiert die Befehle und führt die Logik innerhalb der Befehle aus.
-
Die Ergebnisse der REST - Befehle vom API - Server 106 verarbeitet werden , in einer Speicherkomponente 110, wie beispielsweise eine ETCD Speicherkomponente gespeichert ist, zum Beispiel enthalten in dem Master - Knoten 102. Die Speicherkomponente 110 speichert zuverlässig Konfigurationsdaten des Clusters von Arbeitsknoten 104, die den Status des Clusters darstellen (dh welche Knoten im Cluster verfügbar sind, welche Pods ausgeführt werden sollen, auf welchen Knoten sie ausgeführt werden sollen usw.).. Die Speicherkomponente 110 ist ein verteilter Schlüsselwertspeicher, der hauptsächlich für die gemeinsam genutzte Konfiguration und das Dienstverzeichnis verwendet wird. Die Speicherkomponente 110 stellt Speicher für REST-Befehle bereit, die vom API-Server 106 empfangen werden, um CRUD-Operationen (Create-Update-and-Delete) auszuführen, sowie eine Schnittstelle zum Registrieren von Beobachtern auf bestimmten Knoten, wodurch eine zuverlässige Möglichkeit bereitgestellt wird, den Rest von zu benachrichtigen das Containerverwaltungssystem 100 über Konfigurationsänderungen innerhalb des Containerverwaltungssystems 100. So ermöglichen beispielsweise die gemeinsam genutzten Daten in der Speicherkomponente 110 den API - Server 106 die gesamte Gruppe der Arbeiter 104 in dem Behältermanagementsystem 100 über Konfigurationsänderungen , wie beispielsweise Arbeitsplätze vorgesehen sind, erstellt und bereitgestellt, Schote Knoten benachrichtigen / Servicedetails und -status, Namensräume und Replikationsinformationen usw.
-
Der Hauptknoten 102 enthält auch einen Planer 112 und einen Steuerungsmanager 114. Der Scheduler 112 kann in dem Masterknoten 102 enthalten sein, um Pods und Dienste auf den Arbeiterknoten 104 bereitzustellen. Der Planer 112 enthält Informationen zu verfügbaren Ressourcen auf dem Containerverwaltungssystem 100 sowie Ressourcen, die für die Ausführung der Dienste verwendet werden. Infolgedessen trifft der Planer 112 Entscheidungen darüber, wo ein bestimmter Dienst bereitgestellt werden soll. Der Controller-Manager 112 verwendet den API-Server 106, um den gemeinsam genutzten Status des Container-Management-Systems 100 zu überwachen. Beispielsweise kann der Steuerungsmanager 114 Korrekturänderungen am aktuellen Status des Containerverwaltungssystems 100 vornehmen, um den aktuellen Status in einen anderen Status zu ändern, einen ausgefallenen Pod neu zu erstellen oder einen Pod zu entfernen. Außerdem kann der Master - Knoten 102 umfassen einen DNS - Server 107, wie zum Beispiel, das Zeitpläne den DNS - Pod und Dienste auf dem Cluster von Arbeiter - Knoten 104 und konfiguriert die kubelets einzelnen Behälter anzuweisen , den DNS - Dienst des IP zu verwenden , um Auflösen eines DNS-Eintrags 109.
-
Eine Anzahl von Hülsen 116-1,..., 116-N (nachstehend zusammenfassend als Hülsen 116 bezeichnet) befinden sich in jedem der Arbeiterknoten 104 und einem oder mehreren Behältern 118-1,..., 118-N (nachstehend) zusammen zusammen als Behälter 118 bezeichnet) befinden sich in jeder der Hülsen 116. Die Container 118 befinden sich am Hostcomputer (Computer, auf dem Container ausgeführt werden, dh Arbeiterknoten) und können Ressourcen gemeinsam nutzen. Die Pods 116, die die grundlegende Planungseinheit in Kubernetes darstellen, fügen eine höhere Abstraktionsebene hinzu, indem containerisierte Komponenten gruppiert werden, die Ressourcen gemeinsam nutzen, z. B. Speicher, Linux-Namespaces, Gruppen, IP-Adressen usw. Jede der Hülsen 116 ist zugewiesen eine einzigartige IP - Adresse im Container - Management - System 100, die Anwendungen Ports erlaubt zu verwenden , ohne das Risiko von Konflikten. 116 Jede der Hülsen kann ein Volumen, wie ein lokales Festplattenverzeichnis oder eine Netzwerkplatte und belichten die Lautstärke auf den Behälter 118 in den Hülsen 116 definieren. Die Hülsen 116 können verwaltet werden manuell über die API Server 106 oder die Verwaltung der Hülsen 116 kann an eine Steuerung übertragen werden.
-
Die Container 118 speichern die laufende Anwendung zusammen mit den Bibliotheken und Komponenten oder Diensten, um die zum Ausführen einer Anwendung erforderliche Software auszuführen. Diese Komponenten umfassen Dateien, Umgebungsvariablen, Abhängigkeiten und Bibliotheken. Das Host-Betriebssystem (Betriebssystem, das auf dem Knoten ausgeführt wird, dh Container) beschränkt den Zugriff der Container 118 auf eine physische Ressource wie CPU, Speicher und Speicher, so dass ein einzelner Container, wie z. B. Container 118-1, nicht verwendet werden kann alle physischen Ressourcen eines Hosts. Ein Gasthost-Betriebssystem enthält andererseits Anweisungen, die entweder auf einer virtuellen Maschine oder einer partitionierten Festplatte installiert sind und ein Betriebssystem beschreiben, das sich vom Host-Betriebssystem unterscheidet. Daher wird ein Host-Betriebssystem auf einem Computer installiert und interagiert mit der zugrunde liegenden Hardware, während sich ein Gastbetriebssystem auf einer virtuellen Maschine befindet.
-
Die Schoten in einem einzigen Arbeiter Knoten 104 erzeugt werden, zerstört und neu erstellt, basierend auf dem Zustand des Servers enthielten 116 und den Dienst selbst und damit für eine lange Zeit bestehen kann nicht bestimmt fortzusetzen . Aufgrund der relativ kurzen Lebensdauer der Pods 116 kann sich die IP-Adresse, an der sie bedient werden, ändern, was die Kommunikation der zugehörigen Mikrodienste erschwert. Daher hat Kubernetes das Konzept eines Dienstes eingeführt, bei dem es sich um eine Abstraktion über einer Reihe von Pods 116 handelt, bei der typischerweise ein Proxy verwendet wird, um über den Diensten ausgeführt zu werden, damit andere Dienste über eine virtuelle IP-Adresse kommunizieren können . Infolgedessen kann ein Lastausgleich für zahlreiche Pods 116 eingerichtet werden, so dass die Pods über einen Dienst freigelegt werden können. Die Pods 116 können neu erstellt und Änderungen an ihrem entsprechenden IP-Protokoll vorgenommen werden. Daher werden Dienste mit stabilen IP- und DNS-Namen erstellt, die von anderen Pods zur Kommunikation mit dem Pod 116 verwendet werden können. Stellen Sie sich beispielsweise ein Bildverarbeitungs-Backend vor, das mit drei Replikaten ausgeführt wird. Diese Repliken sind fungibel - das heißt, Frontends ist es egal, welches Backend sie verwenden. Während sich die tatsächlichen Pods 116, aus denen der Backend-Satz besteht, möglicherweise ändern, sind den Frontend-Clients diese Änderungen möglicherweise nicht bekannt oder sie verfolgen möglicherweise keine Liste der Backends. Jedem der Dienste in den Containern 118 des Containerverwaltungssystems 100 wird ein DNS-Name (Domain Name Service) zugewiesen, der einen Namen enthält, der den Pod 116 identifiziert, in dem sich der Dienst befindet, sowie einen Teil des DNS-Namens, der den Namen identifiziert des Dienstes.
-
Jeder der Arbeiterknoten 104 enthält einen Knotenagenten, wie beispielsweise ein Kubelet, (z. B. enthält der Arbeiterknoten 104-1 den Knotenagenten 120-1, nachstehend wird auf die Knotenagenten 120-1, ..., 120-N Bezug genommen gemeinsam als Knotenagenten 120) und ein Proxy, wie beispielsweise ein Kube-Proxy (z. B. der Arbeiterknoten 104-1 enthält den Proxy 122-1, nachstehend werden die Proxys 122-1, ..., 122-N gemeinsam als bezeichnet Proxies 122)). Ein Knotenagent 120 steht mit dem Hauptknoten 102 in Kommunikation und empfängt Details für die Konfiguration der Pods 116 vom API-Server 106. Der Knotenagent 120 verwendet die empfangenen Details, um sicherzustellen, dass die konstruierten Container 118 wie beabsichtigt arbeiten. Zusätzlich kann der Knotenagent 120 auch Informationen über bestimmte Dienste von dem Speicher 110 empfangen, um Informationen zu Diensten zu erhalten und Details zu neu erzeugten oder erstellten Diensten zu erstellen.
-
Jeder der Proxys 122 fungiert als Netzwerk-Proxy oder Hub, über den Anforderungen übertragen werden, und als Load Balancer für einen Dienst auf einem einzelnen Worker-Knoten 104, der als Reverse-Proxy fungiert und den Netzwerk- oder Anwendungsverkehr auf mehrere Server verteilt. Der Load Balancer wird verwendet, um die Kapazität (gleichzeitige Benutzer) und die Zuverlässigkeit von Vorgängen zu erhöhen und das Netzwerkrouting für TCP- (Packation Control Protocol) und UDP-Pakete (User Data Protocol) durchzuführen. Die Proxys 122 sind dafür verantwortlich, den Verkehr an den geeigneten Container 118 weiterzuleiten, um den Zugriff auf Dienste basierend auf einer IP-Adresse und der Nummerierung einer eingehenden Anforderung zum Erstellen einer Anwendung zu ermöglichen.
-
Auf diese Weise sind die Knoten die Ressourcen des Arbeitnehmers 104 zusammen und identifiziert kombiniert werden können , so dass, wenn eine Anwendung oder ein Programm auf den Container - Management - System erstellt oder bereitgestellt werden 100, das Programm oder Dienstleistungen für das Erstellen und Ausführen der Anwendung sind befindet sich in den einzelnen Arbeiterknoten 104. Wenn eine der Knoten 104 hinzugefügt oder entfernt werden , das Container - Management - System 100 ist in der Lage zu erstellen oder die Programme oder Dienste bereitstellen , indem Ressourcen von verschiedenen Knoten 104 oder unter Verwendung eine Kombination verschiedenen Dienste innerhalb des Knoten 104 zu kombinieren.
-
Um containerisierte Anwendungen in einem containerisierten Managementsystem wie beispielsweise einem Kubernetes-System bereitzustellen, kann eine Bereitstellungskonfiguration zum Bereitstellen von Anweisungen zum Erstellen und Aktualisieren von Diensten zum Erstellen einer gewünschten Anwendung über einen Befehl in den Masterknoten 102 eingegeben werden Zeilenschnittstelle 108, wie beispielsweise eine kubectl-Befehlszeilenschnittstelle. Sobald die Anweisungen zum Erstellen und Aktualisieren von Diensten zum Erstellen einer gewünschten Anwendung vom Masterknoten 102 empfangen wurden, plant der API-Server 106 des Masterknotens 102 die Anwendung auf einzelnen Worker-Knoten 104 innerhalb des Clusters von Worker-Knoten 104 des Containerverwaltungssystem 100 zum Erstellen der Anwendung unter Verwendung einer Kombination mehrerer verschiedener Dienste innerhalb mehrerer verschiedener Container 118 aus mehreren verschiedenen Pods 116 des Containerverwaltungssystems 100. Auf diese Weise wird die Anwendung unter Verwendung einer Kombination von Diensten erstellt, die sich in mehreren Containern 118 befinden, die sich in einem oder mehreren Pods 116 in einem oder mehreren Arbeiterknoten 104 befinden.
-
Sobald die Anwendung erstellt und geplant wurde, überwacht der Masterknoten 102 kontinuierlich die Pods 116. Wenn der Masterknoten 102 bestimmt, dass ein Dienst, der für die Anwendung verwendet wird, die sich in einem der Container 118 der Pods 116 befindet, ausfällt oder gelöscht wird, startet der Masterknoten 102 den gelöschten oder nicht operierenden Dienst unter Verwendung von Diensten in den Containern 118 der Pods 116 neu des Containermanagementsystems 100. Auf diese Weise überwacht der API-Server 106 die Funktionalität der Pods 116 und kann den Pod 116 neu erstellen, wenn die Pods 116 nicht mehr wie beabsichtigt funktionieren.
-
Worker Jeder Worker-Knoten 104 enthält eine Hibernator-Bereitstellung (z. B. enthält der Worker-Knoten 104-1 eine Hibernator-Bereitstellung 124-1, nachstehend werden die Hibernator-Bereitstellungen 124-1, ..., 124-N gemeinsam als Hibernator-Bereitstellung 124 bezeichnet). Wie oben beschrieben, speichert jeder der Container 118 die laufende Anwendung zusammen mit den Bibliotheken und Komponenten oder Diensten, um die Software auszuführen, die zum Ausführen einer Operation für die Anwendung erforderlich ist. Wenn ein Benutzer einen Befehl über die CL-Schnittstelle 108 eingibt, kann der Befehl mehrere Semantiken für Anweisungen zum Ausführen der Anwendung enthalten. Beispielsweise kann eine Semantik wie „Ruhezustand bei Inaktivität“ in die Konfigurationsdatei aufgenommen werden, die den Befehl des Benutzers bildet, der anweist, dass die Anwendung in den Ruhezustand versetzt oder in einen inaktiven Zustand versetzt werden soll, wenn die Anwendung für einen bestimmten nicht verwendet wird Zeitraum, wie zum Beispiel zehn (10) Minuten.
-
Die hibernator Entfaltungs 124 kann seine entsprechende Anwendungen , die auf dem entsprechenden Cluster von Arbeiter überwachen die Knoten 104 des Behältermanagement - System 100 und identifizieren diejenigen Anwendungen , die die „Ruhezustand-when-inactive“ semantisches definiert für die Anwendung umfassen. Die Hibernator-Bereitstellung 124 überträgt die Anwendung in einen inaktiven Zustand, wenn die Hibernator-Bereitstellung 124 sowohl feststellt, dass die Anwendung die Semantik „Hibernate-When-Inactive“ enthält, als auch Datenpakete auf dem Service-Port für den angegebenen Zeitraum empfängt, d. H. Zum Beispiel zehn (10) Minuten.
-
Während sich die Anwendung im inaktiven Zustand befindet, leitet die Hibernator-Bereitstellung 124 den Datenverkehr, der über den Service-Port der Hibernator-Anwendung eingeht, zur Hibernator-Bereitstellung 124 um. Die Hibernator-Bereitstellung 124 überwacht den Service-Port im Namen der Ruhezustand-Anwendung, und wenn die Hibernator-Bereitstellung 124 ein eingehendes Paket am Port der Hibernator-Anwendung empfängt, speichert die Hibernator-Bereitstellung das eingehende Paket oder die eingehenden Pakete zwischen und überträgt die Ruhezustand-Anwendung vom inaktiven Zustand an einen aktiver Zustand. Sobald die Anwendung im Ruhezustand vom inaktiven Zustand in den aktiven Zustand übertragen wurde, wird der Betrieb der Anwendung fortgesetzt und die zwischengespeicherten Datenpakete werden zur erneuten Verarbeitung an die Anwendung weitergeleitet, wie nachstehend beschrieben.
-
2 ist ein schematisches Diagramm des Betriebs einer Ruhezustandbereitstellung 224 eines Behälterverwaltungssystems 204 gemäß einem Beispiel, das mit der vorliegenden Offenbarung übereinstimmt. Wenn Anweisungen zum Erstellen und Aktualisieren von Diensten zum Erstellen einer bestimmten Anwendung vom Masterknoten über die Befehlszeilenschnittstelle empfangen werden, wie oben beschrieben, plant ein API-Server 206 einen API-Dienst oder eine Anwendung 240 auf einem Arbeitsknoten 204 unter Verwendung einer Kombination von mehrere verschiedene Dienste, die sich in mehreren verschiedenen Containern 218 mehrerer verschiedener Pods 216 eines Clusters von Arbeiterknoten 204 befinden. Die Anwendung 240 ist eine Gruppe von Pods 218, die auf einem oder mehreren der Arbeitsknoten 204 ausgeführt werden. Jede Anwendung 240 enthält eine Pod-Label-Abfrage, die die Pods 218 mit Containern 216 definiert, die Dienste enthalten, die zum Verarbeiten der Anwendung 240 verwendet werden.
-
Ein Proxy 222 auf den Arbeiter Knoten 204 leitet den Datenverkehr, gekennzeichnet durch mehrere Pfeile 247-1,..., 247N (im Folgenden zusammenfassend als Pfeile 247 bezeichnet) von 2 zu dem geeigneten Container oder den entsprechenden Containern 218, in denen sich Dienste befinden, die zum Erstellen der Anwendung 240 erforderlich sind, so dass ein Dienstendpunkt der Anwendung 240 zum Erhalten des Zugriffs auf die Container 218 vorhanden ist wird basierend auf einer IP-Adresse der zugeordneten Pods 216 identifiziert. Der Proxy 222 Updates iptables 242 für die Anwendung 240, , durch die die ankommenden und abgehenden Paketfluss gesteuert werden kann, , die die IP - Adressen der Hülsen 216 verwendet werden , umfassen für den Verkehr zu den Leistungen der entsprechenden Behälter Erfassung 218 und die Nummerierung eingehender Anforderungen 243 von einem Client 242 zum Erstellen der Anwendung. Eine solche Aktualisierung der iptables 242 durch den Proxy 222 ermöglicht den Zugriff auf Dienste innerhalb der Container 218 innerhalb eines oder mehrerer Pods 216 basierend auf der IP-Adresse für den Pod 216.
-
Wenn ein Benutzer einen Befehl über die CL-Schnittstelle eingibt, um die Anwendung 240 zu erstellen, kann der Benutzer eine Anmerkung in den Befehl aufnehmen, die anweist, dass die Anwendung 240 in den Ruhezustand versetzt werden soll, wenn die Anwendung 240 für einen bestimmten Zeitraum nicht verwendet wird, wie z als zehn (10) Minuten. Beispielsweise kann eine Semantik wie „Ruhezustand bei Inaktivität“ in die Konfigurationsdatei aufgenommen werden, die den Befehl bildet, und einen bestimmten Zeitraum der Inaktivität enthalten. A hibernator Entfaltungs 224 kann eine Liste der Anwendungen 240 auf dem Cluster des Worker - Knoten 204 periodisch schafft für Inaktivität auf der Grundlage dieser Anwendungen 240 , dass die hibernator Entfaltungs 224 identifiziert, als auch den „Ruhezustand-when-inactive“ semantische überwacht werden. Auf diese Weise überwacht die Hibernator-Bereitstellung 224 anschließend den Paketfluss an den Service-Ports der Anwendungen 240, die in den Listen der Anwendungen 240 enthalten sind, die auf Zeiträume der Inaktivität überwacht werden sollen. Die Hibernator-Bereitstellung 224 kann bestimmen, ob die überwachte Anwendung 240 von einem aktiven Zustand in einen inaktiven Zustand übertragen werden soll, wenn sowohl die Semantik als für die Anwendung 240 vorhanden bestimmt wird, dh die Anwendung 240 eine Anwendung 240 ist, die in der erstellten Anwendung enthalten ist Liste der Anwendungen 240, die auf Inaktivität überwacht werden sollen, und die Anwendung 240 wird für den in der Semantik „Ruhezustand bei Inaktivität“ angegebenen Zeitraum als inaktiv bestimmt.
-
3A ist ein schematisches Diagramm 304 der Übertragung einer Anwendung von einem aktiven Zustand in einen inaktiven Zustand gemäß einem Beispiel, das mit der vorliegenden Offenbarung übereinstimmt. Eine Hibernator-Bereitstellung 324 kann periodisch (beispielsweise alle 30 Minuten) eine aktuell erstellte Liste der Anwendungen überwachen, die auf Inaktivität überwacht werden sollen, und wann die Hibernator-Bereitstellung 324 bestimmt, wie durch das Fehlen des Pfeils 343 angezeigt, der sich vom Client 344 zum Client erstreckt Anwendung 340, dass eine Anforderung für die Anwendung 340 vom Client 344 für den Zeitraum der Inaktivität nicht empfangen wurde, dh zehn (10) Minuten, beispielsweise angegeben für die Anwendung 340 innerhalb des „Ruhezustands, wenn inaktiv“ Semantisch kann die Hibernator-Bereitstellung 324 bestimmen, dass die Anwendung 340 in den Ruhezustand versetzt werden soll. Daher überträgt die Hibernator-Bereitstellung 324 die Anwendung 340 vom aktiven Zustand in einen inaktiven Zustand.
-
Um beispielsweise die Anwendung 340 vom aktiven Zustand in einen inaktiven Zustand zu übertragen, kann die Hibernator-Bereitstellung 324 die Replikatsätze der Anwendung 340 von einem aktuellen Wert auf Null verkleinern oder reduzieren, um zu verhindern, dass die Anwendung 340 ausgeführt wird. Replikatsätze bieten Redundanz, indem sie mehrere Versionen einer Anwendung bereitstellen, sodass Probleme vermieden werden können, wenn eine oder mehrere Versionen der Anwendung fehlschlagen. Durch die Verwendung mehrerer Replikatsätze oder Versionen eines Containers kann der Datenverkehr einfacher an verschiedene Instanzen oder Container gesendet werden, um eine Überlastung einer einzelnen Instanz oder eines einzelnen Pods zu verhindern. In dem inaktiven Zustand kann eine Dienstrichtlinie von der Hibernator-Bereitstellung 324 derart geändert werden, dass der Dienstendpunkt der Anwendung 340 von der Hibernator-Bereitstellung 324 von einem Standort an den Pods 316, die der Anwendung 340 zugeordnet sind, zu einem Standort übergeht bei der Bereitstellung des Ruhezustands 324, wie durch das Entfernen der in 2 gezeigten Pfeile 247 und das Hinzufügen des Pfeils 345 in 3A angezeigt. Infolgedessen wird jede nachfolgende Anforderung, die vom Client 344 empfangen wird, um auf die Anwendung 340 zuzugreifen, während sich die Anwendung 340 im inaktiven Zustand befindet, an der Hibernator-Bereitstellung 324 und nicht an den Pods 316 beendet und kann daher von der Hibernator-Bereitstellung 324 erkannt werden.
-
Zusätzlich werden Pakete von API-Interaktionen zwischen dem Masterknoten und den Arbeitsknoten, die sich auf die Anwendung 340 beziehen, so umgestellt, dass sie von der Hibernator-Bereitstellung 324 empfangen werden, während sich die Anwendung 340 im inaktiven Zustand befindet. Die Hibernator-Bereitstellung 324 kann dann den Service-Port im Namen der Ruhezustand-Anwendung 340 überwachen, und wenn die Hibernator-Bereitstellung 324 ein eingehendes Paket für die Anwendung 340 empfängt, wie beispielsweise eine HTTP-GET-API (REST-Paket), kann die Hibernator-Bereitstellung 324 dann zwischenspeichern jedes eingehende Paket oder alle eingehenden Pakete für die Anwendung 340 im Speicher, während sich die Anwendung 340 im inaktiven Zustand befindet.
-
Auf diese Weise wird durch Übertragen der Anwendung 340 von dem in 2 dargestellten aktiven Zustand in einen in 3A dargestellten inaktiven Zustand während inaktiver Zeiträume der Nichtbenutzung, die durch das Fehlen von Clientanforderungen zum Zugriff auf die Anwendung angezeigt werden, unnötiger Ressourcenverbrauch (CPU) verursacht, Speicher usw.) des Clusters von Arbeitsknoten 304 durch die Anwendung 340 können reduziert werden, was zu einer Verringerung der ineffizienten Ressourcennutzung und -kosten führt, zusammen mit einer Erhöhung der Systemleistung und einer Verringerung der Skalierungsprobleme für den Cluster.
-
3B ist ein schematisches Diagramm 304 der Übertragung einer Anwendung von einem inaktiven Zustand in einen aktiven Zustand gemäß einem Beispiel, das mit der vorliegenden Offenbarung übereinstimmt. Während sich die Anwendung 340 im inaktiven Zustand befindet und die Hibernator-Bereitstellung 324 bestimmt, dass eine nachfolgende Anforderung 343 vom Client 344 empfangen wird, um auf die Anwendung 340 zuzugreifen, bestimmt die Hibernator-Bereitstellung 324, dass die Anwendung 340 aus dem dargestellten inaktiven Zustand übertragen werden soll in 3A auf den in 2 dargestellten aktiven Zustand. Wenn beispielsweise bestimmt wird, dass eine nachfolgende Anforderung 343 empfangen wird, wie in 3B gezeigt, während sich die Anwendung 340 in dem in 3A dargestellten inaktiven Zustand befindet, wird der Dienstendpunkt der Anwendung 340 von der Hibernator-Bereitstellung 324 vom Lokalisieren überführt bei der Hibernator-Bereitstellung 324, um sich an den Pods 316 zu befinden, die der Anwendung 340 zugeordnet sind.
-
Zusätzlich kann der Übergang vom inaktiven Zustand in den aktiven Zustand die Hibernator-Bereitstellung 324 umfassen, die die Pakete überträgt, die von der Hibernator-Bereitstellung 324 gespeichert wurden, während sich die Anwendung 340 im inaktiven Zustand befand, zu den Pods 316, um die Verarbeitung der Anwendung 340 fortzusetzen an den Hülsen 316. Infolgedessen werden nachfolgende Anforderungen 343, die vom Client 344 für den Zugriff auf die Anwendung 340 empfangen werden, an den Pods 316 und nicht an der Hibernator-Bereitstellung 324 beendet und Pakete von API-Interaktionen zwischen dem Masterknoten und den Arbeitsknoten in Bezug auf die Die Anwendung 340 wird daher wieder an den Pods 316 empfangen, sobald die Anwendung 340 von dem in 3A dargestellten inaktiven Zustand in den in 2 dargestellten aktiven Zustand durch die Hibernator-Bereitstellung 324 übertragen wird.
-
4 ist ein Flussdiagramm eines beispielhaften Verfahrens 450 zum Übertragen einer Anwendung von einem aktiven Zustand in einen inaktiven Zustand in Übereinstimmung mit der vorliegenden Offenbarung. Wenn ein Benutzer einen Befehl über die CL-Schnittstelle eingibt, um die Anwendung zu erstellen, kann der Benutzer den Befehl so erstellen, dass er eine Anmerkung enthält, die angibt, dass die Anwendung in den Ruhezustand versetzt werden soll, wenn die Anwendung für einen bestimmten Zeitraum nicht verwendet wird, z. B. zehn (10 Minuten. Beispielsweise kann eine Semantik wie „Ruhezustand bei Inaktivität“ in die Konfigurationsdatei aufgenommen werden, die den Befehl bildet, und sie kann einen bestimmten Zeitraum der Inaktivität enthalten, nach dem angefordert wird, dass die Anwendung in den Ruhezustand versetzt wird, dh aus einem aktiven Zustand übertragen wird in einen inaktiven Zustand. Bei 452 kann das Verfahren 450 periodische Überwachungsanwendungen des Containerverwaltungssystems umfassen, wie beispielsweise die Überwachung alle 30 Minuten. Bei 454 kann das Verfahren 450 das Bestimmen umfassen, ob die überwachten Anwendungen eine vorbestimmte Semantik enthalten. In einem Beispiel kann die vorgegebene Semantik eine für die Anwendung definierte Semantik „Ruhezustand bei Inaktivität“ sein, die angibt, dass die Anwendung in Zeiten, in denen die Anwendung inaktiv ist, z. B. wenn die Anwendung inaktiv ist, von einem aktiven Zustand in einen inaktiven Zustand versetzt werden soll ist beispielsweise 10 Minuten inaktiv.
-
Bei 456 kann das Verfahren 450 das Bestimmen umfassen, ob eine Anwendung mit der vorbestimmten Semantik aktiv ist, beispielsweise durch eine Anforderung zum Zugriff auf die Anwendung, die von einem Client innerhalb des angegebenen Zeitraums empfangen wird, der in der Semantik enthalten ist. Beispielsweise kann festgestellt werden, dass die Anwendung nicht aktiv ist, dh inaktiv (Nr. In 456), wenn während des in der Semantik definierten vorgegebenen Zeitraums keine Clientanforderungen für die Anwendung empfangen wurden, wie beispielsweise 10 Minuten. Andererseits kann festgestellt werden, dass die Anwendung aktiv ist (Ja in 456), wenn während des vorgegebenen Zeitraums eine oder mehrere Clientanforderungen für die Anwendung aufgetreten sind.
-
Wenn festgestellt wird, dass die Anwendung aktiv ist, befindet sich die Anwendung weiterhin in einem aktiven Zustand, und die Überwachung der Anwendungen wird bei 452 fortgesetzt. Bei 458 kann das Verfahren 450 als Reaktion auf das Bestimmen, dass die Anwendung nicht aktiv ist, umfassen, dass die Anwendung vom aktiven Zustand in einen inaktiven Zustand übertragen wird. Um beispielsweise die Anwendung vom aktiven in den inaktiven Zustand zu übertragen, können Replikatsätze der Anwendung auf Null verkleinert werden. Darüber hinaus kann eine Änderung der Servicerichtlinie vorgenommen werden, sodass ein Service-Endpunkt der Anwendung von Pods von Worker-Knoten, die der Anwendung zugeordnet sind, in eine Hibernator-Bereitstellung überführt wird, sodass nachfolgende Anforderungen für die Anwendung, während sich die Anwendung im inaktiven Zustand befindet, beendet werden eher bei der Bereitstellung des Ruhezustands als an den Pods der Worker-Knoten.
-
In einem Beispiel kann daher ein Verfahren zum Übertragen einer Anwendung vom aktiven Zustand in einen inaktiven Zustand das Überwachen einer Anwendung durch eine Hibernator-Bereitstellung eines Containerverwaltungssystems, das Bestimmen einer für die Anwendung definierten Semantik und das Übertragen der Anwendung vom aktiven Zustand umfassen in den inaktiven Zustand, wenn die Anwendung nicht aktiv ist und auf der für die Anwendung definierten Semantik basiert.
-
Auf diese Weise kann durch Übertragen der Anwendung vom aktiven Zustand in den inaktiven Zustand während inaktiver Nichtbenutzungsperioden für die Anwendung unnötig Ressourcen (CPU, Speicher usw.) des Clusters von Arbeitsknoten durch die Anwendung verbraucht werden Dies führt zu einer Verringerung der ineffizienten Ressourcennutzung und -kosten sowie zu einer Erhöhung der Systemleistung und einer Verringerung der Skalierungsprobleme für den Cluster.
-
5 ist ein Flussdiagramm eines beispielhaften Verfahrens 560 zum Übertragen einer Anwendung von einem aktiven Zustand in einen inaktiven Zustand gemäß einem Beispiel, das mit der vorliegenden Offenbarung übereinstimmt. In einigen Beispielen erstellt die Hibernator-Bereitstellung möglicherweise eine Liste der Anwendungen auf dem Cluster von Worker-Knoten, die auf Inaktivität überwacht werden sollen, basierend auf den Anwendungen, bei denen die Hibernator-Bereitstellung die Semantik „Hibernate-When-Inactive“ enthält. Auf diese Weise kann das Verfahren 560 bei 562 das regelmäßige (z. B. alle 30 Minuten) Aktualisieren der Liste der Anwendungen, die auf Inaktivität überwacht werden sollen, durch die Bereitstellung des Ruhezustands umfassen. Bei 564 kann das Verfahren 560 als Reaktion auf die Aktualisierung der Liste das anschließende Überwachen des Paketflusses auf Service-Ports der Anwendungen, die in der Liste der zu überwachenden Anwendungen für Zeiträume der Inaktivität enthalten sind, durch die Hibernator-Bereitstellung umfassen.
-
Bei 566 kann das Verfahren 560 das Bestimmen durch die Hibernator-Bereitstellung umfassen, wann Anwendungen in der Liste der Anwendungen inaktiv sind. Beispielsweise kann festgestellt werden, dass die Anwendung inaktiv ist, wenn während eines in der Semantik definierten vorgegebenen Zeitraums, wie beispielsweise zehn (10) Minuten, keine Clientanforderungen für die Anwendung eingegangen sind. Andererseits kann festgestellt werden, dass die Anwendung aktiv und daher nicht inaktiv ist, wenn während des vorbestimmten Zeitraums eine oder mehrere ClientAnforderungen für die Anwendung eingegangen sind.
-
Bei 568 kann das Verfahren 560 das Bestimmen durch die Hibernator-Bereitstellung umfassen, die Anwendung vom aktiven Zustand in den inaktiven Zustand zu übertragen, wenn festgestellt wird, dass die Anwendung inaktiv ist. Um die Anwendung vom aktiven in den inaktiven Zustand zu übertragen, kann die Hibernator-Bereitstellung die Replikatsätze der Anwendung von einem aktuellen Wert auf Null verkleinern oder reduzieren. Replikatsätze bieten Redundanz, indem sie mehrere Versionen einer Anwendung bereitstellen, sodass Probleme vermieden werden können, wenn eine oder mehrere Versionen der Anwendung fehlschlagen. Durch die Verwendung mehrerer Replikatsätze oder Versionen eines Containers kann der Datenverkehr einfacher an verschiedene Instanzen oder Container gesendet werden, um eine Überlastung einer einzelnen Instanz oder eines einzelnen Pods zu verhindern.
-
Bei 570 kann das Verfahren 560 das Ändern einer Dienstrichtlinie für die Anwendung durch die Hibernator-Bereitstellung während der Übertragung der Anwendung vom aktiven Zustand in den inaktiven Zustand umfassen, so dass der Dienstendpunkt der Anwendung vom Hibernator übertragen wird Bereitstellung von der Position an den Pods, die der Anwendung zugeordnet sind, bis zur Bereitstellung im Ruhezustand. Infolgedessen wird jede nachfolgende Anforderung zum Zugriff auf die Anwendung, die empfangen wird, während sich die Anwendung im inaktiven Zustand befindet, bei der Bereitstellung des Ruhezustands und nicht an den Pods beendet und daher von der Bereitstellung des Ruhezustands erkannt.
-
Bei 572 kann das Verfahren 560 das Übertragen von Paketen aus API-Interaktionen zwischen dem Masterknoten und den Arbeiterknoten in Bezug auf die Anwendung, die auf die Hibernator-Bereitstellung übertragen werden sollen, durch die Hibernator-Bereitstellung umfassen, anstatt auf die Pods, wenn die Anwendung an den übertragen wird inaktiver Zustand. Die Hibernator-Bereitstellung kann dann den Service-Port im Namen der Ruhezustand-Anwendung überwachen. Wenn die Hibernator-Bereitstellung ein oder mehrere eingehende Pakete für die Anwendung empfängt, kann die Hibernator-Bereitstellung das eingehende Paket oder die eingehenden Pakete für die Anwendung während der Anwendung speichern ist im inaktiven Zustand.
-
6 ist ein Flussdiagramm eines beispielhaften Verfahrens 670 zum Übertragen einer Anwendung von einem inaktiven Zustand in einen aktiven Zustand, das mit der vorliegenden Offenbarung übereinstimmt. Bei 672 kann das Verfahren 670 umfassen, während sich die Anwendung im inaktiven Zustand befindet, dass die Hibernator-Bereitstellung den Service-Port der Anwendung überwacht und bestimmt, wann eine Anforderung zum Zugriff auf die Anwendung am Service-Port empfangen wird. Bei 674 kann das Verfahren 670 umfassen, dass, sobald eine Anforderung zum Zugriff auf die Anwendung am Service-Port für die Anwendung von der Hibernator-Bereitstellung empfangen wurde, die Hibernator-Bereitstellung die Anwendung vom inaktiven Zustand in den aktiven Zustand überträgt.
-
Um beispielsweise die Anwendung von dem inaktiven Zustand in den aktiven Zustand bei 674 zu übertragen, kann die Hibernator-Bereitstellung Replikatsätze der Anwendung von dem verkleinerten Wert skalieren, der zum Übertragen der Anwendung vom aktiven Zustand in den inaktiven Zustand verwendet wird. dh Null zum Beispiel auf ihren Anfangswert, der von der Anwendung verwendet wird, wenn sich die Anwendung im aktiven Zustand befindet. Bei 676 kann das Verfahren 670 den Dienstendpunkt der Anwendung enthalten, die von der Hibernator-Bereitstellung von einem Standort in der Hibernator-Bereitstellung zu einem Standort in den Pods der Arbeitsknoten mit Containern überführt wird, die Dienste enthalten, die der Ausführung der Anwendung zugeordnet sind.
-
Bei 678 kann das Verfahren 670 während der Übertragung der Anwendung vom inaktiven Zustand in den aktiven Zustand die Hibernator-Bereitstellung umfassen, die die Pakete überträgt, die von der Hibernator-Bereitstellung gespeichert wurden, während sich die Anwendung 340 im inaktiven Zustand befand, zu den Pods, für die sie verwendet wurde Erstellen der Anwendungen, dh Pods der Arbeitsknoten mit Containern, die Dienste enthalten, die mit der Ausführung der Anwendung verbunden sind. Die übertragenen Pakete können dann für den wieder aufgenommenen Prozess der Anwendung verwendet werden.
-
Sobald die Anwendung vom inaktiven in den aktiven Zustand versetzt wird, werden nachfolgende Anforderungen, die für den Zugriff auf die Anwendung empfangen werden, an den Pods der Arbeitsknoten mit Containern beendet, die Container enthalten, die Dienste enthalten, die mit der Ausführung der Anwendung verbunden sind, und nicht um die Hibernator-Bereitstellung. Darüber hinaus werden Pakete von API-Interaktionen zwischen dem Masterknoten und den Arbeitsknoten, die sich auf die Anwendung beziehen, wieder an den Pods der Arbeitsknoten mit Containern empfangen, die Dienste enthalten, die mit der Ausführung der Anwendung verbunden sind, sobald die Anwendung von der inaktiven übertragen wird Status in den aktiven Status durch die Hibernator-Bereitstellung.
-
In der vorstehenden detaillierten Beschreibung der vorliegenden Offenbarung wird auf die beigefügten Zeichnungen Bezug genommen, die einen Teil davon bilden und in denen zur Veranschaulichung gezeigt ist, wie Beispiele der Offenbarung praktiziert werden können. Diese Beispiele werden ausreichend detailliert beschrieben, um es dem Durchschnittsfachmann zu ermöglichen, die Beispiele dieser Offenbarung zu praktizieren, und es versteht sich, dass andere Beispiele verwendet werden können und dass prozess-, elektrische und / oder strukturelle Änderungen vorgenommen werden können ohne vom Umfang der vorliegenden Offenbarung abzuweichen.
-
Die Figuren hier folgen einer Nummerierungskonvention, bei der die erste Ziffer der Zeichnungsfigurennummer entspricht und die verbleibenden Ziffern ein Element oder eine Komponente in der Zeichnung identifizieren. Elemente, die in den verschiedenen Figuren hier gezeigt sind, können hinzugefügt, ausgetauscht und / oder eliminiert werden, um eine Anzahl zusätzlicher Beispiele der vorliegenden Offenbarung bereitzustellen. Darüber hinaus sollen der Anteil und der relative Maßstab der in den Figuren bereitgestellten Elemente die Beispiele der vorliegenden Offenbarung veranschaulichen und sollten nicht in einem einschränkenden Sinne verstanden werden.
