New Relic : Vous ne connaissez pas encore Kubernetes ? Découvrez la très populaire plateforme d'orch…

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 en créant une couche d'abstraction sur un groupe d'hôtes. 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 devenant disponibles lors de l'ajout d'un nouvel hôte au cluster
• Réalisation aisée des déploiements canary et des rollbacks

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 toutes vos équipes.

Fini le remplissage de formulaires pour demander de nouvelles machines pour 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, comme le fait Helm (voir plus bas).

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 fournissent 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 fournisseurs 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.

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 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 à ectd 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.

Tous les noeuds 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 charges pour des services exécutés sur un nœud.

L'unité de programmation 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 object 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.

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.

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.

Les étiquettes (Labels) sont des paires clé-valeur que vous pouvez attribuer aux pods et à d'autres objets dans Kubernetes. Elles 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 étiquettes vous permettent de rapidement descendre dans la hiérarchie jusqu'à l'information qui vous intéresse.

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.

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

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

Si vous utilisez un outil de consignation des logs, vous pouvez l'intégrer à Kubernetes pour extraire et stocker les logs des applications et systèmes au sein d'un cluster pour une sortie et des 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 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 favori 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.

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 technologiques actuels, comme Google et IBM, suggèrent que les deux sont de plus en plus indissociables.

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.

Kubernetes a clairement évolué depuis sa naissance il y a sept ans. 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û adapter 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 »).

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, 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.

New Relic's Kubernetes cluster explorer provides a single UI for your entire cluster.

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.

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.

Lancez-vous dès aujourd'hui en déployant Auto-telemetry with Pixie (lien pour l'Europe).