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.Hier, l'équipe responsable de son développement a indiqué la disponibilité de Kubernetes 1.16 qui s'accompagne de 31 améliorations. Les principaux thèmes de cette version sont :
- les ressources personnalisées : les définitions de ressources personnalisées (CRD pour Custom Resource Definitions) sont largement utilisées en tant que mécanisme d'extensibilité de Kubernetes et sont disponibles en version bêta depuis la version 1.7. La version 1.16 marque leur arrivée en disponibilité générale. La définition de ressources personnalisées permet aux utilisateurs d’ajouter leurs propres objets / leurs objets personnalisés au cluster Kubernetes et de l’utiliser comme tout autre objet Kubernetes natif.
- une amélioration au niveau des métriques : Kubernetes avait déjà largement utilisé un registre de métriques global pour enregistrer les métriques à exposer. En mettant en place un registre de métriques, les métriques sont enregistrées de manière plus transparente. Auparavant, les métriques Kubernetes étaient exclues de toute exigence de stabilité.
- l'extension de volume : cette version comporte de nombreuses améliorations relatives aux volumes et aux modifications de volume. La prise en charge du redimensionnement en volume dans les spécifications CSI passe à la version bêta, ce qui permet de redimensionner tout plug-in de volume de spécification CSI.
Les CRD sont en disponibilité générale
Dans l'API Kubernetes, une ressource est un nœud final qui stocke une collection d'objets API d'un certain type. Par exemple, la ressource des pods intégrés contient une collection d’objets Pod. La distribution Kubernetes standard est livrée avec de nombreux objets / ressources API intégrés. CRD entre en scène lorsque nous voulons introduire notre propre objet dans le cluster Kubernetes afin de satisfaire pleinement nos exigences. Une fois que nous avons créé un CRD dans Kubernetes, nous pouvons l’utiliser comme tout autre objet Kubernetes natif, exploitant ainsi toutes les fonctionnalités de Kubernetes telles que son interface de ligne de commande, sa sécurité, ses services d’API, RBAC, etc.
La ressource personnalisée créée est également stockée dans le cluster etcd avec une gestion appropriée de la réplication et du cycle de vie. CRD nous permet d'utiliser toutes les fonctionnalités fournies par un cluster Kubernetes pour nos objets personnalisés et nous évite la surcharge de les implémenter nous-mêmes.
Les CRD sont devenus la base des extensions de l'écosystème de Kubernetes. Commencé comme une refonte complète du prototype ThirdPartyResources, ils ont finalement atteint la disponibilité générale dans la version Kubernetes 1.16 avec apiextensions.k8s.io/v1, à mesure que les leçons durement gagnées de l’évolution des API dans Kubernetes ont été intégrées.
« Lors de la mise à niveau vers l’API en disponibilité générale, vous remarquerez que plusieurs des rails de protection précédemment optionnels sont devenus obligatoires et/ ou ont un comportement par défaut. Des éléments tels que les schémas structurels, la taille des champs inconnus, la validation et la protection du groupe * .k8s.io sont importants pour assurer la longévité de vos API et sont maintenant beaucoup plus difficiles à manquer accidentellement. Le défaut est un autre élément important de l'évolution de l'API et ce support sera activé par défaut pour CRD.v1. La combinaison de ces éléments et des mécanismes de conversion CRD suffisent à créer des API stables qui évoluent avec le temps, de la même manière que les ressources natives de Kubernetes ont été modifiées sans que leur compatibilité avec les versions antérieures ne soit rompue.
« Les mises à jour de l'API CRD ne s'arrêtent pas là. Nous avons des idées sur des fonctionnalités telles que les sous-ressources arbitraires, la migration de groupes d’API et peut-être un protocole de sérialisation plus efficace, mais les modifications apportées ici devraient être de nature optionnelle et complémentaire à celles déjà existantes dans l’API en disponibilité générale ».
Améliorations Windows
Bêta: amélioration des options d'identité du workload pour les conteneurs Windows
La prise en charge du compte de service de groupe géré (GMSA) Active Directory passe à la version bêta et certaines annotations introduites avec la prise en charge alpha sont obsolètes. GMSA est un type spécifique de compte Active Directory qui permet aux conteneurs Windows de porter une identité sur le réseau et de communiquer avec d'autres ressources. Les conteneurs Windows peuvent désormais obtenir un accès authentifié aux ressources externes. De plus, GMSA offre une gestion automatique des mots de passe, une gestion simplifiée du nom de principal de service (SPN) et la possibilité de déléguer la gestion à d'autres administrateurs sur plusieurs serveurs.
L'équipe a également ajouté la prise en charge de RunAsUserName en tant que version alpha. RunAsUserName est une chaîne spécifiant l'identité Windows (ou le nom d'utilisateur) sous Windows pour exécuter le point d'entrée du conteneur. Elle fait partie du composant windowsOptions nouvellement introduit du securityContext (WindowsSecurityContextOptions).
Alpha: amélioration de la configuration et de la jonction de nœuds avec kubeadm
L'équipe a introduit la prise en charge en alpha de kubeadm, permettant aux utilisateurs de Kubernetes de facilement rejoindre (et réinitialiser) les nœuds de travail Windows d'un cluster existant de la même manière que pour les nœuds Linux. Les utilisateurs peuvent utiliser kubeadm pour préparer et ajouter un nœud Windows à un cluster. Une fois les opérations terminées, le nœud est à l'état Prêt et est capable d'exécuter des conteneurs Windows. En outre, l'équipe va fournir également un ensemble de scripts spécifiques à Windows pour permettre l’installation des prérequis et des CNI avant de joindre le nœud au cluster.
Alpha: introduction de la prise en charge de l'interface CSI (Container Storage Interface)
L'équipe a introduit la prise en charge de plug-in CSI pour les fournisseurs hors arborescence, permettant aux nœuds Windows d'un cluster Kubernetes d'exploiter les capacités de stockage persistant pour les charges de travail Windows. Cela élargit considérablement les options de stockage des charges de travail Windows pour le Cloud computing, en l'ajoutant à une liste comprenant des plug-ins de stockage FlexVolume et in-tree. Cette capacité est obtenue via un proxy de système d'exploitation hôte qui permet l'exécution d'opérations privilégiées sur le nœud Windows pour le compte de conteneurs.
Endpoint Slices
La version 1.16 de Kubernetes inclut une nouvelle fonctionnalité en alpha : Endpoint Slices. Celles-ci constituent une alternative évolutive et extensible aux ressources Endpoints. En coulisse, ces ressources jouent un rôle important dans le routage réseau au sein de Kubernetes. Chaque nœud final réseau est suivi au sein de ces ressources et kube-proxy les utilise pour générer des règles de proxy permettant aux pods de communiquer facilement entre eux dans Kubernetes.
Fournir une plus grande évolutivité
Un objectif clé pour les Endpoint Slices est de permettre une plus grande évolutivité des services Kubernetes. Avec les ressources Endpoint existantes, une ressource unique doit inclure des points de terminaison réseau représentant tous les pods correspondant à un service. Lorsque les services commencent à s’adapter à des milliers de pods, les ressources Endpoints correspondantes deviennent assez volumineuses. Ajouter ou supprimer un simple point endpoint d'un service à cette échelle peut s'avérer très coûteux. Au fur et à mesure que la ressource Endpoint est mise à jour, une copie complète de la ressource doit être envoyée à chaque terminal surveillant le code. Avec kube-proxy en cours d'exécution sur chaque nœud d'un cluster, une copie doit être envoyée à chaque nœud. À petite échelle, ce n'est pas un problème, mais cela devient de plus en plus évident à mesure que les clusters s'agrandissent.
À titre d’exemple simple, dans un cluster de 5 000 nœuds et d’un objet Endpoint de 1 Mo, toute mise à jour entraînerait la transmission d’environ 5 Go (une quantité suffisante pour remplir un DVD). Cela devient de plus en plus important compte tenu de la fréquence à laquelle les Endpoints peuvent changer lors d'événements tels que les mises à jour sur les déploiements.
Avec les Endpoint Slices, les points de terminaison réseau d'un service sont divisés en plusieurs ressources, ce qui réduit considérablement la quantité de données requise pour les mises à jour à grande échelle. Par défaut, les Endpoint Slices sont limitées à 100 points de terminaison chacune.
Par exemple, prenons un cluster avec 20 000 points de terminaison réseau répartis sur 5 000 nœuds. La mise à jour d'un seul point de terminaison sera beaucoup plus efficace avec les Endpoint Slices car chacune ne comprend qu'une infime partie du nombre total de points de terminaison du réseau. Au lieu de transférer un gros objet Endpoints vers chaque nœud, seul le petit segment de point de terminaison qui a été modifié doit être transféré. L'effet net est qu'environ 200 fois moins de données doivent être transférées pour cette mise à jour.
Le second objectif principal pour Endpoint Slices était de fournir une ressource hautement extensible et utile pour une grande variété de cas d'utilisation. L'un des ajouts clés avec les Endpoint Slices implique un nouvel attribut de topologie. Par défaut, les étiquettes de topologie existantes utilisées dans Kubernetes indiquant les attributs tels que la région et la zone sont renseignées. Bien sûr, ce champ peut également être rempli avec des étiquettes personnalisées pour des cas d'utilisation plus spécialisés.
Les Endpoint Slices offrent également une plus grande flexibilité pour les types d'adresses. Chacun contient une liste d'adresses. Un cas d'utilisation initial pour plusieurs adresses consisterait à prendre en charge des points de terminaison à double pile avec des adresses IPv4 et IPv6.
Source : blog Kubernetes
Voir aussi :
DigitalOcean kubernetes, un nouveau service de conteneur ouvert au public et développé par DigitalOcean Kubernetes touché par une faille critique pouvant provoquer une escalade de privilège, des correctifs sont disponibles pour le système d'orchestration Google cède le contrôle opérationnel de Kubernetes à la communauté, qui devra désormais supporter les coûts d'infrastructure cloud du projet Les cours et tutoriels pour apprendre le Cloud computing Cloud computing - le tutoriel pour débutant Le forum Cloud computing