Der Montag
sollte offiziell stattfinden
( aber bisher ist dies nicht geschehen ... AKTUALISIERT am 20.06 .: Die Ankündigung erschien im K8s-Blog). Kubernetes nächste Veröffentlichung ist
1.15 . Gemäß der Tradition, die sich für unseren Blog entwickelt hat, sprechen wir über die wichtigsten Änderungen in der neuen Version.
Die zur Vorbereitung dieses Materials verwendeten Informationen stammen aus
der Kubernetes-Erweiterungsverfolgungstabelle ,
CHANGELOG-1.15 und verwandten Problemen, Pull-Anforderungen sowie Kubernetes-Verbesserungsvorschlägen (KEP). Da die KubeCon-Konferenz in Shanghai nächste Woche stattfinden wird, hatte diese Veröffentlichung einen verkürzten 11-Wochen-Zyklus (anstelle von 12 Wochen), der jedoch die Anzahl der signifikanten Änderungen nicht wesentlich beeinflusste. Also lass uns gehen! ..
Data Warehouses
Einführung eines
neuen API ExecutionHook , mit dem Sie Benutzerbefehle in einem Pod / Container oder einer Gruppe von Pods / Containern dynamisch ausführen können, und damit des entsprechenden Controllers (
ExecutionHookController ), der die Verwaltung des Hook-Lebenszyklus implementiert. Die Motivation für das Erscheinen dieser Funktion war der Wunsch, Benutzern die Möglichkeit zu geben, Schnappschüsse gemäß der Logik der Anwendung zu erstellen / löschen, d. H. Führen Sie vor und nach dem Erstellen des Snapshots alle anwendungsspezifischen Befehle aus. Es wird davon ausgegangen, dass solche Hooks auch in anderen Situationen nützlich sein können - beispielsweise beim Durchführen von Updates, beim Debuggen, beim Aktualisieren von Konfigurationsdateien, beim Neustarten des Containers und beim Vorbereiten auf andere Ereignisse wie die Datenbankmigration. Aktueller Status - Alpha-Version (voraussichtlich für die nächste Version in Beta übersetzt), Details - in
KEP .
Im kurzlebigen Speicher , mit dem Sie für bestimmte Pods / Container die Menge des gemeinsam genutzten gemeinsam genutzten Speicherplatzes
(gemeinsam genutzten Speicher) unterscheiden können , wurde die
Unterstützung für Dateisystemkontingente
hinzugefügt . Dieser neue Mechanismus verwendet Projektquoten (
Projektquoten ), die in XFS und ext4 verfügbar sind, und ermöglicht die Überwachung des Ressourcenverbrauchs und die optionale Auferlegung von Grenzwerten. Aktueller Status - Alpha-Version; Pläne für zukünftige Versionen wurden noch nicht spezifiziert.
Eine weitere neue Funktion von sig-storage ist die Verwendung vorhandener PVCs als
DataSource zum Erstellen neuer PVCs. Mit anderen Worten ist dies eine
Implementierung der Volume-Klonfunktion . Klone sollten von Snapshots unterschieden werden, da jeder Klon ein neues und „vollwertiges“ Volume ist: Er wird als Kopie eines vorhandenen Volumes erstellt, folgt jedoch vollständig dem Lebenszyklus normaler Volumes (im Gegensatz zu Snapshots, obwohl es sich um Kopien von Volumes zu einem bestimmten Zeitpunkt handelt, jedoch nicht unabhängig Bände). Gelegenheitsillustration:
kind: PersistentVolumeClaim apiVersion: v1 metadata: name: pvc-2 namespace: myns spec: capacity: storage: 10Gi dataSource: kind: PersistentVolumeClaim name: pvc-1
In diesem Fall wird ein neues eigenständiges PV / PVC ( pvc-2 ) erstellt, das dieselben Daten wie auf pvc-1 . Es wird angegeben, dass das neue PVC den gleichen Namespace wie das Original haben sollte.Die vorhandenen Einschränkungen werden nur für Dynamic Provisioner und nur für CSI-Plugins unterstützt (sie müssen über die Funktion
CLONE_VOLUME ). Lesen Sie mehr bei
KEP .
Die folgenden Funktionen sind auf den Status der Beta-Version (und damit auf die Aktivierung in Kubernetes Standardinstallationen) "angewachsen":
- Persistente Volumengrößenerweiterungsfunktion "online", d.h. ohne dass der Pod mit dem entsprechenden PVC neu gestartet werden muss. Zum ersten Mal (im Alpha-Status) erschien es in K8s 1.11.
- Unterstützung für Umgebungsvariablen für als
subPath gemountete subPath , die erstmals in K8s 1.11 eingeführt und in der Vergangenheit 1.14 entwickelt wurden.
Der Prozess der Migration der Interna der alten Plug-Ins für Repositorys, die in der Kubernetes-Codebasis (In-Tree) implementiert sind, hat sich jedoch zugunsten der Plug-Ins für die neue CSI-Schnittstelle verschoben. Es wurde erwartet, dass die Version 1.15 die Migration aller Plug-Ins von Cloud-Anbietern abschließen wird. Es wurde jedoch
beschlossen , den Status der Alpha-Version beizubehalten, da die Funktion von den in K8s 1.15 eingeführten und bislang nur in der Alpha-Version implementierten APIs abhängt (insbesondere handelt es sich um Verbesserungen in Azure-Unterstützung:
Azure-Datei- und
Azure-Festplatten- Plugins in csi-translation-lib).
Planer
Zwei bemerkenswerte Neuerungen - beide bisher in Alpha-Form - sind im Kubernetes Scheduler verfügbar.
Das erste ist das
Scheduling Framework (
Kubernetes Scheduling Framework ), ein neuer Satz von APIs für Plugins, die die Funktionen eines vorhandenen Schedulers erweitern. Plugins werden außerhalb des Hauptrepositorys (außerhalb des Baums) erstellt, aber während der Kompilierung in den Scheduler aufgenommen. Somit bleibt der Funktionskern des Schedulers so einfach und bequem wie möglich zu unterstützen, und zusätzliche Funktionen werden separat implementiert, ohne die vielen Einschränkungen, die die
derzeitige Art der Erweiterung der Funktionen des Schedulers mithilfe von Webhooks "erlitten" hat.
In dem neuen Framework ist jeder Pod-Planungsversuch in zwei Phasen unterteilt:
- Planungszyklus - wo der Knoten für den Pod ausgewählt ist,
- und Bindung (Bindungszyklus) - wobei die ausgewählte Lösung innerhalb des Clusters implementiert ist.
In jeder dieser Phasen (zusammen werden sie auch als
Planungskontext bezeichnet ) gibt es viele
Erweiterungspunkte , an denen jeweils Framework-Plugins aufgerufen werden können.
(Lebenszyklus zum Aufrufen von Plugins im Scheduling Framework.)Als Teil der Alpha-Version des Frameworks werden nur
Reserve- ,
Unreserve- und
Prebind-Punkte implementiert . Lesen Sie mehr über diese massive Innovation bei
KEP .
Die zweite
Option ist die
Non-Preempting- Option für PriorityClasses .
Prioritätsklassen erhielten in der letzten Version von Kubernetes einen stabilen Status (GA), was sich auf die Planung und Auswahl von Pods auswirkte: Pods werden nach Priorität geplant. Wenn Pods aufgrund fehlender Ressourcen nicht erstellt werden können, werden Pods erstellt Eine niedrigere Priorität kann verdrängt werden, um den erforderlichen Speicherplatz freizugeben.
Die neue Option -
Preempting , die in der
PriorityClass Struktur als Boolescher
Preempting definiert ist, bedeutet: Wenn ein Pod auf seine Planung wartet und
Preempting=false , werden beim Erstellen anderer Pods
keine anderen Pods vorbelegt. Dieses Feld wird in
PodSpec während des
Pod-Zulassungsprozesses PodSpec (ähnlich dem
PriorityClass Wert). Details zur Implementierung finden Sie in
KEP .
API-Maschinen
Für
CustomResources werden Verbesserungen vorgestellt, die für auf diese Weise gespeicherte Daten (im Rahmen von JSON in CRD) ein Verhalten implementieren sollen, das besser mit der allgemein akzeptierten Kubernetes-API übereinstimmt (für "native" K8s-Objekte):
- Automatisches Löschen von Feldern, die nicht in OpenAPI-Validierungsschemata angegeben sind - Einzelheiten finden Sie in KEP „ Bereinigen für benutzerdefinierte Ressourcen “.
- Die Möglichkeit, Standardwerte für Felder in OpenAPI v3-Validierungsschemata festzulegen. Dies ist besonders wichtig, um die API-Kompatibilität beim Hinzufügen neuer Felder zu Objekten aufrechtzuerhalten. Weitere Informationen finden Sie unter KEP „ Standard für benutzerdefinierte Ressourcen “.
Beide Funktionen sollten ursprünglich in der Version von K8s 1.12 enthalten sein, werden jedoch erst jetzt in Alpha-Versionen angeboten.
Die Änderungen der CRD waren nicht darauf beschränkt:
- CRD OpenAPI- Funktion veröffentlichen - d. H. Die serverseitige CustomResources-Validierung (unter Verwendung des OpenAPI v3-Schemas), die in der letzten Kubernetes-Version eingeführt wurde, hat die Beta erreicht und ist jetzt standardmäßig aktiviert.
- Der Versionskonvertierungsmechanismus für CRD-Ressourcen, die auf externen Webhooks basieren, wurde ebenfalls auf Beta konvertiert.
Eine weitere interessante Neuerung heißt
Watch bookmark . Seine Essenz besteht darin, der
Watch API -
Bookmark einen neuen Ereignistyp hinzuzufügen. Dieser Typ bedeutet eine Bezeichnung, dass alle Objekte bis zu einer bestimmten
resourceVersion bereits von der Uhr verarbeitet wurden. Ein solcher Mechanismus verringert die Belastung des Kube-Apiservers, verringert die Anzahl der Ereignisse, die bei jedem Neustart der Uhr verarbeitet werden müssen, und verringert die Anzahl unerwünschter Fehler wie
"Ressourcenversion zu alt" . In Kubernetes 1.15 hat die Funktion den Status der Alpha-Version, und ihre Erhöhung auf Beta wird für die nächste Version erwartet.
Added EventType = "ADDED" Modified EventType = "MODIFIED" Deleted EventType = "DELETED" Error EventType = "ERROR" Bookmark EventType = "BOOKMARK"
(Mögliche Ereignistypen in der Watch-API.)In Admission Webhooks:
- Unterstützung für einen Objektselektor zusätzlich zu vorhandenen Namespace-Selektoren hinzugefügt
- die Möglichkeit implementiert , eine bestimmte Version einer Ressource zu registrieren und aufzurufen, wenn eine ältere Version dieser Ressource geändert wird;
- Das Feld
Option wurde der AdmissionReview-API hinzugefügt und enthält Berichtsoptionen für den ausgeführten Vorgang.
Netzwerk
Eine bedeutende Neuerung im Netzwerkteil von Kubernetes ist der sogenannte "
Finalizer Protection" für Load Balancer. Bevor Sie die Ressourcen des LoadBalancer löschen, wird überprüft, ob die entsprechende Serviceressource nicht vollständig gelöscht wurde. Zu diesem
type=LoadBalancer wird jedem Dienst ein sogenannter Finalizer mit dem
type=LoadBalancer : Wenn ein solcher Dienst gelöscht wird, wird das tatsächliche Löschen der Ressource blockiert, bis der Finalizer gelöscht wird, und der Finalizer wird nicht gelöscht, bis das "Löschen" der Ressourcen des entsprechenden Load Balancers abgeschlossen ist (
service.kubernetes.io/load-balancer-cleanup ). Die aktuelle Version der Implementierung ist die Alpha-Version. Details dazu finden Sie in
KEP .
Außerdem:
- Das in Kubernetes 1.13 eingeführte NodeLocal DNS Cache- Plugin zur Verbesserung der DNS-Leistung hat die Beta erreicht.
- Kube-Proxy entfernt Netzwerkregeln, die aufgrund seines Betriebs in anderen Modi erstellt wurden, nicht mehr automatisch (dies erfordert den expliziten Start von
kube-proxy --cleanup ).
CLI
Wie immer gab es in Konsolenbefehlen einige nette Kleinigkeiten für die Arbeit mit Kubernetes-Clustern:
Andere
Unter anderen bemerkenswerten Änderungen in Kubernetes 1.15:
- Die Unterstützung für das Pod Disruption Budget (PDB) wurde für CRD-basierte Ressourcen / Controller von Drittanbietern (z. B. EtcdCluster, MySQLReplicaSet ...) mithilfe der Scale-Unterressource hinzugefügt . Bisher ist dies eine Beta-Version, die in der nächsten Version stabilisiert wird. Details finden Sie im KEP .
- Zwei Funktionen für Knoten / Kubelet haben die Beta-Version erreicht: Unterstützung für Geräteüberwachungs-Plug-Ins von Drittanbietern (um alle gerätespezifischen Kenntnisse aus Kubelet zu entfernen, d. H. Außerhalb des Baums) und
SupportNodePidsLimit (Isolierung von PIDs von Knoten zu Schoten). - Die Unterstützung für Go-Module wurde hinzugefügt und standardmäßig für die Kubernetes-Codebasis aktiviert (anstelle von Godep und dem veralteten GOPATH-Modus).
- Die Unterstützung für AWS NLB (Network Load Balancer), die erstmals in K8s 1.9 eingeführt wurde, hat das Beta-Level erreicht. Insbesondere konnte sie
accessLogs konfigurieren, TLS beenden und LoadBalancerSourceRanges . - Die Möglichkeit zum Konfigurieren des Azure-Cloud-Anbieters
cloudConfigType von Kubernetes-Geheimnissen wurde cloudConfigType (hierfür wurde eine neue cloudConfigType Option cloudConfigType , von der eine möglicherweise secret ). Außerdem kann Kubelet in Azure jetzt auch ohne Azure-Identität arbeiten ( useInstanceMetadata muss dafür aktiviert sein). - Im Cluster-Lebenszyklus wurde die Möglichkeit zum Erstellen von HA-Clustern mit kubeadm in die Beta-Phase gebracht und der nächste Schritt (v1beta2) zur Neuorganisation des Formats der kubeadm-Konfigurationsdatei abgeschlossen.
- Die Anzahl der Pods im Status " Ausstehend " in verschiedenen Warteschlangen wird zu den Metriken des Schedulers hinzugefügt , und Statistiken zu Volumes über Kubelet-Volume-Metriken von CSI werden hinzugefügt.
- Aktualisierungen in der verwendeten / abhängigen Software: Go 1.12.5, cri-tools 1.14.0 usw. 3.3.10 (die Version wurde für den Server nicht geändert, aber für den Client aktualisiert) . Die Versionen von CNI, CSI, CoreDNS haben sich nicht geändert (in einer der Alpha-Versionen von Kubernetes 1.15 wurde es auf 1.5.0 aktualisiert, dann aber auf 1.3.1 zurückgesetzt) , unterstützte Versionen von Docker.
PS
Lesen Sie auch in unserem Blog: