Kubernetes… Un mot derrière lequel se cache en fait la réponse à un besoin assez simple : Comment déployer des applications sans me soucier de l’infrastructure systèmes et réseaux sous-jacente ?
Aujourd’hui un des plus importants buzzword dans les CV dans l’informatique, kubernetes est un projet initié par google.
Disclaimer : je tiens à préciser qu’il s’agit d’un article de vulgarisation. Je ferai donc des raccourcis pour faciliter la compréhension, tout en essayant d’être le plus proche de la réalité possible. Je vous invite à lire d’autres articles, bien plus pointus techniquement, si vous désirez devenir expert de cet outil.
Mais c’est quoi ce truc dont tout le monde parle ?
Quand on dit que c’est un buzzword, c’est vrai. Mais ce n’est pas qu’un effet de mode. L’outil a été conçu pour simplifier la gestion d’un Système d’information.
Rien que ça.
En gros, prenez la plus grosse partie de ce que vous avez acquis en expérience dans la gestion de parcs de serveurs informatique, et jetez-le à la poubelle.
On va faire autre chose
Pour autant, kubernetes n’est, ni la seule solution disponible, ni la solution à tout. Swarm ou mesos peuvent apporter des solutions comparables à kubernetes. Mais quand le projet a Google derrière, et bien il part avec de bonnes chances de réussir à passer premier. (mesos est sous license apache, et swarm vient de chez docker)
C’est autant un concept, qu’un outil
Ainsi donc, Nous avons besoin d’éclaircir quelques concepts. Kubernetes a pour prérequis l’utilisation de conteneurs. Il en existe plusieurs types, mais nous nous concentrerons sur la solution la plus répandue : Docker
Je parle plus en détail de docker dans mon article qui traite du sujet et dans celui qui traite de la virtualisation. Je vous invite à les lire pour comprendre la suite.
Comme Mesos, qui se clame être un OS (un système d’exploitation) de datacenter, Kubernetes a pour vocation de cacher les machines du point de vue des utilisateurs et des applications, les agrégeant en grappes et en centralisant la gestion et le déploiement des applications.
Conceptuellement, ça ressemble à ça avec les applications en vert
Sur le principe, je jette mon application dedans, et kubernetes se charge de lui trouver une place, ou des places (selon le besoin en nombre d’instances) et crée un chemin me permettant de la contacter.
Pour ce faire, Kubernetes est basé sur un système de master et de slaves. Les masters organisent, les slaves exécutent les commandes.
Les masters sont répartis sur 1,3, 5 ou 7 machines (un nombre impair, pour leur permettre d’élire un leader qui centralisera les ordres).
Les slaves sont en nombre variable, et sont quand à eux les machines sur lesquelles tournent nos applications.
Le slave, avec l’appli de commande, et les conteneurs docker
Les slaves remontent au master leurs ressources disponibles et le master gère l’ensemble des ressources des slaves. Lorsque l’on désire démarrer un conteneur docker sur le cluster, on adresse la config (sous forme de fichier de conf yaml, la plupart du temps, et via la commande kubectl) au master, qui ordonne à un de ses slave de démarrer ce conteneur. Ce conteneur est associé au réseau virtuel qu’offre kubernetes entre ses instances.
Le groupe des masters, en jaune, et les slaves gravitant autour
Via ce réseau virtuel, les différentes applications conteneurisées peuvent discuter entre elles et vers l’extérieur du cluster kubernetes. Un jeu de règles particulières, appelé ingress permet à l’extérieur de joindre certaines de ces applications via des load-balancers offrant un portail d’accès sécurisé.
Sans règles spécifiques, les applications ne sont pas visibles à l’extérieur de kubernetes. C’est même un choix. Nombreuses sont les applications qui ne quitteront jamais le cluster, celui-ci se comportant comme un vrai système d’information en interne. On y retrouve en effet réseau, applications, ports, load-balancers.
Du coup, c’est génial, on commence quand ?
Au risque de vous surprendre, il ne faut pas en mettre partout.
Kubernetes est basé sur le concept de conteneur. Qui dit conteneur, dit que votre application est stateless. En deux mots, celà signifie que la partie applicative ne doit garder aucune information. Chaque redémarrage lui fait perdre les données accumulées, non stockées à l’extérieur du conteneur (dans une base de données par exemple). Le système de fichier du conteneur est ephémère.
A quoi bon me direz-vous ? Ça aide à la scalabilité, la mise à l’échelle. On supprime les accroches de l’application pour la rendre facilement transportable et duplicable.
Alors bien sûr, il existe des moyens de faire rentrer au chaussepied nos applications stateful (l’inverse de stateless, donc) dans kubernetes. Mais je ne les conseillerai pas. Il est plus habile de ne pas forcer les outils à s’adapter à nos besoins, mais plutôt de trouver un outil qui correspond à ce que l’on attend. Dans ce cadre, il est assez exclus de mettre des bases de données dans kubernetes. Pour ce faire, je vous conseillerais mesos, via la distribution DC/OS, qui est taillé pour le stateful, ou n’importe quel solution autre que le Kube.
Si vous voulez à tout pris en faire, vous pouvez ignorer ces recommandations, mais sachez que ce ne sera pas sans impact sur les performances, ou l’agilité de votre infrastructure.
Comment l’essayer ?
Avec un prototype.
Le mieux pour se lancer, c’est d’utiliser minikube. Les tutos pour l’installer sont légion sur le net, et la solution kubernetes à un seul noeud (server) que minikube représente vous permettra de comprendre simplement si vos applications sont mures pour franchir le pas. La doc de minikube, en français, est ici.
Si vous êtes familier de docker, tout celà devrait se passer sans encombre. Si ce n’est pas le cas, je vous invite à le devenir, tellement celà devient un standard. Vous pouvez également jeter un oeil à mon article sur docker.