Aller au contenu
  1. Blog/

Déployer Kubernetes en production en Suisse : guide complet 2026

·12 mins
Sommaire

Tu veux déployer Kubernetes en production en Suisse et tu te demandes par où commencer ? Bonne question. Entre les contraintes légales suisses, le choix du provider, et les pièges classiques d’un cluster de prod, il y a de quoi se perdre. Ce guide couvre tout ce qu’il faut savoir pour monter un cluster K8s solide, conforme, et adapté au contexte helvétique — sans bullshit marketing.

Pourquoi Kubernetes en production en Suisse ?
#

Déployer Kubernetes en Suisse, ce n’est pas juste une question technique. C’est un choix stratégique qui répond à des contraintes bien réelles.

Souveraineté des données
#

Depuis la révision de la LPD (Loi fédérale sur la Protection des Données) entrée en vigueur le 1er septembre 2023, les exigences sur le traitement des données personnelles se sont durcies. Si tu gères des données de clients suisses — santé, finance, RH — tu as tout intérêt à les garder sur sol helvétique. Ce n’est pas toujours une obligation légale stricte, mais c’est souvent une exigence contractuelle de tes clients, surtout dans le secteur bancaire et médical.

Kubernetes te permet de garder le contrôle sur tournent tes workloads. Contrairement à un PaaS managé chez un hyperscaler US, tu sais exactement dans quel datacenter tes pods s’exécutent.

Latence et proximité
#

Pour des applications qui servent le marché suisse et européen, héberger en Suisse offre une latence optimale. Les datacenters de Zurich, Genève et Lausanne sont à quelques millisecondes de la majorité de tes utilisateurs. C’est un avantage concret pour les APIs temps réel, le trading, ou les applications interactives.

Conformité simplifiée
#

Garder tes données en Suisse simplifie drastiquement ta conformité. Pas besoin de jongler avec les clauses contractuelles types pour les transferts hors UE/EEE, pas de questionnement sur le CLOUD Act américain. Tu restes dans un cadre juridique clair et stable.

Choisir son provider Kubernetes en Suisse
#

C’est la décision fondamentale. Voici les options qui tiennent la route en 2026.

Exoscale SKS (Swiss Kubernetes Service)
#

Exoscale, c’est le provider cloud suisse par excellence. Basé à Lausanne, filiale d’A1 Digital, datacenters à Zurich, Genève, Vienne et Francfort.

Points forts :

  • Kubernetes managé (SKS) basé sur Calico pour le networking
  • API compatible CloudStack, CLI propre
  • Données 100% en Suisse si tu choisis les zones ch-gva-2 ou ch-dk-2
  • Support réactif, en français et allemand
  • Certification ISO 27001

Tarifs indicatifs (2026) :

  • Node pool (3× Medium, 4 vCPU / 8 GB RAM) : ~CHF 180/mois
  • Control plane SKS : inclus (pas de frais pour le master)
  • Load Balancer : ~CHF 12/mois
  • Stockage SSD : ~CHF 0.11/GB/mois

Idéal pour : PME suisses, startups, workloads avec exigences de souveraineté.

Infomaniak Jelastic / Kubernetes
#

Infomaniak, le géant genevois, propose du Kubernetes via sa plateforme cloud. Datacenter à Genève, énergie 100% renouvelable.

Points forts :

  • Hébergement exclusivement en Suisse (Genève)
  • Engagement écologique fort (certifié ISO 14001)
  • Support en français
  • Offre Public Cloud avec instances dédiées pour les nodes K8s

Tarifs indicatifs :

  • Instances compute pour nodes : dès CHF 5/mois par vCPU
  • Stockage bloc : ~CHF 0.09/GB/mois

Idéal pour : Organisations sensibles à l’écologie, clients romands, secteur public.

Scaleway (Datacenter Paris, option Suisse limitée)
#

Scaleway propose Kapsule (Kubernetes managé), mais attention : les datacenters sont à Paris et Amsterdam. Pas de datacenter suisse à ce jour. C’est une option si ta contrainte est “Europe” plutôt que “Suisse stricte”.

Points forts :

  • Excellent rapport qualité/prix
  • Ecosystème riche (Object Storage, Managed DB, etc.)
  • Kubernetes Kapsule très mature

Tarifs indicatifs :

  • 3 nodes DEV1-M (3 vCPU, 4 GB) : ~€75/mois (~CHF 72)
  • Control plane : gratuit

Idéal pour : Projets sans contrainte stricte de localisation suisse, budgets serrés.

Auto-hébergé (bare metal / colocation)
#

Pour les organisations avec des exigences maximales de contrôle, le bare metal dans un datacenter suisse reste une option. Tu loues des serveurs chez Safe Host, Green.ch, ou IP-Max et tu montes ton cluster avec kubeadm, k3s, ou Talos Linux.

Points forts :

  • Contrôle total sur le hardware et le réseau
  • Pas de dépendance à un provider cloud
  • Performances prévisibles, pas de “noisy neighbor”

Tarifs indicatifs :

  • Colocation : CHF 150-300/mois par U de rack
  • Serveur dédié (ex: Hetzner revendu via datacenter CH) : CHF 80-200/mois
  • Bande passante : souvent incluse (1-10 Gbps)

Idéal pour : Secteur bancaire, santé, organisations avec équipe infra dédiée.

Tableau comparatif rapide
#

CritèreExoscale SKSInfomaniakScalewayAuto-hébergé
Données en Suisse❌ (France)
K8s managéPartiel
Coût 3 nodes (CHF/mois)~180~150~72~300+
Support FR
Complexité opsFaibleMoyenneFaibleÉlevée

Architecture haute disponibilité
#

Un cluster Kubernetes de production en Suisse, ça ne se fait pas avec un seul node et une prière. Voici l’architecture cible.

Topologie recommandée
#

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
┌─────────────────────────────────────┐
│          Load Balancer (L4)         │
│        (Exoscale NLB / MetalLB)    │
└──────────────┬──────────────────────┘
    ┌──────────┼──────────┐
    │          │          │
┌───▼───┐ ┌───▼───┐ ┌───▼───┐
│Node 1 │ │Node 2 │ │Node 3 │
│Worker │ │Worker │ │Worker │
│Zone A │ │Zone A │ │Zone B │
└───────┘ └───────┘ └───────┘

Minimum viable pour la prod :

  • 3 worker nodes (idéalement répartis sur 2 zones)
  • Control plane managé (SKS) ou 3 masters si auto-hébergé
  • etcd en cluster de 3 (quorum)

Exemple : provisionner un cluster SKS avec Terraform
#

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
resource "exoscale_sks_cluster" "prod" {
  zone    = "ch-gva-2"
  name    = "prod-cluster"
  version = "1.29"

  auto_upgrade = true
}

resource "exoscale_sks_nodepool" "workers" {
  cluster_id    = exoscale_sks_cluster.prod.id
  zone          = "ch-gva-2"
  name          = "workers"
  instance_type = "standard.large"  # 4 vCPU, 16 GB
  size          = 3

  disk_size = 100  # GB

  security_group_ids = [
    exoscale_security_group.k8s_nodes.id
  ]
}

Pod Disruption Budgets
#

Ne déploie jamais un workload critique sans PDB. C’est ce qui empêche Kubernetes de tuer tous tes pods pendant un rolling update ou un drain de node.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-pdb
  namespace: production
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: api-gateway

Topology Spread Constraints
#

Pour répartir tes pods sur les zones disponibles :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-gateway
spec:
  replicas: 3
  template:
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: api-gateway
      containers:
        - name: api
          image: registry.devopslab.ch/api-gateway:v2.4.1
          resources:
            requests:
              cpu: 500m
              memory: 512Mi
            limits:
              cpu: "1"
              memory: 1Gi

Sécurité : LPD, RGPD et bonnes pratiques
#

La sécurité d’un cluster Kubernetes en production en Suisse, c’est un sujet à trois couches : légal, infra, et applicatif.

Conformité LPD / RGPD
#

La nLPD (nouvelle Loi sur la Protection des Données) s’aligne sur le RGPD mais avec des spécificités suisses :

  • Registre des traitements : obligatoire pour les entreprises de plus de 250 employés (recommandé pour tous)
  • Annonce des violations : notification au PFPDT (Préposé fédéral) dans les meilleurs délais
  • Privacy by Design : intégrer la protection des données dès la conception

Concrètement dans Kubernetes, ça veut dire :

  1. Chiffrement au repos : activer le chiffrement etcd
  2. Chiffrement en transit : mTLS entre les services (Istio, Linkerd, ou Cilium)
  3. Logs d’accès : audit logging Kubernetes activé
  4. RBAC strict : principe du moindre privilège

Network Policies
#

Par défaut, Kubernetes autorise tout le trafic entre pods. En prod, c’est inacceptable. Verrouille tout et ouvre au cas par cas :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-to-db
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: api-gateway
      ports:
        - protocol: TCP
          port: 5432

Gestion des secrets
#

Ne mets jamais tes secrets en clair dans tes manifests. Utilise :

  • External Secrets Operator avec un backend comme HashiCorp Vault
  • Sealed Secrets de Bitnami pour les stocker chiffrés dans Git
  • SOPS avec age pour le chiffrement côté client
1
2
3
4
5
6
7
# Installer Sealed Secrets
helm repo add sealed-secrets https://bitnami-labs.github.io/sealed-secrets
helm install sealed-secrets sealed-secrets/sealed-secrets \
  --namespace kube-system

# Chiffrer un secret
kubeseal --format yaml < secret.yaml > sealed-secret.yaml

Pod Security Standards
#

Depuis Kubernetes 1.25, les Pod Security Policies sont remplacées par les Pod Security Standards. Active-les au niveau du namespace :

1
2
3
4
5
6
7
8
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Le profil restricted interdit les conteneurs root, exige des seccomp profiles, et bloque les capabilities dangereuses. C’est le minimum pour de la prod.

Networking
#

Ingress Controller
#

Pour exposer tes services, deux options dominent en 2026 :

Nginx Ingress Controller : le classique, stable, bien documenté.

1
2
3
4
5
helm install ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx \
  --create-namespace \
  --set controller.replicaCount=2 \
  --set controller.service.annotations."service\.beta\.kubernetes\.io/exoscale-loadbalancer-zone"="ch-gva-2"

Traefik : plus moderne, intégration native avec Let’s Encrypt, middleware flexible. Livré par défaut avec k3s.

Service Mesh
#

Pour le mTLS automatique entre services et l’observabilité réseau :

  • Cilium : basé sur eBPF, performant, de plus en plus adopté. Choix recommandé en 2026.
  • Linkerd : léger, simple à opérer, CNCF graduated.
  • Istio : puissant mais complexe. À réserver aux gros déploiements.

DNS et certificats
#

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
# cert-manager avec Let's Encrypt
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: ops@devopslab.ch
    privateKeySecretRef:
      name: letsencrypt-prod
    solvers:
      - http01:
          ingress:
            class: nginx

Monitoring et observabilité
#

Un cluster sans monitoring, c’est conduire de nuit sans phares. Voici la stack recommandée.

Prometheus + Grafana (kube-prometheus-stack)
#

La référence. Un seul Helm chart pour tout installer :

1
2
3
4
5
6
7
8
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts

helm install monitoring prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --create-namespace \
  --set prometheus.prometheusSpec.retention=30d \
  --set prometheus.prometheusSpec.storageSpec.volumeClaimTemplate.spec.resources.requests.storage=50Gi \
  --set grafana.adminPassword='$(openssl rand -base64 24)'

Ça installe : Prometheus, Grafana, Alertmanager, node-exporter, kube-state-metrics, et des dashboards pré-configurés.

Logging : Loki + Promtail
#

Oublie l’ELK stack surdimensionnée. Loki est léger, s’intègre nativement avec Grafana, et coûte une fraction en stockage.

1
2
3
4
5
helm install loki grafana/loki-stack \
  --namespace monitoring \
  --set promtail.enabled=true \
  --set loki.persistence.enabled=true \
  --set loki.persistence.size=20Gi

Alerting
#

Configure des alertes qui comptent. Pas 200 alertes que tout le monde ignore, mais les essentielles :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: critical-alerts
  namespace: monitoring
spec:
  groups:
    - name: kubernetes-critical
      rules:
        - alert: PodCrashLooping
          expr: rate(kube_pod_container_status_restarts_total[15m]) > 0
          for: 10m
          labels:
            severity: critical
          annotations:
            summary: "Pod {{ $labels.pod }} crash-looping"

        - alert: NodeNotReady
          expr: kube_node_status_condition{condition="Ready",status="true"} == 0
          for: 5m
          labels:
            severity: critical
          annotations:
            summary: "Node {{ $labels.node }} not ready"

        - alert: PersistentVolumeSpaceLow
          expr: kubelet_volume_stats_available_bytes / kubelet_volume_stats_capacity_bytes < 0.1
          for: 10m
          labels:
            severity: warning
          annotations:
            summary: "PV {{ $labels.persistentvolumeclaim }} below 10% space"

Coût du monitoring
#

Sur Exoscale avec des PVs de 50 GB pour Prometheus et 20 GB pour Loki :

  • Stockage monitoring : ~CHF 8/mois
  • Resources (2 pods monitoring ~1 vCPU, 2 GB RAM) : inclus dans les nodes

Alternativement, si tu veux externaliser : Grafana Cloud offre un free tier généreux (10k séries Prometheus, 50 GB logs) qui suffit pour un petit cluster.

Coûts : budget réaliste pour un cluster de prod
#

Parlons chiffres. Voici ce que coûte un cluster Kubernetes de production en Suisse, en CHF, pour une charge de travail typique (API + base de données + monitoring).

Estimation mensuelle — Exoscale SKS
#

ComposantSpécificationCoût CHF/mois
3 worker nodesStandard.large (4 vCPU, 16 GB)~270
Control plane SKSManagé0
Load BalancerNLB~12
Stockage PV200 GB SSD~22
Object Storage (backups)100 GB~5
DNS Zone1 zone~1
Total~CHF 310/mois

Estimation mensuelle — Auto-hébergé (colocation)
#

ComposantSpécificationCoût CHF/mois
3 serveurs dédiés8 cores, 32 GB, 500 GB NVMe~450
Colocation + réseau1/4 rack, 1 Gbps~200
IP publiques/29~30
Backup S3 (Exoscale)100 GB~5
Total~CHF 685/mois

Coûts cachés à ne pas oublier
#

  • Temps ingénieur : un cluster auto-hébergé, c’est facilement 0.5-1 ETP pour l’opérer
  • Licences : certains outils (Datadog, PagerDuty) facturent par host ou par GB
  • Backups cross-site : réplication vers un second datacenter, prévoir ~50% de stockage en plus
  • Formation : CKA/CKAD pour l’équipe, ~CHF 2'000-3'000 par personne

Checklist de mise en production
#

Avant d’envoyer du trafic réel sur ton cluster, vérifie ces points :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
#!/bin/bash
# checklist-prod.sh — Vérifications pré-production K8s

echo "=== Checklist Kubernetes Production ==="

# RBAC
echo "🔒 RBAC activé ?"
kubectl auth can-i --list --as=system:anonymous | grep -q "no" && echo "  ✅ Anonymous access restreint" || echo "  ❌ Anonymous access détecté"

# Network Policies
echo "🌐 Network Policies ?"
NP_COUNT=$(kubectl get networkpolicies -A --no-headers 2>/dev/null | wc -l)
echo "  $NP_COUNT NetworkPolicies trouvées"

# Pod Security
echo "🛡️ Pod Security Standards ?"
kubectl get ns --show-labels | grep "pod-security"

# Resource Limits
echo "📊 Pods sans limits ?"
kubectl get pods -A -o json | jq -r '.items[] | select(.spec.containers[].resources.limits == null) | .metadata.namespace + "/" + .metadata.name'

# Monitoring
echo "📈 Prometheus running ?"
kubectl get pods -n monitoring -l app.kubernetes.io/name=prometheus --no-headers

# Backups
echo "💾 Velero installé ?"
kubectl get pods -n velero --no-headers 2>/dev/null || echo "  ❌ Velero non trouvé"

echo "=== Fin de la checklist ==="

Conclusion
#

Déployer Kubernetes en production en Suisse en 2026, c’est tout à fait accessible — à condition de faire les bons choix dès le départ. Exoscale SKS reste le choix le plus pragmatique pour la majorité des cas : Kubernetes managé, données en Suisse, prix raisonnables. Pour les organisations avec des exigences maximales de contrôle, le bare metal en colocation suisse reste pertinent, mais le coût opérationnel est significativement plus élevé.

Les points non négociables :

  • Network Policies dès le jour 1
  • RBAC strict avec le principe du moindre privilège
  • Monitoring (Prometheus + Grafana minimum)
  • Pod Security Standards en mode restricted
  • Backups testés régulièrement (Velero + snapshots PV)

La conformité LPD n’est pas un obstacle technique — c’est surtout une question de rigueur dans les choix d’hébergement et de documentation. Garde tes données en Suisse, chiffre tout, logge les accès, et tu seras dans les clous.

Tu as un projet K8s en Suisse et des questions spécifiques ? Passe sur notre Discord ou laisse un commentaire — on répond toujours.


Dernière mise à jour : mars 2026. Les prix sont indicatifs et peuvent varier selon les offres en cours des providers.

Articles connexes