Le service de télémétrie d'OpenAI surcharge les serveurs API Kubernetes

OpenAI a déployé un service de télémétrie à 15h12 PST le 11 décembre 2024. Le déploiement a surchargé les serveurs API Kubernetes dans les grands clusters, faisant s’effondrer la découverte de service DNS.

Le service de télémétrie a configuré chaque nœud dans des clusters de milliers pour émettre des appels API coûteux. Ces appels ont saturé les serveurs API Kubernetes, cassant le cache DNS que les pods utilisent pour se localiser.

Déploiement de la télémétrie déclenche une saturation de l’API

Le nouveau service a collecté des métriques détaillées du plan de contrôle. En production, chaque nœud a exécuté des opérations de liste intensives qui ont évolué avec la taille du cluster. Lorsque des milliers de nœuds ont effectué ces opérations simultanément, les serveurs API sont devenus débordés.

La surcharge s’est manifestée par une saturation du serveur API. Les serveurs API ont cessé de fonctionner correctement et le mécanisme de découverte de service basé sur DNS a échoué.

Effondrement du plan de contrôle

Les vérifications de pré-déploiement d’OpenAI ont mesuré l’utilisation du processeur et de la mémoire par cluster, mais ont manqué l’évaluation de la charge du serveur API. Le service de télémétrie a augmenté la charge sur les serveurs API via les demandes d’authentification et d’autorisation générées par kubelet sur chaque nœud.

La montée en flèche du trafic d’auth a tendu le serveur API tandis que d’autres composants continuaient à fonctionner. Les conteneurs ne se sont pas redémarrés, mais la perte de DNS a signifié que les services ne pouvaient plus résoudre les noms les uns des autres.

Contexte industriel plus large

L’incident d’OpenAI met en évidence un défi courant dans l’industrie : équilibrer la nécessité d’une surveillance et d’une télémétrie détaillées avec l’impact potentiel sur les performances du système. Alors que l’adoption de Kubernetes continue de croître, les entreprises cherchent de plus en plus à optimiser leurs clusters pour des déploiements à grande échelle. L’expérience d’OpenAI rappelle l’importance d’une évaluation approfondie de la charge et des tests avant de déployer de nouveaux services.

Histoire d’incidents similaires

Ce n’est pas la première fois qu’une entreprise connaît une panne due à un service de télémétrie ou de surveillance. Dans le passé, des incidents similaires se sont produits dans d’autres organisations, souvent en raison de tests inadéquats ou d’un manque de visibilité dans les performances du système.

Mécaniques techniques

La configuration du service de télémétrie a causé à chaque nœud de chaque cluster d’exécuter des opérations de liste intensives. Cela a entraîné un grand nombre d’appels API aux serveurs API Kubernetes, entraînant une saturation et une panne éventuelle.

Stratégies d’atténuation et leçons

Une analyse approfondie soulève trois questions clés :

1. Comment la charge pourrait-elle être mieux évaluée avant le déploiement ?
2. Quelles sont les implications pour la vérification avec le trafic de production ?
3. Comment la surveillance peut-elle afficher l’état de santé du plan de contrôle ?

Les stratégies d’atténuation comprennent la récupération de métriques à partir d’un agrégateur central au lieu que chaque nœud émette des appels API, ou la limitation de la vitesse de demande en fonction de la taille du cluster. Il est également essentiel de renforcer les vérifications de l’état de santé du cluster pour la latence du serveur API et le volume de demandes.

Conclusion

L’incident met en évidence la nécessité de tests de charge qui simulent la taille de cluster attendue la plus grande. La surveillance doit inclure des métriques qui affichent l’état de santé du plan de contrôle.