Heute, am Mittwoch, findet die nächste Veröffentlichung von Kubernetes
statt - 1.16. Nach der Tradition, die sich für unseren Blog zum zehnten Jahrestag 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.16 und verwandten Problemen, Pull-Anforderungen sowie Kubernetes-Verbesserungsvorschlägen (KEP). Also lass uns gehen! ..
Knoten
Eine wirklich große Anzahl bemerkenswerter Innovationen (im Alpha-Versionsstatus) wird auf der Seite der Knoten von K8s-Clustern (Kubelet) präsentiert.
Zunächst werden die sogenannten
" Ephemeral Container " (Ephemeral Containers) vorgestellt
, die den Debugging-Prozess in Pods vereinfachen sollen . Mit dem neuen Mechanismus können Sie spezielle Container ausführen, die im Namespace vorhandener Pods beginnen und für kurze Zeit leben. Ihr Zweck ist die Interaktion mit anderen Pods und Containern, um Probleme und Fehlerbehebungen zu lösen. Für diese Funktion wird ein neuer
kubectl debug Befehl
kubectl debug , der im Wesentlichen
kubectl exec : Nur anstatt den Prozess im Container zu
kubectl exec (wie im Fall von
exec ), wird der Container im Pod
kubectl exec . Ein solcher Befehl verbindet beispielsweise einen neuen Container mit dem Pod:
kubectl debug -c debug-shell --image=debian target-pod -- bash
Details zu kurzlebigen Behältern (und Beispiele für deren Verwendung) finden Sie im
entsprechenden KEP . Die aktuelle Implementierung (in K8s 1.16) ist die Alpha-Version. Zu den Kriterien für die Übertragung auf die Beta-Version gehört das Testen der Ephemeral Containers-API auf mindestens zwei Releases [Kubernetes].
NB : Im Wesentlichen ähnelt sogar der Name des Features dem bereits vorhandenen kubectl-debug- Plugin, über das wir bereits geschrieben haben . Es wird davon ausgegangen, dass mit dem Aufkommen kurzlebiger Container die Entwicklung eines separaten externen Plug-Ins aufhören wird.Eine weitere Innovation,
PodOverhead bietet einen
Mechanismus zur Berechnung der Gemeinkosten für Pods , die je nach verwendeter Laufzeit stark variieren können. Als Beispiel zitieren die Autoren
dieses KEP Kata-Container, für die der Gastkernel, der Kata-Agent, das Init-System usw. gestartet werden müssen. Wenn der Overhead so groß wird, kann er nicht ignoriert werden. Dies bedeutet, dass ein Weg erforderlich ist, um ihn für weitere Quoten, Planungen usw. zu berücksichtigen. Um dies zu implementieren, wurde
PodSpec Feld
Overhead *ResourceList hinzugefügt (verglichen mit Daten in der
RuntimeClass , falls eine verwendet wird).
Eine weitere bemerkenswerte Neuerung ist der
Node Topology Manager , mit dem der Ansatz zur Feinabstimmung der Zuweisung von Hardwareressourcen für verschiedene Komponenten in Kubernetes vereinheitlicht werden soll. Diese Initiative wird durch die wachsende Nachfrage verschiedener moderner Systeme (aus den Bereichen Telekommunikation, maschinelles Lernen, Finanzdienstleistungen usw.) nach Hochleistungs-Parallelcomputern und zur Minimierung von Verzögerungen bei der Ausführung von Vorgängen verursacht, für die sie die erweiterten Funktionen der CPU- und Hardwarebeschleunigung nutzen. Solche Optimierungen in Kubernetes wurden bisher dank unterschiedlicher Komponenten (CPU-Manager, Geräte-Manager, CNI) erzielt. Jetzt werden sie eine einzige interne Schnittstelle hinzufügen, die den Ansatz vereinheitlicht und die Verbindung neuer ähnlicher - der sogenannten topologiebewussten - Komponenten auf der Kubelet-Seite vereinfacht. Details finden Sie im
entsprechenden KEP .
Komponentendiagramm des Topologie-ManagersDie nächste Funktion ist das
Überprüfen von Containern während des Startvorgangs ( Startsonde ) . Wie Sie wissen, ist es für Container, die lange laufen, schwierig, den aktuellen Status zu erhalten: Sie werden entweder vor dem eigentlichen Betriebsstart "getötet" oder sie geraten für lange Zeit in einen Deadlock. Eine neue Prüfung (aktiviert über das Feature-Gate
StartupProbeEnabled )
StartupProbeEnabled die Aktion anderer Prüfungen ab - oder
StartupProbeEnabled vielmehr, bis der Start des Pods abgeschlossen ist. Aus diesem Grund wurde die Funktion ursprünglich als
Pod-Startup-Liveness-Probe-Holdoff bezeichnet . Bei Pods, deren Start lange dauert, können Sie den Status in relativ kurzen Zeitintervallen abfragen.
Darüber hinaus wird sofort im Beta-Status eine Verbesserung für RuntimeClass hinzugefügt, die Unterstützung für „heterogene Cluster“ hinzufügt. Mit
RuntimeClass Scheduling muss jetzt nicht mehr jeder Knoten für jede RuntimeClass unterstützt werden: Für Pods können Sie RuntimeClass auswählen, ohne über die Clustertopologie nachzudenken. Um dies zu erreichen, mussten Pods NodeSelector und Toleranzen entsprechende Regeln zuweisen, damit Pods auf Knoten mit Unterstützung für alles, was sie benötigen, angezeigt werden.
KEP spricht über Anwendungsbeispiele und natürlich über Implementierungsdetails.
Netzwerk
Zwei wichtige Netzwerkfunktionen, die erstmals (in der Alpha-Version) in Kubernetes 1.16 verfügbar waren, sind:
- Unterstützung für einen dualen Netzwerkstapel - IPv4 / IPv6 - und das entsprechende "Verständnis" auf der Ebene von Pods, Knoten und Diensten. Es umfasst die Interaktion von IPv4-zu-IPv4 und IPv6-zu-IPv6 zwischen Pods, von Pods zu externen Diensten, Referenzimplementierungen (im Rahmen von Bridge CNI-, PTP CNI- und Host-Local IPAM-Plug-Ins) sowie umgekehrt Kompatibel mit Kubernetes-Clustern, die nur über IPv4 oder IPv6 funktionieren. Implementierungsdetails finden Sie in KEP .
Ein Beispiel für die Ausgabe von zwei Arten von IP-Adressen (IPv4 und IPv6) in der Liste der Pods:
kube-master
- Die neue API für Endpoint ist die EndpointSlice-API . Es löst die Probleme der vorhandenen Endpoint-API mit Leistung / Skalierbarkeit, die verschiedene Komponenten in der Steuerebene betreffen (Apiserver usw., Endpoints-Controller, Kube-Proxy). Die neue API wird der Discovery-API-Gruppe hinzugefügt und kann Zehntausende von Backend-Endpunkten für jeden Dienst in einem Cluster aus tausend Knoten bereitstellen. Zu diesem Zweck wird jeder Dienst N
EndpointSlice Objekten zugeordnet, von denen jedes standardmäßig nicht mehr als 100 Endpunkte hat (der Wert ist konfigurierbar). Die EndpointSlice-API bietet auch Möglichkeiten für ihre zukünftige Entwicklung: Unterstützung für viele IP-Adressen für jeden Pod, neue NotReady für Endpunkte (nicht nur Ready und NotReady ), dynamische Teilmenge für Endpunkte.
Der in der letzten Version mit dem Namen
service.kubernetes.io/load-balancer-cleanup und an jeden Dienst mit dem Typ
LoadBalancer angehängte
LoadBalancer auf die Beta-Version erweitert. Zum Zeitpunkt des Entfernens eines solchen Dienstes wird das tatsächliche Löschen der Ressource verhindert, bis die "Bereinigung" aller entsprechenden Ressourcen des Balancers abgeschlossen ist.
API-Maschinen
Der eigentliche "Stabilisierungsmeilenstein" ist im Bereich des Kubernetes-API-Servers und der Interaktion mit diesem festgelegt. In vielerlei Hinsicht geschah dies aufgrund der
Übertragung auf den stabilen Status von CustomResourceDefinitions (CRD) , für
die keine spezielle Präsentation erforderlich war , die seit dem entfernten Kubernetes 1.7 (und dies ist Juni 2017!) Den Beta-Status hatte. Die gleiche Stabilisierung ergab sich für die damit verbundenen Merkmale:
- "Subresources" mit
/status und /scale für CustomResources; - Versionskonvertierung für CRD basierend auf einem externen Webhook;
- kürzlich eingeführte (in K8s 1.15) Standardwerte ( Standard ) und automatisches Löschen von Feldern ( Bereinigen ) für CustomResources;
- die Möglichkeit , das OpenAPI v3-Schema zum Erstellen und Veröffentlichen von OpenAPI-Dokumentationen zu verwenden, die zum Überprüfen von CRD-Ressourcen auf der Serverseite verwendet werden.
Ein weiterer Mechanismus, der Kubernetes-Administratoren seit langem bekannt ist:
Admission Webhook - befindet sich ebenfalls seit langer Zeit (seit K8s 1.9) im Beta-Status und wurde nun für stabil erklärt.
Zwei weitere Funktionen haben die Beta erreicht:
serverseitiges Anwenden und
Überwachen von Lesezeichen .
Die einzige wesentliche Neuerung in der Alpha-Version war die
Ablehnung von SelfLink - einer speziellen URI, die das angegebene Objekt darstellt und Teil von
ObjectMeta und
ListMeta (d. H. Teil eines beliebigen Objekts in Kubernetes). Warum es ablehnen? Die „einfache“ Motivation
klingt nach dem Fehlen realer (unüberwindbarer) Gründe für das Fortbestehen dieses Feldes. Formalere Gründe sind die Optimierung der Leistung (Entfernen eines unnötigen Felds) und die Vereinfachung der Arbeit von generic-apiserver, das gezwungen ist, ein solches Feld auf besondere Weise zu verarbeiten (dies ist das einzige Feld, das unmittelbar vor der Serialisierung des Objekts festgelegt wird). Die eigentliche "Veralterung" (in der Beta-Version) von
SelfLink wird mit Kubernetes Version 1.20 und der letzten Version - 1.21 geschehen.
Datenspeicherung
Die Hauptarbeit im Bereich der Speicherung wird wie in früheren Versionen im Bereich der
Unterstützung für CSI beobachtet . Die wichtigsten Änderungen hier sind:
- Zum ersten Mal (in der Alpha-Version) wurde die Unterstützung für CSI-Plug-Ins für Windows-Arbeitsknoten angezeigt : Die derzeitige Methode zur Arbeit mit Repositorys ersetzt die In-Tree-Plug-Ins im Kubernetes-Kern und die Powershell-basierten FlexVolume-Plug-Ins von Microsoft.
Implementierungsschema für das Windows CSI-Plugin von Kubernetes
- Die in K8s 1.12 eingeführte Möglichkeit , die Größe von CSI-Volumes zu ändern , ist auf eine Beta-Version angewachsen.
- Die Möglichkeit, mit CSI lokale kurzlebige Volumes zu erstellen ( CSI Inline Volume Support ), hat einen ähnlichen „Anstieg“ erreicht (von Alpha auf Beta).
Die
Funktion zum Klonen von Volumes, die in der vorherigen Version von Kubernetes (Verwendung vorhandener PVCs als
DataSource zum Erstellen neuer PVCs) angezeigt wurde, hat jetzt auch den Beta-Status erhalten.
Planer
Zwei bemerkenswerte Änderungen in der Planung (beide in der Alpha-Version):
EvenPodsSpreading ist die Fähigkeit, EvenPodsSpreading zu verwenden, um Lasten anstelle von logischen Anwendungseinheiten (wie Deployment und ReplicaSet) "fair zu verteilen" und diese Verteilung anzupassen (als strenge Anforderung oder als milde Bedingung, d. H. Priorität). Die Funktion erweitert die vorhandenen Verteilungsfunktionen geplanter Pods, die jetzt durch die PodAntiAffinity PodAffinity und PodAntiAffinity , und gibt Administratoren mehr Kontrolle über dieses Problem, was eine bessere Zugänglichkeit und einen optimierten Ressourcenverbrauch bedeutet. Details finden Sie im KEP .- Verwenden der BestFit-Richtlinie in der Prioritätsfunktion RequestedToCapacityRatio während der Pod-Planung, mit der das Packen von Behältern („Packen in Containern“) sowohl für Kernressourcen (Prozessor, Speicher) als auch für erweiterte Ressourcen (wie GPU) verwendet werden kann. Weitere Informationen finden Sie unter KEP .
Pod-Planung: Bevor Sie die Best-Fit-Richtlinie verwenden (direkt über den Standardplaner) und sie verwenden (über den Scheduler-Extender).
Darüber hinaus wird
die Möglichkeit
geboten , eigene Plugins für den Scheduler außerhalb des Hauptentwicklungsbaums von Kubernetes (außerhalb des Baums) zu erstellen.
Andere Änderungen
Auch in der Version 1.16 von Kubernetes kann eine
Initiative erwähnt werden, um vorhandene Metriken in voller Reihenfolge oder genauer in Übereinstimmung mit den
offiziellen Instrumentierungsanforderungen von K8 zu bringen. Sie stützen sich grundsätzlich auf die einschlägige
Prometheus-Dokumentation . Die Inkonsistenzen wurden aus verschiedenen Gründen gebildet (zum Beispiel wurden einige Metriken einfach erstellt, bevor die aktuellen Anweisungen erschienen), und die Entwickler entschieden, dass es Zeit war, alles auf einen einzigen Standard zu bringen, "im Einklang mit dem Rest des Prometheus-Ökosystems". Die aktuelle Implementierung dieser Initiative hat den Status der Alpha-Version, die in zukünftigen Versionen von Kubernetes schrittweise auf Beta (1.17) und Stable (1.18) ansteigen wird.
Darüber hinaus können folgende Änderungen festgestellt werden:
- Entwicklung der Windows-Unterstützung mit dem Aufkommen des Kubeadm-Dienstprogramms für dieses Betriebssystem (Alpha-Version), der Möglichkeit von
RunAsUserName für Windows-Container (Alpha-Version), Verbesserung der Unterstützung für Group Managed Service Account (gMSA) auf Beta-Version, Mount / Attach- Unterstützung für vSphere-Volumes. - Überarbeiteter Datenkomprimierungsmechanismus in API-Antworten . Zuvor wurde für diese Zwecke ein HTTP-Filter verwendet, der eine Reihe von Einschränkungen auferlegte, die dessen Aufnahme standardmäßig verhinderten. Jetzt funktioniert die "transparente Komprimierung von Anforderungen": Clients, die
Accept-Encoding: gzip im Header senden, erhalten eine komprimierte Antwort in GZIP, wenn ihre Größe 128 KB überschreitet. Clients on Go unterstützen automatisch die Komprimierung (senden Sie den gewünschten Header), sodass sie sofort einen Rückgang des Datenverkehrs bemerken. (Für andere Sprachen sind möglicherweise geringfügige Änderungen erforderlich.) - Es wurde möglich, HPA basierend auf externen Metriken von / auf Null zu skalieren . Wenn die Skalierung auf Objekten / externen Metriken basiert, können Sie bei Leerlauf der Workloads automatisch auf 0 Replikate skalieren, um Ressourcen zu sparen. Diese Funktion sollte besonders nützlich sein, wenn Mitarbeiter GPU-Ressourcen anfordern und die Anzahl der verschiedenen Arten von nicht aktiven Mitarbeitern die Anzahl der verfügbaren GPUs überschreitet.
- Ein neuer Client -
k8s.io/client-go/metadata.Client - für den "allgemeinen" Zugriff auf Objekte. Es wurde entwickelt, um auf einfache Weise Metadaten (d. H. Den metadata Unterabschnitt) aus Clusterressourcen abzurufen und Operationen mit diesen aus der Kategorie der Speicherbereinigung und der Kontingente auszuführen. - Kubernetes können jetzt ohne veraltete Cloud-Anbieter (Alpha-Version) erstellt werden.
- Das Dienstprogramm kubeadm wurde
join die experimentelle Möglichkeit (Alpha-Version) erweitert, Patches während Init-, Join- und upgrade Vorgängen anzupassen. Einzelheiten zur Verwendung des --experimental-kustomize finden Sie unter KEP . - Der neue Endpunkt für Apiserver ist
readyz , mit dem Sie Bereitschaftsinformationen exportieren können. Der API-Server verfügt außerdem über das Flag --maximum-startup-sequence-duration , mit dem Sie die Neustarts anpassen können. - Zwei Funktionen für Azure werden als stabil deklariert: Unterstützung für Verfügbarkeitszonen und RG ( Cross Resource Group ). Darüber hinaus hat Azure Folgendes hinzugefügt:
- AWS unterstützt EBS unter Windows und optimierte EC2-API-Aufrufe von
DescribeInstances . - Kubeadm migriert jetzt seine CoreDNS-Konfiguration beim Upgrade auf CoreDNS selbstständig.
- Die Binärdateien usw. im entsprechenden Docker-Image sind weltweit ausführbar, sodass Sie dieses Image ausführen können, ohne Root-Rechte zu benötigen. Darüber hinaus hat das etcd-Migrationsimage die Unterstützung für die etcd2-Version eingestellt.
- Cluster Autoscaler 1.16.0 hat auf die Verwendung von Distroless als Basisimage umgestellt, die Leistung verbessert und neue Cloud-Anbieter (DigitalOcean, Magnum, Packet) hinzugefügt.
- Aktualisierungen in der verwendeten / abhängigen Software: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.
PS
Lesen Sie auch in unserem Blog: