Alles wichtige zur Version 1.19 von Kubernetes

Ingress GA

Die bereits mit der Kubernetes Version 1.1 eingeführte Ingress Ressource für das Management von eingehenden Traffic über HTTP/HTTPS wird nun nach ganzen 18 Minor Versionen Stable. Die neue Version findet ihr nun in der API-Version networking.k8s.io/v1

Hierbei ergibt sich eine wichtige Änderung. Ab sofort müsst ihr bei euren Ingress-Ressourcen den pathType mit angeben. Dieser wurde bisher immer automatisch gesetzt, wenn ihr ihn nicht angegeben hattet. Ein vollständig korrekt aufgebauter Ingress sieht also nun wie folgt aus:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
spec:
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          serviceName: test
          servicePort: 80

Release Schedule und Support

Wie bereits in der Einleitung erwähnt, ändert sich der Release Cycle und die neuen Versionen erhalten nun 12 statt 9 Monate Support. Auch erscheint dieses Jahr eine Minor Version weniger, da sich bereits die Version 1.19 um einige Wochen verschoben hat. Der Grund für diese Änderung liegt zum Teil an der aktuellen COVID-19 Situation.

Ein weiterer Grund für die Änderung ist die aktuelle Verteilung der Kubernetes Versionen in Production. Viele Firmen sind hier teilweise noch auf Kubernetes Versionen unterwegs, welche schon nicht mehr offiziell Unterstützt werden. Mit dem längeren Support Zeitraum erhofft man sich, dass mehr Firmen auf einer unterstützen Version unterwegs sind. Eine Umfrage der LTS Working Group Anfang 2019 zeigt sehr gut, wie dieses Problem aussieht. Zum Zeitpunkt der Umfrage waren die Kubernetes Versionen 1.11, 1.12 sowie 1.13 offiziell noch im Supportzeitraum.

Vereinheitlichte status.conditions

Innerhalb von Kubernetes Objekten enthält das Status Objekt meist eine Angabe der "conditions", welche für das debugging nützlich sein kann. Diese wird allerdings bisher nicht einheitlich über verschiedene CRDs hinweg gesetzt. Jede Resource hat also aktuell eine etwas andere Implementierung. Mit 1.19 gibt es nun eine offizielle Richtlinie, nach der dieses Objekt in Zukunft in CRDs und Co. gesetzt werden sollte:

$ kubectl get po -n cloudpirate cloudpirate-deployment-88dc64d88-w4hvs -o yaml
[...]
conditions:
  - lastProbeTime: null
    lastTransitionTime: "2020-08-14T21:16:45Z"
    status: "True"
    type: Initialized
  - lastProbeTime: null
    lastTransitionTime: "2020-08-17T13:11:32Z"
    status: "True"
    type: Ready
[...]

Top Feature: Kubectl Warnungen

Ab sofort erhaltet ihr bei der Verwendung von kubectl eine Warnung, wenn das von euch verwendete API-Objekt in einer veralteten / deprecated Version vorliegt. Damit seht ihr sofort, ob die von euch im Einsatz befindlichen Versionen ausgetauscht werden sollten. Für mich persönlich ist dieses Feature eines der Highlights, da ihr so nicht mehr auf externe Tools zur Überwachung eurer API-Versionen angewiesen seit.

$ kubectl get ingress.extensions                                                 
Warning: the extensions/v1beta1 ingresses resource is deprecated in v1.14, targeting removal in v1.22
No resources found in default namespace.

$ kubectl get ingresses.networking.k8s.io
No resources found in default namespace.

Tipp
Über kubectl api-versions sowie kubectl api-resources könnt ihr euch die aktuell in eurem Cluster vorhandenen und aktivierten API-Versionen und Ressourcen anzeigen lassen.

seccomp GA

Mit seccomp kannst du einer laufenden Applikation (zum Beispiel einem Pod) bestimmte Berechtigungen und SysCalls erlauben bzw. verbieten. Dieses Feature ist mit Kubernetes 1.3 hinzugefügt worden und wird nun Stable. Im Zuge dieser Änderung Ändert sich auch die Art und Weise, wie du seccomp konfigurierst. Zuvor war eine Konfiguration über umständliche Annotations nötig, nun kannst du innerhalb von Pods und Containern die Angabe securityContext.seccompProfile setzen.

Weiterhin bekommt der Sandbox Container eines jeden Pods nun ein sogenanntes runtime/default seccompProfile.

TLS 1.3 Support

Im Rahmen des 2019 durchgeführten Security Audits von Kubernetes gab es eine Empfehlung, das verwendete TLS auf die Version 1.3 zu aktualisieren. Mit Kubernetes 1.19 sind nun die erforderlichen TLS 1.3 ciphers hinzugekommen und können somit innerhalb von Kubernetes verwendet werden.

Weiterführende Ressourcen

Um mehr über Kubernetes 1.19 zu Erfahren, schau dir gerne die folgenden Beiträge von anderen Plattformen an. Weiterhin sollten die offiziellen Release Notes sowie ein entsprechender Blogbeitrag auf der Kubernetes Seite innerhalb der nächsten Tage veröffentlicht werden.

Stackrox - What’s New in Kubernetes 1.19? New Features and Updates

sysdig - What’s new in Kubernetes 1.19?

Offizieller Blog

Wir nutzen Cookies