Qu’est-ce que Kubernetes ?

Qu’est-ce que Kubernetes ?

Vous avez probablement déjà entendu le mot Kubernetes dans le cadre de la conteneurisation, mais qu'est-ce que Kubernetes et comment cela se traduit-il en termes de réduction de l'effort manuel associé à ces processus ? Développé à l'origine par Google, Kubernetes est une plateforme d'orchestration des conteneurs open source conçue pour automatiser le déploiement, l'évolutivité (ou scalabilité), et la gestion des applications conteneurisées.

En réalité, Kubernetes est devenue la norme de fait pour l'orchestration de conteneurs et est le projet phare de la Cloud Native Computing Foundation (CNCF), soutenue par d'importants acteurs comme Google, Amazon Web Services (AWS), Microsoft, IBM, Intel, Cisco, et Red Hat.

Bien que couramment associé au cloud, Kubernetes opère dans divers environnements : des serveurs classiques aux serveurs dans le cloud en passant par les infrastructures cloud hybrides. 

Les architectures microservices basées sur des conteneurs ont profondément changé la façon dont les équipes de développement et d'opérations testent et déploient les logiciels modernes. Les conteneurs aident les entreprises à se moderniser en facilitant l'évolutivité et le déploiement des applications, mais les conteneurs sont également source de difficultés et d'une plus grande complexité en créant un tout nouvel écosystème d'infrastructure.

Petites ou grandes, les entreprises IT déploient toutes des milliers d'instances de conteneurs chaque jour, et elles doivent gérer cette complexité d'échelle. Comment y arrivent-elles ?

Kubernetes facilite le déploiement et l'exploitation des applications dans une architecture microservices Ainsi, les équipes de développement peuvent déployer leurs applications et confier à Kubernetes la gestion des éléments suivants :

• Contrôle de la consommation des ressources par application ou équipe
• Répartition uniforme de la charge des applications sur l'infrastructure hôte
• Équilibrage automatique de la charge des requêtes sur les différentes instances d'une application
• Monitoring de la consommation et des limites de ressources pour arrêter et redémarrer automatiquement les applications qui consomment trop de ressources
• Déplacement d'une instance d'application d'un hôte à un autre en cas de manque de ressources sur un hôte, ou si l'hôte meurt
• Mobilisation automatique de ressources supplémentaires qui deviennent disponibles lors de l'ajout d'un nouvel hôte au cluster
• Déploiements canary et rollbacks simples

Dans cet article, nous allons plonger en profondeur dans le royaume de Kubernetes et découvrir de quoi il s'agit, pourquoi les organisations l'utilisent et quelles sont les meilleures pratiques pour utiliser le plein potentiel de cette technologie innovante et rentable.

À quoi sert Kubernetes et pourquoi ?

Bien entendu vous savez ce qu'est Kubernetes, mais que fait-il précisément ? Kubernetes automatise divers aspects des applications de conteneurisation en donnant aux développeurs une façon simplifiée et évolutive de gérer un réseau d'applications complexes sur des serveurs en clusters. 

Kubernetes rationalise les opérations des conteneurs en distribuant le trafic pour obtenir une plus grande disponibilité. En fonction du trafic sur votre site ou de celui reçu par les serveurs, Kubernetes permet aux applications de s'adapter automatiquement aux changements, en contrôlant la bonne quantité de ressources des workloads selon les besoins. Cela aide à réduire les temps d’arrêt en raison de pics de trafic ou de pannes de réseau. 

Kubernetes aide également à la découverte des services et permet aux applications en clusters de communiquer les unes avec les autres sans connaître au préalable les adresses IP ou la configuration des points de terminaison. En outre, Kubernetes effectue le monitoring de l'état de santé de vos conteneurs, détecte et remplace automatiquement les conteneurs qui ont échoué ou redémarre ceux qui ont été bloqués pour assurer la continuité des opérations. 

Alors, pourquoi utiliser Kubernetes ?

De plus en plus d'organisations passent aux architectures microservices et cloud natives qui utilisent les conteneurs et elles recherchent des plateformes robustes et éprouvées. Ainsi les professionnels utilisent Kubernetes pour quatre raisons principales :

1. Kubernetes aide à aller plus vite. En effet, Kubernetes vous permet de déployer une plateforme en libre-service (PaaS) qui crée une couche d'abstraction matérielle pour les équipes de développement. Ces dernières peuvent rapidement et efficacement demander les ressources dont elles ont besoin. Si elles nécessitent plus de ressources pour traiter des charges plus importantes, elles peuvent les obtenir tout aussi rapidement, car les ressources proviennent toutes d'une infrastructure partagée avec vos équipes.

Fini les nombreux formulaires à remplir pour obtenir de nouvelles machines qui peuvent exécuter votre application ! Il vous suffit désormais de faire la mise en service et c'est tout. Vous pouvez alors profiter des outils développés autour de Kubernetes pour automatiser l'interface, le déploiement, et les tests. (nous aborderons Helm plus en profondeur dans une prochaine section).

2. Kubernetes est économique. Kubernetes et les conteneurs permettent une bien meilleure utilisation des ressources que ne le font les hyperviseurs et les machines virtuelles (VM). Cela est dû au fait que les conteneurs sont tellement légers qu'ils exigent moins de CPU et de mémoires pour leur exécution.

3. Kubernetes est agnostique au cloud.Kubernetes tourne sur Amazon Web Services (AWS), Microsoft Azure, et Google Cloud Platform (GCP), et vous pouvez également l'exécuter sur site. Déplacez des workloads sans devoir réinventer vos applications ni réexaminer votre infrastructure, cela vous permet ainsi d'effectuer la standardisation sur une plateforme et d'éviter toute dépendance avec un fournisseur.

Les entreprises comme Kublr, Cloud Foundry, et Rancher proposent des outils afin de vous aider à déployer et à gérer votre cluster Kubernetes sur site ou dans le cloud du fournisseur de votre choix.

4. Les fournisseurs cloud gèrent Kubernetes pour vous. Comme nous l'avons noté plus haut, Kubernetes est actuellement la norme évidente en matière d'outils d'orchestration de conteneurs. Il n'est donc pas surprenant que les principaux prestataires cloud proposent de nombreux outils Kubernetes en tant que service. Amazon EKS, Google Cloud Kubernetes Engine, Azure Kubernetes Service (AKS), Red Hat OpenShift, et IBM Cloud Kubernetes Service offrent tous la gestion de toute la plateforme Kubernetes, pour que vous puissiez vous concentrer sur ce qui compte le plus pour vous : déployer des applications qui raviront vos utilisateurs.

Comment fonctionne Kubernetes ?

Dans la hiérarchie de Kubernetes, il y a des clusters, des nœuds et des pods. Ces composants travaillent ensemble pour soutenir les applications conteneurisées. Un cluster est composé de divers nœuds responsables de l'exécution des applications. Chaque nœud représente une machine soit physique (sur site) soit virtuelle (basée sur le cloud) qui aide les applications à fonctionner. Chaque nœud exécute un ou plusieurs pods (la plus petite unité déployable dans Kubernetes). Chaque pod contient un ou plusieurs conteneurs. Pensez aux pods comme à des « conteneurs de conteneurs » qui fournissent les ressources nécessaires pour qu'ils fonctionnent correctement, dont notamment les informations sur les réseaux, le stockage et le calendrier.

C'est une explication légèrement simplifiée sur la façon dont Kubernetes fonctionne. À un niveau plus profond, le composant central de Kubernetes est le cluster. Un cluster est composé de nombreuses machines virtuelles ou physiques qui remplissent une fonction spécialisée soit en tant que maître, soit en tant que nœud. Chaque nœud héberge des groupes d'un ou de plusieurs conteneurs (qui contiennent vos applications), et le master communique avec les nœuds quand il faut créer ou détruire des conteneurs. En même temps, il indique aux nœuds comment réacheminer le trafic en fonction des nouveaux alignements de conteneurs.

Le diagramme suivant représente les grandes lignes d'un cluster Kubernetes :

Le master Kubernetes

Le master Kubernetes est le point d'accès (ou le serveur maître) à partir duquel les administrateurs et les autres utilisateurs interagissent avec le cluster pour gérer la programmation et le déploiement des conteneurs. Un cluster aura toujours au moins un maître, mais peut en avoir plus sur le schéma de réplication du cluster.

Le maître stocke les données d'état et de configuration pour tout le cluster dans etcd, un datastore de clés-valeurs distribué et persistant. Chaque nœud a accès à etcd et à grâce à cela, les nœuds apprennent à prendre en charge les configurations des conteneurs qu'ils exécutent. Vous pouvez exécuter etcd sur le maître Kubernetes, ou dans des configurations autonomes. Vous pouvez exécuter etcd sur le maître Kubernetes, ou dans des configurations autonomes.

Les maîtres communiquent avec le reste du cluster via le kube-apiserver, le principal point d'accès au serveur maître. Par exemple, le kube-apiserver s'assure que les configurations dans etcd correspondent aux configurations des conteneurs déployés dans le cluster.

Le kube-controller-manager traite les boucles de contrôle qui gèrent l'état du cluster via le serveur d'API Kubernetes. Les déploiements, répliques et nœuds ont des contrôles traités par ce service. Par exemple, le contrôleur de nœuds est responsable d'enregistrer un nœud et de réaliser le monitoring de son intégrité tout au long du cycle de vie.

Les workloads de nœuds dans le cluster sont suivis et gérés par le kube-scheduler. Ce service fait le suivi de la capacité et des ressources de nœuds et attribue des tâches aux nœuds en fonction de leur disponibilité.

Le cloud-controller-manager est un service qui est exécuté dans Kubernetes afin de l'aider à rester agnostique au cloud. Il sert de couche d'abstraction entre les API et outils d'un fournisseur cloud (volumes de stockage ou équilibreurs de charge, par exemple) et leurs homologues représentationnels dans Kubernetes.

Nœuds

Tous les nœuds dans un cluster Kubernetes doivent être configurés avec un runtime de conteneur qui est généralement Docker. Le runtime de conteneur démarre et gère les conteneurs au fur et à mesure que Kubernetes les déploie sur des nœuds dans le cluster. Vos applications (serveurs Web, base de données, serveurs d'API, etc.) sont exécutées dans les conteneurs.

Chaque nœud Kubernetes exécute un processus agent, appelé kubelet qui est responsable de la gestion de l'état du nœud : le démarrage, l'arrêt et la maintenance des conteneurs d'applications d'après les instructions du serveur maître. Le kubelet collecte les informations sur la performance et la santé à partir du nœud, des pods et des conteneurs qu'il exécute, puis partage ces informations avec le serveur maître pour l'aider à prendre des décisions de planification.

Le kube-proxy est un proxy réseau qui est exécuté sur des nœuds dans le cluster. Il fonctionne également en tant qu'équilibreur de charge pour des services exécutés sur un nœud.

L'unité de planification de base est un pod, qui est composé d'un ou de plusieurs conteneurs qui seront colocalisés sur la machine hôte, et qui peut partager des ressources. Chaque pod reçoit une adresse IP unique au sein du cluster, ce qui permet à l'application d'utiliser les ports sans aucun conflit.

Vous décrivez l'état voulu des conteneurs dans un pod via un objet YAML ou JSON appelé Pod Spec. Ces objets sont envoyés au kubelet par le biais d'un serveur d'API.

Un pod peut définir un ou plusieurs volumes (un disque local ou un réseau, par exemple) et les expose aux conteneurs dans le pod, ce qui permet à différents conteneurs de partager de l'espace de stockage. Par exemple, les volumes peuvent être utilisés quand un conteneur télécharge du contenu et qu'un autre transfère ce contenu ailleurs. Les conteneurs dans les pods étant souvent éphémères, Kubernetes propose un type d'équilibreur de charge, appelé service, afin de simplifier l'envoi de requêtes à un groupe de pods. Un service cible un ensemble logique de pods sélectionné d'après les étiquettes (voir l'explication plus bas). Par défaut, les services sont accessibles seulement à partir du cluster, mais vous pouvez aussi activer l'accès public si vous voulez qu'ils puissent recevoir des requêtes en dehors du cluster.

Déploiements et répliques

Un déploiement est un objet YAML qui définit les pods et le nombre d'instances de conteneurs, appelées répliques, pour chaque pod. Vous définissez le nombre de répliques que vous voulez exécuter dans le cluster avec un ReplicaSet, qui fait partie de l'objet de déploiement. Par exemple, si un nœud exécutant un pod meurt, le jeu de répliques garantit qu'un autre pod est programmé sur un autre nœud disponible.

Un DaemonSet déploie et exécute un démon spécifique (dans un pod) sur les nœuds que vous spécifiez. Les DaemonSet sont utilisés le plus souvent pour assurer des services ou la maintenance des pods. Par exemple, c'est avec un DaemonSet que New Relic Infrastructure obtient que l'agent Infrastructure soit déployé sur tous les nœuds dans un cluster.

Namespaces

Les namespaces vous permettent de créer des clusters virtuels sur un cluster physique. Ils sont prévus pour être utilisés dans des environnements ayant un grand nombre d'utilisateurs éparpillés entre plusieurs équipes ou projets. Ils attribuent des quotas de ressource et isolent logiquement les ressources des clusters.

Libellés

Les libellés sont des paires clé/valeur que vous pouvez attribuer aux pods et à d'autres objets dans Kubernetes. Ils permettent aux opérateurs Kubernetes d'organiser et de sélectionner un sous-ensemble d'objets. Par exemple, lors du monitoring d'objets Kubernetes, les libellés vous permettent de rapidement descendre dans la hiérarchie jusqu'à l'information qui vous intéresse.

StatefulSets et volumes de stockage persistants

StatefulSets vous permet d'attribuer des identifiants uniques aux pods si vous devez les déplacer vers d'autres nœuds, de maintenir le réseau entre les pods, ou de conserver les données entre eux. De même, les volumes de stockage persistants fournissent des ressources de stockage pour un cluster auxquelles les pods peuvent demander accès au moment de leur déploiement.

Autres composants utiles

Les composants Kubernetes suivants sont utiles, mais ne sont pas requis pour la fonctionnalité Kubernetes normale :

DNS Kubernetes

Kubernetes fournit ce mécanisme pour la découverte de services DNS entre des pods. Ce serveur DNS fonctionne en plus de tout autre serveur DNS que vous utilisez dans votre infrastructure.

Logs au niveau des clusters

Si vous utilisez un outil de consignation des logs, vous pouvez l'intégrer à Kubernetes pour extraire et stocker les logs d'applications et de systèmes au sein d'un cluster pour des sorties et erreurs standard. Si vous voulez utiliser les logs au niveau du cluster, il est important de noter que Kubernetes ne fournit pas de stockage de logs natifs ; vous devez disposer de votre propre solution de stockage.

Helm : la gestion des applications Kubernetes

Helm est un registre de gestion de paquets d'application pour Kubernetes, tenu à jour par la CNCF. Les graphiques de Helm sont des ressources d'applications préconfigurées que vous pouvez télécharger et déployer dans votre environnement Kubernetes. Selon une enquête réalisée en 2020 par la CNCF, 63 % des participants ont indiqué que Helm était leur outil de gestion des packages préféré pour les applications Kubernetes. Les graphiques de Helm peuvent aider les équipes DevOps à vraiment prendre de la vitesse pour la gestion des applications dans Kubernetes. Cela leur permet d'utiliser les graphiques existants et de les partager, de créer de nouvelles versions, et de les déployer dans leurs environnements de développement et de production.

Kubernetes et Istio : un duo très apprécié

Dans une architecture de microservices comme celles qui tournent dans Kubernetes, une maille de service est une couche d'infrastructure qui permet à vos instances de service de communiquer les unes avec les autres. La maille de service vous permet également de configurer comment vos instances de service réalisent les interventions essentielles telles que la découverte de service, l'équilibrage de charge, le chiffrage des données, l'authentification et l'autorisation. Istio est une maille de service de ce type et les leaders de technologie, comme Google et IBM, suggèrent qu'ils sont de plus en plus inséparables.

L'équipe IBM Cloud, par exemple, utilise Istio pour remédier aux problèmes de contrôle, de visibilité et de sécurité rencontrés pendant le déploiement de Kubernetes à très grande échelle. Plus particulièrement, Istio aide IBM à :

• Connecter les services les uns aux autres et contrôler le trafic
• Sécuriser les interactions entre les microservices avec des politiques d'autorisation et d'authentification flexibles
• Fournir un point de contrôle afin qu'IBM puisse gérer les services en production
• Observer ce qui se passe dans leurs services, via un adaptateur qui envoie les données d'Istio à New Relic, ce qui lui permet de monitorer les données de performance des microservices à partir de Kubernetes parallèlement aux données d'applications qui sont déjà en train d'être collectées.

Les défis de l'adoption de Kubernetes

La plateforme Kubernetes a clairement évolué depuis sa première version. Toutefois, ce type de croissance rapide entraîne aussi des difficultés occasionnelles. Voici quelques-uns des défis que présente l'adoption de Kubernetes :

1. Le paysage technologique Kubernetes peut prêter à confusion. Si les développeurs adorent les technologies open source comme Kubernetes pour la rapidité potentielle de l'innovation qu'elles proposent, il arrive aussi parfois qu'un nombre trop important d'innovations crée une certaine confusion (surtout lorsque le code Kubernetes central va plus vite que la capacité des utilisateurs à suivre son développement). Ajoutez à cela une pléthore de plateformes et de fournisseurs de services gérés, et les nouveaux venus peuvent avoir beaucoup de mal à se retrouver dans ce paysage qui ne cesse de changer.

2. Les équipes Dev et IT qui regardent vers l'avenir ne sont pas toujours en accord avec les priorités de l'entreprise. Lorsque les budgets sont attribués pour assurer un statu quo, les équipes peuvent avoir du mal à obtenir des fonds pour expérimenter avec les différentes initiatives d'adoption de Kubernetes, car celles-ci peuvent prendre beaucoup de temps et exiger d'importantes ressources en personnel.En outre, les équipes IT ont souvent tendance à vouloir éviter tout risque et évoluent lentement.

3. Les équipes sont toujours en phase d'acquisition des compétences requises pour utiliser Kubernetes. Ce n'est qu'au cours des quelques dernières années que les développeurs et les équipes d'opérations IT ont dû modifier leurs pratiques pour adopter les conteneurs. Aujourd'hui, elles doivent en plus adopter l'orchestration des conteneurs.Les entreprises qui souhaitent adopter Kubernetes doivent embaucher des professionnels qui peuvent non seulement programmer, mais aussi gérer les opérations et comprendre l'architecture, le stockage, et les workflows de données des applications.

4. Kubernetes peut être difficile à gérer. Vous pouvez facilement trouver des témoignages cauchemardesques sur Kubernetes dans le référentiel GitHub Kubernetes Failure Stories (vous y verrez tout : des pannes DNS aux « défaillances et échecs en cascade de systèmes distribués »).

Les meilleures pratiques Kubernetes

Optimisez votre infrastructure Kubernetes pour les performances, la fiabilité, la sécurité et la scalabilité en suivant les meilleures pratiques ci-dessous :

1. Demandes de ressources et limites : définissez les demandes de ressources et les limites pour les conteneurs. Les demandes indiquent le minimum requis pour les ressources, tandis que les limites empêchent les conteneurs d'utiliser trop de ressources. Ceci garantit l'allocation équitable des ressources et empêche leur contention.
2. Probes de vivacité et de préparation : mettez en service les sondes (probes) de vivacité (liveness) et de préparation (readiness) dans vos conteneurs. Les liveness probes déterminent si un conteneur est exécuté et les readiness probes indiquent quand un conteneur est prêt à servir le trafic. Les probes correctement configurées améliorent la fiabilité de l'application.
3. Gestion des secrets : utilisez les secrets Kubernetes pour stocker les informations sensibles telles que les mots de passe et les clés d'API. Évitez les secrets codés en dur dans des fichiers de configuration ou des images Docker pour améliorer la sécurité.
4. Politiques réseau : implémentez les politiques réseau pour contrôler la communication entre les pods. Les politiques réseau aident à définir les règles pour le trafic entrant et sortant, ce qui améliore la sécurité des clusters.
5. RBAC (contrôle d'accès basé sur les rôles) : mettez en place le RBAC afin de restreindre l'accès aux clusters. Définissez les rôles et les role bindings pour fournir les privilèges minimums nécessaires aux utilisateurs et services, afin d'améliorer la sécurité.
6. Infrastructure immuable : traitez votre infrastructure comme si elle était immuable. Évitez d'apporter des changements directement sur les conteneurs en cours d'exécution. Redéployez plutôt avec les modifications nécessaires. L'infrastructure immuable simplifie la gestion et réduit le risque de dérive de la configuration.
7. Sauvegarde et reprise après sinistre : sauvegardez régulièrement les données et les configurations critiques. Implémentez les plans de reprise après sinistre pour restaurer votre cluster en cas de défaillance. 
8. Autoscaling horizontal des pods (HPA) : utilisez l'autoscaling horizontal des pods pour ajuster automatiquement le nombre de pods dans un déploiement basé sur l'utilisation du CPU ou les métriques personnalisées. HPA garantit une utilisation des ressources optimales et des performances des applications.
9. Monitoring et logging : définissez les solutions de monitoring et de logging pour gagner des informations précieuses sur la santé des clusters et le comportement des applications.

New Relic peut prendre en charge votre parcours avec Kubernetes

Vous devez bien comprendre la performance de vos clusters et workloads, et vous devez le faire rapidement et facilement. Avec New Relic, vous pouvez résoudre les problèmes plus rapidement en analysant tous vos clusters dans une seule interface utilisateur, sans devoir changer le code, redéployer vos applications, ni subir de longues procédures de standardisation avec vos équipes. Auto-telemetry with Pixie vous apporte une visibilité instantanée dans vos clusters et workloads Kubernetes en quelques minutes.

L'explorateur de cluster Kubernetes fournit un seul et même endroit pour l'analyse de toutes vos entités Kubernetes : nœuds, namespaces, déploiements, ReplicaSets, pods, conteneurs, et workloads. Chaque secteur du graphique représente un nœud et chaque hexagone un pod. Sélectionnez un pod pour analyser la performance de vos applications, y compris l'accès aux fichiers de logs.

Analysez la performance des pods et applications  

Vous pouvez également analyser les traces distribuées de l'application. En cliquant sur un span individuel, vous voyez les attributs Kubernetes associés (les pods, clusters et déploiements associés, par exemple).

Et vous pouvez obtenir des données de traçage distribuées à partir des applications exécutées dans vos clusters.

Cet article est une mise à jour de l'article original publié en juillet 2018.