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

Überwachung steht im Zentrum der Verfügbarkeit. Bevor ein Load Balancer eine Ziel-Serverressource auswählt, prüft er deren Verfügbarkeit. Ohne diese Prüfung macht das Ganze keinen Sinn.

In Umgebungen, in denen Ressourcen nur Minuten anstatt Stunden oder Tagen bestehen, müssen Sie vor dem Senden einer Anfrage unbedingt den Status dieser Ressourcen kennen.

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 sicher vorstellen, dass aktive Überwachung durch jeden Forward-Proxy jedes Dienstes den Datenverkehr im lokalen Netzwerk erheblich steigert und Serverressourcen unnötig belastet. Effektive Überwachung findet mindestens auf der TCP- und idealerweise auf der HTTP-Ebene statt. Netzwerkkonnektivität zeigt schließlich nicht zuverlässig die Gesundheit oder Verfügbarkeit eines Dienstes an. Der Aufbau von TCP-Verbindungen und die Verarbeitung von HTTP-Anfragen belasten Container schnell, wenn die Anzahl der Knoten (und damit der Forward-Proxys) zunimmt. Sie möchten nicht skalieren müssen, weil die Container durch die Überwachung überfordert 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 Sie Ressourcen darauf verwenden müssen, die Umgebung zu überwachen, statt sich auf die eigentliche Aufgabe zu konzentrieren: das Skalieren 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.

Umweltüberwachung ist häufig mit dem Service-Register verbunden, das Container beim Ein- und Austritt aus dem System verfolgt. So liefert es oft die zuverlässigsten Informationen zur Verfügbarkeit von Containern im System. Proxys können sich auch auf von Containern erzeugte Ereignisse beim Anlegen und Beenden abonnieren, um diese Ressourcen selbst im Blick zu behalten und dadurch praktisch selbst als Register 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.