Aujourd'hui, mercredi, prochaine version de Kubernetes - 1.16. Selon la tradition qui s'est développée pour notre blog, c'est le dixième anniversaire que nous parlons des changements les plus significatifs de la nouvelle version.
Les informations utilisées pour préparer ce matériel sont tirées de , et les problèmes associés, les demandes d'extraction et les propositions d'amélioration de Kubernetes (KEP). Alors allons-y!..
Nœuds
Un très grand nombre d'innovations notables (en version alpha) sont présentées du côté des nœuds du cluster K8s (Kubelet).
Premièrement, ce qu'on appelle «» (Conteneurs éphémères), conçu pour simplifier les processus de débogage dans les pods. Le nouveau mécanisme vous permet de lancer des conteneurs spéciaux qui démarrent dans l'espace de noms des pods existants et restent actifs pendant une courte période. Leur but est d'interagir avec d'autres pods et conteneurs afin de résoudre tout problème et de déboguer. Une nouvelle commande a été implémentée pour cette fonctionnalité kubectl debug, semblable en substance à kubectl exec: uniquement au lieu d'exécuter un processus dans un conteneur (comme dans exec) il lance un conteneur dans un pod. Par exemple, cette commande connectera un nouveau conteneur à un pod :
kubectl debug -c debug-shell --image=debian target-pod -- bashDes détails sur les conteneurs éphémères (et des exemples de leur utilisation) peuvent être trouvés dans . L'implémentation actuelle (dans K8s 1.16) est une version alpha, et parmi les critères pour son transfert vers une version bêta figure « le test de l'API Ephemeral Containers pour au moins 2 versions de [Kubernetes] ».
NB: Dans son essence et même son nom, la fonctionnalité ressemble à un plugin déjà existant dont nous . On s'attend à ce qu'avec l'avènement des conteneurs éphémères, le développement d'un plugin externe distinct cesse.
Une autre innovation - - conçu pour fournir mécanisme de calcul des frais généraux pour les pods, qui peut varier considérablement en fonction du runtime utilisé. A titre d'exemple, les auteurs aboutissent à des conteneurs Kata, qui nécessitent l'exécution du noyau invité, de l'agent kata, du système d'initialisation, etc. Lorsque les frais généraux deviennent si importants, ils ne peuvent être ignorés, ce qui signifie qu'il doit y avoir un moyen de les prendre en compte pour les quotas ultérieurs, la planification, etc. Pour le mettre en œuvre dans PodSpec champ ajouté Overhead *ResourceList (à comparer avec les données de RuntimeClass, si l'on en utilise un).
Une autre innovation notable est gestionnaire de topologie de nœud (Gestionnaire de topologie de nœud), conçu pour unifier l'approche visant à affiner l'allocation des ressources matérielles pour divers composants dans Kubernetes. Cette initiative est motivée par le besoin croissant de divers systèmes modernes (du domaine des télécommunications, de l'apprentissage automatique, des services financiers, etc.) de calcul parallèle haute performance et de minimisation des délais d'exécution des opérations, pour lesquels ils utilisent des processeurs et des processeurs avancés. capacités d’accélération matérielle. De telles optimisations dans Kubernetes ont jusqu'à présent été réalisées grâce à des composants disparates (gestionnaire de processeur, gestionnaire de périphériques, CNI), et maintenant une interface interne unique qui unifie l'approche et simplifie la connexion de nouveaux similaires - ce qu'on appelle la topologie - conscient - composants du côté Kubelet. Détails - dans .
Diagramme des composants du gestionnaire de topologie
Fonctionnalité suivante - vérifier les conteneurs pendant leur fonctionnement (). Comme vous le savez, pour les conteneurs dont le lancement est long, il est difficile d'obtenir un statut à jour : soit ils sont « tués » avant de commencer réellement à fonctionner, soit ils se retrouvent dans une impasse pendant une longue période. Nouvelle vérification (activée via une porte de fonctionnalité appelée StartupProbeEnabled) annule - ou plutôt reporte - l'effet de toute autre vérification jusqu'au moment où le pod a fini de fonctionner. Pour cette raison, la fonctionnalité s'appelait à l'origine . Pour les pods qui mettent beaucoup de temps à démarrer, vous pouvez interroger l'état à des intervalles de temps relativement courts.
De plus, une amélioration de RuntimeClass est immédiatement disponible en version bêta, ajoutant la prise en charge des « clusters hétérogènes ». C Désormais, il n'est plus du tout nécessaire que chaque nœud prenne en charge chaque RuntimeClass : pour les pods, vous pouvez sélectionner une RuntimeClass sans penser à la topologie du cluster. Auparavant, pour y parvenir - afin que les pods se retrouvent sur des nœuds prenant en charge tout ce dont ils ont besoin - il était nécessaire d'attribuer des règles appropriées à NodeSelector et aux tolérances. DANS Il présente des exemples d'utilisation et, bien sûr, des détails de mise en œuvre.
Réseau
Deux fonctionnalités réseau importantes apparues pour la première fois (en version alpha) dans Kubernetes 1.16 sont :
- double pile réseau - IPv4/IPv6 - et sa « compréhension » correspondante au niveau des pods, nœuds, services. Il inclut l'interopérabilité IPv4 vers IPv4 et IPv6 vers IPv6 entre les pods, des pods aux services externes, des implémentations de référence (au sein des plugins Bridge CNI, PTP CNI et Host-Local IPAM), ainsi qu'une compatibilité inverse avec les clusters Kubernetes en cours d'exécution. IPv4 ou IPv6 uniquement. Les détails de mise en œuvre sont disponibles .
Un exemple d'affichage d'adresses IP de deux types (IPv4 et IPv6) dans la liste des pods :
kube-master# kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE nginx-controller 1/1 Running 0 20m fd00:db8:1::2,192.168.1.3 kube-minion-1 kube-master# - Nouvelle API pour Endpoint - . Il résout les problèmes de performances/évolutivité de l'API Endpoint existante qui affectent divers composants du plan de contrôle (apiserver, etcd, endpoints-controller, kube-proxy). La nouvelle API sera ajoutée au groupe d'API Discovery et pourra servir des dizaines de milliers de points de terminaison backend sur chaque service dans un cluster composé de milliers de nœuds. Pour ce faire, chaque Service est mappé sur N objets
EndpointSlice, dont chacun par défaut n'a pas plus de 100 points de terminaison (la valeur est configurable). L'API EndpointSlice offrira également des opportunités pour son développement futur : prise en charge de plusieurs adresses IP pour chaque pod, de nouveaux états pour les points de terminaison (pas seulementReadyиNotReady), sous-ensemble dynamique pour les points de terminaison.
Celui présenté dans la dernière version a atteint la version bêta , nommé service.kubernetes.io/load-balancer-cleanup et attaché à chaque service avec le type LoadBalancer. Au moment de la suppression d'un tel service, cela empêche la suppression effective de la ressource jusqu'à ce que le « nettoyage » de toutes les ressources d'équilibrage pertinentes soit terminé.
Machines API
Le véritable « jalon de stabilisation » se situe dans le domaine du serveur API Kubernetes et de l’interaction avec celui-ci. Cela s'est produit en grande partie grâce à transférer vers un statut stable ceux qui n'ont pas besoin d'une présentation particulière (CRD), qui ont le statut bêta depuis les jours lointains de Kubernetes 1.7 (et nous sommes en juin 2017 !). La même stabilisation a été appliquée aux fonctionnalités associées :
- avec
/statusи/scalepour les ressources personnalisées ; - versions pour CRD, basées sur un webhook externe ;
- (dans K8s 1.15) valeurs par défaut (par défaut) et suppression automatique des champs (taille) pour les ressources personnalisées ;
- en utilisant le schéma OpenAPI v3 pour créer et publier la documentation OpenAPI utilisée pour valider les ressources CRD côté serveur.
Un autre mécanisme familier depuis longtemps aux administrateurs Kubernetes : - est également resté longtemps en version bêta (depuis K8s 1.9) et est désormais déclaré stable.
Deux autres fonctionnalités sont en version bêta : и .
Et la seule innovation significative de la version alpha était à partir de SelfLink — un URI spécial représentant l'objet spécifié et faisant partie de ObjectMeta и ListMeta (c'est-à-dire une partie de n'importe quel objet dans Kubernetes). Pourquoi l'abandonnent-ils ? La motivation d'une manière simple comme l’absence de raisons réelles (écrasantes) pour que ce domaine existe encore. Des raisons plus formelles sont d'optimiser les performances (en supprimant un champ inutile) et de simplifier le travail du serveur d'api générique, qui est obligé de gérer un tel champ d'une manière particulière (c'est le seul champ qui est défini juste avant l'objet est sérialisé). Véritable obsolescence (dans la version bêta) SelfLink se produira par Kubernetes version 1.20 et finale - 1.21.
Stockage de données
Les principaux travaux dans le domaine du stockage, comme dans les versions précédentes, sont observés dans le domaine . Les principaux changements ici étaient :
- pour la première fois (en version alpha) Prise en charge du plug-in CSI pour les nœuds de travail Windows: la manière actuelle de travailler avec le stockage remplacera également les plugins in-tree dans le noyau Kubernetes et les plugins FlexVolume de Microsoft basés sur Powershell ;
Schéma d'implémentation des plugins CSI dans Kubernetes pour Windows - occasion , introduit dans K8s 1.12, est devenu une version bêta ;
- Une "promotion" similaire (de l'alpha à la bêta) a été obtenue par la possibilité d'utiliser CSI pour créer des volumes éphémères locaux ().
Introduit dans la version précédente de Kubernetes (en utilisant le PVC existant comme DataSource pour créer un nouveau PVC) a également désormais reçu le statut bêta.
Planificateur
Deux changements notables dans la planification (tous deux en alpha) :
- - opportunité utiliser des pods au lieu d'unités d'application logiques pour une « répartition équitable » des charges (comme Deployment et ReplicaSet) et en ajustant cette distribution (en tant qu'exigence stricte ou en tant que condition souple, c'est-à-dire priorité). La fonctionnalité étendra les capacités de distribution existantes des pods prévus, actuellement limitées par les options.
PodAffinityиPodAntiAffinity, donnant aux administrateurs un contrôle plus fin en la matière, ce qui signifie une meilleure haute disponibilité et une consommation optimisée des ressources. Détails - dans . - l'utilisation de Politique BestFit в Fonction prioritaire RequestedToCapacityRatio lors de la planification des pods, ce qui permettra appliquer (« packaging in containers ») pour les ressources de base (processeur, mémoire) et étendues (comme le GPU). Pour plus de détails, voir .
Planification des pods : avant d'utiliser la politique la mieux adaptée (directement via le planificateur par défaut) et avec son utilisation (via l'extension du planificateur)
En outre, la possibilité de créer vos propres plugins de planification en dehors de l'arborescence de développement principale de Kubernetes (hors arborescence).
D'autres changements
Également dans la version Kubernetes 1.16, on peut noter initiative pour métriques disponibles dans l'ordre complet, ou plus précisément, conformément à aux instruments du K8. Ils s'appuient en grande partie sur les . Des incohérences sont apparues pour diverses raisons (par exemple, certaines métriques ont simplement été créées avant l'apparition des instructions actuelles), et les développeurs ont décidé qu'il était temps de tout ramener à une norme unique, "en accord avec le reste de l'écosystème Prometheus". La mise en œuvre actuelle de cette initiative est au statut alpha, qui sera progressivement promue dans les versions ultérieures de Kubernetes vers la version bêta (1.17) et stable (1.18).
De plus, les changements suivants peuvent être notés :
- Développement du support Windows с Utilitaires Kubeadm pour cet OS (version alpha),
RunAsUserNamepour les conteneurs Windows (version alpha), Prise en charge du compte de service géré de groupe (gMSA) jusqu'à la version bêta, monter/attacher pour les volumes vSphere. - mécanisme de compression des données dans les réponses API. Auparavant, un filtre HTTP était utilisé à ces fins, ce qui imposait un certain nombre de restrictions qui empêchaient son activation par défaut. La "Compression transparente des requêtes" fonctionne désormais : les clients envoient
Accept-Encoding: gzipdans l'en-tête, ils reçoivent une réponse compressée GZIP si sa taille dépasse 128 Ko. Les clients Go prennent automatiquement en charge la compression (envoi de l'en-tête requis), ils remarqueront donc immédiatement une réduction du trafic. (De légères modifications peuvent être nécessaires pour d'autres langues.) - faire évoluer HPA de/vers zéro pod en fonction de métriques externes. Si vous effectuez une mise à l'échelle en fonction d'objets/de métriques externes, lorsque les charges de travail sont inactives, vous pouvez automatiquement passer à 0 réplica pour économiser des ressources. Cette fonctionnalité devrait être particulièrement utile dans les cas où les travailleurs demandent des ressources GPU et où le nombre de types différents de travailleurs inactifs dépasse le nombre de GPU disponibles.
- Nouvelle cliente - — pour un accès « généralisé » aux objets. Il est conçu pour récupérer facilement les métadonnées (c'est-à-dire la sous-section
metadata) à partir des ressources du cluster et effectuez des opérations de garbage collection et de quota avec elles. - Construire Kubernetes sans fournisseurs de cloud existants (« intégrés » dans l'arborescence) (version alpha).
- Vers l'utilitaire kubeadm possibilité expérimentale (version alpha) d'appliquer des correctifs personnalisés pendant les opérations
init,joinиupgrade. En savoir plus sur l'utilisation du drapeau--experimental-kustomize, voir dans . - Nouveau point de terminaison pour apiserver - , - vous permet d'exporter des informations sur son état de préparation. Le serveur API a également désormais un indicateur
--maximum-startup-sequence-duration, vous permettant de réguler ses redémarrages. - deux fonctionnalités pour Azure déclaré stable : support (Zones de disponibilité) et (RG). De plus, Azure a ajouté :
- AAD et ADFS ;
-
service.beta.kubernetes.io/azure-pip-namepour spécifier l'adresse IP publique de l'équilibreur de charge ; - настройки
LoadBalancerNameиLoadBalancerResourceGroup.
- AWS a désormais pour EBS sous Windows et Appels d'API EC2
DescribeInstances. - Kubeadm est désormais indépendant Configuration de CoreDNS lors de la mise à niveau de la version CoreDNS.
- Binaires etcd dans l'image Docker correspondante world-executable, qui vous permet d'exécuter cette image sans avoir besoin des droits root. Aussi, image de migration etcd Prise en charge de la version etcd2.
- В passage à l'utilisation de distroless comme image de base, performances améliorées, ajout de nouveaux fournisseurs de cloud (DigitalOcean, Magnum, Packet).
- Mises à jour des logiciels utilisés/dépendants : Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.
PS
A lire aussi sur notre blog :
- «";
- «";
- «";
- «».
Source: habr.com