Discussion :

[Stéphane le calme]

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:

1. Répondre aux demandes des clients finaux (frontend).
2. Traiter les données fournies par les clients (ce qui inclut l'exécution d'opérations gourmandes en CPU comme map-Reduce)
3. 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

[Stéphane le calme]

Kubernetes 1.19 est disponible. Cette version propose l'API Ingress en version stable, prend en charge de TLS 1.3
et marque le début d'une période de support désormais étendue à un an

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

[Stéphane le calme]

La plateforme d'orchestration de containers Kubernetes passe en version 1.20 qui signe l'arrivée en bêta de Kubectl Debug,
mais aussi l'abandon de Dockershim

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é.

L'équipe responsable de son développement a annoncé la disponibilité de Kubernetes 1.20, la troisième et dernière version Kubernetes de 2020. Cette version comprend 42 améliorations : 11 améliorations sont passées à la version stable, 15 améliorations sont en train de passer à la version bêta et 16 améliorations entrent en version alpha.

Principales améliorations et nouveautés

Volume Snapshot Operations passe en version stable

Cette fonctionnalité offre un moyen standard de déclencher des opérations de snapshot de volume et permet aux utilisateurs d'incorporer des opérations de snapshot de manière portable sur n'importe quel environnement Kubernetes et fournisseurs de stockage pris en charge.

De plus, ces primitives de snapshot Kubernetes agissent comme des blocs de construction de base qui permettent de développer des fonctionnalités d'administration de stockage avancées de niveau entreprise pour Kubernetes, y compris des solutions de sauvegarde au niveau des applications ou des clusters.

Notez que la prise en charge des snapshots nécessite que les distributeurs Kubernetes regroupent le contrôleur Snapshot, les CRD Snapshot et le webhook de validation. Un pilote CSI prenant en charge la fonctionnalité de snapshot doit également être déployé sur le cluster.

Kubectl Debug passe en bêta

Kubernetes 1.19 a introduit la commande kubectl alpha debug en alpha. Cette commande crée et exécute un nouveau pod dans les espaces de noms du système d'exploitation hôte pour déboguer les nœuds. Grâce à elle, les utilisateurs peuvent 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.

Dans Kubernetes 1.20, kubectl alpha debug passe en version bêta et devient kubectl debug. Cette fonctionnalité prend en charge les flux de travail de débogage courants directement à partir de kubectl. Les scénarios de dépannage pris en charge dans cette version de kubectl incluent :

• La résolution des problèmes avec les charges de travail qui se bloquent au démarrage en créant une copie du pod qui utilise une image ou une commande de conteneur différente.
• La résolution des problèmes de conteneurs sans distraction en ajoutant un nouveau conteneur avec des outils de débogage, soit dans une nouvelle copie du pod, soit à l'aide d'un conteneur éphémère. (Les conteneurs éphémères sont une fonctionnalité alpha qui n'est pas activée par défaut.)
• Résolvez les problèmes sur un nœud en créant un conteneur s'exécutant dans les espaces de noms de l'hôte et avec accès au système de fichiers de l'hôte.

Notez qu'en tant que nouvelle commande intégrée, kubectl debug a la priorité sur tout plugin kubectl nommé «debug». Vous devez renommer le plugin concerné. Les invocations utilisant kubectl alpha debug sont désormais obsolètes et seront supprimées dans une version ultérieure.

Passage en bêta de l'API Priority and Fairness

Proposée dès la version Kubernetes 1.18, Kubernetes active désormais par défaut l'API Priority and Fairness (APF). Cela permet à kube-apiserver de classer les demandes entrantes par niveaux de priorité.

Alpha avec mises à jour: IPV4 / IPV6

La double pile IPv4 / IPv6 a été réimplémentée pour prendre en charge les services à double pile en fonction des commentaires des utilisateurs et de la communauté. Cela permet aux adresses IP de cluster de services IPv4 et IPv6 d'être attribuées à un seul service, et permet également à un service de passer d'une pile IP unique à une pile IP double et vice versa.

GA : limitation PID de processus pour la stabilité

Les identifiants de processus (Process ID ou pids) sont une ressource fondamentale sur les hôtes Linux. Il est trivial d'atteindre la limite de tâches sans atteindre aucune autre limite de ressources et provoquer une instabilité sur une machine hôte.

Les administrateurs ont besoin de mécanismes pour garantir que les pods utilisateur ne peuvent pas induire d'épuisement pid qui empêche les démons hôtes (runtime, kubelet, etc.) de s'exécuter. En outre, il est important de s'assurer que les pids sont limités entre les pods afin de garantir qu'ils ont un impact limité sur les autres charges de travail sur le nœud. Après avoir été activé par défaut pendant un an, SIG Node passe en GA les limites PID sur SupportNodePidsLimit (isolation PID nœud à pod) et SupportPodPidsLimit (capacité à limiter les PID par pod).

Changements majeurs

Abandon de Dockershim

Dockershim, le CRI (Container Runtime Interface) shim pour Docker est obsolète. La prise en charge de Docker est obsolète et sera supprimée dans une prochaine version. Les images produites par Docker continueront de fonctionner dans votre cluster avec tous les environnements d'exécution compatibles CRI, car les images Docker suivent la spécification d'image Open Container Initiative (OCI).

En clair, Docker, en tant que runtime sous-jacent, est déprécié au profit des runtimes CRI. Les images produites par Docker continueront à fonctionner dans votre cluster comme elles l'ont toujours fait.

Gestion du délai d'expiration de la sonde d'exécution

Un bogue de longue date concernant les délais d'expiration des sondes d'exécution qui peuvent avoir un impact sur les définitions de pod existantes a été corrigé. Avant ce correctif, le champ timeoutSeconds n'était pas respecté pour les sondes d'exécution. Au lieu de cela, les sondes s'exécuteraient indéfiniment, même après leur échéance configurée, jusqu'à ce qu'un résultat soit renvoyé. Avec cette modification, la valeur par défaut de 1 seconde sera appliquée si une valeur n'est pas spécifiée et les définitions de pod existantes peuvent ne plus être suffisantes si une sonde prend plus d'une seconde. Une porte de fonctionnalité, appelée ExecProbeTimeout, a été ajoutée avec ce correctif qui permet aux opérateurs de cluster de revenir au comportement précédent, mais elle sera verrouillée et supprimée dans les versions ultérieures. Afin de revenir au comportement précédent, les opérateurs de cluster doivent définir cette porte de fonctionnalité sur false.

Source : Kubernetes

Voir aussi :

Capgemini organise un webinaire gratuit pour partager son expérience sur le Cloud et le cluster Kubernetes, les inscriptions sont ouvertes
Canonical introduit Micro-Kubernetes à haute disponibilité, un cluster Kubernetes léger pour les postes de travail, les appareils IdO et l'Edge Computing
Kubernetes 1.19 est disponible. Cette version propose l'API Ingress en version stable, prend en charge de TLS 1.3 et marque le début d'une période de support désormais étendue à un an
Amazon annonce que l'outil AWS Controllers for Kubernetes est disponible en version developer preview, il devrait faciliter la gestion des services AWS directement à partir de Kubernetes