MANAGED KUBERNETES

A Kubernetes cluster
production-ready in 5 minutes

Control plane fully managed by Hikube, worker nodes in your tenant. Replicated storage across 3 datacenters. You keep control of your workloads, we take care of the rest.

CONTACT OUR EXPERTS SEE THE ARCHITECTURE
Addons available
kubectl
Helm
FluxCD
cert-manager
Cilium

3 DC

Swiss data centers
(Geneva, Gland, Lucerne)

5 mins

Cluster ready

0 Masters

to manage. Managed control plane.

API K8's

standard. No lock-in.
Architecture

Turnkey managed Kubernetes

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

  • Maintenance-free, managed control plane
    kube-apiserver, etcd, scheduler and controller-manager are hosted and operated by Hikube. Replicated on 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.

  • Replicated storage across 3 datacenters
    Your persistent volumes are automatically replicated to Geneva, Gland and Lucerne. Native high availability at storage level.

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

  • Cilium as default NIC
    Pod-to-pod network, NetworkPolicies and Hubble observability included. Default-allow policy modifiable 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 in rolling update without downtime.
Getting started

A cluster in a few lines of YAML

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

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
# 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 the etcd quorum and high availability of the control plane.

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

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

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

types of instances

Three ranges for every type of workload

Each range is available from small to 8xlarge. Choose the right CPU/RAM ratio for 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 adapted to 8-16 vCPUs per GPU.

  • m1 for power-hungry workloads
    Ideal for monitoring, caching and indexing engines that prefer 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 datacenters

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

STORAGECLASS
REPLICATION
BEHAVIOR
local
A single datacenter
No replication, minimal latency
replicated
Synchronous multi-datacenter
Writing confirmed on 3 sites before return
replicated-async
Asynchronous multi-datacenter
Local writing then delayed propagation
ADD-ONS

Activate what you need

Each add-on is activated by a single line in the cluster manifest. They are automatically deployed and maintained 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 incoming 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 synchronization from your Git repository. Automated deployment and rollback.
USE CASES

Common Hikube architectures

Production-tested configurations for the most common patterns.

WEB APPLICATION

Application stack with Ingress and TLS

Node group web with 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 synchronizes your Git repository every minute. Push on main = automatic deployment in the cluster. Rollback via Git revert.
fluxcd cert-manager cert-ingress-nginx

ML / AI

Hybrid CPU + GPU cluster with zero scaling

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

OBSERVABILITY

Node group dedicated to monitoring

Node group m1.xlarge with 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 managing version upgrades, monitoring the health of etcd, managing internal certificates, and ensuring that quorum is preserved at all times. It's not complicated, but it does take time and attention.

With Hikube, this operational burden disappears. You declare what you want: cluster size, node groups, add-ons and the platform takes care of the rest. You retain full access via the standard Kubernetes API: kubectl, Helm, Terraform and FluxCD work exactly as on a self-managed cluster.

Multi-datacenter replication across three Swiss sites is transparent to your workloads. Your PVCs are available even if one datacenter is inaccessible, without any additional configuration on your part.

Vector (Stroke)-2

No control plane maintenance

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

Vector (Stroke)-2

GPU and CPU on the same cluster

Specialized node groups let you run your APIs and ML pipelines on the same infrastructure, orchestrated by the same control plane.

Vector (Stroke)-2

Declarative and automatic scaling

Change maxReplicas in your YAML and apply. The autoscaler adds or removes nodes according to the actual CPU/memory pressure of your pods.

Vector (Stroke)-2

Swiss data, sovereign architecture

Three independent Swiss data centers. Native RGPD and nLPD compliance.

FAQ

Question about Kubernetes as a Service

Which instance should I choose for my workers?

It depends on what's running on the nodes. For web applications and classic microservices, s1 (ratio 1:2) is the right starting point. For databases, data pipelines or GPU workers, u1 (ratio 1:4) gives more RAM per core. Reserve m1 (ratio 1:8) for really memory-hungry loads - 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 to use in production?

replicated is the default recommendation for production. It replicates your persistent volumes synchronously across the three Swiss datacenters - your data remains accessible even in the event of a site failure.

local is faster (a single copy, less latency) but without high storage availability - reserve it for development or truly temporary data.

How do I add GPU nodes to an existing cluster?

Add a new node group with the gpus[] field in your manifest, activate the gpuOperator addon, and apply. The GPU Operator will automatically install NVIDIA drivers on the new nodes.

Please note: each node in the GPU node group consumes one physical GPU. A node group with minReplicas: 4 uses 4 GPUs at all times - consider using minReplicas: 0 if your GPU workloads are intermittent.

How do I get my kubeconfig back?

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

Can I use FluxCD to deploy my applications?

Yes - enable the fluxcd addon in the cluster manifest with the URL of your Git repository. FluxCD automatically synchronizes all repository YAML manifests in your cluster. A push on your main branch triggers deployment without any manual action.

For private repositories, configure SSH or token authentication in the cluster after initial Flux deployment.