Umgangssprache. Das sind Wörter und Redewendungen mit einer ganz eigenen lokalen Bedeutung, die Menschen von außerhalb vor Rätsel stellen können. Wenn ich zum Beispiel unterwegs bin und Durst habe, halte ich nach einem „Bubbler“ Ausschau. Sie hingegen suchen wahrscheinlich nach einem Trinkbrunnen (ich nehme an, Sie sind kein „Sconnie“). In Wisconsin messen wir Entfernungen in Zeit, nicht in Meilen. Ampeln heißen bei uns „Stop-and-go“-Lichter. Weil man dort eben genau das tut.
Am liebsten macht sich mein Mann (er stammt nicht von hier) über „C’mere once“ lustig. Ich werde gar nicht erst versuchen, es zu erklären – für mich und die Kinder, zu denen ich das sage, ergibt es einfach Sinn. Und wir verstehen ganz selbstverständlich, dass „Up North“ keine Himmelsrichtung bezeichnet, sondern einen Ort, dessen genaue Lage zwar vom jeweiligen Sprecher abhängen mag, der aber für alle gebürtigen Wisconsiner dieselbe Bedeutung hat: „der Ort, an den wir fahren, um dem Alltag zu entfliehen“.
Da du anderswo aufgewachsen bist, hast du wahrscheinlich deine eigene Liste. Aber das hier ist mein Blog, also darf ich meine verwenden.
Heute geht es jedoch nicht um eine Lektion in Semantik an sich, sondern vielmehr darum, wie sie sich auf ein stärker lokal begrenztes Phänomen direkt vor Ihrer eigenen Haustür anwenden lässt – zumindest, wenn mit Ihrer Haustür Ihre Organisation gemeint ist.
Der Aufstieg von Containern und den dafür unerlässlichen automatisierten Systemen zur Cluster-Steuerung (oft als Orchestrierung bezeichnet) hatte die unbeabsichtigte Folge, dass umgangssprachliche Begriffe von der einen Seite der Grenze auf die andere gelangten. Gemeint ist übrigens der Übergang von der Anwendungsentwicklung in die eigentliche IT.
Der kuriose Fall der Container-Umgangssprache
Viele der Funktionen, die für die erforderliche Flexibilität und Zuverlässigkeit bei der Skalierung benötigt werden, haben dazu geführt, dass bestimmte Dienste, die zuvor ausschließlich in Produktionsumgebungen eingesetzt wurden, in die Container-„Umgebung“ migriert wurden. Diese Funktionen sind nun offenbar fest in diese Umgebung „integriert“ und ermöglichen mithilfe leichtgewichtiger Integrationsmechanismen (APIs und Message Queuing), was bislang nur mit einer vollständig implementierten Cloud-Computing-Umgebung realisierbar war: automatische Skalierung und hochverfügbare Anwendungen.
Dadurch sind die Load-Balancing-Funktionen über kleine, daemonähnliche Dienste direkt in die Pods bzw. Nodes integriert. Sie sind zwar nicht besonders ausgereift (ihre Fähigkeiten gehen kaum über die eines Netzwerk-Load-Balancings hinaus), erfüllen aber den Zweck, für den sie entwickelt wurden. Diese Dienste lassen sich gewissermaßen durch Plug-ins erweitern – und werden auch so eingesetzt. Dadurch können andere Projekte (Open Source oder von Anbietern bereitgestellt) fortschrittlichere Funktionen und – so bleibt zu hoffen – Algorithmen ermöglichen.
Für sich genommen ermöglichen diese Lastverteilungsfunktionen jedoch weder die Skalierbarkeit noch die Hochverfügbarkeit, die wir letztlich anstreben (und in Produktionsumgebungen benötigen). Auch sind sie nicht in der Lage, APIs zu routen – dafür ist HTTP-Intelligenz auf Layer 7 erforderlich. Diese benötigen wir, um moderne Anwendungen, die auf Microservices basieren und über API-Fassaden bereitgestellt werden, effizient horizontal skalieren zu können. Wir brauchen eine robustere Lösung.
Hier kommen Ingress-Controller ins Spiel. Dabei handelt es sich um „Load Balancer“, die den eingehenden Ingress-Datenverkehr anhand von URIs und HTTP-Headern analysieren und weiterleiten, um Routing und Skalierbarkeit auf Anwendungsebene zu ermöglichen.
Im Grunde haben die Entwickler, die Ingress-Controller entwickelt haben (und anschließend verwenden), das neu geschaffen, was wir im Netzwerkbetrieb als Traffic-Management, Anwendungsbereitstellung oder Content-Switching/-Routing bezeichnen würden. Im Laufe der Jahre haben wir im Netzwerkbetrieb viele verschiedene Begriffe verwendet, ebenso wie die Kollegen im Bereich Dev(Oops). App-Routing und Seiten-Routing sind weitere Begriffe, mit denen Entwickler das L7-Routing beschreiben. Das Konzept ist beiden Gruppen vertraut. Die Begriffe – die umgangssprachlichen Bezeichnungen – hingegen nicht.
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 weiteren Load-Balancing-Proxy oder um ein containersystemspezifisches Konstrukt handeln. In beiden Fällen besteht die Aufgabe des Ingress-Controllers darin, den Datenverkehr anhand von Werten der Schicht 7 (HTTP) in den HTTP-Headern einer HTTP-Anfrage weiterzuleiten. In der Regel ist dies der URI, es könnte aber auch der Hostname oder ein anderer benutzerdefinierter Wert (wie eine Versionsnummer oder ein API-Schlüssel) sein.
Sobald der Ingress-Controller den Wert aus dem Header extrahiert hat, bestimmt er anhand der in Ressourcendateien beschriebenen Richtlinien, wie die Anfragen verteilt werden. Er kann sie gleichmäßig verteilen oder 75 % an eine Version des Dienstes und 25 % an eine andere senden. In dieser Hinsicht ist er ziemlich flexibel. Der Ingress-Controller ist außerdem für die Überwachung von Funktionsfähigkeit und Status zuständig und muss sorgfältig darauf achten, keine Anfrage an einen „ausgefallenen“ Dienst weiterzuleiten.
Kommt Ihnen das bekannt vor, NetOps? Das sollte es, denn im Grunde sind das die Funktionen eines intelligenten (L7-fähigen) Proxys (wie BIG-IP).
Nachdem Sie nun wissen, worin die Gemeinsamkeiten bestehen, kann ich Ihnen versichern, dass es auch 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 festgelegt. Dies unterscheidet sich von herkömmlichen intelligenten Proxys, die den eingehenden Datenverkehr steuern und weiterleiten. Herkömmliche intelligente Proxys sind maßgebliche Informationsquellen für die Umgebung. Ein Ingress-Controller ist das nicht. Er bezieht diese Informationen stattdessen aus Dateien, die als eine Art „Abstraktionsschicht“ dienen und flexible Implementierungen ermöglichen. Das bedeutet, dass er (oder eine ergänzende Komponente) diese Dateien lesen und interpretieren sowie die der Beschreibung entsprechende Konfiguration erstellen muss. Außerdem muss er sie auf dem neuesten Stand halten. Zwar ist die Variabilität bei der Ingress-Steuerung einer containerisierten Umgebung geringer als in tieferen Ebenen des Systems, dennoch treten auch dort Änderungen auf, die überwacht werden müssen.
Letztendlich ist der Ingress-Controller dafür verantwortlich, Anfragen von außen auf Anwendungsebene an die entsprechende Ressource innerhalb der containerisierten Umgebung weiterzuleiten. Das entspricht ziemlich genau der Definition eines intelligenten Load Balancers.
Der Name mag sich geändert haben, doch die Funktionen sind weitgehend gleich geblieben.
Über den Autor
Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.
Weitere Blogbeiträge von Lori Mac VittieÄhnliche Blogbeiträge
F5 und Equinix bündeln ihre Kräfte, um die sichere Anwendungsbereitstellung in Multicloud-Umgebungen zu vereinfachen
F5 und Equinix ermöglichen es Unternehmen, sich weltweit sicher und zuverlässig mit ihren Partnern zu vernetzen.
API-Sicherheitsrisiken und -herausforderungen
Erfahren Sie, warum APIs für die moderne App-Entwicklung unverzichtbar sind und wie Sie sie vor den häufigsten Sicherheitslücken schützen. Profitieren Sie von Expertentipps und direkt umsetzbaren Strategien.
Ein Meilenstein für die Community Impact Grants von F5
F5 feiert das fünfjährige Bestehen seines innovativen Community Impact Grant-Programms, das gemeinnützige Organisationen, bei denen sich F5-Mitarbeitende ehrenamtlich engagieren, mit Fördermitteln in Höhe von 5.000 US-Dollar unterstützt.
Mit moderner, anpassungsfähiger und sicherer Gesundheits-IT Leben retten
Die IT-Investitionen im Gesundheitswesen tragen dazu bei, die schnellsten Wege zu einer besseren Versorgung zu finden, indem sie die medizinische Betreuung näher an die Patientinnen und Patienten bringen. Viele Gesundheitsunternehmen nutzen riesige Mengen an klinischen und anderen Gesundheitsdaten, um Entwicklungen zu verfolgen und übergreifende Trends in der gesamten Gesundheitslandschaft zu erkennen. Gleichzeitig nähern sie sich einer möglichst präzisen, individuell zugeschnittenen Versorgung an.
Verbesserung der Benutzer- und Administrationserfahrung durch sicheren hybriden Zugriff
Diese Kombination aus BIG-IP Access Policy Manager und Azure Active Directory ermöglicht Identitätsföderation, zentralisierten Benutzerzugriff (über Single Sign-on) und erhöhte Anwendungssicherheit (durch Multi-Faktor-Authentifizierung) für geschäftskritische Anwendungen sowie cloudbasierte und SaaS-Anwendungen. Dieser Ansatz vereinfacht die Einrichtung und Bereitstellung, reduziert den Verwaltungsaufwand und verbessert die gesamte Administration.
Das Internet der Sicherheitsdinge
Nein, das ist keine Tirade über die Sicherheit des IoT. Es ist eine Geschichte über Veränderung – genauer gesagt über Veränderung und ihre Auswirkungen auf die Sicherheit. Veränderung ist allgegenwärtig. Es gibt unzählige Axiome und Sprichwörter über Veränderung, also ist es ...