KUBERNETES MANAGÉ

 Un cluster Kubernetes
production-ready en 5 minutes 

 Control plane entièrement géré par Hikube, nœuds workers dans votre tenant. Stockage répliqué sur 3 datacenters. Vous gardez le contrôle sur vos workloads, nous nous occupons du reste. 

CONTACTEZ NOS EXPERTS VOIR L'ARCHITECTURE
Addons disponibles
kubectl
Helm
FluxCD
cert-manager
Cilium

 3 DC

 Datacenters suisses
(Geneva, Gland, Lucerne) 

 5 mins

 Cluster prêt 

 0 Masters

 à gérer. Control plane managé. 

API K8's

 standard. Aucun lock-in. 
Architecture

 Un Kubernetes managé clé en main 

Le control plane, etcd, le scheduling et les mises à jour — c'est Hikube. Vos workers restent dans votre tenant, sous votre contrôle total. Accès via l'API Kubernetes standard. 

  • Control plane managé sans maintenance
    kube-apiserver, etcd, scheduler et controller-manager sont hébergés et opérés par Hikube. Répliqués sur plusieurs sites.

  • Nœuds workers dans votre tenant
    Vos workers sont des VMs dans votre espace. Vous les configurez via des node groups déclaratifs — type d'instance, scaling, rôles, GPU.

  • Stockage répliqué sur 3 datacenters
    Vos volumes persistants sont automatiquement répliqués sur Genève, Gland et Lucerne. Haute disponibilité native au niveau stockage.

  • API Kubernetes standard
    Accès via kubectl, SDK client, Terraform ou tout outil compatible. Aucun outil propriétaire requis.

  • Cilium comme CNI par défaut
    Réseau pod-to-pod, NetworkPolicies et observabilité Hubble inclus. Politique default-allow modifiable à tout moment.

CONTROL PLANE — GÉRÉ PAR HIKUBE

kube-apiserver etcd x3 scheduler controller-manager

NODE GROUPS

Workers (votre tenant)

VMs avec autoscaling min/max. Séparés par rôle et type de charge..

RÉSEAU

Cilium CNI

NetworkPolicy, Hubble observability, LoadBalancer, Ingress NGINX.

STOCKAGE

PVC répliqués

Provisioning dynamique. 3 backends : Geneva · Gland · Lucerne.

Configuration entièrement déclarative

Cluster, node groups, add-ons... tout se configure via un manifeste YAML et kubectl apply. Les modifications sont appliquées en rolling update sans downtime.
Mise en route

Un cluster en quelques lignes de YAML 

Déclarez votre cluster, appliquez-le, récupérez votre kubeconfig. Le control plane est prêt en quelques clics. 

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
# Déployer le cluster
kubectl apply -f my-first-cluster. yaml

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

# Vérifier les næuds
export KUBECONFIG-kubeconfig.yaml
kubectl get nodes


 

Quelques points à retenir pour bien démarrer :


  • replicas: 3 pour la production
    Un nombre impair de réplicas est recommandé pour garantir le quorum etcd et la haute disponibilité du control plane.

  • resources: {} est obligatoire
    Chaque node group doit déclarer ce champ, même vide. Sans lui, les valeurs CPU/RAM ne sont pas héritées de l'instanceType.

  • Séparez vos node groups par rôle
    Web, compute, monitoring, GPU — des groupes distincts permettent un autoscaling indépendant et une meilleure maîtrise des coûts.

  • Scale à zéro pour les workloads GPU
    minReplicas: 0 sur un node group GPU permet de ne consommer des ressources que quand des pods GPU sont effectivement planifiés.

types d’instances

Trois gammes pour chaque type de workload 

Chaque gamme est disponible de small à 8xlarge. Choisissez selon le ratio CPU/RAM adapté à votre charge.  

GAMME
RATIO
USAGE RECOMMANDÉ
s1 – Standard
1:2
vCPU:RAM
Workloads généraux, serveurs web
u1 — Universal
1:4
vCPU:RAM
Applications métier, bases de données
m1 — Memory
1:8
vCPU:RAM
Cache, analytics, monitoring, ML

La bonne pratique est d'adapter la gamme au rôle du node group :

  • s1 pour les workers generaux et l'Ingress
    Ratio CPU:RAM équilibré pour les applications web et les microservices sans besoin mémoire particulier.

  • u1 pour le compute et les workloads GPU
    Plus de RAM par cœur, recommandé pour les pipelines ML et les bases de données. Ratio adapté au 8-16 vCPU par GPU.

  • m1 pour les workloads à forte consommation
    Idéal pour le monitoring, les caches et les moteurs d’indéxation qui privilégient la RAM au CPU.

Exemples:

s1.large = 4 vCPU / 8 GB · u1.2xlarge = 8 vCPU / 32 GB · m1.xlarge = 4 vCPU / 32 GB. Tableau complet
Stockage persistant

PVC répliqués sur trois datacenters 

Chaque PVC est provisionné dynamiquement et peut être répliqué sur Genève, Gland et Lucerne selon la StorageClass choisie. 

STORAGECLASS
REPLICATION
COMPORTEMENT
local
Un seul datacenter
Pas de réplication, latence minimale
replicated
Multi-datacenter synchrone
Écriture confirmée sur les 3 sites avant retour
replicated-async
Multi-datacenter asynchrone
Écriture locale puis propagation différée
ADD-ONS

Activez ce dont vous avez besoin 

Chaque add-on s'active en une ligne dans le manifeste du cluster. Ils sont déployés et maintenus automatiquement dans votre cluster tenant. 

Cert-Manager

Cert-Manager

Certificats TLS automatiques via Let's Encrypt ou votre autorité privée. Renouvellement automatique. 
image 61-2

Gateway API

Routage HTTP/HTTPS avancé selon le standard Kubernetes. Gestion fine du trafic entrant et support multi-protocoles. 
image 61-1

Monitoring

Node Exporter, Fluent Bit, Kube-State-Metrics. Intégration Grafana et VictoriaMetrics du tenant. 
image 61-3

GPU Operator

Drivers NVIDIA automatiques sur les nœuds GPU. Requis pour utiliser des workloads GPU en Kubernetes. 
image 61-4

FluxCD

GitOps natif, assurant une synchronisation continue depuis votre dépôt Git. Déploiements automatisés et rollback. 
CAS D'USAGE

Architectures courantes sur Hikube 

Des configurations testées en production pour les patterns les plus fréquents. 

APPLICATION WEB

Stack applicative avec Ingress et TLS

Node group web avec rôle ingress-nginx, cert-manager pour les certificats Let's Encrypt, autoscaling entre 2 et 10 nœuds selon le trafic. 
sl.large ingress-nginx cert-manager replicated

GITOPS

Déploiements continus depuis Git avec FluxCD

 FluxCD synchronise votre dépôt Git toutes les minutes. Push sur main = déploiement automatique dans le cluster. Rollback via revert Git. 
fluxcd cert-manager cert-ingress-nginx

ML / AI

Cluster hybride CPU + GPU avec scale à zéro

Node group GPU avec minReplicas: 0 — les nœuds GPU ne tournent que quand des jobs sont planifiés. Node group CPU permanent pour l'orchestration. 
u1.2xlarge L40S GPU gpuOperator 500Gi

OBSERVABILITE

Node group dédié au monitoring

 Node group m1.xlarge avec rôle monitoring et stockage éphémère généreux (200Gi). VictoriaMetrics, Grafana et Fluent Bit isolés du reste des workloads. 
m1.xlarge monitoringAgents 200Gi
Pourquoi Kubernetes managé

Moins d'ops, plus de temps pour vos workloads 

Maintenir un control plane Kubernetes en production, c'est gérer des upgrades de versions, surveiller la santé d'etcd, gérer les certificats internes, et s'assurer que le quorum est préservé à tout moment. Ce n'est pas compliqué mais cela prend du temps et de l'attention.

Sur Hikube, cette charge opérationnelle disparaît. Vous déclarez ce que vous voulez : taille du cluster, node groups, add-ons et la plateforme s'occupe du reste. Vous gardez un accès complet via l'API Kubernetes standard : kubectl, Helm, Terraform et FluxCD fonctionnent exactement comme sur un cluster auto-géré.

La réplication multi-datacenter sur trois sites suisses est transparente pour vos workloads. Vos PVC sont disponibles même si un datacenter est inaccessible, sans configuration supplémentaire de votre côté.

Vector (Stroke)-2

Aucune maintenance du control plane

Upgrades Kubernetes, rotation des certificats internes, supervision d'etcd — tout est géré par Hikube. Vous consommez l'API, pas l'infrastructure. 

Vector (Stroke)-2

GPU et CPU sur le même cluster

Des node groups spécialisés permettent de faire tourner vos APIs et vos pipelines ML sur la même infrastructure, orchestrés par le même control plane.

Vector (Stroke)-2

Scaling déclaratif et automatique

Changez maxReplicas dans votre YAML et appliquez. L'autoscaler ajoute ou retire des nœuds selon la pression CPU/mémoire réelle de vos pods.

Vector (Stroke)-2

Données en Suisse, architecture souveraine

Trois datacenters suisses indépendants. Conformité RGPD et nLPD native.

FAQ

Question sur Kubernetes as a Service

Quelle instance choisir pour mes workers ?

 Ça dépend de ce qui tourne sur les nœuds. Pour des applications web et des microservices classiques, s1 (ratio 1:2) est le bon point de départ. Pour des bases de données, des pipelines de données ou des workers GPU, préférez u1 (ratio 1:4) qui donne plus de RAM par cœur. Réservez m1 (ratio 1:8) aux charges vraiment gourmandes en mémoire — monitoring, caches, analytics.

Comment fonctionne l'autoscaling ?

 L'autoscaling est contrôlé par minReplicas et maxReplicas sur chaque node group. Quand des pods restent en état Pending faute de ressources, de nouveaux nœuds sont provisionnés automatiquement. Quand la charge diminue, les nœuds sous-utilisés sont supprimés — sans descendre sous minReplicas.

Vous pouvez ajuster les bornes à tout moment en modifiant le manifeste et en relançant kubectl apply. Pour les workloads GPU ou de développement, minReplicas: 0 permet de descendre à zéro nœuds quand il n'y a rien à faire — prévoir quelques minutes de cold start au premier pod planifié.

Quelle storageClass utiliser en production ?

 replicated est la recommandation par défaut pour la production. Elle réplique vos volumes persistants sur les trois datacenters suisses de façon synchrone — vos données restent accessibles même en cas de panne d'un site.

local est plus rapide (une seule copie, moins de latence) mais sans haute disponibilité au niveau stockage — réservez-la au développement ou aux données vraiment temporaires.

Comment ajouter des nœuds GPU à un cluster existant ?

Ajoutez un nouveau node group avec le champ gpus[] dans votre manifeste, activez l'addon gpuOperator, et appliquez. Le GPU Operator se charge d'installer les drivers NVIDIA sur les nouveaux nœuds automatiquement.

À noter : chaque nœud du node group GPU consomme un GPU physique. Un node group avec minReplicas: 4 mobilise 4 GPUs en permanence — pensez à utiliser minReplicas: 0 si vos workloads GPU sont intermittents.

Comment récupérer mon kubeconfig ?

Le kubeconfig est généré automatiquement lors de la création du cluster et stocké dans un Secret Kubernetes.

Puis-je utiliser FluxCD pour déployer mes applications ?

Oui — activez l'addon fluxcd dans le manifeste du cluster avec l'URL de votre dépôt Git. FluxCD synchronise automatiquement tous les manifestes YAML du dépôt dans votre cluster. Un push sur votre branche principale déclenche un déploiement sans aucune action manuelle.

Pour les dépôts privés, configurez l'authentification SSH ou par token dans le cluster après le déploiement initial de Flux.