Diese Nacht nächste Version von Kubernetes - . Gemäß der Tradition, die sich für unseren Blog entwickelt hat, sprechen wir über die wichtigsten Änderungen in der neuen Version dieses wunderbaren Open-Source-Produkts.
Die zur Erstellung dieses Materials verwendeten Informationen stammen aus , und verwandte Probleme, Pull Requests, Kubernetes Enhancement Proposals (KEP).
Beginnen wir mit einer wichtigen Einführung aus dem SIG-Cluster-Lebenszyklus: dynamische Failover-Cluster Kubernetes (oder genauer gesagt selbst gehostete HA-Bereitstellungen) ist jetzt verfügbar Verwendung bekannter Befehle (im Kontext von Einzelknoten-Clustern). kubeadm (init и join). Kurz gesagt, dazu:
- vom Cluster verwendete Zertifikate werden in Geheimnisse übertragen;
- für die Möglichkeit, den etcd-Cluster innerhalb des K8s-Clusters zu verwenden (d. h. die zuvor bestehende externe Abhängigkeit zu beseitigen) ;
- Dokumentiert die empfohlenen Einstellungen für einen externen Load Balancer, der eine fehlertolerante Konfiguration bereitstellt (es ist geplant, diese Abhängigkeit in Zukunft zu beseitigen, jedoch noch nicht).
Architektur eines mit kubeadm erstellten Kubernetes HA-Clusters
Details zur Umsetzung finden Sie in . Dieses Feature wurde wirklich lange erwartet: Die Alpha-Version wurde bereits in K8s 1.9 erwartet, erschien aber erst jetzt.
API
Team apply und überhaupt deklarative Objektverwaltung von kubectl im Apiserver. Damit begründen die Entwickler selbst kurz ihre Entscheidung kubectl apply - ein grundlegender Bestandteil der Arbeit mit Konfigurationen in Kubernetes, jedoch „ist es voller Fehler und schwer zu beheben“ und daher muss diese Funktionalität wieder normalisiert und auf die Steuerungsebene übertragen werden. Einfache und klare Beispiele für Probleme, die heute bestehen:
Details zur Umsetzung finden Sie in . Die aktuelle Bereitschaft ist Alpha (die Weiterentwicklung zur Beta ist für die nächste Kubernetes-Version geplant).
Verfügbar in der Alpha-Version Verwenden des OpenAPI v3-Schemas für Erstellen und Veröffentlichen der OpenAPI-Dokumentation für CustomResources (CR) wird zur (serverseitigen) Validierung benutzerdefinierter K8-Ressourcen (CustomResourceDefinition, CRD) verwendet. Durch die Veröffentlichung von OpenAPI für CRD können Clients (z. B. kubectl) Führen Sie eine Validierung auf Ihrer Seite durch (innerhalb von kubectl create и kubectl apply) und Dokumentation gemäß dem Schema ausstellen (kubectl explain). Details - in .
Vorhandene Protokolle mit Fahne O_APPEND (und nicht O_TRUNC), um den Verlust von Protokollen in manchen Situationen zu vermeiden und um das Abschneiden von Protokollen mit externen Dienstprogrammen für die Rotation zu vereinfachen.
Auch im Kontext der Kubernetes API lässt sich feststellen, dass in PodSandbox и PodSandboxStatus Bereich runtime_handler Informationen darüber aufzeichnen RuntimeClass im Pod (lesen Sie mehr darüber im Text über , wo diese Klasse als Alpha-Version erschien) und in Admission Webhooks Möglichkeit, die Versionen zu bestimmen AdmissionReview Sie unterstützen. Schließlich gelten nun die Admission Webhooks-Regeln das Ausmaß ihrer Nutzung durch Namespaces und Cluster-Frameworks.
Tresore
, das seit der Veröffentlichung Beta-Status hatte , stabil (GA): Dieses Feature-Gate ist nicht mehr deaktiviert und wird in Kubernetes 1.17 entfernt.
unter Verwendung von Umgebungsvariablen namens (z. B. der Pod-Name) für die Namen der Verzeichnisse, die als gemountet sind , wurde entwickelt – in Form eines neuen Feldes subPathExpr, mit der nun der gewünschte Verzeichnisname ermittelt wird. Die Funktion erschien ursprünglich in Kubernetes 1.11, blieb aber für 1.14 im Alpha-Versionsstatus.
Wie bei der vorherigen Kubernetes-Version werden viele wichtige Änderungen für das sich aktiv entwickelnde CSI (Container Storage Interface) eingeführt:
CSI
Wurde verfügbar (als Teil der Alpha-Version) Größenänderung für CSI-Volumes. Um es zu verwenden, müssen Sie das sogenannte Feature-Gate aktivieren ExpandCSIVolumessowie das Vorhandensein einer Unterstützung für diesen Vorgang in einem bestimmten CSI-Treiber.
Ein weiteres Feature für CSI in der Alpha-Version - Verweisen Sie direkt (d. h. ohne Verwendung von PV/PVC) auf CSI-Volumes innerhalb der Pod-Spezifikation. Das hebt die Einschränkung der Nutzung von CSI als ausschließlich Remote-Datenspeicher aufund öffnete ihnen Türen zur Welt . Für den Einsatz () muss aktiviert sein CSIInlineVolume Feature-Tor.
Es gab auch Fortschritte bei den „Interna“ von Kubernetes im Zusammenhang mit CSI, die für Endbenutzer (Systemadministratoren) nicht so sichtbar sind ... Derzeit sind Entwickler gezwungen, zwei Versionen jedes Speicher-Plugins zu unterstützen: eine – „im old way“, innerhalb der K8s-Codebasis (in -tree) und der zweite – als Teil des neuen CSI (Lesen Sie mehr darüber zum Beispiel in ). Dies verursacht verständliche Unannehmlichkeiten, die behoben werden müssen, wenn sich CSI selbst stabilisiert. Aus diesem Grund ist es nicht möglich, die API interner (in-tree) Plugins einfach abzulehnen .
All dies führte dazu, dass die Alpha-Version erreicht wurde interner Plugin-Code, implementiert als In-Tree, in CSI-Plugins, wodurch die Sorgen der Entwickler auf die Unterstützung einer Version ihrer Plugins reduziert werden, die Kompatibilität mit alten APIs erhalten bleibt und sie im üblichen Szenario für veraltet erklärt werden können. Es wird erwartet, dass bis zum nächsten Release von Kubernetes (1.15) alle Cloud-Provider-Plugins migriert werden, die Implementierung Beta-Status erhält und in K8s-Installationen standardmäßig aktiviert wird. Einzelheiten finden Sie unter . Diese Migration führte auch dazu von Volumengrenzen, die von bestimmten Cloud-Anbietern (AWS, Azure, GCE, Cinder) definiert werden.
Darüber hinaus Unterstützung für Blockgeräte mit CSI (CSIBlockVolume) zur Beta-Version.
Knoten/Kubelet
Alpha-Version vorgestellt in Kubelet, entworfen für Rückgabemetriken für wichtige Ressourcen. Generell gilt: Während Kubelet früher Statistiken zur Containernutzung von cAdvisor erhielt, stammen diese Daten nun über CRI (Container Runtime Interface) aus der Container-Laufzeitumgebung, aber auch die Kompatibilität für die Arbeit mit älteren Docker-Versionen bleibt erhalten. Früher wurden in Kubelet gesammelte Statistiken über die REST-API gesendet, jetzt befindet sich ein Endpunkt unter /metrics/resource/v1alpha1. Langfristige Strategie der Entwickler besteht darin, die von Kubelet bereitgestellten Metriken zu minimieren. Übrigens, diese Metriken selbst nicht „Kernmetriken“, sondern „Ressourcenmetriken“ und werden als „erstklassige Ressourcen wie CPU und Speicher“ beschrieben.
Eine sehr interessante Nuance: Trotz des deutlichen Leistungsvorteils des gRPC-Endpunkts im Vergleich zu verschiedenen Fällen der Verwendung des Prometheus-Formats (siehe das Ergebnis eines der Benchmarks unten)Aufgrund der klaren Führung dieses Überwachungssystems in der Community bevorzugten die Autoren das Textformat von Prometheus.
„gRPC ist nicht mit den großen Überwachungspipelines kompatibel. Endpoint ist nur für die Bereitstellung von Metriken an Metrics Server oder die Überwachung von Komponenten nützlich, die direkt darin integriert sind. Leistung des Prometheus-Textformats bei Verwendung von Caching in Metrics Server gut genug Angesichts der weit verbreiteten Akzeptanz von Prometheus in der Community empfehlen wir Prometheus gegenüber gRPC. Sobald das OpenMetrics-Format stabiler wird, können wir die gRPC-Leistung mit einem protobasierten Format erreichen.“
Einer der vergleichenden Leistungstests zur Verwendung der Formate gRPC und Prometheus im neuen Kubelet-Endpunkt für Metriken. Weitere Grafiken und andere Details finden Sie in .
Unter anderem:
- Kubelet jetzt (einmalig) Container in einem unbekannten Zustand vor Neustart- und Löschvorgängen.
- Wenn Sie Nun zum Init-Container die gleichen Informationen wie für einen normalen Container.
- kubelet
usageNanoCoresvom CRI-Statistikanbieter und für Knoten und Container unter Windows Netzwerkstatistiken. - Betriebssystem- und Architekturinformationen werden jetzt in Etiketten aufgezeichnet
kubernetes.io/osиkubernetes.io/archKnotenobjekte (von Beta auf GA übertragen). - Möglichkeit, eine bestimmte Systembenutzergruppe für Container in einem Pod anzugeben (
RunAsGroup, erschien in ) vor der Betaversion (standardmäßig aktiviert). - du und find werden in cAdvisor verwendet, On-Go-Implementierung.
CLI
In CLI-Runtime und Kubectl -k Flag für die Integration mit (Übrigens wird seine Entwicklung jetzt in einem separaten Repository durchgeführt), d. h. um zusätzliche YAML-Dateien aus speziellen Anpassungsverzeichnissen zu verarbeiten (Einzelheiten zu deren Verwendung finden Sie unter ):
Beispiel für eine einfache Dateinutzung (Eine komplexere Anwendung von kustomize ist innerhalb möglich )
Außerdem:
- neues Team
kubectl create cronjob, dessen Name für sich spricht. - В
kubectl logskann jetzt Fahnen-f(--followfür Streaming-Protokolle) und-l(--selectorfür Etikettenabfrage). - kubectl Mit Platzhalter ausgewählte Dateien kopieren.
- Zum Team
kubectl waitFlagge--allum alle Ressourcen im Namespace des angegebenen Ressourcentyps auszuwählen.
Andere
Die folgenden Funktionen haben den Status „Stabil“ (GA) erhalten:
- , wird in der Pod-Spezifikation verwendet, um zusätzliche Bedingungen zu definieren, die bei der Bereitschaft des Pods berücksichtigt werden;
- Unterstützung für große Seiten (Feature Gate genannt );
- ;
- PriorityClass-API .
Weitere in Kubernetes 1.14 eingeführte Änderungen:
- Die Standard-RBAC-Richtlinie erlaubt keinen API-Zugriff mehr
discoveryиaccess-reviewBenutzer ohne Authentifizierung (nicht authentifiziert). - Offizielle CoreDNS-Unterstützung Nur Linux. Wenn Sie also kubeadm zum Bereitstellen (CoreDNS) in einem Cluster verwenden, dürfen Knoten nur unter Linux ausgeführt werden (für diese Einschränkung werden nodeSelectors verwendet).
- Die Standard-CoreDNS-Konfiguration ist jetzt statt Proxy. Auch in CoreDNS readinessProbe, das den Lastausgleich auf geeigneten (nicht betriebsbereiten) Pods verhindert.
- In kubeadm, auf Phasen
initoderupload-certs, Laden Sie die Zertifikate, die erforderlich sind, um die neue Steuerungsebene mit dem kubeadm-certs-Geheimnis zu verbinden (verwenden Sie das Flag--experimental-upload-certs). - Für Windows-Installationen ist eine Alpha-Version erschienen gMSA (Group Managed Service Account) – spezielle Konten im Active Directory, die auch von Containern genutzt werden können.
- Für G.C.E. mTLS-Verschlüsselung zwischen etcd und kube-apiserver.
- Updates in verwendeter/abhängiger Software: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, Docker 18.09-Unterstützung in kubeadm und die minimal unterstützte Docker-API-Version ist jetzt 1.26.
PS
Lesen Sie auch auf unserem Blog:
- «";
- «";
- «";
- «".
Source: habr.com