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 tâches qui s'exécutent jusqu'à leur terme (mieux connu sous le nom de Jobs). En raison des différences évidentes entre les types de charge de travail, certains utilisateurs ont recours à la création de clusters complets pour différents besoins. Par exemple, un cluster pour gérer l'exploration de données et un autre pour servir les API de l'application. La raison en est qu'ils ont besoin que le processus de décision diffère. Par exemple, la configuration du planificateur par défaut favorise la haute disponibilité. D'autres utilisateurs peuvent désapprouver la répartition de leurs charges de travail entre plusieurs clusters. Au lieu de cela, ils choisiraient d'installer plusieurs planificateurs sur le même cluster, chacun ayant ses propres règles de prise de décision. Cependant, avoir plusieurs ordonnanceurs dans le même cluster peut introduire des conditions de concurrence critique, où chaque ordonnanceur a une vue différente du cluster et la décision d'ordonnancement appropriée à prendre.
La fonctionnalité #1451 vous permet d'utiliser un planificateur pour le cluster, mais avec des profils différents. Chaque profil peut être référencé via le schedulerName. Les pods peuvent utiliser le schedulerName pour identifier le profil à utiliser. Mais au final, c'est le même ordonnanceur qui fait tout le travail, ce qui évite les situations de concurrence (une situation caractérisée par un résultat différent selon l'ordre dans lequel agissent les acteurs du système - généralement considéré comme un défaut, car source de panne ou de blocage).
La possibilité de définir une règle d'étalement des pods au niveau du cluster
Introduit pour la première fois dans Kubernetes 1.16, Even Pod Spreading vous a permis de vous assurer que les pods seront planifiés sur les zones de disponibilité (à condition que vous utilisiez un cluster multizone) de manière à garantir une disponibilité et une utilisation des ressources maximales. La fonctionnalité a marché en spécifiant topologySpreadConstraints, qui identifie les zones en recherchant des nœuds avec le même label topologyKey. Les nœuds avec la même étiquette topologyKey appartiennent à la même zone. Le paramètre visait à répartir les pods uniformément entre les différentes zones. Cependant, l'inconvénient est que ce paramètre doit être appliqué au niveau du pod. Les pods qui n'ont pas le paramètre de configuration ne seront pas distribués uniformément entre les domaines de défaillance.
La fonctionnalité #895 vous permet de définir des contraintes d'étalement par défaut pour les pods qui ne fournissent aucune contrainte topologySpreadConstraints. Les pods qui ont déjà ce paramètre défini remplaceront celui défini au niveau global.
Prise en charge de ContainerD sous Windows
Lorsque nous disons «Kubernetes», nous pensons presque toujours à Linux. Cependant, Microsoft Windows a pris des mesures sérieuses pour prendre en charge l'exécution de Kubernetes sur sa gamme de produits Windows Server. Ces étapes comprenaient l'ajout de la prise en charge de la version d'exécution de ContainerD 1.3. Windows Server 2019 inclut un service de conteneur hôte mis à jour (HCS v2) qui offre un contrôle accru sur la gestion des conteneurs, ce qui peut améliorer la compatibilité de l'API Kubernetes. Pourtant, la version actuelle de Docker (EE 18.09) n'est pas prête à fonctionner avec Windows HCSv2, seul ContainerD l'est. L'utilisation du runtime ContainerD permet une meilleure compatibilité entre le système d'exploitation Windows et Kubernetes, ce qui signifie que davantage de fonctionnalités seront disponibles. La fonctionnalité #1001 introduit la prise en charge de ContainerD version 1.3 pour Windows en tant qu'interface d'exécution de conteneur (CRI).
Prise en charge de RuntimeClass et des étiquettes pour plusieurs versions de Windows dans le même cluster
Étant donné que Microsoft Windows prend activement en charge diverses fonctionnalités de Kubernetes, il n'est pas rare aujourd'hui de voir des clusters mixtes qui fonctionnent sur des nœuds Linux et Windows. Le RuntimeClass a été introduit dès Kubernetes 1.12, avec des améliorations majeures introduites avec Kubernetes 1.14. Il a été utilisé pour que vous puissiez sélectionner le runtime du conteneur sur lequel les pods spécifiques doivent s'exécuter. Maintenant, avec Kubernetes 1.18, le RuntimeClass prend en charge les nœuds Windows. Ainsi, vous pouvez sélectionner des nœuds qui exécutent une génération Windows spécifique pour planifier des modules qui doivent s'exécuter uniquement sur Windows.
La possibilité d'ignorer le changement de propriété du volume
Par défaut, lorsqu'un volume est monté sur un conteneur dans un cluster Kubernetes, tous les fichiers et répertoires à l'intérieur de ce volume ont leur propriété modifiée à la valeur fournie via le fsGroup. Tout ceci pour permettre au volume d'être lisible et inscriptible par le fsGroup. Cependant, ce comportement s'est révélé indésirable dans certains cas. Par exemple:
- Certaines applications (comme les bases de données) sont sensibles aux autorisations de fichiers et aux modifications de propriété. Ces applications peuvent cesser de démarrer une fois le volume monté.
- Lorsque le volume est très grand (> 1 To) et/ou que le nombre de fichiers et de répertoires qu'il contient est énorme, les opérations chown et chmod peuvent être trop longues. Dans certains cas, elles peuvent provoquer un délai d'attente lors du démarrage du pod.
La fonctionnalité #695 fournit le paramètre FSGroupChangePolicy, qui peut être défini sur Toujours pour conserver le comportement par défaut, ou OnRootMismatch, qui déclenchera le processus de modification uniquement si les autorisations de répertoire de niveau supérieur ne correspondent pas à la valeur fsGroup.
Donner à l'utilisateur plus de possibilités dans le dépannage à l'aide du débogage Kubectl
En tant qu'utilisateur Kubernetes, lorsque vous avez besoin de visibilité sur les pods en cours d'exécution, vous êtes limité à kubectl exec et kubectl port-forward. Avec la version Kubernetes 1.18, vous disposez également de la commande de débogage kubectl. La commande vous permet de:
- Déployer un conteneur éphémère sur un pod en cours d'exécution. Les conteneurs éphémères sont de courte durée. Ils contiennent généralement les outils de débogage nécessaires. Puisqu'ils sont lancés dans le même module, ils ont accès au même réseau et système de fichiers que les autres conteneurs. Cela peut grandement vous aider à résoudre un problème ou à tracer un problème.
- Redémarrer un pod sur place avec une PodSpec modifiée. Cela vous permet de faire des choses comme changer l'image source ou les autorisations du conteneur.
- Vous pouvez même démarrer un conteneur privilégié dans l'espace de noms d'hôte. Cela vous permet de résoudre les problèmes de nœud.
Canonical annonce le support de Kubernetes 1.18
De son côté, Canonical a annoncé la prise en charge intégrale de Kubernetes 1.18 qui couvre notamment Charmed Kubernetes, MicroK8s et kubeadm. Les entreprises peuvent bénéficier des derniers ajouts pour améliorer leurs opérations quotidiennes.
« La motivation de Canonical est de donner aux entreprises les outils pour déployer et exploiter en toute transparence leurs clusters Kubernetes. Cette nouvelle version de Kubernetes débloque des capacités pour MicroK8 et Charmed Kubernetes, avec de nouveaux modules complémentaires comme Kubeflow 1.0, Multus et la prise en charge de la prochaine version Ubuntu 20.04 LTS. Nous sommes ravis de travailler avec nos clients et partenaires pour leur offrir une expérience Kubernetes inégalée », a commenté Alex Chalkias, chef de produit chez Canonical.
MicroK8s, le Kubernetes compact et simple à enclencher est adapté aux cas d'utilisation Edge et IoT comme le clustering Raspberry Pi et idéal pour les équipes DevOps qui souhaitent créer des pipelines CI/CD pour tester les applications basées sur Kubernetes. Les utilisateurs suivant la dernière piste MicroK8 stable seront automatiquement mis à niveau vers Kubernetes 1.18
Charmed Kubernetes, le Kubernetes multi-cloud de Canonical livré sur la plus large gamme de clouds, bénéficie de la prise en charge de la version préliminaire de la prochaine version 20.04 LTS. Multus, une interface réseau de conteneur (CNI), qui permet la création de plusieurs interfaces réseau virtuelles sur des pods Kubernetes est ajoutée à la liste des outils pris en charge. Les utilisateurs intéressés par les modules complémentaires CSI (Container Storage Interface) pour le stockage du système de fichiers peuvent désormais bénéficier de la prise en charge de CephFS. CIS benchmark 1.5 est également pris en charge pour les organisations qui cherchent à accroître leur sécurité et leur conformité.
Sources : Kubernetes, Canonical