Kompatibilität von Container-Images: Ein Schlüssel zur Zuverlässigkeit in Cloud-Umgebungen

In Branchen, in denen Systeme äußerst zuverlässig laufen müssen und strenge Leistungsanforderungen bestehen, wie beispielsweise in der Telekommunikation, Hochleistungs- oder KI-Computing, benötigen containerisierte Anwendungen oft spezifische Betriebssystemkonfigurationen oder Hardware. Es ist gängige Praxis, bestimmte Versionen des Kernels, dessen Konfiguration, Gerätetreiber oder Systemkomponenten zu verlangen.

Trotz der Existenz der Open Container Initiative (OCI), einer Gemeinschaft, die Standards und Spezifikationen für Container-Images definiert, gab es eine Lücke in der Ausdrucksweise solcher Kompatibilitätsanforderungen. Die Notwendigkeit, dieses Problem anzugehen, führte zu unterschiedlichen Vorschlägen und letztlich zu einer Implementierung im Kubernetes-Projekt Node Feature Discovery (NFD).

NFD ist ein Open-Source-Kubernetes-Projekt, das automatisch Hardware- und Systemmerkmale von Cluster-Knoten erkennt und meldet. Diese Informationen helfen Benutzern, Workloads auf Knoten zu planen, die spezifische Systemanforderungen erfüllen, was besonders nützlich für Anwendungen mit strengen Hardware- oder Betriebssystemabhängigkeiten ist.

Die Notwendigkeit einer Spezifikation zur Image-Kompatibilität

Abhängigkeiten zwischen Containern und Host-OS

Ein Container-Image wird auf einem Basis-Image erstellt, das eine minimale Laufzeitumgebung bietet, oft ein abgespecktes Linux-Userland, das völlig leer oder distroless ist. Wenn eine Anwendung bestimmte Funktionen vom Host-OS benötigt, treten Kompatibilitätsprobleme auf. Diese Abhängigkeiten können sich auf verschiedene Weise manifestieren:

• Treiber: Host-Treiber-Versionen müssen mit dem unterstützten Bereich einer Bibliotheksversion innerhalb des Containers übereinstimmen, um Kompatibilitätsprobleme zu vermeiden. Beispiele sind GPUs und Netzwerktreiber.
• Bibliotheken oder Software: Der Container muss mit einer bestimmten Version oder einem Versionsbereich für eine Bibliothek oder Software geliefert werden, um optimal in der Umgebung zu funktionieren. Beispiele aus dem Hochleistungsrechnen sind MPI, EFA oder Infiniband.
• Kernel-Module oder -Funktionen: Bestimmte Kernel-Funktionen oder -Module müssen vorhanden sein. Beispiele sind die Unterstützung von schreibgeschützten großen Seitenfehlern oder die Anwesenheit von VFIO.
• Und mehr…

Während Container in Kubernetes die wahrscheinlichste Abstraktionseinheit für diese Bedürfnisse darstellen, kann die Definition von Kompatibilität weitergehen und andere Container-Technologien wie Singularity sowie andere OCI-Artefakte wie Binärdateien aus einem Spack-Binärcache einschließen.

Herausforderungen in Multi-Cloud- und Hybrid-Cloud-Umgebungen

Containerisierte Anwendungen werden über verschiedene Kubernetes-Distributionen und Cloud-Anbieter hinweg bereitgestellt, wobei unterschiedliche Host-Betriebssysteme Kompatibilitätsherausforderungen mit sich bringen. Oft müssen diese vor der Bereitstellung von Workloads vorkonfiguriert oder sind nicht veränderbar.

Verschiedene Cloud-Anbieter bieten unterschiedliche Betriebssysteme wie:

• RHCOS/RHEL
• Photon OS
• Amazon Linux 2
• Container-Optimized OS
• Azure Linux OS
• Und mehr…

Jedes OS kommt mit einzigartigen Kernel-Versionen, Konfigurationen und Treibern, was die Kompatibilität für Anwendungen, die spezifische Funktionen erfordern, zu einer nicht trivialen Angelegenheit macht. Es muss möglich sein, schnell zu beurteilen, ob ein Container geeignet ist, um in einer bestimmten Umgebung zu laufen.

Die neue Spezifikation zur Kompatibilität von Container-Images kann hier entscheidend helfen. Durch die Verbesserung der Transparenz und der Möglichkeiten zur Validierung von Systemanforderungen wird die Zuverlässigkeit von Anwendungen in Cloud-Umgebungen erheblich gesteigert.

Bei ayedo unterstützen wir Unternehmen dabei, diese Herausforderungen zu meistern und Kubernetes effizient zu nutzen, um die Vorteile einer containerisierten Architektur voll auszuschöpfen.

Quelle: Kubernetes Blog