Un Talos européen sécurisé de qualité à coût maîtrisé

Talos devient au fil du temps la solution de choix pour déployer des clusters Kubernetes cloud ou bare metal hautement sécurisés et performants. Zéro SSH, API-REST first, à peine une douzaine de binaires embarqués, support chiffrement complet, cet OS est entièrement construit de manière conteneurisée et bootstrappé depuis le projet stagex, permettant un build entièrement reproductible et théoriquement insensible aux attaques supply-chain. Nous allons ici tenter de mettre en place un cluster kubernetes Talos sur des Cloud Service Providers européens (non GAFAM), le plus proche possible du production-grade, sans coût délirant.

Pour qui et pourquoi ? 🤔

Ce guide s’adresse aux devs à fortes inspirations DevOps/GitOps, principalement européens, adeptes du self-hosting, souhaitant s’affranchir des VPS à la papa et qui en ont plus qu’assez de la fatalité ambiante face à notre dépendance aux GAFAM, notamment :

• De leurs coûts délirants, inhérents aux modèles économiques de ces hyperscalers.
• De leur main mise sur nos données, notamment pour les entreprises non américaines, qui veulent s’extirper du Cloud Act et adhérer pleinement à la conformité RGPD.
• De leur opacité et aspect vendor-locking, du fait de l’intégration dans leur écosystème propriétaire, alors que l’écosystème Kubernetes commence à offrir de sérieuses alternatives via de puissants opérateurs.

En bref :

• Vous pensez avoir avez fait le tour de Dokploy et/ou de tout ce qui est possible de faire à partir des solutions type Docker Swarm, qui reste toujours parfaitement adapté aux besoins simples.
• Vous souhaitez monter à l’étage supérieur, basé sur des solutions Kubernetes et vous rapprochez de ce qui se fait de mieux chez les hyperscalers sans pour autant en subir le coût.
• Aller plus loin que les solutions classiques type k3s / kubeadm montées à l’arrache vite fait qui trainent sur des debians non maintenus dans leur coin, et monter votre infra complète entièrement contrôlée en mode GitOps.
• Avoir une chaîne de déploiement CI/CD complète, du développement jusqu’au run, avec tous les outils d’observabilité nécessaires.

Le but ici est donc de se rapprocher raisonnablement et à notre échelle de ces hyperscalers sur le triptyque suivant :

• La sécurité, via Zero Trust, chiffrement des données, mTLS, WAF (nous voulons aussi éviter les solutions de facilité tel que Cloudflare).
• La résilience, via haute disponibilité, backups et Plan de Reprise d’Activité (PRA).
• L’observabilité, à tous les niveaux, métriques, logs, traces.

Le sacrifice en échange ?

• Des efforts et du temps…
• Une plus grande part de responsabilité technique.

Les bénéfices :

• Une maîtrise de la stack logicielle complète, infra incluse, du build jusqu’au run.
• Un juste milieu entre les VPS à la papa et les hyperscalers.
• Des coûts 100% maitrisés, aux rapports performances/prix d’un niveau tel qu’aucun CSP ne peut (et ne pourra jamais) rivaliser.

Et les solutions type OVHcloud ou Scaleway alors ? Très bien, c’est un vrai pas dans la bonne direction, et un excellent compromis entre le GAFAM et le cluster kube tout géré à la main. Si cela répond parfaitement à votre besoin alors nickel, vous pouvez déjà vous arrêter ici !

Mais je pense qu’il reste encore la problématique du coût, que ces Cloud Services Providers ont bien naturellement besoin de marger aux clients du fait du nombre toujours grandissant de services cloud proposés.

Comment ? 🛤️

Ici, ce guide se focalisera sur une seule ressource principale et essentielle : le VPS, mais cuisiné aux petits oignons. Exit les grands CSP multi-services, en dehors des S3, DNS, TEM (email transactionnel).

Sur tout ce que j’ai testé, Hetzner Cloud reste le leader incontestable du marché du VPS Cloud européen au rapport performance/prix imbattable, tout en disposant d’une interface UX et API/CLI simple et sans fioritures, uniquement centrée autour des VPS. Il ne propose pratiquement aucun autre service managé mis à part le Load Balancer indispensable (l’Object Storage n’est d’ailleurs arrivé que très récemment), et c’est à peu près tout ce qu’on lui demande ! Il inclut également un provider terraform qui fait super bien son taf sans 15000 ressources à connaître (coucou les providers AWS/AZ).

Comme il est de rigueur, nous n’allons pas mettre tous nos œufs dans le même panier, et utiliserons à ce titre 3 cloud providers différents :

• Hetzner Cloud : l’infrastructure principale, VPS / volumes / Load Balancers
• OVHcloud : pour la partie stockage long-terme et backups S3, avec support chiffrement SSE-C et équivalent SSE-KMS via SSE-OMK.
• Scaleway : pour la partie DNS et TEM (serveur de mail transactionnel)

Les objectifs 🎯

• Monter un cluster Talos fonctionnel européen sécurisé, résiliant, et totalement monitoré.
• Tout en self-hosted ou presque, on maîtrise toute la brique infra logicielle.
• Déploiement 100% GitOps via Terraform/OpenTofu puis FluxCD
• Afin de comprendre et maîtriser chaque étape du processus, l’infra est construite en mode pas à pas, sans raccourci ni utilisation d’outil tout-en-un qui fait tout tel que terraform-hcloud-kubernetes.
• Zero Trust de bout en bout, via l’utilisation de Tailscale.
• Cluster construit avec la notion de worker pools, comme chez tous les providers d’infra cloud proposant du kube managé.
• Utilisation d’un Vaultwarden self-hosted avec backup pour le stockage des secrets dédiés à la partie Terraform.
• Chiffrement à tous les niveaux (volumes systèmes et externes, backups, s3, réseau pod à pod, mTLS).
• Intégration de Cilium sur la couche réseau physique de l’infra Hetzner.
• Intégration cloud (Network, Nodes et Load-Balancer) avec Hetzner Cloud Controller Manager.
• Solution de volumes distribués et backups via Longhorn.
• Du Ingress avec tout l’attirail qui va bien (cert-manager, Traefik, et CrowdSec en tant que solution WAF incluant analyse comportementale du trafic).
• Un Ingress avec endpoint public via Load Balancer et endpoint privé à travers le réseau Tailscale pour l’accès aux outils internes.
• Un cluster primary/replica PostgreSQL des familles via CloudNativePG, avec backup barman cloud sur s3 chiffré.
• Un cluster Dragonfly (équivalent Redis).
• Observabilité à tous les niveaux, monitoring complet via Prometheus/Grafana, logging et tracing distribué via Loki et Tempo en passant par le collecteur Alloy.
• Mis en place d’une logistique CI/CD via Gitea Action et Flux, avec analyse de code via SonarQube, incluant l’observabilité post-déploiement, au travers d’un exemple de projet .NET API.

Un sacré programme, be brave.

Pré-requis 🛠️

Déjà niveau prérequis ça va demander pas mal d’effort avant de commencer quoi que ce soit :

• Un compte Hetzner Cloud.
• Un compte Tailscale et être connecté sur votre tailnet de travail. Activer Tailnet Lock en option pour le maximum de sécurité, sinon activer au moins l’approbation manuelle d’un nouvel appareil.
• Un service S3 avec fonction de chiffrement SSE-C. Un équivalent SSE-KMS en plus sera idéal, car certains services de backup comme barman cloud ne supporte pas le chiffrage serveur avec clé client. On utilisera ici OVH. Activer le versioning pour être moins vulnérable aux ransomwares.
• Un nom de domaine avec un accès admin au DNS (on partira sur ohmytalos.io ici). On réservera un sous-domaine int.ohmytalos.io pour l’accès aux outils internes.
• Un compte de mail transactionnel, déjà actif et pré-paramétré sur votre nom de domaine, avec SPF/DKIM et tout le bousin. Si vous n’utiliser pas Scaleway pour la partie DNS, il faudra adapter le provider DNS-01 en fonction pour le challenge ACME.
• Un environnement bash/zsh avec une belle brochette d’outils CLI préinstallés suivants : mise, step, direnv, bitwarden-cli, hcloud, talosctl, kubectl, helm, terraform, packer, flux, sops. On n’est pas là pour déconner. L’utilisation de brew ou encore mieux mise est vivement recommandé pour les installer et mettre à jour facilement.
• Outils complémentaires optionnels pour la productivité sur kube : cilium, cmctl, cnpg (plugin krew), k9s, ktop, kube-capacity, oh-my-zsh avec plugin kubectl pour les alias.

Vaultwarden 🔑

De nos jours, plus d’infra sérieuse sans KMS centralisé. Le 1er élément critique à mettre en place sera donc Vaultwarden. Il va nous permettre de stocker les secrets de notre infra, notamment les clés d’accès au service S3, les tokens d’authentification Tailscale, Hcloud, etc. À bichonner bien comme il se doit, et à héberger de préférence uniquement en interne ou sinon à travers un VPN.

Dans le cas où le self-hosting de KMS ne vous intéresse pas, vous pouvez utiliser directement le cloud Bitwarden et sauter à la section suivante. L’avantage ici est de pouvoir tester le bon fonctionnement de toute la chaîne VPN / DNS / Email / S3 avant de démarrer les choses sérieuses avec le cluster Talos. Nous n’userons pas de pratique GitOps à ce stade, on veut juste monter un KMS tout en restant propre et sécurisé.

Initialiser un VPS quelconque (Hetzner, OVH, etc.) ou un serveur interne chez vous avec un docker préinstallé (utiliser le script curl -fsSL https://get.docker.com | sh pour l’installer rapidement, mais non recommandé en production bien sûr 😊). Une machine basique suffit amplement (même un NAS ferait l’affaire). Voici un exemple typique simple à démarrer :

1
services:
2
  server:
3
    image: vaultwarden/server:latest
4
    restart: unless-stopped
5
    ports:
6
      - 3000:80
7
    environment:
8
      DOMAIN: https://vw.int.ohmytalos.io
9
      SMTP_HOST: smtp.tem.scaleway.com
10
      SMTP_FROM: vaultwarden@ohmytalos.io
11
      SMTP_PORT: 587
12
      SMTP_USERNAME: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
13
      SMTP_PASSWORD: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
14
    volumes:
15
      - data:/data
16

17
  backup:
18
    image: ttionya/vaultwarden-backup:latest
19
    restart: unless-stopped
20
    environment:
21
      RCLONE_REMOTE_DIR: ohmytalos/vaultwarden
22
      ZIP_PASSWORD: xxxxxxxxxxxxxxxxxxxx
23
      ZIP_TYPE: 7z
24
      BACKUP_KEEP_DAYS: 7
25
      CRON: 5 * * * *
26
    volumes:
27
      - data:/bitwarden/data/
28
      - ./rclone:/config/rclone
29

30
volumes:
31
  data:

1
[BitwardenBackup]
2
type = s3
3
provider = OVH
4
access_key_id = xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
5
secret_access_key = xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
6
region = gra
7
endpoint = s3.gra.io.cloud.ovh.net

1
{
2
    "Statement": [
3
        {
4
            "Action": [
5
                "s3:GetObject",
6
                "s3:PutObject",
7
                "s3:DeleteObject",
8
                "s3:ListBucket",
9
                "s3:ListMultipartUploadParts",
10
                "s3:ListBucketMultipartUploads",
11
                "s3:AbortMultipartUpload",
12
                "s3:GetBucketLocation"
13
            ],
14
            "Effect": "Allow",
15
            "Resource": [
16
                "arn:aws:s3:::ohmytalos/vaultwarden",
17
                "arn:aws:s3:::ohmytalos/vaultwarden/*"
18
            ],
19
            "Sid": "RWContainer"
20
        }
21
    ]
22
}

On démarre le tout avec un docker compose up -d et assurez-vous que tout tourne bien via docker compose logs -f. Une simple mise à jour du service se fera simplement avec docker compose pull && docker compose up -d.

Tailscale et Nginx

Pour accéder à notre Vaultwarden de manière sécurisé dans le cadre d’un VPS externe, on va devoir mettre en place un VPN. On va utiliser Tailscale pour ça. Pour faire simple et rapide lancer curl -fsSL https://tailscale.com/install.sh | sh (toujours à vos risques et périls !), ajouter le node dans votre tailnet via tailscale up, et si besoin approuvez-le. Lancer tailscale ip pour récupérer l’IP Tailscale du client, et créer un enregistrement DNS de type A (le CNAME fonctionne mal sur les clients Windows) dans votre zone DNS, par exemple vw.int.ohmytalos.io pointant vers cette IP privée.

On installe ensuite nginx avec un ufw qui va bien :

sudo apt install ufw nginx

sudo ufw allow ssh
# penser à whitelister votre propre ip sur le port ssh
sudo ufw deny 443/tcp
sudo ufw allow from 100.64.0.0/10 to any port 443 proto tcp
sudo ufw enable

Challenge DNS

C’est super, mais il n’y a pas de HTTPS et on ne va pas pouvoir utiliser HTTP-01 pour générer notre script puisque tout se situe dans un réseau privé. Nous allons utiliser acme.sh pour générer notre certificat TLS via le challenge DNS-01 qui supporte des tonnes de providers DNS. Installer acme.sh via curl https://get.acme.sh | sh -s email=my@ohmytalos.io puis configurer l’accès à l’API DNS de votre provider, ici Scaleway dans notre cas :

export SCALEWAY_API_TOKEN='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
acme.sh --issue --dns dns_scaleway -d vw.int.ohmytalos.io

mkdir -p /etc/nginx/certs

acme.sh --install-cert -d vw.int.ohmytalos.io \
  --key-file       /etc/nginx/certs/vw.int.ohmytalos.io.pem \
  --fullchain-file /etc/nginx/certs/vw.int.ohmytalos.io.crt \
  --reloadcmd     "service nginx force-reload"

À chaque renouvellement de certificats, on s’assure que nginx soit bien redémarré. Enfin, on peut créer la conf nginx pour le site dédié au vault :

1
server {
2
  listen 443 ssl http2;
3
  server_name vw.int.ohmytalos.io;
4

5
  ssl_certificate /etc/nginx/certs/vw.int.ohmytalos.io.crt;
6
  ssl_certificate_key /etc/nginx/certs/vw.int.ohmytalos.io.pem;
7

8
  location / {
9
    proxy_pass http://127.0.0.1:3000;
10
  }
11
}

Lancer ln -s /etc/nginx/sites-available/vaultwarden /etc/nginx/sites-enabled/ pour activer le site. Après redémarrage de nginx, vous devriez enfin accéder à votre Vaultwarden via https://vw.int.ohmytalos.io de manière sécurisé via tailscale.

Accès, backup et CLI

Connectez-vous à l’interface web pour créer un compte admin et/ou une orga dédiée. Assurez-vous que le backup fonctionne bien via docker compose exec backup bash /app/backup.sh et que le fichier zip chiffré est bien présent dans le bucket S3.

Ensuite, on installe le client Bitwarden via brew install bitwarden-cli. Puis activer le login via api-key et tester l’accès :

bw config server https://vw.int.ohmytalos.io
bw login --apikey
bw unlock

Tester avec bw list items pour voir si la liste des identifiants se fait bien. À partir de là, on a un KMS self-hosted de “pro” pour stocker les secrets de notre infra. Et l’on a pu en même temps nous assurer que tout est bon niveau VPN, DNS, envoi de mail et stockage S3, on est bien là non ?

Snapshots 💽

Deuxième prérequis nécessaire, nous allons avoir besoin d’uploader des images Talos prête à l’emploi pour la création à la volée de nos VPS. Un peu comme propose l’outil hcloud-upload-image, mais je préfère utiliser packer pour une approche plus GitOps.

La 1ère chose à faire est d’aller sur le site officiel de Talos Image Factory afin de construire vos images Talos personnalisées. Vous pouvez également créer un fichier de définition des extensions offline comme nous allons le faire ici.

Dans ce guide, nous allons avoir besoin de 2 types d’images :

1. Une dédiée pour les control planes, contenant l’extension Tailscale pour accéder à nos nodes en mode zero-trust.
2. Une dédiée par défaut pour les workers, sans Tailscale car l’on passera par les control planes pour y accéder, mais avec les extensions nécessaires au bon fonctionnement de Longhorn (iSCSI, util-linux-tools).

Créez-vous un nouveau répertoire projet ohmytalos-cluster puis les 2 fichiers suivants :

1
customization:
2
  systemExtensions:
3
    officialExtensions:
4
      - siderolabs/tailscale

1
customization:
2
  systemExtensions:
3
    officialExtensions:
4
      - siderolabs/iscsi-tools
5
      - siderolabs/util-linux-tools

Récupérer les hashs d’identifiant de l’image comme suit :

curl -s -X POST --data-binary @schematic-cp.yaml https://factory.talos.dev/schematics | jq .id
# 4a0d65c669d46663f377e7161e50cfd570c401f26fd9e7bda34a0216b6f1922b
curl -s -X POST --data-binary @schematic-wk.yaml https://factory.talos.dev/schematics | jq .id
# 613e1592b2da41ae5e265e8789429f22e121aab91cb4deb6bc3c0b6262961245

2 infos importantes à retenir à partir de ce hash :

• Notre image de première installation qui va nous servir pour la création de notre snapshot https://factory.talos.dev/image/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/v1.12.2/hcloud-amd64.raw.xz
• L’URL de l’image OCI pour les opérations d’upgrade factory.talos.dev/hcloud-installer/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:v1.12.2

Pour chaque image, il faut prévoir une pour l’archi amd64, et une autre pour arm64, car l’on pourrait très bien imaginer des node pools sous différentes architectures. Rajouter autant de schematics que nécessaire, par exemple une contenant les drivers spécifiques pour des clusters de nodes GPU. On reflète tout cela dans le fichier packer suivant :

1
packer {
2
  required_plugins {
3
    hcloud = {
4
      source  = "github.com/hetznercloud/hcloud"
5
      version = "~> 1"
6
    }
7
  }
8
}
9

10
variable "hcloud_token" {
11
  type      = string
12
  default   = env("HCLOUD_TOKEN")
13
  sensitive = true
14
}
15

16
variable "schematic_id" {
17
  type    = string
18
  default = "376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba"
19
}
20

21
variable "image_name" {
22
  type    = string
23
  default = "default"
24
}
25

26
variable "talos_version" {
27
  type    = string
28
  default = "v1.12.2"
29
}
30

31
variable "arch" {
32
  type    = string
33
}
34

35
variable "server_location" {
36
  type    = string
37
  default = "nbg1"
38
}
39

40
locals {
41
  server_types = {
42
    amd64 = "cpx22"
43
    arm64 = "cax11"
44
  }
45
  image = "https://factory.talos.dev/image/${var.schematic_id}/${var.talos_version}/hcloud-${var.arch}.raw.xz"
46
}
47

48
source "hcloud" "talos" {
49
  rescue       = "linux64"
50
  image        = "debian-13"
51
  location     = var.server_location
52
  server_type  = local.server_types[var.arch]
53
  ssh_username = "root"
54

55
  snapshot_name   = "talos system disk - ${var.image_name} - ${var.arch} - ${var.talos_version}"
56
  snapshot_labels = {
57
    type         = "infra",
58
    os           = "talos",
59
    version      = var.talos_version,
60
    arch         = var.arch,
61
    name         = var.image_name
62
  }
63
  token = var.hcloud_token
64
}
65

66
build {
67
  sources = ["source.hcloud.talos"]
68

69
  provisioner "shell" {
70
    inline = [
71
      "apt-get install -y wget",
72
      "wget -O /tmp/talos.raw.xz ${local.image}",
73
      "xz -d -c /tmp/talos.raw.xz | dd of=/dev/sda && sync",
74
    ]
75
  }
76
}

Il nous est maintenant possible de construire notre image Talos personnalisée pour chaque architecture. Pour cela, nous allons avoir besoin de préparer notre token API Hcloud secrète dans notre environnement. Créer un nouveau projet dédié sur Hcloud et générez-y une clé API read/write, puis enregistrer là dans le Vaultwarden. Retenez l’identifiant itemId dans l’URL et exportez-le dans ce fichier :

export HCLOUD_TOKEN=$(bw get password xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)

Ceci fait, lancer bw sync puis direnv allow pour activer les variables d’environnement spécifique au répertoire de travail courant. Ce dernier devrait ensuite vous demander votre mot de passe Vaultwarden. Une fois saisie, votre clé privée devrait être inscrite dans votre environnement, vérifier avec echo $HCLOUD_TOKEN.

Nous allons maintenant utiliser mise pour automatiser le build de nos images pour nos control planes et workers, créer le fichier suivant pour enregistrer nos tâches de build :

1
[tasks.install]
2
run = "packer init ."
3

4
[tasks.amd64-cp]
5
run = "packer build -var arch=amd64 -var image_name=cp -var schematic_id=4a0d65c669d46663f377e7161e50cfd570c401f26fd9e7bda34a0216b6f1922b ."
6

7
[tasks.arm64-cp]
8
run = "packer build -var arch=arm64 -var image_name=cp -var schematic_id=4a0d65c669d46663f377e7161e50cfd570c401f26fd9e7bda34a0216b6f1922b ."
9

10
[tasks.build-cp]
11
depends = ["amd64-cp", "arm64-cp"]
12

13
[tasks.amd64-wk]
14
run = "packer build -var arch=amd64 -var image_name=wk -var schematic_id=613e1592b2da41ae5e265e8789429f22e121aab91cb4deb6bc3c0b6262961245 ."
15

16
[tasks.arm64-wk]
17
run = "packer build -var arch=arm64 -var image_name=wk -var schematic_id=613e1592b2da41ae5e265e8789429f22e121aab91cb4deb6bc3c0b6262961245 ."
18

19
[tasks.build-wk]
20
depends = ["amd64-wk", "arm64-wk"]
21

22
[tasks.build]
23
depends = ["amd64-cp", "arm64-cp", "amd64-wk", "arm64-wk"]

Plus qu’à lancer mise build et c’est parti pour la construction de tous nos snapshots images Talos en parallèle. À la fin de l’opération, vous devriez obtenir 4 snapshots d’image prêt à l’emploi, visible dans l’onglet “Servers/Snapshots” sur Hetzner Cloud ou plus directement côté CLI via hcloud image list -t snapshot. Pour l’utilisation du CLI, pensez à créer puis activer le contexte auparavant via hcloud context create ohmytalos-dev puis hcloud context use ohmytalos-dev, une clé API uniquement en lecture suffira si vous choisissez la voie 100% terraform à la section 2 de ce guide.

Architecture cloud 🏭

Comme toute architecture kube qui se respecte, et à l’image des kubes managés des hyperscalers, notre IaC devra exprimer la notion de node pools, dans lesquels on indiquera les caractéristiques (type de machine par défaut, volumes, talos config, etc.) puis la liste des hosts. Chaque pool sera dédié à un type de workload spécifique. Dans ce guide, nous allons créer 2 node pools :

1. Un pool de worker : dédié aux workloads applicatifs, dont les nœuds ferons également office de reverse proxy traefik et seront rattachés à un load balancer Hcloud dédié au trafic public.
2. Un pool de stockage : dédié aux workloads type base de données, ainsi que backends de métriques, logs et traces, il sera composé de nœuds avec des volumes rattachés à haute capacité.

Côté choix du type de VPS, l’essentiel est de partir sur 4 Go de RAM (minimum requis) pour les control planes (3 fois pour HA), puis 8 Go de RAM pour les 5 workers, répartis sur les 2 node pools. Ensuite, vous aurez principalement le choix entre 2 typologies niveau performance/prix :

* Inclus le load balancer lb11 à 6,57€ HT

En imaginant un cluster de staging utilisant l’option 1, et un cluster de production sur l’option 2, vous arriverez très grossièrement à un coût total mensuel TTC de ~200€ en comptant tout. À ce tarif, vous pouvez être certain d’avoir bien plus de performance sous le capot tout en étant largement 10 fois moins cher qu’un équivalent anémique chez les hyperscalers. Le tout en étant maître de votre infra de A à Z, avec les avantages, mais aussi disons-le, les inconvénients que cela comporte.

Sur ce segment VPS low cost, en termes de perf CPU et I/O brute, seul OVH parvient à réellement rivaliser, mais pour une tarification 4 à 6 fois supérieure (en tenant compte du nombre de cœurs, par exemple 2 seulement pour un B3-8 à 33,48€ HT sans saving plans), ce qui commence à piquer pour monter une infra kube à haute dispo.

Architecture réseau 🌐

Avant de continuer, il est vital de bien poser l’architecture réseau de notre cluster. Il s’agit du système nerveux de Kubernetes, difficile de le changer après coup sans douleur, sinon à part le recréer. Nous allons dédier un subnet pour nos control planes et chaque node pool. Ce qui nous donne l’architecture suivante :

Côté configuration Talos, il faudra bien préciser la plage des pods et services dans la section cluster.network :

1
cluster:
2
  network:
3
    cni:
4
      name: none
5
    podSubnets:
6
      - 10.42.0.0/16
7
    serviceSubnets:
8
      - 10.43.0.0/16
9
  proxy:
10
    disabled: true
11
  externalCloudProvider:
12
    enabled: true

* Ne faite rien pour le moment, il s’agit juste d’un élément à garder en tête pour la prochaine section du guide.

Architecture storage 🗄️

Chiffrement des disques 🔐

Le chiffrement sera effectué à tous les niveaux, non seulement côté Longhorn mais aussi côté système grâce au support de chiffrement natif de Talos via LUKS. Nous utiliserons la config indiquée dans la doc officielle. Il existe trois types de volumes à chiffrer, les 2 volumes système STATE et EPHEMERAL, valable sur tous les nœuds, ainsi que le volume utilisateur longhorn spécifique aux volumes Hetzner que l’on rattachera aux nœuds du pool de stockage. Nous aurons donc besoin de déclarer jusqu’à 3 configurations de volumes dans notre fichier de configuration Talos :

1
apiVersion: v1alpha1
2
kind: VolumeConfig
3
name: STATE
4
encryption:
5
  keys:
6
    - nodeID: {}
7
      slot: 0
8
---
9
apiVersion: v1alpha1
10
kind: VolumeConfig
11
name: EPHEMERAL
12
encryption:
13
  keys:
14
    - static:
15
        passphrase: supersecret
16
      slot: 0
17
      lockToSTATE: true
18
---
19
apiVersion: v1alpha1
20
kind: UserVolumeConfig
21
name: longhorn
22
encryption:
23
  keys:
24
    - static:
25
        passphrase: supersecret
26
      slot: 0
27
      lockToSTATE: true

* De même cette partie sera traitée dans la prochaine section.

Nous utilisons des clés statiques en dehors du volume STATE afin de permettre la rotation des clés. Nouveauté de Talos 1.11, nous activons également lockToSTATE pour mixer la clé de chiffrement du volume EPHEMERAL et Longhorn avec un salt propre au volume STATE (utilisation d’une fonction de dérivation au niveau de la clé de déchiffrement). L’intérêt est que ces volumes soient indéchiffrables en cas de perte du volume STATE.

C’est le mode le plus sécurisé possible (en tout cas sur Hetzner Cloud à date), mais le moindre problème ou changement matériel entraînant une éventuelle modification de nodeID peut vous faire perdre l’ensemble des données du nœud. Toutefois l’utilisation de replicas Longhorn limite l’impact de la perte d’un nœud. Comme toujours un vrai backup externe sera toujours d’autant plus indispensable (naturellement chiffré). N’indiquez pas lockToSTATE (false par défaut) si vous préférez garder la possibilité de récupérer vos volumes en cas de perte du volume STATE.

Paramétrage Longhorn 🛠️

Pour automatiser au mieux la configuration des volumes pour Longhorn lors de son installation plus tard, le mieux est de préconfigurer les nodes en amont, via des labels et annotations spécifiques. Ils seront logiquement différents selon que ce soit un nœud de workload ou un nœud de stockage avec disque externe rattaché. Voici ce qu’on est en droit d’attendre comme labels et annotations pour chaque node pool selon notre schéma d’archi :

1
machine:
2
  nodeLabels:
3
    node.longhorn.io/create-default-disk: config
4
  nodeAnnotations:
5
    node.longhorn.io/default-disks-config: '[{"allowScheduling":true,"name":"system","path":"/var/lib/longhorn","tags":["local"]}]'
6
    node.longhorn.io/default-node-tags: '["worker"]'

1
machine:
2
  nodeLabels:
3
    node.kubernetes.io/exclude-from-external-load-balancers: "true"
4
    node.kubernetes.io/role: storage
5
    node.longhorn.io/create-default-disk: config
6
  nodeAnnotations:
7
    node.longhorn.io/default-disks-config: '[{"allowScheduling":true,"name":"system","path":"/var/lib/longhorn","tags":["local"]},{"allowScheduling":true,"name":"volume","path":"/var/mnt/longhorn","tags":["volume"]}]'
8
    node.longhorn.io/default-node-tags: '["storage"]'

On s’assure que seuls les nœuds workers soient rattachés aux loads balancers via le label node.kubernetes.io/exclude-from-external-load-balancers sur les autres pools.

Le label node.longhorn.io/create-default-disk: config permet de personnaliser la configuration par défaut des disques Longhorn via l’annotation node.longhorn.io/default-disks-config. On indique ici au format json que l’on souhaite un disque system local sur chaque nœud et un disque volume supplémentaire sur les nœuds de stockage. Ce dernier devra être monté au préalable sur /var/mnt/longhorn côté Hcloud.

On précise le tag local vs volume pour différencier les types de disques dans Longhorn, notamment pour l’aspect performance. On veut s’assurer en effet que les workloads à forts besoins en IOPS (base de données, etc) soient bien placés sur les disques locaux, plus performant que les disques externe.

On rajoute enfin node.longhorn.io/default-node-tags pour faciliter le placement des futurs volumes.

Conclusion

Voilà pour la partie préparatif, il est temps de commencer pour de vrai à la prochaine section.