C’est un orchestrateur de conteneur basé sur un principe essentiel : faire en sorte de toujours faire correspondre l’état d’un parc de conteneur à un référentiel qu’on lui aura construit et qu’on peut manipuler.
Pour arriver à cet objectif, Kubernetes travaille avec un élément unitaire : le pod.
Un pod c’est un ou plusieurs conteneurs qui nécessitent un niveau de redondance identique. C’est important, car pour Kubernetes, il est impossible de travailler directement avec un conteneur, vous êtes obligé d’exploiter le concept de pod, même si vous n’avez qu’un conteneur.
La raison : dans kubernetes on résonne par bloc applicatif ou micro service. Dans cette logique il est souvent nécessaire d’associer plusieurs conteneurs pour couvrir une fonction. On parle parfois d’architecture « side car » : vous avec un conteneur principal chargé d’exécuter la fonction primaire et un conteneur « de support » en charge d’un rôle secondaire, mais essentiel comme la remontée des logs, la supervision, le cache….
Toutes les règles de réplications et de monter/descente de versions s’appliquent donc à un pod. En gros vous décrivez dans un fichier combien vous voulez de pods regroupant un ou plusieurs conteneurs et dans quelles versions. Kubernetes va alors chercher en permanence à satisfaire à vos exigences…si un pod manque à l’appel ou que sa version doit changer, Kubernetes s’en occupe…
Dès lors vous pourrez appliquer des « services ». Ces autres ressources Kubernetes sont chargées de permettre de dialoguer avec le reste de votre infrastructure. Ils offrent des fonctionnalités de load balancing entre vos pods.
Kubernetes est déployé sous forme de cluster. Vous retrouvez un ou plusieurs maitres (un serveur) qui proposent un accès à l’API et à qui vous soumettez tous vos paramètres, et des nodes (d'autres serveurs) qui exécutent les pods.
Un autre élément important de Kubernetes : les tags ! Oubliez les noms de serveurs et les nomenclatures compliquées. À un instant donné, vous n’avez pas à savoir que votre pod X s’exécute sur le serveur Y mais que la version 5 de la fonction d’authentification « AUTH » de votre application «APP » dispose d’un nombre minimal de 10 pods pour assurer la charge. Vous jouerez donc dans vos fichiers Kubernetes avec les tags APP, AUTH et 5…Kubernetes se charge du reste !
C’est un point important : en cas d’incident sur un nœud (donc un serveur), le but n’est plus de comprendre pourquoi, mais de rendre la panne invisible pour vos utilisateurs et de rétablir au plus vite le niveau de disponibilité souhaité… le reste on verra plus tard
Ces logiques de fonctionnement sont celles de…Google, car Kubernetes est un dérivé open source de l’orchestrateur de conteneur maison du géant du web. Ce n’est pas une simple ouverture du code source, c’est un produit entièrement reconstruit à partir de l’expérience de Google pour fournir un outil utilisable par la communauté. Pourquoi Google a fait cela… parce qu’il a bien vu que le besoin était là… et que si on adopte sa logique on aura d’autant plus de facilité à exploiter ses services cloud…
Kubernetes n’est pas simple, en particulier la maintenance du cluster et le suivi des versions. Mais ne vous occupez pas de ça, tous les grands providers du cloud public proposent leur service managé de cluster Kubernetes ! Même vmware à intégrer le moteur kubernetes dans sa mouture 7 de sa suite de virtualisation « vSphere »
À noter également qu’à fur à mesure des évolutions de kubernetes, le produit semble renforcer sa logique « core » / « plugin ». En effet qu’il s’agisse du moteur de conteneurs, la gestion du réseau, la gestion du stockage et autres, Kubernetes propose une normalisation de ses interfaces permettant à des plugin tiers de s’occuper de genre de problématique, le « core » de kubernetes restant l’orchestration des conteneurs.
Le résultat : Google a réussi son coup ! Kubernetes est devenu un vrai standard et a supplanté toutes les solutions concurrentes. L’avantage c’est d’avoir une des seules solutions cross cloud ! Vous pouvez relativement facilement transférer la gestion et l’exécution de vos conteneurs d’un service managé à un autre (incluant votre propre infra), Kubernetes restant le dénominateur commun.
Maintenant, attention :
- Kubernetes n’est pas un moteur de conteneur, il s’appuie sur des solutions existantes comme la plupart du temps Docker (mais pas que…)
- Sans maitrise de la technologie des conteneurs, inutile de faire du Kubernetes
- Kubernetes a été pensé dans une logique « applicative » et non « infrastructure ». Tout est fait pour suivre le cycle de vie des applications depuis leur mise en production, leur mise à jour, mais aussi les tests ou rollback éventuels.
- Kubernetes obéit à une logique « déclarative » : on dit ce qu’on veut, mais pas comment le faire (à l’inverse de la logique « imperative » ou on l’on explique comment faire ce qu’on veut)
Kubernetes est de toute évidence un formidable produit qui évolue très (très) vite. Il va sans doute être adopté par de plus en plus de monde… mais votre IT en a-t-il besoin ? Il y’a souvent bien d’autres choses à faire avant de se précipiter sur Kubernetes…surtout quand on n’a aucun conteneur dans son parc…