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