Kubernetes 1.16 ist seit einer Weile verfügbar und wird nach und nach auf vielen Managed-Kubernetes-Plattformen ausgerollt. Vielleicht haben Sie bereits von API-Deprecations gehört. Die Umstellung selbst ist überschaubar – bleibt sie jedoch unbeachtet, kann sie Ihre Services empfindlich stören.
API-Deprecation – worum geht es?
Mit dem wachsenden Funktionsumfang von Kubernetes müssen sich auch die APIs weiterentwickeln. Dafür gibt es Regeln, die Kompatibilität und Stabilität sicherstellen sollen¹. Das passiert nicht bei jedem Release, doch früher oder später führt kein Weg an der neuen API-Version und dem neuen Format vorbei – die alte Variante wird dann schlicht nicht mehr unterstützt.
Warum ist das beim Release 1.16 wichtig?
In den letzten Kubernetes-Versionen wurden einige veraltete APIs noch mitgeschleppt – mit Kubernetes 1.16 verschwinden sie nun endgültig. Konkret betrifft das folgende API-Gruppen und -Versionen:
- Deployment —
extensions/v1beta1,apps/v1beta1undapps/v1beta2 - NetworkPolicy —
extensions/v1beta1 - PodSecurityPolicy —
extensions/v1beta1 - DaemonSet —
extensions/v1beta1undapps/v1beta2 - StatefulSet —
apps/v1beta1undapps/v1beta2 - ReplicaSet —
extensions/v1beta1,apps/v1beta1undapps/v1beta2
Wer unter 1.16 versucht, eine Ressource mit einer dieser Versionen anzulegen, bei dem schlägt der Vorgang schlicht fehl.
Wie prüfe ich, ob ich betroffen bin?
Sie können natürlich alle Manifeste manuell durchgehen – das kostet allerdings viel Zeit. Schnell wird etwas übersehen, und so richtig praktikabel ist es ohnehin nicht, wenn mehrere Teams in den Cluster deployen oder die aktuellen Manifeste nicht zentral abgelegt sind. Genau hier setzt Kube-No-Trouble an, kurz kubent.
Wo ist der Haken?
Mit welcher API-Version eine Ressource ursprünglich erstellt wurde, lässt sich normalerweise nicht mehr nachvollziehen, da Ressourcen intern stets in die bevorzugte Storage-Version konvertiert und so abgelegt werden. Wenn Sie Ihre Ressourcen jedoch mit kubectl oder Helm deployen, wird das ursprüngliche Manifest zusätzlich im Cluster hinterlegt – und genau das machen wir uns zunutze².
So lösen Sie Ihre Deprecation-Probleme
Am einfachsten geht die Installation so:
sh -c "$(curl -sSL 'https://git.io/install-kubent')"
Damit landet die neueste Version von kubent in /usr/local/bin ³.
Setzen Sie den aktuellen Kontext von kubectl auf den Cluster, den Sie prüfen möchten, und starten Sie kubent:
Abb. 1: Beispielausgabe eines kubent-Laufs
Kubent verbindet sich mit Ihrem Cluster, ruft alle potenziell betroffenen Ressourcen ab, scannt sie und gibt eine Übersicht der tatsächlich betroffenen Ressourcen aus.
Mit dem Flag -f json erhalten Sie die Ausgabe im JSON-Format – ideal, um das Tool in Ihre CI/CD-Pipeline einzubinden oder die Ergebnisse weiterzuverarbeiten. Weitere Details zu den verfügbaren Konfigurationsoptionen finden Sie im README des Repos doitintl/kube-no-trouble.
Was tun mit den erkannten Ressourcen?
Manchmal genügt es, die apiVersion im Manifest anzupassen. In anderen Fällen hat sich die Struktur geändert und muss überarbeitet werden. Beachten Sie außerdem: Zwischen den Versionen haben sich zahlreiche Default-Werte geändert⁴ – wenn Sie also nur die apiVersion anpassen und ansonsten dasselbe Manifest anwenden, kann das Ergebnis deutlich anders ausfallen. Bei StatefulSet etwa hat sich updateStrategy.type von OnDelete auf RollingUpdate geändert – mit erheblichen Auswirkungen auf das Verhalten.
Der früher gebräuchliche Befehl kubectl convert ist inzwischen deprecated und konvertiert Ihre Ressourcen mit Blick auf die genannten geänderten Defaults möglicherweise nicht korrekt.
Der wohl beste Weg: Wenden Sie die Ressourcen einfach an (sofern Sie sie mit kubent erkannt haben, liegen sie Ihnen ja bereits vor) und holen Sie sich anschließend die neue Version über die API. So ist sichergestellt, dass die Ressource sauber in die neue Version überführt wird. Vielleicht ist Ihnen schon aufgefallen, dass kubectl nicht ganz deterministisch ist, welche Version es zurückliefert. Um eine bestimmte API-Version anzufordern, nutzen Sie die vollständige Form:
kubectl get ingress.v1beta1.extensions -o yaml
Feedback willkommen!
Wir hoffen, dieser Beitrag hilft Ihnen, veraltete APIs in Ihren Kubernetes-Clustern aufzuspüren und zu bereinigen, bevor sie Ihnen Ärger machen.
Das Tool kubent steht noch ganz am Anfang. Über Kommentare, Anregungen und Rückmeldungen, ob es Ihnen nützt, freuen wir uns sehr. Allzeit gute Fahrt! ⛵⛵⛵
- [1] Das Kubernetes Deprecation Policy-Dokument regelt, wie einzelne Teile des Systems als veraltet markiert und entfernt werden können.
- [2] Bei kubectl geschieht das über die Annotation
kubectl.kubernetes.io/last-applied-configuration, bei Helm in Form einer ConfigMap oder eines Secret. - [3] Wenn Sie – wie ich – zufälligen Skripten aus Blogposts nicht trauen, laden Sie das aktuelle Release für Ihre Plattform herunter und entpacken Sie es an einen Ort Ihrer Wahl.
- [4] Ein lesenswerter Artikel dazu ist David Schweikerts Kubernetes 1.16 API deprecations and changed defaults.
Weiterführende Links:
- Kube-No-Trouble – kubent GitHub-Repo – https://github.com/doitintl/kube-no-trouble
- Deprecated APIs Removed In 1.16: Here's What You Need To Know – Blogpost von Vallery Lancey – https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/