Erfahren Sie, wie HostProcess-Container die Verwaltung von Windows-Knoten in Kubernetes revolutionieren.
Der lang erwartete Tag ist gekommen: HostProcess-Container, das Windows-Pendant zu Linux-privilegierten Containern, sind endlich in Kubernetes 1.26 allgemein verfügbar!
Cluster-Betreiber sehen sich oft der Herausforderung gegenüber, ihre Knoten bei der Bereitstellung zu konfigurieren, z. B. durch die Installation von Windows-Diensten, die Konfiguration von Registrierungsschlüsseln, das Verwalten von TLS-Zertifikaten, Änderungen an der Netzwerkkonfiguration oder sogar durch die Bereitstellung von Überwachungstools wie dem Prometheus Node-Exporter. Bisher wurden diese Aufgaben auf Windows-Knoten normalerweise durch das Ausführen von PowerShell-Skripten über SSH oder WinRM-Sitzungen und/oder durch die Verwendung der Verwaltungstools des Cloud-Anbieters durchgeführt.
Mit HostProcess-Containern können Sie all dies und noch viel mehr mit minimalem Aufwand über die nativen Kubernetes-APIs erledigen. Sie können jetzt beliebige Payloads in das Container-Image packen, Volumes zur Laufzeit in Container einbinden und sie wie jede andere Kubernetes-Workload verwalten. Sie profitieren von den Vorteilen der containerisierten Verpackungs- und Bereitstellungsmethoden, verbunden mit einer Senkung der administrativen und Entwicklungskosten. Die Zeiten, in denen Cluster-Betreiber sich manuell auf Windows-Knoten anmelden mussten, um administrative Aufgaben zu erledigen, sind vorbei.
HostProcess-Container unterscheiden sich erheblich von regulären Windows-Server-Containern. Sie werden direkt als Prozesse auf dem Host mit den Zugriffsrichtlinien eines von Ihnen festgelegten Benutzers ausgeführt. HostProcess-Container laufen entweder als integrierte Windows-Systemkonten oder als ephemere Benutzer innerhalb einer von Ihnen definierten Benutzergruppe. HostProcess-Container teilen sich auch den Netzwerknamespace des Hosts und können Speicher-Mounts nutzen, die dem Host sichtbar sind. Im Gegensatz dazu sind Windows-Server-Container stark isoliert und existieren in einem separaten Ausführungsnamespace. Der direkte Zugriff auf den Host von einem Windows-Server-Container ist standardmäßig ausdrücklich nicht erlaubt.
Windows HostProcess-Container werden mit Windows Job Objects implementiert, was einen Bruch mit dem vorherigen Containermodell darstellt, das Server-Silos verwendete. Job Objects sind Komponenten des Windows-Betriebssystems, die die Möglichkeit bieten, eine Gruppe von Prozessen als Gruppe (auch bekannt als Job) zu verwalten und Ressourcengrenzen für die Gruppe als Ganzes festzulegen. Job Objects sind spezifisch für das Windows-Betriebssystem und sind nicht mit der Kubernetes Job API verbunden. Sie bieten keine Prozess- oder Dateisystemisolierung, wodurch die privilegierte Payload den Host-Dateisystem mit den gewünschten Berechtigungen einsehen und bearbeiten kann, sowie auf andere Host-Ressourcen zugreifen kann. Der Init-Prozess und alle von ihm gestarteten Prozesse (einschließlich der vom Benutzer ausdrücklich gestarteten Prozesse) werden dem Job-Objekt dieses Containers zugewiesen. Wenn der Init-Prozess beendet wird oder das Signal zum Beenden erhält, werden alle Prozesse im Job ebenfalls aufgefordert, zu beenden, der Job-Handle wird geschlossen und der Speicher wird ungemountet.
HostProcess- und Linux-privilegierte Container ermöglichen ähnliche Szenarien, unterscheiden sich jedoch erheblich in ihrer Implementierung (daher die unterschiedliche Benennung). HostProcess-Container haben ihre eigenen PodSecurityContext Felder. Die zur Konfiguration von Linux-privilegierten Containern verwendeten gelten nicht. Das Aktivieren des privilegierten Zugriffs auf einen Windows-Host ist ein grundlegend anderer Prozess als bei Linux, sodass sich die Konfiguration und die Fähigkeiten erheblich unterscheiden. Unten finden Sie ein Diagramm, das die Gesamtarchitektur von Windows HostProcess-Containern detailliert:
Vor der Stabilisierung wurden zwei wichtige Funktionen hinzugefügt: die Möglichkeit, als lokale Benutzerkonten zu arbeiten, und eine vereinfachte Methode zum Zugriff auf Volume-Mounts. Um mehr zu erfahren, lesen Sie Create a Windows HostProcess Pod.
Mit ayedo als erfahrenem Kubernetes-Partner können Sie sicher sein, dass Sie bei der Nutzung dieser neuen Funktionalitäten bestens unterstützt werden!
Quelle: Kubernetes Blog
Profitieren Sie von skalierbarem App Hosting in Kubernetes, hochverfügbarem Ingress Loadbalancing und erstklassigem Support durch unser Plattform Team. Mit der ayedo Cloud können Sie sich wieder auf das konzentrieren, was Sie am besten können: Software entwickeln.
Moderne generative KI- und große Sprachmodelle (LLMs) stellen Kubernetes vor einzigartige Herausforderungen im Datenverkehrsmanagement. Im Gegensatz zu typischen kurzlebigen, zustandslosen Webanfragen …
Einführung in die Verwaltung von Sidecar-Containern in Kubernetes In der Welt von Kubernetes sind Sidecar-Container nützliche Helfer, die Funktionen erweitern oder zusätzliche Aufgaben für die …
Wir freuen uns, die allgemeine Verfügbarkeit der Gateway API v1.3.0 bekanntzugeben! Diese Version wurde am 24. April 2025 veröffentlicht und bringt spannende neue Funktionen mit sich. Was ändert sich …
Die vergessene Schwachstelle in euren CI/CD-Pipelines: Die Registry Jeder redet über Build-Pipelines, Deployment-Automatisierung, GitOps, Blue/Green-Rollouts, Canary Releases. Alles sauber …
Wer Anwendungen produktiv betreibt, braucht keine schönen Dashboards, sondern harte Daten. Performance-Probleme entstehen nie dann, wenn Zeit für Debugging ist. Sie kommen genau dann, wenn Systeme …
Interessiert an weiteren Inhalten? Hier gehts zu allen Blogs →