Kubernetes Talks im Perfekt Futur

Verwendet man NFS für persistente Datenspeicher von Kubernetes Deployments, können alle Daten durch ein klassisches Backup Verfahren zentral auf dem Host gesichert und wiederhergestellt werden. Dies ändert sich jedoch, wenn man auf leistungsfähigere Datenspeicher Cluster wie beispielsweise GlusterFS oder CephFS (z.b. in Verbindung mit Rook) zurückgreift: In diesem Fall sind persistente Datenspeicher oftmals schwer von außerhalb der Container Instanz zu erreichen. Man hat nun die Möglichkeit entweder in jedem Deployment zum Beispiel durch ein Sidecar Container individuelle Backups aufzusetzen oder man macht sich das Kubernetes Operator Konzept zu nutze. Das Stash Projekt von AppsCode ist Open Source und implementiert einen Kubernetes Operator für das Backup Tool restic. Damit lassen sich individuelle Backups direkt über das Kubernetes Deployment konfigurieren. Je nach Konfiguration werden Init- oder Sidecar Container für Backup und Recovery vollautomatisch erstellt und ausgeführt. Mit dem zusätzlichen Monitoring erhält man ein voll automatisiertes und skalierbares Backup System für alle Deployments des Kubernetes Cluster.

GitLab in Verbindung mit Kubernetes erlaubt eine sehr einfache und schnelle Integration (CI) und ein kontinuierliches, automatisches Deployment (CD) von Containern und die damit verpackten Anwendungen. Dabei versteht man unter Integration das eigentliche Bauen und Testen der Software mithilfe des Quellcodes sowie unter Continuous Deployment vielmehr den Release Prozess der Software und das automatische Ausrollen dieser in verschiedene Umgebungen.

GitLab selbst stellt neben einem Repositorium zur Versionierung und Verwaltung von Software Code auch zahlreiche Werkzeuge zur Verfügung, die den Entwicklungsprozess einer Software unter anderem hinsichtlich CI/CD effektiv unterstützen. So lassen sich sogenannte Pipelines und Jobs definieren, die abhängig von den Git Befehlen des Benutzers getriggert werden können. Ein anschauliches Beispiel ist das automatische Bauen und Packaging einer Software, nachdem ein neuer Git Tag zum Beispiel „V1.0.0“ für einen neuen Release gesetzt wurde. Wurden bereits automatische Tests implementiert, werden diese ebenfalls anschließend in der Pipeline ausgeführt. Abhängig von dem Testergebnis kann nun die Anwendung, entweder als Docker Image in der GitLab eigenen Docker Registry hinterlegt werden oder auch zum Beispiel auf einen Kubernetes Cluster automatisch oder auch teil-automatisch mit händischer Überprüfung in einer Testing- oder Produktumgebung deployed werden.