MANAGED KUBERNETES

A production-ready Kubernetes cluster in 5 minutes

Control plane fully managed by Hikube, worker nodes in your tenant. Storage replicated across 3 datacentres. You keep control of your workloads, we handle the rest.

TRY FOR FREE SEE THE ARCHITECTURE
Available add-ons
kubectl
Helm
FluxCD
cert-manager
Cilium

3 DC

Swiss data centres
(Geneva, Gland, Lucerne)

5 mins

Cluster ready

0 Masters

to manage. Managed control plane.

API K8's

standard. No lock-in.
Architecture

Managed Kubernetes, turnkey

The control plane, etcd, scheduling and updates - that's Hikube. Your workers stay in your tenant, under your full control. Access via the standard Kubernetes API.

  • Managed, maintenance-free, control plane
    kube-apiserver, etcd, scheduler and controller-manager are hosted and operated by Hikube. Replicated across multiple sites.

  • Worker nodes in your tenant
    Your workers are VMs in your space. You configure them via declarative node groups - instance type, scaling, roles, GPU.

  • Storage replicated across 3 datacentres
    Your persistent volumes are automatically replicated across Geneva, Gland and Lucerne. Native high availability at the storage level.

  • Standard Kubernetes API
    Access via kubectl, SDK client, Terraform or any compatible tool. No proprietary tooling required.

  • Cilium as default CNI
    Pod-to-pod networking, NetworkPolicies and Hubble observability included. Default-allow policy can be changed at any time.

CONTROL PLANE - MANAGED BY HIKUBE

kube-apiserver etcd x3 scheduler controller-manager

NODE GROUPS

Workers (your tenant)

VMs with min/max autoscaling. Separated by role and load type...

NETWORK

Cilium CNI

NetworkPolicy, Hubble observability, LoadBalancer, Ingress NGINX.

STORAGE

Replicated PVCs

Dynamic provisioning. 3 backends: Geneva - Gland - Lucerne.

Fully declarative configuration

Cluster, node groups, add-ons... everything is configured via a YAML manifest and kubectl apply. Changes are applied as a rolling update without no downtime.
Getting started

A cluster in a few lines of YAML

Declare your cluster, apply it, retrieve your kubeconfig. The control plane is ready in a few clicks.

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
# Deploy the cluster
kubectl apply -f my-first-cluster. yaml

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

# Check nodes
export KUBECONFIG-kubeconfig.yaml
kubectl get nodes

A few points to remember to get started:


  • replicas: 3 for production
    An odd number of replicas is recommended to guarantee etcd quorum and control-plane high availability.

  • resources: {} is mandatory
    Every node group must declare this field, even empty. Without it, CPU/RAM values are not inherited from the instanceType.

  • Separate your node groups by role
    Web, compute, monitoring, GPU - distinct groups allow independent autoscaling and better cost control.

  • Scale to zero for GPU workloads
    minReplicas: 0 on a GPU node group consumes  resources only when GPU pods are actually scheduled.

Instance types

Three families for every workload type

Each family is available from small to 8xlarge. Choose based on the CPU/RAM ratio suited to your workload.

RANGE
RATIO
RECOMMENDED USE
s1 - Standard
1:2
vCPU:RAM
General workloads, web servers
u1 - Universal
1:4
vCPU:RAM
Business applications, databases
m1 - Memory
1:8
vCPU:RAM
Cache, analytics, monitoring, ML

Best practice is to adapt the range to the role of the node group:

  • s1 for general workers and Ingress
    Balanced CPU:RAM ratio for web applications and microservices with no particular memory requirements.

  • u1 for compute and GPU workloads
    More RAM per core, recommended for ML pipelines and databases. Ratio suited to 8-16 vCPUs per GPU.

  • m1 for memory-heavy workloads
    Ideal for monitoring, caches and indexing engines that favour RAM to CPU.

Examples:

s1.large = 4 vCPU / 8 GB - u1.2xlarge = 8 vCPU / 32 GB - m1.xlarge = 4 vCPU / 32 GB. Complete table
Persistent storage

PVCs replicated across three datacentres

Each PVC is dynamically provisioned and can be replicated across Geneva, Gland and Lucerne, depending on the StorageClass chosen.

STORAGECLASS
REPLICATION
BEHAVIOR
local
A single datacentre
No replication, minimal latency
replicated
Synchronous multi-datacentre
Writing confirmed on all 3 sites before returning
replicated-async
Asynchronous multi-datacentre
Local write then deferred propagation
ADD-ONS

Enable what you need

Each add-on is enabled with one line in the cluster manifest. They are deployed and maintained automatically in your tenant cluster.

Cert-Manager

Cert-Manager

Automatic TLS certificates via Let's Encrypt or your private authority. Automatic renewal.
image 61-2

Gateway API

Advanced HTTP/HTTPS routing based on the Kubernetes standard. Fine-grained ingress-traffic management and multi-protocol support.
image 61-1

Monitoring

Node Exporter, Fluent Bit, Kube-State-Metrics. Grafana and VictoriaMetrics integration.
image 61-3

GPU Operator

Automatic NVIDIA drivers on GPU nodes. Required to use GPU workloads in Kubernetes.
image 61-4

FluxCD

Native GitOps, ensuring continuous synchronisation from your Git repository. Automated deployments and rollback.
USE CASES

Common architectures on Hikube

Production-tested configurations for the most common patterns.

WEB APPLICATION

Application stack with Ingress and TLS

Web node group with the ingress-nginx role, cert-manager for Let's Encrypt certificates, autoscaling between 2 and 10 nodes depending on traffic. 
sl.large ingress-nginx cert-manager replicated

GITOPS

Continuous deployment from Git with FluxCD

FluxCD syncs your Git repository every minute. Push to main = automatic deployment to the cluster. Rollback via Git revert. 
fluxcd cert-manager cert-ingress-nginx

ML / AI

Hybrid CPU + GPU cluster with scale-to-zero

GPU node group with minReplicas: 0 — GPU nodes run only when jobs are scheduled. Permanent CPU node group for orchestration. 
u1.2xwide L40S GPU gpuOperator 500Gi

OBSERVABILITY

Node group dedicated to monitoring

m1.xlarge node group with the monitoring role and generous ephemeral storage (200Gi). VictoriaMetrics, Grafana and Fluent Bit isolated from the rest of the workloads. 
m1.xlarge monitoringAgents 200Gi
Why managed Kubernetes

Less ops, more time for your workloads

Maintaining a Kubernetes control plane in production means handling version upgrades, monitoring etcd health, managing internal certificates, and making sure quorum is preserved at all times. It isn't complicated, but it takes time and attention.

On Hikube, that operational load disappears. You declare what you want — cluster size, node groups, add-ons — and the platform handles the rest. You keep full access via the standard Kubernetes API: kubectl, Helm, Terraform and FluxCD work exactly as on a self-managed cluster.

Multi-data-centre replication across three Swiss sites is transparent to your workloads. Your PVCs remain available even if a data centre is unreachable, with no extra configuration on your side.

Vector (Stroke)-2

No control-plane maintenance

Kubernetes upgrades, internal certificate rotation, etcd supervision - all managed by Hikube. You consume the API, not the infrastructure.

Vector (Stroke)-2

GPU and CPU on the same cluster

Specialised node groups let you run your APIs and ML pipelines on the same infrastructure, orchestrated by the same control-plane. Learn more about our GPUs

Vector (Stroke)-2

Declarative and automatic scaling

Change maxReplicas in your YAML and apply. The autoscaler adds or removes nodes based on the real CPU/memory pressure of your pods.

Vector (Stroke)-2

Data in Switzerland, sovereign architecture

Three independent Swiss data centres. Native GDPR and nFADP compliance.

FAQ

Question about Kubernetes as a Service

Which instance should I choose for my workers?

It depends on what runs on the nodes. For classic web applications and microservices, s1 (1:2 ratio) is the right starting point. For databases, data pipelines or GPU workers, prefer u1 (1:4 ratio), which gives more RAM per core. Reserve m1 (1:8 ratio) for genuinely memory-hungry workloads — monitoring, caches, analytics.

How does autoscaling work?

Autoscaling is controlled by minReplicas and maxReplicas on each node group. When pods remain in the Pending state for lack of resources, new nodes are provisioned automatically. When load decreases, under-utilized nodes are removed - without going below minReplicas.

You can adjust the bounds at any time by modifying the manifest and re-running kubectl apply. For GPU or development workloads, minReplicas: 0 allows you to go down to zero nodes when there's nothing to do - allow a few minutes of cold start at the first scheduled pod.

Which storageClass should I use in production?

replicated is the default recommendation for production. It replicates your persistent volumes across the three Swiss data centres synchronously — your data stays accessible even if a site fails.

local is faster (a single copy, less latency) but with no storage-level high availability — reserve it for development or genuinely temporary data.

 

How do I add GPU nodes to an existing cluster?

Add a new node group with the gpus[] field in your manifest, enable the gpuOperator add-on, and apply. The GPU Operator automatically installs the NVIDIA drivers on the new nodes. Note: each node in the GPU node group consumes one physical GPU. A node group with minReplicas: 4 ties up 4 GPUs permanently. Consider minReplicas: 0 if your GPU workloads are intermittent.

 

How do I retrieve my kubeconfig back?

The kubeconfig is generated automatically when the cluster is created and stored in a Kubernetes Secret.

Can I use FluxCD to deploy my applications?

Yes. Enable the fluxcd add-on in the cluster manifest with your Git repository URL. FluxCD automatically syncs all the YAML manifests from the repository into your cluster. A push to your main branch triggers a deployment with no manual action. For private repositories, configure SSH or token authentication in the cluster after Flux's initial deployment.