Qu’est-ce que l’architecture Kubernetes ?
Kubernetes est une architecture qui offre un mécanisme faiblement couplé pour la détection de services à l’échelle d’un cluster. Un cluster Kubernetes possède un ou plusieurs plans de contrôle, et un ou plusieurs nœuds de calcul. Globalement, le plan de contrôle est responsable de la gestion de l’ensemble du cluster, de l’exposition de l’interface de programme d’application (API) et de la planification du lancement et de l’arrêt des nœuds de calcul en fonction d’une configuration souhaitée. Chacun des nœuds de calcul exécute un runtime de conteneur comme Docker avec un agent, kubelet, qui communique avec le plan de contrôle. Chaque nœud peut être un serveur bare metal ou une machine virtuelle (VM) on-premise ou dans le Cloud.
vSphere with Tanzu 101 - Introduction pour les administrateurs vSphere
Pourquoi choisir la virtualisation VMware pour Kubernetes et les conteneurs
Quels sont les composants de l’architecture Kubernetes ?
Les principaux composants d’un cluster Kubernetes sont les suivants :
Nœuds : les nœuds sont des machines virtuelles ou des serveurs physiques qui hébergent les applications conteneurisées. Chaque nœud d’un cluster peut exécuter une ou plusieurs instances d’application. Il peut n’y avoir qu’un seul nœud, mais un cluster Kubernetes classique en aura plusieurs (et les déploiements avec des centaines de nœuds, voire plus, ne sont pas rares).
Registre d’image : les images de conteneur sont conservées dans le registre et transférées aux nœuds par le plan de contrôle pour exécution dans les pods du conteneur.
Pods : les pods sont l’emplacement d’exécution des applications conteneurisées. Ils peuvent inclure un ou plusieurs conteneurs et constituent la plus petite unité de déploiement pour les applications dans un cluster Kubernetes.
Qu’est-ce que l’architecture de plan de contrôle Kubernetes ?
Un plan de contrôle Kubernetes est le plan de contrôle pour un cluster Kubernetes. Ses composants sont les suivants :
- kube-apiserver : comme son nom l’indique, le serveur d’API expose l’API Kubernetes, qui est la centrale de communication. Les communications externes via l’interface de ligne de commande (CLI) ou d’autres interfaces utilisateur (IU) passent par le serveur kube-apiserver, tout comme toutes les communications entre les plans de contrôle et les nœuds.
- Etcd : le magasin clé-valeur dans lequel toutes les données relatives au cluster sont stockées. etcd est hautement disponible et cohérent, car tous ses accès s’effectuent via le serveur d’API. Les informations contenues dans etcd sont généralement au format YAML (acronyme récursif de « YAML Ain’t Markup Language ») lisible par l’utilisateur.
- kube-scheduler : lorsqu’un nouveau pod est créé, ce composant l’affecte à un nœud pour exécution en fonction des besoins en ressources, des règles et des spécifications d’« affinité » concernant la géolocalisation et les interférences avec d’autres charges de travail.
- kube-controller-manager : même si un cluster Kubernetes a plusieurs fonctions contrôleur, ces dernières sont toutes compilées dans un seul fichier binaire appelé kube-controller-manager.
Les fonctions contrôleur incluses dans ce processus sont les suivantes :
- Contrôleur de réplication : garantit qu’il existe un nombre de pods approprié pour chaque pod répliqué exécuté dans le cluster
- Contrôleur de nœud : surveille l’intégrité de chaque nœud et informe le cluster lorsque des nœuds passent en ligne ou ne répondent plus
- Contrôleur Endpoints : connecte les pods et les services pour renseigner l’objet Endpoints.
- Contrôleurs de compte de service et de jeton : alloue des jetons d’accès d’API et des comptes par défaut aux nouveaux espaces de nommage dans le cluster.
- cloud-controller-manager : si le cluster est partiellement ou entièrement basé sur le Cloud, le gestionnaire de contrôleur Cloud relie le cluster à l’API du fournisseur de Cloud. Seuls les contrôles spécifiques au fournisseur de Cloud s’exécutent. Le gestionnaire de contrôleur Cloud n’existe pas sur les clusters entièrement on-premise. Plusieurs gestionnaires de contrôleur Cloud peuvent être exécutés dans un cluster à des fins de tolérance aux pannes ou d’amélioration des performances globales du Cloud.
Les éléments du gestionnaire de contrôleur Cloud sont notamment :
- Contrôleur de nœud : détermine le statut d’un nœud Cloud qui ne répond plus, c’est-à-dire s’il a été supprimé.
- Contrôleur de route : établit des routes dans l’infrastructure du fournisseur de Cloud.
- Contrôleur de service : gère les équilibreurs de charge du fournisseur de Cloud.
Qu’est-ce que l’architecture de nœuds Kubernetes ?
Les nœuds sont les machines, à savoir les machines virtuelles ou les serveurs physiques, sur lesquelles Kubernetes place des pods à exécuter. Les composants de nœud sont les suivants :
kubelet : chaque nœud est associé à un agent appelé kubelet. Il garantit que le conteneur décrit dans les spécifications PodSpecs fonctionne correctement.
kube-proxy : proxy réseau sur chaque nœud qui gère les nœuds de réseau et permet la communication entre les pods et les sessions réseau, à l’intérieur ou à l’extérieur du cluster, à l’aide du filtrage de paquets du système d’exploitation (SE), le cas échéant.
container runtime : logiciel responsable de l’exécution des applications conteneurisées. Même si Docker est le plus populaire, Kubernetes prend en charge tout runtime compatible avec l’interface Kubernetes CRI (Container Runtime Interface).
Quels sont les autres composants de l’infrastructure Kubernetes ?
Pods : en encapsulant un (ou plusieurs) conteneurs d’applications, les pods sont l’unité d’exécution la plus élémentaire d’une application Kubernetes. Chaque pod contient le code et les ressources de stockage nécessaires à l’exécution et possède sa propre adresse IP. Les pods incluent également des options de configuration. En général, un pod contient un ou quelques conteneurs couplés dans une application ou une fonction métier et partageant un ensemble de ressources et de données.
Déploiements : méthode de déploiement des pods d’application conteneurisées. Si un état souhaité est décrit dans un déploiement, les contrôleurs modifient l’état réel du cluster pour atteindre cet état de manière rationnelle. En savoir plus sur les déploiements Kubernetes.
ReplicaSet : garantit qu’un nombre spécifié de pods identiques s’exécutent à un moment donné.
DNS de cluster : fournit les enregistrements DNS nécessaires au fonctionnement des services Kubernetes.
Surveillance des ressources de conteneur : capture et enregistre les mesures des conteneurs dans une base de données centrale.
Quels sont les meilleures pratiques et les principes de conception d’une architecture Kubernetes ?
Les meilleures pratiques de Gartner en matière de conteneurs suggèrent une stratégie de plate-forme qui intègre la sécurité, la gouvernance, la surveillance, le stockage, la mise en réseau, la gestion du cycle de vie des conteneurs et l’orchestration comme Kubernetes.
Voici quelques-unes des meilleures pratiques pour concevoir une architecture de clusters Kubernetes :
- Assurez-vous d’avoir installé la dernière version de Kubernetes (1.18 au moment de la rédaction).
- Investissez en amont dans la formation des équipes responsables du développement et des opérations.
- Établissez une gouvernance à l’échelle de l’entreprise. Assurez-vous que les outils et les fournisseurs sont alignés et intégrés à l’orchestration Kubernetes.
- Améliorez la sécurité en intégrant des processus d’analyse d’image dans le cadre de votre processus d’intégration et livraison continues (CI/CD), avec une analyse pendant les phases de création et d’exécution. Un code open source extrait d’un référentiel Github doit toujours être considéré comme suspect.
- Adoptez un contrôle d’accès basé sur les rôles (RBAC) sur l’ensemble du cluster. Les modèles de privilège minimum et zéro confiance doivent être la norme.
- Sécurisez davantage les conteneurs en utilisant uniquement des utilisateurs non-root et en définissant le système de fichiers en lecture seule.
- Évitez d’utiliser la valeur par défaut, car les déclaratifs simples sont moins sujets aux erreurs et démontrent plus clairement l’intention.
- Utilisez les images Docker Hub de base avec précaution car elles peuvent contenir des logiciels malveillants ou être surchargées de code inutile. Commencez avec un code simple et propre à partir duquel créer les packages. Les petites images sont créées plus rapidement et prennent moins de place sur le disque. Les extractions d’images sont également plus rapides.
- Simplifiez les conteneurs. Un processus par conteneur permet à l’orchestrateur de signaler si ce processus est sain ou non.
- En cas de doute ou de plantage, Kubernetes redémarre un conteneur défaillant ; ne redémarrez donc pas en cas de panne.
- Donnez des détails. Les libellés descriptifs aident les développeurs actuels et aideront considérablement les développeurs suivants.
- Ne soyez pas trop granulaire avec les microservices. Toutes les fonctions d’un composant de code logique n’ont pas besoin de disposer de leur propre microservice.
- Automatisez là où c’est pertinent. L’automatisation du pipeline CI/CD vous permet d’éviter entièrement les déploiements manuels de Kubernetes.
- Utilisez livenessProbe et readinessProbe pour faciliter la gestion des cycles de vie des pods. Dans le cas contraire, les pods peuvent être arrêtés lors de l’initialisation ou commencer à recevoir des demandes des utilisateurs avant d’être prêts.
L’architecture Kubernetes est simple et intuitive. Le faible couplage entre le plan de contrôle et le nœud offre une flexibilité presque infinie et la capacité pour une application d’évoluer pratiquement instantanément en fonction des besoins, de migrer les utilisateurs vers de nouvelles versions et de prendre en charge la migration des nœuds on-premise vers les nœuds Cloud ou entre plusieurs Clouds pour profiter des fonctionnalités souhaitées de chaque fournisseur de Cloud.
Solutions et produits connexes
Modernisation des applications avec Kubernetes
Exécutez vos applications traditionnelles et modernes côte à côte.
Horizon Cloud sur Microsoft Azure
Plate-forme de postes de travail virtuels Cloud