k3k: agent-less k3s in Kubernetes

Zusammenfassung in drei Punkten

• Controlplane on demand: Mit k3k lässt sich eine vollwertige k3s-Controlplane als Kubernetes-Workload betreiben – ohne Agent-Knoten. Das ermöglicht blitzschnelles Spin-up/Down kompletter, valider k3s-Cluster für Tests, Mandanten oder Edge-Szenarien. (Hintergrund: agent-less servers sind ein Feature von k3s bei dem die Controlplane keine normale Node im Cluster ist, wie sonst üblich) 
• On-Prem turbo: Wo das Bereitstellen vollständiger VMs für jede Controlplane Stunden/Tage dauern kann, erzeugt k3k in Minuten reproduzierbare Umgebungen – ideal für End-to-End-Tests in CI, Multi-Tenant-K3s-Setups, Dev-Cluster und ressourcenlimitiertes Edge.
• Kompatibel & offen: k3s ist ein leichtgewichtiges, CNCF-konformes Kubernetes mit ARM-Support; Helm bleibt der gewohnte Paketmanager. k3k nutzt das – mit Helm-Install, deklarativ, GitOps-freundlich. 

k3k auf GitHub

Warum überhaupt „Kubernetes in Kubernetes"?

Zwei Motive dominieren: Tempo und Dichte.

1. Tempo: In Rechenzentren mit klassischer VM-Bereitstellung sind Controlplane-Rollouts schwergewichtig: IaaS-Tickets, Netzsegmentierung, Firewalls, Load-Balancer-Konfiguration, Images härten, Patches einplanen, etc. Selbst mit guter Automatisierung bleiben viele bewegliche Teile. \nEine Controlplane als Pod-Set im bestehenden Management-Cluster reduziert diese Strecke auf „Chart installieren → CR anlegen → fertig". Für CI-Pipelines (Feature-Branches, E2E-Tests, reproduzierbare Benchmarks) ist das ein Game Changer.
2. Dichte: Mehrere vollwertige k3s-Cluster nebeneinander – ohne dedizierte Master-VMs – heben die Tenant-Dichte in Dev/Stage massiv. Jeder Cluster bekommt seinen eigenen API-Server, Controller-Manager und Datastore; der Overhead pro Controlplane sinkt. Das Prinzip ist nicht neu: Projekte wie Kamaji und Gardener hosten die Controlplane ebenfalls als Pods (Hosted Control Plane / Seed-Shoot), um viele Cluster skalierbar und kosteneffizient bereitzustellen. 

k3k implementiert diese Idee speziell für k3s – dem „leichtgewichtigen" Kubernetes, das sich als Single-Binary gut in Edge/IoT und Dev-Szenarien bewährt hat. 

Was bedeutet „agent-less" bei k3s – und warum ist das relevant?

k3s unterscheidet zwischen server (Controlplane) und agent (Node fürs Workload-Scheduling). Im agent-less Modus betreibt man nur den Server, ohne kubelet – dadurch taucht die Controlplane nicht als Worker-Node im Cluster auf. Genau das will man für eingebettete Controlplanes: saubere Trennung von „Steuerung" und „Workload". Das k3s-Projekt dokumentiert den agent-less-Betrieb explizit, inklusive Hinweisen (z. B. Netzwerk-/Egress-Selector-Modi, da ohne kube-proxy/flannel andere Pfade greifen). 

Vorteile:

• Sicherheit & Klarheit: Keine Applikationspods auf Controlplane-Knoten, keine seitliche Nutzung „aus Versehen".
• Schnelle Lebenszyklen: Controlplanes werden wie jede andere App gerollt/ersetzt (z. B. Blue/Green), ohne Worker-Scheduling zu tangieren.
• Ressourcen-Effizienz: Minimaler Footprint; k3s-Server ist schlank, Startzeiten sind kurz. 

Wichtig: Wer Workloads fahren will, fügt separate agent-Nodes (oder „shared Agents" innerhalb des Management-Clusters) hinzu. Das bleibt bewusst entkoppelt.

k3k im Überblick

Das von ayedo gepflegte k3k-Chart modelliert eine k3s-Controlplane in Kubernetes. In der „Kubernetes-in-Kubernetes"-Topologie entsteht pro gewünschtem Cluster eine isolierte Controlplane-Namespace mit den entsprechenden Pods (api-server, controller-manager, Datastore). Der Cluster-Lifecycle (erstellen, upgraden, löschen) lässt sich über Helm-Werte/CRDs automatisieren – attraktiv für CI, Multi-Tenant-Dev, Staging und kurzlebige Testumgebungen.

Zur Einordnung: Es gibt auch ein Rancher-Projekt k3k (Kubernetes in Kubernetes), das denselben Grundgedanken verfolgt (Controller + CLI, Helm-Deploy, CRD „clusters.k3k.io"). Das unterstreicht den generellen Architekturtrend, Controlplanes als Pods auszurollen, statt für jeden Cluster Master-VMs zu pflegen. 

Geschwindigkeits- und Innovationsvorteil – besonders On-Prem

On-Premises ist traditionell VM-getrieben. Wer für jeden Test-Cluster Master-VMs anfordert, handelt sich Lead-Times von Stunden bis Tagen ein (Change-Fenster, Storage-Zuweisung, Netzfreigaben, LB-Config, Security-Controls). Das bremst:

• Entwicklung/QA: Feature-Branches warten auf „repräsentative" Cluster.
• SRE/Platform: Aufwand für Pflege, Patching, Abbau „vergessener" Test-VMs.
• Innovation: Experimente mit API-Server-Flags, Versionen, Add-ons bleiben liegen.

k3k dreht das um: Helm-Install im Management-Cluster, Values setzen, CR anwenden – wenige Minuten später steht eine einsatzfähige k3s-Controlplane. Das ist nicht nur schneller, sondern reproduzierbar (GitOps, PR-basierte Reviews) und kosteneffizient, weil die Controlplanes Ressourcen der bestehenden Worker teilen. Für Edge-Projekte (ARM, wenig RAM/CPU) passt k3s ohnehin hervorragend. 

Typische Einsatzmuster

1. End-to-End-Tests in CI

   Für jeden PR wird ein frischer k3s-Cluster hochgezogen, Tests laufen realitätsnah gegen eine echte Controlplane. Nach Merge/Close wird der Cluster abgeräumt. Kein „YAML-Mocking" mehr – echte API-Semantik, echte Admission, echte Controllerwege.

2. Multi-Tenant-K3s

   Teams/Mandanten bekommen dedizierte k3s-Cluster statt Namespace-Isolation. Vorteile: klare Blast-Radius-Grenzen, individuelle API-Server-Policies, getrennte CRDs und Admission. Vollwertige Isolation, ohne für jeden Tenant neue Master-VMs.

3. Dev-Cluster

   Entwickler starten „ihren" k3s-Cluster on demand. Versionswechsel testen? API-Flags evaluieren? Add-ons vergleichen? Alles in Minuten – und parallel zu bestehenden Clustern, ohne Risiko für geteilte Controlplanes.

4. Edge & ressourcenlimitiert

   k3s ist klein und ARM-tauglich. In Edge-Szenarien kann eine zentrale Steuer-Ebene (Management-Cluster) schnell Controlplanes provisionieren, Agents vor Ort verbinden (VPN/ZTNA), und so Hunderte Edge-Cluster orchestrieren. 

Vergleich & Alternativen

Kamaji (Clastix)

Kamaji betreibt Hosted Control Planes als Pods im Management-Cluster und skaliert so viele User-Cluster, ohne Master-VMs. Es ist Cluster-API-integriert und fokussiert auf großskalige Multi-Cluster-Betriebe in Enterprise-Umgebungen. Wenn ihr viele „volle" Kubernetes-Cluster (nicht k3s) mit zentralem Lifecycle fahren wollt, ist Kamaji eine ausgereifte Option. 

Wann k3k statt Kamaji?

Wenn k3s-Eigenschaften (Single-Binary, ARM-Optimierung, geringes RAM) wichtig sind, CI-Spin-ups sekundenschnell sein sollen, oder wenn ihr agent-less k3s ausdrücklich bevorzugt, um die Controlplane sauber vom Scheduling zu trennen. 

Gardener (Seed/Shoot)

Gardener hostet die Controlplanes der Shoot-Cluster im Seed-Cluster – ebenfalls „Kubeception". Vorteil: ausgereiftes Ökosystem, Skalierung großer Flotten, Multi-Provider-Betrieb. Nachteil: höhere Einstiegskomplexität und Fokus auf „vollwertige" K8s-Distributionen. Für k3s-spezifische, leichtgewichtige und CI-nahe Use Cases ist k3k agiler und kleiner. 

Technische Eckpunkte & Stolpersteine

• Agent-less Besonderheiten: Ohne kubelet/kube-proxy auf der Controlplane müssen Netzwege bedacht werden (z. B. egress-selector-Mode pod/cluster, Service-Zugriff des API-Servers). Die k3s-Docs führt entsprechende Optionen und Grenzen. 
• Upgrade-Strategie: Controlplanes sind „nur" Workloads – nutzt Rolling/Blue-Green und pinned Container-Images (k3s-Versionen) für reproduzierbare Upgrades.
• Datastore-Wahl: k3s kann sqlite oder etcd sowie externe DBs nutzen. Für kurzlebige CI-Cluster genügt sqlite; persistente Dev/Stage oder Mandanten-Cluster sollten etcd oder Postgres einplanen. 
• RBAC/Netz: Dedizierte Namespaces pro eingebettetem Cluster, NetworkPolicies, getrennte ServiceAccounts und Secret-Scopes – vermeidet „Cross-Talk" zwischen Controlplanes.
• Observability: Jede Controlplane braucht eigene Dashboards/Alerts (API Latenz, etcd-Health, Controller-Queues), sonst fehlen Signale im Störungsfall.

Praxis: k3k per Helm installieren und einen k3s-Cluster erzeugen

Hinweis: Helm ist der Standard-Paketmanager für Kubernetes; gute Doku und Quickstart sind verfügbar. 

1) Values definieren

Die zentralen Einstellungen liegen in den Sektionen loadbalancer und k3s. Wenn loadbalancer.enabled=false, ist die k3s-API nicht von außen erreichbar – in der Praxis willst du fast immer true und eine feste IP. Optional kannst du eine LB-Klasse angeben (z. B. MetalLB/Cilium LB). Außerdem definierst du im k3s-Block den agent-less Betrieb und gängige Deaktivierungen (flannel, kube-proxy, traefik etc. - relevant für die Nutzung von Cilium oder ingress-nginx) sowie egress_selector_mode.

loadbalancer:
  enabled: true
  class_name: ""        # z.B. "metallb" oder spezifische LB-Klasse
  ip: "1.2.3.4"         # feste, im Host-Cluster routbare LB-IP

k3s:
  # grundlegende Secrets/Tokens
  token: "secret"
  agent_token: "secret"

  # Cluster-Netze passend zu deiner Umgebung
  cluster_cidr: "10.42.0.0/16"
  service_cidr: "10.43.0.0/16"
  cluster_dns: "10.43.0.10"
  cluster_domain: "cluster.local"

  # Datenpfad & Logging
  data_dir: /var/lib/rancher/k3s
  log_level: "0"
  debug: false

  # Agent-less & Network-Stack schlank halten
  disable:
    agent: true            # <— agent-less Controlplane
    flannel: true
    helm_controller: true
    network_policy: true
    traefik: true
    localstorage: true
    servicelb: true
    kube_proxy: true
    cloud_controller: false

  # Egress-Handling für die Controlplane
  egress_selector_mode: "pod"

  # Kubeconfig-Ablage (wird im Container erzeugt)
  kubeconfig:
    filename: kubeconfig.yaml
    mode: "0644"

2) Chart installieren

# k3k-Chart aus dem OCI-Registry installieren
helm upgrade --install k3k oci://cargo.ayedo.cloud/library/k3k --namespace k3k --values values.yaml

3) kubeconfig entnehmen

Nach dem Start von k3k erzeugt das Chart automatisch ein Secret im gleichen Namespace, das die kubeconfig der eingebetteten k3s-Controlplane enthält.

# 1) Secret finden (per Label oder Namensmuster)
kubectl -n k3k get secrets

# Optional komfortabel per Label-Selector, falls gesetzt:
kubectl -n k3k get secret k3k-k3k-kubeconfig

CI/CD mit k3k: E2E-Tests pro Pull Request

Ein großes Versprechen von Kubernetes und Cloud-Native-Stacks ist es, Entwicklungszyklen radikal zu beschleunigen. Doch wer heute für jeden Pull Request eine vollständige Testumgebung aufbauen will, stößt schnell an Grenzen: Shared Dev-Cluster sind oft überlastet, dedizierte Testumgebungen zu teuer oder schlicht nicht schnell genug. Genau hier setzt k3k an: Eine Controlplane ist nur ein Helm-Release entfernt – leichtgewichtig, reproduzierbar und isoliert.

Stellen wir uns den typischen Ablauf vor:

Ein Entwickler öffnet einen Pull Request. Anstatt Code in einem geteilten Cluster zu testen, rollt die Pipeline automatisch eine neue k3s-Controlplane via k3k aus. Diese Controlplane bekommt eine feste Load-Balancer-IP, startet im agent-less Mode und liefert binnen Minuten eine vollwertige Kubernetes-API. Die Pipeline wartet, bis der API-Server bereit ist und zieht sich dann die automatisch erstellte kubeconfig aus dem Namespace-Secret.

Nun kann die eigentliche Applikation – das Helm-Chart der App – in dieses frische Cluster deployt werden. Ob einfache Web-App oder komplexer Microservice-Verbund: die Tests laufen in einer sauberen, abgeschotteten Umgebung. Cypress, K6 oder Postman prüfen Endpunkte, Metriken werden gesammelt, Logs archiviert. Zum Schluss wird die gesamte Controlplane wieder entfernt – Helm-Uninstall genügt. Keine vergessenen Cluster, keine aufgeblähten Testlandschaften. Alles ist reproduzierbar, parallelisierbar und GitOps-tauglich.

Das Ergebnis ist eine Umgebung, in der Teams „fail fast, fix fast" leben können. Fehler tauchen nicht erst in Staging oder – schlimmer – in Produktion auf, sondern direkt im PR. Und da die Controlplanes sich beliebig parallelisieren lassen, müssen Teams keine Slots mehr „reservieren" oder sich gegenseitig blockieren. Jeder PR hat sein eigenes, isoliertes Kubernetes.

Wann ist k3k nicht das Richtige?

Natürlich hat dieses Modell seine Grenzen. Wer große Produktionsflotten mit hohen Governance-Anforderungen betreibt, wird früher oder später an Punkte stoßen, an denen ein Hosted-Controlplane-Ansatz wie Kamaji oder eine Plattform wie Gardener besser passt. Dort gibt es HA-Controlplanes, tiefe Day-2-Operations und die Möglichkeit, „vollwertige" Kubernetes-Cluster mit allen Standards und Integrationen bereitzustellen.

Auch für Szenarien, in denen bewusst Workloads auf Controlplane-Nodes laufen sollen, ist k3k nicht geeignet – der agent-less Ansatz schließt das explizit aus. Genau diese klare Trennung ist der Vorteil von k3k, macht es aber ungeeignet für Setups, die ein server+agent-Modell erwarten.

Sicherheits- und Betriebsaspekte: mehr als nur ein Test-Cluster

Ein leichtgewichtiges Controlplane-Modell darf nicht bedeuten, dass Sicherheit und Betrieb auf der Strecke bleiben. Im Gegenteil – gerade weil Controlplanes on demand entstehen und verschwinden, ist es wichtig, den Rahmen klar zu definieren:

• Isolation: Jede k3k-Controlplane sollte in einem eigenen Namespace laufen, idealerweise auf einem dedizierten Node-Pool mit Taints & Tolerations, abgesichert durch NetworkPolicies und Pod Security Standards.
• Secrets & PKI: kubeconfig-Dateien und Zertifikate müssen sicher verteilt und rotiert werden. Tools wie Vault oder cert-manager können hier automatisieren.
• Registry-Kontrolle: Integriert werden sollte ausschließlich aus internen Artefakt-Registries. In Air-Gapped-Umgebungen helfen Pull-Through-Caches und Proxies, um Supply-Chain-Sicherheit zu gewährleisten.
• Monitoring: Auch eine kurzlebige Controlplane braucht Überwachung. API-Latenz, Controller-Queues oder Admission-Fehler sind wertvolle Indikatoren, die automatisiert gesammelt werden sollten.
• Backups: Wenn Controlplanes längerfristig laufen – etwa für dedizierte Mandanten-Cluster – braucht es regelmäßige etcd-Snapshots, bevor Upgrades durchgeführt werden.

Diese Aspekte machen klar: k3k ist nicht nur ein Experiment für Entwickler, sondern ein ernstzunehmendes Werkzeug in einer modernen CI/CD-Toolchain – leichtgewichtig, aber mit klaren Governance- und Security-Prinzipien.

Der größere Kontext: Warum k3s?

k3s ist ein voll konformes Kubernetes in einem sehr kleinen Footprint – Single-Binary, ARM-optimiert, für Edge/Remote entworfen. Weniger Abhängigkeiten, schnellere Start-/Upgrade-Zyklen, geringer RAM/CPU-Verbrauch. Für CI, Dev, Edge und Multi-Tenant-Nicht-Prod-Flotten ist das ideal; in Prod-Szenarien wird k3s inzwischen ebenfalls breit eingesetzt. 

k3k nutzt diese Stärken – und bringt die Schnelligkeit und Reproduzierbarkeit der Cloud-nativen Welt in On-Prem-Kontexte, die von VM-Langsamkeit geprägt sind.

Fazit

k3k ist ein praktischer Beschleuniger: agent-less k3s-Controlplanes als Pods im bestehenden Cluster bedeuten Minuten statt Stunden, Deklaration statt Tickets, GitOps statt Handarbeit. Für CI/E2E, Multi-Tenant-Dev, kurzlebige Staging-Cluster und ressourcenarme Edge-Szenarien ist das ein massiver Produktivitätshebel.

Alternativen wie Kamaji (Hosted Control Plane für Voll-Kubernetes, Cluster-API-ready) und Gardener (Seed/Shoot) sind stark, wenn ihr sehr große, heterogene Flotten orchestriert. Wenn ihr aber k3s-Agilität braucht, Arm-Edge bedient, und die Trennung via agent-less Controlplane schätzt, spielt k3k seine Vorteile aus.

Weiterführend

• K3s on Flatcar via Ansible & vSphere
• Developer Platforms von ayedo
• GPUs in Kubernetes: Praxisleitfaden