🥇Kubernetes 1.17 : aperçu des principales nouveautés

Hier, le 9 décembre, a eu lieu une nouvelle version de Kubernetes — 1.17. Conformément à la tradition de notre blog, nous vous présentons les changements les plus significatifs de cette nouvelle version.

Kubernetes 1.17 : aperçu des principales nouveautés

Les informations utilisées pour préparer ce document proviennent de l'annonce officielle, la table de suivi des améliorations de Kubernetes, CHANGELOG-1.17 et des problèmes correspondants, des demandes de tirage, ainsi que des propositions d'amélioration de Kubernetes (KEP). Alors, quelles sont les nouveautés ?..

Routage tenant compte de la topologie

Cela fait longtemps que la communauté Kubernetes attendait cette fonctionnalité — Routage de services conscient de la topologie. Si KEP qui a commencé en octobre 2018, et l'amélioration officielle il y a 2 ans, alors que les problèmes courants (comme sont même plus anciens de plusieurs années… ce fichier) :) L'idée générale est de permettre la mise en œuvre d'un routage « local » pour les services situés dans Kubernetes. Le terme « local » fait référence ici à « le même niveau topologique »

(niveau topologique) , qui peut être :le même nœud pour les services,

la même baie de serveurs,
la même région,
le même fournisseur de cloud,
Quelques exemples d'utilisation de cette fonctionnalité :
…

économies sur le trafic dans les installations cloud avec de nombreuses zones de disponibilité (multi-AZ) — voir.

la nouvelle illustration sur le trafic d'une région, mais à travers différents AZ dans AWS ; une latence réduite / meilleure bande passante ;
un service partitionné ayant des informations locales sur le nœud dans chaque partition ;
un déploiement de fluentd (ou similaires) sur un même nœud que les applications dont les journaux sont collectés ;
Ce type de routage, qui « connaît » la topologie, est également appelé semblable à l'affinité réseau — par analogie avec
…

l'affinité de nœud affinité de pod/anti-affinité, ou l'apparition récente de la planification de volumes consciente de la topologie Provisionnement de volumes ). Le niveau actuel de mise en œuvre (et ServiceTopologydans Kubernetes — en version alpha. Pour plus de détails sur le fonctionnement de cette fonctionnalité et comment l'utiliser, lisez l'article d'un des auteurs.

Prise en charge de la double pile IPv4/IPv6 cet article Des progrès considérables

ont été réalisés

dans une autre fonctionnalité réseau : la prise en charge simultanée de deux piles IP, qui a été présentée pour la première fois dans K8s 1.16. En particulier, la nouvelle version a apporté les modifications suivantes : dans kube-proxy,la possibilité de fonctionner simultanément en modes IPv4 et IPv6 ;

Pod.Status.PodIPs, réalisée prise en charge de l'API downward (dans le même temps, maintenant, il faut ajouter l'adresse IPv6 pour l'hôte) ;
dans prise en charge de deux piles dans est désormais (Kubernetes IN Docker) et /etc/hosts tests e2e mis à jour.
prise en charge de deux piles dans KIND (Kubernetes dans Docker) et kubeadm;
tests e2e mis à jour.

Kubernetes 1.17 : aperçu des principales nouveautés
Illustration utilisation de la double pile IPV4/IPv6 dans KIND

Progrès de CSI

Déclarée stable prise en charge des topologies pour les stockages basés sur CSI, présentée pour la première fois dans K8s 1.12.

Initiative de migration des plugins de volumes vers CSI — Migration CSI — a atteint le statut beta. Cette fonctionnalité est essentielle pour transférer les plugins de stockage existants (in-tree) vers une interface moderne (CSI, out-of-tree) sans que les utilisateurs finaux de Kubernetes ne s'en aperçoivent. Les administrateurs de clusters doivent simplement activer la migration CSI, après quoi les ressources stateful et les charges de travail existantes continueront de « fonctionner simplement »… mais maintenant avec les pilotes CSI actuels plutôt qu'avec ceux obsolètes intégrés au cœur de Kubernetes.

À l'heure actuelle, la migration pour les pilotes AWS EBS (kubernetes.io/aws-ebs) et GCE PD (kubernetes.io/gce-pd) est prête en version beta. Les prévisions pour d'autres stockages sont les suivantes :

Kubernetes 1.17 : aperçu des principales nouveautés

Nous avons parlé de la façon dont le support « traditionnel » des stockages dans K8s a évolué vers CSI dans cet article. Un article séparé est consacré à la transition de la migration CSI vers le statut beta dans le blog du projet. De plus, un autre ensemble de fonctionnalités importantes liées à CSI, ayant son origine (mise en œuvre alpha) dans K8s 1.12, a atteint le statut beta (c'est-à-dire activé par défaut) dans la version de Kubernetes 1.17 —

la création de snapshots et la restauration à partir de ceux-ci . Parmi les changements apportés à Kubernetes Volume Snapshot en vue de la version beta :la séparation du sidecar CSI external-snapshotter en deux contrôleurs,

ajout d'un secret de suppression
(deletion secret) comme annotation au contenu du snapshot du volume, nouveau finaliseur
(finalizer) pour empêcher la suppression de l'API de l'objet snapshot lorsqu'il reste des références. Au moment de la sortie de 1.17, la fonctionnalité est prise en charge par trois pilotes CSI : GCE Persistent Disk CSI Driver, Portworx CSI Driver et NetApp Trident CSI Driver. Pour en savoir plus sur sa mise en œuvre et son utilisation, vous pouvez lire dans

le blog. cet article Balises du fournisseur de cloud

Les balises qui sont automatiquement

attribuées aux nœuds et volumes créés en fonction du fournisseur de cloud utilisé , étaient disponibles dans Kubernetes en tant que version beta depuis longtemps — depuis la sortie de K8s 1.2(avril 2016 !) . Étant donné leur utilisation généralisée depuis si longtemps, les développeurs, qu'il est temps de déclarer la fonctionnalité stable (GA). ont résoluAinsi, tous ont été renommés en conséquence (par topologies) :

beta.kubernetes.io/instance-type

node.kubernetes.io/instance-type → topology.kubernetes.io/zone
failure-domain.beta.kubernetes.io/zone → failure-domain.beta.kubernetes.io/region
topology.kubernetes.io/region → topology.kubernetes.io/region

… mais restent disponibles sous leurs anciens noms (pour des raisons de compatibilité). Cependant, tous les administrateurs sont encouragés à passer aux étiquettes actuelles. Documentation pertinente K8s a été mis à jour.

Sortie structurée de kubeadm

Présenté pour la première fois sous forme d'alpha sortie structurée pour l'outil kubeadm. Formats pris en charge : JSON, YAML, modèle Go.

La motivation pour la mise en œuvre de cette fonctionnalité (selon KEP) est la suivante :

Bien que Kubernetes puisse être déployé manuellement, la norme de facto (si ce n'est de jure) pour cette opération est l'utilisation de kubeadm. Des outils de gestion de système populaires comme Terraform s'appuient sur kubeadm pour déployer Kubernetes. Les améliorations prévues dans Cluster API incluent un paquet combinable pour le démarrage de Kubernetes avec kubeadm et cloud-init.
Sans sortie structurée, même les modifications les plus innocentes peuvent casser Terraform, Cluster API et d'autres logiciels utilisant les résultats de kubeadm.

Les prochaines étapes prévoient le support (sous forme de sortie structurée) pour les commandes kubeadm suivantes :

alpha certs
config images list
init
token create
token list
upgrade plan
version

Illustration de la réponse JSON pour la commande kubeadm init -o json:

{
  "node0": "192.168.20.51:443",
  "caCrt": "sha256:1f40ff4bd1b854fb4a5cf5d2f38267a5ce5f89e34d34b0f62bf335d74eef91a3",
  "token": {
    "id":          "5ndzuu.ngie1sxkgielfpb1",
    "ttl":         "23h",
    "expires":     "2019-05-08T18:58:07Z",
    "usages":      [
      "authentication",
      "signing"
    ],
    "description": "Le token de démarrage par défaut généré par 'kubeadm init'.",
    "extraGroups": [
      "system:bootstrappers:kubeadm:default-node-token"
    ]
  },
  "raw": "Rm9yIHRoZSBhY3R1YWwgb3V0cHV0IG9mIHRoZSAia3ViZWFkbSBpbml0IiBjb21tYW5kLCBwbGVhc2Ugc2VlIGh0dHBzOi8vZ2lzdC5naXRodWIuY29tL2FrdXR6LzdhNjg2ZGU1N2JmNDMzZjkyZjcxYjZmYjc3ZDRkOWJhI2ZpbGUta3ViZWFkbS1pbml0LW91dHB1dC1sb2c="
}

Stabilisation d'autres nouveautés

En général, la sortie de Kubernetes 1.17 s'est faite sous le slogan «Stabilité». Cela a été favorisé par le fait que de nombreuses fonctionnalités en lui (leur nombre total - 14) ont reçu le statut GA. Parmi celles-ci :

la 'marquage' des nœuds selon certaines conditions (TaintNodesByCondition), apparu dans K8s 1.8;
Watch Bookmarks — un nouveau type d'événements, indiquant que tous les objets jusqu'à une certaine version (resourceVersion) avaient déjà été traités par le watch ;
valeurs par défaut (defaulting) pour les ressources personnalisées ;
espaces de noms de processus partagés entre les conteneurs dans un pod ; ScheduleDaemonSetPods
planification des pods dans un DaemonSet — à l'aide de kube-scheduler (au lieu du contrôleur DaemonSet) ; limites dynamiques
sur le nombre de volumes en fonction du type de nœud ; prise en charge des variables d'environnement
pour les noms de répertoires montés comme pour les noms de répertoires montés comme subPath;
Transfert des cœurs Kubelet dans l'API Lease spécialisée;
«protection du finaliseur» (Protection du Finaliseur) pour les équilibrages de charge (vérification des ressources appropriées du Service avant la suppression des ressources LoadBalancer);
Optimisation de kube-apiserver en performance lors de la gestion de nombreux watches surveillant des ensembles identiques d'objets, ce qui est accompli en évitant la re-sérialisation des mêmes objets pour chaque watcher.

Autres modifications

La liste complète des nouveautés dans Kubernetes 1.17, bien sûr, ne se limite pas à celles énumérées ci-dessus. Voici d'autres parmi elles (pour une liste plus complète, voir CHANGELOG):

la fonctionnalité «atteint» la version bêta présentée dans la dernière version Une publication sur la plateforme d'orchestration des conteneurs a été publiée. pour Windows;
changement similaire a atteint l'API EndpointSlice (aussi de K8s 1.16), cependant cette solution pour améliorer la performance/évolutivité de l'API Endpoint n'est pas activée par défaut;
Les pods critiques pour le fonctionnement du cluster peuvent maintenant être créés non seulement dans les espaces de noms kube-system (voir la documentation sur Limit Priority Class consumption);
une nouvelle option pour kubelet — --reserved-cpus — permet de définir explicitement une liste de CPU réservés pour le système;
pour kubectl logs présenté un nouveau drapeau --prefix, ajoutant le nom du pod et du conteneur source à chaque ligne de log;
dans label.Selector ont ajouté RequiresExactMatch;
tous les conteneurs dans kube-dns sont maintenant exécutés avec moins de privilèges;
hyperkube séparé dans un dépôt GitHub et ne sera plus inclus dans les versions de Kubernetes;
significativement amélioration de la performance de kube-proxy pour les ports non-UDP.

Changements dans les dépendances :

version de CoreDNS incluse dans kubeadm — 1.6.5;
version crictl mise à jour à v1.16.1;
CSI 1.2.0;
etcd 3.4.3;
la dernière version vérifiée de Docker a été portée à 19.03;
la version minimale de Go requise pour compiler Kubernetes 1.17 est 1.13.4.

P.S.

Lisez aussi dans notre blog :

Source : habr.com