Heute ist der 27. September, was
bedeutet, dass wir während der Arbeitszeit (gemäß der US-Zeitzone) mit der nächsten Veröffentlichung von Kubernetes rechnen können - 1.12 (die offizielle Ankündigung wird jedoch manchmal verzögert). Im Allgemeinen ist es an der Zeit, die glorreiche Tradition fortzusetzen und über die wichtigsten Änderungen zu berichten, die wir auf der Grundlage öffentlicher Informationen aus dem Projekt
vornehmen werden :
Kubernetes bietet Tracking-Tabelle ,
CHANGELOG-1.12 , zahlreiche Probleme, Pull-Anfragen und Designvorschläge. Was ist neu in K8s 1.12?
Lagereinrichtungen
Wenn Sie eine Sache herausgreifen, die unter allen Problemen im Zusammenhang mit der Veröffentlichung von Kubernetes 1.12 häufiger als jede andere erwähnt wird, ist dies möglicherweise die
Container Storage Interface (CSI) , über die wir
bereits neulich geschrieben haben . Beginnen wir aus diesem Grund mit den Änderungen an der Speicherunterstützung.
Daher
haben CSI-Plugins den Beta-Status
beibehalten und werden voraussichtlich für die nächste Version von Kubernetes (1.13) stabil sein. Was ist dann neu in der CSI-Unterstützung?
Im Februar dieses Jahres
begannen die Arbeiten am
Topologiekonzept in der CSI-Spezifikation. Kurz gesagt, Topologie sind Informationen zur Clustersegmentierung (z. B. nach „Racks“ für lokale Installationen oder nach „Regionen“ und „Zonen“ für Cloud-Umgebungen), die Orchestrierungssysteme kennen und berücksichtigen müssen. Warum? Von Speicheranbietern zugewiesene Volumes sind nicht unbedingt im gesamten Cluster gleichermaßen zugänglich. Daher sind Kenntnisse der Topologie erforderlich, um Ressourcen effizient zu planen und Bereitstellungsentscheidungen zu treffen.
Das Ergebnis der Entstehung von Topologien in CSI (
angenommen in der Spezifikation am 1. Juni) war ihre Unterstützung in Kubernetes 1.12:
Dies endet jedoch nicht mit CSI-bezogenen Updates. Eine weitere wichtige Neuerung in der Version Kubernetes 1.12 ist die
Unterstützung von Snapshots für CSI (im Alpha-Status). Schnappschüsse für Volumes als solche wurden in der
Version von K8s 1.8 veröffentlicht . Die Hauptimplementierung, zu der der Controller und der Provisioner (zwei separate Binärdateien) gehören, wurde beschlossen, in
ein externes Repository übertragen zu werden . Seitdem wurden Volumes von GCE PD, AWS EBS, OpenStack Cinder, GlusterFS und Kubernetes
hostPath .
Der neue
Entwurfsvorschlag zielt darauf ab, „diese Initiative fortzusetzen, indem Snapshot-Unterstützung für CSI-Volume-Treiber hinzugefügt wird“ (Snapshot-Unterstützung in der CSI-Spezifikation wird
hier beschrieben). Da Kubernetes das Prinzip einhält, einen Mindestsatz an Funktionen in die Kern-API aufzunehmen, verwendet diese Implementierung (wie bei Snapshots im Volume Snapshot Controller) CRD (
CustomResourceDefinitions ).
Und ein paar neue Funktionen für CSI-Treiber:
- Die Alpha-Version der Fähigkeit des Treibers, sich in der Kubernetes-API zu registrieren (um Benutzern das Auffinden der im Cluster installierten Treiber zu erleichtern und es den Treibern zu ermöglichen, die Interaktionsprozesse von Kubernetes mit ihnen zu beeinflussen);
- Die Alpha-Version der Fähigkeit des Treibers , Informationen über das Laufwerk zu erhalten , das das Volume über
NodePublish
In der letzten Version von Kubernetes wurde der
Mechanismus zur dynamischen Begrenzung von Volumes auf Knoten eingeführt, der von Alpha auf Beta verschoben wurde. Sie haben es erraten, Unterstützung für CSI sowie Azure.
Schließlich wird die Funktion zur
Weitergabe des
Mount-Namespace , mit der Sie das Volume als
rshared (sodass alle gemounteten Containerverzeichnisse auf dem Host sichtbar sind) und in der
Version 1.10 von K8s einen Beta-Status hat, als stabil deklariert.
Planer
Im Scheduler verbessert Kubernetes 1.12 die Leistung dank der Alpha-Version des
Suchbeschränkungsmechanismus in einem Knotencluster, der zum Planen von Herden geeignet ist
(mögliche Knoten) . Früher überprüfte der
Kube-Scheduler bei jedem Versuch, jeden Pod zu planen, die Verfügbarkeit aller Knoten und übergab sie zur Auswertung. Jetzt findet der Scheduler nur eine bestimmte Anzahl von ihnen und beendet dann seine Arbeit. Gleichzeitig sieht der Mechanismus die obligatorische Auswahl von Knoten aus verschiedenen Regionen und Zonen sowie die Notwendigkeit vor, verschiedene Knoten in verschiedenen Planungszyklen anzuzeigen (wählen Sie nicht die ersten 100 Knoten bei jedem Start aus). Die Entscheidung zur Implementierung dieses Mechanismus wurde unter Berücksichtigung der Ergebnisse der Analyse der Daten zur Leistung des Schedulers getroffen (wenn das 90. Perzentil eine Zeit von 30 ms für einen Herd zeigte, dann das 99. Perzentil bereits 60 ms).
Darüber hinaus sind die folgenden Funktionen des Schedulers zur Beta-Version gereift:
- Taint-Knoten nach Bedingung , der in K8s 1.8 angezeigt wurde und das Markieren eines Knotens mit einem bestimmten Status (für weitere Aktionen) ermöglicht, wenn bestimmte Ereignisse auftreten: Jetzt erstellt der Lebenszyklus-Controller des Knotens automatisch Taints, und der Scheduler überprüft sie (anstelle von Bedingungen ).
DaemonSet in DaemonSet mit dem Kube-Scheduler (anstelle des DaemonSet Controllers): Standardmäßig wurde sie ebenfalls aktiviert.- Angeben einer Prioritätsklasse in
ResourceQuota .
Clusterknoten
Eine interessante Neuerung war das Erscheinungsbild (im Status der Alpha-Version) von
RuntimeClass - einer neuen Ressource auf Cluster-Ebene, die die Parameter der
Container-Laufzeit (Container-Laufzeit) RuntimeClass .
RuntimeClasses werden den Pods über dasselbe Feld in
PodSpec und implementieren die Unterstützung für die Verwendung mehrerer ausführbarer Umgebungen innerhalb eines Clusters oder Knotens. Warum?
„Das Interesse an der Verwendung unterschiedlicher Laufzeiten in einem Cluster wächst. Hauptmotiv dafür sind derzeit die Sandkästen und der Wunsch der Kata- und gVisor-Container, sich in Kubernetes zu integrieren. Andere Laufzeitmodelle wie Windows-Container oder sogar Remote-Laufzeitumgebungen werden in Zukunft ebenfalls Unterstützung benötigen. RuntimeClass bietet eine Möglichkeit, zwischen verschiedenen in einem Cluster konfigurierten Laufzeiten zu wählen und deren Eigenschaften zu ändern (sowohl vom Cluster als auch vom Benutzer). “
Um zwischen den vordefinierten Konfigurationen zu wählen, wird der
RuntimeHandler an das CRI (Container Runtime Interface) übergeben, das die aktuellen Anmerkungen des Herdes ersetzen soll:
Und die Konfiguration in Containerd für Kata-Runtime sieht ungefähr so aus:
[plugins.cri.containerd.kata-runtime] runtime_type = "io.containerd.runtime.v1.linux" runtime_engine = "/opt/kata/bin/kata-runtime" runtime_root = ""
Das
RuntimeClass Kriterium für die Alpha-Version ist eine erfolgreiche
CRI-Validierung .
Darüber hinaus ist der
Mechanismus zum Registrieren lokaler Plug-Ins (einschließlich CSI) in
Kubelet und
shareProcessNamespace (die Funktion ist standardmäßig aktiviert) auf den Status einer Beta-Version angewachsen.
Netzwerke
Die Hauptnachricht im Netzwerkteil von Kubernetes ist die
Alpha-Version der SCTP- Unterstützung (Stream Control Transmission Protocol). Dieses Telekommunikationsprotokoll wurde in den
Bereichen Pod ,
Service ,
Endpoint und
NetworkPolicy unterstützt und gehört nun zu TCP und UDP. Mit der neuen Funktion „Anwendungen, die SCTP als L4-Protokoll für ihre Schnittstellen benötigen, wird die Bereitstellung auf Kubernetes-Clustern einfacher. Beispielsweise können sie die auf
kube-dns basierende
Diensterkennung verwenden , und ihre Interaktion wird über
NetworkPolicy gesteuert. " Implementierungsdetails finden Sie in
diesem Dokument .
Zwei in K8s 1.8 eingeführte Netzwerkfunktionen haben ebenfalls einen stabilen Status erreicht:
Unterstützung für Richtlinien für ausgehenden
EgressRules Verkehr in der NetworkPolicy-API und
Anwendung von CIDR-
Regeln für Quelle / Ziel über
ipBlockRule .
Skalieren
Zu den Verbesserungen des Horizontal Pod Autoscaler gehören:
Die
vertikale Skalierung der Herde , bei der vor Erreichen der Beta-Version keine Benutzertests durchgeführt wurden, steht nicht still. Die Autoren hielten es für ausreichend für die Veröffentlichung von K8s 1.12 und
erinnern daran, dass diese Funktion eher eine Ergänzung zu Kubernetes ist (nicht im Kernel enthalten). Die gesamte Entwicklung wird in einem separaten Repository durchgeführt, in dem die Beta-Version zeitlich auf die Veröffentlichung von Kubernetes abgestimmt wird.
VPA-Workflow (Vertical Pod Autoscaler) für KubernetesSchließlich enthält K8s 1.12 (in Alpha-Form) die Ergebnisse der
Arbeiten zur "Vereinfachung der Installation mit
ComponentConfig " (als Teil des Sig-Cluster-Lebenszyklus), die seit fast zwei Jahren durchgeführt werden. Leider ist der Zugriff auf das
Dokument mit den
Entwurfsvorschlägen mit Details aus irgendeinem Grund (ein einfaches Versehen?) Für anonyme Benutzer gesperrt.
Andere Änderungen
API
In der API-Maschinengruppe sind zwei neue Funktionen implementiert:
dry-run für Apiserver (Alpha-Version), der die Validierung und Verarbeitung von Anforderungen imitiert;- Ressourcenkontingent-API (sofort Beta), die standardmäßig begrenzte Ressourcen definiert (anstelle des aktuellen Verhaltens, wenn der Ressourcenverbrauch unbegrenzt ist, wenn kein Kontingent festgelegt ist).
Azure
Für stabil erklärt:
Die ersten Implementierungen (Alpha-Versionen) werden hinzugefügt:
Kubectl
- Es wurde eine Alpha-Version des aktualisierten Plug-In-Mechanismus implementiert, mit der Sie neue Befehle hinzufügen oder vorhandene Unterbefehle einer beliebigen Verschachtelungsebene neu schreiben können. Es ähnelt Git und betrachtet ausführbare Dateien, die mit
kubectl- im $PATH des Benutzers beginnen. Weitere Einzelheiten finden Sie im Entwurfsvorschlag . - Eine Beta-Version der Idee, das
pkg/kubectl/genericclioptions von kubectl in ein unabhängiges Repository zu isolieren, wurde implementiert. - Die serverseitige Druckfunktion wurde für stabil erklärt.
Andere
- Die Alpha-Version des neuen TTL-After-Finish- Mechanismus, mit dem die Lebensdauer von Jobs und Pods begrenzt werden soll, deren Ausführung abgeschlossen ist, wird vorgestellt . Nach Ablauf der angegebenen TTL werden Objekte automatisch bereinigt, ohne dass ein Benutzereingriff erforderlich ist.
- Die Generierung eines privaten Schlüssels und eines CSR (TLS Bootstrap) zum Signieren eines Zertifikats auf Clusterebene in Kubelet wird als stabil deklariert.
- Die Rotation des Server-TLS-Zertifikats in Kubelet ging in den Beta-Status über.
PS
Lesen Sie auch in unserem Blog: