Mit Version 1.18 haben wir das zweite Release von Nubus für Kubernetes in diesem Jahr veröffentlicht. Der Fokus in dieser Version liegt darauf, die Abhängigkeiten von bestimmten Rahmenbedingungen innerhalb eines Kubernetes-Clusters zu reduzieren. Dadurch lässt sich Nubus deutlich einfacher und flexibler einsetzen.
Inhaltsverzeichnis
Freie Wahl beim Ingress Controller
Der „Ingress Controller“ in einem Kubernetes-Cluster steuert die Zugriffe auf die Schnittstellen der betriebenen Anwendungen. Bei Nubus betrifft dies beispielsweise die Erreichbarkeit der Webservices von Login und Portal durch die Browser der Endanwender. Betreiber von Kubernetes-Clustern können dabei zwischen mehreren Ingress-Implementierungen wählen, die jeweils unterschiedliche Vor- und Nachteile haben.
Bisher haben wir mit Nubus für Kubernetes eine feste Vorkonfiguration (sogenannte „Annotations“) für die Ingress Implementierung „ingress-nginx“ ausgeliefert und ausschließlich den Betrieb mit diesem Ingress Controller unterstützt. Diese bislang weit verbreitete Implementierung wurde jedoch kürzlich abgekündigt und sollte daher nicht mehr eingesetzt werden.
Bereits mit Nubus 1.17 haben wir erste Verbesserungen in diesem Bereich veröffentlicht. Mit Nubus 1.18 konnten wir diese Arbeiten wie geplant abschließen. Dafür war es notwendig, einige Konfigurationsoptionen in den „Annotations“, die ausschließlich von ingress-nginx unterstützt wurden, durch Änderungen innerhalb der Nubus-Komponenten überflüssig zu machen.
So wurden in den Nubus-Komponenten beispielsweise alle sogenannten „Rewrites“ innerhalb der Webservice-URLs entfernt. Dadurch besteht nun keine Abhängigkeit mehr zu einer bestimmten Ingress-Implementierung, sodass Nubus grundsätzlich mit jeder Implementierung betrieben werden kann. Getestet haben wir dies mit den Implementierungen „haproxy-ingress“ und „traefik“. Zukünftige Releases werden wir standardmäßig mit „traefik“ testen.
Vereinfachungen bei Zertifikaten und S3 Storage
Eine weitere Reduktion von Abhängigkeiten innerhalb des Kubernetes-Clusters betrifft das Zertifikatshandling. Bisher bestand eine feste Abhängigkeit zum „cert-manager“, der in vielen Kubernetes-Clustern für das Ausstellen von SSL Zertifikaten eingesetzt wird. Durch die neue Unabhängigkeit von einer konkreten Ingress-Implementierung können nun jedoch auch andere Zertifikats-Manager im Kubernetes Cluster verwendet werden.
Auch beim S3 Storage konnten wir Abhängigkeiten reduzieren. Nubus speichert einige Binärdaten in S3-Buckets, darunter statische Dateien, die vom Portal genutzt werden. Bisher mussten Teile dieser S3-Buckets öffentlich verfügbar gemacht werden, damit die Browser der Anwender auf diese Dateien zugreifen konnten.
Mit Nubus 1.18 erfolgt der Zugriff auf diese Dateien direkt über die in Nubus integrierten Webservices. Dadurch lässt sich die S3-Konfiguration deutlich vereinfachen.
Die kleinen Highlights
Wie gewohnt übernimmt das Nubus-für-Kubernetes-Release zahlreiche Verbesserungen an den Nubus-Komponenten, die beispielsweise aus den UCS-Errata der vergangenen Wochen bekannt sind. Neben Sicherheitsupdates und Bugfixes gibt es auch einige erwähnenswerte Neuigkeiten:
- Eine Fehlermeldung, die abgelaufene Zertifikate meldete, wurde aus der Management-UI der UMC entfernt. Die zugrunde liegende Prüfung ist nur in Nubus für UCS relevant und wird für Kubernetes nicht benötigt.
- Die Installation oder Aktualisierung von Erweiterungen des UDM – etwa beim Definieren neuer Extended Attributes – erfordert keinen Neustart der UDM REST API mehr.
- Keycloak wird nun so konfiguriert, dass Informationen über Nutzer bei jedem Login aus dem LDAP aktualisiert werden. Dadurch wird sichergestellt, dass Änderungen an Nutzern immer beim nächsten Login wirksam werden.
Nubus 1.18 steht – wie im Operation Manual beschrieben – über unsere OCI Registry zum Downbload bereit. Weitere Informationen zu den enthaltenen Änderungen finden sich in den Release Notes.
