Zwei Motive dominieren: Tempo und Dichte.
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.
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:
Wichtig: Wer Workloads fahren will, fügt separate agent-Nodes (oder „shared Agents" innerhalb des Management-Clusters) hinzu. Das bleibt bewusst entkoppelt.
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.
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:
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.
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.
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.
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.
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.
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.
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 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.
Hinweis: Helm ist der Standard-Paketmanager für Kubernetes; gute Doku und Quickstart sind verfügbar.
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"
# k3k-Chart aus dem OCI-Registry installieren
helm upgrade --install k3k oci://cargo.ayedo.cloud/library/k3k --namespace k3k --values values.yaml
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
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.
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.
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:
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.
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.
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.
Profitieren Sie von skalierbarem App Hosting in Kubernetes, hochverfügbarem Ingress Loadbalancing und erstklassigem Support durch unser Plattform Team. Mit der ayedo Cloud können Sie sich wieder auf das konzentrieren, was Sie am besten können: Software entwickeln.
Interessiert an weiteren Inhalten? Hier gehts zu allen Blogs →
