Sortie de Kubernetes 1.18, un système de gestion de clusters de conteneurs isolés

Publié lancement de la plateforme d'orchestration de conteneurs Kubernetes 1.18, permettant de gérer un cluster de conteneurs isolés en tant qu'entité unique et fournissant des mécanismes pour le déploiement, la maintenance et la mise à l'échelle des applications exécutées dans des conteneurs. Le projet a été initialement créé par Google, mais a ensuite été transféré sur une plateforme indépendante, gérée par la Linux Foundation. La plateforme se positionne comme une solution universelle développée par la communauté, non attachée à des systèmes spécifiques et capable de fonctionner avec n'importe quelles applications dans n'importe quels environnements cloud. Le code de Kubernetes est écrit en Go et est distribué sous licence Apache 2.0.

fournit des fonctions pour le déploiement et la gestion de l'infrastructure, telles que la gestion de la base de données DNS, le chargement d'équilibrage,
la distribution des conteneurs sur les nœuds du cluster (migration des conteneurs en fonction des changements de charge et des besoins en services), le contrôle de la santé au niveau des applications, la gestion des comptes, la mise à jour et la mise à l'échelle dynamique du cluster actif, sans interruption. Il est possible de déployer des groupes de conteneurs en effectuant des opérations de mise à jour et d'annulation des modifications pour l'ensemble du groupe, ainsi qu'une séparation logique du cluster en parties avec répartition des ressources. Le support de la migration dynamique des applications est disponible, pour le stockage des données desquelles peuvent être utilisés des systèmes de stockage locaux ou réseaux.

La version Kubernetes 1.18 comprend 38 modifications et améliorations, dont 15 ont été transférées au statut stable, et 11 au statut bêta. 12 nouvelles modifications sont proposées en statut alpha. Pour la préparation de cette nouvelle version, des efforts égaux ont été consacrés à la finalisation des différentes fonctionnalités et à la stabilisation des capacités expérimentales, ainsi qu'à l'ajout de nouveaux développements. Changements principaux :

• Kubectl
  • Ajouté version alpha de la commande « kubectl debug », qui facilite le débogage dans les pods, en lançant des conteneurs éphémères avec des outils de débogage.
  • Déclarée stable la commande « kubectl diff », permettant de voir ce qui changera dans le cluster si le manifeste est appliqué.
  • Retirés tous les générateurs de la commande « kubectl run », à l'exception du générateur de lancement d'un seul pod.
  • Modifié le drapeau «—dry-run», selon sa valeur (client, server et none), exécute le test de la commande du côté du client ou du serveur.
  • Code kubectl extrait dans un dépôt séparé. Cela a permis de dissocier kubectl des dépendances internes de Kubernetes et d'alléger l'importation du code dans des projets tiers.
• Ingress
  • A commencé le changement de groupe API pour Ingress vers networking.v1beta1.
  • Ajoutés de nouveaux champs :
    • pathType, permettant de spécifier la méthode de comparaison du chemin dans la requête
    • IngressClassName — remplace l'annotation kubernetes.io/ingress.class, qui a été déclarée obsolète. Ce champ spécifie le nom de l'objet spécial IngressClass
  • Ajouté l'objet IngressClass, dans lequel le nom du contrôleur d'ingress est spécifié, ainsi que ses paramètres supplémentaires et l'indicateur de son utilisation par défaut
• Service
  • Ajouté le champ AppProtocol, dans lequel il est possible d'indiquer quel protocole utilise l'application
  • Passé au statut bêta et inclus par défaut EndpointSlicesAPI, qui est un remplacement plus fonctionnel des Endpoints ordinaires.
• Réseau
  • Support IPv6 est passée au statut bêta.
• Disques persistants. La fonctionnalité suivante a été déclarée stable :
  • Clonage PVC
  • Utilisation de dispositifs bruts non réseau en tant que disques persistants
  • Support des dispositifs bruts dans CSI
  • Transmission des informations sur le pod ayant demandé la connexion du disque au pilote CSI
• Configuration de l'application
  • Dans les objets ConfigMap et Secret ajouté un nouveau champ «immutable». Définir la valeur du champ sur true empêche la modification de l'objet.
• Planificateur
  • Ajouté la possibilité de créer des profils supplémentaires pour kube-scheduler. Auparavant, il était nécessaire de lancer des planificateurs distincts supplémentaires pour mettre en œuvre des algorithmes non standard de distribution des pods, mais désormais il est possible de créer des ensembles de configurations supplémentaires pour le planificateur standard et de spécifier son nom dans le même champ du pod «.spec.schedulerName». Statut — alpha.
  • Eviction basée sur Taint déclarée stable
• Mise à l’échelle
  • Ajouté la possibilité de spécifier dans le manifeste HPA le degré d'agressivité lors de la modification du nombre de pods en cours d'exécution, c'est-à-dire d'augmenter la charge en lançant immédiatement N fois plus d'exemplaires (instance).
• Kubelet
  • Gestionnaire de topologie est passé au statut bêta. La fonction inclut la distribution NUMA, évitant ainsi une dégradation des performances sur des systèmes multi-sockets.
  • Statut bêta a reçu La fonction PodOverhead permet de spécifier dans RuntimeClass un nombre supplémentaire de ressources nécessaires au déploiement d'un pod.
  • Étendue le support de HugePages, l'isolement au niveau du conteneur a été ajouté en statut alpha et le support de plusieurs tailles de hugepages.
  • Supprimé le point de terminaison pour les métriques /metrics/resource/v1alpha1, à la place, /metrics/resource est utilisé.
• API
  • Finalisé la possibilité d'utiliser les groupes API obsolètes apps/v1beta1 et extensions/v1beta1 a été supprimée.
  • ServerSide Apply a été porté au statut bêta2. Cette amélioration déplace la manipulation des objets de kubectl vers l'API du serveur. Les auteurs de cette amélioration affirment que cela permettra de corriger de nombreuses erreurs existantes qu'il est impossible de résoudre dans la situation actuelle. Ils ont également ajouté la section « .metadata.managedFields », qui propose de conserver l'historique des modifications de l'objet, en indiquant qui, quand et quoi exactement a été modifié.
  • Déclaré stable pour l'API CertificateSigningRequest.
• Support de la plateforme Windows.
  • Le soutien pour les nœuds Windows continue de s'étendre. Des versions alpha ont été ajoutées :
    • Support de CRI-Contaierd
    • Implémentation de RuntimeClass
    • Proxy CSI
  • Le support de Group Managed Service Account a été porté au statut stable.
    • RunAsUserName
    • Une publication sur la plateforme d'orchestration des conteneurs a été publiée.

Source : opennet.ru