Kubernetes : les coûts opérationnels liés au fait de toucher chaque clou avec un marteau

plus gros mensonge du monde de la technologie de ces 5 à 6 dernières années est le suivant : « Mettez votre application sur Kubernetes et elle fera le reste. » Les personnes qui monteront sur scène lors des conférences vous expliqueront à quel point Kubernetes (K8s) est un outil d'orchestration exceptionnel qui est « autorégénérateur ». Mais personne ne vous parle du coût de l'armée d'ingénieurs nécessaire pour gérer cet orchestre.

La triste vérité, c'est que vous n'êtes pas Google. Vous n'avez probablement pas non plus les problèmes de mise à l'échelle de Google. Mais à cause du « FOMO » (peur d'être laissée pour compte) dans l'industrie, vous essayez de gérer ne serait-ce qu'un simple site web avec un système complexe de panneaux de commande de sous-marins nucléaires. Jetons un coup d'œil à cette facture invisible « YAML hell ».

1. Opérations du « Jour 2 » : Le rêve est terminé, la réalité commence

Mettre en place le cluster Kubernetes est la partie la plus facile (« Jour 1 »). Le cauchemar principal commence avec les opérations du « Jour 2 ». Maintenir le cluster à jour, gérer les rotations de certificats, les incompatibilités entre les versions et le plantage des nœuds

• Coût des ressources humaines : gérer K8s est un travail à plein temps en soi. Est-ce le travail de vos développeurs d'écrire du code ou de corriger pourquoi Ingress Controller n'achemine
pas le trafic ?
• Abstraction Leak : On dit que le matériel K8s est abstrait mais c'est un mensonge. Dès que vous ne définissez pas correctement les limites du processeur (« requêtes » et « limites »), votre application meurt en silence avec le message d'erreur « OomKilled » (Mémoire
insuffisante).
• Réseau : communication entre POD, Service Mesh, plugins CNI... Une simple requête HTTP peut soudainement se transformer en un problème d'ingénierie réseau insoluble

2. Développement piloté par CV

Quand j'entre dans une entreprise en tant qu'expert sceptique, la première chose que je regarde est la suivante : cette architecture a-t-elle été imposée par les exigences du poste ou est-ce le désir des ingénieurs d'inscrire « Kubernetes Expert » sur leur CV ?

Si votre application tient dans un seul serveur virtuel (VM) et que vous la divisez en un cluster K8s de 3 nœuds, vous ne résoudrez que

3. Vulnérabilités liées à la complexité

La complexité est l'ennemi numéro un de la sécurité. Les paramètres par défaut de Kubernetes sont généralement « orientés vers le travail », et non « sûrs ».

un conteneur Docker avec l'autorité root, contourner la gestion des secrets (cryptage Etcd) ou configurer des règles RBAC (Role-Based Access Control) incorrectement... Pour les hackers, K8s est un parc d'attractions s'il est mal configuré. Pour garantir la sécurité des K8, vous avez besoin d'outils supplémentaires (trivy, falco, etc.) et de temps supplémentaire pour les gérer.

4. Quand sort K8s, quand sort le PaaS ?

Alors, devons-nous abandonner Kubernetes ? Non. Trouvons simplement le bon clou.

• Microservice Hell : Si vous avez vraiment plus de 50 microservices à gérer et qu'ils communiquent intensément entre eux, le K8 est un sauveur.
• Applications monolithiques : Si vous avez une application monolithique, la dockeriser et l'exécuter sur un simple PaaS (Heroku, DigitalOcean App Platform, etc.) ou sur un service de conteneurs géré (AWS ECS) vous coûtera 80 % de charge opérationnelle en moins.