Kubernetes 1.18: Überblick über wichtige Innovationen

Gestern, 25. März, die nächste Veröffentlichung von Kubernetes - 1.18. Gemäß der Tradition für unseren Blog sprechen wir über die wichtigsten Änderungen in der neuen Version.



Die zur Vorbereitung dieses Materials verwendeten Informationen stammen aus der offiziellen Ankündigung, der Kubernetes-Erweiterungsverfolgungstabelle , CHANGELOG-1.18 , Bewertungen von SUSE und Sysdig sowie verwandten Themen, Pull-Anfragen, Kubernetes-Verbesserungsvorschlägen (KEP) ...

Die Version 1.18 von Kubernetes erhielt ihr offizielles Logo, dessen Kern darin besteht, das Projekt mit dem Large Hadron Collider zu vergleichen. Wie der LHC, der das Ergebnis der Arbeit von Tausenden von Wissenschaftlern aus der ganzen Welt war, brachte Kubernetes Tausende von Entwicklern aus Hunderten von Organisationen zusammen, und alle arbeiten an einer gemeinsamen Sache: "Verbesserung des Cloud Computing in allen Aspekten".



In der Zwischenzeit haben Enthusiasten des SUSE-Teams eine Wortwolke basierend auf Versionshinweisen für die 3412 Commits für K8s 1.18 erstellt. Und es stellte sich so heraus:



Nun - über das, was hinter diesen Worten steckt, in einer für die Benutzer verständlicheren Form.

Planer


Die Hauptinnovation hier ist das Profilieren der Planung (Planen der Profile) . Dies hängt damit zusammen, dass je heterogener die Workloads im Cluster werden, desto eher unterschiedliche Planungsansätze erforderlich sind.

Um dieses Problem zu lösen, schlagen die Autoren vor, dass der Scheduler verschiedene Konfigurationen verwendet, die dem Scheduler zugewiesen sind und Profile genannt werden. Ab dem Start scannt kube-scheduler alle verfügbaren Profile und speichert sie in der Registrierung. Wenn die Konfiguration keine Profile enthält, ist die Standardoption ( default-scheduler) ausgewählt . Nachdem sich die Pods in der Warteschlange befinden, führt der Kube-Scheduler seine Planung unter Berücksichtigung des ausgewählten Schedulers durch.

Sami Politikplanung basiert auf einem Prädikat ( PodFitsResources, PodMatchNodeSelector,PodToleratesNodeTaintsetc.) und Prioritäten ( SelectorSpreadPriority, InterPodAffinityPriority, MostRequestedPriority, EvenPodsSpreadPriorityusw.). Die Implementierung bietet sofort ein System von Plugins, sodass alle Profile über ein spezielles Framework hinzugefügt werden.

Aktuelle Konfigurationsstruktur (wird in Kürze geändert):

type KubeSchedulerConfiguration struct {
   ...
   SchedulerName string
   AlgorithmSource SchedulerAlgorithmSource
   HardPodAffinitySymmetricWeight
   Plugins *Plugins
   PluginConfig []PluginConfig
   ...
}

... und ein Beispielsetup:

profiles:
  - schedulerName: 'default-scheduler'
    pluginConfig:
      - name: 'InterPodAffinity'
      - args:
          hadPodAffinityWeight: <value>

Bis zur nächsten Version von K8 wird das Feature voraussichtlich in die Beta-Version und nach zwei weiteren Stabilisierungen übersetzt. Weitere Informationen zu Profilen für den Scheduler finden Sie im entsprechenden KEP .

Eine weitere Neuerung, die im Alpha-Versionsstatus angezeigt wurde, ist die Standardregel für die gleichmäßige Verteilung von Pods (Even Pod Spreading) . Derzeit werden Regeln in PodSpecPods definiert und an diese angehängt. Jetzt ist es möglich, die globale Konfiguration auf Clusterebene festzulegen . Details finden Sie in KEP .

Gleichzeitig wurde das Pod Topology Spread- Feature selbst (sein Feature Gate - EvenPodsSpread), mit dem Pods gleichmäßig auf einen Mehrzonencluster verteilt werden können, in den Beta-Status übersetzt.

Darüber hinaus wurde die Stabilisierung der Taint Based Eviction angekündigt , um Knoten unter bestimmten Bedingungen Taints hinzuzufügen. Zum ersten Mal erschien das Feature in der bereits entfernten Version von K8s 1.8 und erhielt in 1.13 den Beta-Status .

Benutzerdefinierte HPA-Skalierungsgeschwindigkeit


Seit mehr als einem Jahr ist ein interessantes Merkmal, das als konfigurierbare Skalengeschwindigkeit für HPA bezeichnet wird, im Kubernetes-Verbesserungsofen , d. H. anpassbare horizontale Zoomgeschwindigkeit. ( Unser Landsmann hat übrigens mit der Entwicklung begonnen .) In der neuen Version wurde es in die erste Phase des Masseneinsatzes gebracht - es wurde in der Alpha-Version verfügbar.

Wie Sie wissen, skaliert Horizontal Pod Autoscaler (HPA) in Kubernetes die Anzahl der Pods für jede Ressource, die eine Unterressource unterstütztscalebasierend auf dem CPU-Verbrauch oder anderen Metriken. Mit einer neuen Funktion können Sie die Geschwindigkeit steuern, mit der diese Skalierung in beide Richtungen erfolgt. Bisher war es möglich, es in sehr begrenztem Umfang zu regulieren (siehe zum Beispiel den Parameter global für den Cluster --horizontal-pod-autoscaler-downscale-stabilization-window).

Die Hauptmotivation für die Einführung einer benutzerdefinierten Skalierungsgeschwindigkeit ist die Möglichkeit, die Cluster-Workloads nach ihrer geschäftlichen Bedeutung zu trennen, sodass eine Anwendung (die den kritischsten Datenverkehr verarbeitet) eine maximale Erhöhung der Größe und eine niedrige Rollup-Geschwindigkeit (da ein neuer Laststoß auftreten kann) ermöglicht. und für andere - nach anderen Kriterien skalieren (um Geld zu sparen usw.).

Vorgeschlagene Lösung - Objekt für HPA-Konfigurationen hinzugefügtbehaviorDamit können Sie Regeln für die Steuerung der Skalierung in beide Richtungen ( scaleUpund scaleDown) definieren. Zum Beispiel die Konfiguration:

behavior:
  scaleUp:
    policies:
    - type: percent
      value: 900%

... wird dazu führen, dass die Anzahl der derzeit laufenden Pods um 900% zunimmt. Das heißt, wenn die Anwendung als einzelner Pod gestartet wird und skaliert werden muss, wächst sie als 1 → 10 → 100 → 1000.

Weitere Beispiele und Implementierungsdetails finden Sie unter KEP .

Knoten


Fortschritte bei der Unterstützung von Riesenseiten ( Gesamt-KEP für Datenblätter ): Die Alpha-Version hat die Unterstützung für diese Seiten auf Containerebene und die Möglichkeit implementiert , Seiten unterschiedlicher Größe anzufordern.

Der Topologie-Manager-Knoten ( der Knoten, der Topologie-Manager ) soll den Ansatz zur Feinabstimmung der Zuordnung von Hardwareressourcen zu verschiedenen Komponenten in Kubernetes vereinheitlichen und in den Beta-Status übertragen.

Der Status der Beta-Version, um eine Vorstellung von einem Feature K8s 1.16 PodOverhead zu bekommen , dem vorgeschlagenen Mechanismus zur Berechnung des Overheads pod'y.

kubectl


Eine Alpha-Version des Befehls kubectl debug ( sein KEP ) wurde hinzugefügt , die das Konzept der „ kurzlebigen Container “ entwickelte. Sie wurden erstmals in K8s 1.16 eingeführt, um das Debuggen in Pods zu vereinfachen. Zu diesem Zweck wird im rechten Pod ein temporärer (d. H. Für kurze Zeit lebender) Container gestartet, der die zum Debuggen erforderlichen Tools enthält. Wie wir bereits geschrieben haben, ist dieser Befehl im Wesentlichen identisch mit dem bisher existierenden kubectl-debug-Plug-In ( dessen Überprüfung ).

Job Illustration kubectl debug:

% kubectl help debug
Execute a container in a pod.

Examples:
  # Start an interactive debugging session with a debian image
  kubectl debug mypod --image=debian

  # Run a debugging session in the same namespace as target container 'myapp'
  # (Useful for debugging other containers when shareProcessNamespace is false)
  kubectl debug mypod --target=myapp

Options:
  -a, --attach=true: Automatically attach to container once created
  -c, --container='': Container name.
  -i, --stdin=true: Pass stdin to the container
  --image='': Required. Container image to use for debug container.
  --target='': Target processes in this container name.
  -t, --tty=true: Stdin is a TTY

Usage:
  kubectl debug (POD | TYPE/NAME) [-c CONTAINER] [flags] -- COMMAND [args...] [options]

Use "kubectl options" for a list of global command-line options (applies to all commands).

Ein anderes Team, kubectl diff , das erstmals in K8s 1.9 erschien und einen Beta-Status von 1.13 erhielt, wird schließlich für stabil erklärt . Wie der Name schon sagt, können Sie Cluster-Konfigurationen vergleichen. Anlässlich der Stabilisierungsfunktionen erschien sie als KEP und wurde mit allen relevanten Dokumentationen der Kubernetes-Site aktualisiert .

Darüber hinaus ist die Flagge kubectl --dry geführte hinzugefügt Unterstützung für verschiedene Werte von ( client, server, none), mit dem Sie den Befehl nur auf der Client - Seite oder Server ausführen kann versuchen. Für die Implementierung auf der Serverseite wurde die Unterstützung für große Teams implementiert, darunter create:apply, patchUnd andere.

Netzwerke


Die Ingress-Ressource wurde von der aktuellen API ( extensions.v1beta1) -Gruppe nach verschoben networking.v1beta1, gefolgt von einer Stabilisierung in der Ansicht v1. Hierfür ist eine Reihe von Änderungen ( KEP ) geplant . Im Moment - als Teil der Beta-Version in K8s 1.18 - hat Ingress zwei bedeutende Neuerungen erhalten :

  • ein neues Feld , pathTypedas Sie bestimmen können , wird durch das, was Prinzip der Pfad verglichen werden ( Exact, Prefixoder ImplementationSpecific, wird bestimmt , in das letzte Verhalten IngressClass);
  • Eine neue Ressource IngressClassund ein neues (unveränderliches) Feld Classin der Definition IngressSpec, das angibt, welcher Controller die Ingress-Ressource implementiert. Diese Änderungen ersetzen die Anmerkung kubernetes.io/ingress.class, deren Verwendung nicht mehr unterstützt wird.

Für viele Netzwerkfunktionen wurde der Verfügbarkeitsstatus erhöht:

  • Das NodeLocal DNS Cache- Plugin ist stabil geworden , wodurch die DNS-Leistung durch die Verwendung eines Agenten für den DNS-Cache auf Clusterknoten verbessert wird.
  • stabil und deklariert ein Feld AppProtocol, das das Anwendungsprotokoll für jeden Service-Port (Ressourcen ServicePortund EndpointPort) definiert;
  • Die IPv6-Unterstützung wird als stabil genug erkannt, um sie in eine Beta-Version zu übersetzen.
  • Standardmäßig ist die EndpointSlices-API jetzt aktiviert (als Teil der Beta-Version) und fungiert als skalierbarer und erweiterbarer Ersatz für die üblichen Endpunkte.

Lagerhäuser


Die Alpha-Version bietet die Grundlage für die Erstellung von Volumes mit vorinstallierten Daten - Generic Data Populators ( KEP ). Als Implementierung wird vorgeschlagen, die Feldvalidierung zu schwächen, DataSourcedamit Objekte beliebigen Typs Datenquellen sein können.

Vor dem Binden des Volumes in den Container werden die Rechte an allen Dateien entsprechend dem Wert geändert fsGroup. Dieser Vorgang kann die Arbeit einiger Anwendungen (z. B. gängiger DBMS) unterbrechen und auch viel Zeit in Anspruch nehmen (bei großen Volumes - mehr als 1 TB). Mit dem neuen FeldPermissionChangePolicy für PersistentVolumeClaimVolumeSource können Sie festlegen, ob Sie den Eigentümer für den Inhalt des Volumes ändern möchten. Die aktuelle Implementierung ist eine Alpha-Version, Details finden Sie inKEP .

Für Objekte Secretswurde ConfigMaps ein neues Feld immutablehinzugefügt , das sie unveränderlich macht. In der Regel werden diese Objekte in Pods als Dateien verwendet. Alle Änderungen an diesen Dateien schnell (nach etwa einer Minute) gelten für alle Pods, die die Dateien bereitgestellt haben. Daher kann eine erfolglose Aktualisierung eines Geheimnisses oder einer ConfigMap zum Ausfall der gesamten Anwendung führen.

Die Autoren der Funktion geben an, dass selbst bei der Aktualisierung der Anwendungen mit der empfohlenen Methode - durch fortlaufende Upgrades - Fehler auftreten können, die durch erfolglose Aktualisierungen vorhandener Geheimnisse / ConfigMaps verursacht werden. Darüber hinaus ist das Aktualisieren dieser Objekte in laufenden Pods hinsichtlich Leistung und Skalierbarkeit kompliziert (jedes Kubelet ist gezwungen, jedes einzelne Geheimnis / CM ständig zu überwachen).

In der aktuellen Implementierung wird festgelegt, dass diese Änderung nicht zurückgesetzt werden kann, nachdem die Ressource als unveränderlich markiert wurde. Sie müssen nicht nur das Objekt löschen und erneut erstellen, sondern auch Pods neu erstellen, die das Remote-Geheimnis verwenden. Version - Alpha, Details - KEP .

Stall erklärt:


Andere Änderungen


Weitere Innovationen in Kubernetes 1.18 (eine vollständigere Liste finden Sie unter CHANGELOG ) :

  • JWT- Kubernetes service accounts (KSA) Kubernetes API. - . API- discovery-, OIDC (OpenID Connect) . OIDC (.. K8s-) KCA-, API-. — KEP.
  • - Priority and Fairness API (KEP) — API- ( max-in-flight). . ( FlowSchema) ( RequestPriority). kubectl:

    kind: RequestPriority
    meta:
      name: workload-high
    spec:
      assuredConcurrencyShares: 30
      queues: 128
      handSize: 6
      queueLengthLimit: 100
    
    kind: FlowSchema
    meta:
      name: workload-high
    spec:
      requestPriority:
        name: workload-high
      flowDistinguisher:
        source: namespace
        # no transformation in this case
      match:
      - and: # users using kubectl
        - notPatternMatch:
          field: user
          pattern: system:serviceaccount:.*
  • CertificateSigningRequest API, x509- Certificate Authority. K8s 1.4 - 1.6.
  • Eine Reihe bemerkenswerter Verbesserungen bei der Arbeit mit Windows: CRI-ContainerD-Unterstützung (Alpha-Version), RuntimeClass-Implementierung (Alpha-Version), CSI-Treiberunterstützung über CSI-Proxy (Alpha-Version), stabile Versionen der GMSA-Unterstützung (Group Managed Service Account) und RunAsUserName .

Abhängigkeitsänderungen:

  • CoreDNS-Version in kubeadm - 1.6.7;
  • cri-tools 1.17.0;
  • CNI (Container Networking Interface) 0.8.5, Calico 3.8.4;
  • Die verwendete Version von Go ist 1.13.8.

Was ist veraltet?


  • API Server bedient nicht veraltete API: alle Ressourcen apps/v1beta1und die extensions/v1beta1Notwendigkeit , sich zu bewegen auf apps/v1, und achten Sie auf die bestimmte Ressource daemonsets, deployments, replicasets, networkpolicies, podsecuritypolicies;
  • Endpunkt für Metriken wird /metrics/resource/v1alpha1 nicht gewartet - jetzt stattdessen /metrics/resource;
  • Alle Teamgeneratoren wurden kubectl run entfernt, mit Ausnahme desjenigen, der für die Pod-Generierung verantwortlich ist.

PS


Lesen Sie auch in unserem Blog:


All Articles