Kubernetes 1.12: ein Überblick über wichtige Neuerungen



    Heute ist der 27. September, was bedeutet, dass wir während der Arbeitszeit (in der US-Zeitzone) mit der nächsten Veröffentlichung von Kubernetes - 1.12 rechnen können (die offizielle Ankündigung ist jedoch manchmal verzögert). Im Allgemeinen ist es an der Zeit, die glorreiche Tradition fortzusetzen und über die wichtigsten Änderungen zu sprechen, die wir anhand der öffentlichen Informationen des Projekts vornehmen werden: Das Kubernetes verfügt über Tracking-Tabelle , CHANGELOG-1.12 , zahlreiche Probleme, Pull-Anfragen und Designvorschläge. Was ist neu in K8s 1.12?

    Lagerung


    Wenn Sie eine Sache herausgreifen, die am häufigsten unter allen Problemen im Zusammenhang mit der Veröffentlichung von Kubernetes 1.12 erwähnt wird, handelt es sich möglicherweise um das Container Storage Interface (CSI) , über das wir neulich bereits geschrieben haben . Beginnen wir daher mit den Änderungen in der Speicherunterstützung.

    Die CSI-Plugins als solche haben den Beta-Status beibehalten und warten darauf, von der nächsten Version von Kubernetes (1.13) als stabil erkannt zu werden. Was ist neu an der CSI-Unterstützung?

    Im Februar dieses Jahres wurde mit der Arbeit an dem Konzept der Topologie in der CSI-Spezifikation selbst begonnen.. Kurz gesagt handelt es sich bei der Topologie um Informationen zur Clustersegmentierung (z. B. durch "Racks" für lokale Installationen oder durch "Regionen" und "Zonen" für Cloud-Umgebungen), die Sie kennen und berücksichtigen müssen. Orchestrierungssysteme. Warum? Die von Speicheranbietern zugewiesenen Volumes sind nicht notwendigerweise im gesamten Cluster gleichermaßen zugänglich. Daher sind Kenntnisse der Topologie erforderlich, um Ressourcen effektiv zu planen und Entscheidungen zur Bereitstellung zu treffen.

    Die Folge der Entstehung von Topologien in der CSI ( aufgenommen in der Spezifikation vom 1. Juni) wurde die Unterstützung Kubernetes 1.12:


    Die CSI-bezogenen Updates enden jedoch nicht dort. Eine weitere wichtige Neuerung in der Veröffentlichung von Kubernetes 1.12 ist die Unterstützung von Snapshots für CSI ( derzeit im Alpha-Status). Snapshots für Volumes als solche sind in der Veröffentlichung von K8s 1.8 erschienen . Es wurde beschlossen, die Hauptimplementierung, die den Controller und den Provisioner (zwei separate Binärdateien) umfasst, in das externe Repository zu übertragen . Seitdem wurde Support für die Volumes GCE PD, AWS EBS, OpenStack Cinder, GlusterFS und Kubernetes veröffentlicht hostPath.

    Der neue Entwurfsvorschlag soll „diese Initiative fortsetzen, indem Unterstützung für CSI-Volume-Treiber hinzugefügt wird“ (die Unterstützung für Momentaufnahmen in der CSI-Spezifikation wird hier beschrieben). Da sich Kubernetes an das Prinzip hält, ein Minimum an Funktionen in die Core-API aufzunehmen, verwendet diese Implementierung (wie für Momentaufnahmen in Volume Snapshot Controller) CRD ( CustomResourceDefinitions).

    Und ein paar neue Funktionen für CSI-Treiber:

    • Die Alpha-Version der Fähigkeit des Treibers, sich bei der Kubernetes-API zu registrieren (um Benutzern das Auffinden der im Cluster installierten Treiber zu erleichtern und Treibern zu ermöglichen, die Interaktionsprozesse von Kubernetes mit ihnen zu beeinflussen);
    • Die Alpha-Version der Fähigkeit des Treibers , Informationen über die Datei zu erhalten , die den Datenträger angefordert hat NodePublish.

    In der letzten Version von Kubernetes vorgestellt, entwickelte sich der Mechanismus der dynamischen Begrenzung von Volumes auf Knoten von Alpha zu Beta, nachdem er ... Sie haben es erraten, Unterstützung für CSI sowie Azure.

    Schließlich wurde die Funktion zum Bereitstellen des Namespace-Ausbreitungsprozesses , mit der das Volume gemountet werden kann rshared(sodass alle gemounteten Containerverzeichnisse auf dem Host sichtbar sind) und der Beta-Status im Release von K8s 1.10 hatte , für stabil erklärt.

    Planer


    Im Kubernetes 1.12-Scheduler wird die Leistung durch eine Alpha-Version des Mechanismus zur Einschränkung der Suche in einem Cluster von Knoten verbessert , der für eine durchführbare Planung geeignet ist . Wenn früher für jeden Versuch, jeden Sub-Cube-Scheduler einzuplanenüberprüfte die Verfügbarkeit aller Knoten und übergab sie zur Auswertung, dann findet der Scheduler nur eine bestimmte Anzahl von Knoten und stoppt dann die Arbeit. In diesem Fall 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 über die Implementierung dieses Mechanismus wurde getroffen, basierend auf den Ergebnissen der Analyse der Daten zur Leistung des Schedulers (wenn das 90. Perzentil für den Herd 30 ms zeigte, war das 99. Mal bereits 60 ms).

    Darüber hinaus sind die folgenden Scheduler-Funktionen zur Beta-Version gereift:

    • Knoten durch Bedingung , der in K8s 1.8 angezeigt wurde, ermöglicht das Markieren eines Knotens mit einem bestimmten Status (für weitere Aktionen) beim Auftreten bestimmter Ereignisse: Jetzt erstellt der Lebenszyklus-Controller des Knotens automatisch Taints, und der Scheduler prüft sie (anstelle von Bedingungen ).
    • Planen Schoten in DaemonSetVerwendung kube-Scheduler (statt Controller DaemonSet): es wird auch standardmäßig aktiv gemacht;
    • Angabe der Prioritätsklasse in ResourceQuota.

    Clusterknoten


    Eine interessante Innovation war das Aufkommen (im Status der Alpha-Version) RuntimeClass- eine neue Ressource auf Clusterebene, die die Parameter der Container- Ausführungszeit (Containerlaufzeit) bereitstellt . RuntimeClassesSie werden den Subs über das gleichnamige Feld zugewiesen PodSpecund implementieren Unterstützung für die Verwendung mehrerer ausführbarer Medien in einem Cluster oder Knoten. Warum?

    „Das Interesse an unterschiedlichen ausführbaren Umgebungen in einem Cluster wächst. Momentan sind hier vor allem Sandboxen (Sandboxen) und der Wunsch von Kata- und gVisor-Containern mit Kubernetes zu integrieren. In Zukunft werden auch andere Laufzeitmodelle wie Windows-Container oder sogar entfernte ausführbare Umgebungen Unterstützung benötigen. RuntimeClass bietet die Möglichkeit, zwischen verschiedenen ausführbaren Umgebungen zu wählen, die in einem Cluster konfiguriert sind, und deren Eigenschaften zu ändern (sowohl vom Cluster als auch vom Benutzer). "

    Um zwischen den vordefinierten Konfigurationen im CRI (Container Runtime Interface) zu wählen RuntimeHandler, wird die aktuelle Annotation der Einreichung ersetzt:



    Eine Konfiguration im containered für Kata-Laufzeit sieht folgendermaßen aus:

    [plugins.cri.containerd.kata-runtime]
        runtime_type = "io.containerd.runtime.v1.linux"
        runtime_engine = "/opt/kata/bin/kata-runtime"
        runtime_root = ""

    Das Kriterium RuntimeClassfür die Alpha-Version ist ein erfolgreicher CRI-Validierungstest .

    Zusätzlich zu dem Status der Beta auf einen Mechanismus lokale Plug-In aufnehmen (einschließlich CSI) in Kubelet und shareProcessNamespace(ein Feature wurde standardmäßig aktiviert).

    Netzwerk


    Die Hauptnachrichten im Netzwerkteil von Kubernetes ist die Alpha-Version der SCTP- Unterstützung (Stream Control Transmission Protocol). Mit Unterstützung von Pod , Service , Endpoint und NetworkPolicy wurde dieses Telekommunikationsprotokoll um TCP und UDP erweitert. Mit der neuen Funktion können Anwendungen, die SCTP als L4-Protokoll für ihre Schnittstellen benötigen, einfacher in Kubernetes-Clustern bereitgestellt werden. So können sie beispielsweise Service Discovery basierend auf kube-dns verwenden , und ihre Interaktion wird über NetworkPolicy gesteuert . “ Details zur Implementierung finden Sie in diesem Dokument .

    Zwei Netzwerkfunktionen, die in K8s 1.8 vorgestellt wurden, erreichten ebenfalls einen stabilen Status: Unterstützung für Richtlinien für ausgehenden Datenverkehr EgressRulesin der NetworkPolicy-API und durch Anwenden von Quell- / Empfänger-CIDR- RegelnipBlockRule .

    Skalieren


    Zu den Verbesserungen des Horizontal Pod Autoscaler gehören:


    Die vertikale Skalierung der Herde ist ebenfalls nicht vorhanden , die bis zur Beta-Version nicht durch Benutzer getestet wurde. Die Autoren fanden es ausreichend für die Veröffentlichung von K8s 1.12 und erinnern daran, dass diese Möglichkeit eher eine Ergänzung zu Kubernetes ist (nicht im Kern des Systems enthalten). Alle Entwicklungen werden in einem separaten Repository durchgeführt, einer Betaversion, in der die Veröffentlichung von Kubernetes erfolgen wird.


    VPA-Workflow (Vertical Pod Autoscaler) in Kubernetes

    Abschließend enthält K8s 1.12 (in der Alpha-Version) die Ergebnisse der Arbeiten zur „Vereinfachung der Installation mit Hilfe ComponentConfig“ (innerhalb des Sig-Cluster-Lebenszyklus), die seit fast zwei Jahren andauern . Leider aus einem unbekannten Grund (einfaches Versehen?), Zugang zum Designvorschlag mit Details für anonyme Benutzer geschlossen.

    Andere Änderungen


    API


    In der api-machinery-Gruppe sind zwei neue Funktionen implementiert:

    • параметр dry-run für Apiserver (Alpha-Version), der Validierung und Abfrageverarbeitung simuliert;
    • Ressourcenkontingent-API (sofort Betaversion), die standardmäßig begrenzte Ressourcen definiert (anstelle des aktuellen Verhaltens, wenn der Ressourcenverbrauch nicht begrenzt ist, wenn keine Quote festgelegt ist).

    Azure


    Für stabil erklärt:


    Erste Implementierungen (Alpha-Versionen) hinzugefügt:


    Kubectl


    • Die Alpha-Version des aktualisierten Plugin-Mechanismus ist implementiert , der das Hinzufügen neuer Befehle und das Überschreiben vorhandener Unterbefehle jeder Schachtelungsebene ermöglicht. Es ist ähnlich wie Git gestaltet und betrachtet ausführbare Dateien, die mit kubectl-dem $PATHBenutzer beginnen. Einzelheiten finden Sie im Entwurfsvorschlag .
    • Eine Beta-Version der Idee, ein Paket pkg/kubectl/genericclioptionsaus kubectl in ein unabhängiges Repository zu extrahieren, wurde implementiert.
    • Erklärte stabile Funktion Ausgang auf der Serverseite (serverseitiger Druck) .

    Andere


    • Eine Alpha-Version des neuen TTL- Mechanismus nach Fertigstellung, die die Lebensdauer von Jobs und Pods begrenzt, wird vorgestellt . Nach einer angegebenen TTL werden die Objekte automatisch ohne Benutzereingriff gereinigt.
    • Der private Kubelet- Schlüssel und die CSR (TLS-Bootstrap) wurden für die Signatur eines Zertifikats auf Clusterebene als stabil deklariert .
    • In den Status einer Beta-Version der Rotation des Server-TLS-Zertifikats in Kubelet übergeben .

    PS


    Lesen Sie auch in unserem Blog:


    Jetzt auch beliebt: