MANAGED KUBERNETES

Ein produktionsbereiter Kubernetes-Cluster in 5 Minuten.

Control Plane vollständig von Hikube verwaltet, Worker-Nodes in Ihrem Tenant. Replizierter Speicher in 3 Rechenzentren. Sie behalten die Kontrolle über Ihre Workloads, wir kümmern uns um den Rest.

KOSTENLOS STARTEN ARCHITEKTUR ANSEHEN
Verfügbare Add-ons
kubectl
Helm
FluxCD
cert-manager
Cilium

3 DC

Schweizer Datenzentren
(Genf, Gland, Luzern)

5 mins

Cluster bereit

0 Masters

zu verwalten. Verwaltete Control Plane.

API K8's

standard. Kein Lock-in.
Architektur

Schlüsselfertiges, verwaltetes Kubernetes.

Control Plane, etcd, Scheduling und Updates — das übernimmt Hikube. Ihre Worker bleiben in Ihrem Tenant, unter Ihrer vollständigen Kontrolle. Zugriff über die Standard-Kubernetes-API.

  • Wartungsfreie, verwaltete Control Plane
    kube-apiserver, etcd, scheduler und controller-manager werden von Hikube gehostet und betrieben. Über mehrere Standorte repliziert.

  • Workers-Nodes in Ihrem Tenant
    Ihre Workers sind VMs in Ihrem tenant. Sie konfigurieren sie über deklarative Nodegroups - Instanztyp, Scaling, Rollen, GPU.

  • Replizierter Speicher in 3 Rechenzentren
    Ihre persistenten Volumes werden automatisch über Genf, Gland und Luzern repliziert. Native Hochverfügbarkeit auf Speicherebene.

  • Standard-Kubernetes-API 
    Zugriff über kubectl, Client-SDK, Terraform oder jedes kompatible Tool. Keine proprietären Tools erforderlich.

  • Cilium als Standard-CNI
    Pod-to-Pod-Netzwerk, NetworkPolicies und Hubble-Observability inklusive. Default-allow-Policy jederzeit änderbar.

CONTROL PLANE - VERWALTET VON HIKUBE

kube-apiserver etcd x3 scheduler controller-manager

NODE GROUPS

Workers (Ihr Tenant)

VMs mit autoscaling min/max. Getrennt nach Rollen und Lasttypen...

NETZWERK

Cilium CNI

NetworkPolicy, Hubble observability, LoadBalancer, Ingress NGINX.

SPEICHER

Repliziertes PVC

Dynamisches Provisioning. 3 Backends: Genf - Gland - Luzern.

Vollständig deklarative Konfiguration

Cluster, Nodegroups, Add-ons … alles wird über ein YAML-Manifest und kubectl apply konfiguriert. Änderungen werden als Rolling Update ohne Downtime übernommen.
ERSTE SCHRITTE

Ein Cluster in wenigen Zeilen YAML.

Deklarieren Sie Ihren Cluster, wenden Sie ihn an, holen Sie sich Ihre kubeconfig. Die Control Plane ist in wenigen Klicks bereit.

yaml
kind: Kubernetes
metadata:
  name: my-first-cluster
spec:
  controlPlane:
    replicas: 2
    storageClass: "replicated"
  nodeGroups:
    general:
      minReplicas: 1
      maxReplicas: 5
      instanceType: "s1.large" # 4 vCPU, 8 GB RAM
      ephemeralstorage: 50G1
      resources：{}
      roles:
        - ingress-nginx
addons:
  certManager:
    enabled: true
  ingressNginx:
    enabled: true
bash
# Stellen Sie den Cluster bereit.
kubectl apply -f my-first-cluster. yaml

# Rufen Sie den kubeconfig ab.
kubectl get tenantsecret my-first-cluster admin-
kubeconfig \
 -o jsonpath='{.data.super-admin}'. \
 | base64 -d > kubeconfig.yaml

# Überprüfen Sie die Knotenpunkte.
export KUBECONFIG-kubeconfig.yaml
kubectl get nodes

Einige Punkte, die Sie sich für einen guten Start merken sollten:


  • replicas: 3 für die Produktion
    Eine ungerade Anzahl von Replikas wird empfohlen, um das etcd-Quorum und die Hochverfügbarkeit der Control-Plane zu gewährleisten.

  • resources: {} ist obligatorisch.
    Jede Nodegroup muss dieses Feld deklarieren, auch leer. Ohne es werden die CPU/RAM-Werte nicht vom instanceType geerbt.

  • Trennen Sie Ihre Nodegroup nach Rolle.
    Web, Compute, Monitoring, GPU - getrennte Gruppen ermöglichen ein unabhängiges Autoscaling und bessere Kostenkontrolle.

  • Scale-to-Zero für GPU-Workloads.
    minReplicas: 0 auf einer GPU-Nodegroup verbraucht nur dann Ressourcen, wenn GPU-Pods tatsächlich geplant sind.

Instanzentypen

Drei Reihen für jeden Workload-Typ.

Jede Reihe ist von small bis 8xlarge verfügbar. Wählen Sie nach dem für Ihre Last geeigneten CPU/RAM-Verhältnis. 

PALETTE
RATIO
EMPFOHLENE VERWENDUNG
s1 - Standard
1:2
vCPU:RAM
Allgemeine Workloads, Webserver
u1 - Universal
1:4
vCPU:RAM
Geschäftsanwendungen, Datenbanken
m1 - Memory
1:8
vCPU:RAM
Cache, analytics, monitoring, ML

Die bewährte Praxis ist, den Bereich an die Rolle der Nodegroup anzupassen:

  • s1 für allgemeine Worker und Ingress.
    Ausgewogenes CPU:RAM-Verhältnis für Webanwendungen und Microservices.

  • u1 für Compute und GPU-Workloads.
    Mehr RAM pro Kern, empfohlen für ML-Pipelines und Datenbanken. Verhältnis passend an 8-16 vCPUs pro GPU.

  • m1 für speicherintensive Workloads.
    Ideal für Monitoring, Caches und Indexierungs-Engines, die RAM gegenüber CPUs bevorzugen.

Beispiele:

s1.large = 4 vCPUs / 8 GB - u1.2xlarge = 8 vCPUs / 32 GB - m1.xlarge = 4 vCPUs / 32 GB. Vollständige Tabelle
Persistente Speicher

PVCs, repliziert über drei Rechenzentren.

Jedes PVC wird dynamisch provisioniert und kann je nach gewählter StorageClass auf Genf, Gland und Luzern repliziert werden.

STORAGECLASS
REPLIKATION
VERHALTEN
local
Einzelnes Rechenzentrum
Keine Replikation, minimale Latenz
replicated
Synchron, Multi-Rechenzentrum
Schreibvorgang an allen 3 Standorten bestätigt, bevor zurückgegeben wird
replicated-async
Asynchron, Multi-Rechenzentrum
Lokaler Schreibvorgang, dann verzögerte Verteilung
ADD-ONS

Aktivieren Sie, was Sie brauchen

Jedes Add-on wird in einer Zeile im Cluster-Manifest aktiviert. Sie werden automatisch in Ihrem Tenant-Cluster bereitgestellt und gepflegt.

Cert-Manager

Cert-Manager

Automatische TLS-Zertifikate über Let's Encrypt oder Ihre private Zertifizierungsstelle (CA). Automatische Erneuerung.
Bild 61-2

Gateway API

Erweitertes HTTP/HTTPS-Routing nach dem Kubernetes-Standard. Feinkörnige Steuerung des eingehenden Traffics und Multi-Protokoll-Unterstützung.
Bild 61-1

Monitoring

Node Exporter, Fluent Bit, Kube-State-Metrics. Integration mit Grafana und VictoriaMetrics des Tenants.
Bild 61-3

GPU Operator

Automatische NVIDIA-Treiber auf GPU-Nodes. Erforderlich, um GPU-Workloads auf Kubernetes auszuführen.
Bild 61-4

FluxCD

Natives GitOps für kontinuierliche Synchronisation aus Ihrem Git-Repository. Automatisierte Deployments und Rollback.
ANWENDUNGSFÄLLE

Häufige Architekturen auf Hikube.

In der Produktion getestete Konfigurationen für die häufigsten Patterns.

WEBANWENDUNG

Application Stack mit Ingress und TLS

Web-Nodegroup mit ingress-nginx-Rolle, cert-manager für Let's-Encrypt-Zertifikate, Autoscaling zwischen 2 und 10 Nodes je nach Traffic. 
sl.large ingress-nginx cert-manager replicated

GITOPS

Kontinuierliche Bereitstellungen aus Git mit FluxCD

FluxCD synchronisiert Ihr Git-Repository jede Minute. Push auf main = automatisches Deployment im Cluster. Rollback über Git revert.
fluxcd cert-manager cert-ingress-nginx

ML / KI

Hybrid-Cluster aus CPU + GPU mit Scale-to-Zero

GPU-Nodegroup mit minReplicas: 0 — GPU-Nodes laufen nur, wenn Jobs geplant sind. Permanente CPU-Nodegroup für die Orchestrierung.
u1.2xbreit L40S GPU gpuOperator 500Gi

OBSERVABILITY

Dem Monitoring gewidmete Nodegroup

m1.xlarge-Nodegroup mit Monitoring-Rolle und großzügigem ephemeren Speicher (200Gi). VictoriaMetrics, Grafana und Fluent Bit isoliert vom Rest der Workloads. 
m1.xlarge monitoringAgenten 200Gi
Warum Verwaltetes Kubernetes

Weniger Ops, mehr Zeit für Ihre Workloads.

Eine Kubernetes-Control-Plane in Produktion zu halten bedeutet, Versions-Upgrades zu verwalten, die etcd-Gesundheit zu überwachen, interne Zertifikate zu pflegen und sicherzustellen, dass das Quorum jederzeit erhalten bleibt. Das ist nicht kompliziert, kostet aber Zeit und Aufmerksamkeit.

Auf Hikube entfällt dieser operative Aufwand. Sie deklarieren, was Sie wollen — Clustergröße, Nodegroups, Add-ons — und die Plattform kümmert sich um den Rest. Sie behalten vollen Zugriff über die Standard-Kubernetes-API: kubectl, Helm, Terraform und FluxCD funktionieren genau wie auf einem selbstverwalteten Cluster.

Die Multi-Rechenzentrum-Replikation über drei Schweizer Standorte ist für Ihre Workloads transparent. Ihre PVCs bleiben verfügbar, selbst wenn ein Rechenzentrum nicht erreichbar ist, ohne zusätzliche Konfiguration auf Ihrer Seite.

Vektor (Stroke)-2

Keine Control-Plane-Wartung

Kubernetes-Upgrades, Rotation interner Zertifikate, etcd-Überwachung — alles von Hikube verwaltet. Sie konsumieren die API, nicht die Infrastruktur.

Vektor (Stroke)-2

GPU und CPU im selben Cluster

Spezialisierte Nodegroups ermöglichen es Ihnen, Ihre APIs und ML-Pipelines auf derselben Infrastruktur laufen zu lassen, orchestriert von derselben Controll Plane. Mehr über GPUs erfahren

Vektor (Stroke)-2

Deklaratives, automatisches Scaling

Ändern Sie maxReplicas in Ihrem YAML und wenden Sie es an. Der Autoscaler fügt je nach dem tatsächlichen CPU-/Speicherdruck Ihrer Pods Nodes hinzu oder entfernt sie.

Vektor (Stroke)-2

Daten in der Schweiz, souveräne Architektur

Drei unabhängige Schweizer Rechenzentren. Native DSGVO- und revDSG-Konformität.

FAQ

Frage zu Kubernetes as a Service

Welche Instanz soll ich für meine Workers wählen?

Es kommt darauf an, was auf den Nodes läuft. Für klassische Webanwendungen und Microservices ist s1 (Verhältnis 1:2) der richtige Ausgangspunkt. Für Datenbanken, Datenpipelines oder GPU-Worker bevorzugen Sie u1 (Verhältnis 1:4) mit mehr RAM pro Kern. Reservieren Sie m1 (Verhältnis 1:8) für wirklich speicherintensive Lasten — Monitoring, Caches, Analytics.

Wie funktioniert Autoscaling?

Das Autoscaling wird durch minReplicas und maxReplicas auf jeder Node Group gesteuert. Wenn Pods mangels Ressourcen im Status Pending bleiben, werden automatisch neue Knoten bereitgestellt. Wenn die Last abnimmt, werden nicht ausgelastete Knoten gelöscht - ohne unter minReplicas zu gehen.

Sie können die Grenzwerte jederzeit anpassen, indem Sie das Manifest ändern und kubectl apply erneut starten. Für GPU- oder Entwicklungs-Workloads erlaubt minReplicas: 0 das Herunterfahren auf null Knoten, wenn es nichts zu tun gibt - planen Sie ein paar Minuten cold start beim ersten geplanten Pod ein.

Welche storageClass soll ich in der Produktion verwenden?

replicated ist die Standardempfehlung für die Produktion. Sie repliziert Ihre persistenten Volumes synchron über die drei Schweizer Rechenzentren - Ihre Daten bleiben auch bei einem Standortausfall zugänglich.

local ist schneller (eine einzige Kopie, weniger Latenz), aber ohne Hochverfügbarkeit auf Speicherebene - reservieren Sie sie für die Entwicklung oder wirklich temporäre Daten.

Wie fügt man GPU-Nodes zu einem bestehenden Cluster hinzu?

Fügen Sie eine neue Nodegroup mit dem Feld gpus[] in Ihrem Manifest hinzu, aktivieren Sie das gpuOperator-Addon und wenden Sie es an. Der GPU Operator installiert die NVIDIA-Treiber automatisch auf den neuen Nodes.

Hinweis: JJeder Node der GPU-Nodegroup verbraucht eine physische GPU. Eine Nodegroup mit minReplicas: 4 beansprucht ständig 4 GPUs - verwenden Sie minReplicas: 0, wenn Ihre GPU-Workloads nur zeitweise anfallen.

Wie erhalte ich meine kubeconfig?

Die kubeconfig wird bei der Cluster-Erstellung automatisch generiert und in einem Kubernetes Secret gespeichert.

Kann ich FluxCD verwenden, um meine Anwendungen bereitzustellen?

Ja - Aktiviere Sie das fluxcd-Addon im Cluster-Manifest mit der URL Ihres Git-Repositorys. FluxCD synchronisiert automatisch alle YAML-Manifeste des Repositoriums in Ihrem Cluster. Ein Push auf Ihren Hauptbranch löst ein Deployment ohne manuelle Aktion aus.

Für private Repositorys konfigurieren Sie nach dem ersten Flux-Deployment die SSH- oder Token-Authentifizierung im Cluster.