{"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\/news\/vypusk-kubernetes-1-24-sistemy-upravleniya-klasterom-izolirovannyh-kontejnerov","title":{"rendered":"Ver\u00f6ffentlichung Kubernetes 1.24, System zur Verwaltung von Clustern isolierter Container","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Die Version der Container-Orchestrierungsplattform Kubernetes 1.24 ist verf\u00fcgbar, die es erm\u00f6glicht, einen Cluster aus isolierten Containern als Einheit zu verwalten und Mechanismen f\u00fcr das Deployment, die Wartung und die Skalierung von in Containern ausgef\u00fchrten Anwendungen bereitstellt. Das Projekt wurde urspr\u00fcnglich von Google ins Leben gerufen, anschlie\u00dfend jedoch auf eine unabh\u00e4ngige Plattform \u00fcbertragen, die von der Linux Foundation betreut wird. Die Plattform wird als von der Community entwickeltes universelles L\u00f6sung angesehen, das nicht an bestimmte Systeme gebunden ist und mit beliebigen Anwendungen in beliebigen Cloud-Umgebungen arbeiten kann. Der Code von Kubernetes ist in Go geschrieben und steht unter der Lizenz Apache 2.0 zur Verf\u00fcgung. <\/p>\n
Es werden Funktionen f\u00fcr die Bereitstellung und Verwaltung der Infrastruktur bereitgestellt, wie z.B. die F\u00fchrung einer DNS-Datenbank, Lastverteilung, Verteilung von Containern auf die Knoten des Clusters (Migration von Containern je nach Last\u00e4nderung und Dienstanforderungen), \u00dcberpr\u00fcfung der Anwendungsfunktionalit\u00e4t, Kontoverwaltung, Aktualisierung und dynamische Skalierung des laufenden Clusters ohne dessen Stopp. Es ist m\u00f6glich, Gruppen von Containern bereitzustellen, wobei Aktualisierungs- und Rollback-Operationen gleichzeitig f\u00fcr die gesamte Gruppe durchgef\u00fchrt werden k\u00f6nnen, sowie eine logische Unterteilung des Clusters in Teile zur Ressourcenteilung. Unterst\u00fctzung f\u00fcr die dynamische Migration von Anwendungen ist vorhanden, wobei sowohl lokale Speicher als auch Netzwerkspeichersysteme zur Datenspeicherung verwendet werden k\u00f6nnen. <\/p>\n
Wesentliche \u00c4nderungen in der neuen Version: <\/p>\n
\n
Die Mittel zur \u00dcberwachung der Speicherkapazit\u00e4t (Storage Capacity Tracking) sind stabilisiert, die die \u00dcberwachung des freien Speicherplatzes in den Partitionen erm\u00f6glichen und Daten an den Verwaltungs-Node \u00fcbertragen, um das Starten von Pods auf Knoten zu verhindern, auf denen nicht gen\u00fcgend freier Speicherplatz vorhanden ist.\n
Die M\u00f6glichkeit, Speicherpartitionen zu erweitern, ist stabilisiert. Der Benutzer kann die Gr\u00f6\u00dfe bereits existierender Partitionen ver\u00e4ndern, und Kubernetes wird automatisch, ohne den Betrieb zu stoppen, die Partition und das zugeh\u00f6rige Dateisystem erweitern.\n
Die Lieferung von runtime Dockershim wurde eingestellt, das als vor\u00fcbergehende L\u00f6sung f\u00fcr die Verwendung von Docker in Kubernetes positioniert war. Es ist nicht mit der standardm\u00e4\u00dfigen CRI (Container Runtime Interface) kompatibel und f\u00fchrt zu zus\u00e4tzlichen Komplikationen im kubelet. Um isolierte Container zu verwalten, sollte ein Runtime verwendet werden, das die CRI-Schnittstelle unterst\u00fctzt, wie containerd und CRI-O, oder die cri-dockerd-Bindung genutzt werden, die die CRI-Schnittstelle \u00fcber die Docker Engine API implementiert.\n
Experimentelle Unterst\u00fctzung zur Verifizierung von Container-Images durch digitale Signaturen mithilfe des Sigstore-Dienstes, der ein \u00f6ffentliches Protokoll zur Best\u00e4tigung der Authentizit\u00e4t (Transparency Log) f\u00fchrt, wurde bereitgestellt. Um Angriffe auf die Lieferkette und das T\u00e4uschen von Komponenten zu verhindern, wird auch die digitale Signierung von mit den Releases verbundenen Artefakten, einschlie\u00dflich aller installierten Kubernetes-Bin\u00e4rdateien, gew\u00e4hrleistet.\n
Die Aktivierung von APIs, die sich im Beta-Stadium befinden, wurde in Clustern standardm\u00e4\u00dfig eingestellt (die in fr\u00fcheren Versionen hinzugef\u00fcgten experimentellen APIs bleiben erhalten; die \u00c4nderung betrifft nur neue APIs).\n
Unterst\u00fctzung des OpenAPI v3-Formats wurde implementiert.\n
Eine Initiative zur Umstellung von Plugins f\u00fcr die Arbeit mit Speichern auf die einheitliche CSI (Container Storage Interface)-Schnittstelle wurde vorgestellt, wobei die API-Kompatibilit\u00e4t erhalten bleibt. Die Azure Disk- und OpenStack Cinder-Plugins wurden auf CSI umgestellt.\n
Der Kubelet Credential Provider, der es erm\u00f6glicht, Anmeldeinformationen f\u00fcr Container-Image-Repositorys dynamisch \u00fcber die Ausf\u00fchrung von Plugins abzurufen, ohne die Anmeldeinformationen im Dateisystem des Knotens zu speichern, wurde in die Beta-Testphase \u00fcberf\u00fchrt.\n