Worum es geht
Klassische Virtualisierung trifft an ihre Grenzen, wenn moderne Anwendungen ins Spiel kommen: Microservices skalieren in Containern besser als in VMs, Continuous Deployment erwartet eine API-getriebene Plattform, und Entwicklerteams wollen Self-Service ohne Ticket-Pingpong. Wer diese Anforderungen mit AWS EKS oder Azure AKS löst, gibt Kontrolle, Daten und nicht selten eine sechsstellige Jahressumme an einen US-Hyperscaler ab.
Wir bauen Kubernetes-Plattformen, die genau das Gegenteil liefern: voll funktionsfähige, hochskalierbare Cloud-Native-Infrastruktur unter Ihrer eigenen Kontrolle, auf Ihrer eigenen Hardware oder bei einem europäischen Hosting-Partner. Mit denselben Konzepten wie EKS und AKS – aber ohne Lock-in, ohne Drittland-Transfer, ohne Lizenzfalle.
Was ist enthalten
01. Cluster-Architektur
Mehrstufiger Aufbau mit Management-Cluster (Rancher) und beliebig vielen Workload-Clustern auf RKE2. Hochverfügbar konzipiert, mit redundanten Control-Plane-Nodes und etcd-Backups, die regelmäßig getestet werden. Wir entwerfen die Architektur so, dass sie sowohl in einem einzelnen Rechenzentrum als auch über mehrere Standorte hinweg funktioniert.
02. Cloud-Native-Networking mit Cilium
eBPF-basiertes Networking mit Cilium statt klassischem kube-proxy. Bringt mehrere Größenordnungen bessere Performance bei großen Cluster-Größen, native Layer-7-Sicherheitsregeln, und Hubble als Observability-Stack obendrauf. Network Policies werden zur First-Class-Citizen-Funktionalität, nicht zum nachträglich aufgeklebten Feature.
03. Storage-Anbindung
Persistent Volumes über Longhorn (cloud-native, im Cluster integriert) oder Ceph (skaliert in den Petabyte-Bereich, externe Verwaltung). Welche Variante passt, hängt von Ihren Workloads ab – wir empfehlen, was zu Ihrer tatsächlichen Last passt, nicht was am meisten Marge abwirft.
04. Identity, Secrets und Compliance
SSO über Keycloak und OIDC, Secrets-Management über HashiCorp Vault oder External Secrets Operator, RBAC-Strukturen, die zu Ihrer Organisationsstruktur passen. Audit-Logs, Image-Signaturen mit Cosign und Policy-Enforcement über Kyverno oder OPA Gatekeeper sind eingebaut, nicht nachträglich angebaut.
05. CI/CD und GitOps
Vollständig GitOps-basierter Workflow mit ArgoCD oder Flux: Ihre gesamte Cluster-Konfiguration und alle Anwendungen liegen in Git, jeder Pull Request wird gereviewed, und der Cluster gleicht sich automatisch dem gewünschten Zustand an. Manueller kubectl apply ist die Ausnahme, nicht die Regel.
06. Observability und Betrieb
Prometheus für Metriken, Grafana für Dashboards, Loki für Logs, Tempo für Traces – die etablierten CNCF-Standards, die auch die großen Cloud-Anbieter verwenden. Auf Wunsch übernehmen wir den Betrieb mit SLA, häufiger übergeben wir die Plattform an Ihr internes Platform-Engineering-Team.
Eingesetzte Open-Source-Komponenten
- Rancher – Multi-Cluster-Management mit Web-UI und API
- RKE2 – CNCF-zertifizierte Kubernetes-Distribution mit gehärteten Defaults
- Cilium – eBPF-basiertes Networking, Security und Observability
- Longhorn / Ceph CSI – Persistent Storage je nach Skalierungsanforderung
- ArgoCD / Flux – GitOps-Continuous-Delivery
- Keycloak – Identity-Provider mit OIDC und SAML
- Vault – Secrets-Management
- Prometheus & Grafana & Loki – Observability-Stack
- Kyverno / OPA Gatekeeper – Policy-Enforcement
Für wen ist dieses Konzept geeignet
- Hosting-Provider und Cloud-Anbieter, die ihren Kunden Kubernetes-as-a-Service anbieten wollen
- Unternehmen mit eigenen Entwicklerteams, die Self-Service-Plattformen für Microservices brauchen
- Organisationen, die aus Compliance-Gründen aus AWS/Azure/GCP migrieren müssen
- Forschungseinrichtungen mit elastischen Compute-Anforderungen für Datenanalyse oder ML-Workloads
Typische Eckdaten
- Projektdauer: 3 bis 6 Monate für initiale Plattform mit Management-Cluster und ersten Workload-Clustern
- Mindestgröße: ab etwa 12 physischen Nodes wirtschaftlich (3 Management + 9 Worker über zwei Cluster)
- Skalierung: Cluster wachsen horizontal, neue Workload-Cluster werden in Stunden, nicht Wochen, hinzugefügt
Im Erstgespräch klären wir, ob Kubernetes für Ihre Workloads das richtige Werkzeug ist – nicht jede Anwendung gehört in einen Container, und nicht jede Organisation braucht die Komplexität, die Kubernetes mitbringt.