Wir haben Ressourcen über Helm angelegt und diese Ressourcendefinitionen seit längerem nicht mehr aktualisiert. Dadurch kamen wir in die Situation, dass nun der Versuch eines Helm Upgrades fehlschlägt.
Die Ausgangssituation
Die Fehlermeldung dazu ist etwas kryptisch und sieht ungefähr so aus:
|
1 2 3 4 5 6 7 8 9 10 11 |
➜ helm upgrade app --install --namespace app -f helm_vars/clone/values.yaml -f helm_vars/clone/secrets.yaml ./chart --wait --timeout 15m0s Error: UPGRADE FAILED: unable to build kubernetes objects from current release manifest: [resource mapping not found for name: "private" namespace: "" from "": no matches for kind "Ingress" in version "networking.k8s.io/v1beta1" ensure CRDs are installed first, resource mapping not found for name: "public" namespace: "" from "": no matches for kind "Ingress" in version "extensions/v1beta1" ensure CRDs are installed first] |
Was uns Helm hier mitteilt ist, dass die Ingress Komponenten mit dem Namen „private“ in der Version „extensions/v1beta1“ vorliegt. Diese Version der API ist mittlerweile veraltet und in einem der letzten Cluster Upgrades entfernt worden.
Das Problem
Helm verweigert hier die weitere Arbeit mit dem deployten Release, da im Kubernetes Cluster die angegebenen Ressourcen nicht mehr existieren. Im Detail beschreiben die Entwickler*innen von Helm das Problem auch hier noch einmal: https://helm.sh/docs/topics/kubernetes_apis/
Auf dieser Seite wird auch die theoretische Lösung beschrieben: Man kann das bestehende Release über Kubectl Befehle exportieren und dann die API Versionen anpassen, bevor man das Deployment wieder importiert. Die Herausforderung bei dieser Variante ist, das man per Hand das gesamte Chart kontrollieren und anpassen muss. Diese Textdokumente können allerdings sehr lang werden mit mehreren 100.000 Zeichen, was die Bearbeitung mühselig macht.
So kann man das aktuelle Secret zum Release in Erfahrung bringen und in einer release.data.decoded Datei sichern:
|
1 2 3 4 5 6 |
kubectl get secret -l owner=helm,status=deployed,name=<release_name> -- namespace <release_namespace> | awk '{print $1}' | grep -v NAME kubectl get secret <release_secret_name> -n <release_namespace> -o yaml > release.yaml cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d | base64 -d | gzip -d > release.data.decoded |
Die Datei muss nun bearbeitet werden und im Anschluss wieder verschlüsselt und im Cluster hinterlegt werden:
|
1 2 3 4 |
cat release.data.decoded | gzip | base64 | base64 # mit dem Code String der hier herausfällt den Wert unter "data.release" der release.yaml ersetzen kubectl apply -f release.yaml -n <release_namespace> |
Im Anschluss sollte dringend ein Helm Upgrade erfolgen, indem die angepassten API’s verwendet wurden.
Die Lösung
Findige Entwickler*innen bei Helm haben das Problem auch erkannt und die Helm-Extension mapkubeapis entwickelt, um diese Anpassungen automatisiert durchzuführen. Das Plugin ist soweit konfigurierbar, dass man sogar seine eigenen Mappings definieren kann, diese hinterlegt man einfach in der Map.yaml.
An dieser Stelle muss darauf hingewiesen werden, das mapkubeapis nur die API Versionen anpasst. Sofern in den Helm Ressourcen eine Funktion der alten API’s verwendet wurde, welche in den aktuellen Versionen nicht existiert, dann muss die Konfig, wie weiter oben beschrieben, per Hand angepasst werden.
Wie verhindere ich dieses Problem?
Viel besser wäre es natürlich, gar nicht erst in diese Situation zu geraten. Dazu würde ich auf zwei Tools vom Team bei Fairwind verweisen. Zum einem gibt es Pluto, welches veraltete Kubernetes Objekte im Cluster erkennt. Die zweite Empfehlung ist Nova, dieses Tool prüft, ob die im Cluster verwendeten Helm Charts aktuell sind.
Du teilst dein Wissen auch gern mit anderen?
Dann bewirb dich bei der Telekom MMS als DevOps oder Cloud Engineer:
Philip Penquitt
Mit über 10 Jahren Erfahrung als System Engineer im klassischen Betrieb, widme ich mich nun seit einigen Jahren mit Freude den Cloud-Technologien. Dabei versuche ich die Erfahrungen und das neu Gelernte auch im traditionellen On-Premises Umfeld anzuwenden.
Ob Digitalisierungsexpert*in, Werkstudent*in oder Schülerpraktikant*in – Hier berichten unsere Gastautoren aus ihrem Alltag.
