🥇Kubernetes 1.17: Überblick über die wichtigsten Neuerungen

Gestern, 9. Dezember, fand statt nächste Version von Kubernetes - 1.17. Gemäß der Tradition, die sich für unseren Blog entwickelt hat, sprechen wir über die wichtigsten Änderungen in der neuen Version.

Die zur Erstellung dieses Materials verwendeten Informationen stammen aus der offiziellen Ankündigung, Tabellen zur Nachverfolgung von Kubernetes-Erweiterungen, CHANGELOG-1.17 und verwandte Probleme, Pull Requests und Kubernetes Enhancement Proposals (KEP). Was gibt es Neues?..

Topologiebewusstes Routing

Auf dieses Feature hat die Kubernetes-Community schon lange gewartet – Topologiebewusstes Service-Routing. Wenn KEP Es stammt aus dem Oktober 2018 und ist offiziell Erweiterung — Vor 2 Jahren die üblichen Probleme (wie sie) - und noch ein paar Jahre älter...

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

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

Beispiele für die Verwendung dieser Funktion:

Einsparungen beim Datenverkehr in Cloud-Installationen mit mehreren Verfügbarkeitszonen (Multi-AZ) – siehe. frische Illustration Am Beispiel von Datenverkehr aus derselben Region, aber unterschiedlichen AZs in AWS;
geringere Leistungslatenz/besserer Durchsatz;
ein Shard-Dienst, der lokale Informationen über den Knoten in jedem Shard hat;
Platzierung von fluentd (oder Analoga) auf demselben Knoten wie die Anwendungen, deren Protokolle gesammelt werden;
...

Ein solches Routing, das die Topologie „kennt“, wird in Analogie zu auch Netzwerkaffinität genannt Knotenaffinität, Pod-Affinität/Anti-Affinität oder erschienen nicht so lange her Topologiebewusste Volumenplanung (Und Volume-Bereitstellung). Aktueller Stand der Umsetzung ServiceTopology in Kubernetes - Alpha-Version.

Einzelheiten dazu, wie die Funktion funktioniert und wie Sie sie bereits nutzen können, finden Sie hier Dieser Artikel von einem der Autoren.

IPv4/IPv6-Dual-Stack-Unterstützung

Erhebliche Fortschritte Fest in einer weiteren Netzwerkfunktion: gleichzeitige Unterstützung für zwei IP-Stacks, die erstmals eingeführt wurde K8s 1.16. Das neue Release brachte insbesondere folgende Änderungen mit sich:

im Kube-Proxy umgesetzt Möglichkeit des gleichzeitigen Betriebs in beiden Modi (IPv4 und IPv6);
в Pod.Status.PodIPs erschienen Unterstützung für die Abwärts-API (zur gleichen Zeit wie in /etc/hosts Jetzt muss der Host eine IPv6-Adresse hinzufügen.
Dual-Stack-Unterstützung NETTE (Kubernetes IN Docker) und kubeadm;
Aktualisierte E2E-Tests.

Illustration Verwendung von Dual-Stack IPV4/IPv6 in KIND

Fortschritte bei CSI

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

Initiative für Migration von Volume-Plugins zu CSI - CSI-Migration - Beta-Version erreicht. Diese Funktion ist für die Übersetzung vorhandener Speicher-Plugins von entscheidender Bedeutung (im Baum) auf eine moderne Oberfläche (CSI, außerhalb des Baums) für Kubernetes-Endbenutzer unsichtbar. Clusteradministratoren müssen lediglich die CSI-Migration aktivieren, woraufhin vorhandene zustandsbehaftete Ressourcen und Workloads weiterhin „einfach funktionieren“ … jedoch mit den neuesten CSI-Treibern anstelle der veralteten, die im Kubernetes-Kern enthalten sind.

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

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

Darüber hinaus erreichte eine weitere wichtige Funktionalität im Kontext von CSI, die ihren Ursprung (Alpha-Implementierung) in K1.17s 8 hat, in der Kubernetes-Version 1.12 den Beta-Status (d. h. standardmäßig aktiviert) – Schnappschüsse erstellen und Genesung von ihnen. Zu den Änderungen, die auf dem Weg zur Beta-Version am Kubernetes Volume Snapshot vorgenommen wurden:

Aufteilen des CSI External-Snapshotter-Sidecars in 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 Verbindungen 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 Einzelheiten zur Implementierung und Verwendung finden Sie in dieser Veröffentlichung auf dem Blog.

Labels von Cloud-Anbietern

Beschriftet das automatisch Abhängig vom verwendeten Cloud-Anbieter den erstellten Knoten und Volumes zugewiesensind in Kubernetes schon seit sehr langer Zeit – seit der Veröffentlichung von K8s 1.2 – als Betaversion verfügbar (April 2016!). Angesichts ihrer weit verbreiteten Verwendung seit so langer Zeit, Entwickler решили, dass es an der Zeit ist, das Feature 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

... sind aber weiterhin unter ihrem alten Namen verfügbar (aus Gründen der Abwärtskompatibilität). Allen Administratoren wird jedoch empfohlen, auf aktuelle Labels umzusteigen. dazugehörige Dokumentation K8s wurde aktualisiert.

Strukturierte Ausgabe von kubeadm

Zum ersten Mal 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) Ist:

Während Kubernetes manuell bereitgestellt werden kann, ist der De-facto-Standard (wenn nicht sogar der De-jure-Standard) für diesen Vorgang die Verwendung von kubeadm. Beliebte Systemverwaltungstools wie Terraform verlassen sich bei der Kubernetes-Bereitstellung auf kubeadm. Zu den geplanten Verbesserungen der Cluster-API gehört ein zusammensetzbares Paket für Kubernetes-Bootstrapping mit kubeadm und cloud-init.

Ohne strukturierte Ausgabe können selbst die auf den ersten Blick harmlosesten Änderungen Terraform, Cluster API und andere Software zerstören, die die Ergebnisse von kubeadm nutzt.

Zu unseren 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 einer JSON-Antwort auf einen 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 die Veröffentlichung von Kubernetes 1.17 unter dem Motto „Stabilität" Dies wurde durch die Tatsache erleichtert, dass viele Funktionen darin enthalten sind (ihre Gesamtzahl beträgt 14) erhielt den GA-Status. Darunter:

„Markieren“ von Knoten gemäß bestimmten Bedingungen (TaintNodesByCondition), erschien in K8s 1.8;
Lesezeichen ansehen – eine neue Art von Ereignissen, die eine Bezeichnung haben, die besagt, dass alle Objekte einer bestimmten Version entsprechen (resourceVersion) wurden bereits von watch verarbeitet;
Standardwerte (Standard) für benutzerdefinierte Ressourcen;
zwischen Containern geteilt in den Pod-Prozess-Namespaces;
ScheduleDaemonSetPods - Planen von Pods in DaemonSet Verwendung von kube-scheduler (anstelle des DaemonSet-Controllers);
dynamische Grenzen von der Anzahl der Volumes abhängig vom Knotentyp;
Unterstützung von Umgebungsvariablen für Verzeichnisnamen, die als gemountet sind subPath;
Kubelet-Heartbeats-Übertragung zu einer speziellen Leasing-API;
„Finalizer-Schutz“ (Finalizer-Schutz) für Load Balancer (Überprüfung der entsprechenden Serviceressourcen vor dem Löschen von LoadBalancer-Ressourcen);
Kube-Apiserver-Optimierung Leistungseinbußen bei der Arbeit mit mehreren Watchern, die identische Objektsätze überwachen – erreicht durch Vermeidung der wiederholten Serialisierung derselben Objekte für jeden Watcher.

Andere Änderungen

Die vollständige Liste der Neuerungen in Kubernetes 1.17 beschränkt sich natürlich nicht auf die oben aufgeführten. Hier sind einige andere (und eine vollständigere Liste finden Sie unter ÄNDERUNGSPROTOKOLL):

Die in der letzten Version vorgestellte Funktion hat die Beta-Version erreicht RunAsUserName für Windows;
ähnliche Veränderung geschah EndpointSlice API (ebenfalls ab K8s 1.16), allerdings ist diese Lösung zur Verbesserung der Leistung/Skalierbarkeit der Endpoint API derzeit nicht standardmäßig aktiviert;
Pods sind jetzt für den Clusterbetrieb von entscheidender Bedeutung erstellt werden können nicht nur in Namensräumen kube-system (Einzelheiten finden Sie in der Dokumentation zu Begrenzen Sie den Verbrauch der Prioritätsklasse);
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, indem der Name des Pods und des Quellcontainers zu jeder Zeile des Protokolls hinzugefügt wird;
в label.Selector hinzugefügt RequiresExactMatch;
alle Container in kube-dns laufen jetzt mit weniger Privilegien;
Hyperkube getrennt in ein separates GitHub-Repository und wird nicht mehr in Kubernetes-Releases enthalten sein;
viel verbesserte Leistung kube-proxy für Nicht-UDP-Ports.

Abhängigkeitsänderungen:

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

PS

Lesen Sie auch auf unserem Blog:

Source: habr.com

Kubernetes 1.17: Highlights der Neuerungen