🥇Kubernetes 1.17 : tour d'horizon des principales innovations

Hier, le 9 décembre, a eu lieu prochaine version de Kubernetes - 1.17. Selon la tradition qui s'est développée pour notre blog, 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 l'annonce officielle, Tableaux de suivi des améliorations Kubernetes, JOURNAL DES CHANGEMENTS-1.17 et les problèmes associés, les demandes d'extraction et les propositions d'amélioration de Kubernetes (KEP). Alors quoi de neuf?..

Routage tenant compte de la topologie

La communauté Kubernetes attendait cette fonctionnalité depuis longtemps - Routage des services tenant compte de la topologie. Si KEP il date d'octobre 2018, et le fonctionnaire Ce renforcement — il y a 2 ans, les problèmes habituels (comme cela) - et quelques années de plus...

L'idée générale est d'offrir la possibilité d'implémenter un routage « local » pour les services résidant dans Kubernetes. « Localité » signifie dans ce cas « le même niveau topologique » (niveau de topologie), qui peut être:

nœud identique pour les services,
le même rack de serveur,
la même région
le même fournisseur de cloud,
...

Exemples d'utilisation de cette fonctionnalité :

économies sur le trafic dans les installations cloud avec plusieurs zones de disponibilité (multi-AZ) - voir. illustration fraîche en utilisant l'exemple du trafic provenant de la même région, mais de zones de disponibilité différentes dans AWS ;
latence de performance inférieure/meilleur débit ;
un service partitionné qui contient des informations locales sur le nœud dans chaque partition ;
placement de fluentd (ou analogues) sur le même nœud avec les applications dont les journaux sont collectés ;
...

Un tel routage, qui « connaît » la topologie, est également appelé affinité réseau - par analogie avec affinité de nœud, affinité/anti-affinité des pods ou est apparu il n'y a pas si longtemps Planification de volumes tenant compte de la topologie (et Approvisionnement en volume). Niveau actuel de mise en œuvre ServiceTopology dans Kubernetes - version alpha.

Pour plus de détails sur le fonctionnement de la fonctionnalité et comment vous pouvez déjà l'utiliser, lisez cet article d'un des auteurs.

Prise en charge de la double pile IPv4/IPv6

Progrés significatif fixé dans une autre fonctionnalité réseau : la prise en charge simultanée de deux piles IP, introduite pour la première fois dans K8 1.16. En particulier, la nouvelle version a apporté les changements suivants :

dans Kube-Proxy mis en œuvre possibilité de fonctionnement simultané dans les deux modes (IPv4 et IPv6) ;
в Pod.Status.PodIPs apparu prise en charge de l'API descendante (en même temps que dans /etc/hosts maintenant, ils demandent à l'hôte d'ajouter une adresse IPv6) ;
prise en charge de la double pile GENTIL (Kubernetes DANS Docker) et Kubeadm;
tests e2e mis à jour.

Illustration utilisation de la double pile IPV4/IPv6 dans KIND

Progrès sur CSI

Déclaré stable prise en charge de la topologie pour le stockage basé sur CSI, introduit pour la première fois dans K8 1.12.

Initiative pour migration des plugins de volume vers CSI - Migration CSI - atteint la version bêta. Cette fonctionnalité est essentielle pour traduire les plugins de stockage existants (dans l'arbre) à une interface moderne (CSI, hors arbre) invisible pour les utilisateurs finaux de Kubernetes. Les administrateurs de cluster n'auront qu'à activer la migration CSI, après quoi les ressources et les charges de travail avec état existantes continueront à « fonctionner »... mais en utilisant les derniers pilotes CSI au lieu de ceux obsolètes inclus dans le noyau Kubernetes.

Pour le moment, la migration des pilotes AWS EBS est prête en version bêta (kubernetes.io/aws-ebs) et GCE PD (kubernetes.io/gce-pd). Les prévisions pour les autres stockages sont les suivantes :

Nous avons expliqué comment la prise en charge du stockage « traditionnelle » dans les K8 est arrivée à CSI en cet article. Et la transition de la migration de CSI vers le statut bêta est dédiée à publication séparée sur le blog du projet.

De plus, une autre fonctionnalité importante dans le contexte de CSI, originaire (implémentation alpha) de K1.17s 8, a atteint le statut bêta (c'est-à-dire activé par défaut) dans la version Kubernetes 1.12 : créer des instantanés et leur rétablissement. Parmi les modifications apportées à Kubernetes Volume Snapshot en route vers la version bêta :

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

Au moment de la version 1.17, la fonctionnalité est prise en charge par trois pilotes CSI : le pilote CSI de disque persistant GCE, le pilote CSI Portworx et le pilote CSI NetApp Trident. Plus de détails sur sa mise en œuvre et son utilisation peuvent être trouvés dans cette publication sur le blog.

Étiquettes du fournisseur de cloud

Des étiquettes qui automatiquement attribué 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 - depuis la sortie de K8s 1.2 (avril 2016 !). Compte tenu de leur utilisation répandue depuis si longtemps, les développeurs décidé, qu'il est 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 sont toujours disponibles sous leurs anciens noms (pour des raisons de compatibilité ascendante). Cependant, il est recommandé à tous les administrateurs de passer aux étiquettes actuelles. Documentation connexe Les K8 ont été mis à jour.

Sortie structurée de kubeadm

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

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

Bien que Kubernetes puisse être déployé manuellement, la norme de facto (sinon de jure) pour cette opération est d'utiliser kubeadm. Les outils de gestion de systèmes populaires tels que Terraform s'appuient sur kubeadm pour le déploiement de Kubernetes. Les améliorations prévues de l'API Cluster incluent un package composable pour le démarrage de Kubernetes avec kubeadm et cloud-init.

Sans sortie structurée, même les modifications les plus inoffensives à première vue peuvent interrompre Terraform, l'API Cluster et d'autres logiciels utilisant les résultats de kubeadm.

Nos plans immédiats incluent la prise en charge (sous forme de sortie structurée) des commandes kubeadm suivantes :

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

Illustration d'une réponse JSON à une 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 des 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 qu'il contient de nombreuses fonctionnalités (leur nombre total est 14) a reçu le statut GA. Parmi eux:

« marquage » des nœuds selon certaines conditions (TaintNodesByCondition), apparaît dans K8 1.8;
Regarder les signets - un nouveau type d'événements qui ont une étiquette indiquant que tous les objets sont à une certaine version (resourceVersion) ont déjà été traités par watch ;
valeurs par défaut (par défaut) pour les ressources personnalisées ;
partagé entre les conteneurs dans les espaces de noms de processus pod ;
ScheduleDaemonSetPods - planification de pods dans DaemonSet en utilisant 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épertoire montés comme subPath;
Transfert des battements de coeur de Kubelet à une API de location spécialisée ;
"protection du finaliseur" (Protection du finaliseur) pour les équilibreurs de charge (vérification des ressources de service correspondantes avant de supprimer les ressources LoadBalancer) ;
optimisation du serveur Kube-Api en performances lorsque vous travaillez avec plusieurs montres surveillant des ensembles d'objets identiques - obtenu en évitant la sérialisation répétée des mêmes objets pour chaque observateur.

Autres changements

La liste complète des innovations de Kubernetes 1.17 ne se limite bien entendu pas à celles énumérées ci-dessus. En voici quelques autres (et pour une liste plus complète, voir CHANGELOG):

La fonctionnalité présentée dans la dernière version a atteint la version bêta RunAsUserName Pour les fenêtres;
changement similaire est arrivé API EndpointSlice (également à partir de K8s 1.16), mais pour l'instant cette solution visant à améliorer les performances/évolutivité de l'API Endpoint n'est pas activée par défaut ;
les pods sont désormais critiques pour le fonctionnement du cluster peut être créé pas seulement dans les espaces de noms kube-system (pour plus de détails, voir la documentation de Limiter la consommation des classes prioritaires);
nouvelle option pour Kubelet - --reserved-cpus — vous permet de définir explicitement la liste des CPU réservés au système ;
pour kubectl logs soumis nouveau drapeau --prefix, en ajoutant le nom du pod et du conteneur source à chaque ligne du journal ;
в label.Selector ajoutée RequiresExactMatch;
tous les conteneurs dans Kube-DNS sont maintenant en cours d'exécution avec moins de privilèges ;
hyperkube séparé dans un référentiel GitHub distinct et ne sera plus inclus dans les versions de Kubernetes ;
significativement performance améliorée Kube-proxy pour les ports non UDP.

Modifications des dépendances :

La version CoreDNS incluse dans kubeadm est la 1.6.5 ;
version crictl mise à jour vers la v1.16.1 ;
CSI 1.2.0 ;
etcd 3.4.3 ;
Dernière version testée de Docker mise à niveau vers 19.03 ;
La version Go minimale requise pour créer Kubernetes 1.17 est la 1.13.4.

PS

A lire aussi sur notre blog :

Source: habr.com

Kubernetes 1.17 : tour d'horizon des principales innovations