Veröffentlichung von Kubernetes 1.24, einem System zur Verwaltung eines Clusters isolierter Container

Die Veröffentlichung der Container-Orchestrierungsplattform Kubernetes 1.24 ist verfügbar, die Ihnen die Verwaltung eines Clusters isolierter Container als Ganzes ermöglicht und Mechanismen für die Bereitstellung, Wartung und Skalierung von in Containern ausgeführten Anwendungen bereitstellt. Das Projekt wurde ursprünglich von Google erstellt, dann aber auf eine unabhängige Website unter der Aufsicht der Linux Foundation übertragen. Die Plattform ist als universelle, von der Community entwickelte Lösung positioniert, die nicht an einzelne Systeme gebunden ist und mit jeder Anwendung in jeder Cloud-Umgebung arbeiten kann. Kubernetes-Code wird in Go geschrieben und unter der Apache 2.0-Lizenz vertrieben.

Es werden Funktionen für die Bereitstellung und Verwaltung der Infrastruktur bereitgestellt, wie z. B. die Pflege einer DNS-Datenbank, den Lastausgleich, die Verteilung von Containern auf Clusterknoten (Migration von Containern abhängig von Laständerungen und Dienstanforderungen), Gesundheitsprüfungen auf Anwendungsebene, Kontoverwaltung, Aktualisierung usw dynamische Skalierung des Arbeitsclusters, ohne ihn zu stoppen. Es ist möglich, Gruppen von Containern mit gleichzeitigen Aktualisierungs- und Rückgängigmachungsvorgängen für die gesamte Gruppe bereitzustellen sowie den Cluster logisch in Teile mit Aufteilung der Ressourcen aufzuteilen. Es gibt Unterstützung für die dynamische Migration von Anwendungen, für deren Datenspeicherung sowohl lokale Speicher als auch Netzwerkspeichersysteme verwendet werden können.

Wichtige Änderungen in der neuen Version:

  • Die Tools zur Speicherkapazitätsverfolgung wurden stabilisiert, um den freien Speicherplatz in Partitionen zu überwachen und Daten an den Kontrollknoten zu übertragen, um zu verhindern, dass Pods auf Knoten gestartet werden, die nicht über genügend freien Speicherplatz verfügen.
  • Die Möglichkeit, Speicherpartitionen zu erweitern, wurde stabilisiert. Der Benutzer kann die Größe bestehender Partitionen ändern und Kubernetes erweitert die Partition und das zugehörige Dateisystem automatisch, ohne die Arbeit zu unterbrechen.
  • Die Lieferung von Runtime Dockershim wurde eingestellt, das als vorübergehende Lösung für die Verwendung von Docker in Kubernetes positioniert war, nicht mit der Standard-CRI-Schnittstelle (Container Runtime Interface) kompatibel war und zu einer zusätzlichen Komplikation des Kubelet führte. Um isolierte Container zu verwalten, sollten Sie eine Laufzeitumgebung verwenden, die die CRI-Schnittstelle unterstützt, z. B. Containerd und CRI-O, oder das cri-dockerd-Framework verwenden, das die CRI-Schnittstelle auf der Docker Engine-API implementiert.
  • Experimentelle Unterstützung wurde für die Überprüfung von Containerbildern mithilfe digitaler Signaturen mithilfe des Sigstore-Dienstes bereitgestellt, der ein öffentliches Protokoll zur Bestätigung der Authentizität führt (Transparenzprotokoll). Um Angriffe auf die Lieferkette und den Austausch von Komponenten zu verhindern, werden auch digitale Signaturen für veröffentlichungsbezogene Artefakte bereitgestellt, einschließlich aller installierten ausführbaren Kubernetes-Dateien.
  • Standardmäßig sind APIs in der Betaversion nicht mehr in Clustern aktiviert (Test-APIs, die in früheren Versionen hinzugefügt wurden, bleiben erhalten; die Änderung gilt nur für neue APIs).
  • Testunterstützung für das OpenAPI v3-Format wurde implementiert.
  • Es wurde eine Initiative gestartet, um Speicher-Plugins auf die einheitliche CSI-Schnittstelle (Container Storage Interface) zu übertragen und gleichzeitig die Kompatibilität auf API-Ebene aufrechtzuerhalten. Die Plugins Azure Disk und OpenStack Cinder wurden auf CSI übertragen.
  • Der Kubelet Credential Provider wurde in die Betatestphase verschoben, sodass Sie Anmeldeinformationen für ein Container-Image-Repository dynamisch abrufen können, indem Sie Plugins starten, ohne Anmeldeinformationen im Knotendateisystem zu speichern.
  • Es besteht die Möglichkeit, einen Bereich von IP-Adressen für die Zuordnung zu Diensten zu reservieren. Wenn diese Option aktiviert ist, weist der Cluster den Diensten automatisch nur IP-Adressen aus einem für jeden Dienst vorab zugewiesenen Pool zu, wodurch Kollisionen bei der Vergabe freier Adressen aus dem gemeinsamen Satz vermieden werden.

Source: opennet.ru

Kommentar hinzufügen