Hier, 25 mars, la prochaine version de Kubernetes - 1.18. Selon la tradition de notre blog, nous parlons des changements les plus importants dans la nouvelle version.
Les informations utilisées pour préparer ce matériel sont tirées de l'annonce officielle, du tableau de suivi des améliorations de Kubernetes , de CHANGELOG-1.18 , des avis de SUSE et de Sysdig , ainsi que des problèmes connexes, des demandes d'extraction, des propositions d'amélioration de Kubernetes (KEP) ...La version Kubernetes 1.18 a reçu son logo officiel, dont l'essence se résume à comparer le projet avec le Grand collisionneur de hadrons. Comme le LHC, qui est le résultat du travail de milliers de scientifiques du monde entier, Kubernetes a réuni des milliers de développeurs de centaines d'organisations, et tous travaillent sur une cause commune: "l'amélioration du cloud computing sous tous ses aspects".
Pendant ce temps, les passionnés de l'équipe SUSE ont préparé un nuage de mots basé sur les notes de publication des 3412 commits effectués pour K8s 1.18. Et cela s'est avéré comme ceci:
Maintenant - sur ce qui se cache derrière ces mots, sous une forme plus compréhensible pour les utilisateurs.Planificateur
La principale innovation ici - il profile la planification (planification des profils) . Elle est liée au fait que plus les charges de travail du cluster deviennent hétérogènes, plus le besoin d'approches différentes de leur planification se fait sentir rapidement.Pour résoudre ce problème, les auteurs proposent que le planificateur utilise différentes configurations attribuées au planificateur et appelées profils. Au démarrage, kube-scheduler analyse tous les profils disponibles et les enregistre dans le registre. S'il n'y a aucun profil dans la configuration, l'option par défaut ( default-scheduler) est sélectionnée . Une fois les pods dans la file d'attente, kube-scheduler effectue leur planification en tenant compte de l'ordonnanceur sélectionné. Laplanification des politiques Sami basée sur un prédicat ( PodFitsResources, PodMatchNodeSelector,PodToleratesNodeTaintsetc.) et les priorités ( SelectorSpreadPriority, InterPodAffinityPriority, MostRequestedPriority, EvenPodsSpreadPriorityetc.). L'implémentation fournit immédiatement un système de plugins afin que tous les profils soient ajoutés via un framework spécial.Structure de configuration actuelle (sera bientôt modifiée):type KubeSchedulerConfiguration struct {
...
SchedulerName string
AlgorithmSource SchedulerAlgorithmSource
HardPodAffinitySymmetricWeight
Plugins *Plugins
PluginConfig []PluginConfig
...
}
... et un exemple de configuration:profiles:
- schedulerName: 'default-scheduler'
pluginConfig:
- name: 'InterPodAffinity'
- args:
hadPodAffinityWeight: <value>
Par la prochaine version de K8, la fonctionnalité devrait être traduite en version bêta, et après deux autres - la stabilisation. Pour plus d'informations sur les profils du planificateur, consultez le KEP approprié .Une autre innovation qui est apparue dans le statut de la version alpha est la règle par défaut pour une distribution uniforme des pods (Even Pod Spreading) . Actuellement, les règles sont définies PodSpecet attachées aux pods, et il est désormais possible de définir la configuration globale au niveau du cluster. Les détails sont en KEP .Dans le même temps, la fonctionnalité Pod Topology Spread elle-même (sa porte de fonctionnalités - EvenPodsSpread), qui permet de répartir également les pods sur un cluster multizone, a été traduite en état bêta.De plus, la stabilisation de l' expulsion basée sur les souillures a été annoncée , conçue pour ajouter des souillures aux nœuds lorsque certaines conditions se produisent. Pour la première fois, la fonctionnalité est apparue dans la version déjà éloignée de K8s 1.8 et a reçu le statut bêta en 1.13 .Vitesse de mise à l'échelle personnalisée HPA
Depuis plus d'un an, une fonctionnalité intéressante appelée Vitesse d'échelle configurable pour HPA languit dans le four à améliorations Kubernetes , c.-à-d. vitesse de zoom horizontale personnalisable. (Soit dit en passant, notre compatriote a lancé son développement .) Dans la nouvelle version, il a été amené à la première étape de l'utilisation de masse - il est devenu disponible dans la version alpha.Comme vous le savez, le Pod Pod Autoscaler horizontal (HPA) dans Kubernetes met à l'échelle le nombre de pods pour toute ressource qui prend en charge une sous-ressourcescaleen fonction de la consommation du processeur ou d'autres mesures. Une nouvelle fonctionnalité vous permet de contrôler la vitesse à laquelle cette mise à l'échelle se produit, et dans les deux sens. Jusqu'à présent, il a été possible de le réguler de manière très limitée (voir, par exemple, le paramètre global pour le cluster --horizontal-pod-autoscaler-downscale-stabilization-window).La principale motivation pour introduire une vitesse de mise à l'échelle personnalisée est la possibilité de séparer les charges de travail du cluster en fonction de leur importance pour l'entreprise, permettant à une application (qui traite le trafic le plus critique) d'avoir une vitesse d'augmentation maximale en taille et une faible vitesse de cumul (car une nouvelle rafale de charge peut se produire), et pour d'autres - évoluer selon d'autres critères (pour économiser de l'argent, etc.).Solution proposée - Objet ajouté pour les configurations HPAbehavior, vous permettant de définir des règles pour contrôler la mise à l'échelle dans les deux directions ( scaleUpet scaleDown). Par exemple, la configuration:behavior:
scaleUp:
policies:
- type: percent
value: 900%
... entraînera une augmentation de 900% du nombre de pods en cours d'exécution. Autrement dit, si l'application démarre en tant que module unique, s'il est nécessaire de la faire évoluer, elle commencera à croître de 1 → 10 → 100 → 1000. Pour d'autres exemples et détails d'implémentation, voir KEP .Noeuds
Progrès dans la prise en charge d' énormes pages ( KEP total pour la fiche ): la version alpha a implémenté la prise en charge de ces pages au niveau du conteneur et la possibilité de demander des pages de différentes tailles.Le nœud du gestionnaire de topologie ( le nœud le gestionnaire de topologie ) , conçu pour unifier l'approche de réglage fin de l'allocation des ressources matérielles aux différents composants de Kubernetes, transféré au statut bêta.Le statut de la version bêta pour avoir une idée dans une fonctionnalité K8s 1.16 PodOverhead , le mécanisme proposé de calcul des frais généraux pod'y.kubectl
Une version alpha de la commande de débogage kubectl ( son KEP ) a été ajoutée , qui a développé le concept de « conteneurs éphémères ». Ils ont d'abord été introduits dans K8s 1.16 dans le but de simplifier le débogage dans les pods. Pour ce faire, dans le bon pod, un conteneur temporaire (c'est-à-dire vivant pendant une courte période) est lancé contenant les outils nécessaires au débogage. Comme nous l'avons déjà écrit, cette commande est essentiellement identique au plug-in kubectl-debug qui existait jusqu'à présent ( sa revue ).Illustration du poste kubectl debug:% kubectl help debug
Execute a container in a pod.
Examples:
kubectl debug mypod --image=debian
kubectl debug mypod --target=myapp
Options:
-a, --attach=true: Automatically attach to container once created
-c, --container='': Container name.
-i, --stdin=true: Pass stdin to the container
--image='': Required. Container image to use for debug container.
--target='': Target processes in this container name.
-t, --tty=true: Stdin is a TTY
Usage:
kubectl debug (POD | TYPE/NAME) [-c CONTAINER] [flags] -- COMMAND [args...] [options]
Use "kubectl options" for a list of global command-line options (applies to all commands).
Une autre équipe, kubectl diff , qui est apparue pour la première fois dans K8s 1.9 et a reçu un statut bêta de 1.13, est finalement déclarée stable. Comme son nom l'indique, il vous permet de comparer les configurations de cluster. À l'occasion des fonctionnalités de stabilisation, elle est apparue le KEP , et a été mise à jour avec toute la documentation pertinente du site Kubernetes.De plus, le drapeau kubectl --dry-run ajouté support pour différentes valeurs de ( client, server, none), ce qui vous permet d' essayer d'exécuter la commande uniquement sur le côté client ou serveur. Pour sa mise en œuvre côté serveur, nous avons implémenté le support des principales équipes create,apply, patchEt d' autres.Réseaux
La ressource Ingress a commencé à passer du groupe API ( extensions.v1beta1) actuel networking.v1beta1à, suivie d'une stabilisation dans la vue v1. Une série de changements ( KEP ) sont prévus à cet effet . À l'heure actuelle - dans le cadre de la version bêta de K8s 1.18 - Ingress a reçu deux innovations importantes :- un nouveau champ
pathTypequi vous permet de déterminer par quel principe le chemin sera comparé ( Exact, Prefixou ImplementationSpecific; le dernier comportement est déterminé dans IngressClass); - une nouvelle ressource
IngressClasset un nouveau champ (immuable) Classdans la définition IngressSpecqui indique quel contrôleur implémente la ressource d'entrée. Ces modifications remplacent l'annotation kubernetes.io/ingress.class, dont l'utilisation sera déconseillée.
Pour de nombreuses fonctionnalités réseau, l'état de disponibilité a été augmenté:- le plug- in NodeLocal DNS Cache est devenu stable , ce qui améliore les performances DNS en utilisant un agent pour le cache DNS sur les nœuds de cluster;
- stable et déclaré un champ
AppProtocolqui définit le protocole d'application pour chaque port de service (ressources ServicePortet EndpointPort); - Le support IPv6 est reconnu comme suffisamment stable pour le traduire en version bêta;
- Par défaut, l' API EndpointSlices est désormais activée (dans le cadre de la version bêta) , agissant comme un remplacement plus évolutif et extensible pour les Endpoints habituels.
Installations de stockage
La version alpha fournit la base pour créer des volumes avec des données préchargées sur eux - KEP ( Generic Data Populators ). En tant qu'implémentation, il est proposé d'affaiblir la validation de champ afin que des objets de types arbitraires puissent être des sources de données. Avant de lier le volume au conteneur dans le conteneur, les droits sur tous ses fichiers sont modifiés en fonction de la valeur . Cette opération peut interrompre le travail de certaines applications (par exemple, les SGBD populaires), et prendre également beaucoup de temps (pour les gros volumes - plus de 1 To). Le nouveau champ pour vous permet de déterminer si vous souhaitez modifier le propriétaire du contenu du volume. L'implémentation actuelle est une version alpha, les détails sont enDataSourcefsGroupPermissionChangePolicyPersistentVolumeClaimVolumeSource KEP .Pour les objets Secrets, ConfigMaps un nouveau champ a été immutableajouté , les rendant immuables. En règle générale, ces objets sont utilisés dans des pods en tant que fichiers. Toute modification de ces fichiers rapidement (après environ une minute) s'applique à tous les pods qui ont monté les fichiers. Ainsi, une mise à jour infructueuse d'un secret ou de ConfigMap peut entraîner l'échec de l'application entière.Les auteurs de la fonctionnalité disent que même dans le cas de la mise à jour de l'application avec la méthode recommandée - par le biais de mises à niveau continues - il peut y avoir des échecs causés par des mises à jour infructueuses des secrets existants / ConfigMaps. De plus, le processus de mise à jour de ces objets dans les pods en cours d'exécution est compliqué en termes de performances et d'évolutivité (chaque kubelet est obligé de surveiller en permanence chaque secret / CM unique).Dans l'implémentation actuelle, il est effectué de sorte qu'après que la ressource soit marquée comme immuable, cette modification ne puisse pas être annulée. Vous devrez non seulement supprimer l'objet et le recréer, mais également recréer des pods qui utilisent le secret distant. Version - alpha, détails - KEP .Stable déclaré:Autres changements
Parmi les autres innovations de Kubernetes 1.18 (pour une liste plus complète, voir CHANGELOG ) :Changements de dépendance:- Version CoreDNS dans kubeadm - 1.6.7;
- cri-tools 1.17.0;
- CNI (Container Networking Interface) 0.8.5, Calico 3.8.4;
- La version de Go utilisée est la 1.13.8.
Qu'est-ce qui est obsolète?
- API serveur ne dessert pas l' API obsolète: toutes les ressources
apps/v1beta1et la extensions/v1beta1nécessité de passer à autre chose apps/v1, et faire attention à la ressource particulière daemonsets, deployments, replicasets, networkpolicies, podsecuritypolicies; - le point de terminaison pour les métriques n'est
/metrics/resource/v1alpha1 pas géré - maintenant à la place /metrics/resource; - tous les générateurs d'équipe ont été
kubectl run supprimés, sauf celui responsable de la génération des modules.
PS
Lisez aussi dans notre blog: