Kubernetes est un système open source pour automatiser le déploiement, la mise à l'échelle et la gestion des applications conteneurisées. Conçu à l'origine par Google, son développement a été confié à la fondation open source Cloud Native Computing Foundation (CNCF), ce qui a permis aujourd'hui à la technologie d'orchestration de conteneurs de gagner rapidement en maturité, grâce aux contributions des géants de la technologie (comme AWS, Oracle, IBM, Microsoft, Alibaba et VMware) et bien d'autres entreprises importantes.L’équipe responsable de son développement a annoncé la disponibilité de Kubernetes 1.18.
L’équipe a expliqué que « Kubernetes 1.18 est une version ‘fit and finish’. Un travail important a été effectué pour améliorer les fonctionnalités bêta et stables afin de garantir aux utilisateurs une meilleure expérience. Un effort égal a été fait pour ajouter de nouveaux développements et de nouvelles fonctionnalités passionnantes qui promettent d'améliorer encore plus l'expérience utilisateur. Avoir presque autant d'améliorations en alpha, bêta et stable est une grande réussite. Cela montre les efforts considérables déployés par la communauté pour améliorer la fiabilité de Kubernetes et continuer à étendre ses fonctionnalités existantes ».
Passons en revue quelques améliorations intéressantes.
La possibilité d'utiliser des jetons de compte de service comme méthode d'authentification générale
Kubernetes utilise des comptes de service pour authentifier les services au sein du cluster. Par exemple, si vous souhaitez qu'un pod gère d'autres ressources Kubernetes comme un déploiement ou un service, vous pouvez vous associer à un compte de service et créer les rôles et les liaisons de rôles nécessaires. Les comptes de service Kubernetes (KSA) envoient des jetons Web JSON (JWT) au serveur API pour s'authentifier. Cela fait du serveur API la seule source d'authentification pour les comptes de service. Alors, que se passe-t-il si l'entité doit s'authentifier auprès d'un autre service en dehors du cluster? Pour utiliser son KSA, l'authentificateur externe doit contacter le serveur API pour valider la demande. Cependant, le serveur API ne doit pas être accessible au public. Cela vous fait recourir à un système d'authentification différent pour la validation, ce qui ajoute plus de complexité. Même si le service tiers se trouve dans le cluster, où le serveur API est accessible, cela ajoute plus de charge, ce qui n'est généralement pas souhaitable. Kubernetes 1.18 offre la fonctionnalité #1393 qui permet au serveur d'API de fournir un document de découverte OpenID Connect qui contient les clés publiques du jeton en plus d'autres métadonnées. Les authentificateurs OIDC peuvent utiliser ces données pour authentifier le jeton sans avoir à se référer au serveur API au préalable.
La possibilité de configurer HPA Velocity pour des pods spécifiques
Horizontal Pod Autoscaler (HPA) est utilisé pour permettre à votre cluster Kubernetes de réagir automatiquement au trafic élevé / faible. Grâce à HPA, vous pouvez demander au contrôleur de créer plus de modules en réponse à des pics de CPU, à d'autres mesures ou à des mesures fournies par l'application. Pour l'optimisation des coûts, HPA terminera les pods en excès lorsqu'ils ne sont plus nécessaires, comme lorsqu'il n'y a plus de charge élevée. HPA augmente / diminue les pods à une vitesse configurable pour éviter la création / destruction de pods fluctuants en période instable. Cependant, actuellement, cette fonctionnalité est configurable au niveau du cluster. Dans une application de microservices typique, vous disposez souvent de services plus importants que d'autres. Supposons que vous hébergez une application Web sur Kubernetes qui effectue les tâches suivantes:
- Répondre aux demandes des clients finaux (frontend).
- Traiter les données fournies par les clients (ce qui inclut l'exécution d'opérations gourmandes en CPU comme map-Reduce)
- Traiter des données moins importantes (par exemple, archivage, nettoyage, etc.)
À partir de ce qui précède, il est clair que la tâche numéro 1 nécessite que les pods évoluent plus rapidement afin que l'application puisse gérer le trafic client accru rapidement et efficacement. De plus, ils devraient diminuer très lentement en prévision d'un autre pic de trafic proche.
La tâche numéro 2 a besoin que ses pods évoluent également très rapidement en réponse à un volume de données accru. Le traitement des données ne doit pas être retardé dans les applications critiques. Cependant, ils devraient également être réduits très rapidement, car ils consomment beaucoup de ressources qui doivent être mises à la disposition d'autres services dès qu'elles ne sont plus nécessaires.
En raison de leur importance, nous pouvons tolérer les pods appartenant aux tâches numéro 1 et 2 répondant aux faux positifs. Après tout, il est préférable de gaspiller certaines ressources au lieu de perdre des clients.
Les pods servant la tâche numéro 3 n'ont pas besoin d'arrangements spéciaux. Ils peuvent être augmentés et diminués de la manière habituelle.
Kubernetes 1.18 offre la fonctionnalité #853, qui permet de configurer le comportement de mise à l'échelle via le champ de comportement HPA. Les comportements sont spécifiés séparément pour la montée et la descente dans la section scaleUp ou scaleDown sous le champ de comportement.
Présentation des profils pour exécuter plusieurs configurations de planificateur
Pour mémoire, Kube Scheduler est le composant qui contrôle quels pods sont déployés (planifiés) sur quels nœuds. La décision du planificateur est liée à plusieurs conditions, notamment l'affinité / l'anti-affinité du nœud, les demandes et les limites configurées sur les modules, la disponibilité des ressources et des nœuds, etc.
En règle générale, il existe deux types de charges de travail dans Kubernetes: les services de longue durée (par exemple, les serveurs Web, les API, etc.) et les...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.