Kubernetes auf OVHcloud: Managed Service oder eigener Cluster?

Kubernetes auf OVHcloud mit klarer Betriebsverantwortung aufbauen? WZ-IT plant Managed- und Self-managed-Architekturen, integriert Netzwerk und Plattformdienste und übernimmt auf Wunsch GitOps, Monitoring, Backup und Betrieb. Kubernetes auf OVHcloud ansehen

OVHcloud bietet mit Managed Kubernetes Service eine verwaltete Control Plane und integrierte Public-Cloud-Ressourcen. Das reduziert den Aufwand für Installation und Lifecycle zentraler Kubernetes-Komponenten. Die Verantwortung für Cluster-Konfiguration, Worker, Workloads, Daten und deren Wiederherstellung bleibt dennoch teilweise oder vollständig beim Kunden.

Die zentrale Architekturfrage lautet deshalb nicht nur "Managed oder selbst betrieben?", sondern: Welche Schicht verantwortet OVHcloud, welche übernimmt WZ-IT und welche bleibt im Anwendungsteam?

Inhaltsverzeichnis

• Drei mögliche Betriebsmodelle
• Was OVHcloud MKS übernimmt
• Was trotz Managed Service übrig bleibt
• Netzwerk mit vRack und öffentlichen Endpunkten
• Node Pools, Load Balancer und Storage
• Identität, GitOps und Security
• Backup und Disaster Recovery
• MKS oder eigener Cluster?

Drei mögliche Betriebsmodelle

Der Managed Service ist häufig der kürzeste Weg zu einer standardisierten OVHcloud-Plattform. Ein eigener Cluster kann sinnvoll sein, wenn die Control Plane bewusst selbst kontrolliert, spezielle Node- oder Netzwerkmodelle benötigt oder Kubernetes mit einer bestehenden Proxmox-Private-Cloud verbunden werden soll.

Was OVHcloud MKS übernimmt

Der OVHcloud Managed Kubernetes Service stellt Kubernetes-Cluster mit verwalteter Control Plane bereit. Die Produktseite nennt unter anderem Node Pools, Autoscaling, Load-Balancer- und Storage-Integration, private Netzwerkanbindung und Infrastructure as Code mit Terraform.

Die Control Plane umfasst Kernkomponenten wie API-Server, etcd und Controller. Je nach gewähltem Angebot und Region unterscheiden sich Verfügbarkeitsmodell und Service Level. Diese Details sollten zum Zeitpunkt der Architekturentscheidung direkt mit der aktuellen Leistungsbeschreibung und den verfügbaren Regionen abgeglichen werden.

Ein verwalteter Control-Plane-Lifecycle reduziert insbesondere:

• Installation und Hochverfügbarkeit der Kubernetes-Control-Plane,
• Wartung zentraler Kubernetes-Komponenten,
• Bereitstellung unterstützter Kubernetes-Versionen,
• Integration von Node Pools in die OVHcloud Public Cloud.

Was trotz Managed Service übrig bleibt

OVHcloud beschreibt auf der Produktseite ein Shared-Responsibility-Modell: Der Provider wartet die Control Plane, während Kunden weiterhin für die Sicherheit ihrer Worker-Nodes, Container und Pods, die Dimensionierung sowie die Datensicherung verantwortlich sind.

Für eine produktive Plattform bleiben damit mindestens folgende Aufgaben:

• Namespaces, Quotas und Mandantentrennung,
• Rollen, Service Accounts und OIDC-Integration,
• Network Policies und Egress-Regeln,
• Ingress, DNS und Zertifikate,
• Container Registry und Image-Sicherheit,
• GitOps und Deployment-Prozesse,
• Monitoring, Logs, Traces und Alerting,
• Backups, Restore-Tests und Disaster Recovery,
• Updates aller Add-ons und Anwendungen.

"Managed Kubernetes" beschreibt also nicht automatisch einen vollständig betreuten Anwendungsbetrieb. Der Leistungsumfang muss pro Schicht benannt werden.

Netzwerk mit vRack und öffentlichen Endpunkten

OVHcloud vRack verbindet kompatible Cloud- und Dedicated-Ressourcen über ein privates Netzwerk. In einer Kubernetes-Architektur kann es mehrere Verkehrsarten trennen:

• Node- und Clusterverkehr,
• Zugriff auf Datenbanken und interne Backends,
• Verbindungen zwischen Public Cloud und Dedicated Servern,
• Managementzugänge,
• öffentliche Anwendungseinstiege.

Öffentliche Anwendungen werden über definierte Load Balancer und Ingress- oder Gateway-Komponenten exponiert. Die Kubernetes-API, Argo CD, Grafana oder interne Dienste können dagegen auf eingeschränkte Netze begrenzt und zusätzlich über NetBird zugänglich gemacht werden.

Die Architektur sollte auch ausgehenden Verkehr berücksichtigen. Feste Egress-Adressen, Firewall-Regeln und die Erreichbarkeit externer Abhängigkeiten sind häufig genauso wichtig wie der eingehende Traffic.

Node Pools, Load Balancer und Storage

MKS-Node-Pools basieren auf OVHcloud Public-Cloud-Instanzen. Unterschiedliche Pools können Workloads nach Ressourcenbedarf, Verfügbarkeit oder Vertrauenszone trennen. Taints, Tolerations, Affinity-Regeln und PodDisruptionBudgets übersetzen diese Infrastrukturaufteilung in Kubernetes-Regeln.

OVHcloud integriert seine Load Balancer und Storage-Klassen in den Managed Service. Trotzdem müssen Teams entscheiden:

• Welche Services sind öffentlich und welche privat?
• Wie werden TLS, DNS und Web Application Firewall angebunden?
• Welche Daten liegen in Persistent Volumes und welche in Managed Databases?
• Welche Workloads benötigen mehrere Availability Zones?
• Wie verhalten sich Anwendungen bei einem Node-, Zonen- oder Storage-Ausfall?

Eine hochverfügbare Control Plane macht eine Anwendung nicht automatisch hochverfügbar. Replikate, Topology Spread Constraints, Datenbankarchitektur und Wiederanlauf müssen auf Workload-Ebene geplant werden.

Identität, GitOps und Security

OVHcloud unterstützt laut Produktseite die Einbindung von OpenID Connect. Auf Kubernetes-Seite ergänzt RBAC die Identity-Integration. Ein belastbares Modell trennt menschliche Nutzer, CI/CD-Identitäten und Workload-Identitäten.

GitOps mit Argo CD oder Flux hält Plattform und Anwendungen versioniert. Dazu gehören beispielsweise:

• Namespaces und Policies,
• Ingress- und Gateway-Konfiguration,
• cert-manager und DNS-Automatisierung,
• Monitoring- und Logging-Komponenten,
• Helm-Releases und Anwendungsmanifeste,
• Secrets als verschlüsselte oder extern verwaltete Referenzen.

Policy Engines wie Kyverno oder OPA Gatekeeper können technische Mindestanforderungen prüfen. Sie ersetzen weder ein Rollenmodell noch die regelmäßige Bewertung von Images, Abhängigkeiten und Cluster-Konfiguration.

Backup und Disaster Recovery

OVHcloud dokumentiert mehrere Backup-Wege für MKS, darunter Velero und Volume Snapshots. Die konkrete Lösung muss alle relevanten Datenebenen abdecken:

1. Kubernetes-Ressourcen und Custom Resources,
2. Persistent Volumes,
3. anwendungskonsistente Datenbank-Backups,
4. externe Secrets, Registries und Git-Repositories,
5. die Infrastructure-as-Code-Konfiguration zum Wiederaufbau.

Ein Backup gilt erst dann als belastbar, wenn die Wiederherstellung in eine definierte Zielumgebung getestet wurde. Für einen Regionenausfall muss zusätzlich geklärt sein, ob Images, Backups, DNS und Schlüssel außerhalb derselben Ausfallgrenze verfügbar sind.

MKS oder eigener Cluster?

WZ-IT kann sowohl MKS als auch eigene Cluster betreuen. Der Schwerpunkt liegt auf dem Übergang von Infrastruktur zu einer nutzbaren Anwendungsplattform: Netzwerk, GitOps, Identity, Observability, Backup und Betrieb werden gemeinsam geplant und mit eindeutigen Zuständigkeiten dokumentiert.

Quellen

• OVHcloud Managed Kubernetes Service
• OVHcloud Dokumentation zu Managed Kubernetes
• OVHcloud Professional Services für Kubernetes
• OVHcloud vRack
• Kubernetes: Shared Responsibility