Kubernetes sur ARM : ce que la migration coûte vraiment

Le discours commercial autour des nœuds ARM tient en une phrase : on change la famille d'instances, on économise 20 à 40 % et on repart travailler. Sur le terrain, la bascule d'un cluster Kubernetes vers de l'ARM n'est presque jamais un problème de compute. C'est un problème de chaîne de build, de registre d'images, d'agents tiers et d'une poignée de dépendances natives qui n'ont jamais été compilées pour autre chose que du x86. Le processeur, lui, se comporte très bien.

L'écosystème a basculé pendant qu'on regardait ailleurs. Amazon revendique que ses puces Graviton représentent plus de la moitié de la nouvelle capacité CPU ajoutée à AWS sur les trois dernières années, et son Graviton5 annoncé en décembre 2025 embarque 192 cœurs Neoverse V3 pour environ 25 % de performance en plus que la génération précédente. Google pousse Axion, Azure ses Cobalt, Ampere fournit les autres. ARM en production n'est plus un pari technologique, c'est un choix d'architecture qui se planifie. Reste à savoir ce qu'il implique côté exploitation.

Le chiffre « 40 % de rapport prix-performance en plus » est un chiffre de constructeur, pas un résultat garanti sur votre charge. Il agrège deux effets distincts qu'il faut séparer avant de bâtir un business case.

Le premier effet est tarifaire : à vCPU équivalent, une instance ARM est facturée moins cher. C'est mécanique et immédiat. Le second est de performance brute, et là ça dépend entièrement du workload. Sur des bases de données, les mesures publiées par AWS sur Amazon RDS donnent 41 % de débit en plus pour Graviton4 comparé à Graviton2, et 23 % comparé à Graviton3. Sur un service HTTP en Go qui passe son temps à faire du parsing JSON et des appels réseau, le gain se rapproche du linéaire. Sur du calcul vectoriel optimisé AVX-512 à la main, il peut être négatif.

Le point de vigilance côté perf par watt : les benchmarks constructeurs se contredisent frontalement. AMD publie des comparatifs où ses EPYC dominent Grace ou Ampere Altra Max en performance par watt système, Ampere publie l'inverse. Les campagnes indépendantes de Phoronix sur AmpereOne montrent un tableau nuancé selon la nature de la charge. Traduction opérationnelle : aucun de ces chiffres ne remplace un benchmark de votre application sur votre profil de trafic. Trois jours de mesure valent mieux qu'un slide.

La règle qu'on applique : on ne valide jamais une migration ARM sur la base d'un tarif horaire. On mesure le coût par requête servie ou par transaction traitée, ce qui suppose d'avoir déjà instrumenté la ventilation des coûts par namespace et par workload. Sans cette base, on compare des prix d'instance et pas des coûts de service.

Un nœud ARM ne sait pas exécuter une image x86. Toute la migration se joue donc dans le registre. La cible est une image dont le manifeste est une liste d'index pointant vers plusieurs variantes de plateforme, typiquement linux/amd64 et linux/arm64. Le kubelet et le runtime tirent alors automatiquement la bonne variante selon l'architecture du nœud, sans que le manifeste du pod n'ait à s'en préoccuper. C'est le seul modèle viable en migration progressive : le même tag fonctionne des deux côtés.

Docker Buildx sait produire ça en une commande :

docker buildx build \
  --platform linux/amd64,linux/arm64 \
  -t registry.example.net/app:1.42 \
  --push .

Le piège est dans ce qui se passe derrière. La documentation Docker liste trois stratégies pour produire ces variantes, et le choix par défaut est le pire des trois.

L'émulation QEMU est celle qu'on obtient sans rien faire, sur un runner x86 classique. La doc officielle est explicite : l'émulation « peut être bien plus lente que des builds natifs, en particulier sur les tâches gourmandes en calcul comme la compilation ou la compression ». Sur une image applicative qui compile du code, le facteur est brutal. Docker documente des cas où un build émulé prend près de sept fois plus de temps que la même construction en cross-compilation. Un pipeline qui tournait en quatre minutes en repart à vingt-cinq, et l'équipe conclut que « ARM, c'est lent ». Non : c'est l'émulation qui est lente.

Les nœuds de build natifs consistent à déclarer un builder Buildx multi-nœuds, avec un nœud amd64 et un nœud arm64, chacun construisant sa propre variante à pleine vitesse. C'est la solution la plus rapide et la seule qui gère correctement les cas tordus que QEMU rate. Le coût est opérationnel : il faut entretenir une flotte de runners hétérogène, ce qui rejoint directement les arbitrages sur l'hébergement de ses propres runners de CI.

La cross-compilation exploite les arguments de plateforme prédéfinis dans un build multi-étapes : l'étape de compilation tourne nativement sur l'architecture du builder et produit un binaire pour l'architecture cible. C'est excellent en Go et en Rust, où le support est de première classe. C'est nettement plus douloureux dès qu'un module natif entre en jeu.

Le seuil de décision qu'on retient : tant qu'un build émulé reste sous les cinq minutes, on laisse QEMU tranquille. Au-delà, on passe en natif ou en cross-compilation. Bricoler des optimisations de cache pour rattraper un facteur sept d'émulation est une perte de temps.

La compatibilité applicative pure est rarement le problème. Ce qui casse se répartit en quatre familles, par ordre de fréquence constatée.

Les DaemonSets tiers. C'est le blocage numéro un et il est structurel. Un agent de collecte de logs, un exportateur de métriques, un agent de sécurité, un plugin CSI ou CNI : chacun tourne sur tous les nœuds par construction. Si un seul de ces composants n'a pas de variante arm64, le nœud ARM démarre, accepte des pods et se retrouve sans supervision, sans collecte de logs ou sans réseau. Le pod reste en ImagePullBackOff et personne ne le voit tout de suite parce que le cluster, lui, a l'air en bonne santé. L'inventaire des DaemonSets se fait avant, pas après.

Les dépendances natives compilées. Les extensions C de Python distribuées en roues précompilées, les modules Node passant par node-gyp, les bibliothèques chargées via JNI en Java. La situation s'est massivement améliorée, la plupart des projets majeurs publient désormais des roues manylinux_aarch64, mais la queue de distribution reste peuplée. Une dépendance transitive de trois niveaux de profondeur qui n'a pas de roue ARM déclenche une compilation depuis les sources au moment du build, ce qui allonge le pipeline ou le fait échouer sur une chaîne de compilation absente de l'image.

Les binaires propriétaires sans source. Un agent de licence, un connecteur éditeur, un pilote de matériel spécifique, un ancien client de base de données fourni en .so x86-only. Il n'y a pas de contournement propre : soit l'éditeur publie une variante ARM, soit ce workload reste sur x86. Le tenter sous émulation en production est une fausse bonne idée qui se paie en latence et en incidents difficiles à diagnostiquer.

Les hypothèses cachées dans le code et les configs. Chemins en dur contenant x86_64, images de base épinglées sans variante, scripts qui téléchargent un binaire selon un nom d'architecture deviné, tests qui reposent sur un comportement de virgule flottante. Rien de dramatique pris isolément, mais c'est là que se consomme le temps d'une migration.

Kubernetes gère nativement l'hétérogénéité d'architecture. Le kubelet renseigne le label kubernetes.io/arch sur chaque nœud avec la valeur de runtime.GOARCH, ce qui donne amd64 ou arm64. C'est un label bien connu, documenté et stable : tout le reste s'appuie dessus.

La méthode qu'on applique pour une bascule progressive tient en quatre temps.

D'abord, on ajoute un pool de nœuds ARM à côté du pool existant, et on le taint immédiatement. Sans taint, le scheduler y enverra des pods dès la première pression de ressources, y compris des workloads dont personne n'a validé l'image multi-arch. Le nœud ARM doit être opt-in, pas opt-out.

Ensuite, on épingle explicitement les workloads déjà validés, via une tolération plus une affinité de nœud :

spec:
  tolerations:
    - key: arch
      operator: Equal
      value: arm64
      effect: NoSchedule
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: kubernetes.io/arch
                operator: In
                values: ['arm64']

Puis on bascule par vagues, en commençant par les charges sans état et sans dépendance native : services HTTP en Go, proxies, workers de file d'attente. On garde le stateful et les intégrations tierces pour la fin. Les contraintes de répartition topologique permettent d'étaler une même Deployment sur les deux architectures pendant la phase de transition, ce qui offre un repli immédiat si une régression apparaît.

Enfin, on retire les nœuds x86 seulement une fois les métriques stables sur plusieurs jours de trafic réel, pics inclus. Si le cluster provisionne ses nœuds dynamiquement, cette logique se déclare directement dans les contraintes de provisionnement automatique des nœuds, qui savent arbitrer entre familles d'instances et architectures selon le coût.

Un point souvent oublié : la supervision doit distinguer les deux architectures dès le premier jour. Un tableau de bord qui agrège latence et taux d'erreur toutes architectures confondues masquera précisément la régression qu'on cherche. On ventile par label d'architecture, sinon la comparaison ne veut rien dire, exactement comme pour toute campagne de mesure de performance sous Linux.

Une migration réussie, c'est aussi savoir ce qu'on ne migre pas.

Les applications legacy dont personne ne maîtrise plus la chaîne de build : le coût d'archéologie dépasse systématiquement l'économie d'instance. Les workloads dépendant de binaires propriétaires x86-only, tant que l'éditeur n'a pas bougé. Les charges dont le profil est déjà dominé par autre chose que le CPU : un service qui passe 90 % de son temps à attendre le stockage ou le réseau ne gagnera rien de mesurable en changeant d'architecture, quel que soit le rapport prix-performance affiché.

Et le cas le plus fréquent, le moins avouable : les petits clusters. Migrer trois nœuds représente quelques dizaines d'euros par mois d'économie, pour plusieurs jours-homme d'ingénierie et une dette de complexité permanente sur la chaîne CI. Le calcul ne tient qu'à partir d'un volume de compute significatif. Cet arbitrage entre gain unitaire et coût d'ingénierie est exactement le raisonnement à tenir sur toute démarche FinOps en production : l'économie théorique n'est pas l'économie nette.

ARM sur Kubernetes n'est plus un sujet de faisabilité, c'est un sujet de discipline de build. Les trois choses qui décident du résultat : un pipeline qui produit des images multi-arch sans passer par une émulation qui multiplie les temps de build, un inventaire exhaustif des DaemonSets et des dépendances natives réalisé avant d'allumer le premier nœud, et une bascule progressive avec taints, affinités et supervision ventilée par architecture. Le reste, c'est du benchmark honnête sur votre charge réelle plutôt que sur un communiqué de presse.

Quand un cluster de production doit accueillir des nœuds ARM sans interruption de service, le travail commence par l'audit de la chaîne d'images, l'inventaire des composants tiers et le plan de bascule par vagues, avec un repli testé à chaque étape. C'est ce qu'on fait sur les infrastructures qu'on opère. Si l'économie annoncée par votre fournisseur cloud vous tente mais que personne ne sait ce que la migration casse, on peut cadrer et conduire l'opération de bout en bout.

• Docker : Multi-platform builds : documentation officielle des trois stratégies de build multi-architecture, avec les limites de l'émulation QEMU.
• Docker : Faster multi-platform builds, cross-compilation guide : mesures comparatives entre build émulé et cross-compilation.
• Kubernetes : Well-Known Labels, Annotations and Taints : référence officielle du label kubernetes.io/arch et de sa valorisation par le kubelet.
• The Register : Amazon keeps the pressure on Intel, AMD with 192-core Graviton5 : chiffres du Graviton5 et part de la nouvelle capacité CPU AWS servie par ARM.
• AWS : Leveling up Amazon RDS with AWS Graviton4 benchmarks : mesures de débit entre générations Graviton sur charge base de données.
• Google Cloud : Migrate an x86 application on GKE to multi-arch with Arm : procédure de migration progressive vers des pools de nœuds ARM.
• Phoronix : AmpereOne A192-32X benchmarks : campagne de mesures indépendante sur serveur ARM 192 cœurs face aux EPYC et Xeon.