Mit Containern und Kubernetes behandelt dieser Kurs die beiden dominierenden Techniken bei Betrieb und Entwicklung von Anwendungen. Anhand eines Beispiels wird praxisnah betrachtet, wie aufwendig der Eigenbetrieb im Vergleich zu Cloud-Lösungen ist.
Kubernetes und Docker – zwei Synonyme für die Erstellung und den Betrieb von Microservices und Containern. So stark, wie diese beiden Begriffe für eine neue Technologie stehen, so häufig hat man sie in den Anfangszeiten der Container-Nutzung gemeinsam gesehen: Docker macht Container, Kubernetes den Betrieb der Docker-Hosts. Doch diese Zeiten sind (eigentlich schon länger) vorbei. Kubernetes hat die Unterstützung von Docker als „deprecated“ markiert und will sie in den nächsten Jahren komplett einstellen. Woran liegt das? Und was bedeutet das für meine Container-Umgebungen?
Bei Kubernetes gilt die Prämisse: Jeder Pod muss jeden Pod desselben Services über IP ohne NAT erreichen können. Eine Lösung ist natürlich, jedem Pod eine Adresse aus dem Subnetz zuzuweisen, zu dem auch der Node gehört, auf dem er ausgeführt wird. Das ist jedoch oft nicht gewollt. So stellt sich die Frage nach dem passenden Overlay-Netz.
Corona regiert das Land. Man hört viel von Entschleunigung. Wenn ich mir mein unmittelbares Arbeitsumfeld ansehe, erlebe ich zurzeit allerdings das Gegenteil. Die IT-Abteilungen arbeiten vielerorts auf Hochtouren, um die Home-Office-Plätze auch wirklich anbieten zu können. Glücklich die, die schon viele Cloud-Anwendungen nutzen. Aber das sind zugegebener Weise wenige. Ich lehne mich jetzt mal aus dem Fenster: Corona wird das ändern.
Wer selbst Anwendungen in der Cloud betreibt, kommt um deren Überwachung nicht herum. Klassische Methoden funktionieren nicht mehr: Die Konfiguration von statischen Adressen und Grenzwerten passt nicht zu dynamischen Microservice-Architekturen wie Kubernetes. Für die Bedarfsplanung reicht ein Monitoring nicht aus, vielmehr ist ein Trending vonnöten.
Anders als bei monolithischer Software ist das Logging von dynamischen Software-Architekturen eine Herausforderung, für die es keinen Standard gibt. Vielmehr müssen die Lösungen geplant und betrieben werden. Welche Alternativen gibt es?
Virtuelle Maschinen (VMs) stellen einer Anwendung alles zur Verfügung, was sie an Ressourcen braucht. Wenn aber eine neue Anwendung nur noch Container statt ganzer Maschinen benötigt, stellt sich die Frage nach der Daseinsberechtigung von VMs. VMs werden jedoch weiterhin benötigt, weil viele Anwendungen nach der bisherigen Architektur konzipiert sind und ein mandantenfähiges RZ Virtualisierung von Maschinen nutzen muss.
ComConsult GmbH
Pascalstraße 27
DE-52076 Aachen
Telefon: 02408/951-0
Fax: 02408/951-200
E-Mail: info@comconsult.com
