Container-Orchestratoren für Bereitstellungen mit kleinem Formfaktor von Azure Local (Vorschau)

In diesem Artikel wird beschrieben, wie Container-Orchestratoren eine Anwendungsisolationsschicht für kleine Formfaktorbereitstellungen von Azure Local bereitstellen. Es behandelt die beiden primären Optionen, K3s und Docker, und erläutert, wann sie jeweils verwendet werden sollen.

Warum Container auf kleinen Formfaktorgeräten verwenden?

Azure-Local-Bereitstellungen mit kleinem Formfaktor sind für Edge-Standorte konzipiert, an denen Platzangebot, Stromversorgung und Budget begrenzt sind. Herkömmliche VM-basierte Workloads können für die Hardwareprofile, die kleine Formfaktorgeräte unterstützen, zu ressourcenintensiv sein.

Container bieten eine leichtgewichtige Alternative für die Ausführung von Anwendungs-Workloads auf Geräten mit kleinem Formfaktor:

• Geringerer Aufwand: Container teilen den Hostbetriebssystem-Kernel und verbrauchen deutlich weniger Arbeitsspeicher und CPU als VMs, wodurch die begrenzten Ressourcen auf kleiner Formfaktorhardware besser genutzt werden.
• Schneller Start: Containerarbeitslasten beginnen in Sekunden und nicht in Minuten, was für Edgeszenarien wichtig ist, bei denen schnelle Wiederherstellung wichtig ist.
• Konsistente Verpackung: Containerimages bieten eine reproduzierbare Bereitstellungseinheit, die unabhängig vom zugrunde liegenden Hardwaremodell mit geringem Formfaktor auf die gleiche Weise funktioniert.
• Isolation: Container isolieren Anwendungsprozesse, Abhängigkeiten und Netzwerke voneinander und vom Hostbetriebssystem, hindern Konflikte zwischen Workloads.

Container auf Geräten mit kleinem Formfaktor fungieren als Anwendungsisolierungsebene, die auf dem Azure Local-Betriebssystem aufsetzt. Das Hostbetriebssystem, das über die provisioned machine resource verwaltet wird, behandelt hardwareverwaltung und Azure Konnektivität, während der Container Orchestrator den Anwendungslebenszyklus darüber verwaltet.

K3s

K3s ist eine einfache, CNCF-zertifizierte Kubernetes-Verteilung, die für ressourcengeschränkte Umgebungen entwickelt wurde. Es ist für Geräte mit kleinem Formfaktor gut geeignet, da es die vollständige Kubernetes-API bei nur einem Bruchteil des Ressourcenbedarfs von Standard-Kubernetes-Distributionen bereitstellt.

Warum K3s auf Geräten im Kleinformat verwenden?

• Geringer Ressourcenbedarf: K3s wird als einzelne Binärdatei unter 100 MB ausgeliefert und wird mit ca. 512 MB RAM ausgeführt und eignet sich für den Speicherbereich von 32 bis 128 GB geringer Kapazität kleiner Formfaktorhardware.
• Gebündelte Containerlaufzeit: K3s enthält containerd als Containerlaufzeit, sodass Sie kein separates Containermodul auf dem Host installieren müssen.
• Kubernetes-kompatibel: K3s besteht die vollständigen Kubernetes-Konformitätstests, was bedeutet, dass standardmäßige Kubernetes-Manifeste, Helm-Charts und Tools ohne Änderungen funktionieren.
• Integrierte Komponenten: K3s umfasst einen lokalen Speicheranbieter, CoreDNS und einen dienstseitigen Lastenausgleich, wodurch die Anzahl der Komponenten reduziert wird, die Sie separat installieren und verwalten müssen.

Azure Arc-Integration

Sie können K3s-Cluster, die auf kleinen Formfaktorgeräten ausgeführt werden, mit Azure Arc-fähigen Kubernetes verbinden und die cloudbasierte Verwaltung in den Edgecluster integrieren. Mithilfe der Arc-Integration können Sie:

• Anzeigen und überwachen Sie den Cluster im Azure-Portal zusammen mit Ihren anderen Azure-Ressourcen.
• Wenden Sie Azure Policy an, um Konfigurationsstandards in Ihren Edge-Kubernetes-Clustern durchzusetzen.
• Stellen Sie Workloads mithilfe von GitOps (Flux) für die automatisierte, quellgesteuerte Anwendungsbereitstellung bereit.
• Enable Azure RBAC sodass Microsoft Entra ID Identitäten und Rollenzuweisungen den Zugriff auf die Kubernetes-API steuern, sodass keine separaten Kubeconfig-Anmeldeinformationen verwaltet werden müssen.

Um einen K3s-Cluster mit Azure Arc zu verbinden, verwenden Sie den Befehl az connectedk8s connect. Da auf Geräten mit kleinem Formfaktor in der Regel keine Azure CLI auf dem Host installiert ist, kann die CLI in einem Container mithilfe der mit K3s gebündelten Containerlaufzeit containerd ausgeführt werden. Bei diesem Ansatz wird vermieden, zusätzliche Software auf dem Hostbetriebssystem zu installieren. Ein Skript, mit dem Sie K3s remote installieren, den Cluster starten und den Cluster für Azure Arc aktivieren können, finden Sie unter setup-k3s-arc.sh script.

Wann K3s verwendet werden soll

Verwenden Sie K3s, wenn Ihre Workloads von kubernetes-nativen Funktionen profitieren:

• Sie möchten Azure IoT Einsatz oder Azure Foundry Local bereitstellen.
• Sie müssen mehrere voneinander abhängige Dienste mit Diensterkennung und Lastenausgleich ausführen.
• Sie möchten deklarative, selbstheilende Bereitstellungen mit fortlaufenden Updates.
• Sie planen die Verwendung von Helm-Diagrammen oder Kubernetes-Operatoren aus dem Ökosystem.
• Für die zentrale Verwaltung benötigen Sie Azure Arc-fähige Kubernetes-Integration.
• Sie möchten GitOps für die automatisierte Workloadbereitstellung über eine Flotte von Edgegeräten hinweg verwenden.

AKS

Azure Kubernetes Service (AKS) ist ein vollständig verwalteter Kubernetes-Dienst, der direkt auf kleinen Formfaktorgeräten ohne Hypervisor ausgeführt wird. Im Gegensatz zu K3s, was erfordert, dass Sie den Cluster selbst installieren und verwalten müssen, stellen Sie AKS vollständig von Azure bereit – einschließlich Clustererstellung, Kubernetes-Versionsupgrades und Überwachung.

Gründe für die Verwendung von AKS auf Geräten mit kleinem Formfaktor

• Vollständig verwalteter Lebenszyklus: Verwalten Sie die Clustererstellung, Upgrades und das Löschen über das Azure-Portal, Bicep-Vorlagen oder ARM-Vorlagen.
• Kein Hypervisor: AKS wird direkt auf dem Bare Metal-Hostbetriebssystem ausgeführt, sodass Sie den Ressourcenaufwand einer Virtualisierungsebene auf Geräten vermeiden, auf denen Arbeitsspeicher und CPU eingeschränkt sind.
• Built-in Azure Arc Integration: Der Cluster ist ab dem Zeitpunkt der Erstellung arcfähig. Es gibt keinen separaten az connectedk8s connect Schritt. Azure Portalsichtbarkeit, Azure RBAC, Azure Monitor und Azure Policy sind sofort verfügbar.
• Kubernetes-kompatibel: AKS führt Standard Kubernetes mit Cilium CNI aus, sodass vorhandene Kubernetes-Manifeste, Helmdiagramme und Tools ohne Änderung funktionieren.
• Ausfallsicher gegenüber Verbindungsverlusten: Da die Kubernetes-Steuerebene lokal auf dem Gerät ausgeführt wird, funktionieren bereitgestellte Workloads während des Verbindungsverlusts weiterhin normal. Nur die Portalsichtbarkeit und Azure Verwaltungsaktionen werden unterbrochen, bis die Verbindung wiederhergestellt wird.

Wann AKS verwendet werden sollte

Verwenden Sie AKS, wenn Azure den Kubernetes-Lebenszyklus auf Ihren Geräten mit kleinem Formfaktor verwalten soll:

• Sie möchten Cluster aus dem Azure Portal erstellen, aktualisieren und löschen, ohne sich beim Gerät anzumelden.
• Sie benötigen Azure RBAC mit Microsoft Entra ID Identitäten, die den Clusterzugriff von Tag 1 steuern.
• Sie verwalten eine Flotte von Edgegeräten und möchten eine konsistente AKS-Erfahrung über Cloud und Edge hinweg.
• Sie möchten integrierte Azure Monitor und Azure Policy ohne zusätzliche Einrichtung.
• Sie bevorzugen eine vollständig verwaltete Plattform, anstatt Ihre eigene Kubernetes-Distribution selbst zu betreiben.

Docker

Docker bietet eine einfachere Containerlaufzeit zum Ausführen einzelner Container oder kleiner Containergruppen auf einem kleinen Formfaktorgerät. Im Vergleich zu K3s hat Docker weniger Betriebsaufwand, aber auch weniger Orchestrierungsfunktionen.

Gründe für Docker auf kleinen Formfaktorgeräten

• Einfachheit: Docker verwendet ein einfaches docker run Modell, das keine Kenntnisse von Kubernetes-Konzepten wie Pods, Bereitstellungen oder Diensten erfordert.
• Geringere Betriebskomplexität: Es gibt keinen Clusterzustand, der verwaltet werden kann, keine Datenbank usw. und keine Steuerungsebenenkomponenten. Docker führt Container direkt auf dem Host aus.
• Vertraute Tools: Docker ist weit verbreitet, und die meisten Entwicklungsteams verfügen bereits über Erfahrung beim Erstellen und Ausführen von Docker-Containern.
• Verfassen für Multi-Container-Apps: Mit Docker Compose können Sie Anwendungen mit mehreren Containern mithilfe einer einzigen YAML-Datei definieren und ausführen, die für viele Edgeworkloads ausreicht.

Einschränkungen im Vergleich zu K3s

Docker selbst bietet nicht Folgendes:

• Automatischer Neustart und Neuverteilung: Wenn ein Container abstürzt, kann Docker ihn (mit --restart-Richtlinien) neu starten, aber es verteilt Workloads nicht neu und führt kein Failover auf Grundlage von Zustandsprüfungen durch.
• Dienstermittlung und Lastenausgleich: Container können über Docker-Netzwerke kommunizieren, aber es gibt keine integrierte DNS-basierte Dienstermittlung oder einen automatischen Lastenausgleich über Replikate hinweg.
• Deklarative Verwaltung des gewünschten Zustands: Docker Compose stellt eine grundlegende deklarative Konfiguration bereit, aber der tatsächliche Zustand wird nicht kontinuierlich mit dem gewünschten Zustand in Einklang gebracht, wie Kubernetes es tut.
• Azure Arc-fähige Kubernetes-Integration: Docker-Container können nicht über Azure Arc-fähige Kubernetes verwaltet werden. Das zentrale Flottenmanagement erfordert zusätzliche Werkzeuge.

Wann Docker verwendet werden sollte

Verwenden Sie Docker, wenn Ihre Workloads einfach sind und keine Kubernetes-Orchestrierung erfordern:

• Sie führen eine einzelne Anwendung oder eine kleine Anzahl unabhängiger Container aus.
• Sie möchten den schnellsten Weg, um eine containerisierte Arbeitslast auf dem Gerät zum Laufen zu bringen.
• Ihr Team ist mit Docker, aber nicht mit Kubernetes vertraut.
• Sie benötigen kein zentrales Flottenmanagement über Azure Arc-fähige Kubernetes.

Auswählen zwischen AKS, K3s und Docker

Die folgende Tabelle fasst die wichtigsten Unterschiede zusammen, um Ihnen die Wahl des richtigen Container-Orchestrators für Ihre Small-Form-Factor-Bereitstellung zu erleichtern:

Geräte mit kleinem Formfaktor sollten nur einen Container-Orchestrator ausführen

Ein Gerät mit kleinem Formfaktor sollte entweder AKS, K3s oder Docker ausführen, nicht mehrere davon. Treffen Sie diese Entscheidung frühzeitig in der Bereitstellungsplanung, bevor Sie mit der Bereitstellung von containerisierten Workloads beginnen. Stellen Sie alle Ihre Anwendungen mithilfe des ausgewählten Orchestrators bereit.

Warum nicht beide?

Sie können zwar sowohl AKS als auch K3s und Docker technisch auf demselben Gerät installieren. Dadurch entstehen jedoch Probleme, die sich im Laufe der Zeit ergeben:

• Ressourcenkonflikt: Kleine Formfaktorgeräte arbeiten innerhalb enger Ressourceneinschränkungen (nur 14 physische Kerne und 32 GB RAM). Jeder Container orchestrator reserviert Arbeitsspeicher und CPU für seine eigenen Laufzeitkomponenten. Wenn Sie beides parallel betreiben, fällt der Overhead doppelt an – die Control-Plane-Komponenten von AKS oder K3s (API-Server, Scheduler, Controller-Manager, etcd) ebenso wie der Docker-Daemon –, wodurch weniger Kapazität für die eigentlichen Anwendungs-Workloads verbleibt.

• Portkonflikte: Beide Orchestratoren verwalten Containernetzwerke und Portzuordnung unabhängig voneinander. Wenn zwei separate Systeme Containerports dem Host zuordnen, werden widersprüchliche Portbindungen wahrscheinlich, insbesondere auf Geräten mit einer einzigen Netzwerkschnittstelle. Nachzuvollziehen, welcher Orchestrator welchen Port belegt, verursacht unnötigen operativen Mehraufwand.

• In Konflikt stehenden Containerlaufzeiten: AKS oder K3s bündeln eine eigene containerierte Laufzeit, während Docker eine eigene containerierte Instanz ausführt (oder in älteren Versionen eine eigene Laufzeit). Zwei Containerlaufzeiten auf demselben Host können den Speicher, das Netzwerk und die Prozessverwaltung gegenseitig beeinträchtigen. Containerimages, die von einer Laufzeit abgerufen werden, sind für den anderen nicht sichtbar, was zu duplizierten Imagespeichern auf einem bereits speichereinschränkten Gerät führt.

• Geteiltes Betriebsmodell: Der gleichzeitige Betrieb beider Orchestratoren bedeutet, dass Ihr Team für dasselbe Gerät zwei unterschiedliche Sätze von Bereitstellungsverfahren, Überwachungsansätzen und Verfahren zur Fehlerbehebung pflegen muss. Von AKS oder K3s verwaltete Container sind über kubectl und Azure Arc sichtbar. Von Docker verwaltete Container sind über docker ps sichtbar. Es gibt keine einheitliche Ansicht über beides hinweg, was es schwierig macht, das vollständige Workload-Bild auf einem Gerät zu verstehen.

• Unvorhersehbares Updateverhalten: Updates auf Betriebssystemebene, die über den bereitgestellten Computerlebenszyklus angewendet werden, können mit jeder Containerlaufzeit unterschiedlich interagieren. Durch die Verwendung eines einzelnen Orchestrators wird die Updatematrix vereinfacht und das Risiko reduziert, dass nach einer Änderung des Hostbetriebssystems ein Laufzeitbruch besteht.

Frühzeitige Entscheidung treffen

Das Ändern von Container-Orchestratoren nach der Bereitstellung von Workloads ist störend. In der Regel ist Folgendes erforderlich:

1. Neupacken von Anwendungsbereitstellungskonfigurationen (Konvertieren zwischen Docker Compose-Dateien und Kubernetes-Manifesten oder umgekehrt).
2. Migrieren persistenter Daten von Volumes, die von einer Laufzeit zur anderen verwaltet werden.
3. Aktualisierung von CI/CD-Pipelines, Monitoring-Integrationen und operativen Runbooks.
4. Koordinieren von Ausfallzeiten für die Migration, die möglicherweise nicht an always-on-Edge-Standorten akzeptabel sind.

Wählen Sie aus diesen Gründen Ihren Container-Orchestrator aus, bevor Sie Ihre erste Workload bereitstellen. Bewerten Sie Ihre Anforderungen anhand der Vergleichstabelle und berücksichtigen Sie dabei nicht nur Ihre aktuellen Anforderungen, sondern auch, wohin sich Ihre Edge-Bereitstellung entwickelt. Falls die Möglichkeit besteht, dass Sie künftig Azure Arc-fähiges Kubernetes-Management oder clusterübergreifendes GitOps benötigen, können Sie durch den Einstieg mit K3s eine kostspielige Migration zu einem späteren Zeitpunkt vermeiden.

Ein Orchestrator pro Flotte, nicht nur pro Gerät

Wenn Sie Geräte im Kleinformat an mehreren Standorten bereitstellen, setzen Sie über Ihre gesamte Flotte hinweg einheitlich auf denselben Container-Orchestrator. Die Verwendung einer gemischten Umgebung, in der einige Geräte K3s ausführen und andere Docker ausführen, erhöht den Betriebsaufwand.

• Die Bereitstellungstools müssen beide Orchestratoren unterstützen.
• Playbooks zur Fehlerbehebung unterscheiden sich je nach Gerätetyp.
• Flottenweite Überwachung erfordert separate Integrationen für Kubernetes-basierte und Docker-basierte Geräte.
• Die Ausbildungs- und Personalanforderungen steigen, da die Betreiber in beiden Systemen Know-how benötigen.

Die Standardisierung auf einem einzigen Orchestrator sorgt dafür, dass Ihre Flotte betriebseinheitlich bleibt und Sie in eine Reihe von Tools, Schulungen und Automatisierung investieren können.

Wechseln des Geräts zu einer anderen Containerlaufzeit

Der Wechsel zu einer neuen Containerlaufzeit ist einfach. Mit az provisionedmachine reset, können Sie den Computer zurücksetzen, ein neues Betriebssystemimage installieren und als neu behandeln.

Überlegungen zum Netzwerk

Unabhängig davon, welchen Container-Orchestrator Sie wählen, sollten Sie bei Bereitstellungen auf Geräten mit kleinem Formfaktor die folgenden Netzwerkaspekte berücksichtigen:

• Hostnetzwerk: Für Workloads, die direkt an die Netzwerkschnittstellen des Geräts gebunden werden müssen (z. B. Netzwerkermittlungsprotokolle), unterstützen K3s und Docker den Hostnetzwerkmodus.
• Ingress: K3s enthält einen integrierten Service-Load-Balancer. Bei Docker stellen Sie Containerports direkt für den Host mithilfe der Portzuordnung (-p Flag) zur Verfügung.
• Firewall und Proxy: Kleine Formfaktorgeräte an Edgestandorten können sich hinter restriktiven Firewalls befinden. Stellen Sie sicher, dass auf die erforderlichen Endpunkte für Ihre Containerregistrierung und (falls zutreffend) Azure Arc zugegriffen werden kann.

Sicherheitsüberlegungen

Durch das Ausführen von Containern auf geräten mit kleinem Formfaktor wird ein Sicherheitsmodell für gemeinsam genutzte Kernel eingeführt. Beachten Sie Folgendes:

• Herkunft von Images: Beziehen Sie Container-Images nur aus vertrauenswürdigen Registries. Verwenden Sie nach Möglichkeit Bildsignatur- und Sicherheitsrisikoüberprüfungen.
• Prinzip der geringsten Rechte: Vermeiden Sie, Container mit Root-Rechten auszuführen, es sei denn, dies ist erforderlich. Sowohl K3s als auch Docker unterstützen das Ausführen von Containern mit eingeschränkten Berechtigungen.

Nächste Schritte

• Ausführen von containerisierten Workloads auf einem bereitgestellten Computer
• Bereitstellen von Anwendungen