Aller au contenu
DevSecOps Logo Stéphane ROBERT
Docs
Blog

Talos Linux ☁️ : cluster Kubernetes multi-AZ

Mise à jour :

Ce guide avancé détaille le déploiement d’un cluster Kubernetes Talos Linux en production sur une infrastructure cloud. Nous aborderons l’architecture multi-zones de disponibilité, le provisionnement Infrastructure as Code avec Terraform, le peering réseau, la haute disponibilité et les configurations de sécurité avancées.

Architecture de production cloud

Ce guide s’appuie sur les concepts Talos Linux détaillés dans le guide d’introduction. Nous allons déployer une architecture sur OUTSCALE avec :

  • 3 control-planes répartis sur 3 zones de disponibilité (quorum etcd)
  • 2 workers minimum pour la répartition de charge applicative
  • Réseau isolé avec peering entre bastion et cluster
  • Load balancer pour l’API Kubernetes

Création de l’image Talos (OMI)

Avant de déployer l’infrastructure, vous devez créer une OMI (Outscale Machine Image) Talos personnalisée. Talos utilise le service Image Factory qui permet de générer des images optimisées avec des extensions système spécifiques.

Comprendre Talos Image Factory

Talos Image Factory est un service public hébergé par Sidero Labs à l’adresse https://factory.talos.dev. Ce service permet de générer des images Talos personnalisées sans avoir à construire l’OS depuis les sources.

Pourquoi utiliser Image Factory ?

Contrairement aux distributions Linux traditionnelles, Talos ne permet pas d’installer des paquets après le déploiement. L’OS est immuable : tout le système est en lecture seule et ne peut être modifié. Cette approche offre une sécurité maximale mais nécessite d’intégrer toutes les personnalisations directement dans l’image OS.

Image Factory résout ce problème en permettant de :

  • Ajouter des extensions système : drivers matériels, utilitaires, outils de monitoring
  • Personnaliser les paramètres kernel : optimisations réseau, sécurité, performances
  • Générer des images compatibles avec votre plateforme cloud
  • Versionner les configurations : chaque schematic a un ID unique et reproductible

Un schematic est un fichier YAML qui décrit toutes les personnalisations à appliquer à l’image de base Talos. Il contient :

  • Extensions système : modules kernel, drivers spécifiques
  • Arguments kernel : paramètres de boot personnalisés
  • Configuration plateforme : optimisations pour l’environnement cible

Exemple de schematic minimal :

customization:
  extraKernelArgs:
    - "talos.platform=aws"

Le processus de génération suit ces étapes :

  1. Envoi du schematic : Vous envoyez votre fichier schematic.yaml à l’API Image Factory via une requête POST
  2. Calcul de l’ID : Image Factory calcule un hash SHA256 de votre schematic, créant un identifiant unique
  3. Génération de l’image : Le service génère une image personnalisée en appliquant vos modifications à l’image de base Talos
  4. Téléchargement : Vous récupérez l’image au format souhaité (RAW, QCOW2, ISO, etc.) via une URL unique

L’ID du schematic garantit que deux schematics identiques produisent toujours la même image, assurant la reproductibilité.

Image Factory supporte de nombreuses extensions officielles :

  • qemu-guest-agent : Agent QEMU pour la virtualisation
  • iscsi-tools : Support iSCSI pour le stockage réseau
  • util-linux-tools : Utilitaires système avancés
  • nut-client : Client UPS pour la gestion d’alimentation
  • intel-ice-firmware : Firmware pour cartes réseau Intel
  • nvidia-container-toolkit : Support GPU NVIDIA pour containers

Liste complète disponible sur factory.talos.dev ↗.

Avantages pour le cloud

Pour les déploiements cloud, Image Factory permet de :

  • Générer une image compatible avec votre plateforme cloud
  • Activer les optimisations spécifiques (NVMe, réseau accéléré, guest agent)
  • Configurer la console série pour les logs de démarrage
  • Appliquer les bonnes pratiques de sécurité (IMA, SELinux, PTI)
  • Créer une image reproductible pour tous vos déploiements

Prérequis pour la création d’image

Sur votre machine de travail, installez les outils nécessaires :

Terminal window
# Installer qemu-img pour la conversion d'images
sudo apt update
sudo apt install -y qemu-utils curl jq xz-utils


# AWS CLI pour Object Storage (compatible S3)
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install


# OSC-CLI pour l'API Outscale
pip install osc-sdk

Création du fichier schematic

Le fichier schematic.yaml définit les personnalisations de l’image Talos pour Outscale (compatible AWS) :

schematic.yaml
customization:
  extraKernelArgs:
    - "talos.platform=aws"        # Utiliser le mode AWS (compatible Outscale)
    - "console=tty1"
    - "console=ttyS0"              # Console série pour les logs
    - "net.ifnames=0"              # Nommage réseau prévisible
    - "init_on_alloc=1"            # Sécurité mémoire
    - "slab_nomerge"
    - "pti=on"
    - "consoleblank=0"
    - "nvme_core.io_timeout=4294967295"
    - "printk.devkmsg=on"
    - "ima_template=ima-ng"
    - "ima_appraise=fix"
    - "ima_hash=sha512"
    - "selinux=1"

Ces paramètres kernel sont optimisés pour :

  • La compatibilité avec l’infrastructure cloud Outscale
  • La sécurité renforcée (IMA, SELinux, PTI)
  • Les performances NVMe
  • Les logs via console série

:::tip[Plateforme cloud] L’argument talos.platform=aws indique à Talos comment interagir avec le cloud provider pour récupérer les métadonnées, la configuration réseau et les informations d’instance. Outscale utilisant une API compatible AWS, ce paramètre est approprié. :::

Génération de l’image Talos

Étape 1 : Envoyer le schematic à Image Factory

Terminal window
# Créer le répertoire de sortie
mkdir -p ./images


# Envoyer le schematic à Image Factory
curl -X POST --data-binary @schematic.yaml \
    https://factory.talos.dev/schematics \
    -o ./images/schematic-response.json


# Extraire l'ID du schematic
SCHEMATIC_ID=$(jq -r '.id' ./images/schematic-response.json)
echo "Schematic ID: $SCHEMATIC_ID"

Le schematic ID est un identifiant unique qui référence votre configuration personnalisée.

Étape 2 : Télécharger l’image

Terminal window
# Définir la version Talos souhaitée
TALOS_VERSION="v1.11.3"


```bash
# Télécharger l'image au format AWS (compatible Outscale)
curl -L "https://factory.talos.dev/image/${SCHEMATIC_ID}/${TALOS_VERSION}/aws-amd64.raw.xz" \
    -o ./images/aws-amd64.raw.xz


# Vérifier la taille du téléchargement
ls -lh ./images/aws-amd64.raw.xz

Étape 3 : Décompresser l’image

Terminal window
# Décompresser l'image (conserve l'archive .xz)
xz -d -k ./images/aws-amd64.raw.xz


# Vérifier l'image décompressée
ls -lh ./images/aws-amd64.raw

Étape 4 : Convertir l’image RAW en QCOW2

Outscale nécessite le format QCOW2 pour les images personnalisées :

Terminal window
# Convertir l'image RAW en QCOW2 avec compression
qemu-img convert -f raw -O qcow2 \
    -o compression_type=zlib \
    ./images/aws-amd64.raw \
    ./images/talos-outscale-${TALOS_VERSION}-${SCHEMATIC_ID}.qcow2


# Afficher les informations de l'image
qemu-img info ./images/talos-outscale-${TALOS_VERSION}-${SCHEMATIC_ID}.qcow2

Étape 5 : Redimensionner l’image (optionnel)

Terminal window
# Redimensionner l'image à 10GB
qemu-img resize ./images/talos-outscale-${TALOS_VERSION}-${SCHEMATIC_ID}.qcow2 10G


# Vérifier la nouvelle taille
qemu-img info ./images/talos-outscale-${TALOS_VERSION}-${SCHEMATIC_ID}.qcow2

Étape 6 : Nettoyage

Terminal window
# Supprimer les fichiers intermédiaires
rm -f ./images/aws-amd64.raw.xz ./images/aws-amd64.raw


# L'image finale est prête
echo "Image prête: ./images/talos-outscale-${TALOS_VERSION}-${SCHEMATIC_ID}.qcow2"

Import de l’image dans Outscale

L’import se fait en plusieurs étapes : upload vers Object Storage (OOS), création d’un snapshot, puis création de l’image machine (OMI).

Upload vers Object Storage

Terminal window
# Définir le nom de l'image générée
IMAGE_FILE="images/talos-outscale-v1.11.3-7998322abdf5a280c73a65f03f15fb276c94090610d4e7e060b98ef4b4c7690d.qcow2"


# Créer un bucket pour les imports d'images (si nécessaire)
aws s3 mb s3://import-images


# Uploader l'image
aws s3 cp "${IMAGE_FILE}" s3://import-images/


# Vérifier l'upload
aws s3 ls s3://import-images/

Génération d’une URL présignée :

Terminal window
# Générer une URL présignée valide 1 heure
PRESIGNED_URL=$(aws s3 presign s3://import-images/talos-outscale-v1.11.3-7998322abdf5a280c73a65f03f15fb276c94090610d4e7e060b98ef4b4c7690d.qcow2)


echo "URL présignée: $PRESIGNED_URL"

Création du snapshot :

Terminal window
# Créer un snapshot depuis l'URL présignée
osc-cli api CreateSnapshot \
  --FileLocation "${PRESIGNED_URL}" \
  --SnapshotSize 10737418240 \
  --Description "Talos v1.10.6 snapshot imported from bucket"


# Récupérer l'ID du snapshot créé
SNAPSHOT_ID=$(osc-cli api ReadSnapshots \
  --Filters '{"Descriptions": ["Talos v1.10.6 snapshot imported from bucket"]}' \
  | jq -r '.Snapshots[0].SnapshotId')


echo "Snapshot créé: ${SNAPSHOT_ID}"

Création de l’OMI :

Terminal window
# Créer l'OMI
IMAGE_ID=$(osc-cli api CreateImage \
  --ImageName "Talos-v1.11.3-Outscale" \
  --Description "Talos Linux v1.11.3 - Kubernetes OS" \
  --Architecture "x86_64" \
  --RootDeviceName "/dev/sda1" \
  --BlockDeviceMappings '[
    {
      "DeviceName": "/dev/sda1",
      "Bsu": {
        "SnapshotId": "'"${SNAPSHOT_ID}"'",
        "VolumeSize": 10,
        "VolumeType": "gp2",
        "DeleteOnVmDeletion": true
      }
    }
  ]' \
  | jq -r '.Image.ImageId')


echo "OMI créée: ${IMAGE_ID}"


# Vérifier l'OMI
osc-cli api ReadImages \
  --Filters '{"ImageIds": ["'"${IMAGE_ID}"'"]}' \
  | jq '.Images[0] | {ImageId, ImageName, State, Description}'

Vérification :

Terminal window
# Lister toutes vos images Talos
osc-cli api ReadImages \
  --Filters '{"ImageNames": ["Talos*"]}' \
  | jq -r '.Images[] | "\(.ImageId) - \(.ImageName) - \(.State)"'

Provisionnement de l’infrastructure cloud

L’image Talos étant prête, provisionons l’infrastructure avec Terraform pour garantir la reproductibilité et le versioning de l’infrastructure as code. Ici nous présentons une architecture générique adaptable à tous les clouds.

Architecture réseau générique

L’architecture suivante est applicable à tous les clouds avec adaptation de la terminologie.

Exemple d’implémentation sur Outscale :

L’infrastructure repose sur deux réseaux virtuels distincts reliés par peering :

  • Réseau 1 (Bastion) : Contient le bastion avec load balancer dans un subnet public
    • Subnet public : 10.100.0.0/24
    • Le bastion sert de point d’entrée pour l’administration et peut héberger un load balancer pour l’API Kubernetes
  • Réseau 2 (Cluster Kubernetes) : Héberge les nœuds Talos répartis sur 3 zones de disponibilité
    • Subnet public : 10.0.254.0/24 (pour les Internet/NAT Gateways)
    • Subnet privé AZ-1 : 10.0.1.0/24 (control-plane 1 + worker 1)
    • Subnet privé AZ-2 : 10.0.2.0/24 (control-plane 2 + worker 2)
    • Subnet privé AZ-3 : 10.0.3.0/24 (control-plane 3)

Cette architecture offre plusieurs avantages :

  • Isolation réseau : Séparation claire entre infrastructure d’administration et cluster Kubernetes
  • Haute disponibilité : Les nœuds control-plane sont distribués sur 3 zones de disponibilité différentes (AZ)
  • Sécurité : Les nœuds Talos sont dans des subnets privés, accessibles uniquement via le peering
  • Connectivité Internet : Accès sortant pour télécharger les images et mises à jour via NAT Gateway

Peering entre réseaux

Le peering permet la communication directe entre le bastion et les nœuds Talos sans transiter par Internet :

  • Le bastion (10.100.0.x) peut joindre tous les nœuds du cluster (10.0.1.x, 10.0.2.x, 10.0.3.x)
  • Les nœuds Talos peuvent communiquer entre eux à travers les subnets
  • Le load balancer distribue le trafic API Kubernetes vers les 3 control-planes

Distribution des instances

Les instances Talos sont créées avec des ip statiques dans les subnets privés selon cette répartition :

  • AZ-1 (eu-west-2a) :
    • talos-cp-1 : 10.0.1.10 (control-plane)
    • talos-worker-1 : 10.0.1.20 (worker)
  • AZ-2 (eu-west-2b) :
    • talos-cp-2 : 10.0.2.11 (control-plane)
    • talos-worker-2 : 10.0.2.21 (worker)
  • AZ-3 (eu-west-2c) :
    • talos-cp-3 : 10.0.3.12 (control-plane)
    • talos-worker-3 : 10.0.3.22 (worker)

Cette répartition garantit que la perte d’une zone de disponibilité complète n’affecte pas le quorum etcd (2 control-planes sur 3 restent disponibles).

Boot des instances

Les instances Talos démarrent depuis l’image cloud créée précédemment. L’image contient tout le système d’exploitation et boot directement sans configuration supplémentaire.

Génération des configurations Talos

La première étape du déploiement consiste à générer les Machine Configs, les manifestes YAML qui définissent complètement chaque nœud Talos. Ce processus est identique quel que soit le cloud provider.

Génération initiale

Depuis le bastion (ou votre machine locale avec accès réseau aux instances), générez les configurations de base. Utilisez le FQDN ou l’IP du Load Balancer comme endpoint.

Exemple avec un load balancer Outscale :

Terminal window
# Se connecter au bastion
ssh talos-bastion


# Définir les variables d'environnement avec les valeurs affichées dans le message de connexion (motd)
export CLUSTER_NAME="talos-prod"
export KUBE_LBU="internal-talos-prod-k8s-lb-640339891.eu-west-2.lbu.outscale.com"

Important : Créez fichier cilium-patch.yaml qui doit contenir la configuration pour désactiver kube-proxy car Cilium le remplacera :

cluster:
  network:
    cni:
      name: none
  proxy:
    disabled: true

Générez ensuite les configurations avec le patch Cilium :

Terminal window
talosctl gen config "$CLUSTER_NAME" "https://${KUBE_LBU}:6443" \
  --output ./talos-out \
  --additional-sans "$KUBE_LBU" \
  --additional-sans "10.0.1.10" \
  --config-patch @cilium-patch.yaml

Cette commande crée un dossier talos-out contenant :

  • talosconfig : Le fichier de configuration pour talosctl (équivalent du kubeconfig)
  • controlplane.yaml : La Machine Config pour les nœuds control-plane
  • worker.yaml : La Machine Config pour les nœuds workers
  • secrets.yaml : Les secrets partagés du cluster (à conserver précieusement)

Configuration de talosctl

Configurez le fichier talosconfig pour cibler les control-planes :

Terminal window
# Définir les endpoints (IPs des control-planes)
talosctl --talosconfig ./talos-out/talosconfig config endpoint 10.0.1.10 10.0.2.11 10.0.3.12


# Définir les nodes par défaut
talosctl --talosconfig ./talos-out/talosconfig config node ${KUBE_LBU}


# Vérifier la configuration
talosctl --talosconfig ./talos-out/talosconfig config info

Le fichier talosconfig contient les certificats et clés pour s’authentifier auprès de l’API Talos. Conservez-le précieusement car il donne un accès administrateur complet au cluster.

Application des configurations et bootstrap du cluster

Maintenant que les configurations sont prêtes, appliquons-les aux nœuds pour initialiser le cluster.

Application aux trois control-planes

Appliquez la configuration aux trois nœuds control-plane. L’option --insecure est nécessaire lors de la première application car les nœuds n’ont pas encore de certificats configurés.

:::tip[Application séquentielle recommandée] Pour le premier déploiement, il est recommandé d’appliquer les configurations séquentiellement avec un délai entre chaque nœud. Cela évite que les 3 nœuds redémarrent simultanément et permet une formation plus stable du quorum etcd. :::

Terminal window
# Appliquer la config au premier control-plane
talosctl --talosconfig ./talos-out/talosconfig \
  --nodes 10.0.1.10 \
  apply-config --insecure \
  --file ./talos-out/controlplane.yaml


# Attendre 10 secondes
sleep 10


# Vérifier le statut du nœud
talosctl --talosconfig ./talos-out/talosconfig \
  --nodes 10.0.1.10 \
  version


# Appliquer la config au deuxième control-plane
talosctl --talosconfig ./talos-out/talosconfig \
  --nodes 10.0.2.11 \
  apply-config --insecure \
  --file ./talos-out/controlplane.yaml


# Attendre 10 secondes
sleep 10
# Vérifier le statut du nœud
talosctl --talosconfig ./talos-out/talosconfig \
  --nodes 10.0.2.11 \
  version


# Appliquer la config au troisième control-plane
talosctl --talosconfig ./talos-out/talosconfig \
  --nodes 10.0.3.12 \
  apply-config --insecure \
  --file ./talos-out/controlplane.yaml


# Vérifier le statut du nœud
talosctl --talosconfig ./talos-out/talosconfig \
  --nodes 10.0.3.12 \
  version

Les nœuds vont redémarrer et appliquer la configuration. Ce processus prend environ 1 minutes par nœud.

Bootstrap d’etcd

Une fois les control-planes configurés et redémarrés (attendre environ 2 minutes après la dernière application de config), initialisez le cluster etcd. Cette opération ne doit être effectuée qu’une seule fois sur un seul nœud :

Terminal window
# Bootstrap etcd sur le premier control-plane uniquement
talosctl --talosconfig ./talos-out/talosconfig \
  --nodes 10.0.1.10 \
  bootstrap

Cette commande initialise le quorum etcd et démarre les composants du plan de contrôle Kubernetes (kube-apiserver, kube-controller-manager, kube-scheduler). Après quelques minutes, l’API Kubernetes devient accessible via le load balancer.

Vérifiez l’état du cluster :

Terminal window
# Vérifier les membres etcd (devrait afficher les 3 control-planes)
talosctl --talosconfig ./talos-out/talosconfig \
  --nodes 10.0.1.10 \
  --endpoints 10.0.1.10 \
  get members

Résultat attendu avec 3 membres :

NODE        NAMESPACE   TYPE     ID             VERSION   HOSTNAME
10.0.1.10   cluster     Member   ip-10-0-1-10   1         ip-10-0-1-10.eu-west-2.compute.internal
10.0.1.10   cluster     Member   ip-10-0-2-11   1         ip-10-0-2-11.eu-west-2.compute.internal
10.0.1.10   cluster     Member   ip-10-0-3-12   1         ip-10-0-3-12.eu-west-2.compute.internal

Récupération du kubeconfig et installation du CNI

À ce stade, le cluster Kubernetes tourne mais les nœuds ne sont pas encore Ready car aucun plugin réseau (CNI) n’est installé.

Récupération du kubeconfig

Récupérez le fichier kubeconfig pour accéder au cluster avec kubectl :

Terminal window
# Création du dossier .kube
mkdir -p ~/.kube
# Récupérer le kubeconfig depuis le cluster
talosctl --talosconfig ./talos-out/talosconfig \
  --nodes 10.0.1.10 \
  --endpoints 10.0.1.10 \
  kubeconfig ~/.kube/config --force


# Vérifier l'accès au cluster
kubectl cluster-info

Vous devriez voir vos nœuds mais avec le statut NotReady car le CNI n’est pas encore installé :

Terminal window
kubectl get nodes


NAME           STATUS     ROLES           AGE     VERSION
ip-10-0-1-10   NotReady   control-plane   7m14s   v1.34.1
ip-10-0-2-11   NotReady   control-plane   6m41s   v1.34.1
ip-10-0-3-12   NotReady   control-plane   6m21s   v1.34.1

Installation de Cilium comme CNI

Talos supporte plusieurs CNI (Calico, Flannel, Cilium). Cilium est recommandé pour ses performances basées sur eBPF, ses fonctionnalités de sécurité réseau avancées et son remplacement de kube-proxy.

Installation de Cilium avec Helm et configuration spécifique pour Talos.

Configuration recommandée pour Outscale (native routing) :

Terminal window
# Ajouter le dépôt Helm Cilium
helm repo add cilium https://helm.cilium.io/
helm repo update


# Installer Cilium avec les paramètres adaptés à Talos sur Outscale
helm install cilium cilium/cilium \
  --namespace kube-system \
  --set ipam.mode=kubernetes \
  --set kubeProxyReplacement=true \
  --set securityContext.capabilities.ciliumAgent="{CHOWN,KILL,NET_ADMIN,NET_RAW,IPC_LOCK,SYS_ADMIN,SYS_RESOURCE,DAC_OVERRIDE,FOWNER,SETGID,SETUID}" \
  --set securityContext.capabilities.cleanCiliumState="{NET_ADMIN,SYS_ADMIN,SYS_RESOURCE}" \
  --set cgroup.autoMount.enabled=false \
  --set cgroup.hostRoot=/sys/fs/cgroup \
  --set k8sServiceHost=${KUBE_LBU} \
  --set k8sServicePort=6443

Variante avec routage natif optimisé (pour clusters multi-AZ) :

Terminal window
# Installation avec native routing et auto-direct-node-routes
helm install cilium cilium/cilium \
  --namespace kube-system \
  --set ipam.mode=kubernetes \
  --set kubeProxyReplacement=true \
  --set securityContext.capabilities.ciliumAgent="{CHOWN,KILL,NET_ADMIN,NET_RAW,IPC_LOCK,SYS_ADMIN,SYS_RESOURCE,DAC_OVERRIDE,FOWNER,SETGID,SETUID}" \
  --set securityContext.capabilities.cleanCiliumState="{NET_ADMIN,SYS_ADMIN,SYS_RESOURCE}" \
  --set cgroup.autoMount.enabled=false \
  --set cgroup.hostRoot=/sys/fs/cgroup \
  --set k8sServiceHost=<VOTRE_LOAD_BALANCER_FQDN> \
  --set k8sServicePort=6443 \
  --set routingMode=native \
  --set autoDirectNodeRoutes=true \
  --set ipv4NativeRoutingCIDR=10.244.0.0/16

Vérification du déploiement de Cilium

Attendez que les pods Cilium soient Running :

Terminal window
# Surveiller le déploiement de Cilium
kubectl get pods -n kube-system -l k8s-app=cilium -w


# Vérifier le statut de Cilium
kubectl -n kube-system exec -it ds/cilium -- cilium status

Résultat attendu :

KVStore:                 Disabled
Kubernetes:              Ok         1.34 (v1.34.1) [linux/amd64]
Kubernetes APIs:         ["EndpointSliceOrEndpoint", "cilium/v2::CiliumCIDRGroup", "cilium/v2::CiliumClusterwideNetworkPolicy", "cilium/v2::CiliumEndpoint", "cilium/v2::CiliumNetworkPolicy", "cilium/v2::CiliumNode", "core/v1::Pods", "networking.k8s.io/v1::NetworkPolicy"]
KubeProxyReplacement:    True   [eth0   10.0.2.11 fe80::a837:40ff:fe87:b736 (Direct Routing)]
Host firewall:           Disabled
SRv6:                    Disabled
CNI Chaining:            none
CNI Config file:         successfully wrote CNI configuration file to /host/etc/cni/net.d/05-cilium.conflist
Cilium:                  Ok   1.18.3 (v1.18.3-c1601689)
NodeMonitor:             Listening for events on 4 CPUs with 64x4096 of shared memory
Cilium health daemon:    Ok
IPAM:                    IPv4: 4/254 allocated from 10.244.1.0/24,
IPv4 BIG TCP:            Disabled
IPv6 BIG TCP:            Disabled
BandwidthManager:        Disabled
Routing:                 Network: Tunnel [vxlan]   Host: Legacy
Attach Mode:             TCX
Device Mode:             veth
Masquerading:            IPTables [IPv4: Enabled, IPv6: Disabled]
Controller Status:       27/27 healthy
Proxy Status:            OK, ip 10.244.1.157, 0 redirects active on ports 10000-20000, Envoy: external
Global Identity Range:   min 256, max 65535
Hubble:                  Ok              Current/Max Flows: 654/4095 (15.97%), Flows/s: 13.89   Metrics: Disabled
Encryption:              Disabled
Cluster health:          0/0 reachable   (2025-11-12T07:18:10Z)   (Probe interval: 0s)
Name                     IP              Node                     Endpoints
Modules Health:          Stopped(12) Degraded(0) OK(68)

Vérifiez que les nœuds sont maintenant Ready :

Terminal window
kubectl get nodes

Résultat attendu :

NAME            STATUS   ROLES           AGE     VERSION
talos-cp-1      Ready    control-plane   15m     v1.31.1
talos-cp-2      Ready    control-plane   12m     v1.31.1
talos-cp-3      Ready    control-plane   12m     v1.31.1

Tous les nœuds control-plane sont maintenant Ready. Il est temps d’ajouter les workers pour héberger les charges applicatives.

Ajout des nœuds workers

Une fois Cilium déployé et les control-planes en état Ready, vous pouvez ajouter les nœuds workers au cluster. Ces nœuds hébergeront vos applications.

Terminal window
# Appliquer la configuration au premier worker
talosctl --talosconfig ./talos-out/talosconfig \
  apply-config --insecure \
  --nodes 10.0.1.20 \
  --file ./talos-out/worker.yaml


# Appliquer la configuration au deuxième worker
talosctl --talosconfig ./talos-out/talosconfig \
  apply-config --insecure \
  --nodes 10.0.2.21 \
  --file ./talos-out/worker.yaml


# Appliquer la configuration au troisième worker
talosctl --talosconfig ./talos-out/talosconfig \
  apply-config --insecure \
  --nodes 10.0.3.22 \
  --file ./talos-out/worker.yaml

Les workers vont démarrer et s’enregistrer automatiquement auprès du plan de contrôle. Vous pouvez suivre leur progression :

Terminal window
# Surveiller l'ajout des workers
kubectl get nodes -w

Après 2-3 minutes, vous devriez voir tous les nœuds (control-planes + workers) en état Ready :

NAME           STATUS   ROLES           AGE   VERSION
NAME           STATUS   ROLES           AGE     VERSION
ip-10-0-1-10   Ready    control-plane   19m     v1.34.1
ip-10-0-1-20   Ready    <none>          3m18s   v1.34.1
ip-10-0-2-11   Ready    control-plane   18m     v1.34.1
ip-10-0-2-21   Ready    <none>          3m13s   v1.34.1
ip-10-0-3-12   Ready    control-plane   18m     v1.34.1
ip-10-0-3-22   Ready    <none>          2m50s   v1.34.1

Les workers sont maintenant prêts à recevoir des pods. Kubernetes va automatiquement distribuer les charges applicatives sur ces nœuds selon les politiques de scheduling configurées.

Test de connectivité

Déployons un Deployment de test pour valider la connectivité réseau :

Terminal window
# Créer un Deployment nginx-unprivileged conforme aux PodSecurity policies
cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      securityContext:
        runAsNonRoot: true
        runAsUser: 101
        runAsGroup: 101
        fsGroup: 101
        seccompProfile:
          type: RuntimeDefault
      containers:
      - name: nginx
        image: nginxinc/nginx-unprivileged:alpine
        ports:
        - containerPort: 8080
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop:
            - ALL
          readOnlyRootFilesystem: false
EOF


# Exposer via un Service
kubectl expose deployment nginx --port=8080 --type=ClusterIP


# Attendre que le pod nginx soit prêt
kubectl wait --for=condition=ready pod -l app=nginx --timeout=60s


# Tester l'accès au service via port-forward depuis le bastion
# Ouvrir un port-forward en arrière-plan
kubectl port-forward deployment/nginx 8080:8080


# Attendre que le port-forward soit établi
sleep 2


# Tester l'accès
curl -s http://localhost:8080 | head -n 15


# Arrêter le port-forward avec un Ctrl+C ou tuer le processus en arrière-plan

Si la commande retourne le HTML par défaut de nginx, la connectivité réseau fonctionne correctement.

Une fois les tests terminés, nettoyez les ressources :

Terminal window
# Supprimer le deployment et le service de test
kubectl delete deployment nginx
kubectl delete service nginx

Conclusion

Ce guide vous a permis de déployer un cluster Kubernetes Talos Linux hautement disponible en production sur une infrastructure cloud Outscale. L’architecture multi-zones de disponibilité avec peering réseau offre :

  • Haute disponibilité : Résistance à la perte d’une zone complète
  • Isolation réseau : Séparation bastion/cluster avec peering sécurisé
  • Reproductibilité : Infrastructure as Code complète avec Terraform
  • Sécurité renforcée : OS immuable, pas d’accès SSH, certificats automatiques
  • Simplicité opérationnelle : API unique (talosctl) pour toutes les opérations
  • Portabilité cloud : Architecture adaptable à d’autres fournisseurs cloud.

Pour l’apprentissage et les tests, consultez le guide d’introduction Talos avec Docker/QEMU local qui permet d’expérimenter dans un environnement sûr avant le passage en production.

Dans un prochain guide, nous aborderons l’installationtion des drivers CSI et CCM pour intégrer le stockage et la gestion des instances cloud notre Cluster Talos Linux.

Plus d’infos