K3s on Flatcar via Ansible & vSphere: automatisiertes K8s für regulierte Umgebungen
Fabian Peter • • 4 Minuten Lesezeit

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.
container - k3s - flatcar - ansible - vsphere - kubernetes - regulierte-umgebungen - automatisierung

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.

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

  1. vSphere liefert die Basis: Datacenter, Cluster, Netzwerk, Datastore.
  2. Ansible mit der Collection community.vmware steuert VM-Erzeugung & Konfiguration.
  3. Flatcar OVA dient als Template – Ignition-Config wird per guestinfo injiziert.
  4. Ignition legt SSH-Keys, systemd-Units und k3s-Services an.
  5. 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

Vorheriger Post Alle Posts Nächster Post