Kubernetes (K8s) : guide d’apprentissage rapide

Kubernetes, également abrégé K8s, est une plateforme open source permettant d’automatiser et d’orchestrer le déploiement, la mise à l’échelle et la gestion des applications et des charges de travail conteneurisées. Elle fournit une infrastructure de calcul offrant nativement flexibilité, évolutivité, fiabilité, haute disponibilité et portabilité aux applications exécutées dans des conteneurs, quel que soit l’environnement : sur site, dans le cloud ou en périphérie.

Qu’est-ce que Kubernetes ?

Kubernetes automatise les tâches les plus courantes liées à la gestion à grande échelle des charges de travail conteneurisées, notamment le déploiement, l’équilibrage de charge, la mise à l’échelle horizontale, les déploiements progressifs et les restaurations, ainsi que l’autoréparation.

De nombreuses organisations utilisent déjà Kubernetes en production, que ce soit pour certaines de leurs applications ou pour la majorité d’entre elles, tandis que d’autres sont en train de l’évaluer. Sa popularité a fait de Kubernetes la norme de facto en matière d’orchestration et de gestion des conteneurs.

Avantages de Kubernetes

L’adoption de Kubernetes progresse rapidement, car il permet de :

Accélérer et simplifier le cycle de publication des applications
Permettre la portabilité des charges de travail entre les environnements de cloud public, privé, hybride et multicloud
Améliorer l’efficacité de l’utilisation des ressources
Faciliter la mise à l’échelle et la préparation à la production
Optimiser l’environnement afin de respecter les SLA métier

Kubernetes et les microservices

La refactorisation des applications monolithiques traditionnelles en composants plus petits et faiblement couplés, appelés « microservices », contribue à améliorer l’agilité de l’entreprise, car les nouvelles fonctionnalités et mises à jour des applications peuvent être déployées plus rapidement et mises à l’échelle plus facilement. L’adoption d’une architecture cloud native fondée sur les microservices nécessite de faire évoluer l’infrastructure de calcul sous-jacente. C’est pourquoi nous observons une transition des systèmes physiques et des machines virtuelles vers les conteneurs, qui constituent l’un des moyens les plus efficaces d’exécuter des microservices.

À mesure que le nombre de microservices et de conteneurs augmente, la nécessité d’automatiser la gestion des conteneurs s’accroît elle aussi. C’est là que Kubernetes entre en jeu.

Qu’est-ce que Kubernetes ?

Kubernetes, également abrégé K8s, est une plateforme open source qui permet d’automatiser et d’orchestrer le déploiement, la mise à l’échelle et la gestion des applications et charges de travail conteneurisées. Elle fournit une infrastructure de calcul offrant nativement flexibilité, évolutivité, fiabilité, haute disponibilité et portabilité aux applications exécutées dans des conteneurs, quel que soit l’environnement : sur site, dans le cloud ou en périphérie.

Avantages de Kubernetes

L’adoption de Kubernetes connaît une croissance rapide, car il peut aider à :

Accélérer et simplifier le cycle de publication des applications
Permettre la portabilité des charges de travail entre les environnements de cloud public, privé et hybride, ainsi que les environnements multicloud
Améliorer l’efficacité de l’utilisation des ressources
Faciliter la mise à l’échelle et la préparation à la production
Optimiser l’environnement afin de respecter les SLA métier

Kubernetes et microservices

La refactorisation des applications monolithiques traditionnelles en composants plus petits et faiblement couplés, appelés microservices (https://www.f5.com/glossary/microservices-architecture), contribue à améliorer l’agilité de l’entreprise, car les nouvelles fonctionnalités et mises à jour des applications peuvent être déployées plus rapidement et mises à l’échelle plus facilement. L’adoption d’une architecture cloud native fondée sur des microservices impose de faire évoluer l’infrastructure informatique sous-jacente. Nous observons ainsi une transition des systèmes physiques et des machines virtuelles vers les conteneurs, qui constituent l’un des moyens les plus efficaces d’exécuter des microservices.

À mesure que le nombre de microservices et de conteneurs augmente, la nécessité d’automatiser la gestion des conteneurs s’accroît elle aussi. C’est là que Kubernetes entre en jeu.

Kubernetes contre Docker

Kubernetes orchestre et exécute des applications conteneurisées à grande échelle. Toutefois, il ne permet pas de conditionner le code d’une application dans un format conteneurisé en vue de sa distribution et de son exécution (une image de conteneur comprend le code de l’application ainsi que les environnements d’exécution, les bibliothèques et les autres dépendances logicielles nécessaires). Pour que les pods puissent s’exécuter, Kubernetes exige également qu’un environnement d’exécution de conteneurs soit installé sur chaque nœud. À l’origine, Kubernetes utilisait Docker Engine comme environnement d’exécution de conteneurs. Toutefois, depuis Kubernetes 1.24, cet environnement doit être conforme à la Container Runtime Interface (CRI), ce qui n’est pas le cas de Docker Engine. CRI-O et containerd (initialement un projet Docker) sont deux environnements d’exécution de conteneurs populaires et conformes à la CRI.

Pour empaqueter des applications dans des conteneurs, vous avez besoin d’un outil comme Docker, l’un des outils les plus populaires pour créer, partager et exécuter des applications conteneurisées. Il simplifie et automatise l’empaquetage des applications dans des images de conteneur portables, prêtes à être exécutées et déployées sur site ou dans le cloud, notamment dans des environnements Kubernetes. Les conteneurs empaquetés avec Docker peuvent s’exécuter nativement avec les environnements d’exécution containerd et CRI-O.

Architecture de Kubernetes

Une plateforme Kubernetes est constituée de nœuds regroupés au sein d’un cluster, dans lequel ils partagent des ressources de calcul mutualisées. Chaque cluster gère des pods, qui sont les plus petites unités déployables de l’architecture Kubernetes. Un pod contient un ou plusieurs conteneurs d’application. Les pods sont regroupés pour former un service. Les applications d’un cluster Kubernetes peuvent être accessibles depuis l’extérieur à l’aide de plusieurs méthodes, le contrôleur Ingress étant l’une des plus populaires et efficaces.

Examinons de plus près les composants d’un environnement Kubernetes :

Pods Kubernetes

Un pod Kubernetes est la plus petite unité exécutable pouvant être déployée dans Kubernetes. Le pod constitue un « hôte virtuel » pour la ou les images de conteneur de l’application (à l’instar d’un serveur physique ou d’une machine virtuelle pour les applications traditionnelles) et encapsule un ou plusieurs conteneurs qui partagent les mêmes ressources de calcul, de stockage et de réseau (et peuvent donc être considérés comme relativement étroitement couplés). Les pods sont déployés et exécutés sur des nœuds Kubernetes.

Nœuds Kubernetes

Un nœud Kubernetes est la plus petite unité d’une infrastructure de calcul. Il peut s’agir d’une machine virtuelle ou d’un serveur physique qui alloue des ressources de processeur, de mémoire, de stockage et de réseau afin de déployer, d’exécuter, de mettre à l’échelle et de gérer des pods. Les nœuds sont regroupés pour former un cluster.

Clusters Kubernetes

Un cluster Kubernetes est un groupe de nœuds dans lequel des ressources de calcul mutualisées sont partagées entre les pods. Il existe deux types de nœuds dans un cluster :

Nœuds de travail – Exécutent les applications conteneurisées dans les pods
Nœuds maîtres – Exécutent le plan de contrôle Kubernetes, qui orchestre et gère les nœuds de travail et les pods

En règle générale, un cluster Kubernetes comporte plusieurs nœuds de chaque type afin de garantir une haute disponibilité et une tolérance aux pannes.

Déploiements Kubernetes

Un déploiement Kubernetes décrit comment exécuter une application sous la forme d’un ensemble de réplicas (ou d’instances) du pod dans un cluster. Un déploiement définit :

Le nombre de réplicas de pod à exécuter
Comment déployer progressivement les mises à jour des pods
Comment restaurer l’état précédent des réplicas de pods
Comment mettre à l’échelle horizontalement les réplicas de pods

Connectivité des applications dans Kubernetes

Kubernetes prend en charge une double pile IPv4/IPv6 afin d’assurer la connectivité réseau des applications conteneurisées exécutées dans un cluster. Les communications entrantes et sortantes des applications du cluster Kubernetes, ainsi que les communications entre les services au sein du cluster, sont gérées au niveau de la couche 4 (adresse IP, port) et de la couche 7 (nom d’hôte, identificateur uniforme de ressource [URI]). Elles incluent des fonctionnalités de routage, d’équilibrage de charge, de sécurité, de surveillance et de visibilité.

Réseau Kubernetes

Dans le modèle réseau de Kubernetes , chaque pod possède une adresse IP unique qui lui est attribuée dynamiquement à partir du pool d’adresses privées du cluster. Tous les pods exécutés sur l’ensemble des nœuds d’un même cluster appartiennent au même réseau IP et peuvent communiquer entre eux via ce réseau. Plusieurs conteneurs au sein d’un même pod communiquent entre eux via l’interface de bouclage.

Services Kubernetes

Un service Kubernetes rend accessible sur le réseau (« expose ») l’application ou le microservice qui s’exécute dans le cluster sous la forme d’un ou de plusieurs pods. Un service Kubernetes représente l’application comme un groupe logique de pods désignés qui remplissent la même fonction, par exemple la diffusion de contenu web. Le même sélecteur (ou label) est appliqué à tous les pods d’un service afin d’indiquer leur appartenance à ce service. Kubernetes utilise ce label pour suivre l’ensemble des pods associés à un service à mesure que de nouveaux pods sont déployés ou que des pods en cours d’exécution sont arrêtés.

Les services Kubernetes peuvent communiquer entre eux au sein du cluster conformément aux politiques de connectivité définies, et être rendus accessibles depuis l’extérieur du cluster, par exemple à l’aide d’un contrôleur Ingress.

Ingress Kubernetes

L’objet Ingress, qui fait partie de l’API Kubernetes Ingress, permet d’exposer à l’extérieur les applications exécutées dans Kubernetes au moyen de protocoles de couche 7 (couche applicative), tels que HTTP. Les passerelles Ingress et les contrôleurs Ingress sont des outils conçus pour contrôler l’objet Ingress et gérer les communications entre les utilisateurs et les applications (connectivité utilisateur-service ou nord-sud).

De par sa conception, l’objet Ingress offre une prise en charge limitée des politiques personnalisées de traitement des requêtes. Par exemple, il n’est pas possible de lui définir et de lui associer des politiques de sécurité. Par conséquent, de nombreux fournisseurs utilisent des définitions de ressources personnalisées (CRD) pour étendre les fonctionnalités de leurs contrôleurs Ingress afin de répondre à l’évolution des besoins de leurs clients.

Par exemple, NGINX Ingress Controller définit des ressources personnalisées (VirtualServer, VirtualServerRoute, TransportServer et Policy) afin d’améliorer les performances, la résilience, la disponibilité, la sécurité et l’observabilité des fonctionnalités de passerelle API, d’équilibreur de charge et d’Ingress à la périphérie d’un cluster Kubernetes.

NGINX fournit des services d’équilibrage de charge, d’authentification, d’autorisation, de contrôle d’accès, de chiffrement, d’observabilité et de répartition du trafic (disjoncteur, tests A/B et déploiements bleu-vert et Canary) afin de garantir des communications rapides, fiables et sécurisées. Pour faciliter les mises en production fréquentes des applications, les ressources personnalisées NGINX permettent également une gouvernance en libre-service au sein des équipes de développement et DevOps mutualisées entre plusieurs locataires.

API Gateway de Kubernetes

La Gateway API est un projet open source visant à améliorer et à normaliser la mise en réseau des services dans Kubernetes. Gérée par la communauté Kubernetes, la spécification Gateway API est issue de l’API Kubernetes Ingress et vise à pallier les limites de la ressource Ingress dans les environnements de production, notamment en permettant de définir des politiques précises pour le traitement des requêtes et de déléguer le contrôle de la configuration à plusieurs équipes et rôles.

Pour en savoir plus sur l’implémentation de la Gateway API par NGINX, consultez l’article « 5 choses à savoir sur NGINX Gateway Fabric » sur notre blog.

Maillage de services

Un maillage de services est une couche d’infrastructure qui contrôle les communications entre les services d’un cluster Kubernetes (connectivité de service à service, ou est-ouest). Les cas d’usage les plus courants d’un maillage de services comprennent l’authentification et le chiffrement mTLS, ainsi que l’observabilité des communications entre les services d’un cluster K8s.

Découvrez comment unifier la mise à disposition des applications avec NGINX Gateway Fabric, conçu pour combiner efficacement les cas d’usage d’un contrôleur Ingress et d’un maillage de services au sein d’un même outil, dans l’article « Annonce de la version 1.0 de NGINX Gateway Fabric » sur notre blog.

Sécurité de Kubernetes

La sécurité de Kubernetes repose sur une approche multicouche visant à protéger l’infrastructure (ressources de calcul sur site et dans le cloud, communications réseau et plan de gestion), ainsi que les applications exécutées au sein d’un cluster Kubernetes.

Pour sécuriser l’infrastructure, suivez les recommandations de sécurité, tutoriels et bonnes pratiques générales visant à protéger les déploiements dans le cloud et sur site.

Pour sécuriser les applications, mettez en œuvre des contrôles de sécurité robustes en périphérie et au sein d’un cluster Kubernetes afin d’assurer l’authentification, l’autorisation, le contrôle des accès, le chiffrement, la surveillance et la visibilité de toutes les communications entrantes, sortantes et internes au cluster, avec, en option, un pare-feu d’applications web et une protection contre les attaques par déni de service.

Pour en savoir plus sur la sécurisation de Kubernetes, consultez notre article de blog « Six façons de sécuriser Kubernetes à l’aide d’outils de gestion du trafic ».

Kubernetes en production

Aux débuts de l’adoption de Kubernetes, l’approche « faites-le vous-même » (DIY) prédominait. Cependant, pour de nombreuses organisations, elle est complexe et difficile à mettre en place et à exploiter. C’est pourquoi, pour les déploiements en production, les organisations adoptent des plateformes Kubernetes gérées dans le cloud et des distributions Kubernetes préconfigurées qui intègrent divers composants technologiques, simplifient le cycle de vie de la maintenance et peuvent être déployées dans des environnements hybrides et multicloud.

Voici quelques exemples de plateformes Kubernetes gérées et préconfigurées :

Kubernetes géré dans le cloud :

Distributions Kubernetes préconfigurées :

Comment NGINX peut vous aider

La pile de connectivité et de sécurité de NGINX, conçue nativement pour Kubernetes, contribue à améliorer l’expérience client en réduisant la complexité, en augmentant la disponibilité et en offrant une visibilité détaillée en temps réel à grande échelle sur les applications Kubernetes exécutées sur site, dans le cloud et en périphérie.

Pile de connectivité pour Kubernetes – Optimisez, faites évoluer et sécurisez les applications Kubernetes dans des environnements hybrides et multicloud.

NGINX Ingress Controller – Une passerelle d’API, un équilibreur de charge et un contrôleur Ingress unifiés qui permettent d’améliorer les SLA métier et d’obtenir une meilleure visibilité sur l’état et les performances des applications à grande échelle dans des environnements Kubernetes distribués.
NGINX Gateway Fabric – Une plateforme unifiée de mise à disposition d’applications qui simplifie la connectivité des applications, des services et des API dans les environnements Kubernetes hybrides et multicloud.
NGINX App Protect – Une solution complète de pare-feu applicatif web (WAF) et de protection contre les attaques par déni de service (DoS), conçue pour protéger les applications et les API contre les attaques de couche 7.

Commencez par demander votre essai gratuit de 30 jours de NGINX Ingress Controller avec NGINX App Protect WAF et DoS.

Contenu associé

Blog Post
Pourquoi les plateformes SASE et ADSP sont complémentaires