Kubernetes 1.18 est disponible et apporte la prise en charge de ContainerD sous Windows,Canonical a déjà annoncé la prise en charge de cette version
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...
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.