Helm-Templates sind Kubernetes-Manifeste, die mit der Go-Templatesprache text/template angereichert wurden. Sie befinden sich im Verzeichnis templates/ Ihres Charts und werden von Helm mithilfe der Werte aus values.yaml und benutzerseitiger Überschreibungen gerendert. Sie zu verstehen ist der Schlüssel zu wartbaren und wiederverwendbaren Charts.

Template-Grundlagen

Ein minimales Deployment-Template:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-app
  labels:
    app: {{ .Chart.Name }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: {{ .Chart.Name }}
  template:
    metadata:
      labels:
        app: {{ .Chart.Name }}
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"

Eingebaute Objekte

Template-Funktionen

Helm enthält die Go-Sprig-Bibliothek mit über 60 Hilfsfunktionen:

# Standardwert wenn leer
image: {{ .Values.image | default "nginx:latest" }}

# String sicher in Anführungszeichen setzen
annotation: {{ .Values.description | quote }}

# In Großbuchstaben umwandeln
name: {{ .Values.name | upper }}

# Strings formatieren
fullname: {{ printf "%s-%s" .Release.Name .Chart.Name }}

# Mehrzeiligen Block einrücken (entscheidend für verschachteltes YAML)
resources:
  {{- toYaml .Values.resources | nindent 2 }}

Bedingungen

spec:
  {{- if .Values.resources }}
  resources:
    {{- toYaml .Values.resources | nindent 4 }}
  {{- end }}
  {{- if .Values.nodeSelector }}
  nodeSelector:
    {{- toYaml .Values.nodeSelector | nindent 4 }}
  {{- else }}
  nodeSelector: {}
  {{- end }}

Das - in {{- entfernt führende Leerzeichen; -}} entfernt nachfolgende Leerzeichen. Das ist entscheidend für saubere YAML-Ausgabe.

Schleifen mit range

Über eine Liste iterieren:

env:
{{- range .Values.envVars }}
  - name: {{ .name }}
    value: {{ .value | quote }}
{{- end }}

Über eine Map iterieren:

annotations:
{{- range $key, $val := .Values.annotations }}
  {{ $key }}: {{ $val | quote }}
{{- end }}

Benannte Templates

Benannte Templates vermeiden Wiederholungen über Dateien hinweg. Üblicherweise leben sie in _helpers.tpl (das _-Präfix verhindert, dass Helm die Datei als Manifest rendert):

{{/* _helpers.tpl */}}
{{- define "myapp.labels" -}}
helm.sh/chart: {{ .Chart.Name }}-{{ .Chart.Version }}
app.kubernetes.io/name: {{ .Chart.Name }}
app.kubernetes.io/instance: {{ .Release.Name }}
app.kubernetes.io/managed-by: {{ .Release.Service }}
{{- end }}

In anderen Templates mit include verwenden:

metadata:
  labels:
    {{- include "myapp.labels" . | nindent 4 }}

Bevorzugen Sie immer include gegenüber der eingebauten template-Aktion, da include einen String zurückgibt, der an Funktionen wie nindent weitergeleitet werden kann.

Templates debuggen

Templates lokal rendern ohne Deployment im Cluster:

# Alle Templates rendern
helm template my-release ./my-chart

# Mit benutzerdefinierten Werten rendern
helm template my-release ./my-chart -f custom-values.yaml

# Validieren und linten
helm lint ./my-chart

Um ein gerendertes Objekt während der Entwicklung zu inspizieren, können Sie es temporär als YAML ausgeben:

{{- toYaml .Values | nindent 0 }}

Wenn Sie mich unterstützen möchten, kaufen Sie mir einen Kaffee.

Helm ist der Paketmanager für Kubernetes. Er ermöglicht es, komplexe Kubernetes-Anwendungen mithilfe wiederverwendbarer Pakete, sogenannter Charts, zu definieren, zu installieren und zu aktualisieren. Stellen Sie sich Helm als apt oder brew für Kubernetes vor.

Schlüsselkonzepte

Installation

# macOS
brew install helm

# Linux
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

Installation überprüfen:

helm version

Ein Chart-Repository hinzufügen

Fügen Sie das Bitnami-Repository hinzu – eine der beliebtesten Quellen für produktionsreife Charts:

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

Verfügbare Charts suchen:

helm search repo nginx

Ein Chart installieren

NGINX von Bitnami installieren:

helm install my-nginx bitnami/nginx

Das Format lautet helm install <release-name> <repo/chart>. Helm erstellt alle erforderlichen Kubernetes-Ressourcen und verfolgt den Release-Zustand.

Laufende Releases auflisten:

helm list

Mit Values anpassen

Jedes Chart bietet konfigurierbare Werte. Standardwerte anzeigen:

helm show values bitnami/nginx

Werte bei der Installation mit --set oder einer Values-Datei überschreiben:

# Direktes Überschreiben
helm install my-nginx bitnami/nginx --set replicaCount=2

# Dateibasiertes Überschreiben
helm install my-nginx bitnami/nginx -f custom-values.yaml

Beispiel custom-values.yaml:

replicaCount: 2
service:
  type: ClusterIP
resources:
  requests:
    cpu: 100m
    memory: 128Mi

Einen Release aktualisieren

Konfigurationsänderungen oder eine neue Chart-Version auf einen laufenden Release anwenden:

helm upgrade my-nginx bitnami/nginx --set replicaCount=3

Mit --install wird installiert, falls noch nicht vorhanden (Upsert-Muster):

helm upgrade --install my-nginx bitnami/nginx -f custom-values.yaml

Zurückrollen

Bei Problemen können Sie zu einer früheren Revision zurückrollen:

# Revisionsverlauf anzeigen
helm history my-nginx

# Zu Revision 1 zurückrollen
helm rollback my-nginx 1

Einen Release deinstallieren

helm uninstall my-nginx

Dadurch werden alle mit dem Release verbundenen Kubernetes-Ressourcen entfernt. Fügen Sie --keep-history hinzu, wenn Sie den Release-Eintrag für Audits behalten möchten.

Ein eigenes Chart erstellen

Chart-Gerüst generieren:

helm create my-app

Dies erzeugt das Standard-Verzeichnis-Layout:

my-app/
├── Chart.yaml        # Chart-Metadaten (Name, Version, Beschreibung)
├── values.yaml       # Standard-Konfigurationswerte
└── templates/        # Kubernetes-Manifest-Vorlagen
    ├── deployment.yaml
    ├── service.yaml
    └── _helpers.tpl  # Wiederverwendbare Template-Schnipsel

Wenn Sie mich unterstützen möchten, kaufen Sie mir einen Kaffee.

ArgoCD ist ein deklaratives, GitOps-basiertes Continuous-Delivery-Tool für Kubernetes. Es automatisiert den Anwendungs-Deployment, indem es den in einem Git-Repository definierten Sollzustand kontinuierlich mit dem Kubernetes-Cluster synchronisiert – das Git-Repository wird zur einzigen Quelle der Wahrheit.

Voraussetzungen

• Ein laufender Kubernetes-Cluster (oder kind für lokale Tests)
• kubectl konfiguriert für den Cluster-Zugriff
• Ein Git-Repository mit Kubernetes-Manifesten

ArgoCD installieren

Erstellen Sie den ArgoCD-Namespace und wenden Sie das offizielle Installationsmanifest an:

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Warten Sie, bis alle Pods bereit sind:

kubectl wait --for=condition=Ready pod --all -n argocd --timeout=120s

Zugriff auf die ArgoCD-Oberfläche

Standardmäßig ist der ArgoCD-Server nicht extern erreichbar. Verwenden Sie Port-Forwarding für den lokalen Zugriff:

kubectl port-forward svc/argocd-server -n argocd 8080:443

Öffnen Sie https://localhost:8080 in Ihrem Browser und rufen Sie das initiale Admin-Passwort ab:

kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath="{.data.password}" | base64 -d

Melden Sie sich mit dem Benutzer admin und dem abgerufenen Passwort an.

ArgoCD CLI installieren

# macOS
brew install argocd

# Linux
curl -sSL -o argocd https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64
chmod +x argocd && sudo mv argocd /usr/local/bin/

CLI authentifizieren:

argocd login localhost:8080 --username admin --password <ihr-passwort> --insecure

Erste Anwendung deployen

Erstellen Sie eine Anwendung, die auf das offizielle ArgoCD-Beispiel-Repository zeigt:

argocd app create guestbook \
  --repo https://github.com/argoproj/argocd-example-apps.git \
  --path guestbook \
  --dest-server https://kubernetes.default.svc \
  --dest-namespace default

Lösen Sie die erste Synchronisierung aus:

argocd app sync guestbook

Status überprüfen:

argocd app get guestbook

Automatische Synchronisierung aktivieren

Standardmäßig wendet ArgoCD Änderungen aus Git nicht automatisch an. Aktivieren Sie Auto-Sync mit Self-Healing, damit der Cluster immer den Repository-Zustand widerspiegelt:

argocd app set guestbook --sync-policy automated --self-heal --auto-prune

Mit --auto-prune werden Ressourcen, die aus Git entfernt wurden, auch aus dem Cluster gelöscht.

ArgoCD aktualisieren

Wenden Sie das Installationsmanifest der Zielversion an:

kubectl apply -n argocd \
  -f https://raw.githubusercontent.com/argoproj/argo-cd/<neue-version>/manifests/install.yaml

Die neueste Version finden Sie auf der Releases-Seite. Wenden Sie nach einem Upgrade individuelle ConfigMaps (argocd-cm) erneut an, um Ihre Konfiguration beizubehalten.

Wenn Sie mich unterstützen möchten, kaufen Sie mir einen Kaffee.

Vor Kurzem wechselte ich meinen Internetanbieter zu Telekom, da ich mit meinem vorherigen Anbieter Probleme hatte. Nach dem Wechsel und der ersten Begutachtung des Telekom Speedport Smart 4 waren die Konfigurationsmöglichkeiten vielversprechend – sogar WireGuard, Mesh-Netzwerk und vieles mehr war enthalten. Zunächst lief alles gut, bis ich merkwürdige Probleme feststellte: Auf Mobiltelefonen brach die Verbindung manchmal plötzlich ab, Videoanrufe funktionierten ebenfalls nicht – sie liefen ein paar Minuten und brachen dann zusammen.

Nach der Fehlersuche schien es, als ob der Router schlicht nicht mit allen verbundenen Geräten zurechtkam. Ich hatte den Eindruck, dass Mobilverbindungen standardmäßig eingeschränkt wurden. Das alles war sehr seltsam, da ich zu Hause nicht besonders viele Geräte im Netzwerk habe.

Aufgrund all dieser Probleme entschied ich mich, meinen bewährten ASUS RT-AC86U Router zu verwenden. Hier erkläre ich, wie man den Speedport Smart 4 in den Bridge-Modus (DSL-Modem) versetzt und ihn mit dem ASUS Router zum Laufen bringt.

Hinweis: Der ASUS Router unterstützt keine Telefonie. Da ich kein Festnetztelefon nutze, ist das für mich nicht relevant.

Telekom-Verbindungseinstellungen

Stellen Sie vor der Aktivierung des Bridge-Modus sicher, dass Sie Ihre Telekom-Zugangsdaten zur Hand haben, um später Ihren ASUS Router damit zu konfigurieren.

Der Benutzername setzt sich aus Anschlußkennung, Zugangsnummer und Mitbenutzer zusammen, zum Beispiel:

Anschlußkennung: 00112233445566
Zugangsnummer: 551122334455
Mitbenutzer: 0001

Benutzername: 001122334455665511223344550001@t-online.de

Falls Ihre Zugangsnummer nur 11 Stellen hat, fügen Sie ein #-Symbol ein:

Anschlußkennung: 00112233445566
Zugangsnummer: 55112233445
Mitbenutzer: 0001

Benutzername: 0011223344556655112233445#0001@t-online.de

Speedport in den DSL-Modus versetzen

Öffnen Sie die Speedport-Einstellungen und aktivieren Sie den DSL-Modem-Modus. Das Gerät fordert Sie auf, die aktuelle Konfiguration zu speichern, da der Router-Modus nur über einen Werksreset deaktiviert werden kann. Nach dem Speichern aktivieren Sie den DSL-Modus und warten, bis der Speedport neu gestartet ist.

ASUS Router konfigurieren

Wählen Sie PPPoE als Verbindungstyp und geben Sie Ihren Benutzernamen und Ihr Passwort ein. Damit die Verbindung funktioniert, muss die PPPoE-Verbindung mit VLAN7 getaggt werden. Gehen Sie dazu zu LAN > IPTV und wählen Sie unter ISP-Profil Manuelle Einstellung.

Übernehmen Sie die Änderungen und überprüfen Sie, ob Sie eine WAN-IP von Telekom erhalten haben.

Velero ist ein Open-Source-Tool zur Erstellung von Backups Ihrer Kubernetes-Cluster – einschließlich Ihrer Kubernetes-Volumes! Velero funktioniert, indem es die Kubernetes API nach den gewünschten Manifests fragt, ohne direkten Zugriff auf die etcd-Datenbank zu benötigen. Das ist besonders nützlich bei verwalteten Kubernetes-Clustern wie AWS, GCP oder Digital Ocean, bei denen kein direkter Zugang zu den Master-Nodes besteht.

Wie im Diagramm dargestellt, erstellt der Benutzer eine Velero-Backup-Ressource. Der auf dem Cluster installierte Velero-Controller fragt daraufhin die Kubernetes API ab und führt das Backup der gewünschten Ressourcen durch. Die Backup-Daten können dann in einen S3-Bucket oder einen anderen Backup-Speicherort hochgeladen werden.

Das Wiederherstellen aus einem Backup funktioniert ähnlich. Wenn der Benutzer eine Restore-Ressource erstellt, lädt der Velero-Controller die Backup-Daten herunter und stellt sie im Cluster wieder her. Velero führt eine nicht-destruktive Wiederherstellung durch – bestehende Ressourcen im Cluster werden nicht gelöscht, sondern übersprungen.

Mehr Informationen zur Funktionsweise von Velero finden Sie hier.

Voraussetzungen

Vor der Nutzung von Velero benötigen wir:

1. Einen eigenen Kubernetes-Cluster – für Testzwecke eignet sich Kind.
2. Einen S3-Bucket zur Speicherung der Backups. Hier verwenden wir MinIO.
3. Den Velero-Client. Dies ist meiner Meinung nach der einfachste Weg, Backups mit Velero zu installieren, zu erstellen und wiederherzustellen.

MinIO

Dieses einfache docker-compose-Setup startet MinIO. Kopieren Sie die Datei und führen Sie docker-compose up aus:

# docker-compose.yaml
version: '3'

services:
  minio:
    image: quay.io/minio/minio:latest
    command: server /data --console-address ":9001"
    environment:
      - MINIO_ROOT_USER=admin
      - MINIO_ROOT_PASSWORD=password
    ports:
      - "9001:9001"
      - "9000:9000"
    volumes:
      - /data

Öffnen Sie http://localhost:9001, melden Sie sich mit admin/password an und erstellen Sie einen Bucket namens velero-backups.

Velero-Client

Laden Sie die neueste Version herunter und entpacken Sie sie:

tar -xvf <RELEASE-TARBALL-NAME>.tar.gz

Verschieben Sie das velero-Binary in Ihren bin-Ordner (/usr/local/bin) oder fügen Sie es Ihrem $PATH hinzu.

Velero im Cluster installieren

Die Standardinstallation von Velero erfordert einen Speicherort. Da wir MinIO verwenden, erstellen Sie zunächst eine Datei namens credentials-velero mit den MinIO-Zugangsdaten:

# credentials-velero
[default]
aws_access_key_id = admin
aws_secret_access_key = password

HINWEIS: In der Cloud müssen Sie einen echten accessKey und secretKey mit den richtigen Berechtigungen verwenden. Je nach Cloud-Anbieter gibt es eine Liste unterstützter Provider hier. Da MinIO mit AWS S3 kompatibel ist, verwenden wir das Velero-Plugin für AWS.

Installieren Sie Velero mit Provider, Plugin, Secret-Datei und Backup-Speicherkonfiguration:

velero install --provider aws --bucket velero-backups --plugins velero/velero-plugin-for-aws:v1.4.1 --secret-file ./credentials-velero --use-volume-snapshots=false --backup-location-config region=minio,s3ForcePathStyle="true",s3Url=http://localhost:9000 --use-restic

Dadurch wird der Velero-Controller im Namespace velero installiert. In diesem Beispiel verwenden wir auch die restic-Integration, die Backups von Volumes ermöglicht.

TIPP: Velero kann auch Snapshots von Volumes erstellen, wenn ein unterstützter Cloud-Anbieter verwendet wird – in diesem Fall ist die restic-Integration nicht erforderlich.

Ein Backup erstellen

Mit dem Velero-Client können verschiedene Arten von Backups erstellt werden. Am schnellsten geht es mit Namespace-basierten Backups:

velero backup create <Backup-Name> --include-namespaces <namespace1,namespace2,...,namespaceN>

Standardmäßig werden Volumes nicht gesichert. Dazu muss die Annotation backup.velero.io/backup-volumes=<volume-name> an den Pods hinzugefügt werden, an denen ein Volume eingehängt ist.

Beispiel: Ein RabbitMQ-Pod mit einem Volume:

apiVersion: v1
kind: Pod
metadata:
  annotations:
    backup.velero.io/backup-volumes: persistence
  labels:
    app.kubernetes.io/component: rabbitmq
  name: rabbitmq-server-0
****
  volumes:
    - name: persistence
      persistentVolumeClaim:
        claimName: persistence-rabbitmq-server-0

In diesem Fall müsste die Annotation wie folgt gesetzt werden: kubectl annotate pod rabbitmq-server-0 backup.velero.io/backup-volumes=persistence.

Backup-Zeitpläne

Es ist auch möglich, wiederkehrende Backups über Zeitpläne einzurichten. Im folgenden Beispiel wird jeden Samstag um 23:00 Uhr ein Backup für bestimmte Namespaces erstellt, mit einer Aufbewahrungszeit von 21 Tagen. Backups, die älter als 21 Tage sind, werden automatisch aus dem Speicherort und der Backup-Liste im Cluster entfernt.

velero schedule create sat-23uhr --schedule="0 23 * * 6" --ttl "504h" --include-namespaces namespace1,namespace2,namespace3

Nach dem Einrichten des Zeitplans können Sie die erstellten Backups anzeigen:

velero backup get

Um Informationen zum erstellten Zeitplan abzurufen:

velero schedule get

Ein Backup wiederherstellen

So stellen Sie ein Backup wieder her:

velero restore create --from-backup <backup-name>

Um vorhandene Backups aufzulisten:

velero backups get

Wenn Sie mich unterstützen möchten, kaufen Sie mir einen Kaffee.