Il y a quelques semaines, j’ai eu l’occasion de réaliser un audit d’infrastructure Nutanix chez un client. À première vue, rien d’inquiétant : l’environnement était bien tenu, les points relevés restaient mineurs. Bref, un contexte assez classique.
Mais en creusant un peu plus, un détail a retenu mon attention : le plan d’adressage interne du Cluster Management Services Platform (CMSP).
Le CMSP, c’est l’infrastructure de microservices déployée avec Prism Central. Il repose sur un plan d’adressage réseau réservé, indispensable au fonctionnement interne des services. Ces sous-réseaux sont invisibles de l’extérieur, mais leur stabilité conditionne toute la plateforme.
Par défaut, Nutanix réserve :
- 10.100.0.0/16 pour le réseau pod Kubernetes
- 10.200.32.0/24 pour le réseau services Kubernetes
- 192.168.5.0/24 pour le réseau infrastructure Kubernetes
Avec l’audit, je me suis aperçu qu’un ces sous-réseaux est déjà utilisé côté client ce qui n’est pas une bonne pratique comme indiqué dans la documentation : https://portal.nutanix.com/page/documents/details?targetId=Prism-Central-Guide-vpc_7_3:mul-cmsp-req-and-limitations-pc-r.html
Do not use the IP addresses in the subnet 10.200.32.0/24 for operational purposes such as DNS or CVM networks. This prevents any negative impact and maintain seamless operations in the networking.
les ennuis arrivent vite : déploiement ou mise à jour qui échoue, microservices qui ne démarrent pas, comportements imprévisibles.
Bonne nouvelle : lors du déploiement, on peut personnaliser ces sous-réseaux. Et même après coup, mais la procédure doit etre réalisé par le support, ou un consultant qualifié. Mieux vaut anticiper, mais il existe donc une porte de sortie en cas de conflit découvert trop tard. https://portal.nutanix.com/kbs/15379
Dans ce cas précis, l’un des réseaux internes du client chevauchait un des sous-réseaux réservés par Nutanix. Le problème n’avait pas encore bloqué l’exploitation, mais il s’annonçait critique pour les prochaines évolutions. Et justement, le client avait déjà un ticket ouvert au support pour un souci de sauvegarde qui pourtant semblait ne pas etre lié.
Cas client : quand un conflit d’IP se déguise en problème d’authentification
Un proxy de sauvegarde voyait ses tâches échouer systématiquement au bout de 15 minutes. Seul moyen de repartir : redémarrer la VM du proxy.
Les logs Prism Central montraient des erreurs HTTP 403 et des tokens OIDC invalides. Tout laissait penser à un bug d’authentification.
La vraie cause était ailleurs : l’IP du proxy appartenait à la plage 10.100.0.0/16, réservée au CMSP. Prism Central traitait donc ses appels API comme internes, ce qui perturbait totalement le mécanisme d’authentification et cassait le renouvellement des tokens.
La résolution a été immédiate : ici on a pu réattribuer une nouvelle IP au proxy, en dehors des plages réservées . Dès ce changement appliqué, les sauvegardes sont redevenues stables.
À retenir : des symptômes applicatifs compliqués (erreurs API, tokens, authentification) peuvent avoir une cause très simple : un conflit d’adressage. Avant de déployer ou d’intégrer un service tiers avec Nutanix, toujours vérifier que les sous-réseaux réservés par la plateforme ne sont pas déjà utilisés. Cette vérification prend cinq minutes et peut éviter des heures d’investigations inutiles.