Kubernetes 1.14: Überblick über wichtige Innovationen

Kubernetes - 1.14 wird diese Nacht veröffentlicht. Gemäß der Tradition, die sich für unseren Blog entwickelt hat, sprechen wir über wichtige Änderungen in der neuen Version dieses wunderbaren Open Source-Produkts.

Die zur Vorbereitung dieses Materials verwendeten Informationen stammen aus der Kubernetes-Erweiterungsverfolgungstabelle , CHANGELOG-1.14 und verwandten Problemen, Pull-Anforderungen und Kubernetes-Verbesserungsvorschlägen (KEP). UPDATE (26. März): Die offizielle Ankündigung der Veröffentlichung erschien auch im K8s-Blog.

Beginnen wir mit einer wichtigen Einführung aus dem SIG-Cluster-Lebenszyklus: Kubernetes dynamische Failover-Cluster (und genauer gesagt selbst gehostete HA-Bereitstellungen) können jetzt mit den üblichen (im Kontext von kubeadm -Clustern) kubeadm ( init und join ) erstellt werden. Kurz gesagt, dafür:

• Vom Cluster verwendete Zertifikate werden an Geheimnisse übertragen.
• Für die Möglichkeit, den etcd-Cluster innerhalb des K8s-Clusters zu verwenden (d. h. die bisher bestehende externe Abhängigkeit zu beseitigen ), wird der etcd-Operator verwendet .
• Empfohlene Einstellungen für einen externen Load Balancer, der eine fehlertolerante Konfiguration bietet, werden dokumentiert (in Zukunft ist die Möglichkeit eines Ausfalls aufgrund dieser Abhängigkeit geplant, jedoch noch nicht).

Kubernetes HA-Cluster-Architektur mit kubeadm

Details zur Implementierung finden Sie im Entwurfsvorschlag . Diese Funktion wurde wirklich lange erwartet: Die Alpha-Version wurde bereits in K8s 1.9 erwartet, erschien aber erst jetzt.

API

Der Befehl apply und die allgemein deklarative Objektverwaltung werden von kubectl nach apiserver verschoben. Die Entwickler selbst erläutern kurz ihre Entscheidung, indem sie sagen, dass kubectl apply ein wesentlicher Bestandteil der Arbeit mit Konfigurationen in Kubernetes ist. Es ist jedoch "voller Fehler und schwer zu beheben". Daher muss diese Funktionalität wieder normalisiert und auf die Steuerebene übertragen werden. Einfache und anschauliche Beispiele für die heutigen Probleme:



Details zur Implementierung finden Sie in KEP . Die aktuelle Verfügbarkeit ist die Alpha-Version (die Beförderung zur Beta ist für die nächste Version von Kubernetes geplant).

In der Alpha-Version ist die Möglichkeit verfügbar, mithilfe des OpenAPI v3-Schemas OpenAPI-Dokumentation zu CustomResources (CR) zu erstellen und zu veröffentlichen , mit der (serverseitige) benutzerdefinierte K8-Ressourcen (CustomResourceDefinition, CRD) validiert werden. Durch das Veröffentlichen von OpenAPI für CRD können Clients (z. B. kubectl ) eine Validierung auf ihrer Seite durchführen (als Teil von kubectl create und kubectl apply ) und Dokumentation gemäß dem Schema kubectl explain ( kubectl explain ). Details finden Sie im KEP .

Bereits vorhandene Protokolle werden jetzt mit dem O_APPEND Flag (anstelle von O_TRUNC ) O_TRUNC , um den Verlust von Protokollen in bestimmten Situationen zu vermeiden und das Abschneiden von Protokollen mit externen Rotationsdienstprogrammen zu vereinfachen.

Auch im Zusammenhang mit der Kubernetes-API kann festgestellt werden, dass im Feld PodSandbox und PodSandboxStatus Feld PodSandboxStatus runtime_handler , um Informationen zur RuntimeClass im Pod zu berücksichtigen (weitere Informationen finden Sie im Text zur Version Kubernetes 1.12 , in der diese Klasse als Alpha-Version RuntimeClass ) und in Admission Webhooks implementierte die Möglichkeit zu bestimmen, welche Versionen von AdmissionReview sie unterstützen. Schließlich können Sie in den Admission Webhooks-Regeln den Anwendungsbereich jetzt auf den Namespace und den Clusterbereich beschränken.

Lagereinrichtungen

PersistentLocalVolumes , die seit der Veröffentlichung von K8s 1.10 Beta-Status haben, werden als stabil (GA) deklariert : Dieses Feature-Gate wird nicht mehr deaktiviert und in Kubernetes 1.17 entfernt.

Die Möglichkeit, die Umgebungsvariablen der sogenannten Downward-API (z. B. den Pod-Namen) für als subPath gemountete subPath wurde entwickelt - in Form eines neuen subPathExpr Felds, mit dem nun der gewünschte Verzeichnisname ermittelt wird. Ursprünglich erschien die Funktion in Kubernetes 1.11, für 1.14 blieb sie jedoch im Alpha-Versionsstatus.

Wie bei der vorherigen Version von Kubernetes wurden viele wichtige Änderungen für das sich schnell entwickelnde CSI (Container Storage Interface) eingeführt:

CSI

Unterstützung für die Größenänderung Unterstützung für CSI-Volumes ist verfügbar (als Teil der Alpha-Version). Um es verwenden zu können, müssen Sie das Feature-Gate ExpandCSIVolumes sowie das Vorhandensein von Unterstützung für diesen Vorgang in einem bestimmten CSI-Treiber ExpandCSIVolumes .

Ein weiteres Merkmal für CSI in der Alpha-Version ist die Möglichkeit , im Rahmen der Pod-Spezifikation direkt (d. H. Ohne Verwendung von PV / PVC) auf CSI-Volumes zu verweisen. Dies hebt die Einschränkung auf, CSI ausschließlich als Remote-Data-Warehouses zu verwenden , und öffnet ihnen die Tür zur Welt der lokalen kurzlebigen Volumes . Zur Verwendung ( Beispiel aus der Dokumentation ) müssen Sie das CSIInlineVolume Feature-Gate CSIInlineVolume .

Bei den „Interna“ von Kubernetes im Zusammenhang mit CSI wurden Fortschritte erzielt, die für Endbenutzer (Systemadministratoren) nicht so auffällig sind. Derzeit sind Entwickler gezwungen, zwei Versionen jedes Speicher-Plugins zu unterstützen: eine ist „altmodisch“ innerhalb der K8-Codebasis (in -tree) und das zweite - als Teil des neuen CSI (lesen Sie zum Beispiel hier mehr darüber ) . Dies führt zu verständlichen Unannehmlichkeiten, die behoben werden müssen, wenn sich der CSI als solcher stabilisiert. Das einfache Verwerfen der veralteten API der In-Tree-Plug-Ins ist aufgrund der entsprechenden Kubernetes-Richtlinie nicht möglich.

All dies führte dazu, dass die Alpha-Version den Prozess der Migration des internen Codes von Plug-Ins, die als In- Tree- Implementierung implementiert wurden, auf CSI-Plugins erreichte, wodurch die Bedenken der Entwickler auf die Unterstützung einer Version ihrer Plug-Ins reduziert werden und die Kompatibilität mit alten APIs bestehen bleibt und dies auch bleiben kann wie gewohnt für veraltet erklären. Es wird erwartet, dass bis zur nächsten Version von Kubernetes (1.15) alle Cloud-Provider-Plugins migriert werden, die Implementierung den Beta-Status erhält und in den Standard-K8-Installationen aktiviert wird. Einzelheiten finden Sie im Entwurfsvorschlag . Diese Migration führte auch zur Ablehnung von Einschränkungen für Volumes, die von bestimmten Cloud-Anbietern (AWS, Azure, GCE, Cinder) definiert wurden.

Darüber hinaus wurde die Unterstützung für CSI-Blockgeräte ( CSIBlockVolume ) auf Beta umgestellt .

Knoten / Kubelet

Einführung einer Alpha-Version des neuen Endpunkts in Kubelet, mit der Metriken für die Hauptressourcen zurückgegeben werden sollen . Wenn Kubelet früher Statistiken über die Verwendung von Containern von cAdvisor abgerufen hat, stammen diese Daten jetzt von der Container-Laufzeit über das CRI (Container Runtime Interface), die Kompatibilität mit älteren Docker-Versionen bleibt jedoch erhalten. Früher wurden in Kubelet gesammelte Statistiken über die REST-API bereitgestellt, jetzt wird der Endpunkt unter /metrics/resource/v1alpha1 . Die langfristige Strategie der Entwickler besteht darin, die von Kubelet bereitgestellten Metriken zu minimieren. Übrigens werden diese Metriken selbst jetzt nicht als "Kernmetriken", sondern als "Ressourcenmetriken" bezeichnet und als "erstklassige Ressourcen wie CPU und Speicher" bezeichnet.

Eine sehr interessante Nuance: Trotz des offensichtlichen Vorteils der gRPC-Endpunktleistung im Vergleich zu verschiedenen Fällen der Verwendung des Prometheus-Formats (das Ergebnis eines der unten aufgeführten Benchmarks) bevorzugten die Autoren das Prometheus-Textformat aufgrund der klaren Führung dieses Überwachungssystems in der Community.

„GRPC ist nicht mit wichtigen Überwachungspipelines kompatibel. Endpoint ist nur nützlich, um Metriken an Metrics Server zu liefern oder Komponenten zu überwachen, die direkt in ihn integriert sind. Bei Verwendung von Caching in Metrics Server ist die Leistung des Prometheus-Textformats gut genug , um Prometheus gegenüber gRPC vorzuziehen, da Prometheus in der Community weit verbreitet ist. Wenn das OpenMetrics-Format stabiler wird, können wir mit einem protobasierten Format der gRPC-Leistung näher kommen. “

Einer der vergleichenden Leistungstests unter Verwendung der Formate gRPC und Prometheus im neuen Kubelet-Endpunkt für Metriken. Weitere Grafiken und andere Details finden Sie in KEP .

Unter anderem:

• Kubelet akzeptiert jetzt den Parameter pid=<number> in den --system-reserved und --kube-reserved , um sicherzustellen, dass die angegebene PID für das gesamte System bzw. die Kubernetes- --kube-reserved ist. Die Funktion wird aktiviert, wenn das Feature-Gate mit dem Namen SupportNodePidsLimit aktiviert ist.
• Kubelet versucht nun (einmal) , Container in einem unbekannten Zustand zu stoppen, bevor sie neu gestartet und gelöscht werden.
• Bei Verwendung von PodPresets dem Init-Container jetzt dieselben Informationen wie bei einem regulären Container hinzugefügt .
• Kubelet begann mit der Verwendung von usageNanoCores vom CRI-Statistikanbieter, und Netzwerkstatistiken wurden für Knoten und Container unter Windows hinzugefügt .
• Informationen zum Betriebssystem und zur Architektur werden jetzt in den kubernetes.io/os und kubernetes.io/arch von Node-Objekten aufgezeichnet (von Beta nach GA übertragen).
• Die Möglichkeit, eine bestimmte Systembenutzergruppe für Container im Pod RunAsGroup ( RunAsGroup , erschienen in K8s 1.11 ), wurde auf die Beta-Version (standardmäßig aktiviert) umgestellt .
• du und find, die in cAdvisor verwendet werden, werden durch Go-Implementierungen ersetzt.

CLI

Das Flag -k wurde zur Integration mit kustomize zu cli-runtime und kubectl hinzugefügt (übrigens wird es jetzt in einem separaten Repository entwickelt), d. H. Informationen zum Verarbeiten zusätzlicher YAML-Dateien aus speziellen Anpassungsverzeichnissen (Einzelheiten zu deren Verwendung finden Sie unter KEP ):


Ein Beispiel für eine einfache Verwendung der Anpassungsdatei (eine kompliziertere Verwendung der Anpassung in Überlagerungen ist ebenfalls möglich )

Außerdem:

• Das kubectl-Logo und seine Dokumentation wurden aktualisiert - siehe kubectl.docs.kubernetes.io .
  
  
• Ein neuer Befehl kubectl create cronjob wurde kubectl create cronjob , dessen Name für sich selbst spricht.
• In kubectl logs Sie jetzt die Flags -f ( --follow für Streaming-Protokolle) und -l ( --selector für Label-Abfragen) --selector .
• kubectl hat gelernt, mit einem Platzhalter ausgewählte Dateien zu kopieren.
• Das Flag --all wurde dem Befehl kubectl wait hinzugefügt, um alle Ressourcen im Namespace des angegebenen Ressourcentyps auszuwählen.
• Deklarierter stabiler Plugin- Mechanismus für kubectl .

Andere

Der stabile Status (GA) erhielt die folgenden Funktionen:

• Unterstützung für Windows-Knoten (einschließlich Windows Server 2019), was die Möglichkeit impliziert, Windows Server-Container in Kubernetes zu planen (siehe auch KEP );
• ReadinessGate wird in der Pod-Spezifikation verwendet, um zusätzliche Bedingungen zu bestimmen, die bei der Bereitschaft des Pods berücksichtigt werden.
• Unterstützung für große Seiten (Feature Gate namens HugePages );
• CustomPodDNS ;
• PriorityClass API, Pod Priority & Preemption .

Weitere in Kubernetes 1.14 eingeführte Änderungen:

• Die Standard-RBAC-Richtlinie bietet nicht mehr authentifizierten Benutzern keinen Zugriff auf die discovery API und keine Zugriffsüberprüfung.
• Die offizielle Unterstützung für CoreDNS wird nur für Linux bereitgestellt. Wenn Sie kubeadm für die (CoreDNS) Bereitstellung in einem Cluster verwenden, sollten Knoten nur unter Linux funktionieren (nodeSelectors werden für diese Einschränkung verwendet).
• Die Standard-CoreDNS-Konfiguration verwendet jetzt das Forward-Plugin anstelle des Proxys. Darüber hinaus wurde CoreDNS um ReadinessProbe erweitert, wodurch ein Lastausgleich auf den entsprechenden (nicht betriebsbereiten) Pods verhindert wird.
• In kubeadm wurde es in der upload-certs init oder upload-certs möglich , die Zertifikate hochzuladen, die erforderlich sind, um die neue Steuerebene mit dem kubeadm-certs-Geheimnis zu verbinden (das --experimental-upload-certs wird verwendet).
• Für Windows-Installationen wurde eine Alpha-Version der Unterstützung für gMSA (Group Managed Service Account) - spezielle Konten in Active Directory, die von Containern verwendet werden können - angezeigt.
• Für GCE wurde die mTLS-Verschlüsselung zwischen etcd und kube-apiserver aktiviert .
• Aktualisierungen in der verwendeten / abhängigen Software: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, Unterstützung für Docker 18.09 in kubeadm und die mindestens unterstützte Version der Docker-API waren 1.26.

PS

Lesen Sie auch in unserem Blog:

• „ Kubernetes 1.13: Ein Überblick über wichtige Innovationen “;
• „ Kubernetes 1.12: Überblick über wichtige Innovationen “;
• „ Kubernetes 1.11: Ein Überblick über wichtige Innovationen “;
• " Kubernetes 1.10: Ein Überblick über wichtige Innovationen ."