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, verwendet er in den Ressourcendateien beschriebene Richtlinien, um zu bestimmen, wie der Wert verteilt werden soll. Es kann eine gleichmäßige Verteilung erfolgen oder 75 % an eine Version des Dienstes und 25 % an eine andere gesendet werden. Auf diese Weise ist es ziemlich flexibel. Der Ingress-Controller ist außerdem für die Überwachung (Integrität und Status) zuständig und muss sehr vorsichtig sein, dass er eine Anforderung nicht an einen „toten“ Dienst weiterleitet.

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).

Nachdem Sie nun wissen, inwiefern sie sich ähneln, kann ich Ihnen versichern, dass es einige Unterschiede gibt. Insbesondere wird ein Ingress-Controller deklarativ konfiguriert. Das heißt, seine Konfiguration wird durch eine Beschreibung in einer Ressourcendatei außerhalb des Controllers selbst bestimmt. Dies ist nicht wie bei herkömmlichen intelligenten Proxys, die eingehenden Datenverkehr steuern und leiten. Herkömmliche Smart-Proxys sind maßgebliche Quellen der Umgebung. Ein Ingress-Controller ist das nicht. Dafür sucht es woanders, in Dateien, die als eine Art „Abstraktionsschicht“ fungieren, die Flexibilität bei Implementierungen ermöglicht. Das bedeutet, dass es (oder eine ergänzende Komponente) die Beschreibung lesen, interpretieren und die entsprechende Konfiguration erstellen muss. Und es muss auf dem neuesten Stand gehalten werden. Während die Variabilität bei der Eingangskontrolle einer Containerumgebung geringer ist als tiefer im System, ändert sie sich dennoch und muss im Auge behalten werden.

Letztendlich ist der Ingress-Controller für das Routing von Anfragen von außen auf Anwendungsebene an die entsprechende Ressource innerhalb der Containerumgebung verantwortlich. Das ist so ziemlich die Definition eines intelligenten Lastenausgleichs.

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