L'équipe de développement Kubernetes a récemment publié par une annonce de la sortie de la nouvelle version "Kubernetes 1.18" dans lequel l'équipe de développement mentionne qu'il s'agit d'une version «adaptée et finie».
Dans cette nouvelle version un travail important a été fait pour améliorer la fonctionnalité bêta et stable pour garantir un meilleure expérience utilisateur. Un effort égal a été fait pour ajouter de nouveaux développements et de nouvelles fonctionnalités passionnantes qui promettent d'améliorer encore l'expérience utilisateur.
Pour ceux qui ignorent Kubernetes, ils devraient savoir que est un système open source pour automatiser la mise en œuvre, la mise à l'échelle et la gestion de applications conteneurisées.
Il était conçu à l'origine par Google, bien que son développement ait été par la suite confié à l'Open Source Cloud Computing Foundation (CNCF), qui a aujourd'hui permis à la technologie d'orchestration de conteneurs de mûrir rapidement, grâce aux apports de géants de la technologie.
Quoi de neuf dans Kubernetes 1.18?
Cette nouvelle version se distingue par la possibilité d'utiliser des jetons de compte de service comme méthode d’authentification générale. Par exemple, si vous souhaitez qu'un pod gère d'autres ressources Kubernetes, telles qu'un déploiement ou un service, il peut être associé à un compte de service et créer les rôles et les liaisons de rôle 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.
Kubernetes 1.18pfournit une fonctionnalité Quoi permet au serveur API de fournir un document de découverte OpenID Connect A contenant les clés publiques du jeton en plus d'autres métadonnées.
Un autre changement qui se démarque de Kubernetes 1.81 est le possibilité de configurer HPA Velocity pour des pods spécifiques. Un autoscaler de pod horizontal (HPA) a été utiliséa pour permettre à un cluster Kubernetes de répondre automatiquement au trafic élevé / faible. Avec HPA, l'utilisateur peut 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.
Kubernetes 1.18 a une vue d'ensemble des profils pour exécuter plusieurs configurations du planificateur. En règle générale, il existe deux types de charges de travail dans Kubernetes: les services à long terme (par exemple, les serveurs Web, les API, etc.) et les tâches qui s'exécutent jusqu'à la fin (mieux connu sous le nom de Jobs).
En raison des différences évidentes entre les types de charges 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 d'application.
La raison en est qu'ils ont besoin que le processus de décision diffère. Par exemple, les paramètres par défaut du planificateur favorisent la haute disponibilité.
D'autre part, nous pouvons également trouver le possibilité de définir une règle de diffusion de pod au niveau du cluster, Que lo a permis de garantir que les pods seront planifiés dans les zones de disponibilité (à condition que vous utilisiez un cluster multizone) pour garantir une disponibilité et une utilisation des ressources maximales.
La fonctionnalité active la spécification topologySpreadConstraints, qui identifie les zones en recherchant des nœuds avec la même balise topologyKey. Les nœuds avec la même balise TopologyKey appartiennent à la même zone. La configuration était de répartir les pods uniformément dans 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 la configuration ne seront pas répartis uniformément entre les domaines de pannes.
Enfin et surtout, nous pouvons également trouver la possibilité d'ignorer la modification de la propriété de volume. Par défaut, lorsqu'un volume est monté dans un conteneur sur un cluster Kubernetes, la propriété de tous les fichiers et répertoires de ce volume est remplacée par la valeur fournie via fsGroup.
Tout cela pour permettre à fsGroup de lire et d'écrire le volume. Cependant, ce comportement s'est avéré indésirable dans certains cas.
Cette nouvelle version de Kubernetes est livré avec un certain nombre de changements et nous n'avons mentionné que quelques-uns des plus importants. Si vous voulez connaître la liste complète, vous pouvez le faire en visitant le lien suivant