Kubernetes is an open source orchestration system for Docker containers. It handles scheduling onto nodes in a compute cluster and actively manages workloads to ensure that their state matches the users declared intentions. Using the concepts of « labels » and « pods », it groups the containers which make up an application into logical units for easy management and discovery.
Ce premier meetup parisien sur Kubernetes fut très instructif. Composé de trois talks très différents, de nombreux thèmes ont été abordés :
Talk 1 : Kubernetes Architecture & Introduction – une présentation très technique et très intéressante de la part d’un ingénieur de Mesosphere.
Talk 2 : Retour d’expérience GKE en production chez Clustree – des explications pertinentes sur les problèmes rencontrés en prod avec Kubernetes, ainsi que les avantages que cela a apporté.
Talk 3 : Retour d’expérience Twistlock Security – une présentation commerciale de Twistlock, une solution de sécurité pour Docker et Kubernetes.
Talk 1 – Kubernetes Architecture & Introduction
Par Dr. Stefan Schimannski, Distributed Systems Engineer @Mesosphere
Cette présentation reprenait les bases de Kubernetes.
Qu’est-ce qu’un pod ?
Une des notions les plus importantes dans Kubernetes est celle de pod. Si elle peut exister hors de Kubernetes, c’est là qu’elle prend tout son sens. Un pod est un groupe de containers qui partagent un set de ressources : même namespace, mêmes volumes, mêmes adresses IPs, etc. Si deux containers sont dans un même pod, et que l’un fait tourner un serveur web sur le port 80, l’autre pourra accéder à se serveur web via 127.0.0.1:80.
Architecture de Kubernetes
Le «cœur» de Kubernetes est l’API server. C’est le composant avec lequel tout le reste interagit : kubectl (la CLI), les nodes (serveurs hosts), le scheduler, les replications controller, etc. Son storage backend est un cluster etcd. Les replications controllers sont en charge de gérer le nombre de réplicas d’un pod, en fonction de différentes règles. Les replications controllers passent leur temps à interroger le serveur l’API pour demander le nombre de réplicas du pod qui les intéressent : « Est-ce qu’il y en a trop ? Oui, j’en supprime. Est-ce qu’il y en a assez ? Non, j’en ajoute. »
La documentation pour s’interfacer avec Kubernetes est disponible ici : http://kubernetes.io/v1.1/. Le code source est également très bien documenté.
Kubernetes a une approche très différente du réseau et de la découverte de service que les solutions Docker « vanilla ». Dans un cluster, chaque pod a sa propre IP, il n’y a donc pas de port mapping contre-intuitif à faire. Pour la découverte de service, plutôt que de se baser sur du DNS et ses TTLs embêtants, Kubernetes propose la notion de « Service » (très original comme nom) : une IP virtuelle fixe qui load-balance le trafic entrant vers les pods associés. Cette IP virtuelle est gérée par le kube-proxy, un process qui tourne sur chaque node et qui va gérer les règles IPTables pour « créer » cette IP virtuelle.
Talk 2 – Retour d’expérience GKE en production chez Clustree
Par Romain Vrignaud, Directeur Techinque @Clustree
Clustree a commencé a passer en production sur un cluster managé par GKE (Google Kubernetes Engine) en juillet. Avec une infrastrucutre micro-services, les principes de Kubernetes s’appliquent très bien.
Ils utilisent Shippable, une chaîne de CI en SaaS spécialisée pour Docker, pour gérer la construction de leurs containers et leur déploiement dans le cluster. Leurs développeurs sont responsables à 100% de leur application, y compris le MCO. L’équipe infra/ops apporte du conseil quand il y en a besoin sur des aspects plus système. Ils mettent aussi en œuvre tout le tooling qui va autour de cet environnement de travail (métrologie, monitoring, etc.).
Quelques problèmes rencontrés par Clustree avec Kubernetes : quelques bugs de jeunesse, notamment sur la gestion des volumes, ce qui leur fait dire que Kubernetes n’est pas encore prêt pour héberger de la donnée persistante. Ils ont aussi pris des machines trop petites (et GKE ne permet apparemment pas de changer cela facilement), et ont donc eu des problèmes de mémoire, avec des containers qui consomment trop.
Sont évoquées aussi de futures features du Kubernetes, avec notamment :
- Auto-scalling sur des métriques arbitraires,
- Ubernetes, un système qui permet de fédérer plusieurs cluster Kubernetes, possiblement à travers plusieurs cloud providers.
Talk 3 – Retour d’expérience Twistlock Security
Par Michael Withrom, de Twistlock
Twistlock est une solution SaaS de sécurité pour Docker et Kubernetes qui apporte plusieurs fonctionnalités très intéressantes :
- S’intègre avec une chaîne de CI classique (Jenkins ou TeamCity),
- Vérifie le contenu des containers (du système au framework applicatif) contre les CVE et CIS en temps réel,
- Permet de gérer des ACLs, personne par personne, namespace par namespace, sur un cluster Kubernetes, qui est un manque majeur aujourd’hui.
Article rédigé par Théo Chamley