Développé à l’origine par Google, le gestionnaire de clusters de containers Kubernetes est la plus importante technologie de microservices modernes. Elle permet de simplifier et d’automatiser la gestion des clusters de microservices d'applications conteneurisées. Mais cette notion simple cache un monde de complexité. Cet article permet de mieux comprendre comment fonctionne cette technologie. Une façon utile d'envisager Kubernetes, c’est de le considérer comme un système d'exploitation distribué pour les conteneurs. Il fournit les outils et les commandes nécessaires pour orchestrer l'interaction et la mise à l'échelle des conteneurs (le plus souvent des conteneurs Docker) et de l'infrastructure sur laquelle ils fonctionnent. Outil général capable de fonctionner dans des scénarios très variés, Kubernetes est un système très flexible, mais aussi très complexe.

Comprendre l'architecture qui fait fonctionner Kubernetes.

Nœuds de travail et plan de contrôle de Kubernetes

Kubernetes comporte deux aspects : les nœuds de travail et le plan de contrôle. Les nœuds de travail désignent les endroits où se trouvent les applications conteneurisées physiques et les outils Kubernetes nécessaires. Le plan de contrôle désigne l'endroit où se trouvent les outils de gestion de ce cluster. La Figure 1 donne une vue d'ensemble de cette architecture.

 

Figure 1. Nœuds de travail et plan de contrôle de Kubernetes. (Crédit : IDG)

Comme on peut le voir sur la Figure 1, l'architecture est divisée entre les nœuds de travail et les nœuds de tête respectivement responsables de l'exécution des charges de travail et des outils de gestion. Dans les deux cas, les nœuds sont des machines, virtuelles ou physique, selon le cluster.

Mise à l'échelle des nœuds Kubernetes par rapport aux charges de travail

Il est important de préciser que Kubernetes est conscient de l'infrastructure sous-jacente, en particulier des ressources (calcul, mémoire, disque et réseau) disponibles en vue de leur utilisation pour l'exécution des charges de travail des nœuds de travail, mais il ne les contrôle pas directement. Kubernetes est responsable de la mise à l'échelle des charges de travail, mais un mécanisme d'ordre supérieur (comme la mise à l’échelle automatique du cloud public ou une intervention manuelle) est responsable de l'ajustement de la disponibilité des nœuds. Pour cela, il existe un contrôleur (voir plus loin) qui permet d’interagir avec des systèmes externes.

Composants du nœud de travail Kubernetes

La Figure 2 montre les principaux éléments d'un nœud de travail Kubernetes que nous allons examiner successivement.

 

Figure 2. Détail du nœud de travail Kubernetes. (Crédit : IDG)

Le kubelet

Un kubelet est un « petit » programme, un agent, qui s’exécute sur chaque nœud du cluster et s’assure que les conteneurs fonctionnent dans un pod. Il est responsable de la négociation entre le plan de contrôle et le nœud. Son objectif principal est d'appliquer les directives provenant du cluster du nœud principal sur les pods et d’envoyer un rapport sur l'état actuel des charges de travail.

Le kube-proxy

Le kube-proxy est proxy réseau responsable de l'application des règles du réseau sur le nœud et autorise le trafic vers et depuis le nœud. Le kube-proxy est distinct de l'ingress, qui gère l’accès externe aux services dans un cluster et définit les règles pour les routes réseau, généralement du trafic HTTP, vers le cluster.

Les pods

Les pods correspondent à l'unité de travail autonome sur le nœud. Ce sont les plus petites unités informatiques déployables pouvant être créées et gérées dans Kubernetes. Ils sont une abstraction qui enveloppe une ou plusieurs applications conteneurisées. Les pods permettent de regrouper et d'isoler logiquement les conteneurs qui s'exécutent ensemble, tout en autorisant la communication entre les pods sur la même machine. La relation entre les conteneurs et les pods est contrôlée par les descripteurs de déploiement Kubernetes.

Deployments et ReplicaSets

Un Deployment (Déploiement) fournit des mises à jour déclaratives pour les pods et ReplicaSets. Les pods sont généralement configurés et déployés dans le cadre d'un ReplicaSet. Un ReplicaSet définit les caractéristiques d'exécution souhaitées du pod, et fait en sorte que Kubernetes travaille pour maintenir cet état. Les ReplicaSets sont généralement définis par un Deployment (Déploiement), lequel définit à la fois les paramètres du ReplicaSet et la stratégie à utiliser (c'est-à-dire si les pods sont mis à jour ou recréés) lors de la gestion du cluster.

Conteneurs Sidecar

Au niveau des pods, des fonctionnalités supplémentaires sont activées via des add-ons appelés Sidecars. Les Sidecars gèrent des tâches comme la journalisation au niveau du pod et la collecte de statistiques. La Figure 3 donne un aperçu plus détaillé des pods dans un nœud de travail.

 

Figure 3. Détail d'un pod Kubernetes. (Crédit : IDG)

Plan de contrôle Kubernetes

Jusqu'à présent, nous nous sommes concentrés sur la compréhension de l'aspect « travail ». Passons maintenant à l'aspect « contrôle ». La question cette fois est de comprendre comment opère Kubernetes pour contrôler le fonctionnement du cluster. La Figure 4 offre un aperçu détaillé des composants du nœud de tête.

 

Figure 4. Détail du nœud de tête Kubernetes. (Crédit : IDG)

Etcd

L’etcd (prononcer « et-c-d ») est le composant le plus simple à comprendre. Il s’agit d’un magasin d'objets distribué qui agit comme base de données d'enregistrement pour la configuration et l'état de l'ensemble du cluster. Ou encore, c’est une base de données clé-valeur consistante et hautement disponible utilisée comme mémoire de sauvegarde pour toutes les données du cluster, comme l’indique le site de Kubernetes.

Le serveur API

Comme le montre clairement la Figure 4, le serveur API est le mécanisme de communication central du cluster. Il sert de courtier pour l'interaction entre le plan de contrôle, les nœuds de travail et les administrateurs lorsqu'ils appliquent des changements de configuration via les outils de ligne de commande Kubernetes (comme kubectl) ou une autre interface utilisateur.

Le planificateur

Le planificateur est responsable de l'identification du nœud sur lequel les pods seront exécutés. Les détails de cette détermination varient en fonction des caractéristiques des pods et de l'état existant des nœuds disponibles. La stratégie de prise de décision du planificateur peut être adaptée, y compris en écrivant des planificateurs personnalisés. Le planificateur interagit avec le serveur API pour effectuer son travail.

Le contrôleur

Le composant contrôleur est responsable du maintien du cluster dans l'état souhaité tel qu'il est configuré, et de le faire évoluer vers cet état lorsqu'il s'en éloigne. Le contrôleur agit comme une sorte de thermostat qui spécifie un état désiré et fait en sorte de le maintenir. Dans la terminologie Kubernetes, on crée un objet qui est une entité persistante enregistrée dans etcd. L'objet sert de référence de l’état souhaité. Le contrôleur agit ensuite pour s'assurer que l'objet possède les spécifications, ou propriétés, souhaitées. Par exemple, un ReplicaSet (voir ci-dessus) définit le nombre de pods à exécuter en fonction de critères d'utilisation. Le ReplicaSet est l'objet, et le nombre de pods spécifié est la spécification. L'état réel du cluster par rapport à ce ReplicaSet est le statut. Le contrôleur reçoit des rapports cohérents du cluster concernant cet état, et prend des mesures pour mettre l'état en accord avec les spécifications en créant ou en détruisant des pods.

Référentiel d'images de conteneurs

Un dernier composant à connaître est le référentiel d'images (également appelé registre d'images). Ce composant existe en dehors du cluster et les administrateurs et le plan de contrôle y accèdent pour télécharger les définitions de conteneurs requises. Les registres sont hébergés chez divers fournisseurs, dont Docker Hub, et peuvent être publics ou privés. Les principaux fournisseurs de cloud proposent tous des référentiels gérés pour les entreprises.

Conteneurs de règles Kubernetes

Vous avez maintenant une meilleure idée de ce que peut être une architecture Kubernetes et de la manière dont le gestionnaire fonctionne pour atteindre son objectif. Ce n'est pas un système simple, parce que le déploiement, la gestion et la mise à l'échelle d'applications basées sur des conteneurs n'est pas un objectif simple. Kubernetes est hautement configurable et suffisamment flexible pour gérer les nombreux scénarios d'applications basées sur des conteneurs que l’on peut rencontrer.

Kubernetes est la technologie la plus importante utilisée dans les approches actuelles de l'architecture logicielle. Si bien que la connaissance de Kubernetes sera essentielle pour quiconque s'intéresse aux devops, aux conteneurs, aux applications natives du cloud et à l'architecture de microservices.