Nachdem wir uns im ersten Blogbeitrag eine Übersicht zu der grundlegenden Struktur von Kubernetes-Clustern im Cloud-Native-Umfeld und im darauf folgenden die technischen Grundlagen zur Runtime näher angeschaut haben, wird es Zeit auf die nächste Ebene zu blicken. Das Layer “Orchestrierung & Management” ist der Einstiegspunkt für die meisten Anwender. Während die Runtime für den Betrieb von container-basierten Umgebungen wichtig ist, bildet dieses Layer die Grundlage für den Betrieb von Applikationen. Die Erklärungen zu den einzelnen Komponenten des Layers “Orchestrierung & Management” sind sehr komplex, weswegen wir die einzelnen Komponenten erklären werden. In diesem Beitrag schauen wir uns, neben der generellen Idee hinter zentralen Microservices, den Service Proxy einmal genauer an.
Zentrale Komponenten im dezentralen Umfeld
In Kubernetes können zentrale Komponenten für standardisierte Aufgaben in der Software-Architektur eingesetzt werden. So kann z. B. mit einem Service Proxy oder einem Service Mesh eine Software eingesetzt werden, welche globale Funktionsanforderungen erfüllt.
Die Verteilung von zentralen Aufgaben auf einzelne Komponenten ist dann erstrebenswert, wenn man dem Prinzip des “Separation of Concerns” fokussieren möchte. Es führt zu dedizierten Laufzeiten für Funktionen, welches den Microservice-Gedanken aufgreift und die Ausfallzeiten auf einzelne Komponenten beschränkt, anstatt auf die gesamte Applikation in einer einzelnen Laufzeitumgebung. Sie wird auf der anderen Seite aber auch in der Menge größer und damit unübersichtlich. Änderungen müssen mit mehr Bedacht eingepflegt werden, um sicherzustellen, dass bei einer Änderung – technisch wie menschlich – alle Nutzer und Abhängigkeiten bedacht werden.
Call all the things – die verschiedenen Service-Typen
Kommen wir zum ersten Thema mit Außenwirkung: Der Service Proxy. Endlich einmal eine Anwendung installieren. Die ganze Vorarbeit mit Lorbeeren schmücken. Doch wie erreichen wir das?
Wie im Beitrag Runtime bereits angesprochen, erzeugt Kubernetes ein Subnetz, in dem die interne Erreichbarkeit der Services gewährleistet wird. Eine externe Erreichbarkeit ist aber, abgesehen vom Kubernetes API Server, noch nicht vorhanden.
Kubernetes klassifiziert die Erreichbarkeit von Pods über den Typ eines Services:
- ExternalName,
- NodePort,
- LoadBalancer und
- ClusterIP.
Eine Übersicht könnte so aussehen:
Der Service vom Typ External Name dient dazu, Kubernetes-interne Aufrufe auf externe Services weiterzuleiten. Das ist z. B. für Authentifizierungssysteme, die nicht auf Kubernetes gehostet werden sollen, sinnvoll.
Ein Service vom Typ ClusterIP ist der Standardeintrag für die Erreichbarkeit von Diensten innerhalb von Kubernetes. Sie besitzen einen Cluster-internen DNS-Eintrag der durch die Komponente “Coordination & Service Discovery” gemanagt wird.
Interessanter für uns sind aber die Typen NodePort und Load Balancer. Beide bieten die Möglichkeit, einen direkten Aufruf von außen auf die Anwendung möglich zu machen. Der Unterschied ist tatsächlich in der Vererbung zu finden: Ein Load Balancer-Service, ist ein erweiterter Service vom Type NodePort, und ein NodePort-Service ein erweiterter Service vom Typ ClusterIP. Während aber der NodePort sich weiterhin den Grundressourcen des Kubernetes Clusters bedient (die IP ist in dem Fall eine beliebige VM-IP einer Node von Kubernetes), kann ein Load Balancer-Service durch eine FloatingIP selbstständiger agieren. Dafür wird meist ein tatsächlicher Load Balancer eingesetzt.
Making the LoadBalancer an Ingress
Damit nicht zu viele LoadBalancer erzeugt werden müssen (wer will schon für jede Applikation ein dedizierte IP?) kann man bereits hier eine zentrale Komponente wählen. Hier kommen die sogenannten Ingress-Controller ins Spiel.
Ein Ingress kann als ein Konfigurationseintrag in einem Reverse Proxy für Services gesehen werden. Auch hierfür gibt es Kubernetes-spezifische Ressourcen, die konfiguriert werden können. Der Ingress ermöglicht es, als zentrale Instanz mit dezentralen Konfigurationselementen die Anfragen an Applikationen zu verteilen und benötigt nur eine Cluster-externe Ressource.
NGINX ist bereits als Webserver und Reverse Proxy bekannt und stellt bei Kubernetes ebenfalls eine Version names nginx-ingress-controller zur Verfügung.
Der Aufwand hier zeigt sich in der Bereitstellung von Floating IPs, am besten automatisiert, und ist damit ebenfalls ein Thema aus dem Netzwerkbereich, der für einigen Aufwand sorgen kann.
Im ersten Schritt kann es für die ein oder andere Software-Architektur ein tiefer Einschnitt bedeuten. Deutlich wird es besonders in unserem nächsten Beitrag zum Thema Service Mesh. Der Mehraufwand lohnt sich langfristig aber allemal. Wenn ihr aber denkt, dass zu viel Neues in euer System fließt, können wir gerne Abhilfe schaffen. Jede MetaKube-Version bietet Euch das, was ihr braucht und hilft Euch in der Modernisierung. Damit könnt auch ihr dann die Qual der Wahl auf das beschränken, was wichtig ist – Eurem Kerngeschäft!
