Installer Kubernetes sur un VPS : guide pas à pas

Vous cherchez à installer Kubernetes VPS sans passer par une offre managée coûteuse ? C'est parfaitement réalisable avec quelques serveurs virtuels bien dimensionnés et un peu de rigueur. Ce tutoriel 2026 détaille le déploiement d'un cluster fonctionnel sur des VPS Linux, du provisioning initial jusqu'à la mise en réseau des pods et la sécurisation du plan de contrôle.

Prérequis avant d'installer Kubernetes VPS

Kubernetes est exigeant en ressources et sensible à la configuration réseau. Avant de vous lancer, il faut cadrer l'architecture pour éviter les erreurs classiques : nœuds sous-dimensionnés, swap actif, ou modules kernel manquants.

Dimensionnement des nœuds

Un cluster minimal viable repose sur au moins trois machines : un nœud control-plane et deux nœuds workers. Pour un usage réel, prévoyez la répartition suivante :

Rôle	vCPU	RAM	Disque
Control-plane	2	4 Go	40 Go NVMe
Worker	2 à 4	4 à 8 Go	40 à 80 Go SSD SAS

Le stockage SSD SAS fait une vraie différence pour etcd, qui est très sensible à la latence disque. Des VPS Linux OmegaCloud en SSD SAS avec CPU KVM dédié offrent une base saine, notamment parce qu'etcd déteste les I/O lentes et le CPU partagé imprévisible. Pour un cluster de laboratoire, un VPS Proxmox permet de monter les nœuds en conteneurs LXC sur une seule machine.

Système et réseau

• OS récent : Debian 12, Ubuntu 24.04 ou Rocky/Alma 9
• Kernel récent avec les modules overlay et br_netfilter
• Swap désactivé (obligatoire pour kubelet)
• Latence réseau faible entre les nœuds : privilégiez des VPS dans le même datacenter

La faible latence intra-datacenter est un point clé : le trafic control-plane / workers et le réseau des pods circulent en permanence. Regrouper vos VPS dans une même localisation UE réduit les timeouts et stabilise etcd.

Point sécurité : l'anti-DDoS volumetrique est déjà géré côté infrastructure par OmegaCloud. Vous n'avez donc pas à ajouter de couche de mitigation volumétrique. En revanche, la sécurisation applicative du cluster reste entièrement de votre ressort.

Préparer les VPS Linux pour Kubernetes

Cette phase est identique sur tous les nœuds. Automatisez-la avec un script ou un playbook Ansible si vous provisionnez plusieurs machines.

Mise à jour et paramètres kernel

apt update && apt upgrade -y
apt install -y curl gpg apt-transport-https ca-certificates

# Désactiver le swap
swapoff -a
sed -i '/ swap / s/^/#/' /etc/fstab

# Modules kernel requis
cat <

Paramètres sysctl réseau

cat <

Installer le runtime containerd

Kubernetes n'embarque plus Docker comme runtime. On utilise containerd, standard CRI aujourd'hui.

apt install -y containerd
mkdir -p /etc/containerd
containerd config default | tee /etc/containerd/config.toml

# Activer le cgroup driver systemd
sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml

systemctl restart containerd
systemctl enable containerd

Le passage à SystemdCgroup = true est essentiel : sans ça, kubelet et containerd se disputent la gestion des cgroups, ce qui provoque des redémarrages intempestifs de pods.

Installer kubeadm, kubelet et kubectl

KUBE_VERSION=v1.31
curl -fsSL https://pkgs.k8s.io/core:/stable:/$KUBE_VERSION/deb/Release.key | \
  gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

echo "deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] \
https://pkgs.k8s.io/core:/stable:/$KUBE_VERSION/deb/ /" | \
  tee /etc/apt/sources.list.d/kubernetes.list

apt update
apt install -y kubelet kubeadm kubectl
apt-mark hold kubelet kubeadm kubectl

Le apt-mark hold évite qu'une mise à jour incontrôlée casse le cluster. Les upgrades Kubernetes se font manuellement, version mineure par version mineure.

Initialiser le cluster et déployer le réseau

On passe maintenant à l'installation du plan de contrôle sur le nœud control-plane, puis à la jonction des workers.

Initialiser le control-plane

Choisissez un CIDR pour les pods qui ne rentre pas en conflit avec le réseau de vos VPS. Le plage 10.244.0.0/16 est classique avec Flannel.

kubeadm init \
  --pod-network-cidr=10.244.0.0/16 \
  --apiserver-advertise-address=<IP_PRIVEE_CONTROL_PLANE>

À la fin, kubeadm affiche une commande kubeadm join avec un token. Conservez-la. Configurez ensuite kubectl pour votre utilisateur :

mkdir -p $HOME/.kube
cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
chown $(id -u):$(id -g) $HOME/.kube/config

kubectl get nodes

Le nœud apparaîtra en état NotReady : c'est normal tant qu'aucun réseau de pods (CNI) n'est déployé.

Déployer un CNI

Le plugin réseau relie les pods entre eux. Flannel est simple et léger pour débuter ; Calico offre en plus des NetworkPolicies. Pour un premier cluster VPS, Flannel suffit :

kubectl apply -f \
https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml

# Vérifier
kubectl get pods -n kube-flannel
kubectl get nodes

Une fois les pods Flannel Running, le nœud control-plane passe en Ready.

Joindre les workers

Sur chaque worker, exécutez la commande kubeadm join récupérée précédemment :

kubeadm join <IP_CONTROL_PLANE>:6443 \
  --token <TOKEN> \
  --discovery-token-ca-cert-hash sha256:<HASH>

Si vous avez perdu le token, régénérez-le depuis le control-plane :

kubeadm token create --print-join-command

Vérifiez ensuite l'état global du cluster :

kubectl get nodes -o wide

Tester un déploiement

kubectl create deployment nginx --image=nginx --replicas=2
kubectl expose deployment nginx --port=80 --type=NodePort
kubectl get svc nginx

Le port NodePort exposé (plage 30000-32767) vous permet de valider que le routage inter-nœuds fonctionne.

Sécuriser et exploiter le cluster

Un cluster Kubernetes exposé sur Internet est une cible. La sécurisation combine durcissement des VPS et bonnes pratiques Kubernetes. Le trafic volumétrique DDoS étant filtré côté infrastructure OmegaCloud, concentrez-vous sur l'accès et l'API.

Durcir l'accès SSH

# Sur votre poste local
ssh-keygen -t ed25519 -C "admin-k8s"
ssh-copy-id admin@<IP_VPS>

Puis désactivez l'authentification par mot de passe dans /etc/ssh/sshd_config :

PasswordAuthentication no
PermitRootLogin prohibit-password

systemctl restart sshd

Filtrer avec le pare-feu

Le plan de contrôle Kubernetes utilise plusieurs ports. Autorisez uniquement le nécessaire, et restreignez l'accès à l'API (6443) à vos IP d'administration.

ufw allow 22/tcp
ufw allow from <IP_ADMIN> to any port 6443 proto tcp

# Communication interne du cluster (control-plane)
ufw allow 2379:2380/tcp   # etcd
ufw allow 10250/tcp       # kubelet
ufw allow 10259/tcp       # kube-scheduler
ufw allow 10257/tcp       # kube-controller-manager

ufw enable
ufw status numbered

Pour un contrôle plus fin des flux inter-VPS, nftables permet des règles stateful avancées. Complétez avec fail2ban pour bloquer le brute-force SSH.

Isoler le trafic des pods

Si vous avez déployé Calico, activez les NetworkPolicies pour empêcher un pod compromis de communiquer librement avec les autres. Le principe du moindre privilège s'applique aussi au réseau interne. Consultez la documentation officielle des Source bonnes pratiques de sécurité.

Sauvegarder etcd

etcd contient tout l'état du cluster. Une sauvegarde régulière évite la perte totale en cas d'incident.

ETCDCTL_API=3 etcdctl snapshot save /root/etcd-snapshot.db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

Combinez ces snapshots etcd avec les snapshots VPS disponibles depuis le panel OmegaCloud, qui permettent aussi un reboot ou une réinstallation en un clic si un nœud devient inutilisable.

Intégrer le CI/CD

Pour déployer automatiquement sur votre cluster, connectez GitHub Actions ou GitLab CI. Un runner authentifié via kubeconfig applique vos manifestes à chaque push. Les Intégrations & API OmegaCloud (API REST, webhooks) facilitent le provisioning des VPS en amont de votre pipeline.

Surveillance

• Activez le 2FA sur le panel de gestion pour protéger l'accès aux VPS
• Surveillez CPU/RAM/SSD/réseau en temps réel via le dashboard
• Déployez Prometheus + Grafana dans le cluster pour les métriques Kubernetes
• Configurez des alertes sur la santé d'etcd et la pression mémoire des nœuds

Conclusion

Installer Kubernetes sur des VPS reste un exercice accessible dès lors que le runtime, le réseau CNI et la sécurité sont maîtrisés. Un control-plane, deux workers, containerd, un CNI et un pare-feu bien réglé suffisent pour un cluster solide. La clé du succès tient dans le dimensionnement, la latence réseau et des sauvegardes etcd régulières et testées.

FAQ

Combien de VPS faut-il au minimum pour installer Kubernetes ?

Techniquement, un seul nœud suffit avec kubeadm et le retrait du taint control-plane. Mais pour un usage réel avec redondance, prévoyez trois VPS : un control-plane et deux workers. Cela sépare le plan de contrôle des charges applicatives et permet de tolérer la perte d'un worker.

Faut-il désactiver le swap pour faire tourner kubelet ?

Oui. kubelet refuse par défaut de démarrer si le swap est actif, car il fausse la gestion mémoire des pods. Utilisez swapoff -a puis commentez la ligne swap dans /etc/fstab pour rendre le changement permanent après reboot.

L'anti-DDoS d'OmegaCloud protège-t-il aussi mon cluster Kubernetes ?

La mitigation volumétrique kernel-level est incluse par défaut et filtre les attaques réseau en amont, de façon transparente. En revanche, la sécurité applicative (accès API, RBAC, NetworkPolicies, durcissement SSH) reste à votre charge et doit être configurée sur vos nœuds.