Kubernetes Deployment: Bestehende Konfiguration nahtlos übernehmen

In diesem Blogpost zeige ich dir, wie du eine bestehende Home Assistant-Installation nahtlos von einem containerisierten Raspberry Pi-Setup in ein Azure Arc-fähiges Kubernetes-Cluster migrierst. Dabei bleibt die vorhandene Konfiguration vollständig erhalten, indem sie als ZIP-Datei eingebunden wird.

Mit dieser Methode kannst du:
✅ Home Assistant ohne Neukonfiguration starten
✅ Eine zentrale Verwaltung über Kubernetes nutzen
✅ Hybrid-Cloud-Deployments mit Azure Arc steuern

Falls du Basisthemen nachlesen möchtest:

Azure Arc: Die clevere Lösung für hybride IT-Infrastrukturen

Die Verwaltung hybrider und Multi-Cloud-Umgebungen kann schnell zu einer komplexen Herausforderung werden. Microsoft Azure Arc bietet eine Lösung, die dieses Problem effektiv adressiert. Mit Azure Arc können Ressourcen über verschiedene Umgebungen hinweg zentral verwaltet werden – sei es On-Premises, in Azure oder bei anderen Cloud-Anbietern. Gleichzeitig entfällt das lokale Management der

IoTim BlogTim Steiner

Kubernetes Cluster mit Azure Arc verbinden – Mein Erfahrungsbericht

Einleitung Die Verwaltung eines Kubernetes-Clusters kann eine Herausforderung sein, besonders wenn verschiedene Umgebungen ins Spiel kommen. Mit Azure Arc lässt sich dieser Prozess vereinfachen, indem es eine zentrale Verwaltungsplattform für hybride Kubernetes-Umgebungen bietet. In diesem Blogpost zeige ich, wie ich meinen Kubernetes-Cluster eingerichtet und mit Azure Arc verbunden habe. Ich

IoTim BlogTim Steiner

Azure IoT Operations mit Azure Arc – Ein umfassender Überblick

Einleitung Die Verwaltung und Skalierung von IoT-Geräten stellt viele Unternehmen vor große Herausforderungen. Besonders in hybriden und verteilten Umgebungen kann es schwierig sein, IoT-Geräte und Edge-Deployments effizient zu steuern. Azure IoT Operations (AIO) bietet hier eine umfassende Lösung, indem es eine einheitliche Verwaltungsplattform für vernetzte IoT-Umgebungen bereitstellt. Wer von Azure

IoTim BlogTim Steiner

🔹 Voraussetzungen

Bevor du startest, sollten folgende Anforderungen erfüllt sein:

✔ Azure Arc-fähiges Kubernetes-Cluster – Ein eingerichtetes und mit Azure Arc verbundenes Cluster.
✔ Gesicherte Home Assistant-Konfiguration – Eine aktuelle Sicherung deiner Home Assistant-Einstellungen als ZIP-Datei.
✔ Azure Container Registry (optional) – Falls eigene Docker-Images verwendet werden sollen.
✔ Installierte Tools – kubectl und helm sollten installiert und konfiguriert sein.

📌 Tipp: Es ist hilfreich, wenn du dich mit den Grundlagen von Kubernetes Storage und Volumes vertraut machst.

🔹 Schritt 1: Kubernetes Namespace erstellen

Ein Namespace isoliert deine Anwendung und erleichtert die Verwaltung.

🚀 Befehl zur Erstellung

kubectl create namespace demo-deployment

✅ Vorteile eines Namespaces

• Saubere Trennung von Ressourcen
• Mehr Sicherheit & bessere Organisation
• Ermöglicht Multi-Tenancy in Kubernetes

🔹 Schritt 2: Azure Storage Account anlegen

Damit deine Home Assistant-Konfiguration gespeichert werden kann, brauchst du einen Azure Storage Account mit einer Dateifreigabe.

📌 Storage Account erstellen

Führe folgenden Befehl aus, um einen neuen Storage Account anzulegen:

az storage account create --name <storageaccountname> --resource-group <resourcegroup> --location <region> --sku Standard_LRS

Ersetze <storageaccountname>, <resourcegroup> und <region> mit deinen eigenen Werten.

🔹 Dateifreigabe für Home Assistant anlegen:

Erstelle anschließend eine File Share für die Home Assistant-Konfiguration:

az storage share create --name homeassistant-config --account-name <storageaccountname>

🔹 ZIP-Datei mit der Home Assistant-Konfiguration hochladen:

az storage blob upload --account-name <storageaccountname> --container-name homeassistant-config --file homeassistant-config.zip --name ha.zip

📌 Sicherheitstipp: Speichere deine Storage-Account-Zugangsdaten sicher, z. B. mit Azure Key Vault.

🔹 Schritt 3: Kubernetes Secret für den Storage-Zugriff erstellen

Da Kubernetes keinen direkten Zugriff auf Azure File Shares hat, musst du ein Secret erstellen, das die Zugangsdaten deines Storage Accounts speichert. Dieses Secret wird anschließend von den Pods verwendet, um eine Verbindung zur Dateifreigabe herzustellen.

📌 Secret erstellen

kubectl create secret generic demo-fs-secret --namespace demo-deployment
--from-literal=azurestorageaccountname=<storageaccountname>
--from-literal=azurestorageaccountkey=<storageaccountkey>

Ersetze <storageaccountname> und <storageaccountkey> durch die Zugangsdaten deines Storage Accounts.

📢 Wichtig: Vermeide es, Zugangsdaten im Klartext in YAML-Dateien zu speichern! Nutze Secrets oder Azure Key Vault.

🔹 Schritt 4: Azure File CSI Driver installieren

Damit Kubernetes auf Azure File Shares zugreifen kann, musst du den Azure File CSI Driver installieren. Dieser Treiber ermöglicht die nahtlose Integration von Azure Files als Storage in Kubernetes.

🚀 Installation des Azure File CSI Drivers

Führe folgenden Befehl aus, um den Treiber zu installieren:

curl -skSL https://raw.githubusercontent.com/kubernetes-sigs/azurefile-csi-driver/v1.31.2/deploy/install-driver.sh | bash -s v1.31.2 --

Weitere Informationen

Ausführliche Details zur Installation und Konfiguration findest du in der offiziellen Dokumentation des Azure File CSI Drivers.

🔹 Schritt 5: Storage Class erstellen

Eine Storage Class definiert, wie Kubernetes Speicher dynamisch bereitstellt und verwaltet. Sie ermöglicht es, dass Persistent Volume Claims (PVCs) automatisch ein Persistent Volume (PV) anfordern, ohne dass ein Administrator dies manuell erstellen muss.

In diesem Beispiel legen wir eine Storage Class für Azure File Storage an, die den Container Storage Interface (CSI) Treiber von Azure verwendet.

📌 Storage Class YAML-Datei (azurefile-storageclass.yaml)

Speichere die folgende Konfiguration in einer Datei, z. B. azurefile-storageclass.yaml:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile  # Name der Storage Class, die in PVCs verwendet wird
provisioner: file.csi.azure.com  # CSI Treiber für Azure Files
parameters:
  skuName: Standard_LRS  # Storage-Tier (Standard_LRS, Premium_LRS)
allowVolumeExpansion: true  # Erlaubt das Erweitern bestehender PVCs
reclaimPolicy: Retain  # Speicher bleibt bestehen, auch wenn PVC gelöscht wird
volumeBindingMode: Immediate  # PV wird sofort beim Erstellen des PVCs gebunden

🔹 Erstellen mit:

kubectl apply -f azurefile-storageclass.yaml

Parameter der Storage Class erklärt

🔹 Schritt 6: Persistent Volume (PV) & Persistent Volume Claim (PVC) erstellen

In Kubernetes werden Persistent Volumes (PV) und Persistent Volume Claims (PVC) genutzt, um Speicherressourcen effizient zu verwalten:

• Persistent Volume (PV) stellt eine Speicherressource bereit.
• Persistent Volume Claim (PVC) fordert diesen Speicher an und macht ihn für Pods nutzbar.

In diesem Beispiel verwenden wir Azure File Storage als Storage-Backend.

Persistent Volume (PV) erstellen

Das PV wird manuell definiert und legt fest, wie viel Speicherplatz verfügbar ist und unter welchen Bedingungen er genutzt werden kann.

📌 PV YAML-Datei (azurefile-pv.yaml)

apiVersion: v1
kind: PersistentVolume
metadata:
  name: azurefile-pv
spec:
  capacity:
    storage: 5Gi  # Größe des Speicherplatzes
  accessModes:
    - ReadWriteMany  # Ermöglicht gleichzeitigen Lese-/Schreibzugriff für mehrere Pods
  persistentVolumeReclaimPolicy: Retain  # PV bleibt nach PVC-Löschung erhalten
  storageClassName: azurefile
  azureFile:
    secretName: demo-fs-secret  # Geheimnis für die Authentifizierung mit Azure Storage
    shareName: demo-fs  # Name des Azure File Shares
    readOnly: false  # Lese- und Schreibzugriff erlauben

📌 PV in Kubernetes erstellen

kubectl apply -f azurefile-pv.yaml

Persistent Volume Claim (PVC) erstellen

Ein PVC wird von Anwendungen genutzt, um Speicher anzufordern. Kubernetes sucht automatisch nach einem passenden PV.

📌 PVC YAML-Datei (azurefile-pvc.yaml)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: azurefile-pvc
spec:
  accessModes:
    - ReadWriteMany  # Mehrere Pods können gleichzeitig darauf zugreifen
  resources:
    requests:
      storage: 5Gi  # Speicherplatzanforderung
  storageClassName: azurefile  # Stellt sicher, dass das richtige PV gebunden wird

📌 PVC in Kubernetes erstellen

kubectl apply -f azurefile-pvc.yaml

Zusätzliche Hinweise

• Access Modes:
  • ReadWriteOnce (RWO): Ein Node kann lesen & schreiben.
  • ReadOnlyMany (ROX): Mehrere Nodes können nur lesen.
  • ReadWriteMany (RWX): Mehrere Nodes können lesen & schreiben.
  • Azure Files unterstützt nur RWX!
• Speicherverwaltung:
  • Retain: Das PV bleibt erhalten, auch wenn das PVC gelöscht wird.
  • Recycle: Das PV wird bereinigt und wiederverwendet.
  • Delete: Das PV wird zusammen mit dem Speicher gelöscht.

Mit diesem Setup bleibt der Speicher auch nach einem Deployment-Neustart erhalten und kann von mehreren Pods gleichzeitig genutzt werden. 🚀

🔹 Schritt 7: Service für den Zugriff auf Home Assistant

Ein Kubernetes Service stellt sicher, dass Home Assistant sowohl innerhalb als auch außerhalb des Clusters erreichbar ist. Der Service leitet Anfragen zuverlässig an die entsprechenden Pods weiter.

Es gibt verschiedene Service-Typen in Kubernetes:

1. ClusterIP (Standard) – Der Service ist nur innerhalb des Clusters erreichbar.
2. NodePort – Der Service ist über die IP eines Nodes und einen festgelegten Port (zwischen 30000-32767) erreichbar.
3. LoadBalancer – Wenn Kubernetes in einer Cloud (z. B. Azure, AWS) läuft, wird ein externer Load Balancer erstellt.
4. Ingress – Ermöglicht Routing per Domänennamen und TLS-Zertifikaten (empfohlen für Produktivumgebungen).

📌 NodePort Service (Für lokale Cluster)

Falls dein Cluster ohne Cloud Load Balancer betrieben wird, kannst du den NodePort-Modus verwenden. Dabei ist der Service über die IP eines beliebigen Cluster-Nodes erreichbar.

NodePort-Service Konfigurationsdatei (homeassistant-service-nodeport.yaml)

apiVersion: v1
kind: Service
metadata:
  name: homeassistant-service
  namespace: demo-deployment
spec:
  selector:
    app: homeassistant
  type: NodePort  # Zugriff über eine beliebige Node-IP
  ports:
    - protocol: TCP
      port: 8123       # Port innerhalb des Clusters
      targetPort: 8123 # Port im Container
      nodePort: 30123  # Externer Zugriff (muss zwischen 30000-32767 liegen)

📌 Service in Kubernetes erstellen

kubectl apply -f homeassistant-service-nodeport.yaml

Zugriff auf Home Assistant über die Node-IP

http://<NODE_IP>:30123

Um die Node-IP zu ermitteln, kannst du folgenden Befehl verwenden:

kubectl get nodes -o wide

📌 LoadBalancer Service (Für Cluster in der Cloud)

Falls dein Cluster in einer Cloud-Umgebung läuft (z. B. Azure Kubernetes Service, AWS EKS, Google Kubernetes Engine), kannst du einen LoadBalancer-Service nutzen. Kubernetes erstellt dann automatisch einen externen Load Balancer und stellt den Dienst unter einer öffentlichen IP bereit.

LoadBalancer-Service Konfigurationsdatei (homeassistant-service-loadbalancer.yaml)

apiVersion: v1
kind: Service
metadata:
  name: homeassistant-service
  namespace: demo-deployment
spec:
  selector:
    app: homeassistant
  type: LoadBalancer  # Externer Zugriff über Cloud Load Balancer
  ports:
    - protocol: TCP
      port: 8123
      targetPort: 8123

📌 Service in Kubernetes erstellen

kubectl apply -f homeassistant-service-loadbalancer.yaml

Externe IP-Adresse ermitteln

kubectl get service homeassistant-service -n demo-deployment

Die Ausgabe sieht in etwa so aus:

NAME                     TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)        
homeassistant-service   LoadBalancer   10.0.171.239   40.112.45.23   8123:31234/TCP

Home Assistant ist dann unter http://40.112.45.23:8123 erreichbar.

Hinweis: Falls die EXTERNAL-IP mit <pending> angezeigt wird, läuft die Bereitstellung des Load Balancers noch.

📌 Ingress Controller (Empfohlen für Produktionsumgebungen)

Ein Ingress Controller bietet eine elegantere Möglichkeit, Home Assistant über eine Domain (z. B. homeassistant.example.com) erreichbar zu machen. Zudem ermöglicht er TLS/SSL-Verschlüsselung mit Let's Encrypt.

Falls du Ingress verwendest, kannst du Home Assistant mit einer Ingress-Definition veröffentlichen.

Ingress-Konfigurationsdatei (homeassistant-ingress.yaml)

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: homeassistant-ingress
  namespace: demo-deployment
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"  # Automatisches SSL mit Let's Encrypt
spec:
  ingressClassName: nginx
  rules:
    - host: homeassistant.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: homeassistant-service
                port:
                  number: 8123
  tls:
    - hosts:
        - homeassistant.example.com
      secretName: homeassistant-tls

Damit Ingress funktioniert, benötigst du:

✅ Einen Ingress-Controller (z. B. NGINX Ingress).
✅ Eine Domain (homeassistant.example.com), die auf die Load Balancer IP zeigt.
✅ Einen cert-manager, falls TLS-Zertifikate automatisch ausgestellt werden sollen.

Zusammenfassung der Service-Typen

Mit dieser Konfiguration ist sichergestellt, dass Home Assistant sowohl intern als auch extern zuverlässig erreichbar ist – egal ob dein Cluster lokal, in der Cloud oder in einer Produktionsumgebung läuft. 🚀

🔹 Schritt 8: Deployment von Home Assistant in Kubernetes

Ein Deployment stellt sicher, dass Home Assistant immer mit der gewünschten Anzahl an Instanzen läuft und automatisch neu gestartet wird, falls ein Pod ausfällt. Zudem gewährleistet es eine konsistente Bereitstellung der Konfiguration.

📌Deployment Definition

Die folgende Deployment-Konfiguration nutzt:
✅ Init-Container, um Home Assistant-Dateien zu entpacken, bevor der Hauptcontainer startet.
✅ Persistent Volume Claims (PVC), um Konfigurationsdaten dauerhaft zu speichern.
✅ Secrets, falls das Image aus einer privaten Azure Container Registry (ACR) bezogen wird.

Deployment YAML-Datei (homeassistant-deployment.yaml)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: homeassistant
  namespace: demo-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: homeassistant
  template:
    metadata:
      labels:
        app: homeassistant
    spec:
      initContainers:
      - name: homeassistant-unzip-files
        image: alpine:3.16
        command: ["/bin/sh", "-c"]
        args:
          - |
            echo "Start unzip..."
            if [ -d "/storage/home_assistant" ]; then
              echo "Directory exists, delete and unzip again..."
              rm -rf /storage/home_assistant
            fi
            echo "Check if ZIP file exists..."
            if [ ! -f /storage/ha.zip ]; then
              echo "ERROR: File /storage/ha.zip not found!"
              exit 1
            fi
            echo "Found ZIP. Unzipping..."
            mkdir -p /storage/home_assistant
            unzip -o /storage/ha.zip -d /storage/home_assistant || { echo "Error while unzipping!"; exit 1; }
            echo "Unzip complete!"
        volumeMounts:
        - name: storage-volume
          mountPath: /storage

      containers:
      - name: homeassistant-container
        image: timkubernetes.azurecr.io/apps/home-assistant:latest
        volumeMounts:
        - name: storage-volume
          mountPath: /config
          subPathExpr: home_assistant
      imagePullSecrets:
        - name: acr-secret

      volumes:
      - name: storage-volume
        persistentVolumeClaim:
          claimName: azurefile-pvc

📌Verbesserungen und zusätzliche Informationen

✅ Init-Container für die Dateiextraktion

🔹 Bevor Home Assistant startet, entpackt der Init-Container die Datei ha.zip in das Verzeichnis /storage/home_assistant.
🔹 Falls das Verzeichnis bereits existiert, wird es gelöscht und neu erstellt.
🔹 Falls ha.zip fehlt, schlägt das Deployment fehl.

✅ Storage-Anbindung

🔹 Das Persistent Volume Claim (PVC) sorgt dafür, dass Konfigurationsdaten dauerhaft gespeichert werden.
🔹 Home Assistant nutzt /config, um Einstellungen und Konfigurationsdateien zu speichern.

✅ ImagePullSecrets für private Container Registries

🔹 Falls das Docker-Image aus einer privaten Azure Container Registry (ACR) gezogen wird, ist ein Secret erforderlich (acr-secret).

📌Deployment ausführen

Nachdem alle YAML-Dateien erstellt wurden, kannst du sie mit folgenden Befehlen in Kubernetes anwenden:

kubectl apply -f namespace.yaml
kubectl apply -f storageclass.yaml
kubectl apply -f pv.yaml
kubectl apply -f pvc.yaml
kubectl apply -f deployment.yaml
kubectl apply -f service.yaml

📌Fehleranalyse & Debugging

Falls das Deployment fehlschlägt oder Home Assistant nicht wie erwartet funktioniert, helfen folgende Befehle bei der Fehlerdiagnose:

📌 Pod-Status überprüfen:

kubectl get pods -n demo-deployment

📌 Detaillierte Pod-Analyse (describe zeigt Events, Fehler, Neustarts):

kubectl describe pods -n demo-deployment

📌 Logs des Home Assistant Containers anzeigen:

kubectl logs -l app=homeassistant -n demo-deployment

📌 Logs eines spezifischen Containers anzeigen (z. B. homeassistant-unzip-files):

kubectl logs <POD_NAME> -c homeassistant-unzip-files -n demo-deployment

📌 Direkten Zugriff auf den Container für manuelle Tests erhalten:

kubectl exec -it <POD_NAME> -n demo-deployment -- /bin/sh

🔹 Zusammenfassung

✔ Automatische Verwaltung: Das Deployment sorgt für eine kontinuierliche Verfügbarkeit von Home Assistant.
✔ Dauerhafte Speicherung: Alle Konfigurationen werden in einem persistenten Volume gesichert.
✔ Health Checks: Liveness- und Readiness-Probes helfen, Ausfälle automatisch zu erkennen.
✔ Debugging & Skalierung: Mehrere Befehle erleichtern die Fehleranalyse und Anpassung der Instanzzahl.

Mit dieser Konfiguration läuft Home Assistant stabil und flexibel in Kubernetes – bereit für den produktiven Einsatz! 🚀

🔹 Fazit

Mit diesem Deployment wurde Home Assistant erfolgreich von einem Raspberry Pi in eine Kubernetes-Umgebung migriert. Die bestehende Konfiguration wird dabei automatisch entpackt und wiederverwendet, sodass alle gewohnten Funktionen erhalten bleiben. Dank Azure Arc lässt sich die Umgebung zentral verwalten und für hybride Cloud-Szenarien optimieren.

Die Migration in ein Azure Arc-fähiges Kubernetes-Cluster schafft die Grundlage für eine skalierbare, ausfallsichere und zentral verwaltete Smart-Home-Lösung. Kubernetes bietet dabei zahlreiche Vorteile:
✅ Automatische Wiederherstellung & Skalierung – Home Assistant bleibt jederzeit verfügbar.
✅ Zentrale Verwaltung & Sicherheit – Zugriffskontrolle und Updates lassen sich effizient steuern.
✅ Flexibilität für zukünftige Erweiterungen – Die Architektur ist offen für weitere Automatisierungen und Optimierungen.

🔹 Ausblick: Weiterentwicklung & Optimierung

Mit der aktuellen Kubernetes-Einrichtung eröffnen sich zahlreiche Möglichkeiten zur Weiterentwicklung deiner Home Assistant-Umgebung:

1️⃣ Automatisierung & Skalierung

🔹 Nutze Horizontal Pod Autoscaling (HPA), um die Leistung von Home Assistant dynamisch an steigende Anforderungen anzupassen.
🔹 Implementiere GitOps-Workflows (z. B. mit FluxCD oder ArgoCD), um Konfigurationsänderungen automatisch und versionskontrolliert auszurollen.

2️⃣ Monitoring & Logging

🔹 Prometheus & Grafana ermöglichen eine umfassende Überwachung der Anwendung und ihrer Ressourcen.
🔹 Ein ELK-Stack (Elasticsearch, Logstash, Kibana) sorgt für effizientes Logging und die detaillierte Analyse von Systemereignissen.

3️⃣ Sicherheit & Zugriffskontrolle

🔹 Setze Netzwerkrichtlinien und rollenbasierte Zugriffskontrolle (RBAC) ein, um den Zugriff auf Home Assistant gezielt zu steuern.
🔹 Regelmäßige Sicherheits-Scans der Container-Images helfen, Schwachstellen frühzeitig zu erkennen und zu beheben.

4️⃣ CI/CD-Integration für automatisierte Updates

🔹 Erstelle eine CI/CD-Pipeline mit GitHub Actions, Jenkins oder Azure DevOps, um Updates und Konfigurationsänderungen automatisiert bereitzustellen.
🔹 Nutze Canary Releases oder Blue-Green Deployments, um neue Versionen risikofrei zu testen.

🔹 Schlussgedanke

Durch diese Erweiterungen kannst du die Effizienz, Sicherheit und Wartbarkeit deiner Home Assistant-Installation weiter steigern. Dein Smart-Home-System wird skalierbarer, flexibler und zukunftssicher, während Kubernetes die Verwaltung und Automatisierung auf ein neues Level hebt. 🚀

🔹 Links

Create a persistent volume with Azure Files in Azure Kubernetes Service (AKS) - Azure Kubernetes Service

Learn how to create a static or dynamic persistent volume with Azure Files for use with multiple concurrent pods in Azure Kubernetes Service (AKS)

Microsoft Learnschaffererin

azurefile-csi-driver/docs/install-csi-driver-v1.31.2.md at master · kubernetes-sigs/azurefile-csi-driver

Azure File CSI Driver. Contribute to kubernetes-sigs/azurefile-csi-driver development by creating an account on GitHub.

GitHubkubernetes-sigs