EinfĂŒhrung der Container-Orchestrierungsplattform , die es ermöglicht, einen Cluster aus isolierten Containern als Ganzes zu verwalten, und Mechanismen fĂŒr das Deployment, die Wartung und das Skalieren von in Containern laufenden Anwendungen bereitstellt. Das Projekt wurde ursprĂŒnglich von Google ins Leben gerufen, dann aber auf eine unabhĂ€ngige Plattform ĂŒbertragen, die von der Linux Foundation betreut wird. Die Plattform wird als universelle Lösung fĂŒr eine sich entwickelnde Gemeinschaft positioniert, die nicht an bestimmte Systeme gebunden ist und mit allen Anwendungen in allen Cloud-Umgebungen arbeiten kann. Der Kubernetes-Code ist in Go geschrieben und unter der Apache 2.0 Lizenz.
stellt Funktionen fĂŒr das Deployment und die Verwaltung der Infrastruktur bereit, wie z.B. DNS-Management, Lastverteilung,
Verteilung der Container auf die Knoten des Clusters (Migration der Container je nach LastĂ€nderung und Dienstbedarf), ĂberprĂŒfung der AnwendungsintegritĂ€t, Verwaltung von Konten, Aktualisierung und dynamisches Skalieren des laufenden Clusters, ohne es anzuhalten. Es ist möglich, Gruppen von Containern bereitzustellen, bei denen Aktualisierungs- und Rollback-Operationen sofort fĂŒr die gesamte Gruppe durchgefĂŒhrt werden, sowie logische Partitionierung des Clusters mit Ressourcenteilung. Eine UnterstĂŒtzung fĂŒr dynamische Anwendungs-Migration ist gegeben, fĂŒr die sowohl lokale Speicher als auch Netzwerkspeichersysteme verwendet werden können.
Die Veröffentlichung von Kubernetes 1.18 umfasst 38 Ănderungen und Verbesserungen, von denen 15 in den stabilen Status ĂŒberfĂŒhrt wurden, 11 in den Beta-Status. 12 neue Ănderungen wurden im Alpha-Status vorgeschlagen. Bei der Vorbereitung der neuen Version wurden gleichwertige Anstrengungen sowohl fĂŒr die Verbesserung verschiedener FunktionalitĂ€ten und die Stabilisierung experimenteller Funktionen als auch fĂŒr die HinzufĂŒgung neuer Entwicklungen eingesetzt. Zu den wichtigsten Ănderungen gehören:
- Kubectl
- Alpha-Version des Befehls âkubectl debugâ, der die Fehlersuche in Pods erleichtert, indem er ephemeral Container mit Debugging-Tools startet.
- Befehl âkubectl diffâ, der es ermöglicht zu sehen, was sich im Cluster Ă€ndern wird, wenn das Manifest angewendet wird.
- alle Generatoren des Befehls âkubectl runâ, mit Ausnahme des Generators zum Starten eines einzelnen Pods.
- Das Flag «âdry-run», abhĂ€ngig von seinem Wert (client, server und none), fĂŒhrt die TestausfĂŒhrung des Befehls entweder auf der Client- oder der Serverseite aus.
- Der kubectl-Code in ein separates Repository ausgelagert. Dadurch konnte kubectl von internen AbhÀngigkeiten von Kubernetes getrennt werden, was den Import des Codes in Drittprojekte erleichtert.
- Ingress
- Ănderung der API-Gruppe fĂŒr Ingress auf networking.v1beta1.
- Neue Felder:
- pathType, das angibt, wie der Pfad in der Anfrage verglichen wird.
- IngressClassName â Ersatz fĂŒr die Annotation kubernetes.io/ingress.class, die als veraltet gilt. In diesem Feld wird der Name eines speziellen Objekts IngressClass angegeben.
- Das IngressClass-Objekt, in dem der Name des Ingress-Controllers, seine zusĂ€tzlichen Parameter und das Zeichen fĂŒr seine Standardverwendung angegeben sind.
- Service
- Das Feld AppProtocol, in dem angegeben werden kann, welches Protokoll die Anwendung verwendet.
- in den Beta-Status ĂŒberfĂŒhrt und standardmĂ€Ăig aktiviert EndpointSlicesAPI, das eine funktionsreichere Alternative zu den normalen Endpoints darstellt.
- Netzwerk
- IPv6 wurde in den Beta-Status ĂŒberfĂŒhrt.
- Persistent Disks. Folgende FunktionalitÀt wurde als stabil erklÀrt:
- Konfiguration der Anwendung
- In die Objekte ConfigMap und Secret. ein neues Feld «immutable». Das Festlegen des Wertes dieses Feldes auf true verbietet die Ănderung des Objekts.
- Scheduler
- die Möglichkeit, zusĂ€tzliche Profile fĂŒr kube-scheduler zu erstellen. Wenn zuvor separate zusĂ€tzliche Scheduler zur Implementierung von Nicht-Standard-Algorithmen zur Pod-Zuweisung erforderlich waren, besteht nun die Möglichkeit, zusĂ€tzliche EinstellungssĂ€tze fĂŒr den Standard-Scheduler zu erstellen und seinen Namen im selben Feld des Pods «.spec.schedulerName» anzugeben. Status â Alpha.
- wurde als stabil erklÀrt.
- Skalierung
- die Möglichkeit, im Manifest HPA den Grad der AggressivitĂ€t beim Ăndern der Anzahl der gestarteten Pods anzugeben, das heiĂt, bei steigender Last sofort N-mal mehr Instanzen zu starten.
- Kubelet
- hat den Beta-Status erhalten. Die Funktion umfasst die NUMA-Zuweisung, die eine Leistungsverschlechterung in Multi-Socket-Systemen vermeidet.
- Beta-Status die Funktion PodOverhead, die es ermöglicht, in RuntimeClass die zusÀtzliche Menge an Ressourcen anzugeben, die erforderlich ist, um einen Pod zu starten.
- UnterstĂŒtzung von HugePages, die Isolation auf Container-Ebene wurde in den Alpha-Status hinzugefĂŒgt, sowie die UnterstĂŒtzung mehrerer GröĂen von HugePages.
- Endpoint fĂŒr Metriken /metrics/resource/v1alpha1, stattdessen wird /metrics/resource verwendet
- API
- Die Möglichkeit, die veralteten API-Gruppen apps/v1beta1 und extensions/v1beta1 zu verwenden, wurde entfernt.
- Auf Beta2 erhöht. Diese Verbesserung verlagert die Objektmanipulation von kubectl zum API-Server. Die Autoren der Verbesserung behaupten, dass dies viele bestehende Fehler beheben wird, die in der aktuellen Situation nicht behoben werden können. Sie haben auch den Abschnitt â.metadata.managedFieldsâ hinzugefĂŒgt, in dem die Ănderungshistorie des Objekts gespeichert werden soll, mit Angabe von wer, wann und was genau geĂ€ndert hat.
- Stabiles CertificateSigningRequest API.
- UnterstĂŒtzung fĂŒr die Windows-Plattform.
- Die UnterstĂŒtzung von Windows-Nodes wird weiterhin ausgebaut. Alpha-Versionen hinzugefĂŒgt:
- Die UnterstĂŒtzung fĂŒr die Gruppenverwalteten Dienstkonten wurde in den stabilen Status ĂŒberfĂŒhrt
- Die UnterstĂŒtzung von Windows-Nodes wird weiterhin ausgebaut. Alpha-Versionen hinzugefĂŒgt:
Quelle: opennet.ru
