The “upstream” kubernetes

Kubernetes est devenu en quelque temps le standard de facto en terme d’orchestration de conteneurs. Si les fonctionnalités de base commencent à être connues, les nouvelles dites “upstream” le sont moins, elles permettent cependant d’enrichir le produit et de répondre à des cas d’usage très spécifiques.

Cet article est un passage en revue des nouvelles fonctionnalités des dernières versions, ainsi que celles qui arrivent pour la prochaine qui est la 1.10,  il requiert donc la connaissance préalable de kubernetes.

Disclaimer: certaines de ces fonctionnalités sont en alpha, c’est-à-dire que lors des prochaines releases certains changements peuvent ne pas être rétro-compatibles, pour les mises à jour il faut toujours se référer aux release-notes.

Kubernetes et la gestion des nœuds

Les teintes et les tolérances (taints & tolerations) sont des features de Kubernetes qui permettent de s’assurer que des pods soient placés sur des noeuds appropriés. Une teinte est composée d’une clé ou d’une paire clé/valeur (i.e la valeur est optionnelle) et d’un effet. Trois effets sont disponibles :

  • Une teinte avec l’effet NoExecute indique qu’il ne faut plus placer de pods sur ce nœud et qu’il faut commencer à le drainer. Cette dernière permet la mise en place de politiques d’évictions en se basant sur les teintes.
  • Une teinte avec l’effet NoSchedule indique qu’il ne faut plus placer de pods sur ce nœud.
  • Une teinte avec l’effet PreferNoSchedule indique qu’il ne faut placer des pods sur ce nœud qu’en dernier ressort.

Dans certains cas, l’administrateur du cluster a besoin de tolérer des teintes pour des raisons qui lui sont propres. Une tolérance est une propriété d’un Pod, elle est composée de la clef de la teinte à tolérer, d’une valeur optionnelle, d’une durée de tolérance (durée infinie par défaut) ainsi que d’un opérateur, il existe deux types d’opérateurs :

  • L’opérateur Exist indique que la vérification est faite sur la clef et l’effet.
  • L’opérateur Equal effectue les mêmes vérifications que l’opérateur Exist et en plus vérifie que la valeur optionnelle est la même que sur la teinte.

Les teintes et tolérance permettent d’introduire de nouveaux comportements dans kubernetes, tel que le fait de teinter les noeuds par leurs NodeCondition. Cela permet de tolérer certains états et de placer des Pods même si on teinte le nœud avec une teinte networkUnavailable, ce afin de diagnostiquer ou de préparer la mise en service du nœud.

Kubernetes fait de kube-scheduler un composant critique

Le scheduler s’enrichit au fur et à mesure, tout d’abord avec les APIs priority & preemption commencent leurs transitions vers un support beta, et ce dés la version 1.11. En effet les critical pods s’intégreront directement avec la priority API au lieu de reposer sur le rescheduler et les teintes.

La préemption deviendra plus complète pour la prochaine version, en gérant les préemptions de pods afin de placer les DaemonSet lorsque les ressources ne le permettent pas. Pour y arriver, leur placement ne sera plus assuré par le DaemonSet controller mais bien par le kube-scheduler directement. Cela aura pour effet de rendre kube-scheduler critique lors du démarrage du cluster pour les outils déployant les masters sous forme de DaemonSet dès la prochaine version, ce comportement sera introduit en alpha et devra donc être activé explicitement si il est désiré. Il en sera de même pour la gestion de la préemption dans le cas où on utilise plusieurs schedulers, qui elle arrivera en version 1.11.

Côté performance, la version 1.10 verra l’arrivée du design Predicates-ordering, pour rappel l’algorithme de scheduling applique une suite de prédicats, qui sont un ensemble de fonction qui déterminent si un pod peut aller sur ce noeud. Les noeuds éligible sont ensuite priorisés par un ensemble de fonctions de priorisation pour choisir le noeud le plus adéquat.

Le scheduler définira l’ordre d’exécution des prédicats, de manière à exécuter en premier les prédicats les plus restrictifs et moins complexes à calculer. Cela optimise le temps d’exécution, de plus si un prédicat échoue, on n’exécute pas le reste des prédicats.

Cette dernière partie sera développée plus en détails dans un prochain article, afin d’exposer le travail qui a pu être effectué avec Bobby Salamat de chez Google sur le sujet.

Vers plus de modularité

Kubernetes cherche à devenir plus modulaire et plus facile à étendre par des contributions externes comme c’est le cas actuellement avec CNI et CRI, il devient maintenant important de séparer le cœur de Kubernetes au niveau de :

  • L’intégration avec les clouds providers avec l’introduction des CCM
  • L’intégration de gestionnaire de stockage au travers de CSI

Kubernetes à l’assaut du cloud avec le Cloud Controller Manager

Depuis Kubernetes 1.8, le Cloud Controller Manager permet à tout fournisseur cloud de s’intégrer avec kubernetes, ceci représente un avantage non-négligeable car ils ne sont plus obligés d’avoir leur code directement dans kubernetes. Ainsi le rythme de release est fixé par le provider et non plus par la communauté kubernetes, ce qui à terme permettra d’améliorer la vélocité et l’enrichissement des fonctionnalités proposées par les différents fournisseurs. On commence déjà à voir certains fournisseurs se positionner en développant leur implémentation : Rancher, Oracle, Alibaba, DigitalOcean ou encore Cloudify.

Cela fonctionne en se basant sur un mécanisme de plugin, en effet tout fournisseur cloud implémentant l’interface cloudprovider.Interface et s’enregistrant auprès de kubernetes peut être lié au binaire CCM.

Dans les prochaines releases, tous les fournisseurs cloud (incluant les fournisseurs déjà supportés dans le kubernetes/kubernetes) vont implémenter cette interface en dehors du repository Kubernetes, ce qui rendra le projet plus modulaire. Par exemple voici la roadmap discutée par la communauté pour Azure.

Kubernetes lance la CSI (Container Storage Interface)

Lancée pour la version 1.9 en tant qu’alpha, CSI est une spécification qui permet à n’importe quel fournisseur qui implémente la spécification de fournir un driver qui permettra à kubernetes de manipuler le storage, dans la version 1.10 de kubernetes CSI passera en beta.

La douleur que traite CSI est double, comme le CCM, il rend possible l’externalisation des drivers de stockage et permet donc d’adapter le rythme de release des drivers au souhait des vendeurs. Deuxièmement, CSI résout le problème des plugins FlexVolume qui étaient difficiles à installer. Si vous souhaitez écrire votre driver, voici comment le déployer.

Kubernetes v1beta1.Event à la rescousse

Les événements ont toujours été un problème sur kubernetes, que ce soit d’un point de vue sémantique ou de performance.

Actuellement, toute la sémantique est englobée dans un message, ce qui rend l’extraction de sens ainsi que le requêtage d’événements très difficile. L’aspect performance reste à améliorer, pour l’instant kubernetes dispose d’une logique de dédoublonnage qui permet d’éliminer les doublons, ce qui permet de réduire l’empreinte mémoire sur Etcd. Cependant, le nombre d’appels à etcd reste problématique. Pour cela la version 1.11 va introduire une nouvelle logique de gestion d’évènements qui devrait soulager etcd. Le principe est simple, le dédoublonnage d’événements et les mises à jour d’événements se feront périodiquement, ce qui réduira grandement le nombre d’appels à l’api-server afin d’écrire les événements sur etcd.

Cette partie sera développée plus en détails dans un prochain article de la série, afin d’exposer le travail qui a pu être effectué avec Marek Grabowski de chez Google ainsi que Timothy St. Clair de chez Heptio sur le sujet.

Kubernetes  HPA – Horizontal Pod Autoscaler

Kubernetes permettra de scaler vos pods en se basant sur des métriques personnalisées, cette feature est passée en beta, elle permet grâce à une couche d’agrégation d’étendre l’api-server au delà des APIs fournies par kubernetes en ajoutant deux APIs :

  • Resources Metrics API : elle permet de collecter des métriques dites ressources, à savoir le CPU et la mémoire, l’implémentation canonique est le Metrics-Server ce qui permet de ne plus utiliser Heapster.
  • Custom Metrics API : elle permet de collecter des métriques personnalisées, cela permet d’utiliser des outils comme Prometheus afin de gérer l’auto-scaling. Un adaptateur interroge les métriques Prometheus et les rend utilisables comme seuils pour l’auto-scaling.

Les cas d’usage sont variés, ce qui permet de coller aux besoins spécifiques de chacun. Cette partie sera développée plus en détails dans un prochain article de la série.

Kubernetes fédération

Déployer plusieurs clusters devient de plus en plus un besoin. Kube-fed permet de gérer cela en déployant on premise, sur différents fournisseurs cloud ou sur différentes régions d’un fournisseur, ce qui permet d’avoir une grande flexibilité. Les ressources sont relativement matures. Ainsi de nouvelles fonctionnalités ont vu le jour pour la fédération :

  • Le support de la HPA arrive, le principe est le même que celle au sein d’un cluster, sauf que le travail n’est pas fait au même niveau : celle de fédération assure l’auto-scaling sur différents clusters.
  • Les private registry d’images de conteneurs pour la fédération, et ce, dès la version 1.10.
  • Il sera aussi possible de choisir sur quel noeud déployer le fédération-controller grâce au nodeSelectors.

Conclusion

L’écosystème kubernetes est arrivé à maturité, et il continue de s’enrichir fonctionnellement afin de répondre aux différents besoins de ses utilisateurs. La possibilité d’étendre kubernetes permettra aux utilisateurs de coller aux cas d’usage les plus pointus. Les prochains articles aborderont plus en détails certaines des fonctionnalités introduites dans cet article, tel que le fonctionnement de la HPA, la gestion des événements etc…

 

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


Ce formulaire est protégé par Google Recaptcha