Kubernetes répond, entre autres, aux besoins cités dans la première partie de cet série de posts. En tant qu’orchestrateur, Kubernetes offre la possibilité d’automatiser le déploiement et la mise à l’échelle des conteneurs, et ce même sur plusieurs hôtes. Kubernetes apporte d’autres fonctionnalités et avantages, comme la sécurité, avec par exemple la vérification de l’intégrité des applications.

Un cluster Kubernetes est composé de Master, de Nodes et de Pods :

Le master est l’entité qui est en charge du contrôle du cluster. Lorsqu’un administrateur interagit avec le cluster Kubernetes, il communique avec le master.

• Un node est une machine hôte qui peut être une machine virtuelle, ou une machine physique. Un node peut héberger plusieurs pods. C’est aussi dans un node que se trouve le master, et il est recommandé d’utiliser un node dédié pour le master. A noter qu’il est possible d’avoir plusieurs masters, chacun étant hébergé dans un node dédié. Cette configuration de haute disponibilité est recommandée dans un contexte de production.
• Un pod est une unité du cluster vue comme un process. Un pod héberge un ou plusieurs conteneurs, des ressources de stockage, et détient une IP unique.

Pour que le cluster soit fonctionnel, plusieurs composants doivent être installés au sein des nodes et du master. La figure ci-dessous montre ces différents composants :

Master components :

• kube-apiserver est le ‘’front-end’’ du control plane. Le control plane, ou plan de contrôle, est la partie intelligente du cluster. C’est le control plane qui fait en sorte que le cluster soit dans l’état définit par l’administrateur à travers les fichiers de configuration. Par exemple, en actionnant la création de nouveaux pods pour remplacer ceux qui sont défaillants. Tous les composants du cluster communiquent entre eux via cette api.
• etcd stocke les données relatives au cluster.
• kube-scheduler vérifie s’il y a des pods en attente et choisit le node dans lequel le pod sera placé. Le choix tient compte de différentes contraintes (hardware, politique de sécurité etc…).
• kube-controller-manager est le composant qui fait en sorte que les controllers fonctionnent correctement. Il y a plusieurs controllers qui sont :
• Node Controller
• Replication controller
• Endpoints controller
• Service account & Token controllers

Node components :

• kubelet est un agent actif sur tous les nœuds, qui s’assure notamment que chaque conteneur est bien actif au sein d’un pod. Kubeletcommunique avec le Container Runtime, qui sera Docker dans notre exemple.
• kube-proxy se charge d’apporter les modifications nécessaires sur le node pour maintenir la couche d’abstraction réseau. kube-proxy agira par exemple sur les iptables des machines linux. Pour ceux qui veulent en savoir plus, cet article en trois parties permet de comprendre comment la partie réseau est gérée avec Kubernetes.

Kubectl est l’interface de ligne de commande de Kubernetes. Ce n’est pas un composant du cluster. Kubectl communique avec le cluster via kube-apiserver.

D’autre composants peuvent être ajoutés mais restent optionnels. Par exemple, le composant dashboard fournit une interface web à partir de laquelle on peut voir l’état du cluster. Kube-dns est aussi très utilisé et permet d’offrir un service DNS aux pods. Il en existe même des plus spécialisés, comme l’addon ACI qui permet d’intégrer Kubernetes à une fabrik Cisco ACI.