Homelab - Talos Kubernetes

Kubernetes gibt es mittlerweile in vielen Varianten. Ich hatte mich zu erst an das c’T Open Source Team-Container Projekt erinnert, dann nur mit dem verwendeten k3s gestetet und bin zu erst einmal gescheitert.

Nach etwas Überlegung und Recherche bin ich auf Talos gestoßen, dass mir wegen der Sicherheit und Minimalismus sehr gut gefällt.

Der Aufbau eines Kubernetes Clusters stand an - und der geht erstaunlich schnell - mit den richtigen Tools und Talos.

Eines der Themen, um das man sich bei einem Kubernetes Cluster Gedanken machen muss, ist der Datenspeicher - dieser muss allen Worker Nodes zur Verfügung stehen. Es gibt dafür einige Lösungen - es sei hier nur ISCSI und Lognhorn genannt - es gibt aber durchaus weitere Lösungen (oft mit ISCSI).

Die Reise hat für mich aber erst begonnen und Talos hat so die ein oder andere Besonderheit, da es stark auf Sicherheit setzt.

Warum Talos

Talos ist…

  • Verteilt
    • Talos ist für hochverfügbare, verteilte Umgebungen ohne Single Point of Failure ausgelegt.
  • Unveränderlich
    • Talos läuft aus einem unveränderlichen, signierten Image und vermeidet dauerhafte Schreibzugriffe.
  • Minimal
    • Talos enthält nur absolut notwendige Komponenten und bleibt dadurch extrem schlank.
  • Ephemer
    • Alle Daten auf der Festplatte sind vergänglich, replizierbar oder rekonstruierbar.
  • Sicher
    • Talos setzt auf strikte Sicherheit durch Minimalismus, starke Kryptografie und kurzlebige Zertifikate.
  • Deklarativ
    • Talos wird vollständig über eine einzige deklarative YAML-Konfiguration gesteuert.

Mein redundanter Cluster

Grundsätzlich sollte man besser drei Controlplane Nodes haben (3 Verwaltungsserver) - dabei genügen 2 CPUs und 6 GB RAM mit 10GB Datenträger für den Anfang.

Mit Lonhorn könnte man minimal zwei Worker verwenden - ich habe mich aber für vier Worker Nodes mit 4 CPU, 8 GB RAM und 200 GB Datenträgern entschieden.

Als StorageClass/Datenspeicher habe ich mich für Longhorn entschieden, wodurch ich per ISCSI redundanten Speicher für die Pods bereitstellen kann. Der Aubau richtet sich nach Controlplane (Longhorn Manger) und Worker (Lognhorn Worker).

Der Cluster sieht also so aus:

  • 3x Controll Plane
    • 4 GB RAM
    • 10 GB Disk
  • 4x Worker
    • 8 GB RAM
    • 200 GB Disk
flowchart TD
  subgraph K8S[Talos Kubernetes]
    subgraph CP[Controllplane]
      CP1
      CP2
      CP3
    end
    subgraph WK[Worker]
      WK1
      WK2
      WK3
      WK4
    end
    CP-->WK
  end

Talos Anpassungen

Alle Talos VMs wurden mit der der Talos Linux Image Factory um die folgenden Pakete für Longhorn erweitert:

  • siderolabs/iscsi-tools
  • siderolabs/util-linux-tools

Das ist der Talos spezifische Code mit URL:

613e1592b2da41ae5e265e8789429f22e121aab91cb4deb6bc3c0b6262961245

Controlplane

Die Controllplane führt Kubernetes spezifisch die folgenden Dienste aus:

  • API Server
  • Controller-Manager (ETCD)
  • Kubelet
  • Scheduler

StorageClass Longhorn

Die StorageClass Longhorn hat die folgenden Vorteile:

  • Web basierte GUI
  • Integrierte Backup und Restore Lösung
  • Hohe Verfügbarkeit - auch bei Updates
  • Einfache Backups auf S3 (in meinem Fall Minio auf einen TrueNAS) Speicher
  • Aufbau
    • 3x Controlplane (Longhorn Manager)
    • 4x Workload (Longhorn Worker)
flowchart LR
  subgraph K8S[Talos Kubernetes]
    subgraph CP[Longhorn Manager]
      CP1
      CP2
      CP3
    end
    subgraph ISCSI[Longhorn ISCSI]
      subgraph WK[Longhorn Storage]
        WK1
        WK2
        WK3
        WK4
      end
    end
    subgraph POD[Kuvbernetes PODs]
      POD1
      POD2
      POD3
    end
    POD1<-->ISCSI
    POD2<-->ISCSI
    POD3<-->ISCSI
    CP-->WK
  end

Traefik Ingress

Mein Ingress läuft mit Traefik traefik - das hat die folgenden Gründe:

  • Web GUI
  • Code basierte Konfiguration (git fähig)
  • Sehr gute Integration in Kubernetes

Der Ingress verwendet ein Letsencrypt Wildcard Zertifika, das über den cert-manager verwaltet wird. Die dafür notwendige Domain und DNS Auth Schnittstelle läuft über den kostenlosen Dienst DuckDNS.

external-dns aktualisiert die DNS Einträge in meinem Technitium Docker Container auf TrueNAS (vorher AdGuard Home), der meinen SpeedPort mit gefiltertem DNS versorgt. Siehe dazu DNS zu Hause und im Homelab

flowchart LR
  subgraph T[Kubernetes Umgebung]
    Talos{Talos}<-->EXT[external-dns]
    Talos<-->Traefik
    Talos<-->cert-manager
    cert-manager-->Traefik
    subgraph KOM[Ingress]
      Traefik<-->IA(Ingress A)
      Traefik<-->IB(Ingress B)
      Traefik<-->IC(Ingress C)
    end
  end
    EXT--interne DNS Updates-->TN
  subgraph INET[Internet basierte Dienste]
    cert-manager<-->DuckDNS
    cert-manager<-->Letsencrypt
  end
  subgraph Home
    NAS(TrueNAS)<-->TN{Technitium}
    SP(SpeedPort)
  end
  TN<--externe DNS Abragen-->CFD(CloudFlare und Google DNS)
  SP<--alle DNS Abfragen-->TN