Cette nuit prochaine version de Kubernetes - . Selon la tradition qui s'est développée pour notre blog, nous parlons des principaux changements apportés à la nouvelle version de ce merveilleux produit Open Source.
Les informations utilisées pour préparer ce matériel sont tirées de , et problèmes associés, demandes d'extraction, propositions d'amélioration de Kubernetes (KEP).
Commençons par une introduction importante du cycle de vie du cluster SIG : clusters de basculement dynamique Kubernetes (ou pour être plus précis, les déploiements HA auto-hébergés) est désormais en utilisant des commandes familières (dans le contexte de clusters à nœud unique) kubeadm (init и join). Bref, pour cela :
- les certificats utilisés par le cluster sont transférés vers les secrets ;
- pour la possibilité d'utiliser le cluster etcd à l'intérieur du cluster K8s (c'est-à-dire en se débarrassant de la dépendance externe précédemment existante) ;
- Documente les paramètres recommandés pour un équilibreur de charge externe qui fournit une configuration tolérante aux pannes (à l'avenir, il est prévu d'éliminer cette dépendance, mais pas à ce stade).
Architecture d'un cluster Kubernetes HA créé avec kubeadm
Les détails de la mise en œuvre peuvent être trouvés dans . Cette fonctionnalité était vraiment très attendue : la version alpha était attendue dans K8s 1.9, mais n'est apparue que maintenant.
API
Équipe apply et en général gestion déclarative des objets de kubectl dans l'APIserver. Les développeurs eux-mêmes expliquent brièvement leur décision en disant que kubectl apply - une partie fondamentale du travail avec les configurations dans Kubernetes, cependant, "elle est pleine de bugs et difficile à corriger", et donc cette fonctionnalité doit être ramenée à la normale et transférée au plan de contrôle. Exemples simples et clairs de problèmes qui existent aujourd’hui :
Les détails sur la mise en œuvre sont disponibles . La préparation actuelle est alpha (la promotion en version bêta est prévue pour la prochaine version de Kubernetes).
Disponible en version alpha en utilisant le schéma OpenAPI v3 pour créer et publier la documentation OpenAPI pour CustomResources (CR), utilisé pour valider (côté serveur) les ressources définies par l'utilisateur K8 (CustomResourceDefinition, CRD). La publication d'OpenAPI pour CRD permet aux clients (par ex. kubectl) effectuez la validation de votre côté (dans un délai kubectl create и kubectl apply) et délivrer la documentation selon le schéma (kubectl explain). Détails - dans .
Journaux préexistants avec drapeau O_APPEND (et pas O_TRUNC) pour éviter la perte de journaux dans certaines situations et pour faciliter la troncature des journaux avec des utilitaires externes pour la rotation.
Toujours dans le contexte de l'API Kubernetes, on peut noter que dans PodSandbox и PodSandboxStatus terrain runtime_handler pour enregistrer des informations sur RuntimeClass dans le pod (en savoir plus dans le texte sur , où cette classe est apparue en version alpha), et dans les Webhooks d'admission possibilité de déterminer quelles versions AdmissionReview ils supportent. Enfin, les règles d'admission des Webhooks sont désormais l'étendue de leur utilisation par les espaces de noms et les frameworks de cluster.
Installations de stockage
, qui avait le statut bêta depuis sa sortie , stable (GA) : cette porte de fonctionnalité n'est plus désactivée et sera supprimée dans Kubernetes 1.17.
en utilisant des variables d'environnement appelées (par exemple, le nom du pod) pour les noms des répertoires montés en tant que , a été développé - sous la forme d'un nouveau domaine subPathExpr, qui est maintenant utilisé pour déterminer le nom du répertoire souhaité. La fonctionnalité est initialement apparue dans Kubernetes 1.11, mais pour la 1.14, elle est restée en version alpha.
Comme pour la version précédente de Kubernetes, de nombreux changements importants sont introduits pour le CSI (Container Storage Interface) en développement actif :
CSI
Devenu disponible (dans le cadre de la version alpha) redimensionnement pour les volumes CSI. Pour l'utiliser, vous devrez activer la porte de fonctionnalité appelée ExpandCSIVolumes, ainsi que la présence du support de cette opération dans un pilote CSI spécifique.
Une autre fonctionnalité pour CSI dans la version alpha - se référer directement (c'est-à-dire sans utiliser PV/PVC) aux volumes CSI dans la spécification du pod. Ce supprime la restriction sur l'utilisation de CSI comme stockage de données exclusivement à distance, leur ouvrant les portes du monde . Pour utilisation () doit être activé CSIInlineVolume porte de fonctionnalité.
Il y a également eu des progrès dans les « internes » de Kubernetes liés à CSI, qui ne sont pas si visibles pour les utilisateurs finaux (administrateurs système)... Actuellement, les développeurs sont obligés de prendre en charge deux versions de chaque plugin de stockage : une - « dans le old way", à l'intérieur de la base de code K8s (dans l'arborescence), et le second - dans le cadre du nouveau CSI (en savoir plus à ce sujet, par exemple, dans ). Cela entraîne des inconvénients compréhensibles qui doivent être résolus à mesure que CSI lui-même se stabilise. Il n'est pas possible de simplement déprécier l'API des plugins internes (dans l'arborescence) en raison de .
Tout cela a conduit au fait que la version alpha a atteint code du plugin interne, implémenté comme in-tree, dans les plugins CSI, grâce auquel les soucis des développeurs seront réduits à supporter une version de leurs plugins, et la compatibilité avec les anciennes API restera et elles pourront être déclarées obsolètes dans le scénario habituel. Il est prévu que d'ici la prochaine version de Kubernetes (1.15), tous les plugins des fournisseurs de cloud seront migrés, l'implémentation recevra le statut bêta et sera activée par défaut dans les installations K8. Pour plus de détails, voir . Cette migration a également entraîné à partir des limites de volume définies par des fournisseurs de cloud spécifiques (AWS, Azure, GCE, Cinder).
De plus, prise en charge des périphériques de bloc avec CSI (CSIBlockVolume) à la version bêta.
Nœuds/Kubelet
Version alpha présentée à Kubelet, conçu pour renvoyer des métriques sur les ressources clés. De manière générale, si auparavant Kubelet recevait des statistiques sur l'utilisation des conteneurs de cAdvisor, ces données proviennent désormais de l'environnement d'exécution du conteneur via CRI (Container Runtime Interface), mais la compatibilité pour travailler avec les anciennes versions de Docker est également préservée. Auparavant, les statistiques collectées dans Kubelet étaient envoyées via l'API REST, mais désormais un point de terminaison situé à /metrics/resource/v1alpha1. Stratégie à long terme des développeurs est de minimiser l'ensemble de métriques fournies par Kubelet. D'ailleurs, ces mesures elles-mêmes non pas des « métriques de base », mais des « métriques de ressources » et sont décrites comme des « ressources de première classe, telles que le processeur et la mémoire ».
Une nuance très intéressante : malgré le net avantage en termes de performances du point de terminaison gRPC par rapport à divers cas d'utilisation du format Prometheus (voir le résultat d'un des benchmarks ci-dessous), les auteurs ont préféré le format texte de Prometheus en raison du leadership clair de ce système de surveillance dans la communauté.
« gRPC n'est pas compatible avec les principaux pipelines de surveillance. Endpoint ne sera utile que pour fournir des métriques à Metrics Server ou surveiller les composants qui s'y intègrent directement. Performances du format de texte Prometheus lors de l'utilisation de la mise en cache dans Metrics Server assez bien pour nous de préférer Prometheus à gRPC étant donné l'adoption généralisée de Prometheus dans la communauté. Une fois que le format OpenMetrics sera plus stable, nous pourrons aborder les performances de gRPC avec un format basé sur un prototype.
L'un des tests de performances comparatifs de l'utilisation des 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 .
Entre autres changements :
- Kubelet maintenant (une fois) conteneurs dans un état inconnu avant les opérations de redémarrage et de suppression.
- Lorsque vous utilisez le maintenant au conteneur d'initialisation les mêmes informations que pour un conteneur ordinaire.
- kubelet
usageNanoCoresdu fournisseur de statistiques CRI et pour les nœuds et conteneurs sous Windows statistiques du réseau. - Les informations sur le système d'exploitation et l'architecture sont désormais enregistrées dans des étiquettes
kubernetes.io/osиkubernetes.io/archObjets nœuds (transférés de la version bêta à GA). - Possibilité de spécifier un groupe d'utilisateurs système spécifique pour les conteneurs dans un pod (
RunAsGroup, apparaît dans ) avant la version bêta (activé par défaut). - du et find utilisé dans cAdvisor, mise en œuvre en déplacement.
CLI
Dans cli-runtime et kubectl -k indicateur pour l'intégration avec (d'ailleurs, son développement s'effectue désormais dans un référentiel séparé), c'est-à-dire pour traiter des fichiers YAML supplémentaires à partir de répertoires de personnalisation spéciaux (pour plus de détails sur leur utilisation, voir ):
Exemple d'utilisation simple d'un fichier (une application plus complexe de kustomize est possible dans )
En outre:
- nouvelle équipe
kubectl create cronjob, dont le nom parle de lui-même. - В
kubectl logspeut maintenant флаги-f(--followpour les journaux en streaming) et-l(--selectorpour la requête d'étiquette). - kubectl copier les fichiers sélectionnés par caractère générique.
- À l'équipe
kubectl waitdrapeau--allpour sélectionner toutes les ressources dans l'espace de noms du type de ressource spécifié.
Autres
Les fonctionnalités suivantes ont reçu le statut stable (GA) :
- , utilisé dans la spécification du pod pour définir des conditions supplémentaires prises en compte dans la préparation du pod ;
- Prise en charge des grandes pages (porte de fonctionnalité appelée );
- ;
- API de classe prioritaire .
Autres changements introduits dans Kubernetes 1.14 :
- La stratégie RBAC par défaut n'autorise plus l'accès à l'API
discoveryиaccess-reviewutilisateurs sans authentification (non authentifié). - Prise en charge officielle de CoreDNS Linux uniquement, donc lorsque vous utilisez kubeadm pour le déployer (CoreDNS) dans un cluster, les nœuds ne doivent fonctionner que sous Linux (les nodeSelectors sont utilisés pour cette limitation).
- La configuration CoreDNS par défaut est maintenant au lieu d'un mandataire. Aussi, dans CoreDNS readinessProbe, qui empêche l'équilibrage de charge sur les pods appropriés (non prêts à être mis en service).
- Dans Kubeadm, sur les phases
initouupload-certs, chargez les certificats requis pour connecter le nouveau plan de contrôle au secret kubeadm-certs (utilisez l'indicateur--experimental-upload-certs). - Une version alpha est apparue pour les installations Windows gMSA (Group Managed Service Account) - comptes spéciaux dans Active Directory qui peuvent également être utilisés par les conteneurs.
- Pour G.C.E. Chiffrement mTLS entre etcd et kube-apiserver.
- 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 de l'API Docker prise en charge est désormais 1.26.
PS
A lire aussi sur notre blog :
- «";
- «";
- «";
- «».
Source: habr.com