Kubernetes

Kubernetes fait tourner des applications en conteneurs sur un ensemble de machines : il décide où chaque service s'exécute, le redémarre s'il tombe, ajoute des instances quand la charge monte, et remplace les anciennes versions par les nouvelles sans coupure. C'est devenu le standard de fait de l'industrie, et c'est aussi l'outil le plus souvent adopté pour de mauvaises raisons — parce qu'il est sur toutes les offres d'emploi, pas parce que le projet le demandait.

• →Docker et composition de conteneursLe même bénéfice de reproductibilité, sans orchestrateur à exploiter : le bon niveau pour la plupart des projetsVoir la page
• →Plateformes d'hébergement applicatifQuand l'objectif est de ne pas exploiter d'infrastructure du toutVoir la page
• →NomadOrchestration nettement plus simple à exploiter, quand il faut vraiment ordonnancer sur plusieurs machines
• →TerraformPour décrire et rejouer l'infrastructure sous-jacente, cluster ou pasVoir la page

1. 01

   Poser la question du besoin avant celle de la mise en œuvre, et accepter que la réponse soit non

2. 02

   Cluster managé chez un fournisseur plutôt qu'auto-géré : la maintenance du plan de contrôle n'apporte aucune valeur métier

3. 03

   Une seule façon de déployer, décrite dans le dépôt, plutôt que des commandes tapées à la main

4. 04

   État persistant hors du cluster autant que possible : base managée et stockage objet

5. 05

   Limites de ressources et sondes de disponibilité dès le premier service, pas après le premier incident

• À partir de quand Kubernetes devient-il justifié ?

  Quand plusieurs équipes déploient indépendamment plusieurs services, quand la charge varie assez pour que l'élasticité change la facture, ou quand le même socle doit être rejoué à l'identique dans plusieurs environnements. En dessous, le rapport entre ce qu'il apporte et ce qu'il demande à exploiter joue contre vous. Le seuil n'est pas une taille d'entreprise, c'est un nombre de services déployés séparément.
• Docker suffit-il à la place ?

  Pour beaucoup de projets, oui. Les conteneurs règlent le problème principal — l'application tourne à l'identique partout — et un fichier de composition sur une ou deux machines couvre un besoin courant. Kubernetes règle un autre problème : faire tourner beaucoup de conteneurs sur beaucoup de machines sans intervention humaine. Si vous n'avez pas ce second problème, vous n'avez pas besoin de sa solution.
• Qu'est-ce que ça coûte à faire tourner ?

  Deux postes distincts. L'infrastructure : les machines du cluster, auxquelles s'ajoute parfois un forfait mensuel pour le plan de contrôle managé, et qui restent facturées même à charge nulle. Et l'exploitation : les montées de version du cluster reviennent plusieurs fois par an et ne sont pas optionnelles. C'est ce second poste, invisible au moment du choix, qui décide vraiment de la note.
• Combien coûte une migration vers Kubernetes ?

  Ce qui commande, c'est le nombre de services à porter, leur état de conteneurisation, la gestion de l'état persistant, le nombre d'environnements et la reprise de la chaîne de déploiement. Mais avant de chiffrer une migration, je préfère chiffrer l'alternative : dans la moitié des cas, elle répond au même besoin pour bien moins cher. Le montant se fixe au devis, après un cadrage initial gratuit qui écrit le périmètre avant tout engagement.
• Un cluster managé enlève-t-il la complexité ?

  Il enlève la partie la plus ingrate — tenir le plan de contrôle disponible — et c'est une raison suffisante de le préférer à l'auto-géré. Il n'enlève ni le réseau, ni le stockage persistant, ni les droits, ni les montées de version des composants que vous avez installés dedans. C'est-à-dire la majeure partie de ce qui fait la difficulté au quotidien.