Der Container-Umgangssprachübersetzer für NetOps

Es gibt Tage, da schwirrt einem der Fachjargon aus der Containerwelt den Kopf. Mit jeder neuen Fähigkeit oder Funktion, die von verwandten Lösungen (Service Mesh, Orchestratoren, Registern) angeboten wird, scheint ein neuer Begriff oder eine neue Phrase erforderlich zu sein. Für DevOps ist dieser Satz oft sinnvoll, ruft bei NetOps jedoch einen schielenden, verwirrten Gesichtsausdruck hervor.

So ähnlich wie der Satz, den Sie machen, wenn ich frage, wo der nächste Sprudler ist. Sie nennen es einen Springbrunnen. In Wisconsin nennen wir es einen Bubbler. Dasselbe, anderer Begriff.

Es stellt sich heraus, dass viele der „neuen“ Fähigkeiten und Funktionen im Zusammenhang mit der internen Skalierung von Containern und in Multi-Cloud-Szenarien eigentlich nur Wasserfontänen sind, die DevOps als „Bubbler“ bezeichnet. Dieser Zusammenprall der Umgangssprache kann zu Reibereien mit NetOps führen, da Container weiterhin unvermindert in den Mainstream vordringen. Auch wenn Container-Cluster in der Produktion ein isoliertes, Mini-Cloud-ähnliches Dasein fristen, gibt es dennoch Berührungspunkte mit dem Unternehmensnetzwerk, über das weiterhin NetOps herrscht. Und um diese Cluster in einer Multi-Cloud-Welt sicher zu skalieren, müssen NetOps und DevOps ausnahmslos zusammenarbeiten.

Ingress-Controller

• Wie bereits erwähnt , verleiht der Begriff „Ingress Controller“ dem Lastenausgleich auf Ebene 7 (Content Switching, Content Routing usw.) einen neuen Anstrich. Ein Ingress-Controller ist ein Layer-7-(HTTP)-fähiger Proxy, der Anfragen an die entsprechende Ressource innerhalb eines Container-Clusters weiterleitet.  Der wesentliche Unterschied zwischen den von NetOps im Netzwerk verwendeten HTTP-Proxys und denen, die als Einstiegspunkte zu Container-Clustern dienen, besteht darin, dass ein Ingress-Controller Container-fähig sein muss. Mit „containerbewusst“ meine ich, dass es automatisch auf Grundlage von Änderungen konfiguriert und verwaltet wird, die in der Container-Umgebung stattfinden – insbesondere auf Grundlage der Ressourcendatei, die beschreibt, wie der Ingress eingehende Anfragen weiterleiten soll.

Latenzbewusster Lastenausgleich

• Klingt cool und frisch, nicht wahr? Aber wenn Sie den Kimono zurückziehen, wird NetOps nachdrücklich nicken, wenn Sie feststellen, dass es sich hierbei eigentlich um nichts anderes handelt als um die Nutzung eines Lastausgleichsalgorithmus mit der „schnellsten Reaktion“. Die Absicht besteht darin, die App-Leistung zu verbessern, indem „ Verkehr von langsamen Instanzen weg verlagert wird “. Der Grund hierfür liegt darin, dass die von Container-Orchestratoren verwendeten nativen Lastausgleichsalgorithmen im Allgemeinen apathisch sind. Round Robin ist so ziemlich der Standard und unserer Kenntnis nach der letzte Algorithmus, den Sie wählen sollten, wenn Sie die Leistung optimieren möchten. Die Möglichkeit, Anfragen basierend auf der besten Leistung weiterzuleiten, ist ziemlich wichtig, wenn man bedenkt, dass jeder Microservice-Microservice-Aufruf zur Erfüllung einer einzelnen Client-Anforderung seine eigene Latenz verursacht.

Multi-Cluster-Ingress

• Ich möchte zunächst sagen, dass dies viel cooler klingt als der Begriff, den die Branche seit fast zwanzig Jahren verwendet. Im Wesentlichen ist dies GSLB (Global Server Load Balancing). Ja, ich weiß, Sie sind enttäuscht, aber unter der Haube passiert genau das beim Multi-Cluster-Ingress . Sie nehmen einen Ingress-Controller, streuen etwas globales Verkehrsmanagement darum herum und voilà! Sie haben GSLB für Containercluster in einer Multi-Cloud-Konfiguration. Ich stimme dafür, GSLB auf der NetOps-Seite durch diesen Begriff zu ersetzen, weil es einfach beeindruckender klingt.

Dies sind nicht die einzigen Begriffe, die auftauchen, und auch nicht die letzten. Sie sind im Hinblick auf die Funktionalität und Fähigkeiten „im Netzwerk“, die von DevOps erfasst werden, am relevantesten. Einige davon werden die Aufmerksamkeit von NetOps erfordern, wenn sie in Produktionsumgebungen verlagert werden (wie Multi-Cluster-Ingress), andere nicht. Latenzbewusstes Lastenausgleich in Containerumgebungen wird wahrscheinlich weiterhin in der Zuständigkeit von DevOps bleiben, obwohl es gut ist, bei Diskussionen über die Verbesserung der Leistung oder Verfügbarkeit ein Verständnis dafür zu haben.

DevOps hat eine kulturelle Komponente, die oft übersehen oder völlig ignoriert wird. Da die Bewegung weiterhin ihre Spuren im NetOps-Bereich hinterlässt und der traditionelle Netzwerkbetrieb langsam aber sicher ihre Prinzipien übernimmt, um ein agiles Netzwerk zu erreichen, wird die Kommunikation von entscheidender Bedeutung. Das bedeutet, einen gemeinsamen Nenner zu finden. Das Verständnis des Fachjargons des anderen kann ein guter erster Schritt zum Aufbau einer stärker kollaborativen Kultur sein, die erforderlich ist, um sicherzustellen, dass die Application genauso schnell, sicher und zuverlässig ist wie ihre Lieferung.