🥇Kubernetes 1.16: Überblick über die wichtigsten Neuerungen

Heute, Mittwoch, gehalten nächste Version von Kubernetes - 1.16. Gemäß der Tradition, die sich für unseren Blog entwickelt hat, sprechen wir bereits zum zehnten Mal über die wichtigsten Änderungen in der neuen Version.

Die zur Erstellung dieses Materials verwendeten Informationen stammen aus Tabellen zur Nachverfolgung von Kubernetes-Erweiterungen, CHANGELOG-1.16 und verwandte Probleme, Pull Requests und Kubernetes Enhancement Proposals (KEP). So lass uns gehen!..

Knoten

Auf der Seite der K8s-Clusterknoten (Kubelet) werden wirklich viele bemerkenswerte Neuerungen (im Alpha-Versionsstatus) vorgestellt.

Erstens das sogenannte «vergängliche Behälter» (Vergängliche Behälter), entworfen, um Debugging-Prozesse in Pods zu vereinfachen. Mit dem neuen Mechanismus können Sie spezielle Container starten, die im Namensraum vorhandener Pods starten und für kurze Zeit aktiv sind. Ihr Zweck besteht darin, mit anderen Pods und Containern zu interagieren, um etwaige Probleme zu lösen und Fehler zu beheben. Für diese Funktion wurde ein neuer Befehl implementiert kubectl debug, im Wesentlichen ähnlich zu kubectl exec: nur, anstatt einen Prozess in einem Container auszuführen (wie in exec) startet es einen Container in einem Pod. Mit diesem Befehl wird beispielsweise ein neuer Container mit einem Pod verbunden:

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

Einzelheiten zu kurzlebigen Containern (und Beispiele für deren Verwendung) finden Sie in entsprechenden KEP. Die aktuelle Implementierung (in K8s 1.16) ist eine Alpha-Version, und zu den Kriterien für die Überführung in eine Beta-Version gehört „das Testen der Ephemeral Containers API für mindestens 2 Releases von [Kubernetes]“.

NB: Im Wesentlichen und sogar im Namen ähnelt die Funktion einem bereits vorhandenen Plugin kubectl-debugworüber wir schon geschrieben. Es wird erwartet, dass mit dem Aufkommen kurzlebiger Container die Entwicklung eines separaten externen Plugins eingestellt wird.

Eine weitere Innovation - PodOverhead - entworfen, um bereitzustellen Mechanismus zur Berechnung der Gemeinkosten für Pods, die je nach verwendeter Laufzeit stark variieren kann. Als Beispiel die Autoren dieses KEP Dies führt zu Kata-Containern, die die Ausführung des Gastkernels, des Kata-Agenten, des Init-Systems usw. erfordern. Wenn der Overhead so groß wird, kann er nicht ignoriert werden, was bedeutet, dass es eine Möglichkeit geben muss, ihn bei weiteren Quoten, Planung usw. zu berücksichtigen. Um es umzusetzen PodSpec Feld hinzugefügt Overhead *ResourceList (vergleicht mit Daten in RuntimeClass, falls einer verwendet wird).

Eine weitere bemerkenswerte Innovation ist Knotentopologiemanager (Knotentopologie-Manager), entwickelt, um den Ansatz zur Feinabstimmung der Zuweisung von Hardwareressourcen für verschiedene Komponenten in Kubernetes zu vereinheitlichen. Diese Initiative wird durch den wachsenden Bedarf verschiedener moderner Systeme (aus dem Bereich Telekommunikation, maschinelles Lernen, Finanzdienstleistungen usw.) an Hochleistungs-Parallelrechnen und der Minimierung von Verzögerungen bei der Ausführung von Vorgängen vorangetrieben, für die sie fortschrittliche CPUs und verwenden Hardwarebeschleunigungsfunktionen. Solche Optimierungen in Kubernetes wurden bisher dank unterschiedlicher Komponenten (CPU-Manager, Gerätemanager, CNI) erreicht, und nun wird ihnen eine einzige interne Schnittstelle hinzugefügt, die den Ansatz vereinheitlicht und die Verbindung neuer ähnlicher – sogenannter Topologien – vereinfacht. bewusst - Komponenten auf der Kubelet-Seite. Details - in entsprechenden KEP.

Komponentendiagramm des Topologie-Managers

Nächstes Feature - Überprüfen von Containern, während sie ausgeführt werden (Startprobe). Wie Sie wissen, ist es bei Containern, deren Start lange dauert, schwierig, einen aktuellen Status zu erhalten: Sie werden entweder „getötet“, bevor sie tatsächlich funktionieren, oder sie bleiben für lange Zeit im Stillstand. Neue Prüfung (aktiviert durch Feature-Gate namens StartupProbeEnabled) hebt die Wirkung aller anderen Prüfungen auf, oder verschiebt sie vielmehr, bis der Pod seine Ausführung beendet hat. Aus diesem Grund wurde das Feature ursprünglich aufgerufen Pod-Startup Liveness-Probe Holdoff. Bei Pods, deren Start lange dauert, können Sie den Status in relativ kurzen Zeitintervallen abfragen.

Darüber hinaus ist ab sofort eine Verbesserung für RuntimeClass im Beta-Status verfügbar, die Unterstützung für „heterogene Cluster“ hinzufügt. C Laufzeitklassenplanung Jetzt ist es überhaupt nicht mehr notwendig, dass jeder Knoten jede RuntimeClass unterstützt: Für Pods können Sie eine RuntimeClass auswählen, ohne sich Gedanken über die Cluster-Topologie zu machen. Um dies zu erreichen – sodass Pods auf Knoten landen, die alles unterstützen, was sie benötigen – war es bisher notwendig, dem NodeSelector und den Toleranzen entsprechende Regeln zuzuweisen. IN KEP Es geht um Anwendungsbeispiele und natürlich um Implementierungsdetails.

Netzwerk

Zwei wichtige Netzwerkfunktionen, die erstmals (in der Alpha-Version) in Kubernetes 1.16 erschienen, sind:

Unterstützen Dualer Netzwerkstapel – IPv4/IPv6 - und das entsprechende „Verständnis“ auf der Ebene von Pods, Knoten und Diensten. Es umfasst IPv4-zu-IPv4- und IPv6-zu-IPv6-Interoperabilität zwischen Pods, von Pods zu externen Diensten, Referenzimplementierungen (innerhalb der Plugins Bridge CNI, PTP CNI und Host-Local IPAM) sowie Rückwärtskompatibilität mit laufenden Kubernetes-Clustern Nur IPv4 oder IPv6. Einzelheiten zur Implementierung finden Sie in KEP.
Ein Beispiel für die Anzeige von IP-Adressen zweier Typen (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. Es löst die Leistungs-/Skalierbarkeitsprobleme der vorhandenen Endpoint-API, die sich auf verschiedene Komponenten in der Steuerungsebene (Apiserver, etcd, Endpoints-Controller, Kube-Proxy) auswirken. Die neue API wird der Discovery-API-Gruppe hinzugefügt und kann Zehntausende Backend-Endpunkte für jeden Dienst in einem Cluster bestehend aus Tausenden von Knoten bedienen. Dazu wird jeder Service auf N Objekte abgebildet EndpointSlice, von denen jeder standardmäßig nicht mehr als 100 Endpunkte hat (der Wert ist konfigurierbar). Die EndpointSlice-API wird auch Möglichkeiten für ihre zukünftige Entwicklung bieten: Unterstützung für mehrere IP-Adressen für jeden Pod, neue Zustände für Endpunkte (nicht nur Ready и NotReady), dynamische Teilmenge für Endpunkte.

Die in der letzten Version vorgestellte Version hat die Beta-Version erreicht Finalizer, genannt service.kubernetes.io/load-balancer-cleanup und an jeden Dienst mit Typ angehängt LoadBalancer. Zum Zeitpunkt des Löschens eines solchen Dienstes wird das tatsächliche Löschen der Ressource verhindert, bis die „Bereinigung“ aller relevanten Balancer-Ressourcen abgeschlossen ist.

API-Maschinen

Der eigentliche „Stabilisierungsmeilenstein“ liegt im Bereich des Kubernetes API-Servers und der Interaktion mit diesem. Dies geschah vor allem dank Überführung in einen stabilen Status derjenigen, die keiner besonderen Einführung bedürfen CustomResourceDefinitions (CRD), die seit den fernen Tagen von Kubernetes 1.7 (und das ist Juni 2017!) Beta-Status haben. Die gleiche Stabilisierung erfolgte bei den zugehörigen Funktionen:

„Unterressourcen“ mit /status и /scale für CustomResources;
Transformation Versionen für CRD, basierend auf externem Webhook;
kürzlich vorgestellt (in K8s 1.15) Standardwerte (Standard) und automatische Feldentfernung (Beschneidung) für CustomResources;
Gelegenheit Verwenden des OpenAPI v3-Schemas zum Erstellen und Veröffentlichen der OpenAPI-Dokumentation, die zur Validierung von CRD-Ressourcen auf der Serverseite verwendet wird.

Ein weiterer Mechanismus, der Kubernetes-Administratoren längst bekannt ist: Zulassungs-Webhook - blieb ebenfalls lange im Beta-Status (seit K8s 1.9) und gilt nun als stabil.

Zwei weitere Funktionen haben die Beta-Phase erreicht: serverseitig gelten и Lesezeichen ansehen.

Und die einzige wesentliche Neuerung in der Alpha-Version war Ausfall aus SelfLink – ein spezieller URI, der das angegebene Objekt darstellt und Teil davon ist ObjectMeta и ListMeta (d. h. Teil eines beliebigen Objekts in Kubernetes). Warum geben sie es auf? Motivation auf einfache Weise klingt als das Fehlen wirklicher (überwältigender) Gründe dafür, dass dieses Feld noch existiert. Formalere Gründe bestehen darin, die Leistung zu optimieren (durch Entfernen eines unnötigen Felds) und die Arbeit des generic-apiservers zu vereinfachen, der gezwungen ist, ein solches Feld auf besondere Weise zu verarbeiten (dies ist das einzige Feld, das direkt vor dem Objekt gesetzt wird). serialisiert ist). Echte Obsoleszenz (innerhalb der Betaphase) SelfLink Dies geschieht mit der Kubernetes-Version 1.20 und der endgültigen Version 1.21.

Datenspeicherung

Die Hauptarbeiten im Bereich Lagerung werden wie in früheren Versionen im Bereich beobachtet CSI-Unterstützung. Die wesentlichen Änderungen waren hier:

zum ersten Mal (in der Alpha-Version) erschienen CSI-Plugin-Unterstützung für Windows-Worker-Knoten: Die aktuelle Arbeitsweise mit Speicher wird auch In-Tree-Plugins im Kubernetes-Kern und FlexVolume-Plugins von Microsoft auf Basis von Powershell ersetzen;

Schema zur Implementierung von CSI-Plugins in Kubernetes für Windows
Gelegenheit Größenänderung von CSI-Volumes, das bereits in K8s 1.12 eingeführt wurde, ist zu einer Betaversion gewachsen;
Eine ähnliche „Beförderung“ (von Alpha zu Beta) wurde durch die Möglichkeit erreicht, CSI zum Erstellen lokaler kurzlebiger Volumes zu verwenden (CSI-Inline-Volume-Unterstützung).

Eingeführt in der vorherigen Version von Kubernetes Funktion zum Klonen von Volumes (unter Verwendung von vorhandenem PVC wie DataSource zur Herstellung von neuem PVC) hat nun ebenfalls den Beta-Status erhalten.

Planer

Zwei bemerkenswerte Änderungen an der Planung (beide in der Alpha-Phase):

EvenPodsSpreading - Gelegenheit Verwenden Sie Pods anstelle logischer Anwendungseinheiten für eine „faire Verteilung“ der Lasten (wie Deployment und ReplicaSet) und Anpassen dieser Verteilung (als harte Anforderung oder als weiche Bedingung, d. h. Priorität). Die Funktion wird die bestehenden Verteilungsmöglichkeiten geplanter Pods erweitern, die derzeit durch Optionen begrenzt sind PodAffinity и PodAntiAffinityDies gibt Administratoren eine genauere Kontrolle in dieser Angelegenheit, was eine bessere Hochverfügbarkeit und einen optimierten Ressourcenverbrauch bedeutet. Details - in KEP.
Verwenden BestFit-Richtlinie в RequestedToCapacityRatio-Prioritätsfunktion während der Pod-Planung, die es ermöglichen wird применять Behälterverpackung („Verpacken in Container“) sowohl für grundlegende Ressourcen (Prozessor, Speicher) als auch für erweiterte Ressourcen (wie GPU). Weitere Einzelheiten finden Sie unter KEP.

Pods planen: vor der Verwendung der Best-Fit-Richtlinie (direkt über den Standard-Scheduler) und mit ihrer Verwendung (über den Scheduler-Extender)

Außerdem, vertreten die Möglichkeit, eigene Scheduler-Plugins außerhalb des Hauptentwicklungsbaums von Kubernetes (Out-of-Tree) zu erstellen.

Andere Änderungen

Auch in der Kubernetes 1.16-Version können Sie darauf achten Initiative für bringen verfügbare Metriken in vollständiger Reihenfolge, oder genauer gesagt, gemäß behördliche Vorschriften zur K8-Instrumentierung. Sie verlassen sich weitgehend auf das entsprechende Prometheus-Dokumentation. Aus verschiedenen Gründen kam es zu Inkonsistenzen (zum Beispiel wurden einige Metriken einfach erstellt, bevor die aktuellen Anweisungen erschienen), und die Entwickler entschieden, dass es an der Zeit sei, alles auf einen einzigen Standard zu bringen, „im Einklang mit dem Rest des Prometheus-Ökosystems“. Die aktuelle Implementierung dieser Initiative befindet sich im Alpha-Status, der in nachfolgenden Versionen von Kubernetes schrittweise auf Beta (1.17) und Stable (1.18) hochgestuft wird.

Darüber hinaus sind folgende Änderungen festzustellen:

Windows unterstützt die Entwicklung с das Aufkommen von Kubeadm-Dienstprogramme für dieses Betriebssystem (Alpha-Version), Gelegenheit RunAsUserName für Windows-Container (Alpha-Version), Verbesserung Group Managed Service Account (gMSA)-Unterstützung bis zur Beta-Version, Unterstützung Mounten/Anhängen für vSphere-Volumes.
Recycelt Datenkomprimierungsmechanismus in API-Antworten. Zuvor wurde für diese Zwecke ein HTTP-Filter verwendet, der eine Reihe von Einschränkungen mit sich brachte, die eine standardmäßige Aktivierung verhinderten. „Transparente Anfragekomprimierung“ funktioniert jetzt: Clients senden Accept-Encoding: gzip Im Header erhalten sie eine GZIP-komprimierte Antwort, wenn die Größe 128 KB überschreitet. Go-Clients unterstützen automatisch die Komprimierung (Senden des erforderlichen Headers), sodass sie sofort eine Reduzierung des Datenverkehrs bemerken. (Für andere Sprachen können geringfügige Änderungen erforderlich sein.)
Wurde möglich Skalierung von HPA von/auf null Pods basierend auf externen Metriken. Wenn Sie auf der Grundlage von Objekten/externen Metriken skalieren, können Sie bei Leerlauf von Arbeitslasten automatisch auf 0 Replikate skalieren, um Ressourcen zu sparen. Diese Funktion sollte besonders in Fällen nützlich sein, in denen Arbeiter GPU-Ressourcen anfordern und die Anzahl der verschiedenen Arten von inaktiven Arbeitern die Anzahl der verfügbaren GPUs übersteigt.
Neuer Kunde - k8s.io/client-go/metadata.Client — für „allgemeinen“ Zugriff auf Objekte. Es wurde entwickelt, um Metadaten (z. B. Unterabschnitte) einfach abzurufen metadata) aus Cluster-Ressourcen und führen Sie Garbage-Collection- und Kontingentoperationen mit ihnen durch.
Erstellen Sie Kubernetes kann jetzt ohne veraltete („integrierte“ im Baum) Cloud-Anbieter (Alpha-Version).
Zum kubeadm-Dienstprogramm hinzugefügt experimentelle (Alpha-Version) Möglichkeit, benutzerdefinierte Patches während des Betriebs anzuwenden init, join и upgrade. Erfahren Sie mehr über die Verwendung der Flagge --experimental-kustomize, sehen in KEP.
Neuer Endpunkt für Apiserver - readyz, - ermöglicht Ihnen den Export von Informationen über seine Bereitschaft. Auch der API-Server verfügt jetzt über ein Flag --maximum-startup-sequence-duration, sodass Sie die Neustarts regulieren können.
zwei Funktionen für Azure für stabil erklärt: Unterstützung Verfügbarkeitszonen (Verfügbarkeitszonen) und ressourcengruppenübergreifend (RG). Darüber hinaus hat Azure Folgendes hinzugefügt:
- Authentifizierungsunterstützung AAD und ADFS;
- abstrakt service.beta.kubernetes.io/azure-pip-name um die öffentliche IP des Load Balancers anzugeben;
- Gelegenheit настройки LoadBalancerName и LoadBalancerResourceGroup.
AWS hat es jetzt unterstützen für EBS unter Windows und optimiert EC2-API-Aufrufe DescribeInstances.
Kubeadm ist jetzt unabhängig wandert CoreDNS-Konfiguration beim Upgrade der CoreDNS-Version.
Binärdateien usw im entsprechenden Docker-Image getan haben World-Executable, mit dem Sie dieses Image ausführen können, ohne dass Root-Rechte erforderlich sind. Außerdem ein etcd-Migrationsbild aufgehört Unterstützung der etcd2-Version.
В Cluster-Autoscaler 1.16.0 Umstellung auf die Verwendung von Distroless als Basis-Image, verbesserte Leistung, Hinzufügung neuer Cloud-Anbieter (DigitalOcean, Magnum, Packet).
Updates in verwendeter/abhängiger Software: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

PS

Lesen Sie auch auf unserem Blog:

Source: habr.com

Kubernetes 1.16: Highlights der Neuerungen