Aller au contenu

Premier deploiement reel : ce que l'apply a appris

Ce document consigne le premier passage complet sur Scaleway, le 19/10/2026. Tout ce qui suit vient d'un tofu apply reel, pas d'une relecture.

Ce qui tourne

Une control plane GP1-XS a fr-par-1, un cluster Talos v1.13.11, Kubernetes 1.36.1, noeud Ready.

Couche plateforme : Cilium 1.20.3 en remplacement de kube-proxy, chiffrement WireGuard, mode pare-feu en audit, cert-manager v1.21.2, Istio 1.30.6 par la Gateway API v1.4.0.

Couche bord : Gateway edge-gateway acceptee et programmed, deux HTTPRoute, application de demonstration en deux replicas. Le HTTP repond 301 vers HTTPS sur le port NodePort de la passerelle.

Operateur : les deux CRD s'installent, BlocklistSource alimente Cilium et l'EdgeSite deploie ses objets.

name kind enforce entries shards synced test-cve Certain true 2 1 oui test-proxies Presumed false 2 1 oui

Le premier produit un CiliumCIDRGroup avec les prefixes attendus, et une CiliumClusterwideNetworkPolicy qui selectionne le groupe par etiquette, donc insensible au decoupage en tranches :

externalCIDRs: ["198.51.100.0/24", "203.0.113.45/32"] ingressDeny: [{ fromCIDRSet: [{ cidrGroupSelector: { edge.exoledge.io/source: test-cve } }] }]

Le second, de presumption, part en ConfigMap pour le decideur, sans aucune politique noyau. C'est la separation voulue.

L'EdgeSite cree Gateway, HTTPRoute, Service, Deployment du decideur, ConfigMap de configuration, WasmPlugin et Certificate, et passe Ready=True.

Quatre blocages, quatre corrections

  1. Disque racine. scaleway_instance_server.root_volume.volume_id n'accepte qu'un volume de l'API Instance, et un volume bloc SBS n'y est pas visible. La chaine qui marche : snapshot d'instance importe du bucket, puis image privee creee depuis ce snapshot, puis image sur le serveur. Passer directement le snapshot en image echoue, le provider le resout comme une image du catalogue.

  2. Gamme d'instance. Le snapshot importe est de type l_ssd : les gammes PLAY2 le refusent. GP1-XS accepte.

  3. Identifiant d'Elastic Metal. Le provider rend fr-par-1/<uuid>, que le CLI scw refuse. Il faut depouiller le prefixe de zone avant l'appel.

  4. Capacites Cilium. L'init apply-sysctl-overwrites echoue parce que Talos monte /proc/sys en lecture seule : sysctlfix.enabled: false. Puis clean-cilium-state echoue sur SYS_MODULE, capacite que Talos retire du noyau : runc refuse d'accorder une capacite absente du jeu herite. En privilegie, Cilium ne la demande plus.

Un cinquieme blocage, plus vicieux, a coute dix minutes d'attente : talos_cluster_kubeconfig recevait https://<ip>:6443, l'adresse de l'API Kubernetes, alors que son champ endpoint designe celle du client Talos. La poignee de main TLS se faisait donc avec kube-apiserver, et le provider rendait x509: certificate signed by unknown authority sur un cluster parfaitement sain. Corrige en passant l'adresse du control plane : le provider en deduit :50000 pour Talos et ecrit :6443 comme server: du kubeconfig.

Deux defauts de generation ont aussi ete corriges : les etiquettes du bucket attendaient une table et non une liste, et les CRD sortaient avec un groupe vide faute de marqueur +groupName, ce que kubeconform ne pouvait pas voir.

Ce qui reste ouvert

  • Pas de nom de domaine : les deux Certificate restent False, Let's Encrypt ne peut pas valider un nom qui ne resout pas. Le HTTPS n'est donc pas servi.
  • Elastic Metal inutilisable : le mode rescue demarre mais refuse la cle SSH, ssh_key_ids restant vide cote serveur. L'installation par dd n'a donc pas pu se faire, et le POC tourne sur la control plane seule.
  • Le decideur n'est pas demarre : son image n'existe pas encore dans un registre.
  • Le WasmPlugin reference un artefact OCI qui n'est pas publie non plus.