AKS retire Azure NPM des nœuds Windows le 30 septembre, et la voie Cilium s’arrête au seuil Linux
Le 30 septembre 2026, Azure Kubernetes Service cesse de prendre en charge Azure Network Policy Manager sur les nœuds Windows. Or la migration recommandée vers Cilium Network Policy reste réservée à Linux : recensez vos pools Windows et choisissez entre NSG de nœud, Calico auto-géré ou migration Linux avant l’échéance.
30 septembre 2026. Azure Kubernetes Service cesse de prendre en charge Azure Network Policy Manager (NPM) sur les nœuds Windows. 18 juillet 2026. Microsoft publiait l’annonce de retrait et fermait déjà le nouvel onboarding. Septembre 2026. Le guide de migration officiel NPM → Cilium précise qu’il ne s’applique qu’aux clusters Linux. Pourquoi c’est important : la voie de migration recommandée s’arrête exactement là où les organisations Windows en ont le plus besoin, à une semaine de l’échéance.
Un retrait dont la porte de sortie est verrouillée pour Windows
La mécanique du retrait est simple : Azure NPM disparaît des nœuds Windows d’AKS le 30 septembre 2026. Les déploiements déjà embarqués peuvent continuer à l’utiliser jusqu’à cette date, mais le nouvel onboarding n’est plus possible. La suite logique, côté Microsoft, est de migrer vers Cilium Network Policy, porté par Azure CNI Powered by Cilium.
Sauf que ce chemin bute sur une frontière technique. Azure CNI Powered by Cilium et Cilium Network Policy restent réservés à Linux dans AKS. Microsoft l’écrit noir sur blanc : Cilium Network Policy n’est pas pris en charge pour les nœuds Windows, et AKS ne peut pas faire basculer un cluster contenant des pools Windows vers le plan de données Cilium.
La conséquence est architecturale, pas cosmétique. Un cluster mixte dont le pool système est en Linux ne peut pas être migré vers Cilium tant qu’un pool Windows existe. L’équipe qui pensait « migrer le cluster » découvre que le blocage s’applique au cluster entier, pas seulement aux politiques qui sélectionnent des pods Windows.
Pourquoi Cilium ne remplace pas NPM sur Windows
La raison est dans la façon dont chaque système applique la politique réseau. Sur Linux, Azure NPM s’appuie sur iptables ; Cilium remplace cette couche par un plan de données eBPF propre à Linux. Sur Windows, l’application de la politique passe par les ACL du Host Network Service (HNS), un chemin totalement différent.
Cilium n’est pas une implémentation interchangeable de ce chemin HNS. Son plan de données AKS est construit autour des capacités de Linux ; il ne peut pas « traduire » les règles vers les ACL HNS des nœuds Windows. Le retrait de NPM ne laisse donc pas de successeur managé équivalent pour Windows — c’est un retrait, pas un simple remplacement d’agent.
La stratégie eBPF derrière le retrait
Le retrait de Azure NPM n’est pas un accident de calendrier : il s’inscrit dans la bascule assumée d’AKS vers un plan de données eBPF. Cilium, bâti sur eBPF, devient le chemin réseau stratégique de la plateforme, avec ses gains d’observabilité et de performance. NPM, construit sur iptables, est la couche héritée que Microsoft démonte progressivement.
Le problème n’est pas la direction, c’est l’asymétrie de la transition. Les charges Linux reçoivent un successeur managé, documenté et testé. Les charges Windows, elles, sont renvoyées vers des NSG de nœud ou un Calico auto-géré — deux options qui transfèrent à l’équipe une part de responsabilité que NPM absorbait. Et le 30 septembre n’est pas une date isolée : c’est le même jour que tombent d’autres retraits Azure (notamment BlobFuse v1, Azure Functions v3 en consommation Linux et Azure Virtual Desktop Classic). Une équipe qui gère un parc hétérogène peut avoir plusieurs échéances simultanées à traiter le même jour — l’inventaire doit porter sur l’ensemble, pas seulement sur AKS.
Trois issues, aucune transparente
Pour les clusters Windows, il reste trois options, et aucune n’est une migration « drop-in ».
Les Network Security Groups de nœud. C’est l’alternative la plus « Azure-native » désignée par Microsoft. Un NSG filtre au niveau du sous-réseau ou de l’interface réseau, pas au niveau du pod. Il peut suffire quand les nœuds Windows sont déjà séparés par niveau de confiance ou par application. Mais si plusieurs tenants ou plusieurs niveaux sensibles partagent les mêmes nœuds, remplacer une politique de pod par un filtrage de nœud élargit la zone de confiance — le NSG paraît restrictif alors qu’il protège moins finement. Choisir les NSG, c’est aussi redessiner le placement des charges en pools dédiés pour retrouver les frontières perdues.
Project Calico auto-géré. C’est l’autre direction nommée par Microsoft. Calico préserve le modèle de politique de pod — plus proche de ce que les utilisateurs de NPM connaissent — mais le mot-clé est « open source » : l’organisation hérite du déploiement, des mises à niveau, de la supervision et du support du composant. Il faut une réponse claire à « qui répond quand la politique se comporte différemment après une mise à jour de nœud ou de Kubernetes ». Calico est le bon choix quand la segmentation pod à pod est non négociable et que l’équipe a l’expertise réseau pour l’opérer ; c’est un mauvais choix pour qui avait adopté AKS justement pour minimiser cette responsabilité.
Repenser la charge. Dernière issue, souvent la moins chère à long terme : éliminer la dépendance aux nœuds Windows — migrer vers Linux, une autre plateforme ou une architecture séparée — avant l’échéance. Pour une charge « legacy » maintenue par inertie, le coût de la réécriture peut être inférieur au coût récurrent d’un Calico auto-géré.
Ce qu’il faut faire avant le 30 septembre
L’échéance est dans une semaine : le diagnostic prime sur le choix d’outil.
Inventoriez. Recensez chaque cluster AKS contenant des pools Windows et vérifiez si Azure NPM y est activé. Sans inventaire, vous découvrirez le retrait le jour où une politique cessera d’être appliquée.
Cartographiez les frontières réelles. Identifiez quelles ressources NetworkPolicy sélectionnent des charges planifiées sur ces pools, et documentez la frontière de sécurité que chacune garantit — celles qui sont impératives, pas celles héritées d’un modèle standard. Un cluster avec des dizaines de politiques générées ne dépend parfois que de quelques règles d’isolation significatives.
Décidez dans l’ordre. Si la frontière de nœud suffit, partez sur des NSG et des pools dédiés. Si la segmentation pod à pod reste obligatoire, évaluez Calico et assignez-en le cycle de vie. Si ni l’un ni l’autre ne tient, lancez la migration vers Linux avant la date. Validez ensuite le choix en non-production, en testant le trafic autorisé et le trafic qui doit être bloqué.
Un cluster Windows qui dépasse l’échéance sans action ne « tombe » pas d’un coup : NPM peut continuer d’appliquer les règles encore quelque temps, mais sans correctif ni support. Le vrai risque est le même que pour tout composant retiré — une mise à jour de nœud ou de version Kubernetes qui casse le chemin d’application de la politique, et une équipe qui découvre la brèche en production. Le 30 septembre n’est pas le jour où tout s’arrête, c’est le jour où la responsabilité bascule entièrement de votre côté.
Verdict
Microsoft a retiré Azure NPM des nœuds Windows en désignant un successeur — Cilium — qui ne fonctionne pas sur Windows. Ce n’est pas une négligence, c’est un choix de stratégie : la plateforme pousse vers le plan de données eBPF et laisse les charges Windows assumer le coût de la transition. Si vous exploitez des pools Windows sous AKS, ne traitez pas ce retrait comme une simple mise à niveau d’agent : c’est une décision d’architecture. Inventoriez vos clusters, mesurez les frontières de sécurité réelles, puis choisissez entre NSG de nœud, Calico auto-géré ou migration Linux — avant le 30 septembre, pas après.