🥇Kubernetes 1.17: Überblick über die wichtigsten Neuerungen

Gestern, am 9. Dezember, fand statt Die nächste Version von Kubernetes ist 1.17. Traditionell berichten wir in unserem Blog über die wichtigsten Änderungen der neuen Version.

Kubernetes 1.17: Highlights der Neuerungen

Die zur Erstellung dieses Materials verwendeten Informationen wurden der offiziellen Ankündigung entnommen. Tabellen zur Nachverfolgung von Kubernetes-Erweiterungen, CHANGELOG-1.17 und damit verbundene Probleme, Pull Requests und Kubernetes Enhancement Proposals (KEPs). Also, was gibt es Neues?

Topologiebewusstes Routing

Die Kubernetes-Community hat lange auf diese Funktion gewartet - Topologiebewusstes Service-Routing. Wenn KEP Es begann im Oktober 2018, und die offizielle Erweiterung — vor 2 Jahren, dann die üblichen Probleme (wie sie) – und sogar noch ein paar Jahre älter …

Die allgemeine Idee besteht darin, die Möglichkeit bereitzustellen, „lokales“ Routing für in Kubernetes befindliche Dienste zu implementieren. „Lokalität“ bedeutet in diesem Fall „dieselbe topologische Ebene“ (Topologieebene), die sein können:

derselbe Knoten für Dienste,
das gleiche Server-Rack,
die gleiche Region,
derselbe Cloud-Anbieter,
...

Beispiele für die Verwendung dieser Funktion:

Einsparung von Datenverkehr in Cloud-Installationen mit mehreren Verfügbarkeitszonen (Multi-AZ) - siehe frische Illustration am Beispiel von Datenverkehr aus einer Region, aber unterschiedlichen AZs in AWS;
geringere Leistungslatenz/besserer Durchsatz;
ein Sharded-Dienst, der lokale Informationen über den Knoten in jedem Shard hat;
Platzieren von fluentd (oder ähnlichem) auf demselben Knoten wie die Anwendungen, deren Protokolle gesammelt werden;
...

Diese Art des Routings, das die Topologie „bewusst“ berücksichtigt, wird auch als eine Art Netzwerkaffinität bezeichnet – analog zu Knotenaffinität, Pod-Affinität/Anti-Affinität oder erschienen nicht so lange her Topologiebewusste Datenträgerplanung (Und Volume-Bereitstellung). Aktueller Umsetzungsstand ServiceTopology in Kubernetes – Alpha-Version.

Lesen Sie mehr darüber, wie die Funktion funktioniert und wie Sie sie bereits nutzen können in Dieser Artikel von einem der Autoren.

IPv4/IPv6-Dual-Stack-Unterstützung

Bedeutende Fortschritte Fest in einer weiteren Netzwerkfunktion: gleichzeitige Unterstützung für zwei IP-Stacks, die erstmals in K8s 1.16. Die neue Version brachte insbesondere folgende Änderungen mit sich:

im Kube-Proxy umgesetzt die Möglichkeit, gleichzeitig in beiden Modi (IPv4 und IPv6) zu arbeiten;
в Pod.Status.PodIPs erschienen Downstream-API-Unterstützung (gleichzeitig in /etc/hosts jetzt müssen sie eine IPv6-Adresse für den Host hinzufügen);
Dual-Stack-Unterstützung NETTE (Kubernetes IN Docker) und kubeadm;
aktualisierte E2E-Tests.

Kubernetes 1.17: Highlights der Neuerungen
Illustration Verwenden von Dual Stack IPV4/IPv6 in KIND

Fortschritte bei CSI

Für stabil erklärt Topologieunterstützung für CSI-basierte Speicherung, erstmals eingeführt in K8s 1.12.

Initiative zum Migrieren von Volume-Plugins zu CSI - CSI-Migration – hat die Betaversion erreicht. Diese Funktion ist für die Migration vorhandener Speicher-Plugins von entscheidender Bedeutung. (im Baum) zu einer modernen Schnittstelle (CSI, außerhalb des Baumes) transparent für Kubernetes-Endbenutzer. Clusteradministratoren müssen lediglich die CSI-Migration aktivieren. Anschließend funktionieren vorhandene statusbehaftete Ressourcen und Workloads weiterhin „einfach“ … allerdings unter Verwendung der neuesten CSI-Treiber anstelle der im Kubernetes-Kern enthaltenen Legacy-Treiber.

Derzeit ist die Migration für AWS EBS-Treiber im Beta-Status bereit (kubernetes.io/aws-ebs) und GCE PD (kubernetes.io/gce-pd). Für die anderen Speicheranlagen gelten folgende Prognosen:

Kubernetes 1.17: Highlights der Neuerungen

Wir haben darüber gesprochen, wie die „traditionelle“ Speicherunterstützung in K8s zu CSI kam in Dieser Artikel. Und der Übergang der CSI-Migration zum Beta-Status ist gewidmet separate Veröffentlichung auf dem Projektblog.

Darüber hinaus hat eine weitere wichtige Funktion im Zusammenhang mit CSI, die ihren Ursprung (Alpha-Implementierung) in K1.17s 8 hatte, in der Kubernetes-Version 1.12 den Beta-Status erreicht (d. h. standardmäßig aktiviert): Erstellen von Schnappschüssen und Wiederherstellung von ihnen. Zu den Änderungen, die auf dem Weg zur Betaversion am Kubernetes Volume Snapshot vorgenommen wurden, gehören:

Aufteilung des CSI-Sidecars für externe Snapshots auf zwei Controller,
Geheimnis zum Löschen hinzugefügt (Löschgeheimnis) als Anmerkung zum Inhalt eines Volume-Überblicks,
neuer Finalizer (Finalisierer) um zu verhindern, dass das Snapshot-API-Objekt gelöscht wird, wenn noch Links vorhanden sind.

Zum Zeitpunkt der Version 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 Verwendung finden Sie in dieser Veröffentlichung auf dem Blog.

Cloud-Anbieter-Labels

Etiketten, die automatisch den erstellten Knoten und Volumes je nach verwendetem Cloud-Anbieter zugewiesen, sind in Kubernetes schon sehr lange als Beta-Version verfügbar – seit der Veröffentlichung von K8s 1.2 (April 2016!). Angesichts ihrer weitverbreiteten Nutzung seit so langer Zeit решили, dass es Zeit ist, die Funktion als stabil (GA) zu erklären.

Daher wurden sie alle entsprechend (topologisch) umbenannt:

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 (aus Gründen der Abwärtskompatibilität). Allen Administratoren wird jedoch empfohlen, auf aktuelle Bezeichnungen umzusteigen. Relevante Dokumentation K8s wurde aktualisiert.

Strukturierte Ausgabe von kubeadm

Erstmals in der Alpha-Version präsentiert strukturierte Ausgabe für das Dienstprogramm Kubeadm. Unterstützte Formate: JSON, YAML, Go-Vorlage.

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

Obwohl Kubernetes manuell bereitgestellt werden kann, besteht der De-facto-Standard (wenn nicht sogar der De-jure-Standard) für diesen Vorgang in der Verwendung von kubeadm. Beliebte Systemverwaltungstools wie Terraform verlassen sich beim Bereitstellen von Kubernetes auf kubeadm. Zu den geplanten Verbesserungen der Cluster-API gehört ein zusammensetzbares Paket zum Bootstrapping von Kubernetes mit kubeadm und cloud-init.
Ohne strukturierte Ausgabe können selbst die scheinbar harmlosesten Änderungen Terraform, Cluster API und andere Software beschädigen, die die Ergebnisse von kubeadm verwendet.

Zu den unmittelbaren Plänen gehört die Unterstützung (in Form einer strukturierten Ausgabe) für die folgenden Kubeadm-Befehle:

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

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

Stabilisierung anderer Innovationen

Generell erfolgte der Release von Kubernetes 1.17 unter dem Motto „Stabilität". Dies wurde durch die Tatsache erleichtert, dass es viele Funktionen darin gibt (ihre Gesamtzahl ist 14) erhielt den GA-Status. Dazu gehören:

"Markieren" von Knoten nach bestimmten Bedingungen (TaintNodesByCondition), erschienen in K8s 1.8;
Lesezeichen ansehen — ein neuer Ereignistyp, der mit einer Bezeichnung versehen ist, die alle Objekte bis zu einer bestimmten Version (resourceVersion) wurden bereits von der Uhr verarbeitet;
Standardwerte (Standard) für benutzerdefinierte Ressourcen;
zwischen Containern geteilt in Pod-Prozess-Namespaces;
ScheduleDaemonSetPods - Planen von Pods in DaemonSet Verwendung des Kube-Schedulers (anstelle des DaemonSet-Controllers);
dynamische Grenzen durch die Anzahl der Volumes, abhängig vom Knotentyp;
Unterstützung für Umgebungsvariablen für Verzeichnisnamen, die als gemountet sind subPath;
Kubelet Heartbeats-Übertragung in eine spezialisierte Lease-API;
"Finalizer-Schutz" (Finalizer-Schutz) für Load Balancer (Überprüfung der entsprechenden Service-Ressourcen vor dem Löschen von LoadBalancer-Ressourcen);
Kube-API-Server-Optimierung in der Leistung beim Arbeiten mit mehreren Uhren, die identische Objektsätze beobachten – erreicht durch Vermeidung der erneuten Serialisierung derselben Objekte für jeden Beobachter.

Andere Änderungen

Die vollständige Liste der neuen Funktionen in Kubernetes 1.17 ist natürlich nicht auf die oben aufgeführten beschränkt. Hier sind einige andere (und für eine vollständigere Liste siehe ÄNDERUNGSPROTOKOLL):

Die in der vorherigen Version vorgestellte Funktion ist zur Beta-Version ausgereift RunAsUserName für Windows;
ähnliche Änderung befiel EndpointSlice API (ebenfalls ab K8s 1.16), diese Lösung zur Verbesserung der Leistung/Skalierbarkeit der Endpoint API ist jedoch noch nicht standardmäßig aktiviert;
Pods, die für den Clusterbetrieb kritisch sind, sind jetzt kann erstellt werden nicht nur in Namespaces kube-system (Details finden Sie in der Dokumentation auf Verbrauch der Prioritätsklasse begrenzen);
neue Option für Kubelet — --reserved-cpus - ermöglicht Ihnen, die Liste der für das System reservierten CPUs explizit zu definieren;
für kubectl logs eingereicht neue Flagge --prefix, das jeder Protokollzeile den Namen des Pods und des Quellcontainers hinzufügt;
в label.Selector hinzugefügt RequiresExactMatch;
alle Container in Kube-DNS jetzt fangen sie an mit weniger Privilegien;
Hyperkube wurde in ein separates GitHub-Repository ausgegliedert und ist nicht mehr in Kubernetes-Releases enthalten;
viel Leistung verbessert Kube-Proxy für Nicht-UDP-Ports.

Änderungen in Abhängigkeiten:

die in kubeadm enthaltene Version von CoreDNS ist 1.6.5;
Crictl-Version auf v1.16.1 aktualisiert;
CSI 1.2.0;
etcd 3.4.3;
Die zuletzt getestete Version von Docker wurde auf 19.03 aktualisiert;
Die zum Erstellen von Kubernetes 1.17 erforderliche Mindestversion von Go ist 1.13.4.

PS

Lesen Sie auch auf unserem Blog:

Source: habr.com