L’essentiel sur Google Container Engine

Description de Kubernetes

Kubernetes est au coeur même de GKE. Si les développeurs n'ont pas besoin d'en connaître tous les rouages pour utiliser GKE, il est bon d'en comprendre les concepts.

Les applications conteneurisées ne reposent sur aucune infrastructure sous-jacente. Dans la mesure où tous les éléments requis (système d'exploitation, environnement d'exécution, bibliothèques, frameworks et dépendances) sont regroupés en une seule unité, il est possible de déployer plusieurs conteneurs sur un seul hôte ou de les distribuer sur plusieurs hôtes.

Tant que les conteneurs sont capables de découvrir les autres conteneurs dont ils dépendent, peu importe l'endroit où ils sont déployés. Ces conteneurs permettent de considérer l'infrastructure comme un simple produit parmi d'autres.

Une fois les machines virtuelles mises à disposition, elles peuvent être traitées comme une seule unité de traitement, ce qui rend possible l'exécution de clusters de conteneurs.

Si Docker gère efficacement le cycle de vie de chaque conteneur, les développeurs ont besoin d'un outil pour gérer l'intégralité d'un cluster de conteneurs. Les applications conteneurisées doivent disposer d'un mécanisme de découverte pour communiquer les unes avec les autres de façon dynamique. Par exemple, le conteneur de serveur Web doit pouvoir découvrir le conteneur de base de données pour s'y connecter. Kubernetes est l'outil chargé de la découverte et de la gestion du cycle de vie des applications conteneurisées s'exécutant en clusters.

Côté DevOps dans le Cloud, Kubernetes est l'outil de contrôle à distance qui permet de configurer et de gérer les clusters, qu'il s'agisse de quelques conteneurs seulement ou d'imposants déploiements faisant intervenir des centaines de milliers de conteneurs.

D'un point de vue purement technique, Kubernetes n'est pas lié au Cloud Google. Il peut être configuré de manière à travailler avec une grande diversité de fournisseurs d'infrastructures, qu'il s'agisse de bare mtal, d'hyperviseurs ou de Cloud public. Microsoft l'a intégré avec les VM Azure, alors que VMware cherche à le préparer pour vSphere vCloud Air. OpenShift de Red Hat fonctionne déjà avec Kubernetes.

Les solutions de type PaaS (plateforme en tant que service) reposent généralement sur Kubernetes. Les métadonnées requises pour définir les spécifications et les contraintes sont déclarées dans un fichier JSON. Les données détaillées concernant les contrôleurs, les services et les pods sont déclarées dans des fichiers individuels et soumises à Kubernetes via la ligne de commande.

Le serveur maître reçoit et analyse le fichier JSON pour décider du positionnement de chaque conteneur. Il est possible de définir des contraintes pour empêcher la mise à disposition de conteneurs incompatibles sur le même hôte. Tel est le cas notamment lors de la configuration maître/esclave des serveurs de base de données.

Avec Kubernetes, les conteneurs bénéficient d'une orchestration et d'une gestion du cycle de vie de type PaaS. Dans l'avenir, nous risquons de voir une multitude d'implémentations PaaS open source pilotées par Docker et Kubernetes.

Google Compute Engine

Annoncé lors de l'édition de novembre 2014 du Google Cloud Platform Live, GKE n'en est encore qu'à ses débuts. Il agit en tant que couche d'abstraction qui orchestre la gestion des conteneurs sur GCE.

GKE propose deux mécanismes pour déployer et gérer les conteneurs : une console Web et des outils de ligne de commande.

Dans la version actuelle, la ligne de commande s'avère plus puissante que la console Web. Bien que les conteneurs soient mis à disposition au-dessus des VM qui s'exécutent dans GCE, il n'est pas obligatoire de se connecter à l'une d'entre elles. Les outils de ligne de commande interagissent avec l'agent Kubernetes, nommé kubelet, qui s'exécute sur chaque VM.

Dans la mesure où GKE vise à simplifier Kubernetes, il propose une abstraction supplémentaire. La première version introduisait les concepts de cluster et de nœud.

Un cluster contient des nœuds maîtres et des nœuds « de travail ». Le nœud maître expose un point d'accès par une API pour la création et le contrôle des ressources de traitement. La console et les outils de ligne de commande communiquent avec lui lors de la réalisation des tâches.

Un nœud de travail d'un cluster est chargé de fournir aux applications les ressources de traitement et de mémoire nécessaires. Ils sont les moteurs du déploiement.

Un nœud appartient en principe à un seul et unique cluster et est mis à disposition lors de la création du cluster. Le nombre de nœuds créés représente la puissance de traitement cumulée des machines virtuelles sous-jacentes. Le cluster maître planifie le travail sur chaque nœud. Tous les nœuds du cluster reposent sur le même type d'instance de machine virtuelle.

Outre GKE, les développeurs peuvent également utiliser les machines virtuelles gérées et disponibles via Google App Engine. Elles combinent le meilleur des deux mondes, PaaS et IaaS, en s'appuyant sur les conteneurs Docker.

A l'allure où Docker améliore ses capacités d'orchestration et de gestion de clusters, il sera intéressant de voir en quoi le projet se distinguera des implémentations telles que Kubernetes.