GEMANAGTES KUBERNETES

Ein Kubernetes-Cluster
production-ready in 5 Minuten.

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

KONTAKTIEREN SIE UNSERE EXPERTEN ARCHITEKTUR ANSEHEN
Verfügbare Addons
kubectl
Helm
FluxCD
cert-manager
Cilium

3 DC

Schweizer Datenzentren
(Geneva, Gland, Lucerne)

5 mins

Cluster bereit

0 Masters

die verwaltet werden müssen. Control Plane verwaltet.

API K8's

standard. Kein Lock-in.
Architektur

Ein schlüsselfertiges, verwaltetes Kubernetes.

Control Plane, etcd, Scheduling und Updates - das ist Hikube. Ihre Workers bleiben in Ihrem Tenant und stehen unter Ihrer vollständigen Kontrolle. Zugriff über die standardmäßige Kubernetes-API.

  • wartungsfreie, verwaltete control plane
    kube-apiserver, etcd, scheduler und controller-manager werden von Hikube gehostet und betrieben. Über mehrere Standorte hinweg repliziert.

  • Workers-Knoten in Ihrem Tenant
    Ihre Workers sind VMs in Ihrem tenant. Sie konfigurieren sie über deklarative node groups - Instanztyp, Skalierung, Rollen, GPU.

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

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

  • Cilium als standardmäßiger CNI.
    Pod-to-Pod-Netzwerk, NetworkPolicies und Hubble-Observabilität enthalten. Default-allow-Politik 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.

STOCKAGE

Repliziertes PVC

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

Vollständig deklarative Konfiguration

Cluster, Knotengruppen, Add-ons ... alles wird über ein YAML-Manifest und kubectl apply konfiguriert. Änderungen werden im Rolling Update ohne Downtime übernommen.
Einschalten

Ein Cluster in ein paar Zeilen YAML.

Erklären Sie Ihren Cluster, wenden Sie ihn an, holen Sie sich Ihr kubeconfig. Die control plane ist in wenigen Klicks fertig.

yaml
apiVersion: apps.cozystack.io/v1alpha1
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 Node-Gruppe muss dieses Feld deklarieren, auch wenn es leer ist. Ohne dieses Feld werden die CPU/RAM-Werte nicht vom instanceType vererbt.

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

  • Skalierung auf Null für GPU-Workloads.
    minReplicas: 0 auf einer GPU-Nodegruppe ermöglicht es, nur dann Ressourcen zu verbrauchen, wenn GPU-Pods tatsächlich geplant sind.

Instanzentypen

Drei Produktreihen für jeden Workload-Typ.

Jede Produktreihe ist von small bis 8xlarge erhältlich. Wählen Sie nach dem für Ihre Auslastung 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 Node Group anzupassen:

  • s1 für allgemeine Workers und Ingress.
    Ausgewogenes CPU:RAM-Verhältnis für Webanwendungen und Microservices ohne besonderen Speicherbedarf.

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

  • m1 für verbrauchsintensive Workloads.
    Ideal für Monitoring, Caches und Indexe-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 Speicherung

PVCs, die auf drei Rechenzentren repliziert werden.

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

STORAGECLASS
REPLIKATION
VERHALTEN
Lokal
Ein einziges Rechenzentrum
Keine Replikation, minimale Latenz
replicated
Synchrones Multi-Datacenter
Bestätigtes Schreiben an allen 3 Standorten vor der Rückkehr
replicated-async
Asynchrones Multi-Datacenter
Lokales Schreiben und dann verzögerte Ausbreitung
ADD-ONS

Aktivieren Sie, was Sie brauchen

Jedes Add-on wird in einer Zeile im Clustermanifest 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 Behörde. Automatische Verlängerung.
Bild 61-2

Gateway API

Erweitertes HTTP/HTTPS-Routing nach dem Kubernetes-Standard. Feinsteuerung des eingehenden Datenverkehrs und Multi-Protokoll-Unterstützung.
Bild 61-1

Monitoring

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

GPU Operator

Automatische NVIDIA-Treiber auf GPU-Knoten. Erforderlich für die Nutzung von GPU-Workloads in Kubernetes.
Bild 61-4

FluxCD

Natives GitOps, das eine kontinuierliche Synchronisation von Ihrem Git-Repository aus gewährleistet. Automatisierte Deployments und Rollbacks.
GEBRAUCHSFALL

Häufige Architekturen auf Hikube.

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

WEBANWENDUNG

Application Stack mit Ingress und TLS

Web-Group-Node mit ingress-nginx-Rolle, Cert-Manager für Let's Encrypt-Zertifikate, Autoskalierung zwischen 2 und 10 Knoten je nach Datenverkehr.
sl.large ingress-nginx cert-manager replicated

GITOPS

Kontinuierliche Bereitstellungen aus Git mit FluxCD

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

ML / AI

Hybrid-Cluster aus CPU + GPU mit Scale to Zero

GPU-Knotengruppe mit minReplicas: 0 - GPU-Knoten laufen nur, wenn Jobs geplant werden. CPU-Knotengruppe: Permanent für die Orchestrierung.
u1.2xbreit L40S GPU gpuOperator 500Gi

OBSERVABILITÄT

Node group dedicated to monitoring

Node group m1.xlarge 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 gemanagtes Kubernetes

Weniger Ops, mehr Zeit für Ihre Workloads.

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

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

Die Multi-Datacenter-Replikation an drei Schweizer Standorten ist für Ihre Workloads transparent. Ihre PVCs sind auch dann verfügbar, wenn ein Datacenter nicht erreichbar ist, ohne zusätzliche Konfiguration auf Ihrer Seite.

Vektor (Stroke)-2

Keine Wartung des control plane

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

Vektor (Stroke)-2

GPU und CPU auf demselben Cluster

Spezialisierte Node Groups ermöglichen es Ihnen, Ihre APIs und ML-Pipelines auf derselben Infrastruktur laufen zu lassen, orchestriert von derselben Controll Plane.

Vektor (Stroke)-2

Deklaratives und 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 Knoten hinzu oder entfernt sie.

Vektor (Stroke)-2

Daten in der Schweiz, souveräne Architektur

Drei unabhängige Schweizer Rechenzentren. Native DSGVO- und nLPD-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 Knoten 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), das mehr RAM pro Kern liefert. 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 in der Produktion verwendet werden?

replicated ist die Standardempfehlung für die Produktion. Sie repliziert Ihre persistenten Volumes synchron über die drei Schweizer Rechenzentren - Ihre Daten bleiben auch dann zugänglich, wenn ein Standort ausfällt.

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-Knoten zu einem bestehenden Cluster hinzu?

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

Beachten Sie: Jeder Knoten in der Knotengruppe GPU verbraucht einen physischen Grafikprozessor. Eine Knotengruppe mit minReplicas: 4 beansprucht ständig 4 GPUs - verwenden Sie minReplicas: 0, wenn Ihre GPU-Workloads nur zeitweise anfallen.

Wie bekomme ich meinen kubeconfig zurück?

Das kubeconfig wird bei der Erstellung des Clusters automatisch generiert und in einem Kubernetes Secret gespeichert.

Kann ich FluxCD verwenden, um meine Anwendungen bereitzustellen?

Ja - Aktiviere das fluxcd-Addon im Clustermanifest mit der URL deines Git-Repositorys. FluxCD synchronisiert automatisch alle YAML-Manifeste des Repositoriums in Ihrem Cluster. Ein Push auf Ihrem Hauptzweig löst eine Bereitstellung aus, ohne dass eine manuelle Aktion erforderlich ist.

Für private Repositories konfigurieren Sie die SSH- oder Token-Authentifizierung im Cluster nach der ersten Bereitstellung von Flux.