Clever Geek Handbook

Kubernetes 1.19: Ein Überblick über die wichtigsten Innovationen

Heute, am 25. August, wird eine neue Version von Kubernetes stattfinden (insgesamt um fast 2 Monate verzögert) - 1.19. In Anlehnung an die Tradition unseres Blogs sprechen wir über die wichtigsten Änderungen in der neuen Version.







Die zur Vorbereitung dieses Materials verwendeten Informationen stammen aus der Kubernetes-Erweiterungsverfolgungstabelle , CHANGELOG-1.19 , der Sysdig- Übersicht sowie verwandten Problemen, Pull-Anforderungen und Kubernetes-Verbesserungsvorschlägen (KEP).



Beginnen wir mit einigen wichtigen Innovationen allgemeiner Art ...



Mit der Veröffentlichung von Kubernetes 1.19 wurde das "Support-Fenster" für Kubernetes-Versionen von 9 Monaten (dh den letzten 3 Versionen) auf 1 Jahr (dh 4 Versionen) erhöht . Warum?



Es stellte sich heraus, dass Kubernetes-Clusteradministratoren aufgrund der hohen Geschwindigkeit der Projektentwicklung (häufige Hauptversionen) keine Zeit haben, ihre Installationen zu aktualisieren. Die Autoren des entsprechenden KEP beziehen sich auf eine Umfrage, die Anfang letzten Jahres von der Arbeitsgruppe durchgeführt wurde, und zeigten, dass sich etwa ein Drittel der Kubernetes-Benutzer mit veralteten K8-Versionen befasst, die in der Produktion ausgeführt werden:





(Zum Zeitpunkt der Umfrage betrug die aktuelle Kubernetes-Version 1,13, d. H. Alle K8-Benutzer 1.9 und 1.10 arbeiteten mit Releases, die zu diesem Zeitpunkt nicht mehr unterstützt wurden.)



Daher wird davon ausgegangen, dass eine dreimonatige Verlängerung des Supportzeitraums für Kubernetes-Versionen - die Veröffentlichung von Patches, mit denen die im Code gefundenen Probleme behoben werden - sicherstellt, dass mehr als 80% der Benutzer an unterstützten Versionen von K8 arbeiten (anstelle der derzeit angenommenen 50-60%) ).



Eine weitere große Entwicklung: Es wurde ein Standard für strukturierte Protokolle entwickelt ... Das aktuelle Protokollierungssystem in der Steuerebene garantiert keine einzige Struktur für Nachrichten und Objektreferenzen in Kubernetes, was die Verarbeitung solcher Protokolle erschwert. Um dieses Problem zu lösen, wird eine neue Struktur für Nachrichten in Protokollen eingeführt, für die die Klog-Bibliothek um neue Methoden erweitert wurde, die eine strukturierte Schnittstelle zum Generieren von Protokollen bieten, sowie zusätzliche Methoden zum Identifizieren von K8s-Objekten in Protokollen.



Gleichzeitig mit der Migration zu klog v2 wird der Übergang zu einem neuen Format für die Ausgabe von Protokollen in JSON durchgeführt, wodurch die Ausführung von Anforderungen an die Protokolle und deren Verarbeitung vereinfacht wird. Hierzu erscheint ein Flag --logging-format, das standardmäßig das alte Textformat verwendet.



Da ist das Kubernetes-Repository riesig und die AutorenDie KEPs für strukturierte Protokollierung sind Realisten und konzentrieren ihre Bemühungen, neue Ideen zum Leben zu erwecken, auf die häufigsten Nachrichten.



Eine Illustration der Protokollierung mit den neuen Methoden in klog: 



klog.InfoS("Pod status updated", "pod", "kubedns", "status", "ready")

I1025 00:15:15.525108       1 controller_utils.go:116] "Pod status updated" pod="kubedns"


klog.InfoS("Pod status updated", "pod", klog.KRef("kube-system", "kubedns"), "status", "ready")

I1025 00:15:15.525108       1 controller_utils.go:116] "Pod status updated" pod="kube-system/kubedns" status="ready"


klog.ErrorS(err, "Failed to update pod status")

E1025 00:15:15.525108       1 controller_utils.go:114] "Failed to update pod status" err="timeout"


Verwenden des JSON-Formats: 



pod := corev1.Pod{Name: "kubedns", Namespace: "kube-system", ...}
klog.InfoS("Pod status updated", "pod", klog.KObj(pod), "status", "ready")


{
   "ts": 1580306777.04728,
   "v": 4,
   "msg": "Pod status updated",
   "pod":{
      "name": "nginx-1",
      "namespace": "default"
   },
   "status": "ready"
}


Eine weitere wichtige (und sehr relevante) Neuerung ist der Mechanismus zum Informieren über veraltete APIs , der sofort als Beta-Version implementiert wird (d. H. Standardmäßig in Installationen aktiv ist). Wie erklärt von den Autoren in vielen Kubernetes ständig überholt Kapazität, in verschiedenen Staaten und mit unterschiedlicher Zeit bleiben s mi Aussichten. Es ist fast unmöglich, den Überblick zu behalten, alle Versionshinweise sorgfältig zu lesen und Konfigurationen / Einstellungen manuell zu bereinigen.



Um dieses Problem zu lösen, wird jetzt bei Verwendung der veralteten API ein Header zu den Antworten hinzugefügt Warning, der auf der Clientseite erkannt wird (client-go) mit der Möglichkeit unterschiedlicher Antworten: ignorieren, deduplizieren, protokollieren. Im Dienstprogramm kubectl lernten sie, wie diese Nachrichten an stderr ausgegeben, die Nachricht in der Konsole mit Farbe hervorgehoben und ein Flag --warnings-as-errorsmit einem selbsterklärenden Namen hinzugefügt werden .



Darüber hinaus wurden spezielle Metriken hinzugefügt, um die Verwendung veralteter APIs und Prüfanmerkungen zu melden.



Schließlich kümmerten sich die Entwickler um die Weiterentwicklung der Kubernetes-Funktionen aus der Beta-Version . Wie die Erfahrung des Projekts gezeigt hat, blieben einige neue Funktionen und Änderungen in der API im Beta-Status "hängen", da sie bereits automatisch (standardmäßig) aktiviert wurden und keine weiteren Maßnahmen der Benutzer erforderten.



Um dies zu verhindern, wird empfohlen Senden Sie automatisch die Funktionen an die Verfallsliste, die sich seit 6 Monaten in der Beta befinden (zwei Versionen) und keine der folgenden Bedingungen erfüllen:



  1. die GA-Kriterien erfüllen und in einen stabilen Status befördert werden;
  2. habe eine neue Beta, die die vorherige Beta überholt.


Nun zu den anderen Änderungen in Kubernetes 1.19, die nach ihren jeweiligen SIGs kategorisiert sind.



Gewölbe



Die neuen CSIStorageCapacity- Objekte sollen den Planungsprozess für Pods verbessern, die CSI-Volumes verwenden: Sie werden nicht auf Knoten gehostet, auf denen nicht genügend Speicherplatz vorhanden ist. Zu diesem Zweck werden Informationen zum verfügbaren Speicherplatz auf dem API-Server gespeichert und stehen CSI-Treibern und dem Scheduler zur Verfügung. Der aktuelle Implementierungsstatus ist die Alpha-Version. Einzelheiten finden Sie unter KEP .



Eine weitere Neuerung in der Alpha-Version ist die Möglichkeit, kurzlebige Volumes direkt in Pod-Spezifikationen, generischen kurzlebigen Inline-Volumes ( KEP), zu definieren). Vergängliche Volumes werden zum Zeitpunkt des Laichens für bestimmte Pods erstellt und beim Beenden gelöscht. Sie hätten früher definiert werden können (einschließlich direkt in der Spezifikation, d. H. Durch das Inline-Verfahren), aber der bestehende Ansatz, der die Konsistenz des Merkmals selbst bewiesen hat, deckte nicht alle Fälle seiner Verwendung ab.



Der neue Mechanismus bietet eine einfache API zum Definieren kurzlebiger Volumes für jeden Treiber mit Unterstützung für dynamische Bereitstellung (zuvor war hierfür eine Treiberänderung erforderlich). Es ermöglicht Ihnen, mit allen kurzlebigen Volumes (sowohl CSI als auch In-Tree-Volumes EmptyDir) zu arbeiten, und bietet Unterstützung für eine weitere neue Funktion (wie oben beschrieben) - die Verfolgung des verfügbaren Speicherplatzes.



Ein Beispiel für ein übergeordnetes Kubernetes-Objekt mit einem neuen kurzlebigen Volume (generisches Inline): 



apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-elasticsearch
  namespace: kube-system
spec:
  selector:
    matchLabels:
      name: fluentd-elasticsearch
  template:
    metadata:
      labels:
        name: fluentd-elasticsearch
    spec:
      containers:
      - name: fluentd-elasticsearch
        image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: scratch
          mountPath: /scratch
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: scratch
        ephemeral:
          metadata:
            labels:
              type: fluentd-elasticsearch-volume
          spec:
            accessModes: [ "ReadWriteOnce" ]
            storageClassName: "scratch-storage-class"
            resources:
              requests:
                storage: 1Gi


Hier erstellt der DaemonSet-Controller Pods mit Ansichtsnamen fluentd-elasticsearch-b96sd, wonach für einen solchen Pod ein PersistentVolumeClaim hinzugefügt wird fluentd-elasticsearch-b96sd-scratch.



Die letzte völlig neue Speicherfunktion, die als Alpha-Version eingeführt wurde, ist ein neues Feld csidriver.spec.SupportsFSGroupfür CSI-Treiber, das die Unterstützung von FSGroup- basierten Berechtigungen ( KEP ) anzeigt . Motivation: Ein Eigentümerwechsel für ein CSI-Volume wird durchgeführt, bevor es in einem Container bereitgestellt wird. Allerdings unterstützen nicht alle Arten von Speicher einen solchen Vorgang (z. B. NFS), weshalb dies jetzt zu Fehlern führen kann.



Bis zur Beta-Version (dh den Standardeinschlüssen):





/ Kubelet



Seccomp wurde für stabil erklärt (GA) . Diese Arbeit führte insbesondere zum Übergang zu Feldern für seccomp in der API anstelle von für veraltet erklärten Anmerkungen (neue Kubelets ignorieren Anmerkungen) und wirkte sich auf PodSecurityPolicy aus .



Ein neues Feld wurde bisher der zusätzlichen PodSpec , fqdnInHostnamedamit Sie den FQDN (Fully Qualified Domain Name) für den Pod - Host setzen . Ziel ist es, die Unterstützung für Legacy-Anwendungen in Kubernetes zu verbessern. So erklären die Autoren ihre Absichten:



« Unix Linux-, Red Hat CentOS, FQDN- hostname. , , Kubernetes, . ».


Standardmäßig wird falsedas alte Verhalten (für Kubernetes) beibehalten. Funktionsstatus - Alpha-Version, die in der nächsten Version (1.20) für stabil erklärt werden soll.



Es wurde beschlossen , die von Kubelet gesammelten Beschleunigermetriken aufzugeben . Es wird vorgeschlagen, solche Metriken von externen Überwachungsagenten über die PodResources-API zu erfassen. Diese API selbst wurde genau mit dem Ziel erstellt, alle gerätespezifischen Metriken aus dem Haupt-Kubernetes-Repository zu entfernen, sodass Anbieter sie implementieren können, ohne Änderungen am Kubernetes-Kern vorzunehmen. Die PodResources-API befindet sich in der Beta-Phase (Feature Gate ist dafür verantwortlich KubeletPodResources) und wird bald stabil sein. Für die aktuelle Version befindet sich der Abbruchprozess im Alpha-Status, Details in KEP .



Von nun an Kubelet gebaut werden kann , ohne Docker : durch diese „ohne“ die Autoren das Fehlen jeglicher Docker-spezifischen Code und die Abhängigkeit von der Golang Paket bedeuten docker/docker. Das ultimative Ziel dieser Initiative ist es, zu einem völlig "dockerlosen" Kubelet (dh ohne Docker-Abhängigkeit) zu gelangen. Wie immer können Sie bei KEP mehr über Motivation lesen . Diese Gelegenheit erhielt sofort den GA-Status.



Der Node Topology Manager, der in der letzten K8-Version seine Beta-Version erreicht hat , kann jetzt Ressourcen auf Pod-Ebene ausgleichen .



Planer



Zurück in Kubernetes 1.18 haben wir über eine globale Konfiguration für eine gleichmäßige Pod-Verteilung (Even Pod Spreading) geschrieben , aber dann wurde beschlossen , diese Funktion aufgrund der Ergebnisse von Leistungstests zu verschieben. Sie ist jetzt in Kubernetes (im Alpha-Status).



Das Wesentliche der Innovation ist die Hinzufügung globaler Einschränkungen ( DefaultConstraints), die es ermöglichen, die Regeln für die Verteilung von Pods auf einer höheren Ebene zu regeln - auf Clusterebene und nicht nur in PodSpec(durch topologySpreadConstraints), wie es bisher war. Die Standardkonfiguration ähnelt dem aktuellen Plugin DefaultPodTopologySpread: 



defaultConstraints:
  - maxSkew: 3
    topologyKey: "kubernetes.io/hostname"
    whenUnsatisfiable: ScheduleAnyway
  - maxSkew: 5
    topologyKey: "topology.kubernetes.io/zone"
    whenUnsatisfiable: ScheduleAnyway


Details finden Sie in KEP .



Eine weitere Funktion im Zusammenhang mit der gleichmäßigen Verteilung von Pods: die Verteilung einer Gruppe von Pods nach Fehlerdomänen (Regionen, Zonen, Knoten usw.) - übertragen von Alpha auf Beta (standardmäßig aktiviert).



Drei weitere Funktionen im Scheduler haben eine ähnliche "Steigerung" erzielt:





Netzwerke



Die Ingress-Ressource wird schließlich als stabil deklariert und hat eine Version v1in der API. In diesem Zusammenhang wurden in der entsprechenden Dokumentation einige Aktualisierungen vorgestellt. Besonderes Augenmerk sollte auf die Änderungen gelegt werden, die für den Benutzer durch diese PR erkennbar sind : Beispielsweise gibt es Umbenennungen wie spec.backend→ spec.defaultBackend, serviceName→ service.name, servicePort→ service.port.number...



Das Feld AppProtocol für Dienste und Endpunkte sowie die EndpointSlice-API (kube-proxy unter Linux startet Verwenden Sie standardmäßig EndpointSlices, bleiben Sie jedoch in Alpha für Windows und unterstützen Sie SCTP .



kubeadm



Für das Dienstprogramm kubeadm werden zwei neue Funktionen (in der Alpha-Version) eingeführt.



Das erste ist die Verwendung von Patches , um die von kubeadm generierten Manifeste zu ändern . Es war bereits möglich , sie mit Kustomize (in Alpha) zu ändern. Die Entwickler von kubeadm entschieden jedoch, dass die Verwendung regulärer Patches der bevorzugte Weg ist (da Kustomize zu einer unnötigen Abhängigkeit wird, was nicht erwünscht ist).



Jetzt ist es möglich , rohen Patches anwenden (über einen Flag --experimental-patches) für kubeadm Befehle init, joinund upgradesowie ihre Phasen. Die Kustomize-basierte Implementierung (Flag --experimental-kustomize) wird veraltet und entfernt.



Das zweite Feature ist ein neuer Ansatz für die Arbeit mit Komponentenkonfigurationendas kubeadm arbeitet mit. Das Dienstprogramm generiert, validiert, legt Standardwerte fest und speichert Konfigurationen (in Form von ConfigMaps) für Kubernetes-Clusterkomponenten wie Kubelet und kube-proxy. Im Laufe der Zeit wurde klar, dass dies eine Reihe von Schwierigkeiten mit sich bringt: Wie kann man zwischen Konfigurationen unterscheiden, die von kubeadm generiert oder vom Benutzer übermittelt wurden (und wenn nicht, was mit der Konfigurationsmigration zu tun ist)? Welche Felder mit Standardwerten wurden automatisch generiert und welche wurden absichtlich festgelegt?



Um diese Probleme zu lösen, wird eine Vielzahl von Änderungen dargestellt , darunter: Weigerung, Standardwerte festzulegen (dies muss von den Komponenten selbst durchgeführt werden), Delegierung der Konfigurationsvalidierung selbst Komponenten, Signieren jeder generierten ConfigMap usw.



Ein weiteres weniger wichtiges Merkmal für kubeadm ist das so genannte Feature-Gate PublicKeysECDSA, das die Möglichkeit umfasst , einen Cluster [via kubeadm init] mit ECDSA-Zertifikaten zu erstellen . Das Aktualisieren vorhandener Zertifikate (über kubeadm alpha certs renew) wird ebenfalls bereitgestellt, es gibt jedoch keine Mechanismen für den einfachen Wechsel zwischen RSA und ECDSA.



Andere Änderungen



  • Der GA-Status erhielt drei Funktionen im Bereich der Authentifizierung: CertificateSigningRequest-API , Einschränkung des Knotenzugriffs auf bestimmte APIs (über ein Zulassungs-Plugin NodeRestriction), Bootstrap und automatische Erneuerung des Kubelet-Client-Zertifikats.
  • Die neue Ereignis-API wurde ebenfalls mit einem geänderten Ansatz für die Deduplizierung für stabil erklärt (um eine Überlastung des Clusters mit Ereignissen zu vermeiden).
  • (kube-apiserver, kube-scheduler, etcd ) debian distroless. : , ( — KEP).
  • Kubelet Docker runtime target-, TargetContainerName EphemeralContainer ( ).
  • « » .status.conditions, API .
  • kube-proxy IPv6DualStack Windows ( feature gate).
  • Feature Gate mit einem selbsterklärenden Namen CSIMigrationvSphere(Migration vom integrierten Plug-In für vSphere zum CSI-Treiber) wurde auf die Beta-Version verschoben .
  • Für kubectl run hinzugefügtes Flag --privileged.
  • Dem Scheduler - , - wurde ein neuer Erweiterungspunkt hinzugefügt, der nach der Phase beginnt .PostFilterFilter
  • Die Cri-Containerd- Unterstützung unter Windows hat die Beta erreicht.


Abhängigkeitsänderungen:



  • Version von CoreDNS in kubeadm - 1.7.0 enthalten;
  • cri-tools 1.18.0;
  • CNI (Container Networking Interface) 0.8.6;
  • etcd 3.4.9;
  • Die verwendete Version von Go ist 1.15.0-rc.1.


PS



Lesen Sie auch in unserem Blog:





More articles:


All Articles