sortie de la plateforme d'orchestration de conteneurs , qui vous permet de gérer un cluster de conteneurs isolés dans son ensemble et fournit des mécanismes de déploiement, de maintenance et de mise à l'échelle des applications exécutées dans des conteneurs. Le projet a été initialement créé par Google, mais ensuite transféré sur un site indépendant supervisé par la Linux Foundation. La plateforme se positionne comme une solution universelle développée par la communauté, non liée à des systèmes individuels et capable de fonctionner avec n'importe quelle application dans n'importe quel environnement cloud. Le code Kubernetes est écrit en Go et sous licence Apache 2.0.
Fournit des fonctions de déploiement et de gestion de l'infrastructure, telles que la maintenance de la base de données DNS, l'équilibrage de charge,
répartition des conteneurs entre les nœuds du cluster (migration des conteneurs en fonction de l'évolution de la charge et des besoins de service), contrôles de santé au niveau de l'application, gestion des comptes, mise à jour et mise à l'échelle dynamique d'un cluster en cours d'exécution, sans l'arrêter. Il est possible de déployer des groupes de conteneurs avec des opérations de mise à jour et d'annulation pour l'ensemble du groupe à la fois, ainsi qu'une division logique du cluster en parties avec répartition des ressources. Il existe un support pour la migration dynamique des applications, pour le stockage des données dont les systèmes de stockage local et de stockage en réseau peuvent être utilisés.
La version Kubernetes 1.18 comprend 38 modifications et améliorations, dont 15 ont été déplacées vers le statut stable et 11 vers le statut bêta. 12 nouveaux changements sont proposés en statut alpha. Lors de la préparation de la nouvelle version, des efforts égaux ont été déployés pour affiner diverses fonctionnalités et stabiliser les capacités expérimentales, ainsi que pour ajouter de nouveaux développements. Principaux changements :
- KubectlName
- Une version alpha de la commande "kubectl debug", qui permet de simplifier le débogage dans les pods en lançant des conteneurs éphémères avec des outils de débogage.
- la commande « kubectl diff », qui permet de voir ce qui va changer dans le cluster si vous appliquez le manifeste.
- tous les générateurs de la commande "kubectl run", à l'exception du générateur permettant d'exécuter un seul pod.
- flag « --dry-run », selon sa valeur (client, serveur et aucun), l'exécution d'essai de la commande est effectuée côté client ou serveur.
- code Kubectl vers un référentiel distinct. Cela a permis à Kubectl d'être découplé des dépendances internes de Kubernetes et a facilité l'importation de code dans des projets tiers.
- Entrée
- changement du groupe API pour Ingress en networking.v1beta1.
- nouveaux champs :
- pathType, qui vous permet de spécifier comment le chemin dans la requête sera comparé
- IngressClassName remplace l'annotation kubernetes.io/ingress.class, qui est déclarée obsolète. Ce champ précise le nom de l'objet spécial InressClass
- un objet IngressClass, qui indique le nom du contrôleur d'entrée, ses paramètres supplémentaires et le signe de son utilisation par défaut
- Service
- le champ AppProtocol, dans lequel vous pouvez spécifier le protocole utilisé par l'application
- en statut bêta et activé par défaut EndpointSlicesAPI, qui est un remplacement plus fonctionnel des points de terminaison classiques.
- Réseau
- IPv6 a été déplacé vers le statut bêta.
- Disques permanents. La fonctionnalité suivante a été déclarée stable :
- Configuration des applications
- Vers les objets ConfigMap et Secret nouveau champ "immuable". Définir la valeur du champ sur true empêche la modification de l'objet.
- Planificateur
- possibilité de créer des profils supplémentaires pour kube-scheduler. Si auparavant il était nécessaire d'exécuter des planificateurs distincts supplémentaires pour implémenter des algorithmes de distribution de pods non standard, il est désormais possible de créer des ensembles de paramètres supplémentaires pour le planificateur standard et de spécifier son nom dans le même champ de pod « .spec.schedulerName ». Statut - alpha.
- déclaré stable
- Mise à l'échelle
- 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 que lorsque la charge augmente, lancer N fois plus d'instances à la fois.
- kubelet
- a reçu le statut bêta. La fonctionnalité permet l'allocation NUMA, ce qui évite la dégradation des performances sur les systèmes multisockets.
- Statut bêta Fonction PodOverhead, qui vous permet de spécifier dans RuntimeClass la quantité supplémentaire de ressources requise pour exécuter le pod.
- la prise en charge de HugePages, en statut alpha, a ajouté une isolation au niveau du conteneur et la prise en charge de plusieurs tailles de pages énormes.
- le point de terminaison pour les métriques /metrics/resource/v1alpha1, /metrics/resource est utilisé à la place
- API
- Suppression de la possibilité d'utiliser les groupes d'API obsolètes apps/v1beta1 et extensions/v1beta1.
- mis à niveau vers le statut bêta2. Cette amélioration déplace la manipulation d'objets de kubectl vers le serveur API. Les auteurs de l'amélioration affirment que cela corrigera de nombreuses erreurs existantes qui ne peuvent pas être corrigées dans la situation actuelle. Ils ont également ajouté une section « .metadata.managedFields », dans laquelle ils proposent de stocker l'historique des modifications d'objets, indiquant qui, quand et quoi exactement a changé.
- API stable de CertificateSigningRequest.
- Prise en charge de la plateforme Windows.
- La prise en charge du nœud Windows continue de s'étendre. Versions alpha ajoutées :
- Le support a été déplacé vers un statut stable
- La prise en charge du nœud Windows continue de s'étendre. Versions alpha ajoutées :
Source: opennet.ru