Zum Inhalt

Kubernetes Distribution

Die ayedo Kubernetes Distribution ist die Grundlage der Software Delivery Plattform. Sie bietet eine produktionsreife Kubernetes-Umgebung mit über 50 vorkonfigurierten Managed Apps, die als Bausteine für den Aufbau Ihrer individuellen Plattform dienen.

Wir bieten zwei spezialisierte Varianten: Loopback für Public Cloud-Deployments und eine hauseigene k3s-basierte Lösung für On-Premises- und Enterprise-Szenarien.

Was ist die Kubernetes Distribution?

Die Kubernetes Distribution umfasst:

  1. Kubernetes Cluster - Produktionsreifes, verwaltetes Kubernetes (Loopback oder k3s)
  2. Managed Apps - Über 50 vorkonfigurierte Anwendungen

Kubernetes Distribution vs. Software Delivery Plattform

Die Kubernetes Distribution ist die Basis - sie bringt Kubernetes und Managed Apps mit und ermöglicht es, darauf eine Plattform aufzubauen. Die Software Delivery Plattform ist die darauf aufbauende Plattform mit Platform-Services, Compliance, Automatisierung und Integration von Polycrate und ohMyHelm. Die SDP wird in drei Editionen angeboten: Public Cloud, Private Cloud und Enterprise Cloud.

Deployment-Varianten

Die ayedo Kubernetes Distribution wird in zwei Varianten angeboten, um unterschiedliche Infrastruktur-Anforderungen optimal zu unterstützen:

Public Cloud: Loopback

Für Kunden, die Public Cloud-Infrastruktur verwenden möchten, setzen wir auf Loopback - eine moderne SaaS-Plattform für Kubernetes in europäischen Cloud-Umgebungen.

Vorteile von Loopback:

  • 🌍 Multi-Cloud: Unterstützt alle europäischen Cloud-Provider sowie die großen Hyperscaler
  • 🎯 Self-Service: Vollständige Kontrolle über Cluster-Verwaltung, Sizing und Zugang
  • ⚡ Schnelles Provisioning: Neue Cluster in Minuten statt Stunden
  • 🔐 Managed Control Plane: Hochverfügbare Control Plane ohne Wartungsaufwand
  • 📊 Integriertes Monitoring: Built-in Observability und Dashboards
  • 🔄 Automatische Updates: Verwaltete Kubernetes-Updates mit Zero-Downtime

Unterstützte Cloud-Provider:

  • Europäische Provider: Hetzner Cloud, IONOS Cloud, OVHcloud, Scaleway
  • Hyperscaler: AWS, Azure, Google Cloud (europäische Regionen)

Wie es funktioniert:

  1. Cluster erstellen: Self-Service im Loopback Dashboard
  2. Sizing wählen: Node-Typen und Anzahl nach Bedarf
  3. Zugang konfigurieren: RBAC und User Management

Weitere Informationen: loopback.cloud

On-Premises & Enterprise: k3s-basierte Variante

Für On-Premises-Umgebungen, Enterprise-Szenarien oder wenn Kubernetes auf restriktiver Infrastruktur betrieben werden muss, nutzen wir unsere hauseigene, auf k3s basierende Kubernetes-Variante.

Ideal für:

  • 🏢 On-Premises: Eigene Rechenzentren und dedizierte Hardware
  • 🔒 Restriktive Umgebungen: Air-gapped, High-Security, regulierte Branchen
  • 🏭 Edge & IoT: Resource-constrained Environments
  • 🎛️ Volle Kontrolle: Komplette Kontrolle über alle Cluster-Komponenten
  • 📦 Bare Metal: Direkter Hardware-Zugriff ohne Virtualisierung

Technische Basis:

  • k3s: Lightweight, CNCF-zertifizierte Kubernetes-Distribution von SUSE (Deutschland)
  • Hochverfügbar: Multi-Master Setup möglich
  • Ressourcen-effizient: Geringer Memory- und CPU-Footprint
  • Produktionserprobt: In zahlreichen Enterprise-Deployments im Einsatz

Installation mit Polycrate:

Die Installation erfolgt vollständig automatisiert über Polycrate mit dem offiziellen k8s-1.27 Block:

Kubernetes Versionen

Der Block cargo.ayedo.cloud/ayedo/linux/k8s-1.27 unterstützt ab Version 0.3.6 alle Kubernetes-Versionen ab 1.27. Sie können durch Setzen von config.k3s.version jede gewünschte k3s-Version installieren.

# workspace.poly
name: on-prem-k8s

blocks:
  - name: k8s
    from: cargo.ayedo.cloud/ayedo/linux/k8s-1.27:0.3.6
    inventory:
      from: baremetal
    config:
      cluster_name: my-cluster
      cluster_ip_detection:
        enabled: true
      init:
        restart_nodes: true # nach erster Installation auf false setzen
      oidc:
        enabled: true
        issuer_url: "https://id.example.com/application/o/k8s/"
        client_id: "k8s-production"
        username_claim: "email"
        groups_claim: "groups"
      k3s:
        version: v1.27.1+k3s1  # Kubernetes-Version
        token: mySecureToken
        maxpods: "110"  # Kubernetes default
        cidr: 10.42.0.0/16
        # TLS Subject Alternative Names für API-Server
        tlssans:
          - k8s-api.example.com
          - 192.168.1.10
        # Private Container Registry Konfiguration
        private_registries:
          enabled: true
          content:
            mirrors:
              registry.example.com:
                endpoint:
                  - "https://registry.example.com:443"
              docker.io:
                endpoint:
                  - "https://registry.example.com:443"
                rewrite:
                  "^(.*)": "dockerhub/$1"
            config:
              "registry.example.com:443":
                auth:
                  username: registry-user
                  password: registry-password
        # Kubelet Resource Limits
        limits:
          kube_reserved: cpu=200m,memory=500Mi,ephemeral-storage=500m
          system_reserved: cpu=200m,memory=200Mi,ephemeral-storage=500m
          eviction_hard: memory.available<100Mi,nodefs.available<10%
          image_gc_high_threshold: 75
          image_gc_low_threshold: 70
        # Control Plane Konfiguration
        controlplane:
          disable_agent: false
          taint:
            disabled: false
            add: "CriticalAddonsOnly=true:NoExecute"
        # Restart-Verhalten mit Node Draining
        restart:
          drain_disabled: false
      # Networking
      flannel:
        disabled: false
        backend: vxlan
      kube_proxy:
        disabled: false
      # Host-Gruppen für Control Plane und Worker Nodes
      ansible_host_groups:
        controlplane: k8s_controlplane
        worker: k8s_worker

Wichtige Konfigurationsoptionen:

Option Beschreibung Standard
k3s.version Kubernetes-Version (ab v1.27.x) v1.27.1+k3s1
k3s.token Shared Secret für Cluster-Nodes -
k3s.cidr Pod-Netzwerk CIDR 10.42.0.0/16
k3s.maxpods Maximale Pods pro Node 110
k3s.tlssans TLS SANs für API-Server []
oidc.enabled OIDC-Authentifizierung aktivieren false
flannel.backend Flannel Backend-Typ vxlan
external_cloud_provider Externer Cloud Provider false
local_storage Lokaler Storage (local-path-provisioner) false 
# Cluster installieren
polycrate install k8s

# Verfügbare Actions anzeigen
polycrate run k8s

# Cluster-Status und IPs anzeigen
polycrate run k8s show-ips

# Kubeconfig exportieren (default: k3s.yaml)
polycrate run k8s export-kubeconfig

# Cluster neu konfigurieren (z.B. nach Config-Änderungen)
polycrate run k8s configure-cluster

# Weitere Nodes zum Cluster hinzufügen
polycrate run k8s join-cluster

# k3s Service neu starten
polycrate run k8s restart-k3s

Features der k3s-Variante:

  • Automatische Installation auf Linux-Hosts (Ubuntu, Flatcar Linux, CentOS, Debian)
  • OIDC-Integration für Enterprise Single Sign-On
  • Private Registry Support mit Mirror-Konfiguration und Authentication
  • Resource Limits für Kubelet (kube-reserved, system-reserved, eviction policies)
  • Control Plane Taints für dedizierte Control Plane Nodes
  • Automatisches Node Draining bei k3s-Restarts
  • TLS SAN-Support für Custom DNS-Namen und IPs
  • Flannel CNI mit konfigurierbarem Backend (vxlan, host-gw, wireguard)
  • Air-gap Installation mit Private Registry Mirror
  • Rolling Updates ohne Downtime via Polycrate Actions

Vergleich der Varianten

Aspekt Loopback (Public Cloud) k3s (On-Premises)
Zielgruppe Cloud-native Teams Enterprise, On-Prem
Infrastruktur Public Cloud Eigene Hardware/VMs
Verwaltung Self-Service Portal Polycrate CLI
Provisioning Minuten 1-2 Stunden
Control Plane Fully Managed Self-Hosted
Updates Automatisch Via Polycrate
Monitoring Integriert Separat konfiguriert
Komplexität Niedrig Mittel
Flexibilität Cloud-Provider-abhängig Maximum

Welche Variante ist die richtige?

  • Loopback: Wenn Sie schnell starten wollen, Public Cloud nutzen und sich nicht um Cluster-Management kümmern möchten
  • k3s: Wenn Sie On-Premises bleiben müssen, volle Kontrolle benötigen oder in restriktiven Umgebungen arbeiten

Kubernetes Cluster

Produktionsreife Kubernetes-Umgebung

  • Hochverfügbarkeit: Multi-Node Control Plane
  • Auto-Scaling: Automatische Skalierung von Nodes und Pods
  • Multi-AZ: Verteilung über mehrere Availability Zones
  • Verwaltete Updates: Automatische Security Patches und Updates
  • 24/7 Monitoring: Kontinuierliche Überwachung der Cluster-Health

Technische Basis

Beide Varianten der Kubernetes Distribution basieren auf:

  • Upstream Kubernetes / k3s - CNCF-zertifizierte Kubernetes-Versionen
  • Container Runtime - containerd als standardisierte Runtime
  • Storage - Longhorn und/oder Rook-Ceph für persistenten Storage
  • Networking - CNI-basiertes Networking (Cilium oder Flannel)

CNCF-Konform

Beide Varianten nutzen ausschließlich CNCF-konforme Kubernetes-Versionen und bewährte Open-Source-Komponenten. k3s ist eine offiziell zertifizierte Kubernetes-Distribution.

Managed Apps

Über 50 vorkonfigurierte Anwendungen sind als Managed Apps verfügbar und können per Polycrate oder GitOps deployed werden.

Kategorien

DevOps & CI/CD - GitLab, ArgoCD, Flux, Harbor, Tekton

Datenbanken - PostgreSQL, MongoDB, Redis, MySQL, MariaDB, ClickHouse

Identity & Access - Keycloak, Authentik, Zitadel

Monitoring & Observability - Grafana, VictoriaMetrics, InfluxDB, Prometheus

Messaging & Streaming - Kafka, RabbitMQ, NATS, Redis Streams

Security - Vault, SOPS, External Secrets Operator

Und viele mehr...

Managed Apps durchsuchen

Die vollständige Liste aller verfügbaren Managed Apps finden Sie unter:

ayedo.de/cloud/kubernetes/apps/

Dort finden Sie: - Detaillierte Beschreibungen jeder App - Konfigurations-Beispiele - Links zu PolyHub Blocks

Deployment-Möglichkeiten

Mit Polycrate

Managed Apps können über Polycrate deployed werden:

# workspace.poly
blocks:
  - name: postgresql
    from: ayedo/k8s/postgresql:1.0.0
    config:
      database_name: myapp
      storage_size: 100Gi

polycrate install postgresql

Mit GitOps (Flux/ArgoCD)

Apps können auch via GitOps deployed werden:

# HelmRelease für Flux
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: postgresql
spec:
  chart:
    spec:
      chart: postgresql
      sourceRef:
        kind: HelmRepository
        name: bitnami

Mit Helm

Direkte Installation via Helm:

helm repo add bitnami https://charts.bitnami.com/bitnami
helm install postgresql bitnami/postgresql

Integration in die Software Delivery Plattform

Die Kubernetes Distribution wird durch folgende Komponenten zur vollständigen Software Delivery Plattform:

Platform-Services

Die SDP ergänzt Kubernetes mit essentiellen Platform-Services:

  • Cilium - eBPF-basiertes Networking und Network Policies
  • VictoriaMetrics - Metriken und Monitoring
  • VictoriaLogs - Log-Aggregation
  • Harbor - Container Registry mit Vulnerability Scanning
  • Keycloak - Identity und Access Management
  • Kyverno - Policy-Enforcement
  • Cert-Manager - Automatisierte TLS-Zertifikate
  • Velero - Backup und Disaster Recovery

Details: Features

Polycrate

Polycrate orchestriert die Installation und Day-2-Operations:

  • Deployment von Kubernetes-Clustern
  • Installation von Platform-Services
  • Verwaltung von Managed Apps
  • Automatisierte Updates und Backups

ohMyHelm

ohMyHelm ermöglicht Entwicklern, eigene Apps ohne Chart-Entwicklung zu deployen:

  • Universeller Helm Chart Wrapper
  • Vorgefertigte Templates
  • Automatische Integration mit Platform-Services

Nächste Schritte

Deployment-Variante wählen

Kubernetes Distribution erkunden

Software Delivery Plattform verstehen

Support