K3s on Flatcar via Ansible & vSphere: automatisiertes K8s für regulierte Umgebungen

In Branchen wie Industrie, Finanzwesen oder kritischen Infrastrukturen ist Automatisierung kein „Nice-to-have", sondern zwingende Notwendigkeit. Kubernetes ist längst etabliert – doch die Bereitstellung von Controlplanes in regulierten On-Premises-Umgebungen bleibt komplex.

Meta: Fabian Peter · 17.08.2025 · ⏳ 4 Minuten · Alle Blogs →

Tags: k3s · flatcar · ansible · vsphere · kubernetes · regulierte-umgebungen · automatisierung

Virtuelle Maschinen müssen auditierbar, reproduzierbar und sicher erzeugt werden. Standard-Templates mit Ubuntu oder CentOS sind oft schwer aktuell zu halten. Gleichzeitig erfordert Compliance die volle Kontrolle über Supply-Chain, Secrets und Netzwerkzugänge.

Ein Ansatz, der sich gerade für Edge, Test, Dev und auch Prod-Cluster in sensiblen Umgebungen anbietet: Flatcar Linux + k3s, vollautomatisch provisioniert über Ansible auf vSphere.

Warum Flatcar + k3s?

Flatcar Linux ist ein minimaler, Container-optimierter Linux-Fork (Nachfolger von CoreOS). Kein Ballast, automatische Updates möglich, und vollständig per Ignition konfigurierbar.
k3s ist ein leichtgewichtiger, CNCF-zertifizierter Kubernetes-Distribution von Rancher. Optimiert für Edge und CI/CD, kleiner Footprint, aber vollständig kompatibel.
Ansible orchestriert den gesamten Lifecycle – von der VM-Erzeugung in vSphere bis zur Übergabe der Kubeconfig.

Das Ergebnis: schnell hochgezogene, standardisierte Controlplanes, ohne Click-Ops in vCenter, reproduzierbar aus Code, und auch für Air-Gapped-Umgebungen adaptierbar.

Architektur im Überblick

vSphere liefert die Basis: Datacenter, Cluster, Netzwerk, Datastore.
Ansible mit der Collection community.vmware steuert VM-Erzeugung & Konfiguration.
Flatcar OVA dient als Template – Ignition-Config wird per guestinfo injiziert.
Ignition legt SSH-Keys, systemd-Units und k3s-Services an.
k3s startet als Controlplane, entweder als Single-Server oder als HA-Cluster mit embedded etcd.

Warum nicht Ubuntu + Cloud-Init?

In vielen Industrien sind die Nachteile von Cloud-Init-VMs bekannt:

Templates müssen regelmäßig manuell gepatcht werden.
Unterschiede in der User-Data-Verarbeitung je Version/Cloud-Treiber.
Kein deterministischer, reproduzierbarer Build.

Flatcar + Ignition bietet:

Immutable Images, Konfiguration über klar definierte JSON-Deskriptoren.
Einfache Integration in GitOps: Versioniertes Ignition-JSON = reproduzierbarer Cluster.
Keine Abhängigkeit von distribuierten Cloud-Init-Implementierungen.

Ignition: Infrastruktur als Code

Flatcar liest beim Boot eine Ignition-JSON-Datei, die über VMware guestinfo bereitgestellt wird. Diese beschreibt Benutzer, Files, Units, Netzwerk – und damit auch den k3s-Bootstrapping-Prozess.

Beispiel: k3s-Server (Single)

{
  "ignition": { "version": "3.4.0" },
  "passwd": {
    "users": [
      {
        "name": "core",
        "sshAuthorizedKeys": ["ssh-ed25519 AAAAC..."]
      }
    ]
  },
  "storage": {
    "files": [
      {
        "path": "/etc/systemd/system/k3s.service",
        "mode": 420,
        "contents": {
          "source": "data:text/plain;charset=utf-8,[Unit]\nDescription=Lightweight Kubernetes\nAfter=network-online.target\n..."
        }
      }
    ]
  },
  "systemd": {
    "units": [
      {
        "name": "k3s.service",
        "enabled": true
      }
    ]
  }
}

Vorteil: komplette Config im Git-Repo versioniert. Jeder Re-Deploy ist identisch.

Ansible: Vollautomatisierung auf vSphere

Mit der Ansible-Collection community.vmware lassen sich VMs aus Content Library OVAs deployen, Ignition injizieren und IP-Adressen abfragen.

Beispiel: Single k3s-Server

- name: Provision Flatcar VM and run k3s (single server)
  hosts: localhost
  collections:
    - community.vmware
  tasks:
    - name: Deploy VM
      vmware_content_deploy_ovf_template:
        hostname: vcsa.lab.local
        username: svc_ansible@vsphere.local
        password: "{{ vcenter_password }}"
        datacenter: "DC1"
        cluster: "Compute"
        datastore: "vsanDatastore"
        name: "cp1"
        content_library: "BaseImages"
        template: "flatcar-stable-vmware.ova"
        folder: "/DC1/vm/k3s"
        networks:
          - name: "VM Network"
        power_on: true
        advanced_settings:
          - key: "guestinfo.ignition.config.data"
            value: "{{ lookup('file', 'ignition-k3s.json') | b64encode }}"
          - key: "guestinfo.ignition.config.data.encoding"
            value: "base64"

HA-Controlplanes: 3× Flatcar + k3s

Für Produktiv-Szenarien empfiehlt sich ein 3-Node-Cluster mit embedded etcd:

Node A: --cluster-init
Node B/C: --server https://<VIP>:6443 --token <token>

Load-Balancer (VIP) kann über kube-vip oder keepalived bereitgestellt werden.

So entstehen hochverfügbare Controlplanes, die sich in Minuten provisionieren lassen – ideal auch für Mandanten-Cluster oder Staging-Systeme.

Betrieb in regulierten Branchen

In Industrien mit hohen Compliance-Anforderungen kommt es auf Details an:

Air-Gapped: Kein Download von get.k3s.io, sondern eigener Mirror. Ansible ersetzt die URL im Ignition-Template.
PKI & Secrets: kubeconfigs & Zertifikate über Vault oder HSM-gesicherte PKI verteilen.
Audits: Jede VM-Definition ist in Git dokumentiert. Change-Management: PR → Audit-Trail.
Update-Strategie: Flatcar-Channel (stable) oder kontrollierte Rolling-Upgrades via Ansible Playbook.
Storage & Backup: etcd-Snapshots automatisiert sichern, Recovery Playbooks bereitstellen.

Beispiel: CI/CD & E2E-Tests

Ein besonders starker Anwendungsfall: End-to-End-Tests pro Pull Request.

PR wird erstellt → Ansible startet Flatcar-VM + k3s-Controlplane.
App wird ins Cluster deployt.
Cypress/K6 Tests laufen in isolierter Umgebung.
Logs & Reports werden gesichert.
VM wird wieder gelöscht.

Das ist reproduzierbar, parallelisierbar und ohne shared Cluster – perfekt für Fail Fast, Fix Fast.

Alternativen im Vergleich

Kamaji (kamaji.clastix.io): Hosted-Controlplanes in Kubernetes selbst, ideal für SaaS-Plattformen.
Gardener (gardener.cloud): Vollwertige Cluster-as-a-Service-Plattform, geeignet für Hyperscaler-ähnliche Betreiber.
k3k (ayedo/k3k): Controlplanes in Kubernetes, extrem schnell für Multi-Tenant & CI.

Im Vergleich bietet Ansible+Flatcar+vSphere vor allem in klassischen Rechenzentren und regulierten Branchen Vorteile, da es sich nahtlos in bestehende VMware-Ökosysteme integrieren lässt – ohne zusätzliche Plattformschicht.

Fazit

Mit Ansible, Flatcar und k3s auf vSphere lassen sich Kubernetes-Controlplanes in regulierten Umgebungen standardisiert, sicher und reproduzierbar bereitstellen.

Das Ergebnis:

Schneller Rollout neuer Cluster – ob für Tests, Staging oder Edge.
Compliance-konform durch GitOps, Immutable OS, Auditierbarkeit.
Skalierbar von Einzelserver bis HA-Controlplane.

Wer heute in Industrie oder regulierten Branchen Kubernetes betreibt, braucht genau das: Automatisierung mit klarer Governance – nicht Click-Ops.

Weiterführend

Hosten Sie Ihre Apps bei ayedo

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.

Jetzt ausprobieren →