Mobiliar Kubernetes Support

Puzzle ITC unterstützt die Schweizerische Mobiliar in diversen spannenden Projekten rund um ihre Kubernetes Plattform.

Ausgangslage

Das Vikingsteam der Mobiliar betreibt die hauseigene Container Plattform (auf Basis von Kubernetes), auf deren viele Business-Applikationen laufen. Dazu gehört der Support und das Know-How Sharing rund um Kubernetes für die Mobiliar-eigenen Entwicklerteams, aber auch der Betrieb für diverse unterstützenden Applikationen, die das Leben der Entwickler vereinfachen sowie DevOps ermöglichen.

Lösung/Projekt

Puzzle ITC darf die Mobiliar mit zwei System Engineers in diesem Vorhaben begleiten. Sebastian Plattner und David Schneider helfen insbesondere beim Erstellen von Proof-of-Concepts verschiedener Applikationen von der Einführung bis in die Produktion. Aber auch bei alltäglichen Wartungsarbeiten rund um die Kubernetes Cluster sowie bei der Weiterentwicklung eigener Applikationen und Tools auf der Container Plattform können sie als Unterstützung dienen.

Die Rolle von Puzzle ITC

Bei folgenden Vorhaben hat Puzzle ITC unter anderem mitgewirkt:

Proof-of-Concept Hashicorp Vault
Hashicorp Vault speichert auf eine sichere Art und Weise Tokens, Passwörter, Zertifikate oder sonstige sensitive Daten und bieten eine UI, CLI oder HTTP API für den Zugriff an. Für das Deployen in der Mobiliar Kubernetes Umgebung haben wir Helm Charts entwickelt, die mit Hilfe von Liima den Hashicorp Vault automatisch installieren und konfigurieren. Weiter haben wir ein Berechtigungskonzept und eine Struktur in Vault aufgebaut, um die bereits bestehenden Berechtigungskonzepte der Mobiliar zu integrieren. Dazu haben wir ein Konfigurations-Tool in Python entwickelt, um die Konfiguration dieser Berechtigungsstrukturen zu standardisieren. Dies hat schlussendlich eine Automatisierung beim Erstellen von Berechtigungen auf die Bereiche in Vault vereinfacht. Das Berechtigungskonzept ermöglicht unter anderen eine Authentifizierung mit der bestehenden Mobiliar Active Directory Umgebung, wie auch eine Authentifizierung mit Hilfe von Kubernetes Service Account Tokens. Damit wird unter anderem ermöglicht, dass Applikationen, die auf Kubernetes deployed wurden, einen Service Account verwenden können, um Secrets oder Zertifikate aus Hashicorp Vault auszulesen und dann zu verwenden.

Entwicklung Kubernetes Controller für Secret Management mit Hashicorp Vault
Ein Kubernetes Controller kann auf Custom Ressource Records (CRD) in Kubernetes reagieren. Im Zusammenhang mit der Hashicorp Vault Einführung haben wir einen Kubernetes Controller entwickelt, der mit Hilfe eines Custom Ressource Record Secrets aus Hashicorp Vault ausliest und in einem Kubernetes Secret ablegt. Der Kubernetes Secret Controller nutzt zur Authentifizierung einen Service Account, dessen Token direkt in Hashicorp authentifiziert werden kann.

Weiterentwicklung Kubernetes Controller zum Verwalten von Oracle Datenbanken
Das Vikingsteam hat für die Mobiliar einen Kubernetes Controller entwickelt, mit dem die Entwickler automatisiert mit einem Custom Ressource Record Oracle PDB’s erstellen können. Der Controller erstellt der Oracle PDB und legt anschliessend eine Config Map sowie ein Secret im gewünschten Namespace ab. Der Applikationsentwickler kann dies dann für die Verbindung zur Oracle PDB verwenden. Wir durften hier diverse Ergänzungen wie die Einführung eines Status im Custom Resource Record umsetzen sowie kleinere Bugs beheben.

Einfühung external-dns
Damit Entwickler effektiv DevOps betreiben können, muss es unter anderem möglich sein, DNS Records selbständig zu erstellen. Mit dem external-dns Projekt können DNS Records automatisch anhand von Ingress & Service auf dem DNS Server der Mobiliar erstellt werden. Hier haben wir geholfen, external-dns richtig auf den verschiedenen Kubernetes Cluster zu deployen und die korrekte Anbindung an die DNS Server sicherzustellen.

Entwicklung Storage Provisioner für Hitachi NAS
In Kubernetes kann man mit Storage Classes verschiedene Arten von Storage definieren. Beim Bestellen von Persistent Storage mit einem Persistent Volume Claim (PVC) kann durch die Storage Class angegeben werden, welche Art von Storage man möchte. In jeder Storage Class wird ein Provisoner definiert. Wenn über ein PVC Storage bestellt wird, ist der Provisioner zuständig den entsprechenden Storage vorzubereiten und die Mountoptionen in der Form eines Persistent Volume (PV) zur Verfügung zu stellen. In Kubernetes gibt es einige Provisioners, welche von Haus aus verwendet werden können. Wenn man bestimmte Arten von Storage wie z.B. iSCSI oder NFS verwenden will oder spezielle Anforderungen an einen Provisioner stellt, dann muss einen eigenen Provisioner betrieben werden.

Für die Mobiliar durften wir ein Provisioner entwickeln, welcher iSCSI Volumes auf der Hitachi NAS Platform der Mobiliar bereitstellt. Beim Erstellen verwendet dabei der Provisioner die REST-API des Hitachi NAS Managers, um ein iSCSI Target und eine LUN, mit der im PVC gewünschten Grösse, zu erstellen. Das Target wird mit einem zufällig generierten Passwort CHAP Secret versehen. Dieses Secret wird als Kubernetes Secret im Namspace des PVCs abgelegt und im PV referenziert (siehe Beispiel PV). Somit kann sich ein Pod beim Mounten des Volumes authentifizieren. Beim Löschen werden die angelegten Objekte (Target und LUN) auf dem selben Weg wieder gelöscht.

Tech Stack

In den diversen Projekten bei Mobiliar verwenden wir folgende Technologien:

  • Kubernetes
  • Docker
  • Helm
  • Hashicorp Vault
  • JetBrains Teamcity
  • Atlassian BitBucket
  • Golang
  • Python
  • Bash