Ich hatte bereits am Ende des letzten Blogposts angerissen, dass ich geplant hatte KubeDB zu verwenden um PostgreSQL-Instanzen im Kubernetescluster aufzusetzen. KubeDB hat bei einigen meiner Versuche sehr gut funktioniert. AppsCode hat dann allerdings die Community Edition stark beschnitten. Auch der Operator von Zalando (https://github.com/zalando/postgres-operator) hat sich für mich als ungeeignet erwiesen. Die Prozessarchitektur arm64 wird nicht unterstüzt. Ich habe mich dann entschieden keinen Operator zu verwenden und PostgreSQL per Helm-Chart zu installieren. …

Dieser Blogpost der K8S-Reihe hat lange auf sich warten lassen. Das hat nicht nur damit zu tun, dass ich mit anderen Dingen beschäftigt war, sondern auch damit, dass Persistenz im Kubernetes-Cluster kein leichtes Thema ist. Seit ich begonnen habe, mich näher mit Kubernetes zu befassen, habe ich mich auch mit diesem Thema beschäftigt und immer wieder verschiedene Lösungen ausprobiert, ohne eine zu finden, mit der ich vollständig zufrieden gewesen wäre. …

Ein Helm-Chart Repository besteht lediglich aus den per tar archivierten und mit gzip komprimierten Charts, einer sogenannten Provenienz-Datei pro Chart und einer index.yaml. Die Struktur eines Helm-Chart Repositories sieht üblicherweise wie folgt aus: /path/to/chart/folder/ | |- index.yaml | |- chart-a-1.0.0.tgz | |- chart-a-1.0.0.tgz.prov | |- chart-b-1.0.0.tgz | |- chart-b-1.0.0.tgz.prov Die Provenienz-Dateien werden während der Archivierung eines Charts erzeugt. Mehr Detailinformationen zur Provienenz und Integrität von Helm-Charts gibt es unter https://helm.sh/docs/topics/provenance/. …