Aller au contenu

Configuration des VPS

Inventaire

Nœud Région IP publique WireGuard Rôle K3s
vps-a2cbe513 GRA 213.32.65.236 10.50.0.1 control-plane, etcd, workloads
vps-7a702a91 SBG 152.228.237.203 10.50.0.2 control-plane, etcd, workloads
vps-b49e4e6f GRA 51.254.130.191 10.50.0.3 control-plane, etcd, workloads
vps-f0621bb1 os-uk2 57.128.185.8 10.50.0.4 worker, workloads

Configuration attendue sur chaque machine

  • K3s v1.36.3+k3s1 : mode serveur avec etcd embarqué sur les trois control-plane ; mode agent sur le worker UK.
  • Interface WireGuard et maillage privé entre les quatre nœuds.
  • Pare-feu UFW en refus entrant par défaut.
  • SSH par clé ; WireGuard et ports K3s nécessaires autorisés. HTTP/HTTPS publics restent servis par les trois nœuds portant actuellement les réplicas Traefik.
  • DNS système : Cloudflare, avec secours Quad9.
  • Synchronisation horaire active.
  • Aucun swap actif si la configuration K3s l'exige.

Configuration DNS attendue

Les resolvers utilisés en régime normal sont fournis une seule fois par l'interface ens3 : Cloudflare 1.1.1.1, 1.0.0.1, puis Quad9 9.9.9.9 comme troisième resolver. Le fichier /etc/systemd/resolved.conf.d/99-cloudflare.conf ne redéclare pas DNS= ; il conserve uniquement une configuration FallbackDNS= utilisée par systemd-resolved lorsqu'aucune autre information DNS appropriée n'est connue :

[Resolve]
FallbackDNS=9.9.9.9 149.112.112.112
DNSOverTLS=opportunistic
DNSSEC=allow-downgrade

FallbackDNS= n'est pas un mécanisme de failover d'un resolver ens3 devenu injoignable : tant que la configuration DNS de l'interface est disponible, la redondance normale repose sur les trois resolvers per-link, dont 9.9.9.9. 149.112.112.112 n'est donc pas attendu dans /run/systemd/resolve/resolv.conf en fonctionnement normal.

Cette séparation évite que /run/systemd/resolve/resolv.conf contienne deux fois les DNS Cloudflare. K3s transmet ce fichier aux pods et Kubernetes n'accepte au maximum que trois entrées de serveurs DNS sans émettre l'événement DNSConfigForming.

grep '^nameserver' /run/systemd/resolve/resolv.conf
resolvectl status ens3
getent hosts github.com

Le résultat normal contient exactement 1.1.1.1, 1.0.0.1 et 9.9.9.9, sans doublon.

Vérification après redémarrage

Sur un control-plane :

sudo systemctl is-active k3s
sudo systemctl is-active wg-quick@wg0
sudo systemctl is-active systemd-timesyncd
sudo wg show
sudo ufw status verbose
df -h
free -h

Sur le worker UK, le service attendu est k3s-agent :

sudo systemctl is-active k3s-agent
sudo systemctl is-active wg-quick@wg0
sudo systemctl is-active systemd-timesyncd

Depuis le poste opérateur :

kubectl get nodes -o wide
kubectl get pods -A -o wide
kubectl -n kube-system get pods
kubectl -n flux-system get gitrepositories,kustomizations
kubectl top nodes

Ajout ou remplacement d'un VPS

  1. Définir d'abord le rôle attendu : control-plane/etcd ou worker.
  2. Créer la machine dans une région distincte si possible.
  3. Mettre à jour le système, créer l'utilisateur opérateur et installer uniquement les clés publiques nécessaires.
  4. Configurer UFW sans fermer la session SSH courante.
  5. Ajouter WireGuard et vérifier les échanges privés dans les deux sens avec les membres concernés.
  6. Joindre K3s avec l'URL privée d'un serveur existant et le token récupéré de manière sécurisée : serveur + etcd pour un control-plane, agent pour un worker.
  7. Vérifier l'état Ready. Pour un control-plane, vérifier en plus que le nouveau membre etcd est sain avant toute autre opération sur le quorum.
  8. Vérifier la répartition des pods et, si le nœud doit porter l'Ingress, la présence effective de Traefik/ServiceLB et l'accessibilité HTTP/HTTPS.
  9. Ajouter ou ajuster les enregistrements DNS si nécessaire.
  10. Si le changement touche un membre etcd, créer un snapshot etcd ; dans tous les cas, mettre à jour cette documentation.

Quorum etcd

Ne jamais arrêter ou réinstaller deux control-planes simultanément. Le quorum etcd repose sur trois membres et tolère la perte d'un seul membre.

Dépannage VPS

Symptôme Vérifications
Nœud NotReady systemctl status k3s ou k3s-agent selon le rôle, journal du service, WireGuard, espace disque, heure
Nœud absent réseau privé, token/URL K3s, pare-feu TCP 6443 ; ports etcd uniquement entre serveurs control-plane
API lente CPU/RAM/disque, latence WireGuard, etcd, événements Kubernetes
Sites injoignables sur une IP d'Ingress Traefik/ServiceLB sur ce nœud, ports 80/443, UFW
Pods bloqués capacité, taints, affinité, PVC local, téléchargement d'image

Sur un control-plane :

sudo journalctl -u k3s --since "30 minutes ago" --no-pager
sudo k3s etcd-snapshot ls
sudo ss -lntup
sudo dmesg --level=err,warn

Sur le worker :

sudo journalctl -u k3s-agent --since "30 minutes ago" --no-pager
sudo ss -lntup
sudo dmesg --level=err,warn