🥇Kubernetes 1.17: Überblick über die wichtigsten Neuerungen

Gestern, 9. Dezember, hat stattgefunden gab es ein weiteres Release von Kubernetes – 1.17. Wie in unserem Blog gewohnt, berichten wir über die wichtigsten Änderungen in der neuen Version.

Kubernetes 1.17: Überblick über die wichtigsten Neuerungen

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

Routing unter Berücksichtigung der Topologie

Eine lange erwartete Funktion in der Kubernetes-Community — Topologie-bewusstes Service-Routing. Wenn KEP hat ihren Ursprung im Oktober 2018, während das offizielle Enhancement vor 2 Jahren vorgestellt wurde; gewöhnliche Issues (wie dieses) — und sogar noch einige Jahre älter…

Die grundlegende Idee besteht darin, die Möglichkeit zu bieten, eine „lokale“ Routing-Lösung für Services in Kubernetes zu realisieren. „Lokale“ bedeutet in diesem Fall „auf derselben topologischen Ebene“ (topology level), was Folgendes umfassen kann:

einen gemeinsamen Knoten für Services,
das gleiche Server-Rack,
die gleiche Region,
den gleichen Cloud-Anbieter.
…

Beispiele für die Nutzung dieser Funktion:

Kostensenkung beim Traffic in Cloud-Installationen mit mehreren Verfügbarkeitszonen (multi-AZ) — siehe. eine neue Illustration am Beispiel des Traffics einer Region, jedoch unterschiedlicher AZ in AWS;
geringere Latenzzeiten in der Leistung/bessere Bandbreite;
ein shardierter Service, der lokale Informationen über den Knoten in jedem Shard hat;
die Platzierung von fluentd (oder Alternativen) auf demselben Knoten wie die Anwendungen, deren Protokolle gesammelt werden;
…

Ein solches Routing, das die Topologie kennt, wird auch als Netzwerkaffinität bezeichnet – in Anlehnung an Node Affinity, Pod Affinity/Anti-Affinity oder das kürzlich hinzugefügte Topology-Aware Volume Scheduling Volume Provisioning (und ). Der aktuelle ImplementierungsstandServiceTopology in Kubernetes ist eine Alpha-Version. Details dazu, wie die Funktion aufgebaut ist und wie sie bereits genutzt werden kann, finden Sie in

einem Artikel von einem der Autoren. diesem Artikel Unterstützung für dualen Stack IPv4/IPv6

Bedeutende Fortschritte

wurden in einer anderen Netzwerkanforderung verzeichnet: gleichzeitige Unterstützung zweier IP-Stacks, die erstmals in K8s 1.16 vorgestellt wurde. Insbesondere brachte das neue Release folgende Änderungen mit sich:in kube-proxy

die Möglichkeit der gleichzeitigen Ausführung in beiden Modi (IPv4 und IPv6); wurde Pod.Status.PodIPs
in Unterstützung des Downward API (gleichzeitig müssen die Hosts nun auch IPv6-Adressen hinzufügen); ein Unterstützung für zwei Stacks in /etc/hosts (Kubernetes IN Docker) und
aktualisierte e2e-Tests. KIND Illustration kubeadm;
aktualisierte e2e-Tests.

Kubernetes 1.17: Überblick über die wichtigsten Neuerungen
Illustration Verwendung des Dual-Stacks IPV4/IPv6 in KIND

Fortschritt bei CSI

Als stabil eingestuft Unterstützung von Topologien für CSI-basierte Speicher, erstmals vorgestellt in K8s 1.12.

Initiative zur Migration von Volume-Plugins auf CSI — CSI-Migration — hat den Beta-Status erreicht. Diese Funktion ist entscheidend, um bestehende Speichermodule (in-tree) auf die moderne Schnittstelle (CSI, out-of-tree) für Endbenutzer von Kubernetes nahtlos zu migrieren. Cluster-Administratoren müssen lediglich die CSI-Migration aktivieren, wodurch bestehende Stateful-Ressourcen und Workloads weiterhin "einfach funktionieren" … jedoch jetzt mit den aktuellen CSI-Treibern anstelle von veralteten, im Kubernetes-Kern integrierten Treibern.

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

Kubernetes 1.17: Überblick über die wichtigsten Neuerungen

Über die "traditionelle" Unterstützung von Speichern in K8s, die zu CSI kam, haben wir berichtet in diesem Artikel. Der Übergang der CSI-Migration in den Beta-Status wird thematisiert in einem separaten Beitrag im Projektblog.

Darüber hinaus hat eine andere bedeutende Funktionalität im Kontext von CSI, die ihren Ursprung (Alpha-Implementierung) in K8s 1.12 hat, im Release Kubernetes 1.17 den Beta-Status erreicht — Snapshot-Erstellung und die Wiederherstellung daraus. Zu den Änderungen, die an Kubernetes Volume Snapshot auf dem Weg zur Beta-Version vorgenommen wurden, gehören:

Aufteilung des CSI External-Snapshotters in zwei Controller,
Hinzufügen eines Löschgeheimnisses (deletion secret) als Annotation zum Inhalt des Volume-Snapshots,
neuer Finalizer (finalizer) zum Verhindern der Löschung des API-Objekts des Snapshots bei verbleibenden Verbindungen.

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 dieser Veröffentlichung dem Blog.

Cloud Provider Labels

Labels, die automatisch den erstellten Knoten und Volumes je nach verwendetem Cloud-Anbieter zugewiesen werden, waren in Kubernetes seit langem als Beta-Version verfügbar — seit der Veröffentlichung von K8s 1.2 (April 2016!). Angesichts ihrer weiten Verbreitung über so lange Zeit haben die Entwickler entschieden, dass es an der Zeit ist, die Funktion als stabil (GA) einzustufen.

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 → topologie.kubernetes.io/region

… ist jedoch weiterhin unter ihren alten Bezeichnungen (für die Abwärtskompatibilität) verfügbar. Allen Administratoren wird jedoch geraten, auf aktuelle Labels umzusteigen. Die 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-Vorlage.

Die Motivation für die Umsetzung dieser Funktion (gemäß KEP) ist folgende:

Obwohl Kubernetes manuell bereitgestellt werden kann, ist die De-facto-Norm (wenn nicht de jure) für diesen Vorgang die Verwendung von kubeadm. Beliebte Systemverwaltungstools wie Terraform basieren auf kubeadm für die Bereitstellung von Kubernetes. Geplante Verbesserungen im Cluster-API umfassen ein verwandtes Paket zum Bootstrapping von Kubernetes mit kubeadm und cloud-init.
Ohne termingerechte Ausgabe können selbst die harmlosesten, auf den ersten Blick unschuldigen Änderungen Terraform, Cluster API und andere Software, die die Ergebnisse von kubeadm nutzen, brechen.

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

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

Beispiel für die 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": "Das Standard-Boostrap-Token, das von 'kubeadm init' generiert wurde.",
    "extraGroups": [
      "system:bootstrappers:kubeadm:default-node-token"
    ]
  },
  "raw": "Rm9yIHRoZSBhY3R1YWwgb3V0cHV0IG9mIHRoZSAia3ViZWFkbSBpbml0IiBjb21tYW5kLCBwbGVhc2Ugc2VlIGh0dHBzOi8vZ2lzdC5naXRodWIuY29tL2FrdXR6LzdhNjg2ZGU1N2JmNDMzZjkyZjcxYjZmYjc3ZDRkOWJhI2ZpbGUta3ViZWFkbS1pbml0LW91dHB1dC1sb2c="
}

Stabilisierung anderer Neuerungen

Die Veröffentlichung von Kubernetes 1.17 stand ganz unter dem Motto „Stabilität“. Dies wurde dadurch begünstigt, dass viele Features in ihr (insgesamt 14) den GA-Status erhalten haben. Dazu gehören:

„Tainting“ von Knoten unter bestimmten Bedingungen (TaintNodesByCondition), das in K8s 1.8;
Watch Bookmarks — ein neuer Typ von Ereignissen, die das Label tragen, dass alle Objekte bis zu einer bestimmten Version (resourceVersion) bereits vom Watch verarbeitet wurden;
Standardwerte (defaulting) für benutzerdefinierte Ressourcen;
geteilte Prozessnamespaces zwischen Containern im Pod;
ScheduleDaemonSetPods — Planung von Pods in DaemonSet mit kube-scheduler (anstatt des DaemonSet-Controllers);
dynamische Limits für die Anzahl der Volumes abhängig vom Knotentyp;
Unterstützung von Umgebungsvariablen für Verzeichnissnamen, die als subPath;
Kubelet-Herzw beats übertragen an eine spezielle Lease API;
„Finalizer-Schutz“ (Finalizer Protection) für Lastenausgleicher (Prüfung der relevanten Ressourcen eines Service vor der Löschung der Ressourcen des Lastenausgleichs);
Optimierung des kube-apiserver in der Leistung bei der Arbeit mit vielen Watches, die identische Objektsätze beobachten, - erreicht durch das Vermeiden der erneuten Serialisierung derselben 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 (und für eine vollständige Liste - siehe CHANGELOG):

die im vorherigen Release vorgestellte Funktion hat jetzt die Beta-Version erreicht RunAsUserName unter Windows;
eine ähnliche Änderung hat erreicht das EndpointSlice API (auch aus K8s 1.16), jedoch wurde diese Lösung zur Verbesserung der Leistung / Skalierbarkeit des Endpoint API noch nicht standardmäßig aktiviert;
kritische Pods für den Clusterbetrieb können jetzt nicht nur im Namensraum (siehe Details in der Dokumentation zu kube-system Limit Priority Class consumption eine neue Option für kubelet -);
--reserved-cpus ermöglicht es, eine Liste von CPUs explizit für das System zu reservieren; ein neues Flag
für Flags vorgestellt , das den Namen des Pods und des Quellcontainers zu jeder Protokollzeile hinzufügt; --prefixlabel.Selector
in RequiresExactMatch haben alle Container in kube-dns;
werden jetzt mit geringeren Berechtigungen gestartet; in ein separates GitHub-Repository ausgelagert und wird nicht mehr in Kubernetes-Releases enthalten sein;
hyperkube die Leistung
deutlich kube-proxy für Nicht-UDP-Ports verbessert. Ä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 Version von Go, die für den Build von Kubernetes 1.17 erforderlich ist, beträgt 1.13.4.
Gestern, am 9. Dezember, fand das nächste Release von Kubernetes - 1.17 - statt.

P.S.

Lesen Sie auch in unserem Blog:

Quelle: habr.com