Kubernetes est un bon choix par défaut pour la plupart des plateformes web.
Il offre aux équipes un déploiement répétable, une isolation des ressources, une découverte de services, et un modèle opérationnel mature. Pour l'API typique, la flotte de travailleurs ou la plateforme interne, ces avantages l'emportent sur les frais généraux.
L'erreur consiste à faire de cela une règle universelle.
Il existe des charges de travail où les frais généraux d'orchestration, le réseau virtualisé et le comportement de voisin bruyant ne sont pas des erreurs d'arrondi. Ils constituent la charge de travail.
Ce que la plateforme ajoute
Kubernetes ne se contente pas d'exécuter votre processus. Il l'enveloppe dans un modèle d'exécution plus large :
- mise en réseau des conteneurs
- routage des services
- gestion des paquets via kube-proxy ou eBPF
- cgroups et planification du CPU
- réseaux superposés dans de nombreux environnements
Pour la plupart des applications, ces frais généraux sont acceptables.
Pour les systèmes qui se soucient de la latence de queue stricte, du rythme des paquets ou de l'interaction directe avec le NIC, ce ne sera peut-être pas le cas.
La véritable décision concerne le déterminisme
Le problème n'est généralement pas la latence moyenne. Il s'agit de la variance.
Certaines charges de travail se préoccupent beaucoup plus du jitter que du débit :
- traitement de paquets
- trading à faible latence
- ingestion de télémétrie spécialisée
- mise en réseau en espace utilisateur avec DPDK ou des approches similaires
Dans ces systèmes, les avantages du plan de contrôle Kubernetes peuvent être moins importants que :
- placement fixe du CPU
- moins de couches réseau
- moins de bruit dans le planificateur
- accès matériel plus prévisible
C'est là que des modèles de déploiement plus simples, des hôtes dédiés ou du matériel brut commencent à avoir du sens.
La plupart des équipes ne devraient pas lire cela comme "Quittez Kubernetes"
Pour les systèmes SaaS normaux, la conclusion opposée est généralement correcte.
Si le goulet d'étranglement de votre produit est la latence de base de données, des essais non bornés, un stockage d'objets lent, ou une logique applicative coûteuse, passer à autre chose que Kubernetes n'est probablement pas la solution.
Le seuil pour quitter la plateforme doit être élevé.
Une meilleure façon de l'évaluer
Avant de blâmer Kubernetes, vérifiez :
- Mesurez-vous la latence de queue, et pas seulement les moyennes ?
- Le goulet d'étranglement est-il lié au réseau, à la planification CPU, ou à tout autre chose ?
- L'affinité des nœuds, le pinning CPU, ou des nœuds dédiés résoudraient-ils une part suffisante du problème ?
- Utilisez-vous un modèle CNI et de routage qui correspond à la charge de travail ?
Parfois, la bonne réponse n'est pas "matériel brut au lieu de Kubernetes". C'est "un cluster plus petit et plus spécialisé avec des règles de placement plus strictes".
Quand le matériel brut devient raisonnable
Le matériel brut ou les hôtes dédiés deviennent plus défendables lorsque :
- la charge de travail est extrêmement sensible à la latence
- le processus nécessite un contrôle direct du matériel
- vous pouvez justifier le coût opérationnel
- l'équipe peut soutenir un modèle d'exécution plus sur mesure
C'est une tranche étroite de systèmes. C'est réel, mais étroit.
Kubernetes est un système d'orchestration, pas une promesse de déterminisme matériel parfait. Si la charge de travail nécessite ce dernier, soyez prêt à choisir une pile plus simple.
Lecture complémentaire