🥇Kubernetes 1.16: Übersicht über die Hauptneuerungen | ProHoster

In dieser Nacht stattfinden wurde eine weitere Version von Kubernetes veröffentlicht — 1.14. Wie es für unseren Blog Tradition ist, berichten wir über die wichtigsten Änderungen in dieser neuen Version dieses bemerkenswerten Open Source-Produkts.

Die Informationen, die zur Vorbereitung dieses Materials verwendet wurden, stammen aus der Tabelle zur Nachverfolgung von Kubernetes-Verbesserungen, CHANGELOG-1.14 und die entsprechenden Issues, Pull Requests, Kubernetes Enhancement Proposals (KEP).

Wir beginnen mit einer wichtigen Einführung von SIG cluster-lifecycle: dynamische fehlertolerante Cluster Kubernetes (oder präziser gesagt, self-hosted HA-Deployments) können jetzt erstellt werden mit den gewohnten (im Kontext von Clustern mit einem Knoten) Befehlen kubeadm (init und join). Kurz gesagt, dafür:

• Die vom Cluster verwendeten Zertifikate werden in Secrets verschoben;
• um die Nutzung von etcd innerhalb des K8s-Clusters zu ermöglichen (d.h. um die bisher bestehende externe Abhängigkeit zu beseitigen), wird der etcd-Operator;
• eingesetzt, um empfohlene Einstellungen für einen externen Lastenausgleich zu dokumentieren, der eine fehlertolerante Konfiguration sicherstellt (es ist geplant, auch diese Abhängigkeit in Zukunft abzulehnen, jedoch nicht zu diesem Zeitpunkt).

Die Architektur des HA-Clusters von Kubernetes, das mit kubeadm erstellt wurde,

Die Details zur Umsetzung sind im Designvorschlageinzusehen. Dieses Feature war wirklich lange erwartet: Die Alpha-Version wurde bereits in K8s 1.9 erwartet, ist aber erst jetzt erschienen.

API

Team apply Und generell deklaratives Management von Objekten wurde ausgegliedert aus kubectl in den apiserver. Die Entwickler selbst erklären ihre Entscheidung damit, dass kubectl apply es eine fundamentale Komponente bei der Arbeit mit Konfigurationen in Kubernetes ist, jedoch "voller Fehler ist und schwer zu reparieren ist", weswegen diese Funktionalität in einen ordentlichen Zustand gebracht und in den Control Plane verschoben werden muss. Einfache und anschauliche Beispiele für die bestehenden Probleme sind:

Details zur Umsetzung finden Sie im KEP. Der aktuelle Stand ist die Alpha-Version (die Versetzung in die Beta ist für die nächste Kubernetes-Version geplant).

In der Alpha-Version wurde die Nutzung des OpenAPI v3-Schemas für die Möglichkeit die Erstellung und Veröffentlichung von OpenAPI-Dokumentationen für CustomResources (CR), die zur Validierung (serverseitig) von K8s-Ressourcen, die vom Benutzer definiert sind (CustomResourceDefinition, CRD), verwendet werden, verfügbar. Die Veröffentlichung von OpenAPI für CRD ermöglicht es den Clients (zum Beispiel, ) die Validierung auf ihrer Seite (im Rahmen von kubectl) durchzuführen und die Dokumentation zur Schema ( ) bereitzustellen. Details finden Sie im und kubectl applyDie früheren Logs, der die Spezifikationen aller Ressourcen direkt in Ihrem Terminal anzeigt.werden jetzt geöffnet KEP.

O_APPEND (und nicht mit dem Flag O_TRUNC (und nicht O_TRUNC) um den Verlust von Protokollen in bestimmten Situationen zu vermeiden und um die Protokolldateien für die Rotation durch externe Tools bequem zu truncaten.

Im Kontext der Kubernetes API kann auch erwähnt werden, dass PodSandbox und PodSandboxStatus hinzugefügt Feld runtime_handler um Informationen über RuntimeClass im Pod zu berücksichtigen (lesen Sie mehr darüber im Text über Kubernetes-Version 1.12, wo diese Klasse als Alpha-Version eingeführt wurde), während bei Admission Webhooks wurde die Möglichkeit besteht, zu bestimmen, welche Versionen AdmissionReview unterstützt werden. Schließlich kann in den Regeln für Admission Webhooks nun die Anwendungskontexte auf Namespaces und Clustergrenzen beschränkt werden.

Speicher

Persistente lokale Volumes, die den Status einer Beta-Version seit der Veröffentlichung K8s 1.10, erhalten hatten, wurden als stabil (GA) erklärt: dieses Feature Gate wird nicht mehr deaktiviert und wird in Kubernetes 1.17 entfernt.

Die Möglichkeit die Nutzung von Umgebungsvariablen des sogenannten Downward API z.B. den Namen des Pods, für Verzeichnisse, die als subPath, eingeführt — in Form eines neuen Feldes subPathExpr, mit dessen Hilfe nun auch der benötigte Verzeichnisname festgelegt wird. Das Feature wurde erstmals in Kubernetes 1.11 eingeführt, blieb aber auch für 1.14 im Status einer Alpha-Version.

Wie im vorherigen Kubernetes-Release wurden viele bedeutende Änderungen für das aktiv entwickelte CSI (Container Storage Interface) vorgestellt:

CSI

wurde verfügbar gemacht (im Rahmen der Alpha-Version) unterstützt für die Größenänderung von CSI-Volumes.Um es zu nutzen, muss das Feature Gate mit dem Namen ExpandCSIVolumesaktiviere werden, vorausgesetzt, der spezifische CSI-Treiber unterstützt diese Operation.

Ein weiteres Feature für CSI in der Alpha-Version — die Möglichkeit direkt (d.h. ohne Verwendung von PV/PVC) auf CSI-Volumes innerhalb der Pod-Spezifikation zu verweisen. Dies behebt die Einschränkung, dass CSI ausschließlich als entferntes Speichersystem genutzt wird,und öffnet ihnen die Tür zur Welt der lokalen ephemeral volumes.Zur Nutzung (Beispiel aus der Dokumentation) muss das CSIInlineVolume Feature Gate aktiviert werden.

Es gab Fortschritte auch in den 'Innereien' von Kubernetes, die mit CSI verbunden sind und den Endbenutzern (Systemadministratoren) nicht so auffallen… Momentan sind die Entwickler gezwungen, zwei Versionen jedes Speicher-Plugins zu unterstützen: eine – 'auf alte Art' – innerhalb der K8s-Codebasis (in-tree), und eine zweite – im Rahmen des neuen CSI. (lesen Sie mehr darüber, z.B. in hier). Dies führt zu verständlichen Unannehmlichkeiten, die behoben werden müssen, sobald CSI als solches stabil ist. Es ist jedoch nicht möglich, interne (in-tree) API von Plugins als veraltet (deprecated) zu erklären aufgrund der entsprechenden Kubernetes-Richtlinien..

All dies führte dazu, dass die Alpha-Versionen die Migrationsprozesse des internen Codes von Plugins, die als in-tree implementiert werden, in CSI-Plugins umgewandelt werden, wodurch die Entwickler sich auf die Unterstützung einer Version ihrer Plugins konzentrieren können, während die Kompatibilität mit alten APIs erhalten bleibt und sie im Rahmen des gewohnten Szenarios als veraltet erklärt werden können. Es wird erwartet, dass bis zur nächsten Kubernetes-Version (1.15) alle Plugins der Cloud-Anbieter migriert werden, die Implementierung den Status einer Beta-Version erhält und standardmäßig in K8s-Installationen aktiviert wird. Details siehe Designvorschlag. Eine Folge dieser Migration war auch der Verzicht die Aufhebung von Einschränkungen für Volumes, die von bestimmten Cloud-Anbietern festgelegt werden (AWS, Azure, GCE, Cinder).

Darüber hinaus wird die Unterstützung für Blockgeräte mit CSI (CSIBlockVolume) wurde in die Beta-Version überführt.

Knoten / Kubelet

Eine Alpha-Version eines neuen Endpunkts wurde im Kubelet eingeführt, der dazu dient, Metriken zu den Hauptressourcen bereitzustellen.. Im Allgemeinen erhielt Kubelet vorher Statistiken zur Nutzung von Containern von cAdvisor, jetzt stammen diese Daten aus der Container-Laufzeitumgebung über CRI (Container Runtime Interface), wobei die Kompatibilität für die Arbeit mit alten Docker-Versionen jedoch erhalten bleibt. Früher wurden die in Kubelet gesammelten Statistiken über die REST-API bereitgestellt, jetzt wird dafür ein Endpunkt verwendet, der unter der Adresse /metrics/resource/v1alpha1liegt. Die langfristige Strategie der Entwickler besteht darin, die Menge der von Kubelet bereitgestellten Metriken zu minimieren. Übrigens werden diese Metriken jetzt als nicht mehr als „Kernmetriken“, sondern als „Ressourc metriken“ bezeichnet und beschreiben „Erstklassige Ressourcen wie CPU und Speicher“.

Ein interessanter Punkt: Trotz des offensichtlichen Performancevorteils des gRPC-Endpunkts im Vergleich zu verschiedenen Nutzungsfällen des Prometheus-Formats (das Ergebnis eines der Benchmarks siehe unten), zogen die Autoren das textbasierte Prometheus-Format aufgrund der offensichtlichen Führungsposition dieses Monitoringsystems in der Community vor.

«gRPC ist nicht mit den Hauptüberwachungs-Pipelines kompatibel. Der Endpoint wird jedoch nur für die Bereitstellung von Metriken an den Metrics Server oder an Monitoring-Komponenten nützlich sein, die direkt damit integriert sind. Bei Verwendung von Caching im Metrics Server ist die Leistung des textbasierten Prometheus-Formats recht gut für uns, um Prometheus gegenüber gRPC zu bevorzugen, angesichts der breiten Verbreitung von Prometheus in der Gemeinschaft. Wenn das OpenMetrics-Format stabiler wird, können wir die Leistung von gRPC mit einem proto-basierten Format annähern.»

Einer der Leistungstestvergleiche zwischen gRPC- und Prometheus-Formaten im neuen Kubelet-Endpoint für Metriken. Mehr Grafiken und weitere Einzelheiten finden Sie unter KEP.

Unter den weiteren Änderungen:

• versucht Kubelet jetzt (einmalig) die Container in unbekanntem Zustand (unknown) vor Neustart- und Löschoperationen zu stoppen. PodPresets
• Bei der Nutzung eines wird jetzt dem Init-Container die gleichen Informationen wie dem regulären Container hinzugefügt. begann, usageNanoCores
• Kubelet vom CRI-Statistikprovider zu verwenden, und für Knoten und Container unter Windows Netzwerkstatistiken. Informationen über das Betriebssystem und die Architektur werden jetzt in den Labels hinzugefügt kubernetes.io/os
• kubernetes.io/arch von Node-Objekten (von Beta auf GA übertragen). und Die Möglichkeit, eine bestimmte Benutzer-Systemgruppe für Container im Pod anzugeben ( RunAsGroup
• , wurde inK8s 1.11vorangetrieben bis zur Beta-Version (standardmäßig aktiviert).) du und find, die in cAdvisor verwendet wurden, wurden
• durch Go-Implementierungen ersetzt. In cli-runtime und kubectl fand der -k-Flag für die Integration mit

CLI

(übrigens wird die Entwicklung jetzt in einem eigenen Repository durchgeführt), d.h. zur Verarbeitung zusätzlicher YAML-Dateien aus speziellen Kustomization-Verzeichnissen (weitere Einzelheiten zur Verwendung finden Sie in wurde hinzugefügt Beispiel für die einfache Verwendung einer Datei kustomize kustomization KEP):

(möglicherweise auch komplexere Anwendungen von kustomize im Rahmen von overlays das neue Kommando kubectl create cronjob)

Außerdem:

• Hinzugefügt , dessen Name für sich selbst spricht. kubectl logskombiniert
• Im Flags ist jetzt möglich --follow für das Streaming von Logs) und -f (--selector für die Labelabfrage). -l (lernte Dateien zu kopieren, die mit Wildcards ausgewählt werden.
• kubectl Im Befehl kubectl wait
• --all zum Auswählen aller Ressourcen im Namensraum eines angegebenen Ressourcentyps. haben Flag Der stabile (GA) Status wurde für folgende Funktionen erreicht: ReadinessGate

Andere

, verwendet in der Pod-Spezifikation zur Bestimmung zusätzlicher Bedingungen, die bei der Pod-Bereitschaft berücksichtigt werden;

• ReadinessGate, der in der Pod-Spezifikation verwendet wird, um zusätzliche Bedingungen zu definieren, die bei der Bereitschaft des Pods berücksichtigt werden;
• Unterstützung für große Seiten (Feature-Gate mit dem Namen HugePages);
• CustomPodDNS;
• PriorityClass API, Pod-Priorität & Vorabenteignung.

Weiter Änderungen, die in Kubernetes 1.14 vorgestellt wurden:

• Die standardmäßige RBAC-Richtlinie gewährt keinen Zugriff auf die API discovery und access-review Benutzern ohne Authentifizierung (unauthenticated).
• Offizielle Unterstützung für CoreDNS wird nur für Linux bereitgestellt, daher müssen beim Einsatz von kubeadm zur Bereitstellung von CoreDNS in einem Cluster die Knoten ausschließlich unter Linux betrieben werden (für diese Einschränkung werden nodeSelectors verwendet).
• Die Standardkonfiguration von CoreDNS ist jetzt verwendet Plugin forward anstatt proxy. Zudem gibt es in CoreDNS hinzugefügt readinessProbe, die eine Lastverteilung auf entsprechende (nicht bereit gestellte) Pods verhindert.
• In kubeadm, in den Phasen init oder upload-certs, wurde es möglich, die für die Verbindung eines neuen Control-Plans benötigten Zertifikate in das Secret kubeadm-certs hochzuladen (es wird die Option --experimental-upload-certs).
• Für Windows-Installationen gibt es eine Alpha-Version Unterstützung gMSA (Group Managed Service Account) - spezielle Konten in Active Directory, die auch von Containern verwendet werden können.
• Für GCE wurde aktiviert mTLS-Verschlüsselung zwischen etcd und kube-apiserver.
• Updates der verwendeten/abhängigen Software: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, Unterstützung von Docker 18.09 in kubeadm, und die minimal unterstützte Version der Docker-API ist nun 1.26.

P.S.

Lesen Sie auch in unserem Blog:

• «🥇Kubernetes 1.16: Übersicht über die Hauptneuerungen | ProHoster»;
• «🥇Kubernetes 1.16: Übersicht über die Hauptneuerungen | ProHoster»;
• «Kubernetes 1.11: Überblick über die wichtigsten Neuerungen»;
• «Kubernetes 1.10: Überblick über die wichtigsten Neuerungen».

Quelle: habr.com