In dieser Nacht ist das nächste Release von Kubernetes — . In Übereinstimmung mit der Tradition unseres Blogs berichten wir über die wichtigsten Änderungen in der neuen Version dieses bemerkenswerten Open Source-Produkts.
Die Informationen, die zur Erstellung dieses Materials verwendet wurden, stammen aus , und zugehörige Issues, Pull Requests, Kubernetes Enhancement Proposals (KEP).
Beginnen wir mit einer wichtigen Einführung von SIG cluster-lifecycle: dynamische, ausfallsichere Cluster Kubernetes (oder, um genauer zu sein, selbstgehostete HA-Deployments) können jetzt ). Kurz gesagt: kubeadm zu wechseln. (init und beitretendie vom Cluster verwendeten Zertifikate werden in Secrets übertragen;
- um die Verwendung von etcd innerhalb des K8s-Clusters (d.h. die Beseitigung der bisherigen externen Abhängigkeit) zu ermöglichen, wird
- etcd-operator ;
- Architektur des HA-Kubernetes-Clusters, erstellt mit kubeadm
Die Einzelheiten zur Implementierung sind in
design proposal . Dieses Feature wurde wirklich lang erwartet: Die Alpha-Version wurde bereits für K8s 1.9 angekündigt, ist aber erst jetzt verfügbar.
API
Der Befehl apply und allgemein deklarative Verwaltung von Objekten von kubectl in den apiserver. Die Entwickler erläutern kurz ihre Entscheidung damit, dass kubectl apply — ein grundlegender Teil der Arbeit mit Konfigurationen in Kubernetes, jedoch voller Bugs und schwer zu reparieren ist, weshalb diese Funktionalität in einen funktionierenden Zustand gebracht und in den Control Plane verlagert werden muss. Hier sind einige einfache und anschauliche Beispiele für bestehende Probleme:
Details zur Implementierung finden Sie in . Der aktuelle Status ist Alpha-Version (das Upgrade auf Beta ist für die nächste Kubernetes-Version geplant).
In der Alpha-Version wurde die Verwendung des OpenAPI v3-Schemas für die Erstellung und Veröffentlichung von OpenAPI-Dokumentation für CustomResources (CR), die zur Validierung (auf Serverseite) von K8s-Ressourcen dienen, die vom Benutzer definiert sind (CustomResourceDefinition, CRD). Die Veröffentlichung von OpenAPI für CRD ermöglicht es den Clients (zum Beispiel, kubectl) die Validation auf ihrer Seite (im Rahmen von kubectl create und kubectl apply) durchzuführen und Schemadokumentation bereitzustellen (kubectl explain). Weitere Details finden Sie in .
Frühere Protokolle das Flag O_APPEND (und nicht O_TRUNC) um den Verlust von Logs in bestimmten Situationen zu vermeiden und um das Truncieren von Logs mit externen Tools zur Rotation zu erleichtern.
Im Kontext der Kubernetes-API ist zudem zu erwähnen, dass in PodSandbox und PodSandboxStatus das Feld runtime_handler zur Erfassung von Informationen über RuntimeClass in einem Pod (näheres dazu erfahren Sie im Text über , wo diese Klasse als Alpha-Version eingeführt wurde), sowie in den Admission Webhooks die Möglichkeit besteht, welche Versionen AdmissionReview sie unterstützen. Schließlich können in den Regeln für Admission Webhooks nun auf Namespaces und Clustergrenzen beschränkt werden.
Speicherlösungen
, die mit dem Status Beta seit der Veröffentlichung , sind jetzt stabil (GA): dieses Feature-Gate wird nicht mehr deaktiviert und wird in Kubernetes 1.17 entfernt.
die Verwendung von Umgebungsvariablen bekannt als (zum Beispiel den Namen des Pods) für die Benennung von Verzeichnissen, die als gemountet werden, hat sich weiterentwickelt – in Form eines neuen Feldes subPathExpr, welches nun zur Bestimmung des erforderlichen Verzeichnisnamens verwendet wird. Dieses Feature erschien ursprünglich in Kubernetes 1.11, blieb jedoch auch für 1.14 im Alpha-Status.
Wie in der vorherigen Version von Kubernetes wurden viele bedeutende Änderungen für das aktiv weiterentwickelte CSI (Container Storage Interface) vorgestellt:
CSI
Wurde in der Alpha-Version verfügbar gemacht Änderung der Größe für CSI-Volumes. Um es zu nutzen, müssen Sie das Feature-Gate mit dem Namen ExpandCSIVolumesaktivieren und die Unterstützung dieser Operation im spezifischen CSI-Treiber vorhanden sein.
Eine weitere Funktion für CSI in der Alpha-Version ist die direkte Referenzierung (d.h. ohne Verwendung von PV/PVC) auf CSI-Volumes innerhalb der Pod-Spezifikation. Dies aufhebt die Einschränkung, CSI ausschließlich als entfernte Datenspeicher zu verwenden, und öffnet ihnen die Türen zur Welt . Für die Nutzung () muss das CSIInlineVolume Feature-Gate aktiviert werden.
Es gibt Fortschritte in den „Innereien“ von Kubernetes in Bezug auf CSI, die den Endbenutzern (Systemadministratoren) nicht so offensichtlich sind... Momentan sind die Entwickler gezwungen, zwei Versionen jedes Storage-Plugins zu pflegen: eine „alte“ Version innerhalb der K8s-Codebasis (in-tree) und eine zweite im Rahmen des neuen CSI. (näheres dazu lesen Sie zum Beispiel in ). Dies verursacht verständliche Unannehmlichkeiten, die beseitigt werden müssen, während sich CSI als solches stabilisiert. Einfach die in den internen (in-tree) Plugins verwendeten APIs als veraltet zu erklären, ist aufgrund von .
All dies führte dazu, dass die Alpha-Versionen erreicht wurden internen Plugin-Code, die als in-tree und in CSI-Plugins implementiert werden, wodurch die Sorgen der Entwickler auf die Unterstützung einer Version ihrer Plugins reduziert werden und die Kompatibilität mit älteren APIs erhalten bleibt, sodass sie im üblichen Szenario als veraltet deklariert werden können. Es wird erwartet, dass bis zur nächsten Kubernetes-Version (1.15) alle Plugins von Cloud-Anbietern migriert, die Implementierung den Status einer Beta-Version erhalten und in K8s-Installationen standardmäßig aktiviert wird. Weitere Informationen finden Sie in . Die Folge dieser Migration war auch von Einschränkungen für Volumes, die von bestimmten Cloud-Anbietern (AWS, Azure, GCE, Cinder) definiert werden.
Darüber hinaus wird die Unterstützung von Blockgeräten mit CSI (CSIBlockVolume) .
Knoten / Kubelet
Die Alpha-Version wurde eingeführt in Kubelet, der für die Bereitstellung von Metriken zu den grundlegenden Ressourcen gedacht ist. Generell erhält Kubelet, anstatt die Container-Nutzungsstatistiken von cAdvisor zu beziehen, nun diese Daten aus der Ausführungsumgebung des Containers über die CRI (Container Runtime Interface). Allerdings bleibt die Kompatibilität zu älteren Docker-Versionen erhalten. Früher wurde die in Kubelet gesammelte Statistik über die REST API bereitgestellt, jetzt wird dafür ein Endpoint verwendet, der unter folgender Adresse zu finden ist. /metrics/resource/v1alpha1. Die langfristige Strategie der Entwickler darin, die Anzahl der von Kubelet bereitgestellten Metriken zu minimieren. Übrigens werden diese Metriken nicht mehr «Core-Metriken», sondern «Ressourcen-Metriken» bezeichnet, die als «erstklassige Ressourcen, wie CPU und Arbeitsspeicher» beschrieben werden.
Ein interessanter Punkt: Trotz der offensichtlichen Leistungsvorteile des gRPC-Endpunkts im Vergleich zu verschiedenen Verwendungsszenarien des Prometheus-Formats (das Ergebnis eines der Benchmarks, siehe unten), bevorzugten die Autoren das textbasierte Format von Prometheus aufgrund der klaren Führungsposition dieses Überwachungssystems in der Community.
gRPC ist nicht mit den wichtigsten Monitoring-Pipelines kompatibel. Der Endpoint wird jedoch nur nützlich sein, um Metriken an den Metrics Server oder Monitoring-Komponenten zu liefern, die direkt mit ihm integriert sind. Bei Verwendung von Caching im Metrics Server ist die Leistung des textbasierten Formats von Prometheus ausreichend gut für uns, um Prometheus gegenüber gRPC zu bevorzugen, aufgrund der weitreichenden Verbreitung von Prometheus in der Community. Wenn das OpenMetrics-Format stabiler wird, können wir die Leistung von gRPC mit einem auf Proto basierenden Format annähern.
Einer der Vergleichstests zur Leistung von gRPC- und Prometheus-Formaten im neuen Kubelet-Endpoint für Metriken. Mehr Grafiken und weitere Details finden Sie in .
Unter den weiteren Änderungen:
- Kubelet versucht jetzt (einmalig) PodPresets
- Bei der Nutzung jetzt dem Init-Container die gleichen Informationen wie dem regulären Container.
- Kubelet
usageNanoCoresvom CRI-Statistikanbieter zu verwenden, und für Knoten und Container in Windows Netzwerkstatistiken. - Informationen über das Betriebssystem und die Architektur werden jetzt in Labels aufgezeichnet.
kubernetes.io/osundkubernetes.io/archNode-Objekte (von Beta in GA überführt). - Die Möglichkeit, eine bestimmte Benutzergruppe für Container im Pod anzugeben (
RunAsGroup, wurde eingeführt in ) bis zur Beta-Version (standardmäßig aktiviert). - du und find, die in cAdvisor verwendet werden, durch Go-Implementierungen ersetzt.
CLI
Im cli-runtime und kubectl das -k-Flag zur Integration mit (übrigens wird dessen Entwicklung jetzt in einem separaten Repository durchgeführt), d.h. zur Verarbeitung zusätzlicher YAML-Dateien aus speziellen Verzeichnissen der kustomization (weiterführende Informationen zur Verwendung finden Sie in ):
Beispiel für die einfache Verwendung der Datei (kompliziertere Anwendungen von kustomize sind ebenfalls möglich im Rahmen von )
Darüber hinaus:
- neuer Befehl
kubectl create cronjob, dessen Name für sich spricht. - In
kubectl logsist jetzt möglich Flags-f(--followzum Streaming von Logs) und-l(--selectorfür die Label-Abfrage). - kubectl Dateien auszuwählen, die mit Wildcards kopiert werden.
- Im Befehl
kubectl waitDas Flag--allum alle Ressourcen eines spezifizierten Ressourcentyps im Namespace auszuwählen.
Andere
Folgende Funktionen haben den stabilen (GA) Status erreicht:
- , verwendet in der Pod-Spezifikation zur Feststellung zusätzlicher Bedingungen, die bei der Bereitschaft des Pods berücksichtigt werden;
- Unterstützung großer Seiten (Feature-Gate mit dem Namen );
- ;
- PriorityClass API, .
Weitere Änderungen, die in Kubernetes 1.14 eingeführt wurden:
- Die Standard-RBAC-Policy gewährt keinen Zugriff mehr auf die API
discoveryundaccess-reviewBenutzern ohne Authentifizierung (unauthenticated). - Offizielle Unterstützung für CoreDNS ausschließlich für Linux bereitgestellt, daher müssen bei der Verwendung von kubeadm zur Bereitstellung von CoreDNS im Cluster die Knoten nur unter Linux laufen (für diese Einschränkung werden nodeSelectors verwendet).
- Die Standardkonfiguration von CoreDNS ist jetzt anstelle von Proxy. Darüber hinaus gibt es in CoreDNS eine readinessProbe, die das Load Balancing für die entsprechenden (nicht einsatzbereiten) Pods verhindert.
- In kubeadm, während der Phasen
initoderupload-certs, die erforderlichen Zertifikate für den Anschluss eines neuen control-plane an das Secret kubeadm-certs hochzuladen (das Flag--experimental-upload-certs). - Für Windows-Installationen gibt es eine Alpha-Version gMSA (Group Managed Service Account) — spezielle Konten in Active Directory, die auch von Containern verwendet werden können.
- Für GCE mTLS-Verschlüsselung zwischen etcd und kube-apiserver.
- Updates in the used/dependent software: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, Docker 18.09 support in kubeadm, with the minimum supported version of Docker API being 1.26.
P.S.
Lesen Sie auch in unserem Blog:
- «»;
- «»;
- «»;
- «».
Quelle: habr.com
