Kubernetes, betrieben wie ein Produktivsystem.
Wir betreuen produktive Kubernetes- und k3s-Cluster als Managed Service: Monitoring, Backups, Updates, Zertifikate, GitOps und Störungsbearbeitung. Ihre Entwickler kümmern sich um das Produkt, TechOneOps hält die Plattform stabil. Auf Hetzner bleiben die Infrastrukturkosten niedrig, und wir übernehmen auch den Cluster, den Sie bereits haben.
Monitoring des Clusters, auch von außerhalb des Clusters
Selbst betriebene Cluster mit mehreren Control-Plane-Knoten
Cluster-Konfiguration versioniert in Git und nachvollziehbar
Ein günstiger Cluster ist nur günstig, solange er läuft.
Selbst betriebenes Kubernetes auf Hetzner Cloud ist schnell, preiswert und vollständig unter Ihrer Kontrolle. Es bedeutet aber auch: Niemand sonst achtet auf Control Plane, Volumes und Backups.
In vielen Start-ups und technischen Teams haben ein oder zwei Entwickler den Cluster aufgebaut und inzwischen andere Aufgaben. Updates werden verschoben, Alarme einmal eingestellt und vergessen, und ob sich ein Backup tatsächlich wiederherstellen lässt, hat niemand geprüft.
TechOneOps übernimmt diese Betriebsebene. Sie behalten den Kostenvorteil von Hetzner und gewinnen ein Team, das den Aufbau Ihres Clusters kennt, ihn rund um die Uhr überwacht und bei Störungen eingreift.
Womit wir arbeiten
Wir betreiben k3s auf Hetzner Cloud produktiv, mit mehreren Control-Plane-Knoten, vollständig als Code aufgebaut. Ein typischer Stack sieht zum Beispiel so aus. Setzen Sie andere Werkzeuge ein, arbeiten wir mit Ihren.
Cluster
k3s auf Hetzner Cloud mit hochverfügbarer Control Plane, getrennten Worker-Pools sowie Floating IPs oder Load Balancern, wo nötig.
Infrastruktur als Code
Terraform für Server, Netzwerke und Firewalls, Packer für reproduzierbare Node-Images. Ein Neuaufbau folgt dem Code, nicht dem Gedächtnis einzelner Personen.
Deployment und GitOps
Helm-Charts, ArgoCD gleicht den Cluster mit Git ab, CI-Pipelines etwa mit GitHub Actions für Build und Release.
Speicher und Backup
Longhorn für persistente Volumes, Velero für Cluster- und Volume-Backups, mit Kopien außerhalb des Clusters, zum Beispiel in Object Storage.
Datenverkehr und Zertifikate
Ingress, cert-manager für die automatische Verlängerung von TLS-Zertifikaten sowie DNS und Schutz am Netzwerkrand über Anbieter wie Cloudflare.
Monitoring und Logs
Prometheus für Metriken, Loki für Logs, Grafana für Dashboards und Alarme, Sentry für Anwendungsfehler.
Worauf wir achten
Cluster fallen selten auf einen Schlag aus. Sie weichen schleichend vom Sollzustand ab. Diese Bereiche prüfen wir regelmäßig und ergänzen weitere, wo Ihre Umgebung es erfordert.
| Bereich | Was wir prüfen | Warum es wichtig ist |
|---|---|---|
| Monitoring-Konfiguration als Code | Dashboards, Alarmregeln und Scrape-Konfiguration sind in Git versioniert, nicht von Hand geändert | Das Monitoring übersteht einen Neuaufbau, Änderungen bleiben nachvollziehbar |
| Erfassung von Metriken | Alle Ziele werden abgefragt, keine stillen Lücken nach Updates oder neuen Deployments | Ein Alarm, der nie auslöst, ist schlimmer als keiner |
| Speicher | Passende Storage Classes, Volume-Größen, Zustand der Replikate und freie Kapazität | Volle oder beschädigte Volumes sind eine häufige Ausfallursache |
| Backups | Velero-Zeitpläne laufen vollständig, Kopien liegen außerhalb des Clusters, jeden Monat wird ein ausgewähltes Backup testweise wiederhergestellt | Erst die Testwiederherstellung zeigt, ob ein Backup im Ernstfall hilft |
| Überwachung von außen | Endpunkte und der Cluster selbst werden zusätzlich von außerhalb des Clusters überwacht | Fällt der Cluster aus, fällt sein eigenes Monitoring mit aus |
| Bestand in der Hetzner-Konsole | Server, Datenträger, Snapshots, Floating IPs und Load Balancer im Abgleich mit dem, was der Code beschreibt | Vergessene Ressourcen kosten Geld und verbergen Risiken |
| Images und Abhängigkeiten | Container-Images und Abhängigkeiten auf bekannte Schwachstellen geprüft, Basis-Images aktuell gehalten | Viele Sicherheitslücken stecken in veralteten Komponenten |
| Secrets und Zugriffe | Wie Secrets gespeichert und erneuert werden, wer Zugriff auf den Cluster hat, welche Service-Accounts bestehen | Zugriffe, die niemand prüft, wachsen mit der Zeit |
Jeden Monat schriftlich
Jeden Monat erhalten Sie einen Bericht mit Datum, ausführender Person und technischem Nachweis zu jeder Prüfung. Jede Prüfung wird mit der Ausgangsbasis aus dem Audit verglichen, sodass Änderungen und neue Abweichungen sofort sichtbar sind.
Monatliche Cluster-Prüfung
| Prüfung | Erledigt | Anmerkung |
|---|---|---|
| Updates für k3s und Betriebssystem der Knoten | Ja | Snapshot vor dem Update, Versionen vorher und nachher erfasst, Knoten einzeln geleert und aktualisiert |
| Velero-Backups und Testwiederherstellung | Ja | Alle geplanten Backups vollständig, ausgewählter Namespace in einen Test-Namespace wiederhergestellt und geprüft |
| Zertifikate | Ja | Alle Zertifikate über cert-manager verwaltet, keines läuft in den nächsten 30 Tagen ab |
| Bestand in der Hetzner-Konsole | Ja | Zwei nicht verbundene Volumes gefunden, zur Freigabe vor dem Löschen aufgeführt |
| Image-Prüfung | Ja | Ein Basis-Image mit bekannter Schwachstelle, Update als separater Punkt vorgeschlagen |
Das Beispiel dient der Veranschaulichung. Arbeiten über den vereinbarten Umfang hinaus führen wir im Bericht gesondert auf und stimmen sie vorab mit Ihnen ab.
So beginnen wir
Drei Schritte, von denen jeder für sich einen Nutzen hat.
Cluster-Audit
In den ersten zwei Wochen erhalten wir Zugänge und eine Wissensübergabe von Ihrem Team, prüfen Infrastruktur-Code, Helm-Charts und GitOps-Repositories, verifizieren den laufenden Cluster und richten Monitoring und Alarmierung ein. Sie erhalten priorisierte Befunde.
Monatliche Betreuung
Ab der dritten Woche betreiben wir den Cluster: vorbeugende Prüfungen, Updates, Testwiederherstellungen und Log-Auswertung jeden Monat, mit schriftlichem Bericht im Vergleich zur Ausgangsbasis.
SLA
Support zu Geschäftszeiten (Mo–Fr, 9–17 Uhr MEZ/MESZ) oder 24/7, das Monitoring des Clusters läuft in beiden Varianten rund um die Uhr. Standard: Reaktion auf Störungen innerhalb von 4 Stunden, Wiederherstellung des Dienstes innerhalb von 8 Stunden, schneller nach Vereinbarung. Eine Verfügbarkeitszusage vereinbaren wir, sobald wir den Cluster aus dem Audit kennen.
Klare Grenzen zwischen Plattform und Produkt
Wir betreiben die Plattform. Ihre Entwickler verantworten die Anwendung. Wo beides zusammenkommt, arbeiten wir gemeinsam.
- Im Support enthalten: Bereitschaft, Monitoring rund um die Uhr, Diagnose, Eskalation, Wiederherstellung des Dienstes und eine schriftliche Ursachenanalyse nach jeder Störung.
- Betrifft eine Störung die Anwendung, ein Deployment oder eine Konfigurationsänderung, stimmen wir uns direkt mit Ihren Entwicklern ab.
- Entwicklung, Leistungsoptimierung und Migrationen bieten wir vorab an und führen sie nach Ihrer Freigabe aus. Ausgenommen sind dringende Arbeiten an einer laufenden Störung.
- Auf Fragen und Änderungswünsche reagieren wir innerhalb eines Arbeitstags (Mo–Fr). Geplante Wartungen kündigen wir mindestens 24 Stunden vorher an, in der Regel außerhalb der Geschäftszeiten.
- Kein Lock-in. Alles liegt in Ihren Git-Repositories, und bei Vertragsende übergeben wir Dokumentation, Konfigurationen, Skripte und Zugänge.
Fragen zur Kubernetes-Betreuung.
Arbeiten Sie nur mit k3s auf Hetzner?
Nein. Mit k3s auf Hetzner Cloud haben wir die meiste Erfahrung, wir arbeiten aber auch mit anderen Kubernetes-Distributionen, dedizierten Servern und anderen Anbietern. Das Audit zeigt, was Ihr Cluster braucht.
Müssen wir unsere Werkzeuge wechseln?
Nein. Der oben beschriebene Stack ist ein Beispiel. Wir arbeiten mit Ihren bestehenden Werkzeugen für CI, Deployment und Monitoring und schlagen Änderungen nur vor, wo sie Risiko oder Aufwand spürbar senken.
Können Sie uns vom Kubernetes-Dienst eines großen Cloud-Anbieters zu Hetzner umziehen?
Ja. Wir planen den Ziel-Cluster, bauen ihn als Code auf, betreiben ihn parallel zu Ihrer bisherigen Umgebung und schalten in einem vereinbarten Zeitfenster um. Migrationen bieten wir vor Beginn separat an.
Wer kümmert sich um eine Störung, die unsere Anwendung verursacht?
Wir erkennen sie, analysieren sie und stellen den Dienst wieder her, soweit das auf Plattformseite möglich ist, zum Beispiel durch das Zurücksetzen eines Releases. Die dauerhafte Lösung erarbeiten wir mit Ihren Entwicklern und dokumentieren die Ursache schriftlich.
Was benötigen Sie von uns für den Start?
Zugang zum Cluster, zum Hetzner-Projekt und zu Ihren Repositories, eine kurze Systembeschreibung, eine Liste berechtigter Personen und Zeit mit den Personen, die den Aufbau heute kennen.
Den Cluster behalten. Die Bereitschaft abgeben.
Erzählen Sie uns, wie Ihr Cluster aufgebaut ist und was Ihnen Sorgen bereitet. Wir antworten innerhalb eines Arbeitstags und schlagen Ihnen den Umfang eines Audits und die nächsten Schritte schriftlich vor. Unverbindlich.