Présentation de l'architecture de Kubernetes

• L'architecture de Kubernetes repose sur un modèle comprenant un plan de contrôle et des nœuds de calcul.
• Un cluster Kubernetes doit être sécurisé, facile à utiliser et adaptable.
• Un cluster se divise en deux parties : le plan de contrôle qui prend des décisions globales et les nœuds qui exécutent les applications.
• Telle quelle, l'architecture de Kubernetes ne permet pas d'ouvrir la communication entre les pods de différents nœuds, d'acheminer le trafic Internet vers l'intérieur, ni de faciliter la consultation des journaux.
• Kubernetes offre les outils nécessaires pour orchestrer une application conteneurisée complexe et volumineuse, mais l'utilisateur doit prendre de nombreuses autres décisions.

Définition de l'architecture de Kubernetes

L'architecture de Kubernetes repose sur un modèle comprenant un plan de contrôle et des nœuds de calcul. Elle divise un cluster en deux couches principales : le plan de contrôle, chargé de prendre des décisions globales et de gérer le cluster, et les nœuds de calcul, qui exécutent physiquement les applications à l'intérieur des conteneurs.

Il suffit de connaître les bases de Kubernetes pour savoir qu'il s'agit d'une plateforme Open Source d'orchestration des conteneurs qui exécute des applications et services distribués à grande échelle. Ses composants et leurs interactions sont toutefois plus complexes à comprendre.

Découvrons les principes clés de conception de Kubernetes ainsi que la manière dont ses différents composants fonctionnent ensemble.

Comme expliqué dans le guide de mise en œuvre, un cluster Kubernetes est conçu selon trois principes

et doit être :

• Sécurisé : il doit suivre les meilleures pratiques les plus récentes en matière de sécurité.
• Facile à utiliser : il doit être utilisable avec quelques commandes simples.
• Adaptable : il doit être personnalisable via un fichier de configuration et ne pas favoriser un fournisseur.

Un cluster correspond à un déploiement Kubernetes opérationnel. Un cluster Kubernetes se divise en deux parties : le plan de contrôle et les machines de calcul ou nœuds. Chaque nœud est son propre environnement Linux®. Il peut s'agir d'une machine virtuelle ou physique. Chaque nœud exécute des pods, constitués de conteneurs.

Le schéma ci-dessous montre les liens entre les différents éléments d'un cluster Kubernetes :

Le plan de contrôle Kubernetes est le « cerveau » du cluster. Sa mission consiste à prendre des décisions globales (comme l'ordonnancement des applications), à détecter les événements qui se produisent au sein du cluster et à y répondre, ainsi qu'à vérifier que l'état réel du cluster correspond à l'état souhaité qui a été déclaré.

Le plan de contrôle Kubernetes contient les composants qui contrôlent le cluster, ainsi que des données sur l'état et la configuration du cluster. Ces principaux composants de Kubernetes s'assurent que suffisamment de conteneurs peuvent fonctionner avec les ressources nécessaires. 

Le plan de contrôle est en contact permanent avec les machines de calcul. L'utilisateur configure le cluster pour qu'il s'exécute d'une certaine manière. Le plan de contrôle veille au respect de cette configuration.

kube-apiserver

L'API Kubernetes est la partie frontale du plan de contrôle. Elle traite les demandes internes et externes. Le serveur d'API détermine si une demande est valide ou non et la traite, le cas échéant. L'accès à l'API se fait via des appels REST, à l'aide de l'interface en ligne de commande kubectl ou d'autres outils en ligne de commande tels que kubeadm.

kube-scheduler

En plus de l'intégrité du cluster, l'ordonnanceur doit prendre en compte les besoins en ressources (par exemple, processeur ou mémoire) d'un pod. Il ordonnance ensuite l'attribution du pod au nœud de calcul adéquat.

kube-controller-manager

Les contrôleurs assurent l'exécution du cluster, tandis que le gestionnaire de contrôleur Kubernetes, controller-manager, regroupe plusieurs fonctions de contrôleur. Un contrôleur vérifie auprès de l'ordonnanceur qu'un nombre suffisant de pods est exécuté. Si un pod est défaillant, un autre contrôleur le remarque et réagit. Un contrôleur connecte les services aux pods pour diriger les requêtes vers les points de terminaison appropriés. Des contrôleurs sont également chargés de créer des comptes et des jetons d'accès aux API.

etcd

etcd est une base de données clés-valeurs qui comprend les données de configuration et les informations sur l'état du cluster. Distribuée et tolérante aux pannes, cette base de données constitue la référence unique concernant un cluster.

Tandis que le plan de contrôle joue le rôle de « cerveau », les nœuds de calcul Kubernetes représentent les « muscles » du cluster, qui assurent l'exécution des applications.

Un nœud Kubernetes peut prendre la forme d'une machine physique ou virtuelle. Il effectue en continu les mêmes tâches : recevoir des instructions du plan de contrôle, exécuter des conteneurs, gérer la mise en réseau et faire un rapport sur l'intégrité du cluster.

Un cluster Kubernetes nécessite au moins un nœud de calcul, mais en général il en contient un grand nombre. Les pods sont ordonnancés et orchestrés pour s'exécuter sur des nœuds. Pour mettre à l'échelle la capacité du cluster, il suffit d'ajouter des nœuds.

Pods

Le pod est l'unité la plus petite et la plus simple du modèle d'objets Kubernetes. Il représente une seule instance d'une application. Chaque pod est constitué d'un conteneur ou d'un ensemble de conteneurs étroitement couplés, ainsi que d'options qui permettent de contrôler l'exécution de ces conteneurs. Il est possible de connecter les pods à un système de stockage persistant afin d'exécuter des applications stateful.

Moteur d'exécution des conteneurs

Chaque nœud de calcul dispose d'un moteur qui permet d'exécuter les conteneurs, comme Docker. Kubernetes prend aussi en charge d'autres environnements conformes à l'OCI (Open Container Initiative), tels que rkt et CRI-O.

kubelet

Chaque nœud de calcul contient un kubelet, une petite application qui communique avec le plan de contrôle. Le kubelet s'assure que les conteneurs sont exécutés dans un pod. Lorsque le plan de contrôle envoie une requête à un nœud, le kubelet exécute l'action.

kube-proxy

Chaque nœud de calcul contient également un proxy réseau, kube-proxy, qui facilite l'exécution des services de mise en réseau de Kubernetes. Le composant kube-proxy gère les communications réseau dans et en dehors du cluster. Il utilise la couche de filtrage de paquets du système d'exploitation si elle est disponible, sinon il transmet le trafic lui-même.

D'un point de vue technique, un plan de contrôle et des nœuds de calcul suffisent pour former un cluster Kubernetes. Celui-ci est toutefois encore incomplet. Telle quelle, l'architecture Kubernetes ne permet pas d'ouvrir la communication entre les pods de différents nœuds, d'acheminer le trafic Internet vers l'intérieur, ni de faciliter la consultation des journaux.

Un cluster n'est prêt pour la production qu'après l'installation de modules complémentaires et d'une infrastructure sous-jacente.

1. Mise en réseau : Kubernetes nécessite un réseau virtuel superposé pour faciliter la communication des pods entre différents nœuds. Il faut installer un plug-in CNI (Container Network Interface), tel que Cilium ou Calico, pour créer cette couche réseau et attribuer des adresses IP uniques à chaque pod.
2. Contrôleur Ingress : si le trafic interne est géré automatiquement, la mise en place d'une passerelle s'impose pour autoriser le trafic externe. Un contrôleur Ingress tel que NGINX ou Traefik agit comme un proxy inversé et un équilibreur de charge qui achemine en toute sécurité le trafic Internet externe vers les services appropriés à l'intérieur du cluster.
3. Service DNS du cluster : étant donné que les pods changent d'adresse IP à chaque redémarrage, il n'est pas envisageable de coder en dur les chemins d'accès au réseau. Un fournisseur de service DNS (par exemple, CoreDNS) met automatiquement en correspondance les noms de domaine permanents et les services, permettant ainsi aux applications de se localiser entre elles.
4. Système de provisionnement du stockage : les conteneurs sont de nature stateless, ce qui signifie que toutes les données qu'ils contiennent s'effacent en cas de panne. Une interface CSI (Container Storage Interface) lie le cluster à un système de stockage physique externe (tel que des disques cloud ou un système de fichiers réseau), en provisionnant et en associant automatiquement des disques durs permanents pour préserver les données lors des redémarrages.
5. Pile d'observabilité : lorsque les applications sont dispersées sur plusieurs machines, il est nécessaire de centraliser les informations pour résoudre les problèmes. Des outils tels que Prometheus et Grafana surveillent les indicateurs de mesure des clusters. Avec des agents de journalisation comme FluentBit, ils regroupent les journaux des conteneurs dans un seul tableau de bord consultable.

Cette présentation simplifiée de l'architecture de Kubernetes ne couvre que les bases. Pour vraiment comprendre les défis que posent la configuration et la sécurisation d'un cluster Kubernetes, il faut observer la manière dont ces composants communiquent, entre eux et avec l'infrastructure et les ressources externes.

Kubernetes offre les outils nécessaires pour orchestrer une application conteneurisée complexe et volumineuse, mais l'utilisateur doit prendre de nombreuses autres décisions. Celui-ci doit choisir le système d'exploitation, l'environnement d'exécution des conteneurs, les outils de CI/CD (intégration et distribution continues), les services d'applications, le système de stockage et la plupart des autres composants. Il lui faut également gérer les rôles, le contrôle des accès, l'architecture multi-client et les paramètres de sécurité par défaut. Par ailleurs, l'utilisateur peut choisir d'exécuter lui-même Kubernetes ou de faire appel à un fournisseur qui propose une version prise en charge.

Cette liberté de choix démontre la flexibilité de Kubernetes. Malgré une mise en œuvre parfois complexe, Kubernetes permet aux entreprises d'exécuter des applications conteneurisées selon leurs propres exigences et de réagir aux changements de manière agile.

Assemblage d'applications cloud-native avec Kubernetes

Nous proposons une série de webinars qui fournit des conseils de spécialistes pour aider les entreprises à mettre au point la plateforme de données basée sur Kubernetes dont elles ont besoin pour assembler, exécuter, déployer et moderniser des applications. 

Regarder les webinars en replay

Chez Red Hat, nous contribuons activement aux technologies Open Source de conteneurisation, notamment Kubernetes. Nous créons les outils essentiels pour sécuriser, simplifier et mettre à jour automatiquement les infrastructures de conteneurs. 

La solution Red Hat® OpenShift® est une distribution Kubernetes adaptée aux entreprises. Avec elle, les équipes bénéficient d'une seule et même plateforme intégrée pour les pratiques DevOps. Red Hat OpenShift permet aux équipes de développement d'utiliser les langages, frameworks, solutions de middleware et bases de données de leur choix, ainsi que de mettre en œuvre des processus automatisés pour assembler et déployer des applications à l'aide de pipelines de CI/CD, avec à la clé une hausse de la productivité. Nous proposons également une plateforme de services de données et de stockage conçue pour les conteneurs, Red Hat OpenShift Data Foundation.

En savoir plus