🥇Kubernetes 1.17: Übersicht der wichtigsten Neuerungen

Gestern, 9. Dezember, statt ein neuer Release von Kubernetes — 1.17. Wie gewohnt, berichten wir in unserem Blog über die bedeutendsten Änderungen in der neuen Version.

Kubernetes 1.17: Überblick über die wichtigsten Neuerungen.

Die Informationen, die zur Vorbereitung dieses Materials verwendet wurden, stammen aus der offiziellen Ankündigung, der Tabelle zur Verfolgung von Kubernetes-Verbesserungen, CHANGELOG-1.17 sowie den entsprechenden Issues, Pull Requests und Kubernetes Enhancement Proposals (KEP). Was gibt es Neues?..

Topologie-bewusste Routing

Schon lange wurde in der Kubernetes-Community auf dieses Feature gewartet — Topology-aware service routinguseString KEP seine Ursprünge liegen im Oktober 2018, während die offizielle Erweiterung vor 2 Jahren erfolgt ist, während die regulären Issues (wie dieses Ergebnis herauskommt) in der Tat noch einige Jahre älter sind…

Die Grundidee ist, die Möglichkeit zu bieten, eine „lokale“ Routing-Implementierung für in Kubernetes befindliche Services zu ermöglichen. „Lokalität“ bedeutet in diesem Fall „auf derselben topologischen Ebene“ (topology level),die sein kann:

der gleiche Knoten für die Services,
das gleiche Serverrack,
der gleiche Region,
der gleiche Cloud-Anbieter.
…

Beispiele für die Verwendung dieses Features:

Einsparungen bei der Bandbreite in Cloud-Installationen mit mehreren Verfügbarkeitszonen (multi-AZ) — siehe die aktuelle Illustration beispielsweise anhand des Traffics einer Region, jedoch mit unterschiedlichen AZ in AWS;
geringere Latenzen in der Performance / bessere Bandbreite;
shardierter Service, der lokale Informationen über den Knoten in jedem Shard hat;
Platzierung von fluentd (oder ähnlichen Diensten) auf einem Knoten mit den Anwendungen, deren Protokolle gesammelt werden;
…

Eine solche Routing-Methode, die über die Topologie informiert ist, wird auch als netzwerknah bekannt — analog zu node affinity, pod affinity / anti-affinity oder dem neu eingeführten nicht allzu lange her Topology-Aware Volume Scheduling (und Volume Provisioning). Der aktuelle Implementierungsstand ServiceTopology in Kubernetes — Alpha-Version.

Detailinformationen darüber, wie die Funktion gestaltet ist und wie man sie bereits nutzen kann, finden Sie in in diesem Artikel einem Beitrag eines der Autoren.

Unterstützung für Dual-Stack IPv4 / IPv6

Bedeutende Fortschritte wurden verzeichnet in einer anderen Netzwerktechnologie: gleichzeitige Unterstützung von zwei IP-Stacks, die erstmals in K8s 1.16. Insbesondere brachte das neue Release folgende Änderungen:

im kube-proxy wurde Möglichkeit, simultan in beiden Modi (IPv4 und IPv6) zu arbeiten;
in Pod.Status.PodIPs wurde eingeführt Unterstützung des Downward API (gleichzeitig erfordert dies, dass für den Host auch eine IPv6-Adresse hinzugefügt wird); /etc/hosts Unterstützung von zwei Stacks in
(Kubernetes IN Docker) und KIND aktualisierte e2e-Tests. kubeadm zu wechseln.;
обновлённые e2e-тесты.

Kubernetes 1.17: Überblick über die wichtigsten Neuerungen.
Illustration Nutzung des doppelten Stacks IPV4/IPv6 in KIND

Fortschritt bei CSI

Ist jetzt stabil angekündigt. Unterstützung von Topologien für Speicher auf Basis von CSI, erstmals präsentiert in K8s 1.12.

Initiative zur Migration von Volume-Plugins zu CSI — CSI Migration hat die Beta-Version erreicht. Dieses Feature ist entscheidend, um vorhandene Speicher-Plugins (in-tree) auf eine moderne Schnittstelle (CSI, out-of-tree) nahtlos für die Endbenutzer von Kubernetes zu migrieren. Cluster-Administratoren müssen lediglich die CSI-Migration aktivieren, danach werden bestehende Stateful-Ressourcen und Workloads weiterhin „einfach funktionieren“ … jedoch mit den aktuellen CSI-Treibern anstelle der veralteten, die im Kubernetes-Kernel enthalten sind.

Derzeit ist die Migration für AWS EBS-Treiber (kubernetes.io/aws-ebs) und GCE PD (kubernetes.io/gce-pd) im Status der Beta-Version verfügbar. Die Prognosen für andere Speicher sind wie folgt:

Kubernetes 1.17: Überblick über die wichtigsten Neuerungen.

Wie die „traditionelle“ Unterstützung von Speichern in K8s zu CSI kam, haben wir in in diesem Artikel. Der Übergang der CSI-Migration zum Status der Beta-Version wird in einer separaten Veröffentlichung im Projektblog behandelt.

Darüber hinaus erreichte eine weitere bedeutende Funktionalität im Kontext von CSI, die ihren Anfang (Alpha-Implementierung) in K8s 1.12 nahm, mit der Version Kubernetes 1.17 den Status einer Beta-Version (d.h. standardmäßig aktiviert), Snapshots erstellen und aus ihnen wiederherstellen. Zu den Änderungen, die auf dem Weg zur Beta-Version von Kubernetes Volume Snapshot vorgenommen wurden, gehören:

Die Aufteilung des CSI external-snapshotter Sidecars in zwei Controller,
es wurde ein Löschgeheimnis (deletion secret) hinzugefügt als Annotation des Volumensnapshots,
ein neuer Finalizer (finalizer) zum Schutz vor der Löschung des API-Objekts des Snapshots, solange noch Referenzen bestehen.

Zum Zeitpunkt des Releases 1.17 wird die Funktion von drei CSI-Treibern unterstützt: GCE Persistent Disk CSI Driver, Portworx CSI Driver und NetApp Trident CSI Driver. Weitere Informationen zur Implementierung und Nutzung finden Sie in In dieser Veröffentlichung dem Blog.

Cloud Provider Labels

Labels, die automatisch auf die erstellten Knoten und Volumes in Abhängigkeit vom verwendeten Cloud-Anbieter angewendet werden,sind in Kubernetes schon seit langem als Beta-Version verfügbar — seit der Veröffentlichung von K8s 1.2 (April 2016!). Angesichts ihrer langjährigen breiten Anwendung war es für die Entwickler nun an der Zeit, die Funktion als stabil (GA) zu verkünden. haben, что настало время объявить фичу стабильной (GA).

Daher wurden sie entsprechend umbenannt (nach Topologien):

beta.kubernetes.io/instance-type → node.kubernetes.io/instance-type
failure-domain.beta.kubernetes.io/zone → topology.kubernetes.io/zone
failure-domain.beta.kubernetes.io/region → topology.kubernetes.io/region

… sind aber weiterhin unter ihren alten Namen verfügbar (zur Rückwärtskompatibilität). Allen Administratoren wird jedoch geraten, auf die aktuellen Labels umzusteigen. Entsprechende Dokumentation K8s wurde aktualisiert.

Strukturierte Ausgabe von kubeadm

Wurde erstmals im Alpha-Format vorgestellt strukturierte Ausgabe für das Tool kubeadm. Unterstützte Formate: JSON, YAML, Go-Template.

Die Motivation zur Umsetzung dieses Features (laut KEP) ist folgende:

Obwohl Kubernetes manuell bereitgestellt werden kann, ist der De-facto-Standard (wenn nicht de jure) für diese Operation die Verwendung von kubeadm. Beliebte Systemmanagement-Tools wie Terraform basieren auf kubeadm für die Bereitstellung von Kubernetes. Geplante Verbesserungen im Cluster API umfassen ein kompilierbares Paket zum Bootstrapping von Kubernetes mit kubeadm und cloud-init.
Ohne strukturierte Ausgabe können selbst die harmlosesten auf den ersten Blick Änderungen Terraform, Cluster API und andere Software, die auf den Ergebnissen von kubeadm basieren, brechen.

In naher Zukunft ist die Unterstützung (in Form einer strukturierten Ausgabe) für die folgenden kubeadm-Befehle geplant:

alpha certs
config images list
init
token create
token list
upgrade plan
version

Illustration der JSON-Antwort auf den Befehl kubeadm init -o json:

{
  "node0": "192.168.20.51:443",
  "caCrt": "sha256:1f40ff4bd1b854fb4a5cf5d2f38267a5ce5f89e34d34b0f62bf335d74eef91a3",
  "token": {
    "id":          "5ndzuu.ngie1sxkgielfpb1",
    "ttl":         "23h",
    "expires":     "2019-05-08T18:58:07Z",
    "usages":      [
      "authentication",
      "signing"
    ],
    "description": "Der standardmäßige Bootstrap-Token, der von 'kubeadm init' generiert wird.",
    "extraGroups": [
      "system:bootstrappers:kubeadm:default-node-token"
    ]
  },
  "raw": "Rm9yIHRoZSBhY3R1YWwgb3V0cHV0IG9mIHRoZSAia3ViZWFkbSBpbml0IiBjb21tYW5kLCBwbGVhc2Ugc2VlIGh0dHBzOi8vZ2lzdC5naXRodWIuY29tL2FrdXR6LzdhNjg2ZGU1N2JmNDMzZjkyZjcxYjZmYjc3ZDRkOWJhI2ZpbGUta3ViZWFkbS1pbml0LW91dHB1dC1sb2c="
}

Stabilisierung anderer Neuerungen

Der Kubernetes 1.17 Release fand unter dem Motto "Stabilität" statt. Dies wurde durch die Tatsache gefördert, dass viele der Features in ihm (insgesamt 14) den GA-Status erhielten. Dazu gehören:

die "Tainting" von Knoten unter bestimmten Bedingungen (TaintNodesByCondition), die in K8s 1.8;
Watch Bookmarks — ein neuer Typ von Ereignissen, der markiert, dass alle Objekte bis zu einer bestimmten Version (resourceVersion) bereits durch den Watcher verarbeitet wurden;
Standardwerte (Defaulting) für Custom Resources;
zwischen Containern im Pod geteilte Prozess-Namensräume;
ScheduleDaemonSetPods — Planung von Pods im DaemonSet mit kube-scheduler (statt DaemonSet-Controller);
dynamische Limits für die Anzahl von Volumes abhängig vom Knotentyp;
Unterstützung von Umgebungsvariablen für Verzeichnisnamen, die als subPath;
Übertragung von Kubelet-Herzanstößen in die spezialisierte Lease-API;
„Finalizer-Schutz“ (Finalizer Protection) für Lastenausgleichsserver (Prüfung der entsprechenden Ressourcen des Service vor der Löschung der LoadBalancer-Ressourcen);
Optimierung von kube-apiserver in der Leistung beim Arbeiten mit vielen Watches, die die gleichen Objektsätze beobachten — erreicht durch das Vermeiden der Wiederserialisierung der gleichen Objekte für jeden Watcher.

Weitere Änderungen

Die vollständige Liste der Neuerungen in Kubernetes 1.17 beschränkt sich natürlich nicht auf die oben genannten. Hier sind einige andere (für eine vollständige Liste — siehe CHANGELOG):

die in der vorherigen Version vorgestellte Funktion hat die Beta-Phase erreicht RunAsUserName für Windows;
eine ähnliche Änderung hat das EndpointSlice-API (auch aus K8s 1.16) getroffen, jedoch ist diese Lösung zur Verbesserung der Leistung/Skalierbarkeit des Endpoint-APIs derzeit nicht standardmäßig aktiviert;
Kritische Pods für den Betrieb des Clusters können jetzt nicht nur im Namespace erstellt werden kube-system (siehe Details in der Dokumentation zu Limitierung des Verbrauchs der Prioritätsklasse);
neue Option für kubelet — --reserved-cpus — ermöglicht die explizite Festlegung einer Liste von CPUs, die für das System reserviert sind;
für kubectl logs wurde vorgestellt neues Flag --prefix, das den Namen des Pods und des Container-Quell zu jeder Zeile im Log hinzufügen;
in label.Selector wurde erweitert RequiresExactMatch;
alle Container in kube-dns werden jetzt mit geringeren Berechtigungen gestartet; in ein separates GitHub-Repository ausgelagert und wird nicht mehr in die Kubernetes-Releases aufgenommen;
hyperkube Leistungsverbesserung
erheblich kube-proxy für Nicht-UDP-Ports. Änderungen bei Abhängigkeiten:

CoreDNS-Version in kubeadm — 1.6.5;

crictl-Version auf v1.16.1 aktualisiert;
CSI 1.2.0;
etcd 3.4.3;
die letzte getestete Docker-Version wurde auf 19.03 erhöht;
die minimale Go-Version, die für den Build von Kubernetes 1.17 erforderlich ist, beträgt 1.13.4.
Gestern, am 9. Dezember, fand die neue Veröffentlichung von Kubernetes — 1.17 statt. Wie es für unseren Blog Tradition ist, berichten wir über die bedeutendsten Änderungen in der neuen Version. Die Informationen zu diesem Material stammen aus der offiziellen Ankündigung, der Tabelle zum Verfolgen der Kubernetes-Verbesserungen, CHANGELOG-1.17 und entsprechenden Issues, Pull-Requests sowie Kubernetes Enhancement Proposals (KEP). Also, was gibt es Neues?.. Routing mit

P.S.

Lesen Sie auch in unserem Blog:

Quelle: habr.com