The upstream Kubernetes

Kubernetes has quickly become the de facto standard for container orchestration. If the basics are now well understood, the new “upstream” features are much less, even though they make the product richer and able to address some very specific use cases.
This article is a review of these new features, as well as the upcoming ones that come with the 1.10 release. A prior knowledge of kubernetes is a prerequisite.
Disclaimer: some of these features are alpha, meaning that some backward incompatible changes may be released with the upcoming versions. Always refer to the release-notes when upgrading.

Kubernetes and node management

Taints and tolerations are Kubernetes features that ensure Pods are assigned to appropriate nodes. A taint is composed of a key or a key/value pair (the value is optional), and an effect. Three effects are available:

  • A taint with the NoExecute effect indicates that no more Pods should be assigned to the node and that it should be drained out. This enables the creation of eviction policies based on taints.
  • A taint with the NoSchedule effect indicates that no more Pods should be assigned to the node.
  • A taint with the PreferNoSchedule effect indicates that Pods should be assigned to this node only as a last resort.

In some cases, the cluster administrator needs to tolerate taints for some reasons. A toleration is a Pod’s property. It’s composed of a tolerated taint’s key, an optional value, a toleration delay (infinite by default), and an operator. There are 2 types of operators:

  • The Exist operator indicates that the check was done on the key and effect
  • The Equal operator performs the same checks as the Exist operator, and also checks that the optional value is the same as on the taint

The taints and tolerations introduce new behaviours in Kubernetes, such as tainting node with their NodeCondition. This allows to tolerate some states and to assign Pods even though the node is tainted with networkUnavailable, so as to diagnose or prepare a node deployment.

Kubernetes makes kube-scheduler a critical component

The scheduler is getting richer and richer, starting with the priority & preemption APIs that begin to move towards beta support. Indeed the critical pods will integrate directly with the priority API instead of relying on rescheduler and taints.
Preemption will become more complete in the next version, managing Pods preemptions to assign DaemonSet when resources forbid it. To get there, the assignment will no longer be handled by the DaemonSet controller but directly by the kube-scheduler. This makes the kube-scheduler a critical component when starting a cluster with tools that deploy masters as DaemonSet, as early as the next version. The preemption management when several schedulers are in use will happen in version 1.11.
Performance wise, the version 1.10 will embed the Predicates-ordering design. Short reminder, the scheduler algorithm operates a suite of predicates, a set of functions, to determine if a pod can be hosted on a node. The eligible nodes are then prioritised by a set of prioritisation functions to elect the best fitted node.
The scheduler will define the predicates execution order, so as to execute first the higher restriction and less complex predicates. This will optimise the execution time, and if a predicate fails, the remainder of predicates will not be executed.
This last part will be detailed further in a following article, to present the work done by Googler Bobby Salamat about it.

Towards more modularity

Kubernetes is becoming more modular and easier to extend with external contributions, such as CNI (Container Network Interface) and CRI (Container Runtime Interface) currently. It now becomes important to split Kubernetes’ core when it come to:

  • Integration with cloud providers thanks to CCM (Cloud Controller Manager)
  • Integration to storage management thanks to CSI (Container Storage Interface)

Kubernetes addresses the Cloud with the Cloud Controller Manager

Ever since Kubernetes 1.8, the Cloud Controller Manager makes possible for any cloud provider to integrate with Kubernetes. This is a great improvement as they don’t have to contribute directly into Kubernetes code. Thus, the release pace is given by the provider and not by the Kubernetes community, which improves velocity and the variety of features proposed by the cloud providers. Some providers are already developing their own implementation: Rancher, Oracle, Alibaba, DigitalOcean or Cloudify.

This works by relying on a plugin mechanism, as any cloud provider implementing cloudprovider.Interface and registering to Kubernetes can be linked to the CCM binary.
In the next releases, every cloud providers (including providers already supported by kubernetes/kubernetes) will implement this interface outside of the Kubernetes repository, making the project more modular. For instance, here is the roadmap discussed by the Azure community.

Kubernetes launches CSI (Container Storage Interface)

Launched in version 1.9 in alpha, CSI is a spec that allows any provider implementing the specification to provide a driver that allows Kubernetes to manage storage. CSI will go alpha in version 1.10.
The pain point addressed by CSI is twofold. Like CCM, it enables externalization of storage drivers and makes it possible for providers to define their release pace. Secondly, CSI resolves the hard installation issue of the FlexVolume plugins. If you want to write your own driver, see here how to deploy it.

Kubernetes v1beta1.Event to the rescue

Events have always been an issue on Kubernetes, semantic wise and performance wise.

Currently, the whole semantic is embedded in a message, which hardens considerably the information extraction and the events requesting. Performance wise, there is room for improvement. For now, Kubernetes has a deduplication process to remove identical entries, which decreases the memory footprint of etcd, Kubernetes’ distributed key-value store. However, the number of requests to etcd remains an issue. The version 1.10 will introduce the new event processing logic which should release this pressure. The principle is simple, event deduplication and events updates will happen periodically, which will greatly decrease the number of api-server calls for writing requests to etcd.
This part will be further detailed in a following article, to present the related work by Googler Marek Grabowski and Heptio’s Timothy St. Clair.

Kubernetes HPA – Horizontal Pod Autoscaler

Kubernetes will make it possible to scale your Pods depending on custom metrics. This feature is now beta. An aggregation layer makes it possible to extend the api-server beyond the native APIs provided by Kubernetes. It does so by adding 2 APIs:

  • Resources Metrics API: collect metrics called resources, namely CPU and memory. The nominal implementation is Metrics-Server, that makes Heapster redundant.
  • Custom Metrics API: collect custom metrics, which facilitates the use tools such as Prometheus to manage auto-scaling. An adapter polls Prometheus metrics and makes them available as auto-scaling thresholds.

There are various use cases, and this allows to address each of their specific needs. This part will be detailed in a next article.

Kubernetes federation

The need for deploying multiple clusters becomes more and more mainstream. Kube-fed offers to manage that across on-premise sites, various cloud providers or on different regions of a same hosting service, which enables a considerable flexibility. Resources are relatively mature, and several features were added for federation:

  • The HPA support is on its way, with the same principle as for a cluster, except that the processing is done on another level: the federation one ensures auto-scaling on multiple clusters.
  • The private image registries for federation is planned for version 1.10.
  • It will be possible to choose on what node to deploy the federation-controller thanks to the nodeSelector.


The Kubernetes eco-system is reaching a satisfying maturity level, and keeps improving to address the many needs of its users. The possibility to extend Kubernetes will offer the users a way to address some very specific use cases. The next articles will detail more thoroughly some of the features introduced in this article such as the HPA principles, the event management, etc.

Laisser un commentaire

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

Ce formulaire est protégé par Google Recaptcha

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.


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 e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce formulaire est protégé par Google Recaptcha