Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03111.jsonl.gz/2730

Vor kurzem habe ich für Microsoft ein Webinar zum Azure Kubernetes Service (AKS) gehalten. In diesem Blogpost gebe ich Ihnen eine Übersicht, was ich darin behandelt habe, sowie ein paar zusätzliche Infos zu AKS.
Kurze Geschichte der Container
Beginnen wir mit einer kurzen Rekapitulation darüber, was Container sind, woher sie kommen und wie sie in eine moderne Cloud-Architektur passen. In den letzten vier bis fünf Jahren stand die Container-Technologie im Vordergrund der modernen Cloud-Infrastruktur und im Clouddesign. Um 2012 basierten Cloud-PaaS- und IaaS-Architekturen auf virtuellen Maschinen.
Die Migrationen erfolgten hauptsächlich im «Lift-and-shift”-Verfahren. Viele Cloud-Anwender verlagerten VMs in die Cloud, um die Vorteile der Cloud-Infrastruktur für die Rechenarbeitslasten zu nutzen.
Die VMs konnten ziemlich unübersichtlich werden, wie bereits im traditionellen On-Prem-Rechenzentrum mit verschiedenen Komponenten und Anwendungen. Diese liefen auf derselben VM, wie Dateifreigaben, Überwachungs- und Konfigurationsagenten, IIS, Anwendungskomponenten und manchmal auch Speicher wie Datenbanken.
Dies warf die gleiche Art von Einsatz-, Redundanz- und Kontinuitätsproblemen auf wie zuvor. Die VMs wurden am häufigsten durch imperative Programmierung verwaltet.
Daher war es manchmal schwierig zu wissen, ob der Aufbau der VM funktionierte oder nicht.
Gold Image auf einer VM
Man erkannte, dass die Umstellung auf eine unveränderliche Infrastruktur diese Verwaltung und Bereitstellung immens vereinfachen könnte. Eine unveränderliche Infrastruktur liegt dann vor, wenn wir ein «Gold Image» einer VM auf einem beliebigen Hypervisor mit einer bestimmten Konfiguration bereitstellen.
Wenn wir fertig sind, zerstören wir diese VM und werfen sie weg. Wenn wir sie wiederverwenden wollen, starten wir eine weitere VM von diesem «Gold Image» und haben jedes Mal die exakt gleich laufende Konfiguration. An dem Image wird nichts geändert, und es wird jedes Mal auf die gleiche Weise eingesetzt und funktioniert entsprechend gleich: verpacken, verteilen, isolieren. Das ist natürlich sehr praktisch.
Daraus entstand eine stabile, vorhersehbare Umgebung, die aus unveränderlichen VMs besteht. Aber VMs sind sperrige Objekte, sie nehmen viel Platz ein und ihre Verlagerung, z.B. während eines Failover, kann zeit- und ressourcenaufwändig sein.
Sie sind auch nicht sehr entwicklerfreundlich. Änderungsprotokolle müssen gepflegt, Änderungen festgehalten und in die VM-Images integriert werden.
Container-Images
Die Idee der Container-Images nimmt also die Komponenten die auf der VM laufen und abstrahiert nur die Teile, die nicht Bestandteil des zugrundeliegenden Kernels sind. Die Teile werden in eine stromlinienförmige und leichtgewichtige Kapselung abstrahiert, in der wir alles innerhalb des Containers haben, was wir zum Ausführen der Anwendung brauchen. Die gemeinsam genutzten Komponenten aus dem Kernel hingegen werden nicht integriert, wodurch wir faktisch eine Trennung Verantwortlichkeiten schaffen.
Dies ist ein ähnliches Prinzip wie die Anwendungsvirtualisierung, die zu dieser Zeit auch noch in den Szenarien von On-Prem-Rechenzentren populär war.
Sobald die Anwendungen und ihre Abhängigkeiten abstrahiert und in Container-Images verpackt waren, konnten sie in ein Cloud-Repository hochgeladen werden, wodurch die Images global verteilt und von überall auf der Welt abgerufen werden konnten.
In Azure wird das Cloud-Repository ACR gennant, aber es gibt auch andere wie bspw. DockerHub. Darüber hinaus können diese Bilder zusammen mit anderen Bildern auf derselben zugrundeliegenden Infrastruktur ausgeführt werden, ohne dass sie miteinander interagieren, wodurch die Effizienz dieser Hardware erhöht wird. Darüber hinaus können Sie, anstatt für eine VM zu bezahlen, die eine einzige Anwendung ausführt und nur zu 10 % ausgelastet ist, 3 oder 4 containerisierte Anwendungen auf dieselbe VM laden und die Auslastung um bis zu 50 bis 60 % steigern, ohne irgendwelche Anwendungen umzugestalten.
Container-Orchestrator
Um diese Container-Bilder auf einer Hardwarerückwand zu verwenden und das Beste aus den Bildern herauszuholen, müssen wir einen Container-Orchestrator verwenden, der es uns erlaubt, Bilder zu skalieren und zu verteilen, wenn nötig weltweit. wie z.B. Kubernetes. Kubernetes, auch gennant K8S, ist ein Container-Orchestrator.
Die Hardwarerückwand ist wie eine Reihe von VMs oder physischen Maschinen, aber sie bilden einen Pool von Hardwareressourcen, Knoten genannt, auf denen unsere Container sitzen.
In K8S sind diese Knoten für die Ausführung von Gruppen containerisierter Anwendungen, so genannten Pods, zuständig, und der Masterknoten verwaltet, welche Pods auf welchen Knoten laufen.
Der Master-Knoten enthält eine Reihe von Komponenten wie die API, die die Steuerungsebene bilden. Am wichtigsten ist hier zu wissen, dass kubectl (eine Befehlszeilenschnittstelle) Befehle an den kube-API-Server gesendet werden, der alle Knotenoperationen abwickelt: entwickeln, bereitstellen, patchen, aktualisieren, skalieren.
Wie sieht das Ganze in Azure aus?
Der K8S-Control-Plane wird vollständig von Microsoft verwaltet, d.h. das komplette K8S-Cluster und die Infrastruktur. Wenn Sie schon einmal ein K8S-Cluster aktualisieren mussten, wissen Sie, was für eine grosse Sache das ist.
Die gesamte Lösung ist K8S, d.h. es ist kein Microsoft-Produkt. Zum Zeitpunkt der Veröffentlichung dieses Blogposts ist es ein Open-Source-Code-Projekt. Dies bedeutet, dass es immer noch vollständig von Containerlösungen und Community-Entwicklung betreut wird.
In einem nächsten Beitrag werde ich Ihnen, anhand des Beispiels einer Web App, eine Schritt-für-Schritt Anleitung für die Umsetzung vorstellen.