Ingress-Controller: Neuer Name, vertraute Funktion

Umgangssprache. Dabei handelt es sich um Wörter und Ausdrücke mit einer einzigartigen lokalen Bedeutung, die für Ortsfremde verwirrend sein kann. Wenn ich beispielsweise unterwegs bin und Durst habe, suche ich nach einem Sprudler. Sie suchen wahrscheinlich (ich vermute, Sie sind kein „Sconnie“) nach einem Springbrunnen. In Wisconsin messen wir Entfernungen in Zeit, nicht in Meilen. Ampeln sind „Stop-and-Go“-Ampeln. Denn das ist, was Sie tun.

Mein Mann (er ist kein Muttersprachler) lacht am liebsten über „Komm her!“. Ich werde nicht versuchen, es weiter zu erklären, als es für mich und die Kinder, bei denen ich es verwende, Sinn ergibt. Und uns ist klar, dass „Up North“ keine Richtung ist, sondern ein Ort, dessen Lage für den Sprecher zwar spezifisch sein mag, der aber eine gemeinsame Konnotation für jeden Einheimischen in Wisconsin hat, der beschreibt, „wohin wir gehen, um allem zu entfliehen“.

Da Sie woanders aufgewachsen sind, haben Sie wahrscheinlich Ihre eigene Liste. Aber dies ist mein Blog, also darf ich meines verwenden.

Heute geht es allerdings nicht um eine Lektion in Semantik an sich, sondern eher um ihre Anwendbarkeit auf ein eher lokales Phänomen direkt vor Ihrer Haustür. Zumindest, wenn Ihr Hinterhof Ihre Organisation wäre.

Der Aufstieg der Container und ihrer notwendigen automatisierten Cluster-Kontrollsysteme (oft als Orchestrierung bezeichnet) hatte die unbeabsichtigte Folge, dass Umgangssprache von einer Seite der Staatsgrenze auf die andere verlagert wurde. Das ist übrigens die eigentliche App-Entwicklung in der IT.

Der seltsame Fall der Container-Umgangssprache

Viele der Funktionen, die zum Erreichen der geforderten Flexibilität und Skalierbarkeit erforderlich sind, erforderten die Migration bestimmter, bislang nur für die Produktion verfügbarer Dienste in die Containerumgebung. Diese Funktionen sind nun scheinbar in diese Umgebung „eingebrannt“ und nutzen eine leichte Integration (APIs und Nachrichtenwarteschlangen), um das zu erreichen, was bisher nur in einer vollständig implementierten Cloud-Computing-Umgebung realisiert werden konnte: automatisch skalierende, hochverfügbare Anwendungen.

Dabei werden Lastausgleichsfunktionen über kleine, daemonähnliche Dienste nativ in die Pods/Knoten integriert. Sie sind zwar nicht hochentwickelt (wir sprechen hier von Fähigkeiten, die kaum über Netzwerklastausgleich hinausgehen), aber sie erfüllen den Job, für den sie entwickelt wurden. Diese Dienste können (und sind) steckbar, wenn Sie so wollen, und ermöglichen so andere Projekte (Open Source und vom Anbieter bereitgestellt), die erweiterte Funktionen (und, so hofft man, auch Algorithmen) freischalten.

Aber diese Lastausgleichsfunktionen allein ermöglichen nicht die Skalierbarkeit und Hochverfügbarkeit, die wir letztendlich suchen (und in Produktionsumgebungen benötigen). Sie sind auch nicht in der Lage, APIs zu routen, wofür die intelligente HTTP-Funktion (L7) erforderlich ist. Das ist erforderlich, wenn wir moderne Anwendungen, die auf Microservices basieren und über API-Fassaden verfügen, effizient skalieren möchten. Wir brauchen eine robustere Lösung.

Hier kommen Ingress-Controller ins Spiel. Dabei handelt es sich um die „Load Balancer“, die den eingehenden Datenverkehr anhand von URIs und HTTP-Headern aufschlüsseln und weiterleiten, um Routing und Skalierbarkeit auf Anwendungsebene zu ermöglichen.

Was passiert ist, ist, dass die Entwickler, die Ingress-Controller erstellt haben (und anschließend verwenden), im Grunde neu erstellt haben, was wir (in Netops) als Verkehrsmanagement, Anwendungsbereitstellung oder Inhaltsumschaltung/-weiterleitung bezeichnen würden. Wir haben im Laufe der Jahre bei Netops viele verschiedene Begriffe verwendet, ebenso wie bei Dev(ops). App-Routing und Seiten-Routing sind weitere Begriffe, die Entwickler zur Beschreibung des L7-Routings verwendet haben. Das Konzept ist keiner der beiden Gruppen unbekannt. Aber die Begriffe – die Umgangssprache – sind es.

Ein Ingress-Controller hat die Aufgabe, Anfragen an den entsprechenden (virtuellen) Dienst innerhalb des Container-Clusters weiterzuleiten. Bei diesem Dienst kann es sich um einen anderen Proxy zum Lastenausgleich oder um eine containersystemspezifische Konstruktion handeln. In beiden Fällen besteht die Rolle des Ingress-Controllers darin, den Datenverkehr basierend auf Layer-7-Werten (HTTP) innerhalb der HTTP-Header einer HTTP-Anforderung weiterzuleiten. Normalerweise ist dies die URI, es könnte jedoch auch der Hostname oder ein anderer benutzerdefinierter Wert (z. B. eine Versionsnummer oder ein API-Schlüssel) sein.

Nachdem der Ingress-Controller den Wert aus dem Header extrahiert hat, nutzt er Richtlinien aus den Ressourcendateien, um die Verteilung zu steuern. Er kann die Verteilung gleichmäßig vornehmen oder 75 % an eine Serviceversion und 25 % an eine andere senden. So bietet er Ihnen eine hohe Flexibilität. Außerdem überwacht der Ingress-Controller den Zustand und die Verfügbarkeit und sorgt dafür, dass keine Anfragen an ausgefallene Dienste weitergeleitet werden.

Kommt Ihnen das bekannt vor, Netops? Das sollte es, denn das sind grundsätzlich die Funktionen eines intelligenten (L7-fähigen) Proxys (wie BIG-IP).

Jetzt, da Sie wissen, worin sie sich ähneln, versichere ich Ihnen, dass es auch Unterschiede gibt. Insbesondere konfigurieren Sie einen Ingress-Controller declarativ. Seine Konfiguration bestimmt eine Beschreibung in einer Ressourcendatei außerhalb des Controllers selbst. Das funktioniert nicht wie bei herkömmlichen Smart-Proxys, die den eingehenden Datenverkehr steuern und lenken. Herkömmliche Smart-Proxys gelten als autoritäre Quellen der Umgebung. Einen Ingress-Controller sehen Sie anders. Er sucht externe Dateien auf, die als eine Art „Abstraktionsschicht“ dienen und Flexibilität bei der Umsetzung ermöglichen. Sie oder eine ergänzende Komponente müssen diese Dateien lesen, interpretieren und eine passende Konfiguration daraus erstellen. Und Sie halten die Konfiguration stets aktuell. Obwohl sich die Kontrolle am Eingang einer containerisierten Umgebung weniger verändert als in tieferen Systembereichen, müssen Sie auch diese Änderungen beobachten.

Im Kern steuert der Ingress-Controller die Anforderungsweiterleitung auf Anwendungsebene von außen zur passenden Ressource innerhalb der containerisierten Umgebung. Damit ist er im Grunde ein intelligenter Lastenausgleich.

Der Name hat sich möglicherweise geändert, die Funktionen bleiben jedoch weitgehend dieselben.