Lundi
était censé avoir lieu officiellement
( mais jusqu'à présent, cela ne s'est pas produit ... MISE À JOUR 20/06 : l'annonce est apparue sur le blog K8s) La prochaine version de
Kubernetes est la
1.15 . Selon la tradition qui s'est développée pour 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 du
tableau de suivi des améliorations de Kubernetes , de
CHANGELOG-1.15 et des problèmes connexes, des demandes d'extraction, ainsi que des propositions d'amélioration de Kubernetes (KEP). Étant donné que la conférence KubeCon à Shanghai aura lieu la semaine prochaine, cette version a eu un cycle raccourci de 11 semaines (au lieu de 12 semaines), ce qui n'a cependant pas affecté de manière significative le nombre de changements importants. Alors allons-y! ..
Entrepôts de données
Introduction d'un
nouvel API ExecutionHook , qui vous permet d'exécuter dynamiquement des commandes utilisateur dans un pod / conteneur ou un groupe de pods / conteneurs, et avec lui le contrôleur correspondant (
ExecutionHookController ) qui implémente la gestion du cycle de vie du hook. La motivation de l'apparition de cette fonctionnalité était le désir de fournir aux utilisateurs la possibilité de créer / supprimer des instantanés conformément à la logique de l'application, c'est-à-dire exécutez toutes les commandes spécifiques à l'application avant et après la création de l'instantané. Il est supposé que ces hooks peuvent également être utiles dans d'autres situations - par exemple, effectuer des mises à jour, déboguer, mettre à jour les fichiers de configuration, redémarrer le conteneur, préparer d'autres événements comme la migration de la base de données. État actuel - version alpha (qui devrait être traduite en version bêta pour la prochaine version), détails - dans
KEP .
Dans le stockage éphémère , qui vous permet de différencier pour des pods / conteneurs spécifiques le volume d'espace partagé partagé
(stockage partagé) , la
prise en charge des quotas de système de fichiers
a été ajoutée . Ce nouveau mécanisme utilise des quotas de projet (quotas de
projet ) disponibles dans XFS et ext4, assurant le suivi de la consommation des ressources et l'imposition facultative de limites sur ceux-ci. État actuel - version alpha; les plans pour les versions futures n'ont pas encore été spécifiés.
Une autre nouvelle fonctionnalité introduite par sig-storage est l'utilisation de PVC existants en tant que
DataSource pour créer de nouveaux PVC. En d'autres termes, il s'agit d'une
implémentation de la fonction de clonage de volume . Les clones doivent être distingués des instantanés, car chaque clone est un nouveau volume «à part entière»: il est créé en tant que copie d'un volume existant, mais il suit pleinement le cycle de vie des volumes ordinaires (contrairement aux instantanés, bien qu'ils soient des copies de volumes à un certain moment, mais pas indépendants) volumes). Illustration de l'opportunité:
kind: PersistentVolumeClaim apiVersion: v1 metadata: name: pvc-2 namespace: myns spec: capacity: storage: 10Gi dataSource: kind: PersistentVolumeClaim name: pvc-1
Dans ce cas, un nouveau PV / PVC autonome ( pvc-2 ) sera créé contenant les mêmes données que sur pvc-1 . Il est indiqué que le nouveau PVC doit avoir le même espace de noms que l'original.Les limitations existantes ne prennent en charge que le provisionneur dynamique et uniquement les plugins CSI (ils doivent avoir la capacité
CLONE_VOLUME ). En savoir plus sur
KEP .
Les fonctionnalités suivantes sont passées à l'état de la version bêta (et, par conséquent, à l'activation dans les installations par défaut de Kubernetes):
- Fonction d' extension de taille de volume persistante «en ligne», c'est-à-dire sans avoir besoin de redémarrer le pod en utilisant le PVC approprié. Pour la première fois (en statut alpha), il est apparu dans K8s 1.11.
- Prise en charge des variables d'environnement pour les noms de répertoires montés en tant que
subPath , qui a été introduit pour la première fois dans K8s 1.11 et a été développé dans la dernière 1.14.
Mais le processus de migration des composants internes des anciens plug-ins pour les référentiels implémentés dans la base de code Kubernetes (dans l'arborescence) a traîné en faveur des plug-ins pour la nouvelle interface CSI. Il était prévu que la version 1.15 achève la migration de tous les plug-ins des fournisseurs de cloud, cependant, il a été
décidé de conserver le statut de la version alpha, car la fonctionnalité dépend des API introduites dans K8s 1.15 et jusqu'à présent uniquement implémentées dans la version alpha (en particulier, nous parlons d'améliorations dans la prise en charge Azure: plugins
Azure File et
Azure Disk dans csi-translation-lib).
Planificateur
Deux innovations notables - toutes deux sous forme alpha jusqu'à présent - sont disponibles dans le planificateur Kubernetes.
Le premier est le
cadre de planification (
Kubernetes Scheduling Framework ), qui est un nouvel ensemble d'API pour les plugins qui étendent les capacités d'un planificateur existant. Les plugins sont créés en dehors du référentiel principal (hors arborescence), mais sont inclus dans le planificateur lors de la compilation. Ainsi, le noyau fonctionnel de l'ordonnanceur reste aussi simple et pratique à prendre en charge que possible, et des fonctionnalités supplémentaires sont implémentées séparément, sans les nombreuses restrictions que la
manière actuelle d' étendre les fonctionnalités de l'ordonnanceur "subissait" à l'aide de webhooks.
Dans le nouveau cadre, chaque tentative de planification de pod est divisée en deux étapes:
- cycle de planification - où le nœud du pod est sélectionné,
- et liaison (cycle de liaison) - où la solution sélectionnée est implémentée au sein du cluster.
À chacune de ces étapes (ensemble, elles sont également appelées le
contexte de planification ), il existe de nombreux
points d'extension , à chacun desquels des plugins de structure peuvent être appelés.
(Cycle de vie pour appeler des plugins dans le Scheduling Framework.)Dans le cadre de la version alpha du framework, seuls les
points Reserve ,
Unreserve et
Prebind sont implémentés . En savoir plus sur cette innovation massive chez
KEP .
Le second est l'
option non préemptive pour PriorityClasses .
Les classes prioritaires ont reçu un statut stable (GA) dans la dernière version de Kubernetes, ce qui a affecté la planification et la sélection des pods: les pods sont planifiés en fonction de la priorité, et si le pod ne peut pas être créé par manque de ressources, alors les pods une priorité inférieure peut être évincée pour libérer l'espace nécessaire.
La nouvelle option -
Preempting , définie comme un booléen dans la structure
PriorityClass , signifie: si un pod attend sa planification et a
Preempting=false , sa création
ne préemptera
pas les autres pods. Ce champ apparaît dans
PodSpec pendant le processus d'
admission du
pod (similaire à la valeur
PriorityClass ). Les détails de l'implémentation sont dans
KEP .
Machines API
Pour
CustomResources , des améliorations sont présentées qui sont conçues pour implémenter pour les données stockées de cette manière (dans le cadre de JSON dans CRD) un comportement qui correspond mieux à celui généralement accepté dans l'API Kubernetes (pour les objets K8s "natifs"):
- suppression automatique des champs non spécifiés dans les schémas de validation OpenAPI - pour plus de détails, voir KEP « Elagage pour les ressources personnalisées »;
- la possibilité de définir des valeurs par défaut pour les champs dans les schémas de validation OpenAPI v3, ce qui est particulièrement important pour maintenir la compatibilité de l'API lors de l'ajout de nouveaux champs aux objets - pour plus de détails, voir KEP « Defaulting for Custom Resources ».
Les deux fonctionnalités étaient initialement prévues pour être incluses dans la sortie de K8s 1.12, mais seulement maintenant elles sont présentées en versions alpha.
Les changements dans CRD ne se sont pas limités à ceci:
- Publier la fonctionnalité CRD OpenAPI - c.-à-d. la validation CustomResources côté serveur (utilisant le schéma OpenAPI v3) introduite dans la dernière version de Kubernetes - atteint la version bêta et est désormais activée par défaut;
- Le mécanisme de conversion de version des ressources CRD basé sur des webhooks externes a également été converti en version bêta.
Une autre innovation intéressante s'appelle
Watch bookmark . Son essence se résume à ajouter un nouveau type d'événement à l'
API Watch -
Bookmark . Ce type signifie une étiquette que tous les objets jusqu'à une certaine version de la
resourceVersion ont déjà été traités par la montre. Un tel mécanisme réduira la charge sur kube-apiserver, réduisant le nombre d'événements qui doivent être traités à chaque redémarrage de la montre, ainsi que le nombre d'erreurs indésirables comme
«version de ressource trop ancienne» . Dans Kubernetes 1.15, la fonctionnalité a le statut de la version alpha et son augmentation en version bêta est attendue pour la prochaine version.
Added EventType = "ADDED" Modified EventType = "MODIFIED" Deleted EventType = "DELETED" Error EventType = "ERROR" Bookmark EventType = "BOOKMARK"
(Types d'événements possibles dans l'API Watch.)Dans les Webhooks d'admission:
- Prise en charge d'un sélecteur d'objet en plus des sélecteurs d'espace de noms existants
- implémenté la possibilité d'enregistrer une version spécifique d'une ressource et d'appeler lorsqu'une ancienne version de cette ressource est modifiée;
- Le champ
Option a été ajouté à l'API AdmissionReview, indiquant les options de l'opération en cours.
Réseau
Une innovation importante dans la partie réseau de Kubernetes est ce que l'on appelle la «
protection du finaliseur» pour les équilibreurs de charge. Avant de supprimer les ressources du LoadBalancer, il est vérifié que la ressource de service correspondante n'a pas été complètement supprimée. Pour ce faire, un soi-disant finaliseur est attaché à chaque service avec
type=LoadBalancer : lorsqu'un tel service est supprimé, la suppression réelle de la ressource est bloquée jusqu'à ce que le finaliseur soit supprimé, et le finaliseur n'est pas supprimé jusqu'à ce que "l'effacement" des ressources de l'équilibreur de charge correspondant soit terminé (
service.kubernetes.io/load-balancer-cleanup ). La version actuelle de l'implémentation est la version alpha, et des détails à ce sujet peuvent être trouvés dans
KEP .
De plus:
- Le plug- in NodeLocal DNS Cache introduit dans Kubernetes 1.13 et améliorant les performances DNS a atteint la version bêta.
- Kube-proxy ne supprime plus automatiquement les règles de réseau créées à la suite de son fonctionnement dans d'autres modes (cela nécessite le lancement explicite de
kube-proxy --cleanup ).
CLI
Comme toujours, il y avait de belles petites choses dans les commandes de la console pour travailler avec les clusters Kubernetes:
Autre
Parmi d'autres changements notables dans Kubernetes 1.15:
- La prise en charge Pod Disruption Budget (PDB) a été ajoutée pour les ressources / contrôleurs tiers basés sur CRD (par exemple: EtcdCluster, MySQLReplicaSet ...) à l'aide de la sous- ressource Scale . Jusqu'à présent, il s'agit d'une version bêta qui sera rendue stable dans la prochaine version. Les détails sont dans le KEP .
- Deux fonctionnalités pour les nœuds / Kubelet ont atteint la version bêta: la prise en charge des plugins de surveillance des appareils tiers (afin de supprimer toutes les connaissances spécifiques aux appareils de Kubelet, c'est-à-dire hors de l'arborescence) et
SupportNodePidsLimit (isolation des PID du nœud au dosettes). - La prise en charge des modules Go a été ajoutée et activée par défaut pour la base de code Kubernetes (au lieu de Godep et du mode GOPATH, qui est déconseillé).
- La prise en charge d' AWS NLB (Network Load Balancer), introduite pour la première fois dans K8s 1.9, a atteint le niveau bêta. Elle a notamment pu configurer
accessLogs , mettre fin à TLS et LoadBalancerSourceRanges . - Implémentation de la possibilité de configurer le fournisseur de cloud Azure à partir des secrets Kubernetes (pour cela, une nouvelle option
cloudConfigType a été cloudConfigType , dont l'une peut être secret ). De plus, Kubelet dans Azure peut désormais fonctionner sans identité Azure ( useInstanceMetadata doit être activé pour cela). - Dans le cycle de vie du cluster, la possibilité de créer des clusters HA à l'aide de kubeadm a été portée en version bêta, et ils ont également terminé l'étape suivante (v1beta2) en réorganisant le format du fichier de configuration kubeadm.
- Le nombre de pods en attente dans différentes files d'attente est ajouté aux métriques du planificateur et des statistiques sur les volumes via les métriques de volume de kubelet de CSI sont ajoutées.
- Mises à jour du logiciel utilisé / dépendant: Go 1.12.5, cri-tools 1.14.0, etcd 3.3.10 (la version n'a pas changé pour le serveur, mais a été mise à jour pour le client) . Les versions de CNI, CSI, CoreDNS n'ont pas changé (dans l'une des versions alpha de Kubernetes 1.15, elle a été mise à jour vers 1.5.0, mais est ensuite revenue à 1.3.1) , versions prises en charge de Docker.
PS
Lisez aussi dans notre blog: