Découvrez comment obtenir l'observabilité Kubernetes en lisant le Guide du monitoring Kubernetes et en regardant notre session FutureStack sur Auto-telemetry with Pixie.
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 ?
Entrez dans l'ère de Kubernetes.
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, AWS, Microsoft, IBM, Intel, Cisco, et Red Hat.
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
D'accord, mais pourquoi tout cet engouement ? D'où vient la popularité de 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 passent à 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 ?
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 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 :
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 ?
Entrez dans l'ère de Kubernetes.
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, AWS, Microsoft, IBM, Intel, Cisco, et Red Hat.
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
D'accord, mais pourquoi tout cet engouement ? D'où vient la popularité de 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 passent à 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 ?
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 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 clé/valeur 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.
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 : démarrage, arrêt et 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, et 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
Kubernetes a clairement évolué au cours de ses cinq premières années. 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 que trop 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 fournisseurs de plateforme et 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 »).
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.
Étapes suivantes
Lancez-vous dès aujourd'hui en déployant Auto-telemetry with Pixie (lien pour l'UE).
Cet article est une mise à jour de l'article original publié en juillet 2018.
Les opinions exprimées sur ce blog sont celles de l'auteur et ne reflètent pas nécessairement celles de New Relic. Toutes les solutions proposées par l'auteur sont spécifiques à l'environnement et ne font pas partie des solutions commerciales ou du support proposés par New Relic. Veuillez nous rejoindre exclusivement sur l'Explorers Hub (discuss.newrelic.com) pour toute question et assistance concernant cet article de blog. Ce blog peut contenir des liens vers du contenu de sites tiers. En fournissant de tels liens, New Relic n'adopte, ne garantit, n'approuve ou n'approuve pas les informations, vues ou produits disponibles sur ces sites.