🥇Kubernetes 1.16: Überblick über die wichtigsten Neuerungen

Heute, am Mittwoch, stattfinden veröffentlichen wir eine neue Version von Kubernetes — 1.16. In Übereinstimmung mit der Tradition unseres Blogs berichten wir nun bereits zum zehnten Mal über die bedeutendsten Änderungen in der neuen Version.

Die Informationen, die zur Erstellung dieses Materials verwendet wurden, stammen aus der Tabelle zur Verfolgung von Kubernetes-Verbesserungen, CHANGELOG-1.16 und den entsprechenden Issues, Pull Requests sowie Kubernetes Enhancement Proposals (KEP). Also, los geht's! ..

Knoten

Eine wirklich große Anzahl bemerkenswerter Neuerungen (im Status Alpha) wurde auf der Seite der K8s-Cluster-Knoten (Kubelet) vorgestellt.

Zunächst wurden die sogenannten «ephemeren Container» (Ephemeral Containers)präsentiert, die darauf abzielen, die Debugging-Prozesse in Pods zu vereinfachen.Der neue Mechanismus ermöglicht das Starten spezieller Container, die im Namensraum vorhandener Pods laufen und nur eine kurze Zeit leben. Ihr Zweck ist die Interaktion mit anderen Pods und Containern, um Probleme zu lösen und Debugging durchzuführen. Für diese Möglichkeit wurde ein neuer Befehl kubectl debugimplementiert, der in seiner Funktionsweise kubectl execähnlich ist: nur anstatt einen Prozess im Container zu starten (wie im Fall von exec) sie startet einen Container im Pod. Zum Beispiel verbindet dieser Befehl einen neuen Container mit dem Pod:

kubectl debug -c debug-shell --image=debian target-pod -- bash

Details zu ephemeral Containers (und Beispiele für deren Verwendung) finden Sie im entsprechenden KEP. Die aktuelle Implementierung (in K8s 1.16) ist eine Alpha-Version, und zu den Kriterien für die Umstellung auf die Beta-Version gehört die "Testung der Ephemeral Containers API über mindestens 2 Releases [Kubernetes]."

NB: Im Grunde genommen und sogar im Namen ähnelt die Funktion bereits dem existierenden Plugin kubectl-debug, über das wir bereits geschrieben haben. Es wird davon ausgegangen, dass mit der Einführung von ephemeral Containers die Entwicklung eines separaten externen Plugins eingestellt wird.

Eine weitere Neuerung — PodOverhead — soll einen Mechanismus zur Berechnung der Overheads für Pods bereitstellen, die je nach verwendeter Ausführungsumgebung (Runtime) stark variieren können. Als Beispiel führen die Autoren dieses KEP führen zu Kata Containers, die den Einsatz eines Gastkernels, eines Kata-Agenten, eines Init-Systems usw. erfordern. Wenn der Overhead so hoch wird, kann er nicht ignoriert werden, und deshalb ist ein Weg erforderlich, um ihn für weiteres Quoten- und Planungsmanagement zu berücksichtigen. PodSpec wurde ein Feld hinzugefügt Overhead *ResourceList (entspricht den Daten in RuntimeClass, falls verwendet).

Eine weitere bemerkenswerte Neuerung ist der Node Topology Manager ., der darauf abzielt, den Ansatz zur Feinabstimmung der Verteilung von Hardware-Ressourcen für verschiedene Komponenten in Kubernetes zu vereinheitlichen. Diese Initiative wird durch die wachsende Nachfrage verschiedener moderner Systeme (aus den Bereichen Telekommunikation, maschinelles Lernen, Finanzdienstleistungen usw.) nach leistungsstarken Parallelverarbeitungen und der Minimierung von Verzögerungen bei der Ausführung von Operationen angetrieben, wobei fortschrittliche Funktionen von CPU und Hardwarebeschleunigung genutzt werden. Solche Optimierungen in Kubernetes wurden bisher durch voneinander getrennte Komponenten (CPU-Manager, Geräte-Manager, CNI) erreicht, und jetzt wird ein einheitliches internes Interface hinzugefügt, das den Ansatz vereinheitlicht und die Anbindung neuer ähnlicher — sogenannter topology-aware — Komponenten auf der Kubelet-Seite vereinfacht. Weitere Details finden Sie in entsprechenden KEP.

Schema der Komponenten des Topology Managers

Das nächste Feature ist die Überprüfung von Containern während ihres Starts (Startup-Probe). Wie bekannt ist, ist es für Container, die lange benötigt werden, schwierig, den aktuellen Status zu ermitteln: Sie werden entweder „getötet“, noch bevor sie wirklich in Betrieb genommen werden, oder sie geraten für längere Zeit in einen Deadlock. Die neue Überprüfung (die über einen Feature-Gate namens StartupProbeEnabled) hebt – genauer gesagt, verschiebt – die Ausführung aller anderen Überprüfungen bis zu dem Zeitpunkt auf, an dem der Pod seinen Start abgeschlossen hat. Aus diesem Grund wurde die Funktion zunächst als pod-startup liveness-probe holdoffbezeichnet. Für Pods, die langsam starten, kann der Zustand in relativ kurzen Zeitabständen abgefragt werden.

Darüber hinaus gibt es bereits in der Beta-Version eine Verbesserung für RuntimeClass, die Unterstützung für „heterogene Cluster“ hinzufügt. Mit RuntimeClass Scheduling ist es nun nicht mehr erforderlich, dass jeder Knoten jeden RuntimeClass unterstützt: Für Pods kann ein RuntimeClass ausgewählt werden, ohne über die Topologie des Clusters nachdenken zu müssen. Früher musste dies erreicht werden – sodass Pods auf Knoten mit vollständiger Unterstützung ihrer Anforderungen landeten – indem entsprechende Regeln für NodeSelector und Tolerierungen festgelegt wurden. In der KEP werden Anwendungsbeispiele und natürlich die Implementierungsdetails behandelt.

Netzwerk

Zwei bedeutende Netzwerk-Features, die erstmals (in der Alpha-Version) in Kubernetes 1.16 vorgestellt wurden, sind:

Support doppelter Netzwerk-Stack — IPv4/IPv6 — und das entsprechende "Verständnis" auf der Ebene der Pods, Knoten und Dienste. Dies umfasst die Interaktion zwischen IPv4-to-IPv4 und IPv6-to-IPv6 zwischen Pods, von Pods zu externen Diensten, Referenzimplementierungen (im Rahmen der Bridge CNI-, PTP CNI- und Host-Local IPAM-Plugins) sowie die Abwärtskompatibilität mit Kubernetes-Clustern, die ausschließlich über IPv4 oder IPv6 arbeiten. Details zur Implementierung finden Sie in. KEP.
Beispielausgabe von zwei Arten von IP-Adressen (IPv4 und IPv6) in der Liste der Pods:
```
kube-master# kubectl get pods -o wide
NAME               READY     STATUS    RESTARTS   AGE       IP                          NODE
nginx-controller   1/1       Running   0          20m       fd00:db8:1::2,192.168.1.3   kube-minion-1
kube-master#
```
Neue API für Endpoint — EndpointSlice API. Diese löst Probleme des bestehenden Endpoint API bezüglich Leistung/Skalierbarkeit, die verschiedene Komponenten im Control-Plane (apiserver, etcd, endpoints-controller, kube-proxy) betreffen. Die neue API wird zur API-Gruppe Discovery hinzugefügt und kann Zehntausende von Backend-Endpunkten für jeden Dienst in einem Cluster mit Tausenden von Knoten bedienen. Dazu wird jeder Service in N Objekte abgebildet. EndpointSlice, von denen standardmäßig nicht mehr als 100 Endpunkte (das Wert ist konfigurierbar) vorhanden sind. Die EndpointSlice-API bietet auch Möglichkeiten für zukünftige Entwicklungen: die Unterstützung mehrerer IP-Adressen pro Pod, neue Status für Endpunkte (nicht nur Bereit und NichtBereit), dynamisches Subsetting für Endpunkte.

Die in der letzten Version vorgestellte Beta-Version Finalizer, genannt service.kubernetes.io/load-balancer-cleanup , wird an jeden Dienst mit dem Typ LoadBalancerangehängt. Beim Löschen eines solchen Dienstes verhindert er die tatsächliche Löschung der Ressource, bis die 'Bereinigung' aller entsprechenden Ressourcen des Lastenausgleichs abgeschlossen ist.

API-Maschinen

Dieser 'Stabilisierung-Meilenstein' ist im Bereich des Kubernetes API-Servers und seiner Interaktionen festgehalten. Dies ist zu einem großen Teil auf die Überführung in den stabilen Status von nicht besonders darstellungsbedürftigen CustomResourceDefinitions (CRD), die seit der weit entfernten Kubernetes-Version 1.7 (Juni 2017) den Beta-Status hatten. Eine ähnliche Stabilisierung gilt auch für die damit verbundenen Features:

'Unterressourcen' (Subresources) , für /status und /scale CustomResources;
Versionskonvertierung für CRD, basierend auf einem externen Webhook;
kürzlich vorgestellt (in K8s 1.15) Standardwerte (Standardisierung) und automatische Entfernung von Feldern (Pruning) CustomResources;
die Möglichkeit Verwendung des OpenAPI v3 Schemas zur Erstellung und Veröffentlichung von OpenAPI-Dokumentation, die zur Validierung von CRD-Ressourcen auf der Serverseite verwendet wird.

Ein weiterer Mechanismus, der Administratoren von Kubernetes vertraut ist: Admission Webhook war ebenfalls lange Zeit im Beta-Status (seit K8s 1.9) und wurde nun als stabil erklärt.

Zwei weitere Funktionen haben die Beta-Phase erreicht: Server-seitige Anwendung und Watch Bookmarks.

Und die einzige nennenswerte Neuerung in der Alpha-Version war der Verzicht auf ab SelfLink - eine spezielle URI, die das angegebene Objekt darstellt und Teil von ObjectMeta und ListMeta (d.h. Teil jedes Objekts in Kubernetes). Warum wird darauf verzichtet? Die Motivation „einfach gesagt“ ertönt wie das Fehlen echter (unüberwindbarer) Gründe, warum dieses Feld weiterhin existieren sollte. Formalere Gründe sind die Optimierung der Leistungsfähigkeit (durch die Entfernung eines unnötigen Feldes) und die Vereinfachung der Arbeit des generic-apiserver, der gezwungen ist, ein solches Feld auf besondere Weise zu verarbeiten (es ist das einzige Feld, das direkt vor der Serialisierung des Objekts gesetzt wird). Das eigentliche „Erschöpfen“ (im Rahmen der Beta-Version) SelfLink wird auf Version Kubernetes 1.20 stattfinden, und die endgültige - 1.21.

Datenspeicherung

Die Hauptarbeit im Bereich Storage, wie in den vorherigen Versionen, konzentriert sich auf die Unterstützung von CSI. Die wichtigsten Änderungen hier sind:

zum ersten Mal (in der Alpha-Version) wurde eingeführt die Unterstützung von CSI-Plugins für Windows-Worker-Knoten: ein aktueller Weg zur Arbeit mit Speichern wird hier die in-tree Plugins im Kubernetes-Kern und die FlexVolume-Plugins von Microsoft basierend auf Powershell ersetzen;

Das Implementierungsschema von CSI-Plugins in Kubernetes für Windows
die Möglichkeit die Größenänderung von CSI-Volumes, vorgestellt in K8s 1.12, hat den Beta-Status erreicht;
eine ähnliche 'Höhenanpassung' (von Alpha- zu Beta-Version) hat die Möglichkeit erreicht, CSI für die Erstellung von lokalen ephemeral Volumes zu verwenden (CSI Inline Volume Support).

Die in der vorherigen Version von Kubernetes eingeführte Funktion zum Klonen von Volumes (die Verwendung vorhandener PVC als DataSource zur Erstellung neuer PVC) hat jetzt ebenfalls den Beta-Status erhalten.

Scheduler

Zwei bemerkenswerte Änderungen im Scheduling (beide in Alpha-Version):

EvenPodsSpreading — die Möglichkeit belastete Pods anstelle von logischen Anwendungseinheiten für eine 'faire Verteilung' zu verwenden (wie Deployment und ReplicaSet) und Anpassungen dieser Verteilung (als harte Anforderung oder als weiche Bedingung, d.h. Priorität). Diese Funktion wird die bestehenden Möglichkeiten der Verteilung geplanter Pods erweitern, die derzeit durch Optionen eingeschränkt sind. PodAffinity und PodAntiAffinity, indem sie Administratoren eine präzisere Kontrolle in dieser Angelegenheit bieten, was zu höherer Verfügbarkeit und optimiertem Ressourcenverbrauch führt. Weitere Informationen finden Sie in KEP.
Nutzung BestFit Policy in RequestedToCapacityRatio Priority Function bei der Planung von Pods, was es ermöglicht, anzuwenden bin packing („Containerverpackung“) sowohl für grundlegende Ressourcen (CPU, RAM) als auch für erweiterte Ressourcen (wie GPU). Weitere Details finden Sie in KEP.

Pod-Planung: vor der Verwendung der Best-Fit-Policy (direkt über den Standard-Scheduler) und mit deren Verwendung (über den Scheduler-Extender)

Darüber hinaus, wurde eingeführt die Möglichkeit, eigene Plugins für den Scheduler außerhalb des Hauptentwicklungsbaums von Kubernetes (out-of-tree) zu erstellen.

Weitere Änderungen

Außerdem kann im Release von Kubernetes 1.16 die Initiative zur Ordnung der vorhandenen Metriken , genauer gesagt — die Übereinstimmung mitden offiziellen Vorgaben zur Instrumentierung von K8s. Diese basieren im Wesentlichen auf der entsprechenden Dokumentation von Prometheus. die Prometheus-Dokumentation. Die Inkonsistenzen sind aus verschiedenen Gründen entstanden (zum Beispiel wurden einige Metriken einfach schon vor der Veröffentlichung der aktuellen Anweisungen erstellt), und die Entwickler haben beschlossen, dass es an der Zeit ist, alles auf einen einheitlichen Standard zu bringen, "in Übereinstimmung mit dem Rest des Prometheus-Ökosystems". Die derzeitige Umsetzung dieser Initiative hat den Status einer Alpha-Version, die in den kommenden Kubernetes-Versionen schrittweise auf Beta (1.17) und dann auf stabil (1.18) angehoben wird.

Darüber hinaus sind die folgenden Änderungen zu verzeichnen:

Weiterentwicklung der Unterstützung für Windows mit mit dem Erscheinen des Kubeadm-Tools für dieses Betriebssystem (Alpha-Version), verfügbar mit der RunAsUserName Option für Windows-Container (Alpha-Version), Verbesserungen der Unterstützung von Group Managed Service Accounts (gMSA) bis zur Beta-Version, die Unterstützung von mount/attach für vSphere-Volumes.
Überarbeiteter Datenkompressionsmechanismus in API-Antworten. Früher wurde zu diesem Zweck ein HTTP-Filter verwendet, der eine Reihe von Einschränkungen aufwies, die eine standardmäßige Aktivierung verhinderten. Nun funktioniert die "transparente Kompression von Anfragen": Klienten, die Accept-Encoding: gzip Im Header erhalten Sie eine komprimierte GZIP-Antwort, wenn deren Größe 128 KB überschreitet. Kunden auf Go unterstützen automatisch die Komprimierung (versenden den erforderlichen Header), sodass sie sofort eine Verringerung des Traffics feststellen. (Für andere Sprachen sind möglicherweise kleine Anpassungen erforderlich.)
die PID in den Tab-Tooltips anzuzeigen (browser.tabs.tooltipsShowPid). HPA-Skalierung von/bis zu null Pods basierend auf externen Metriken. Wenn die Skalierung basierend auf Objekten/externalen Metriken erfolgt, können Sie automatisch auf 0 Replikate skalieren, um Ressourcen zu sparen, wenn die Arbeitslasten pausiert sind. Diese Funktion sollte besonders nützlich sein, wenn Worker GPU-Ressourcen anfordern und die Anzahl der verschiedenen Arten von inaktiven Workern die verfügbaren GPUs übersteigt.
Neuer Client — k8s.io/client-go/metadata.Client — für den „generischen“ Zugriff auf Objekte. Er ist dafür konzipiert, Metadaten (d.h. die Unterteilung metadata) aus den Cluster-Ressourcen einfach abzurufen und Operationen wie Garbage Collection und Quota-Management durchzuführen.
Kubernetes zu sammeln ist jetzt möglich ohne veraltete („in-tree“ integrierte) Cloud-Anbieter (Alpha-Version).
Das Tool kubeadm wurde erweitert Die experimentelle (Alpha-Version) Möglichkeit, Kustomize-Patches während der Operationen anzuwenden. init, beitreten und upgrade. Weitere Informationen zur Verwendung des Flags --experimental-kustomize, siehe KEP.
Neuer Endpoint für den Apiservice — readyz, — ermöglicht das Exportieren von Informationen über seine Bereitschaft (Readiness). Der API-Server hat außerdem das Flag --maximum-startup-sequence-duration, das die Neustarts regelt.
Zwei Features für Azure wurden für stabil erklärt: Unterstützung von Verfügbarkeitszonen (Availability Zones) und cross resource group (RG). Außerdem wurden in Azure hinzugefügt:
- Unterstützung für Authentifizierung AAD und ADFS;
- Annotation service.beta.kubernetes.io/azure-pip-name zum Angeben der öffentlichen IP des Load-Balancers;
- die Möglichkeit Einstellungen LoadBalancerName und LoadBalancerResourceGroup.
AWS hat für EBS in Windows Unterstützung für optimierte API-Aufrufe EC2 DescribeInstances. Kubeadm migriert nun selbstständig.
die Konfiguration von CoreDNS bei der Aktualisierung der CoreDNS-Version. Die Binärdateien etcd
sind im entsprechenden Docker-Image world-executable, was das Ausführen dieses Images ohne Root-Rechte ermöglicht. Darüber hinaus hat das etcd-Migrations-Image die Unterstützung für die Version etcd2 eingestellt. Cluster Autoscaler 1.16.0 die Möglichkeit geschaffen, Linux-Betriebssysteme mit dem Steuerpanel ISPmanager 5 Lite zu installieren. weltweit ausführbar, was die Ausführung dieses Images ohne root-Rechte ermöglicht. Darüber hinaus unterstützt das Migration-Image etcd eingestellt Version etcd2.
In Cluster Autoscaler 1.16.0 Wir haben auf Distroless als Basis-Image umgestellt, die Leistung verbessert und neue Cloud-Anbieter (DigitalOcean, Magnum, Packet) hinzugefügt.
Aktualisierungen in der verwendeten/abhängigen Software: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

P.S.

Lesen Sie auch in unserem Blog:

Quelle: habr.com

Kubernetes 1.16: Überblick über die wichtigsten Neuerungen