Auswirkungen von Container-Orchestrierungsumgebungen auf die Integritätsüberwachung

Im Mittelpunkt der Verfügbarkeit steht die Überwachung. Jeder Load Balancer muss – bevor er eine Zielressource auswählt – wissen, ob diese Ressource tatsächlich verfügbar ist oder nicht. Was hätte es sonst für einen Sinn?

In Umgebungen, in denen die Lebensdauer von Ressourcen eher in Minuten als in Stunden oder Tagen gemessen wird, ist es umso wichtiger, den Status der Ressourcen zu kennen, bevor entschieden wird, ob eine Anforderung an sie gesendet wird.

Die Integritätsüberwachung ist ein wesentlicher Bestandteil von Load Balancern und Proxys. Dies gilt (oder sollte zumindest gelten) auch für Containerumgebungen. Während diese Umgebungen (schnell) immer ausgereifter werden, entstehen neue Überwachungsmodelle, um die recht einzigartigen Herausforderungen zu bewältigen, die mit derartigen hochvolatilen, verteilten Systemen verbunden sind.

Die herkömmliche Integritätsüberwachung ist sicherlich ein Teil der Gleichung, aber einige Modelle der Verfügbarkeit und Skalierung in Containerumgebungen stellen eine Belastung für die herkömmliche Integritätsüberwachung dar, die angegangen werden muss. Beispielsweise wird von Proxys, die in einem Forward-Proxy-Modell eingesetzt werden, erwartet, dass sie in der Lage sind, aus allen möglichen Diensten ein fehlerfreies (verfügbares) Ziel auszuwählen. Während ein Reverse-Proxy (wenn man so will, ein herkömmlicher Load Balancer) nur für die Statusverfolgung eines ganz bestimmten Satzes von Diensten für eine einzelne Anwendung zuständig ist, ist ein Forward-Proxy dafür zuständig, den Status jedes Dienstes für jede Anwendung in der Umgebung zu kennen. Denn das Senden einer Anfrage an einen bereits außer Betrieb befindlichen Container wäre nicht gut, okay?

Traditionelle Gesundheitsüberwachung

Traditionell wird die Integritätsüberwachung durch einen Proxy auf zwei Arten durchgeführt:

• Aktive Überwachung: Senden von Probe- oder Integritätsprüfungsanfragen an Container und Auswerten ihrer Antworten.
• Passives Monitoring: Beobachten Sie natürliche Kundenanfragen und die Antworten darauf.

Sie können sich vorstellen, dass die aktive Überwachung durch jeden Forwardproxy jedes Dienstes den Datenverkehr im lokalen Netzwerk ziemlich drastisch erhöht und unnötig Ressourcen verbraucht. Eine sinnvolle Überwachung erfolgt zumindest auf der TCP- und idealerweise auf der HTTP-Ebene. Schließlich ist die Netzwerkkonnektivität kein Indikator für die Integrität oder Verfügbarkeit eines Dienstes. Die Nutzung von TCP-Verbindungen und die erforderliche HTTP-Verarbeitung belasten Container schnell, wenn die Anzahl der Knoten (und damit der Weiterleitungsproxys) zunimmt. Sie möchten nicht hochskalieren müssen, weil die Container durch die Überwachung überlastet sind.

Passives Monitoring ist in diesem Fall die bessere Option, da es das überwachte System nicht belastet, in manchen Containerumgebungen hat es allerdings seine Grenzen. Viele basieren auf Overlay-Networking-Prinzipien, die es schwierig machen, sicherzustellen, dass jeder Proxy jede Serviceantwort sehen und verfolgen kann. Nicht unmöglich, aber auf der Netzwerkebene eine Herausforderung.

Beide Modelle belasten auch den Proxy selbst, da die Ressourcen lediglich für die Überwachung der Umgebung eingesetzt werden müssen und nicht für die eigentliche Aufgabe: die Skalierung von Diensten.

Containerisierte Integritätsüberwachung 

Containerumgebungen sind sich dieser Herausforderungen bewusst. Als Reaktion hierauf sehen wir die Entstehung von zwei neuen Modellen, die sicherlich dazu beitragen werden, die Verfügbarkeit in Architekturen sicherzustellen, die Forward-Proxys für Verfügbarkeit und Skalierbarkeit einsetzen.

Diese beiden Modelle sind:

• Umweltüberwachung: Proxys sind sich dank Informationen aus der Container Orchestration Environment (COE) über den Zustand/die Verfügbarkeit der Container bewusst.
• Gemeinsame Überwachung: Da in einer Umgebung wahrscheinlich viele Proxys vorhanden sind, kann die Überwachungsarbeit auf mehrere Proxys aufgeteilt und die Ergebnisse gemeinsam genutzt werden.

Die Umweltüberwachung wird häufig mit der Serviceregistrierung in Verbindung gebracht, die Container beim Betreten und Verlassen des Systems verfolgt. Das bedeutet, dass es sich häufig um die zuverlässigste Quelle für die Containerverfügbarkeit im System handelt. Proxys können außerdem Ereignisse abonnieren, die durch die Erstellung und Zerstörung von Containern ausgelöst werden, um diese Ressourcen selbst zu verfolgen (und so selbst als Registrierungsstelle zu fungieren).

Wenn beispielsweise die Integritätsüberwachung für eine App in Marathon aktiviert ist, kann ein Proxy das Feld „healthCheckResults“ verwenden. In Kubernetes können Proxys Liveness- und/oder Bereitschaftsprüfungen verwenden. Durch Integritätsprüfungen der Umgebung können Proxys mit der Auswahl gesünderer Endpunkte beginnen, bevor das Orchestrierungssystem einen ungesunden Endpunkt neu startet.

Die gemeinsame Überwachung ist in Systemen mit Forward-Proxy-Modellen sehr sinnvoll, insbesondere in Systemen mit Service-Mesh-Grundlage wie Istio . Der mit dem Knoten verknüpfte Proxy kann durchaus den Zustand und die Verfügbarkeit der Container überwachen, für die er Anfragen weiterleitet (ähnlich wie er die Dienste in einem Reverse-Proxy-Modell verfolgen könnte). Sie möchten jedoch sicherlich nicht, dass jeder Proxy jeden Endpunkt in einem solchen System aktiv prüft. Durch das Teilen lokaler Gesundheitsinformationen mit anderen Proxys (oder noch besser mit der Umgebung) können alle Proxys den gesamten bekannten Zustand des Systems abrufen, ohne dass übermäßige Gesundheitsprüfungen für jeden Dienst erforderlich sind.

Im „Netzwerk“ finden viele Änderungen in Bezug auf App-Dienste statt, beispielsweise beim Lastenausgleich und der Art und Weise, wie diese interagieren, um die Bedürfnisse und Anforderungen neuer Modelle wie der Containerisierung zu erfüllen. Diese Anforderungen setzen Proxys ständig unter Anpassungsdruck. Das liegt daran, dass Proxys zu den flexibelsten Technologien gehören, die in den letzten zwanzig Jahren entwickelt wurden, und nach wie vor eine wichtige Grundlage für den Entwurf, die Entwicklung und die Bereitstellung von App-Diensten bilden.