Cutter 8
- vCPU
- 4 × dédié
- RAM
- 8 GB
- Stockage
- 160 GB SSD NVMe
- Transfert
- 10 TB
- IPv4 / IPv6
- 1 / /64 routed
Solution
Un nœud de plan de contrôle K3s nécessite 2 cœurs et 4 Go ; un plan de contrôle kubeadm complet veut 4 Go minimum et 8 Go pour être confortable. Les nœuds workers sont dimensionnés selon vos charges de travail. Trois instances Cutter 8 dans trois juridictions vous donnent un cluster réellement tolérant aux pannes pour moins de 110 $ par mois, avec un réseau privé via WireGuard entre les régions.
| Ressource | Ce dont vous avez réellement besoin |
|---|---|
| Plan de contrôle | 2 vCPU / 4 Go pour K3s, 4 vCPU / 8 Go pour kubeadm |
| Workers | Dimensionnés selon les charges de travail ; 4 vCPU / 8 Go est une unité raisonnable |
| Disque | NVMe pour etcd — il est sensible à la latence fsync |
| Réseau | Maillage WireGuard entre les régions ; IPv6 natif pour les clusters dual-stack |
L'emplacement est généralement la décision la plus importante pour ce type de charge de travail — soit parce que la latence domine, soit parce que la juridiction en fait partie.
Trois est le minimum pour le quorum etcd.
Donnez à chaque nœud une adresse privée et routez le CIDR du cluster dessus.
curl -sfL https://get.k3s.io | sh -s - server --cluster-init sur le premier nœud.
Utilisez le jeton de nœud depuis /var/lib/rancher/k3s/server/node-token.
Traefik est inclus avec K3s ; ajoutez cert-manager pour les certificats automatiques.
K3s fait tourner un plan de contrôle avec 2 vCPU et 4 Go. Un kubeadm complet exige 4 Go comme minimum absolu et se comporte bien mieux avec 8 Go. La taille des workers est entièrement déterminée par ce que vous y programmez.
Oui, via un maillage WireGuard. Gardez les membres etcd à moins de 100 ms les uns des autres, sinon le heartbeat Raft devient instable.
Critiquement. etcd fait un fsync à chaque écriture ; sur HDD ou stockage très sollicité, le cluster devient instable sous charge. Mettez-le toujours sur NVMe.