Geekly articles weekly

Kubernetes 1.17: aperçu des principales innovations

Hier 9 décembre, la prochaine version de Kubernetes - 1.17. 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.17 et des problèmes connexes, des demandes d'extraction, ainsi que des propositions d'amélioration de Kubernetes (KEP). Alors quoi de neuf? ..

Routage basé sur la topologie


Depuis longtemps, la communauté Kubernetes attend cette fonctionnalité - le routage de service prenant en charge la topologie . Si KEP est basé sur celui-ci en octobre 2018 et que l' amélioration officielle date d'il y a 2 ans, les problèmes habituels (comme celui-ci ) sont même plus anciens de quelques années ...

L'idée générale se résume à fournir la possibilité de mettre en œuvre un routage «local» pour les services situés dans Kubernetes. «Localité» dans ce cas signifie «le même niveau topologique» (niveau topologique) , qui peut être:

  • même noeud pour les services,
  • même rack de serveur
  • la même région
  • le même fournisseur de cloud
  • ...

Exemples d'utilisation d'une telle fonctionnalité:

  • économie sur le trafic dans les installations cloud avec de nombreuses zones de disponibilité (multi-AZ) - voir la dernière illustration sur l'exemple du trafic d'une région, mais différents AZ dans AWS;
  • moins de latence dans les performances / meilleur débit;
  • un service fragmenté qui a des informations de nœud local dans chaque fragment;
  • placer fluentd (ou analogues) sur un nœud avec des applications dont les journaux sont collectés;
  • ...

Ce routage, "connaissant" la topologie, est également appelé affinité de l'affinité du réseau - similaire à l' affinité du nœud , l' affinité / l'anti-affinité du pod ou la planification de volume (et l' approvisionnement de volume ) récemment prise en compte de la topologie . Le niveau d'implémentation actuel de ServiceTopology dans Kubernetes est la version alpha.

Pour plus de détails sur la façon dont la fonctionnalité est organisée et comment elle peut déjà être utilisée, lisez cet article de l'un des auteurs.

Prise en charge double pile IPv4 / IPv6


Des progrès significatifs ont été enregistrés dans une autre fonctionnalité du réseau: la prise en charge simultanée de deux piles IP, qui a été introduite pour la première fois dans K8s 1.16 . En particulier, la nouvelle version a apporté les modifications suivantes:

  • kube-proxy implémente la possibilité d'un fonctionnement simultané dans les deux modes (IPv4 et IPv6);
  • la prise en charge de l'API descendante est apparue dans Pod.Status.PodIPs (en même temps, /etc/hosts nécessite désormais l'ajout d'une adresse IPv6 pour l'hôte)
  • prise en charge de deux piles dans KIND (Kubernetes IN Docker) et kubeadm ;
  • Tests e2e mis à jour.


KIND IPV4 / IPv6 Double pile Illustration

Progrès du CSI


La prise en charge de la topologie pour les référentiels basés sur CSI, introduite pour la première fois dans K8s 1.12, a été déclarée stable .

Initiative CSI Migration Volume Plugins - Migration CSI - Bêta atteinte. Cette fonctionnalité est essentielle pour transférer les plugins existants dans l'arborescence vers une interface moderne (CSI, hors arborescence) inaperçue par les utilisateurs finaux de Kubernetes. Il suffira que les administrateurs de cluster activent la migration CSI, après quoi les ressources et charges de travail avec état existantes «fonctionneront toujours» ... mais en utilisant les pilotes CSI actuels au lieu de ceux obsolètes inclus dans le noyau Kubernetes.

Pour le moment, le statut de migration des pilotes AWS EBS ( kubernetes.io/aws-ebs ) et GCE PD ( kubernetes.io/gce-pd ) est prêt en statut bêta. Les prévisions pour les autres référentiels sont les suivantes:



Comment le support de stockage «traditionnel» dans les K8 est venu à CSI, nous en avons parlé dans cet article . Une transition vers la migration de CSI en version bêta est consacrée à une publication distincte sur le blog du projet.

De plus, le statut de la version bêta (c'est-à-dire l'inclusion par défaut) dans la version Kubernetes 1.17 a été atteint par une autre fonctionnalité importante dans le contexte de CSI, originaire de (implémentation alpha) dans K8s 1.12 - créer des instantanés et les restaurer à partir d'eux . Parmi les modifications apportées à Kubernetes Volume Snapshot sur le chemin de la version bêta:

  • diviser le snapshotter externe CSI du side-car en deux contrôleurs,
  • ajout d'un secret de suppression en tant qu'annotation au contenu de l'instantané de volume,
  • Un nouveau finaliseur pour empêcher la suppression de l'objet API d'instantané s'il reste des connexions.

Au moment de la sortie de la version 1.17, la fonction était prise en charge par trois pilotes CSI: le pilote CCE du disque persistant GCE, le pilote CSI Portworx et le pilote CSI NetApp Trident. Vous pouvez en savoir plus sur sa mise en œuvre et son utilisation dans cet article de blog.

Étiquettes de fournisseur de cloud


Les étiquettes qui sont automatiquement attribuées aux nœuds et volumes créés en fonction du fournisseur de cloud utilisé sont disponibles dans Kubernetes en version bêta depuis très longtemps - à commencer par la sortie de K8s 1.2 (avril 2016!) . Compte tenu de leur utilisation répandue depuis si longtemps, les développeurs ont décidé qu'il était temps de déclarer la fonctionnalité stable (GA).

Par conséquent, ils ont tous été renommés en conséquence (par topologie):

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

... mais toujours disponible par leurs anciens noms (pour des raisons de compatibilité descendante). Cependant, tous les administrateurs sont encouragés à passer aux étiquettes actuelles. La documentation pertinente de K8 a été mise à jour.

Kubeadm à sortie structurée


Au format alpha, la sortie structurée de l'utilitaire kubeadm est présentée pour la première fois. Formats pris en charge: JSON, YAML, Go-template.

La motivation pour implémenter cette fonctionnalité (selon KEP ) est la suivante:

Bien que Kubernetes puisse être déployé manuellement, la norme de facto (sinon de jure) pour cette opération consiste à utiliser kubeadm. Les outils de gestion de système populaires comme Terraform s'appuient sur kubeadm pour le déploiement de Kubernetes. Les améliorations planifiées de l'API de cluster incluent un package composable pour l'amorçage Kubernetes avec kubeadm et cloud-init.

Sans sortie structurée, même les changements les plus anodins à première vue peuvent casser Terraform, l'API de cluster et d'autres logiciels qui utilisent les résultats de kubeadm.

Dans un avenir proche, le support apparaît (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 à 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": "The default bootstrap token generated by 'kubeadm init'.", "extraGroups": [ "system:bootstrappers:kubeadm:default-node-token" ] }, "raw": "Rm9yIHRoZSBhY3R1YWwgb3V0cHV0IG9mIHRoZSAia3ViZWFkbSBpbml0IiBjb21tYW5kLCBwbGVhc2Ugc2VlIGh0dHBzOi8vZ2lzdC5naXRodWIuY29tL2FrdXR6LzdhNjg2ZGU1N2JmNDMzZjkyZjcxYjZmYjc3ZDRkOWJhI2ZpbGUta3ViZWFkbS1pbml0LW91dHB1dC1sb2c=" }

Stabilisation d'autres innovations


En général, la sortie de Kubernetes 1.17 a eu lieu sous la devise " Stabilité ". Cela a été facilité par le fait que tant de fonctionnalités (leur nombre total est de 14 ) ont reçu le statut GA. Parmi ceux-ci:


Autres changements


Bien entendu, la liste complète des innovations de Kubernetes 1.17 n'est pas limitée à celles répertoriées ci-dessus. En voici d'autres (et pour une liste plus complète - voir CHANGELOG ):

  • La version bêta de RunAsUserName pour Windows présentée dans la version précédente est passée à la version bêta;
  • un changement similaire est arrivé à l' API EndpointSlice (également à partir de K8s 1.16), mais jusqu'à présent, cette solution pour améliorer les performances / l'évolutivité de l'API Endpoint n'a pas été activée par défaut;
  • les pods critiques pour le fonctionnement du cluster peuvent désormais être créés non seulement dans les espaces de noms du kube-system (voir la documentation pour la consommation de classe de priorité limite pour plus de détails) ;
  • une nouvelle option pour kubelet - --reserved-cpus - vous permet de définir explicitement une liste de CPU réservés au système;
  • pour les kubectl logs un nouveau drapeau est présenté - préfixe, ajoutant le nom du pod et du conteneur source à chaque ligne du journal;
  • dans label.Selector ajouté RequiresExactMatch ;
  • tous les conteneurs dans kube-dns s'exécutent maintenant avec moins de privilèges;
  • hyperkube est alloué à un référentiel GitHub séparé et ne sera plus inclus dans les versions de Kubernetes;
  • Amélioration significative des performances du proxy de cube pour les ports non UDP.

Changements de dépendance:

  • Version CoreDNS dans kubeadm - 1.6.5;
  • version crictl mise à jour vers v1.16.1;
  • CSI 1.2.0;
  • etcd 3.4.3;
  • La dernière version testée de Docker a été mise à niveau vers 19/03;
  • la version Go minimum requise pour construire Kubernetes 1.17 est 1.13.4.

PS


Lisez aussi dans notre blog:

Source: https://habr.com/ru/post/fr476998/

More articles:


All Articles