Kubernetes 1.13 : aperçu des principales nouveautés

Cette nuit aura lieu un autre lancement de Kubernetes — 1.14. Conformément à la tradition de notre blog, nous allons vous parler des changements clés dans cette nouvelle version de ce merveilleux produit Open Source.

Les informations utilisées pour préparer ce matériel proviennent de la table de suivi des améliorations de Kubernetes, CHANGELOG-1.14 et des problèmes, demandes de tirage, Propositions d'Amélioration Kubernetes (KEP) associées.

Commençons par une introduction importante de SIG cluster-lifecycle : des clusters hautement disponibles et dynamiques Kubernetes (ou, pour être plus précis, les déploiements HA auto-hébergés) peuvent maintenant être créés à l'aide des commandes familières (dans le contexte des clusters à un seul nœud) kubeadm (init et joindre). En résumé, pour ce faire :

• les certificats utilisés par le cluster sont transférés dans des secrets ;
• afin de permettre l'utilisation d'etcd à l'intérieur du cluster K8s (c'est-à-dire de se débarrasser de la dépendance externe qui existait), un etcd-operator;
• les paramètres recommandés pour le répartiteur de charge externe, garantissant une configuration hautement disponible, sont documentés (il est prévu de pouvoir également se passer de cette dépendance plus tard, mais pas à ce stade).

L'architecture du cluster Kubernetes HA, créée avec kubeadm

Pour plus de détails sur la mise en œuvre, vous pouvez consulter la proposition de design. Cette fonctionnalité était très attendue : la version alpha était attendue déjà dans K8s 1.9, mais n'est arrivée qu'à présent.

API

Commande appliquer et en général la gestion déclarative des objets a été déplacée de kubectl dans apiserver. Les développeurs eux-mêmes expliquent brièvement leur décision en disant que kubectl apply est une partie fondamentale du travail avec les configurations dans Kubernetes, mais qu'elle "est pleine de bogues et difficile à corriger", c'est pourquoi cette fonctionnalité doit être mise en conformité et déplacée dans le plan de contrôle. Des exemples simples et évidents des problèmes existants aujourd'hui :

Les détails de la mise en œuvre — dans KEP. L'état actuel — version alpha (la promotion vers la bêta est prévue pour la prochaine version de Kubernetes).

Dans la version alpha, il est devenu possible la possibilité d'utiliser le schéma OpenAPI v3 pour créer et publier de la documentation OpenAPI sur les CustomResources (CR), utilisés pour valider (côté serveur) les ressources K8s définies par l'utilisateur (CustomResourceDefinition, CRD). La publication d'OpenAPI pour les CRD permet aux clients (par exemple, kubectl) d'effectuer une validation de leur côté (dans le cadre de kubectl create et kubectl apply) et de générer de la documentation sur le schéma (kubectl explain). Les détails — dans KEP.

Les journaux précédemment existants sont désormais disponibles avec le drapeau O_APPEND (et non pas O_TRUNC) afin d'éviter la perte de journaux dans certaines situations et pour faciliter la troncature des journaux par des utilitaires externes pour la rotation.

Dans le contexte de l'API Kubernetes, il est également important de noter que dans PodSandbox et PodSandboxStatus ajouté le champ runtime_handler pour prendre en compte les informations concernant RuntimeClass dans le pod (pour en savoir plus, lisez le texte sur la version 1.12 de Kubernetes, où cette classe est apparue en tant que version alpha), et dans Admission Webhooks réalisée la possibilité de définir quelles versions AdmissionReview elles supportent. Enfin, dans les règles d'Admission Webhooks, il est désormais possible de limiter l'ampleur de leur application aux namespaces et aux limites du cluster. Les stockages

, qui avaient le statut de version bêta depuis la version

PersistentLocalVolumesK8s 1.10 sont maintenant, déclarés stables (GA) : ce gate de fonctionnalité ne sera plus désactivé et sera supprimé dans Kubernetes 1.17.

Possibilité l'utilisation de variables d'environnement appelées Downward API (par exemple, le nom du pod) pour les noms des répertoires montés comme subPath, a évolué — via un nouveau champ subPathExpr, qui détermine désormais le nom requis du répertoire. À l'origine, cette fonctionnalité est apparue dans Kubernetes 1.11, mais elle est restée en version alpha pour 1.14.

Comme dans la précédente version de Kubernetes, de nombreux changements significatifs ont été apportés au CSI (Container Storage Interface) en pleine évolution :

CSI

La possibilité de redimensionner les volumes CSI est devenue disponible (dans le cadre de la version alpha) la prise en charge . Pour l'utiliser, il sera nécessaire d'activer le gate de fonctionnalité appeléExpandCSIVolumes , ainsi que d'avoir le support de cette opération dans le driver CSI spécifique.Une autre fonctionnalité pour le CSI en version alpha —

citer directement (c'est-à-dire sans utiliser de PV/PVC) des volumes CSI dans la spécification des pods. Cela la possibilité supprime la restriction sur l'utilisation de CSI comme uniquement des solutions de stockage de données distantes , ouvrant ainsi pour eux les portes du mondedes volumes éphémères locaux. Pour l'utiliser () vous devez activerexemple de la documentationle gate de fonctionnalité CSIInlineVolume. Des progrès ont également été réalisés dans les ‘intérieurs’ de Kubernetes liés au CSI, qui ne sont pas très visibles pour les utilisateurs finaux (administrateurs système)... Actuellement, les développeurs doivent maintenir deux versions de chaque plugin de stockage : l'une — 'à l'ancienne', dans la base de code K8s (in-tree), et l'autre — dans le cadre du nouveau CSI

(pour en savoir plus, lisez par exemple, dans . Cela engendre des désagréments compréhensibles qui doivent être résolus à mesure que le CSI se stabilise en tant que tel. Il n'est pas possible de simplement déclarer obsolètes (deprecated) les API des plugins internes (in-tree) en raison de ici). Cela entraîne des inconvénients compréhensibles qui doivent être corrigés à mesure que le CSI en tant que tel se stabilise. Il n'est pas possible de déclarer simplement les API des plugins internes (in-tree) obsolètes (deprecated) en raison de la politique correspondante de Kubernetes.

Tout cela a conduit à ce que les versions alpha atteignent le processus de migration du code interne des plugins, mis en œuvre sous forme d'in-tree, dans les plugins CSI, ce qui signifie que les préoccupations des développeurs seront réduites à la prise en charge d'une seule version de leurs plugins, tout en maintenant la compatibilité avec les anciennes API, qui pourront être déclarées obsolètes selon le scénario habituel. La migration de tous les plugins des fournisseurs de cloud devrait être réalisée d'ici la prochaine version de Kubernetes (1.15), cette mise en œuvre obtiendra le statut bêta et sera activée par défaut dans les installations K8s. Plus de détails peuvent être trouvés dans la proposition de design. L'une des conséquences de cette migration a également été la suppression la levée des restrictions sur les volumes déterminés par des fournisseurs cloud spécifiques (AWS, Azure, GCE, Cinder).

De plus, le support des dispositifs de blocs avec CSI (CSIBlockVolume) réduit à la version bêta.

Nœuds / Kubelet

Une version alpha de nouveau point de terminaison dans Kubelet, destinée à fournir des métriques sur les ressources principales. En général, alors qu'auparavant Kubelet obtenait des statistiques d'utilisation des conteneurs à partir de cAdvisor, ces données proviennent maintenant de l'environnement d'exécution du conteneur via le CRI (Container Runtime Interface), bien que la compatibilité avec les anciennes versions de Docker soit maintenue. Auparavant, les statistiques collectées dans Kubelet étaient fournies via l'API REST, tandis qu'à présent, un point de terminaison est utilisé pour cela, situé à l'adresse /metrics/resource/v1alpha1. La stratégie à long terme des développeurs vise à minimiser l'ensemble des métriques fournies par Kubelet. À propos, ces métriques sont désormais appelées non pas «métriques de base», mais «métriques de ressources», et décrivent des «ressources de première classe, telles que le CPU et la mémoire».

Un point très intéressant : malgré l'avantage évident en termes de performances du point de terminaison gRPC par rapport à divers cas d'utilisation du format Prometheus (le résultat de l'un des benchmarks est ci-dessous), les auteurs ont préféré le format texte de Prometheus en raison du leadership évident de ce système de surveillance dans la communauté.

«gRPC n'est pas compatible avec les pipelines de surveillance principaux. Le point de terminaison ne sera utile que pour la livraison de métriques au Metrics Server ou aux composants de surveillance qui s'intègrent directement avec lui. Lors de l'utilisation du cache dans le Metrics Server, les performances du format texte de Prometheus sont plutôt bonnes. pour nous, il est préférable de choisir Prometheus plutôt que gRPC, compte tenu de la large adoption de Prometheus dans la communauté. Lorsque le format OpenMetrics sera plus stable, nous pourrons atteindre des performances similaires à celles de gRPC grâce à un format basé sur proto.

L'un des tests comparatifs de performances utilisant les formats gRPC et Prometheus dans le nouveau point de terminaison Kubelet pour les métriques. Plus de graphiques et d'autres détails peuvent être trouvés dans KEP.

Parmi d'autres changements :

• Kubelet essaie maintenant (une seule fois) d'arrêter les conteneurs dans un état inconnu (unknown) avant les opérations de redémarrage et de suppression.
• Lorsque vous utilisez PodPresets est maintenant ajouté à l'init-container la même information que pour le conteneur ordinaire. a commencé à utiliser
• Kubelet usageNanoCores du fournisseur de statistiques CRI, et pour les nœuds et conteneurs sous Windows les statistiques réseau. ajouté Les informations sur le système d'exploitation et l'architecture sont désormais enregistrées dans les labels
• kubernetes.io/os kubernetes.io/arch et des objets Node (transféré de la bêta en GA). La possibilité de spécifier un groupe d'utilisateurs système spécifique pour les conteneurs dans un pod (
• RunAsGroup) est apparue dansK8s 1.11 est passé) en version bêta (activé par défaut). du et find, utilisés dans cAdvisor,
• ont été remplacés par des implémentations en Go. Dans cli-runtime et kubectl

CLI

le drapeau -k pour l'intégration avec ajouté (d'ailleurs, son développement est maintenant réalisé dans un référentiel séparé), c'est-à-dire pour le traitement de fichiers YAML supplémentaires à partir de répertoires de kustomization spéciaux (voir les détails de leur utilisation kustomize Exemple d'utilisation simple d'un fichier KEP):

kustomization (une application potentiellement plus complexe de kustomize dans le cadre de overlays la nouvelle commande)

En outre :

• Ajouté kubectl create cronjob , dont le nom parle de lui-même.combinent
• Dans kubectl logs est maintenant possible --follow drapeaux -f (pour le streaming des logs) et --selector -l (pour la requête des labels). ont été apprises
• kubectl à copier des fichiers sélectionnés à l'aide de caractères génériques. Dans la commande
• kubectl wait --all ont ajouté drapeau pour sélectionner toutes les ressources du type de ressource spécifié dans l'espace de noms. Les fonctionnalités suivantes ont obtenu un statut stable (GA) :

Autres

ReadinessGate

• , utilisé dans la spécification du pod pour définir des conditions supplémentaires prises en compte dans la disponibilité du pod ;Prise en charge des grandes pages (feature gate intitulé
• HugePages CustomPodDNS);
• PriorityClass API,;
• Pod Priority & Preemption D'autres changements introduits dans Kubernetes 1.14 :.

La stratégie RBAC par défaut ne donne plus accès à l'API

• discovery access-review et aux utilisateurs sans authentification (unauthenticated) Le support officiel de CoreDNS.
• est assuré. est fourni uniquement pour Linux, donc lors de l'utilisation de kubeadm pour son déploiement (CoreDNS) dans le cluster, les nœuds doivent fonctionner uniquement sous Linux (des nodeSelectors sont utilisés pour cette restriction).
• La configuration par défaut de CoreDNS est maintenant utilise le plugin forward au lieu de proxy. De plus, dans CoreDNS ajouté readinessProbe, empêchant l'équilibrage de charge sur les pod concernés (non prêts à être servis).
• Dans kubeadm, aux étapes init ou upload-certs, il est devenu possible de télécharger les certificats nécessaires pour connecter un nouveau control-plane au secret kubeadm-certs (le drapeau est utilisé --experimental-upload-certs).
• Pour les installations Windows, une version alpha est apparue le support gMSA (Group Managed Service Account) — des comptes spéciaux dans Active Directory, qui peuvent être utilisés par les conteneurs.
• Pour GCE mTLS-cryptage entre etcd et kube-apiserver a été activé. Mises à jour des logiciels utilisés/dépendants : Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, prise en charge de Docker 18.09 dans kubeadm, et la version minimale prise en charge de l'API Docker est devenue 1.26.
• Kubernetes 1.11 : aperçu des principales nouveautés

P.S.

Lisez aussi dans notre blog :

• «Kubernetes 1.12 : aperçu des principales nouveautés»;
• «De minuscules images Docker qui croyaient en elles*»;
• «Kubernetes 1.10 : aperçu des principales nouveautés»;
• «Quick Draw Doodle Recognition : comment associer R, C++ et réseaux de neurones».

Source : habr.com