Heute, am Mittwoch, der nächste Release von Kubernetes — 1.16. Nach Tradition für unseren Blog berichten wir nun schon zum zehnten Mal über die bedeutendsten Änderungen in der neuen Version.
Die Informationen, die zur Vorbereitung dieses Materials verwendet wurden, stammen aus , und den entsprechenden Issues, Pull Requests sowie den Kubernetes Enhancement Proposals (KEP). Also, los geht's!..
Nodes
Eine wirklich große Anzahl bemerkenswerter Neuerungen (im Alpha-Status) wurde auf der Node-Seite der K8s-Cluster (Kubelet) vorgestellt.
Zunächst wurden die sogenannten «» (Ephemeral Containers), die darauf abzielen, die Debugging-Prozesse in Pods zu erleichtern, vorgestellt.Der neue Mechanismus ermöglicht das Starten spezieller Container, die im Namensraum vorhandener Pods gestartet werden und nur kurze Zeit leben. Ihr Zweck ist die Interaktion mit anderen Pods und Containern zur Lösung von Problemen und zum Debugging. Für diese Möglichkeit wurde ein neuer Befehl implementiert, kubectl debug, der in seiner Funktionalität mit kubectl exec: vergleichbar ist — nur dass anstelle des Startens eines Prozesses im Container (wie im Falle von exec) ein Container im Pod gestartet wird. Ein solches Kommando fügt einen neuen Container zu einem Pod hinzu:
kubectl debug -c debug-shell --image=debian target-pod -- bashDetails zu den ephemeren Containern (und Beispiele für deren Nutzung) finden Sie in . Die aktuelle Implementierung (in K8s 1.16) ist eine Alpha-Version, und unter den Kriterien für ihre Überführung in den Beta-Status steht "Testen der Ephemeral Containers API über mindestens 2 Releases [Kubernetes]".
NB: In ihrer Natur und sogar im Namen ähnelt die Funktionalität bereits bestehenden Plugins, , über die wir . Es wird angenommen, dass mit dem Erscheinen der ephemeren Container die Entwicklung eines separaten externen Plugins eingestellt wird.
Eine weitere Neuerung — — soll einen Mechanismus zur Berechnung der Overheads für Pods bereitstellen,die je nach verwendeter Ausführungsumgebung (Runtime) stark variieren können. Als Beispiel nennen die Autoren Kata Containers, die das Starten eines Gastkernels, eines Kata-Agenten, eines Init-Systems usw. erfordern. Wenn der Overhead so groß wird, dass er nicht ignoriert werden kann, ist ein Verfahren erforderlich, um ihn für die weitere Quotenverwaltung, Planung usw. zu berücksichtigen. Zu diesem Zweck wurde im PodSpec ein Feld hinzugefügt, Overhead *ResourceList (entspricht den Daten in RuntimeClass, sofern vorhanden).
Ein weiteres bemerkenswertes neues Feature ist der Node Topology Manager (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 ergibt sich aus dem wachsenden Bedarf verschiedener moderner Systeme (aus den Bereichen Telekommunikation, maschinelles Lernen, Finanzdienstleistungen usw.) an leistungsstarkem parallelem Rechnen und der Minimierung von Verzögerungen bei der Ausführung von Operationen, wofür sie die erweiterten Möglichkeiten von CPU und Hardware-Beschleunigung nutzen. Solche Optimierungen in Kubernetes wurden bisher durch disparate Komponenten (CPU-Manager, Device-Manager, CNI) erreicht, und nun wird eine einheitliche interne Schnittstelle hinzugefügt, die den Ansatz vereinheitlicht und die Anbindung neuer ähnlicher — sogenannter topology-aware — Komponenten auf der Kubelet-Seite vereinfacht. Einzelheiten finden Sie in .
der Komponentenschema des Topology Managers
Das nächste Feature ist die Überprüfung von Containern während ihres Starts (). Wie bekannt ist, ist es bei Containern, die lange für den Start brauchen, schwierig, den aktuellen Status zu erhalten: Sie werden entweder „abgeschossen“, bevor sie tatsächlich funktionieren, oder sie geraten für lange Zeit in einen Deadlock. Die neue Überprüfung (die über ein Feature-Gate mit dem Namen StartupProbeEnabled) hebt — genauer gesagt, verschiebt — die Ausführung aller anderen Überprüfungen bis zu dem Moment auf, an dem der Pod seinen Start abgeschlossen hat. Aus diesem Grund wurde das Feature ursprünglich als bezeichnet. Für Pods, die lange starten, kann der Status in relativ kurzen Zeitintervallen abgefragt werden.
Darüber hinaus wird sofort in der Beta-Version eine Verbesserung für RuntimeClass vorgestellt, die die Unterstützung für „heterogene Cluster“ hinzufügt. Mit ist es nun nicht mehr zwingend erforderlich, dass jeder Knoten jede RuntimeClass unterstützt: Für Pods kann eine RuntimeClass ausgewählt werden, ohne sich um die Topologie des Clusters Gedanken zu machen. Früher musste, um dies zu erreichen — damit Pods auf Knoten landen, die alles unterstützen, was sie benötigen — entsprechende Regeln für NodeSelector und Toleranzen festgelegt werden. In werden Anwendungsbeispiele und natürlich Details zur Umsetzung beschrieben.
Netzwerk
Zwei bedeutende Netzwerkfunktionen, die erstmals (in der Alpha-Version) in Kubernetes 1.16 eingeführt wurden, sind:
- doubles stack — IPv4/IPv6 — und das entsprechende „Verständnis“ auf der Ebene von Pods, Knoten, Services. Es umfasst die IPv4-zu-IPv4- und IPv6-zu-IPv6-Interaktionen zwischen Pods, von Pods zu externen Services, Referenzimplementierungen (im Rahmen der Bridge CNI-, PTP CNI- und Host-Local IPAM-Plugins) sowie die Abwärtskompatibilität mit Kubernetes-Clustern, die nur über IPv4 oder IPv6 arbeiten. Details zur Implementierung finden Sie in .
Beispielausgabe von IP-Adressen zweier Arten (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 — . Es löst die Probleme der bestehenden Endpoint-API hinsichtlich 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 Service in einem Cluster, der aus Tausenden von Knoten besteht, bedienen. Dazu wird jeder Service in N Objekte umgewandelt
EndpointSlice, die standardmäßig maximal 100 Endpunkte haben (dieser Wert ist konfigurierbar). In der EndpointSlice API sind auch zukünftige Erweiterungsmöglichkeiten vorgesehen: Unterstützung für mehrere IP-Adressen pro Pod, neue Zustände für Endpunkte (nicht nurBereitundNotReady), dynamisches Subsetting für Endpunkte.
Bis zur Beta-Version ist der in der letzten Veröffentlichung vorgestellte , genannt service.kubernetes.io/load-balancer-cleanup , und wird an jeden Service des Typs LoadBalancer, angeheftet. Bei der Löschung eines solchen Services verhindert er das tatsächliche Löschen der Ressource, bis die „Bereinigung“ aller entsprechenden Ressourcen des Load-Balancers abgeschlossen ist.
API Machinery
Dieses „Stabilisierungsetappe“ wurde im Bereich des Kubernetes API-Servers und der Interaktion mit ihm festgehalten. Vieles geschah dank der Überführung in den stabilen Status von nicht besonders darstellungsbedürftigen (CRD), die seit der fernen Kubernetes-Version 1.7 (Juni 2017) den Beta-Status hatten. Dieselbe Stabilisierung wurde auch für die damit verbundenen Funktionen erreicht:
- für
/statusund/scaleCustomResources; - die kürzlich eingeführten
- (defaulting) und die automatische Entfernung von Feldern (pruning) der Anwendung des OpenAPI v3-Schemas zur Erstellung und Veröffentlichung von OpenAPI-Dokumentationen, die zur Validierung von CRD-Ressourcen auf der Serverseite verwendet werden. CustomResources;
- Verwendung des OpenAPI v3-Schemas zur Erstellung und Veröffentlichung von OpenAPI-Dokumentationen, die zur Validierung von CRD-Ressourcen auf der Serverseite verwendet werden.
Ein weiterer Mechanismus, der für Kubernetes-Administratoren mittlerweile zur Gewohnheit geworden ist: — befand sich ebenfalls lange Zeit im Beta-Status (seit K8s 1.9) und ist jetzt als stabil erklärt.
Zwei weitere Funktionen haben die Beta-Version erreicht: und .
Das einzige bedeutende Novum in der Alpha-Version war ab SelfLink — eine spezielle URI, die das angegebene Objekt repräsentiert und Teil von ObjectMeta und ListMeta (d.h. Teil jedes Objekts in Kubernetes). Warum wird darauf verzichtet? Die Motivation "auf einfache Weise" wie das Fehlen tatsächlicher (unüberwindbarer) Gründe, warum dieses Feld weiterhin bestehen sollte. Formalere Gründe sind die Leistungsoptimierung (indem unnötige Felder entfernt werden) 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). Die tatsächliche "Abwärtskompatibilität" (im Rahmen der Beta-Version) SelfLink wird mit der Version Kubernetes 1.20 eintreten, die endgültige mit 1.21.
Datenspeicherung
Die Hauptarbeit im Bereich Storage, wie auch in den vorherigen Releases, erfolgt im Bereich . Die wichtigsten Änderungen hier sind:
- zunächst (in der Alpha-Version) die Unterstützung von CSI-Plugins für Worker-Knoten mit Windows: die aktuelle Methode zur Arbeit mit Speichern wird hier die in-kernel Plugins in Kubernetes und die FlexVolume-Plugins von Microsoft auf Powershell-Basis ersetzen;
Das Schema zur Implementierung von CSI-Plugins in Kubernetes für Windows - die Möglichkeit , das bereits in K8s 1.12 vorgestellt wurde, hat die Beta-Version erreicht;
- eine ähnliche "Einstufung" (von Alpha zu Beta) ist die Möglichkeit, CSI zur Erstellung von lokalen ephemeralen Volumes zu verwenden ().
Die in der vorherigen Kubernetes-Version (Verwendung vorhandener PVC als DataSource zur Erstellung neuer PVC) hat ebenfalls den Beta-Status erreicht.
Scheduler
Zwei bemerkenswerte Änderungen in der Planung (beide in Alpha):
- — die Möglichkeit, für die "gerechte Verteilung" von Lasten Pods anstelle von logischen Einheit von Anwendungen zu verwenden (wie Deployment und ReplicaSet) und diese Verteilung zu regulieren (als strenge Anforderung oder als weiche Bedingung, d.h. Priorität). Diese Funktion wird die bestehenden Möglichkeiten zur Verteilung geplanter Pods erweitern, die derzeit durch die Optionen PodAffinity
PodAntiAffinityundPodAntiAffinity, indem den Administratoren eine feinere Kontrolle in dieser Angelegenheit eingeräumt wird, was eine höhere Verfügbarkeit und optimierten Ressourcenverbrauch zur Folge hat. Einzelheiten — in . - Verwendung BestFit-Richtlinie in RequestedToCapacityRatio-Prioritätsfunktion bei der Planung von Pods, was es ermöglichen wird, einzusetzen („Containerverpackung“) sowohl für grundlegende Ressourcen (CPU, Speicher) als auch für erweiterte (wie GPU). Weitere Informationen finden Sie in .
Pod-Planung: vor der Verwendung der Best-Fit-Politik (direkt über den Default-Scheduler) und mit ihrer Verwendung (über den Scheduler Extender)
Außerdem, 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 in Kubernetes 1.16 auf folgendes hingewiesen werden: die Initiative zur bestehender Metriken, genauer gesagt — in Übereinstimmung mit zur Instrumentierung von K8s. Diese basieren größtenteils auf der entsprechenden . Unstimmigkeiten sind aus verschiedenen Gründen entstanden (zum Beispiel wurden einige Metriken einfach schon erstellt, bevor die aktuellen Anweisungen erschienen), und die Entwickler haben beschlossen, dass es an der Zeit sei, alles auf einen einheitlichen Standard zu bringen, „in Übereinstimmung mit dem restlichen Prometheus-Ökosystem“. Die aktuelle Umsetzung dieser Initiative hat den Status einer Alpha-Version, der in den nachfolgenden Kubernetes-Versionen schrittweise auf Beta (1.17) und stabil (1.18) angehoben wird.
Darüber hinaus können folgende Änderungen hervorgehoben werden:
- Entwicklung der Windows-Unterstützung c des Kubeadm-Tools für dieses Betriebssystem (Alpha-Version),
RunAsUserNamefür Windows-Containern (Alpha-Version), der Unterstützung von Gruppenverwalteten Dienstkonten (gMSA) bis zur Beta-Version, mount/attach für vSphere-Volumes. - Datenkomprimierungsmechanismus in API-Antworten. Früher wurde dafür ein HTTP-Filter verwendet, der eine Reihe von Einschränkungen mit sich brachte, die seine Verwendung standardmäßig verhinderten. Jetzt funktioniert die „transparente Kompression von Anfragen“: Clients, die
Accept-Encoding: gzipim Header senden, erhalten eine GZIP-komprimierte Antwort, wenn deren Größe 128 Kb überschreitet. Clients in Go unterstützen automatisch die Kompression (senden den benötigten Header), sodass sie sofort einen Rückgang des Datenverkehrs bemerken. (Für andere Sprachen sind möglicherweise geringfügige Modifikationen erforderlich.) - Skalierung von HPA aus / zu null Pods basierend auf externen Metriken. Wenn das Scaling auf Basis von Objekten / externen Metriken erfolgt, kann automatisch auf 0 Replikate skaliert werden, wenn die Workloads inaktiv sind, um Ressourcen zu sparen. Diese Funktion ist besonders nützlich in Fällen, in denen Worker GPU-Ressourcen anfordern und die Anzahl der verschiedenen Arten inaktiver Worker die Anzahl der verfügbaren GPUs übersteigt.
- Neuer Kunde — — für den "generischen" Zugriff auf Objekte. Er ist dafür gedacht, Metadaten (d.h. Unterteilungen
in der Ressourcenspezifikation des Pods. Genauere Informationen finden Sie im) aus den Clusterressourcen einfach zu erhalten und Operationen wie Garbage Collection und Quota Management durchzuführen. - Kubernetes zu sammeln ohne veraltete ("in-tree" integrierte) Cloud-Anbieter (Alpha-Version).
- In das Tool kubeadm wurde eine experimentelle (Alpha-Version) Möglichkeit integriert, Kustomize-Patches während des
init,joinundupgrade. Weitere Informationen zur Verwendung des Flags--experimental-kustomize, siehe . - Neuer Endpunkt für apiserver — , — der es ermöglicht, Informationen über seine Bereitschaft (readiness) zu exportieren. Der API-Server hat auch ein Flag erhalten
--maximum-startup-sequence-duration, das es ermöglicht, seine Neustarts zu steuern. - Zwei Funktionen für Azure wurden als stabil erklärt: Unterstützung für (Availability Zones) und (RG). Darüber hinaus wurden in Azure hinzugefügt:
- AAD und ADFS;
-
service.beta.kubernetes.io/azure-pip-namezum Festlegen einer öffentlichen IP für den Lastenausgleich; - von Einstellungen
LoadBalancerNameundLoadBalancerResourceGroup.
- AWS hat jetzt für EBS in Windows API-Aufrufe EC2
DescribeInstances. - Kubeadm migriert jetzt selbstständig Binärdateien
- etcd im entsprechenden Docker-Image wurden world-executable gemacht, was es ermöglicht, dieses Image ohne Root-Rechte zu starten. Darüber hinaus hat das etcd-Migrationsimage Cluster Autoscaler 1.16.0 Aktualisierungen in der verwendeten / abhängigen Software: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.
- Im Kubernetes 1.14: Übersicht über die Hauptneuerungen
- Kubernetes 1.13: Übersicht über die Hauptneuerungen
P.S.
Lesen Sie auch in unserem Blog:
- «»;
- «»;
- «»;
- «».
Quelle: habr.com
