🐫 👨🏼‍🚀 😐 Kubernetes 1.17: Übersicht der wichtigsten Neuerungen 🦏 🤹 💱

Gestern, 9. Dezember, die nächste Veröffentlichung von Kubernetes - 1.17. Entsprechend der Tradition für unseren Blog sprechen wir über die wichtigsten Änderungen in der neuen Version.

Die Informationen, die zur Vorbereitung dieses Materials verwendet wurden, stammen aus der offiziellen Ankündigung, der Nachverfolgungstabelle für Kubernetes-Verbesserungen , CHANGELOG-1.17 und verwandten Problemen, Pull-Anforderungen sowie Kubernetes Enhancement Proposals (KEP). Also, was ist neu? ..

Topologiebasiertes Routing

Die Kubernetes-Community hat lange auf diese Funktion gewartet - topologiebezogenes Service-Routing . Wenn KEP im Oktober 2018 darauf basiert und die offizielle Erweiterung vor 2 Jahren ist, dann sind die üblichen Probleme (wie dieses ) noch ein paar Jahre älter ...

Die allgemeine Idee besteht darin, die Möglichkeit zu bieten, "lokales" Routing für Dienste in Kubernetes zu implementieren. "Lokalität" bedeutet in diesem Fall "dieselbe topologische Ebene" (Topologieebene) , die sein kann:

gleicher Knoten für Dienste,
gleiches Server-Rack
die gleiche Region
der gleiche Cloud-Anbieter
...

Beispiele für die Verwendung einer solchen Funktion:

Einsparung von Datenverkehr in Cloud-Installationen mit vielen Verfügbarkeitszonen (Multi-AZs) - siehe die neueste Abbildung am Beispiel des Datenverkehrs aus einer Region, aber unterschiedlicher AZs in AWS;
geringere Latenz bei der Leistung / besserer Durchsatz;
einen Shard-Dienst, der in jedem Shard lokale Knoteninformationen enthält;
Platzieren von Fluentd (oder Analoga) auf einem Knoten mit Anwendungen, deren Protokolle gesammelt werden;
...

Dieses Routing, das die Topologie „kennt“, wird auch als Affinität der Netzwerkaffinität bezeichnet - ähnlich wie Knotenaffinität , Pod-Affinität / Anti-Affinität oder das kürzlich eingeführte topologiebewusste Volume-Scheduling (und Volume-Provisioning ). Die aktuelle Implementierungsstufe von ServiceTopology in Kubernetes ist die Alpha-Version.

In diesem Artikel eines Autors erfahren Sie, wie das Feature angeordnet ist und wie es bereits verwendet werden kann.

IPv4 / IPv6-Dual-Stack-Unterstützung

In einem anderen Netzwerkmerkmal wurden erhebliche Fortschritte erzielt : Die gleichzeitige Unterstützung von zwei IP-Stacks, die erstmals in K8s 1.16 eingeführt wurde . Insbesondere die neue Version brachte die folgenden Änderungen:

kube-proxy implementiert die Möglichkeit des gleichzeitigen Betriebs in beiden Modi (IPv4 und IPv6);
Unterstützung für die Downward-API ist in Pod.Status.PodIPs (gleichzeitig erfordern /etc/hosts jetzt das Hinzufügen einer IPv6-Adresse für den Host).
Unterstützung für zwei Stapel in KIND (Kubernetes IN Docker) und kubeadm ;
Aktualisierte e2e-Tests.

KIND IPV4 / IPv6 Dual Stack Abbildung

CSI-Fortschritt

Die Topologieunterstützung für CSI-basierte Repositorys, die erstmals in K8 1.12 eingeführt wurde, wurde für stabil erklärt .

CSI Migration Volume Plugins- Initiative - CSI-Migration - Beta erreicht. Diese Funktion ist wichtig, um vorhandene In-Tree- Plug-Ins unbemerkt von Kubernetes-Endbenutzern auf eine moderne Schnittstelle (CSI, out-of-tree) zu übertragen . Für Cluster-Administratoren ist es ausreichend, die CSI-Migration zu aktivieren, wonach die vorhandenen statusbehafteten Ressourcen und Workloads weiterhin "nur" funktionieren. Statt der im Kubernetes-Kernel enthaltenen veralteten Treiber werden jedoch aktuelle CSI-Treiber verwendet.

Derzeit ist der Migrationsstatus für die AWS EBS-Treiber ( kubernetes.io/aws-ebs ) und GCE PD ( kubernetes.io/gce-pd ) im kubernetes.io/gce-pd bereit. Die Prognosen für andere Repositorys lauten wie folgt:

Wie die „traditionelle“ Speicherunterstützung in K8 zu CSI kam, haben wir in diesem Artikel besprochen. Ein Übergang zur Migration von CSI im Beta-Status ist einer separaten Veröffentlichung im Blog des Projekts gewidmet.

Darüber hinaus wurde der Status der Beta-Version (d. H. Die Standardeinstellung) in Kubernetes 1.17 durch eine weitere wichtige Funktionalität im Kontext von CSI erreicht, die aus (Alpha-Implementierung) in K8 1.12 stammt - Erstellen von Snapshots und Wiederherstellen von diesen . Zu den Änderungen in Kubernetes Volume Snapshot auf dem Weg zur Beta-Version:

Aufteilung des externen CSI-Snapshotter des Beiwagens in zwei Controller,
Löschgeheimnis als Anmerkung zum Inhalt des Volume-Schnappschusses hinzugefügt,
Ein neuer Finalizer, der das Entfernen des Snapshot-API-Objekts verhindert, wenn noch Verbindungen bestehen.

Zum Zeitpunkt der Veröffentlichung 1.17 wird die Funktion von drei CSI-Treibern unterstützt: GCE Persistent Disk CSI-Treiber, Portworx CSI-Treiber und NetApp Trident CSI-Treiber. Weitere Informationen zur Implementierung und Verwendung finden Sie in diesem Blogbeitrag.

Cloud-Anbieter-Labels

Bezeichnungen, die den erstellten Knoten und Volumes abhängig vom verwendeten Cloud-Anbieter automatisch zugewiesen werden , sind in Kubernetes seit sehr langer Zeit als Beta-Version verfügbar - beginnend mit der Veröffentlichung von K8s 1.2 (April 2016!) . In Anbetracht der langen Verbreitung der Funktion entschieden die Entwickler , dass es an der Zeit war, die Funktion für stabil (GA) zu erklären.

Daher wurden sie alle entsprechend umbenannt (nach Topologie):

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

... aber immer noch unter den alten Namen verfügbar (aus Gründen der Abwärtskompatibilität). Alle Administratoren werden jedoch aufgefordert, zu den aktuellen Labels zu wechseln. Die relevante K8- Dokumentation wurde aktualisiert.

Strukturierte Ausgabe kubeadm

Im Alpha-Format wird zum ersten Mal eine strukturierte Ausgabe für das Dienstprogramm kubeadm angezeigt . Unterstützte Formate: JSON, YAML, Go-Template.

Die Motivation für die Implementierung dieser Funktion (gemäß KEP ) ist wie folgt:

Obwohl Kubernetes manuell bereitgestellt werden können, ist der De-facto-Standard (wenn nicht de jure) für diesen Vorgang die Verwendung von kubeadm. Bekannte Systemverwaltungstools wie Terraform setzen bei der Kubernetes-Bereitstellung auf kubeadm. Zu den geplanten Verbesserungen der Cluster-API gehört ein komponierbares Paket für Kubernetes-Bootstrapping mit Kubeadm und Cloud-Init.

Ohne strukturierte Ausgabe können selbst die harmlosesten Änderungen auf den ersten Blick Terraform, die Cluster-API und andere Software, die die Ergebnisse von kubeadm verwendet, beschädigen.

In naher Zukunft werden (in Form einer strukturierten Ausgabe) die folgenden kubeadm-Befehle unterstützt:

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

Abbildung der JSON-Antwort auf den 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": "The default bootstrap token generated by 'kubeadm init'.", "extraGroups": [ "system:bootstrappers:kubeadm:default-node-token" ] }, "raw": "Rm9yIHRoZSBhY3R1YWwgb3V0cHV0IG9mIHRoZSAia3ViZWFkbSBpbml0IiBjb21tYW5kLCBwbGVhc2Ugc2VlIGh0dHBzOi8vZ2lzdC5naXRodWIuY29tL2FrdXR6LzdhNjg2ZGU1N2JmNDMzZjkyZjcxYjZmYjc3ZDRkOWJhI2ZpbGUta3ViZWFkbS1pbml0LW91dHB1dC1sb2c=" }

Stabilisierung anderer Innovationen

Generell stand die Veröffentlichung von Kubernetes 1.17 unter dem Motto " Stabilität ". Dies wurde durch die Tatsache erleichtert, dass so viele Funktionen (ihre Gesamtzahl ist 14 ) GA-Status erhielten. Unter diesen:

"Markieren" von Knoten unter bestimmten Bedingungen ( TaintNodesByCondition ), die in K8s 1.8 erschienen sind ;
Watch Bookmarks - eine neue Art von Ereignissen mit der Bezeichnung, dass alle Objekte bis zu einer bestimmten Version ( resourceVersion ) bereits von watch verarbeitet wurden;
Standardwerte für benutzerdefinierte Ressourcen;
geteilt zwischen Containern in den Pod-Prozess-Namespaces;
ScheduleDaemonSetPods - Planen von Pods in DaemonSet mithilfe von kube-scheduler (anstelle des DaemonSet-Controllers);
dynamische Begrenzung der Anzahl der Datenträger in Abhängigkeit vom Knotentyp;
Unterstützung für Umgebungsvariablen für Verzeichnisnamen, die als subPath ;
Portierung von Kubelet-Heartbeats auf eine spezialisierte Lease-API;
" Finalizer-Schutz " für Load Balancer (Überprüfung der entsprechenden Service-Ressourcen vor dem Löschen der LoadBalancer-Ressourcen);
Die Optimierung der Leistung von kube-apiserver bei der Arbeit mit mehreren Überwachungen, die identische Objektmengen überwachen, wird erreicht, indem vermieden wird, dass dieselben Objekte für jeden Überwacher erneut serialisiert werden.

Andere Änderungen

Die vollständige Liste der Neuerungen in Kubernetes 1.17 ist natürlich nicht auf die oben aufgeführten beschränkt. Hier sind einige andere von ihnen (und für eine vollständigere Liste - siehe CHANGELOG ):

Die Beta-Version von RunAsUserName für Windows, die in der vorherigen Version vorgestellt wurde, ist auf die Beta-Version angewachsen.
Eine ähnliche Änderung betraf die EndpointSlice-API (ebenfalls ab K8s 1.16). Bisher wurde diese Lösung zur Verbesserung der Leistung / Skalierbarkeit der Endpoint-API jedoch nicht standardmäßig aktiviert.
Pods, die für den Cluster-Betrieb kritisch sind, können jetzt nicht nur in den kube-system Namespaces erstellt werden (weitere kube-system Sie in der Dokumentation zum Verbrauch der Limit Priority Class ) .
Mit einer neuen Option für kubelet - --reserved-cpus - können Sie explizit eine Liste der für das System reservierten CPUs definieren.
Für kubectl logs ein neues Flag kubectl logs - Präfix, bei dem jeder Zeile des Protokolls der Name des Pods und der kubectl logs hinzugefügt werden.
in label.Selector hinzugefügt RequiresExactMatch ;
Alle Container in kube-dns werden jetzt mit weniger Berechtigungen ausgeführt.
hyperkube ist einem separaten GitHub-Repository zugeordnet und wird in Kubernetes-Releases nicht mehr enthalten sein.
Deutlich verbesserte Cube-Proxy- Leistung für Nicht-UDP-Ports.

Abhängigkeitsänderungen:

CoreDNS-Version in kubeadm - 1.6.5;
Crictl-Version auf v1.16.1 aktualisiert;
CSI 1.2.0;
etcd 3.4.3;
Die neueste getestete Version von Docker wurde auf den Stand 03/19 aktualisiert.
Die minimale Go-Version, die zum Erstellen von Kubernetes 1.17 erforderlich ist, ist 1.13.4.

PS

Lesen Sie auch in unserem Blog:

Kubernetes 1.17: Übersicht der wichtigsten Neuerungen