Kubernetes

Kubernetes permet d'automatiser la mise en production des applications contenairisées. Il apporte d'intéressantes fonctionnalités à Docker pour gérer la mise en cluster. Couramment appelé K8S, il permet de deployer des ensembles de containers sur un cluster de machines et de gérer aussi bien l'allocation de ressources, que la haute-disponibilité au travers d'API et de fichiers de configuration. Le principe de fonctionnement est de décrire l'état du cluster dans des fichiers et de laisser celui-ci converger vers cet état attendu.

Un cluster Kubernetes utilise principalement ces composants :

  • un master qui a 3 process :
    • kube-apiserver qui contrôle les données et permet d'interagir avc K8S
    • kube-controller-manager qui gère l'état du cluster
    • kube-scheduler qui va gérer l'allocation de ressources
  • des noeuds qui font tourner les containers au travers de 3 process :
    • kubelet est un agent qui va créer et gérer les containers
    • kube-proxy comme son nom l'indique est un proxy qui permet d'abstraire les services déclarés globalement sur le cluster et les resources au niveau du noeud.
    • docker pour faire tourner les containers (d'autres alternatives à docker pourront être supportées notamment rkt actuellement expérimental)

Les objets d'un K8S sont les suivants :

  • les Pods sont les unités de base qui peuvent être déployées. Ils comprennent un (ou plusieurs) containers, et différentes ressources nécessaires.
  • les Services sont la matérialisation du service rendu par les pods. Ces derniers peuvent disparaitre, être upgradés, par contre le service qu'ils sont sensé incarné doit persister. Le lien entre service et pods est fait par des Labels.
  • les Volumes permettent d'allouer des ressources disques et de les attacher à des Pods de manière durable et résiliente. Dans le cas de Google Container Engine (GKE) on peut attacher des disques de GCE pour fournir ces volumes.
  • les Namespaces permettent de découper un cluster en unités logiques isolées et de déployer de multiples applications qui pourraient avoir des conflits dans les noms de ressources par exemple.
  • les ReplicaSets vont executer un certain nombre de copies d'un Pod sur le cluster. Ceci permet d'assurer le re-démarrage automatisé d'un Pod suite à une défaillance. Dans le cas d'un ReplicaSet les hostnames des Pods, leur stockage est volatile et sensible au redémarrage de ceux-ci.
  • les StatefulSets sont très proches des ReplicaSets à ceci près qu'ils permettent de disposer de hostnames stables pour chacun des pods, et ainsi de permettre le déploiement d'un cluster par exemple.
  • les DaemonSets vont assurer qu'une copie d'un Pod est déployée sur chaque noeud du cluster. C'est très utile pour des services comme du logging, ou un stockage distribué.
  • les Deployments sont les descriptions des applications mises en oeuvre sur le cluster (image de container, volumes, replicas, etc...). Cette description de l'état attendu va générer tous les objets sous-jacents nécessaires à rendre le service, et automatiser l'exécution de ceux-ci.
  • les ressources de type Ingress sont des routeurs qui permettent d'exposer les services sur des IP publiques externes au cluster.
  • les Secrets et les ConfigMaps ont pour vocation de pouvoir stocker de manière centralisée les configurations utilisées par les deployments. Les ConfigMaps sont des Key-Values, alors que les Secrets sont utilisés pour stocker des objets binaires comme des certificats par exemple.
  • les Jobs deploient des Pods et vérifient que ceux-ci se sont terminés avec succès.

Lors de la dernière Dockercon, Docker a annoncé le support de Kubernetes dans l'offre Docker EE, ce qui en fait de facto l'orchestrateur standard du marché. Kubernetes permet de mettre en oeuvre des scénarios très évolués de gestion de clusters de containers docker. Dans de prochains blogs, nous illustrerons tout ça par la pratique.