{"id":103964,"date":"2022-05-05T21:36:43","date_gmt":"2022-05-05T19:36:43","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-kubernetes-1-24-sistemy-upravleniya-klasterom-izolirovannyh-kontejnerov"},"modified":"2022-05-05T21:36:43","modified_gmt":"2022-05-05T19:36:43","slug":"vypusk-kubernetes-1-24-sistemy-upravleniya-klasterom-izolirovannyh-kontejnerov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/vypusk-kubernetes-1-24-sistemy-upravleniya-klasterom-izolirovannyh-kontejnerov","title":{"rendered":"Kubernetes-Version 1.24, ein System zur Verwaltung von Clustern isolierter Container.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Die neue Version der Container-Orchestrierungsplattform Kubernetes 1.24 steht zur Verf\u00fcgung. Sie erm\u00f6glicht die umfassende Verwaltung von Clustern isolierter Container und bietet Mechanismen f\u00fcr die Bereitstellung, Wartung und Skalierung von in Containern ausgef\u00fchrten Anwendungen. Das Projekt wurde urspr\u00fcnglich von Google ins Leben gerufen und sp\u00e4ter auf eine unabh\u00e4ngige Plattform \u00fcberf\u00fchrt, die von der Linux Foundation betreut wird. Die Plattform wird als gemeinschaftlich entwickeltes universelles L\u00f6sung betrachtet, das nicht an spezifische Systeme gebunden ist und mit beliebigen Anwendungen in allen Cloud-Umgebungen arbeiten kann. Der Code von Kubernetes ist in Go geschrieben und wird unter der Lizenz Apache 2.0 ver\u00f6ffentlicht. <\/p>\n
Es werden Funktionen zur Bereitstellung und Verwaltung von Infrastruktur angeboten, wie z.B. die Verwaltung von DNS, Lastverteilung, die Containerverteilung auf Clusterknoten (Migration von Containern basierend auf Lastwechseln und Serviceanforderungen), Anwendungs\u00fcberwachung, Kontoverwaltung, Aktualisierung und dynamisches Skalieren des aktiven Clusters ohne Unterbrechung. Es ist m\u00f6glich, Gruppen von Containern bereitzustellen und dabei Aktualisierungen und R\u00fcckg\u00e4ngigmachungen gleichzeitig f\u00fcr die gesamte Gruppe durchzuf\u00fchren, sowie das logische Aufteilen des Clusters in Teile mit Ressourcenteilung. Es wird auch die dynamische Migration von Anwendungen unterst\u00fctzt, f\u00fcr deren Datenspeicherung sowohl lokale Speicher als auch Netzwerkspeichersysteme genutzt werden k\u00f6nnen. <\/p>\n
Wesentliche \u00c4nderungen in der neuen Version: <\/p>\n
\n
Die Mittel zur \u00dcberwachung der Speicherkapazit\u00e4t (Storage Capacity Tracking) wurden stabilisiert, um den freien Speicherplatz in den Partitionen zu \u00fcberwachen und die Daten an den Steuerknoten zu \u00fcbermitteln, um das Starten von Pods auf Knoten mit unzureichendem freiem Speicherplatz zu verhindern.\n
Die M\u00f6glichkeit zur Erweiterung von Speicherbereichen wurde stabilisiert. Benutzer k\u00f6nnen die Gr\u00f6\u00dfe bestehender Partitionen \u00e4ndern, und Kubernetes erweitert automatisch die Partition sowie das zugeh\u00f6rige Dateisystem, ohne den Betrieb zu unterbrechen.\n
Die Bereitstellung des Runtime Dockershim, das als vor\u00fcbergehende L\u00f6sung zur Nutzung von Docker in Kubernetes gedacht war und nicht mit der standardm\u00e4\u00dfigen CRI (Container Runtime Interface) kompatibel ist, wurde eingestellt. Zur Verwaltung isolierter Container sollte ein Runtime verwendet werden, das das CRI unterst\u00fctzt, wie containerd oder CRI-O, oder die cri-dockerd-Bindung, die das CRI \u00fcber die Docker Engine API implementiert.\n
Experimentelle Unterst\u00fctzung f\u00fcr die Verifizierung von Container-Images \u00fcber digitale Signaturen mit dem Sigstore-Dienst wurde bereitgestellt, der ein \u00f6ffentliches Protokoll zur Best\u00e4tigung der Authentizit\u00e4t f\u00fchrt (Transparency Log). Um Angriffe auf die Lieferkette und die \u00c4nderung von Komponenten zu verhindern, erfolgt au\u00dferdem die Beglaubigung digitaler Signaturen f\u00fcr die mit Releases verbundenen Artefakte, einschlie\u00dflich aller installierten ausf\u00fchrbaren Dateien von Kubernetes.\n
Standardm\u00e4\u00dfig ist die Aktivierung von APIs in Clustern, die sich im Beta-Zustand befinden, deaktiviert (bereits in fr\u00fcheren Versionen hinzugef\u00fcgte Test-APIs bleiben erhalten, die \u00c4nderung betrifft nur neue APIs).\n
Eine Testunterst\u00fctzung f\u00fcr das OpenAPI v3-Format wurde implementiert.\n
Eine Initiative zur \u00dcbertragung von Plugins f\u00fcr die Arbeit mit Speichern auf das einheitliche CSI (Container Storage Interface) wurde vorgestellt, w\u00e4hrend die API-Kompatibilit\u00e4t gewahrt bleibt. Die Azure Disk- und OpenStack Cinder-Plugins wurden auf CSI umgestellt.\n
Der Kubelet Credential Provider wurde in die Beta-Testphase \u00fcberf\u00fchrt, der es erm\u00f6glicht, Anmeldeinformationen f\u00fcr Container-Image-Repositories dynamisch \u00fcber die Ausf\u00fchrung von Plugins abzurufen, ohne die Anmeldeinformationen im Dateisystem des Knotens zu speichern.\n
Es besteht die M\u00f6glichkeit, einen IP-Adressbereich f\u00fcr die Zuweisung an Dienste zu reservieren. Wenn diese Option aktiviert ist, wird der Cluster den Diensten automatisch nur Adressen aus einem zuvor f\u00fcr jeden Dienst zugewiesenen Pool zuweisen, um Kollisionen bei der Vergabe freier Adressen aus einem gemeinsamen Set zu vermeiden. IP-Adressen<\/a> In Chrome wird ein integrierter Screenshot-Editor getestet. <\/ul>\n