Avec les services Web modernes, les utilisateurs s'attendent à ce que les applications soient disponibles 24 heures sur 24, 7 jours sur 7 et les développeurs prévoient de déployer de nouvelles versions de ces applications plusieurs fois par jour. La conteneurisation aide les progiciels à atteindre ces objectifs, en permettant aux applications d'être publiées et mises à jour de manière simple et rapide sans temps d'arrêt. Kubernetes vous aide à vous assurer que ces applications conteneurisées s'exécutent où et quand vous le souhaitez, et les aide à trouver les ressources et les outils dont elles ont besoin pour travailler. Kubernetes est une plateforme open source prête pour la production, conçue avec l'expérience accumulée de Google dans l'orchestration de conteneurs, associée aux meilleures idées de la communauté.Bien que la publication de la version la plus récente de Kubernetes ait été un peu retardée, l'équipe derrière son développement a présenté Kubernetes version 1.19, avec plusieurs mises à jour qui améliorent la préparation à la production de Kubernetes. Ces améliorations incluent la disponibilité en version stable des fonctionnalités Ingress et seccomp, des améliorations de sécurité, telles que la prise en charge de TLS 1.3, et d'autres améliorations de fonctionnalités.
« Enfin, nous sommes parvenus à Kubernetes 1.19, la deuxième version pour 2020, et de loin le cycle de sortie le plus long qui a eu une durée totale de 20 semaines. Il se compose de 34 améliorations : 10 améliorations sont passées en version stable, 15 améliorations en version bêta et 9 améliorations en version alpha.
« La version 1.19 était assez différente d'une version régulière en raison du COVID-19, des manifestations de George Floyd et de plusieurs autres événements mondiaux que nous avons vécus en tant qu'équipe de publication. En raison de ces événements, nous avons pris la décision d'ajuster notre calendrier et de donner plus de temps aux SIG, aux groupes de travail et aux contributeurs pour faire avancer les choses. Le temps supplémentaire a également permis aux gens de prendre le temps de se concentrer sur leur vie en dehors du projet Kubernetes et de s'assurer que leur bien-être mental était au bon endroit.
« Les contributeurs sont au cœur de Kubernetes, et non l'inverse. Le code de conduite de Kubernetes demande que les gens soient excellents les uns envers les autres et malgré les troubles dans notre monde, nous n'avons vu que la grandeur et l'humilité de la communauté ».
Bien que l'équipe Kubernetes ait historiquement publié quatre mises à jour par an, elle n'en publiera que trois cette année, en raison de conditions pandémiques. La version 1.19 sera probablement la dernière mise à jour de cette année civile.
Ingress et seccomp
Ingress
Ingress a été initialement introduit en tant qu'API en version bêta dans Kubernetes version 1.1. Un Ingress est un objet Kubernetes qui gère l'accès externe aux services dans un cluster, généralement du trafic HTTP. Un Ingress peut fournir un équilibrage de charge, une terminaison TLS et un hébergement virtuel basé sur un nom. Ingress (ou une entrée réseau), ajouté à Kubernetes v1.1, expose les routes HTTP et HTTPS de l'extérieur du cluster à des services au sein du cluster. Le routage du trafic est contrôlé par des règles définies sur la ressource Ingress.
Un Ingress peut être configuré pour donner aux services des URL accessibles de l'extérieur, du trafic de charge équilibrée, la terminaison SSL/TLS et un hébergement virtuel basé sur le nom. Un contrôleur d'Ingress est responsable de l'exécution de l'Ingress, généralement avec un load-balancer (équilibreur de charge), bien qu'il puisse également configurer votre routeur périphérique ou des interfaces supplémentaires pour aider à gérer le trafic.
Pour que la ressource Ingress fonctionne, un contrôleur Ingress doit être utilisé. Kubernetes prend actuellement en charge et maintient les contrôleurs GCE/GKE (Google Cloud Engine / Google Kubernetes Engine) et nginx.
Dans la version 1.19, Ingress passe en version stable et il a été ajouté aux API réseau v1. Cette mise à jour apporte des modifications clés dans les objets Ingress v1, notamment des modifications de schéma et de validation.
Seccomp
seccomp (Security Computing Mode) est également disponible en version stable dans Kubernetes version 1.19. seccomp est une fonction de sécurité du noyau Linux qui limite le nombre d'appels système que les applications peuvent effectuer. Il a été introduit pour la première fois en tant que fonctionnalité Kubernetes dans la version 1.3, mais présentait certaines limitations. Auparavant, une annotation sur un PodSecurityPolicy était requise lors de l'application des profils seccomp aux pods.
Dans cette version, seccomp introduit un nouveau champ seccompProfile ajouté aux objets pod et container securityContext. Pour assurer la rétrocompatibilité de Kubelet, les profils seccomp seront appliqués dans un ordre de priorité:
- Champ spécifique au conteneur.
- Annotation spécifique au conteneur.
- Champ à l'échelle du pod.
- Annotation à l'échelle du pod.
Le conteneur sandbox de pod est désormais également configuré avec un profil seccomp runtime/default distinct dans cette mise à jour.
Augmentation de la période de support de Kubernetes à un an
Une enquête menée début 2019 par le groupe de travail Long Term Support (LTS) a montré qu'un sous-ensemble important d'utilisateurs finaux de Kubernetes ne parvient pas à se mettre à niveau au cours de la période de support actuelle de 9 mois. Ceci, et d'autres réponses de l'enquête, suggèrent que 30 % des utilisateurs seraient en mesure de conserver leurs déploiements sur des versions prises en charge si la période de prise en charge des correctifs était étendue à 12-14 mois. L’équipe a estimé qu’une extension de cette période de support permettrait à plus de 80 % des utilisateurs d’utiliser des versions supportées, au lieu des 50-60 % qu’elle observe actuellement.
« Une période de support annuelle fournit l’élément que les utilisateurs finaux semblent souhaiter et est plus en harmonie avec les cycles de planification annuels habituels. À partir de la version 1.19 de Kubernetes, la fenêtre de support sera étendue à un an ».
Suivi de la capacité de stockage
Traditionnellement, le planificateur Kubernetes était basé sur l'hypothèse que le stockage persistant supplémentaire est disponible partout dans le cluster et a une capacité infinie. Les contraintes de topologie abordaient le premier point, mais jusqu'à présent, la planification des pods était toujours effectuée sans tenir compte du fait que la capacité de stockage restante pourrait ne pas être suffisante pour démarrer un nouveau pod.
Le suivi de la capacité de stockage, une nouvelle fonctionnalité alpha, résout ce problème en ajoutant une API pour un pilote CSI afin de signaler la capacité de stockage et utilise ces informations dans le planificateur Kubernetes lors du choix d'un nœud (une seule machine virtuelle ou physique dans un cluster Kubernetes) pour un pod. Cette fonctionnalité sert de tremplin pour la prise en charge de l'approvisionnement dynamique pour les volumes locaux et d'autres types de volumes plus limités en capacité.
Volumes éphémères génériques
Kubernetes fournit des plugins de volume dont le cycle de vie est lié à un pod et peuvent être utilisés comme espace de travail (par exemple le type de volume intégré emptydir) ou pour charger certaines données dans un pod (par exemple, la configuration intégrée et les types de volume secret, ou « volumes en ligne CSI » - un secret est un objet qui contient une petite quantité de données sensibles telles qu'un mot de passe, un jeton ou une clé).
La nouvelle fonctionnalité alpha des volumes éphémères génériques permet à tout pilote de stockage existant prenant en charge le provisionnement dynamique d'être utilisé comme volume éphémère avec le cycle de vie du volume lié au pod. Il peut être utilisé pour fournir un stockage de travail différent du disque racine, par exemple une mémoire persistante ou un disque local distinct sur ce nœud. Tous les paramètres StorageClass pour le provisionnement de volume sont pris en charge. Toutes les fonctionnalités prises en charge avec PersistentVolumeClaims sont prises en charge, telles que le suivi de la capacité de stockage, les snapshots et la restauration, et le redimensionnement du volume.
Surveillance de l'intégrité du volume CSI
La version alpha de la surveillance de l'état de CSI est publiée avec Kubernetes 1.19. Cette fonctionnalité permet aux pilotes CSI de partager des conditions de volume anormales des systèmes de stockage sous-jacents avec Kubernetes afin qu'ils puissent être signalés comme des événements sur des PVC ou des pods. Cette fonctionnalité sert de tremplin vers la détection programmatique et la résolution des problèmes de santé des volumes individuels par Kubernetes.
Prise en charge de TLS 1.3
Suite aux recommandations recueillies lors de l'audit de sécurité de l'année dernière, Kubernetes version 1.19 ajoute la prise en charge des nouveaux chiffrements TLS 1.3 qui peuvent être utilisés avec l'orchestrateur.
Présentation des débogages de nœuds
Kubernetes 1.19 introduit la commande de débogage kubectl alpha, désormais disponible en alpha. Cette commande créera et exécutera un nouveau pod dans les espaces de noms du système d'exploitation hôte pour déboguer les nœuds. Les utilisateurs peuvent désormais inspecter un pod en cours d'exécution sans avoir à le redémarrer. En outre, les utilisateurs n'ont plus à entrer dans le conteneur lui-même pour vérifier les systèmes ou lancer des opérations telles que les utilitaires de débogage ou les demandes réseau initiales à partir de l'espace de noms réseau du pod. Cette amélioration élimine la dépendance à SSH pour la maintenance et le débogage des nœuds.
Autres modifications et dépréciations
Dans un esprit d'inclusivité, Kubernetes 1.19 inclut également des changements dans la terminologie qu'il utilise pour refléter un langage plus inclusif, en remplaçant la liste blanche par une liste d'autorisation par exemple.
Une modification supplémentaire a été apportée à la répartition de topologie de pod, qui pondère automatiquement les topologies et applique une meilleure différenciation entre les nœuds et les zones pour obtenir des résultats plus équilibrés entre les contraintes. Cette fonctionnalité a été publiée en version bêta dans la version 1.18 pour créer des définitions simples pour des dispositions de pod complexes. En outre, la fonctionnalité Immutable Secrets et ConfigMaps, également introduite dans la version 1.18, passe en bêta sur la version 1.19.
Hyberkube est désormais obsolète et ne sera plus construit par le projet Kubernetes à l'avenir. Quelques anciennes versions d'API bêta sont également obsolètes dans la version 1.19. Ils devraient être supprimés dans la version 1.22, qui pourrait devenir une version de rupture pour de nombreux utilisateurs.
Source : note de version