Kubernetes -
1.14 sortira cette nuit. Selon la tradition qui s'est développée pour notre blog, nous parlons de changements clés dans la nouvelle version de ce merveilleux produit Open Source.
Les informations utilisées pour préparer ce matériel sont tirées du
tableau de suivi des améliorations de Kubernetes ,
CHANGELOG-1.14 et des problèmes connexes, des demandes d'extraction, des propositions d'amélioration de Kubernetes (KEP).
MISE À JOUR (26 mars): L'
annonce officielle de la sortie est également apparue sur le blog K8s.
Commençons par une introduction importante du cycle de vie du cluster SIG:
les clusters de basculement dynamique Kubernetes (et plus précisément les déploiements HA auto-hébergés)
peuvent désormais
être créés à l'aide des commandes
kubeadm (
init et
join ) habituelles (dans le contexte des clusters à nœud unique). En bref, pour cela:
- les certificats utilisés par le cluster sont transférés vers des secrets;
- pour la possibilité d'utiliser le cluster etcd à l'intérieur du cluster K8s (c'est-à-dire de se débarrasser de la dépendance externe qui a existé jusqu'à présent), l' opérateur etcd est utilisé ;
- Les paramètres recommandés pour un équilibreur de charge externe qui fournit une configuration à tolérance de pannes sont documentés (à l'avenir, la possibilité d'une défaillance à partir de cette dépendance est prévue, mais pas à ce stade).
Architecture de cluster Kubernetes HA construite avec kubeadmLes détails de la mise en œuvre peuvent être trouvés dans la
proposition de conception . Cette fonctionnalité était très attendue: la version alpha était attendue dans K8s 1.9, mais n'apparaissait que maintenant.
API
La commande
apply et la
gestion d'objet généralement
déclarative sont déplacées de
kubectl vers apiserver. Les développeurs eux-mêmes expliquent brièvement leur décision en disant que l'
kubectl apply est un élément fondamental du travail avec les configurations dans Kubernetes, cependant, c'est «plein de bugs et difficile à corriger», et donc cette fonctionnalité doit être restaurée à la normale et transférée sur le plan de contrôle. Exemples simples et illustratifs des problèmes d'aujourd'hui:
Les détails de l'implémentation sont dans
KEP . La disponibilité actuelle est la version alpha (la promotion en version bêta est prévue pour la prochaine version de Kubernetes).
Dans la version alpha, la
possibilité d' utiliser le schéma OpenAPI v3 pour
créer et publier la documentation OpenAPI sur CustomResources (CR) utilisée pour valider (côté serveur) les ressources K8 définies par l'utilisateur (CustomResourceDefinition, CRD) est devenue disponible. La publication d'OpenAPI pour 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 d'émettre de la documentation conformément au schéma (
kubectl explain ). Les détails sont dans le
KEP .
Les journaux préexistants
s'ouvrent désormais avec l'indicateur
O_APPEND (plutôt que
O_TRUNC ) pour éviter la perte de journaux dans certaines situations et pour la commodité de tronquer les journaux avec des utilitaires de rotation externes.
Toujours dans le contexte de l'API Kubernetes, on peut noter que dans
PodSandbox et
PodSandboxStatus champ
PodSandboxStatus est
runtime_handler pour prendre en compte les informations sur
RuntimeClass dans le pod (en savoir plus à ce sujet dans le texte sur
la version Kubernetes 1.12 , où cette classe est apparue comme une version alpha), et dans Admission Webhooks a
implémenté la possibilité de déterminer les versions d'
AdmissionReview qu'ils prennent en charge. Enfin, dans les règles d'admission Webhooks,
vous pouvez désormais
limiter la portée de leur application à
la portée de l'espace de noms et du cluster.
Installations de stockage
PersistentLocalVolumes qui ont le statut bêta depuis la sortie de
K8s 1.10 sont
déclarés stables (GA): cette porte de fonctionnalité ne sera plus désactivée et sera supprimée dans Kubernetes 1.17.
La possibilité d' utiliser les variables d'environnement de la soi-disant
API descendante (par exemple, le nom du pod) pour les noms de répertoire montés en tant que sous-
subPath a été développée - sous la forme d'un nouveau champ
subPathExpr , avec lequel le nom de répertoire souhaité est maintenant déterminé. Initialement, la fonctionnalité est apparue dans Kubernetes 1.11, mais pour 1.14, elle est restée dans l'état de la version alpha.
Comme avec la version précédente de Kubernetes, de nombreux changements importants sont introduits pour la CSI (Container Storage Interface) en évolution rapide:
CSI
La prise en charge du redimensionnement de la prise en charge des volumes CSI est devenue disponible (dans le cadre de la version alpha). Pour l'utiliser, vous devrez activer la porte de fonctionnalité appelée
ExpandCSIVolumes , ainsi que la présence de la prise en charge de cette opération dans un pilote CSI spécifique.
Une autre caractéristique de CSI dans la version alpha est la
possibilité de se référer directement (c'est-à-dire sans utiliser de PV / PVC) aux volumes CSI dans le cadre de la spécification du pod. Cela
supprime la restriction d'utilisation de CSI comme entrepôts de données exclusivement distants , leur ouvrant la porte au monde des
volumes éphémères locaux . Pour l'utiliser (
exemple de la documentation ), vous devez activer la porte de fonctionnalité
CSIInlineVolume .
Il y a 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) ... Pour le moment, les développeurs sont obligés de prendre en charge deux versions de chaque plug-in de stockage: une «à l'ancienne», à l'intérieur de la base de code K8 (dans -tree), et le second - dans le cadre du nouveau CSI
(en savoir plus à ce sujet, par exemple, ici ) . Cela entraîne des inconvénients compréhensibles qui doivent être résolus à mesure que le CSI se stabilise. La simple dépréciation de l'API obsolète des plug-ins dans l'arborescence n'est pas possible en raison de la
politique Kubernetes correspondante .
Tout cela a conduit au fait que la version alpha a atteint le
processus de migration du code interne des plug-ins implémentés en tant
qu'arborescences vers les plug-ins CSI, en raison de quoi les développeurs seront réduits à prendre en charge une version de leurs plug-ins, et la compatibilité avec les anciennes API sera préservée et ils peuvent être déclarer obsolète comme d'habitude. Il est prévu que d'ici la prochaine version de Kubernetes (1.15), tous les plugins du fournisseur de cloud seront migrés, l'implémentation recevra le statut bêta et sera activée dans les installations par défaut de K8s. Voir la
proposition de conception pour plus
de détails. Cette migration a également entraîné le
rejet des restrictions pour les volumes définis par des fournisseurs de cloud spécifiques (AWS, Azure, GCE, Cinder).
De plus, la prise en charge des périphériques de bloc CSI (
CSIBlockVolume ) a été
convertie en version bêta.
Nodes / Kubelet
Introduction d'une version alpha du
nouveau point de
terminaison dans Kubelet, conçue pour
renvoyer des métriques pour les principales ressources . De manière générale, si Kubelet obtenait des statistiques sur l'utilisation des conteneurs de cAdvisor, ces données proviennent désormais de l'exécution du conteneur via le CRI (Container Runtime Interface), mais la compatibilité avec les anciennes versions de Docker est préservée. Auparavant, les statistiques collectées dans Kubelet étaient fournies via l'API REST, mais maintenant il utilise le point de terminaison situé dans
/metrics/resource/v1alpha1 . La stratégie à long terme des développeurs
est de minimiser l'ensemble des métriques fournies par Kubelet.
Soit dit en passant, ces mesures elles-mêmes ne sont plus appelées «mesures de base», mais «mesures 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é l'avantage évident des performances des points de terminaison gRPC par rapport aux différents cas d'utilisation du format Prometheus
(le résultat de l'un des tests
de référence ci-dessous) , les auteurs ont préféré le format texte Prometheus en raison de la direction claire 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 des composants qui s'intègrent directement avec lui. Lors de l'utilisation de la mise en cache dans Metrics Server, les performances du format de texte Prometheus sont suffisamment bonnes pour que nous préférions Prometheus à gRPC, étant donné l'utilisation répandue de Prometheus dans la communauté. Lorsque le format OpenMetrics devient plus stable, nous pouvons nous rapprocher des performances gRPC avec un format basé sur des prototypes. »
L'un des tests de performances comparatifs 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 .Entre autres changements:
- Kubelet accepte désormais le paramètre
pid=<number> dans les --system-reserved et --kube-reserved , garantissant que le PID spécifié sera réservé pour le système entier ou les démons du système Kubernetes, respectivement. La fonctionnalité est activée lorsque la porte de fonctionnalité est activée, appelée SupportNodePidsLimit . - Kubelet essaie maintenant (une fois) d'arrêter les conteneurs dans un état inconnu avant de redémarrer et de supprimer les opérations.
- Lorsque vous utilisez
PodPresets , les mêmes informations sont désormais ajoutées au conteneur init en tant que conteneur standard. - Kubelet a commencé à utiliser
usageNanoCores du fournisseur de statistiques CRI, et des statistiques de réseau ont été ajoutées pour les nœuds et les conteneurs sous Windows. - Les informations sur le système d'exploitation et l'architecture sont désormais enregistrées dans les
kubernetes.io/os et kubernetes.io/arch des objets Node (transférées de la version bêta à GA). - La possibilité de spécifier un groupe d'utilisateurs système spécifique pour les conteneurs dans le pod (
RunAsGroup , apparu dans K8s 1.11 ) est passée à la version bêta (activée par défaut). - du et find utilisés dans cAdvisor sont remplacés par des implémentations Go.
CLI
L'indicateur -k a été
ajouté à cli-runtime et kubectl pour l'intégration avec
kustomize (à propos, il est maintenant développé dans un référentiel séparé), c'est-à-dire pour le traitement de fichiers YAML supplémentaires à partir de répertoires de personnalisation spéciaux (pour plus de détails sur leur utilisation, voir
KEP ):
Un exemple d'une utilisation simple du fichier de personnalisation (une utilisation plus compliquée de kustomize dans les superpositions est également possible )De plus:
- Le logo kubectl et sa documentation ont été mis à jour - voir kubectl.docs.kubernetes.io .
- Une nouvelle commande
kubectl create cronjob a été kubectl create cronjob , dont le nom parle de lui-même. - Dans les
kubectl logs vous pouvez désormais combiner les indicateurs -f ( --follow pour les journaux de streaming) et -l ( --selector pour la requête d'étiquette). - kubectl a appris à copier des fichiers sélectionnés avec un joker.
- L'indicateur
--all a été ajouté à la commande kubectl wait pour sélectionner toutes les ressources dans l'espace de noms du type de ressource spécifié. - Mécanisme de plugin stable déclaré pour kubectl .
Autre
Le statut stable (GA) a reçu les fonctionnalités suivantes:
- Prise en charge des nœuds Windows (y compris Windows Server 2019), ce qui implique la possibilité de planifier des conteneurs Windows Server dans Kubernetes (voir également KEP );
ReadinessGate utilisé dans la spécification du pod pour déterminer les conditions supplémentaires qui sont prises en compte dans la préparation du pod;- Prise en charge des grandes pages (portail de fonctionnalités appelé
HugePages ); - CustomPodDNS ;
- API PriorityClass, Pod Priority & Preemption .
Autres changements introduits dans Kubernetes 1.14:
- La stratégie RBAC par défaut ne fournit plus l'accès à l'API de
discovery et la access-review d' access-review aux utilisateurs non authentifiés. - La prise en charge officielle de CoreDNS est fournie uniquement pour Linux, donc lorsque vous utilisez kubeadm pour son déploiement (CoreDNS) dans un cluster, les nœuds doivent fonctionner uniquement sous Linux (les sélecteurs de nœuds sont utilisés pour cette limitation).
- La configuration CoreDNS par défaut utilise désormais le plug-in de transfert au lieu du proxy. De plus, readinessProbe a été ajouté à CoreDNS, ce qui empêche l'équilibrage de charge sur les pods correspondants (non prêts pour le service).
- Dans kubeadm, dans les
upload-certs init ou upload-certs , il est devenu possible de télécharger les certificats requis pour connecter le nouveau plan de contrôle au secret kubeadm-certs (l' --experimental-upload-certs est utilisé). - Pour les installations Windows, une version alpha de la prise en charge de gMSA (Group Managed Service Account) - comptes spéciaux dans Active Directory, qui peuvent être utilisés par des conteneurs, est apparue.
- Pour GCE , le cryptage mTLS a été activé entre etcd et kube-apiserver.
- Mises à jour du logiciel utilisé / dépendant: 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 était de 1,26.
PS
Lisez aussi dans notre blog: