OpenAI : un nouveau service de télémétrie sature Kubernetes et coupe ChatGPT pendant plus de quatre heures
2024-12-11 · Éditeur : OpenAI · Domaine : Cloud & DevOps
Le 11 décembre 2024, le déploiement d'un service de télémétrie surcharge les serveurs d'API Kubernetes d'OpenAI et casse la découverte de services par DNS. ChatGPT, l'API et Sora sont dégradés pendant 4 h 22.
Ce qui change
- Un service de télémétrie nouvellement déployé a saturé les serveurs d'API Kubernetes.
- La découverte de services par DNS a cessé ; ChatGPT, l'API et Sora ont été dégradés pendant 4 h 22.
- Les tests en clusters plus petits n'ont pas détecté ce défaut dépendant de l'échelle.
- OpenAI promet des déploiements progressifs et un accès d'urgence au plan de contrôle.
### Ce qui change Le 11 décembre 2024, entre 15 h 16 et 19 h 38 (heure du Pacifique), ChatGPT, l'API et Sora d'OpenAI sont indisponibles ou dégradés. Le post-mortem de l'entreprise donne la cause : un **service de télémétrie** fraîchement déployé a généré une charge inattendue sur les **serveurs d'API Kubernetes** de grands clusters. Chaque nœud d'un cluster exécutait des opérations d'API coûteuses, dont le coût croît avec la taille du cluster. Le plan de contrôle a été submergé, et la découverte de services par DNS a cessé de fonctionner. ### Caractéristiques - Durée de dégradation significative : 4 h 22. Retour à la normale pour ChatGPT à 19 h 01, pour l'API à 19 h 38, pour Sora à 19 h 01. - Les tests dans des clusters de préproduction plus petits n'ont pas révélé ce défaut dépendant de l'échelle. - La mise en cache DNS a retardé la visibilité du problème, ce qui a permis au déploiement de se poursuivre sur toute la flotte. - Une fois le plan de contrôle saturé, l'accès à celui-ci pour réparer est devenu impossible. - Mesures : déploiements progressifs avec supervision, tests d'injection de pannes, accès d'urgence aux serveurs d'API, découplage du plan de données et du plan de contrôle. ### Pourquoi c'est important Le cas illustre un piège classique : l'outil d'observabilité lui-même peut être la cause de la panne. Pour les équipes plateforme, il impose de tester les déploiements d'agents à l'échelle réelle, de limiter leur rayon d'action, et de garder un accès de secours au plan de contrôle Kubernetes qui ne dépende pas du DNS du cluster. ### À retenir Un agent de supervision déployé trop vite a mis hors service le plan de contrôle qu'il devait surveiller.
Liens
Tags : Incident, Kubernetes, Observabilité, DevOps