</TECH NEWS>
NEUESTES VON UNSEREN ENTWICKLERN:

15.08.2019 – von Linus|

The Google Cloud Initialization – Lessons learned (3/3)

Cert-Manager

Wir benutzen den cert-manager um unsere Services im Cluster mit SSL Zertifikaten zu versorgen. Als wir versucht haben, ein Update des cert-manager cluster issuer vorzunehmen, sind wir mit einigen Herausforderungen konfrontiert worden. Diese verhinderten, dass unsere Services weiterhin mit Zertifikaten versorgt wurden. Während wir die Herausforderungen angegangen sind, haben wir folgendes gelernt:

VPN Networking Routes With Preemptible Nodes

In der Google Cloud gibt es die Möglichkeit preemptible compute Instanzen hochfahren zu lassen. Diese kosten einen Bruchteil, des normalen Preises, werden aber nach spätestens 24 Std beendet und wieder neu hochgefahren. Kubernetes bemerkt den Ausfall der nodes und reorganisiert sich wieder. Somit sind preemptible Instanzen ein guter Weg um bares Geld zu sparen.
Um von unseren Standorten aus direkt in unser Kubernetes Cluster kommunizieren zu können, haben wir von jedem Standort aus eine VPN Verbindung in die Google Cloud eingerichtet und eine Route zu einer der Kubernetes Nodes aufgesetzt. Es kam wie es kommen musste, die Nodes wurden nach 24 Stunden beendet, neu gestartet und unsere Route wurde ungültig, da sie noch auf die alte Node zeigte. Als workaround, haben wir uns dazu entschieden einen sehr kleinen fixen Nodepool aufzusetzen, welcher keine preemptible Nodes enthält und somit immer online bleibt. Er dient uns jetzt als Gateway-Pool für den VPN um die Route in das Kubernetes Cluster aufrecht zu erhalten.

NFS Provisioner vs. Google NFS Provisioner

Eine der größten Herausforderungen, mit der wir im Kubernetes Umfeld konfrontiert waren, ist der Umgang mit Speicherplatz. Da es in der Google Cloud keine Read-Write-Many Persistent Volume Claims (PVC) gibt, mussten wir nach einer Alternative suchen, welche es uns erlaubt, Read-Write-Many Speicherplatz zwischen mehreren Pods zu verwenden. Google selbst bietet zwar den Google Cloud Storage an, dieser ist aber für deutlich größeren Speicherplatzbedarf ausgelegt, als unsere Pods im Betrieb benötigen. Somit haben wir uns nach Alternativen umgeschaut und verschiedene Lösungen gefunden. Die meisten dieser Lösungen setzen auf eine Vermittlungsschicht zwischen einem Read-Write-Once PVC und dem Kubernetes Netzwerk. Pods, welche geteilten Speicherplatz benötigen, können sich direkt über das Netzwerk mit dem Speicherplatz verbinden und diesen nutzen.
Der NFS Server Provisioner (https://github.com/helm/charts/tree/master/stable/nfs-server-provisioner) sah nach einer guten Lösung dafür aus. Allerdings mussten wir schnell feststellen, dass dieser sich nicht immer so verhielt wie erwartet. Die Performance war langsamer als gedacht. Teilweise sind die PVC’s, welche am NFS Provisioner hingen, in den Tiefen der Cloud verschwunden und konnten nicht mehr wiederhergestellt werden. Es musste also etwas anderes her.
Als nächstes fanden wir den Google NFS Provisioner (https://github.com/mappedinn/kubernetes-nfs-volume-on-gke/tree/master/config-yml-files) – `gcr.io/google_containers/volume-nfs:0.8` – das sah genau nach dem aus, was wir gesucht haben. Wir haben also das installations yaml in ein Helm Chart umgeschrieben und dieses dann deployt. Nach 24 Stunden, nachdem die preemptible nodes kurz beendet und wieder neu gestartet wurden, waren auch hier die PV und PVC’s nicht mehr zu finden. Als Workaround haben wir nun den Google NFS Provisioner in unserem VPN Gateway Nodepool gestartet und seitdem haben wir keine Probleme mehr damit gehabt.

Gitlab Runners

CI/CD setzen wir mit Gitlab um. Dazu haben wir die Kubernetes Gitlab runners per Helm chart deployt (https://gitlab.com/charts/gitlab-runner). Sie starten schnell, für die meisten Builds und Deployments klappt das gut, allerdings gibt es auch hier ein paar limitierungen, an denen wir derzeit noch arbeiten.

  • Speicher Read/Write Performance ist die größte Herausforderung. Wir haben dazu einen SSD cluster in der Cloud angelegt und die Gitlab runners benutzen diesen bereits. Allerdings sind die Gitlab builders noch nicht in der Lage den Speicher zu verwenden. Laut Dokumentation sollte es möglich sein, aber selbst nachdem wir den hostPath gesetzt haben, gab es bisher noch keinen Erfolg und wir arbeiten weiter daran.
  • Wenn die Runners entsprechende Builds gestartet haben, werden diese nach dem Bauen komplett abgeräumt, was zu Folge hat, dass wir keine Möglichkeit haben das docker layer caching für den nächsten Build zu verwenden und nicht angepasste stages daraus zu beziehen.
  • Aktuell suchen wir noch nach einer Node- und Runner-Ressourcengröße, die gut skaliert, schnell baut und für alle unsere Buildprozesse Ressourcen effizient arbeitet

Next Steps

1. Um PHP Applikationen in Kubernetes zu deployen, haben wir einige Herausforderungen gemeistert (web server + php server + NFS shared volume). Für unsere WordPress deployments werden wir in naher Zukunft eine andere Variante testen:

  • PHP Container und Nginx Container in einem Pod
  • Beim Build bereits die komplette Codebase in beide Container integrieren
  • das WP-Stateless Plugin (https://wp-stateless.github.io/) nutzen, um Uploads und all die anderen WordPress eigenen Dateien zentral in der Cloud abzulegen

Damit werden wir den NFS Workaround ablösen.

Für alle anderen PHP Anwendungen, bleibt abzuwarten, wie die Anforderungen sind und ob es weiterhin möglich sein wird, komplett auf einen NFS in Kubernetes zu verzichten. Wir bleiben auf jeden Fall dran und berichten, sobald wir eine stabile NFS Version gefunden haben sollten.

2. Unsere Kubernetes Cluster verwenden bereits das Google Autoscaling. Allerdings gibt es noch weit mehr Tools und Features um die Performance vom Kubernetes Cluster noch zu steigern und Ressourcen Verschwendung zu reduzieren:

  • Benutzerdefinierte Metriken und Cluster Monitoring, um deutlich präzisere Nutzungsinformationen zu erhalten und das Scaling weiter zu verbessern
  • Optimierung der Container Ressourcelimits
  • Herunterfahren bzw. Downscaling von Test-Clusterressourcen außerhalb der Arbeitszeiten

3. Die default Domain des Kubernetes DNS ist ‚cluster.local‘ und kann mit dem default KubeDNS Service auch nicht geändert werden. Wir würden gerne pro Kubernetes Cluster eine selbst definierte Domain vergeben, um die Cluster besser per DNS identifizieren zu können und um DNS Konflikten mit den lokalen Maschinen zu umgehen. Dazu werden wir in naher Zukunft CoreDNS einsetzen, was uns genau diese Konfiguration erlaubt.



WEITERE SPANNENDE BEITRÄGE



Unternehmen Marken Team Presse Karriere Tech-Blog SH Händler-Shop