Google annoncé la disponibilité du pilote automatique de Google Kubernetes Engine (GKE), un environnement Kubernetes entièrement géré et exploité pour les clients Google Cloud. L’infrastructure sous-jacente est complètement cachée aux utilisateurs tout en exposant l’environnement nécessaire à l’exécution des charges de travail natives du cloud.

Google Kubernetes Engine est l’un des premiers services d’orchestration de conteneurs gérés disponibles dans le cloud public. Depuis son lancement en 2015, Google a amélioré le service pour le rendre prêt pour l’entreprise. GKE Autopilot est la dernière initiative visant à accélérer l’adoption de Google Cloud et à créer une différenciation unique pour Google.

Comme toute plate-forme distribuée, Kubernetes comporte deux composants: le plan de contrôle et les nœuds de travail. Le plan de contrôle est responsable de la gestion de l’ensemble de l’infrastructure du cluster et des charges de travail qui y sont exécutées. Les nœuds agissent comme des bêtes de somme qui exécutent les applications client présentées sous forme de conteneurs.

Lorsque Kubernetes est devenu disponible en tant que service géré, les fournisseurs de cloud possédaient et géraient le plan de contrôle, qui est la partie critique de l’infrastructure du cluster. Étant donné que les nœuds de travail sont essentiellement un ensemble de machines virtuelles, ils ont toujours été accessibles aux utilisateurs. Dans GCE, les nœuds de calcul se traduisent en un ensemble d’instances Google Compute Engine pour les clients.

L’exécution d’un cluster Kubernetes géré dans le cloud comporte deux aspects. Le premier consiste à faire le bon choix de configuration de calcul, de stockage et de réseau, tandis que le second consiste à maintenir les nœuds de travail dans le cadre des opérations du jour 2. Le premier concerne la sélection de la bonne taille de VM, le choix de l’interface réseau du conteneur et le stockage de superposition. Une fois le cluster provisionné et en cours d’exécution, les clients doivent gérer et maintenir les nœuds de calcul. En fonction du système d’exploitation, du réseau et de la pile de stockage, ils peuvent devoir effectuer une maintenance continue, des correctifs et des mises à niveau des nœuds de travail. Bien qu’il s’agisse d’un service géré, l’orchestration de conteneurs laisse un peu de gestion et de configuration aux clients. Il est fermement ancré dans la philosophie de la responsabilité partagée applicable à la plupart des services de cloud public.

Avec GKE Autopilot, Google souhaite gérer l’ensemble de l’infrastructure Kubernetes et pas seulement le plan de contrôle. Cela réduit considérablement les décisions à prendre lors de la création du cluster. La pile choisie pour GKE Autopilot par Google possède le meilleur des composants de la race, tels que des VM protégées, un réseau public / privé basé sur VPC, un stockage basé sur CSI, entre autres.

GKE Autopilot vise à simplifier les choix de provisionnement d’une infrastructure de cluster sécurisée et de niveau production. Il y a très peu de boutons et de commutateurs disponibles lors de la mise en service d’un cluster GKE Autopilot. Vous n’avez même pas à décider du nombre de nœuds de calcul et de leur configuration lors de la création du cluster. Le service de pilote automatique déterminera la meilleure configuration de sa catégorie et la taille idéale de la flotte au moment de l’exécution en fonction des caractéristiques de la charge de travail que vous avez déployée.

L’aspect le plus excitant de GKE Autopilot est la facturation basée sur l’unité de déploiement, le pod.

GKE Standard, l’avatar original de GKE, comporte des frais de gestion de cluster fixes plus le coût des instances GCE. Peu importe le nombre de pods – l’unité fondamentale de déploiement dans Kubernetes – que vous exécutez dans le cluster. Vous êtes toujours facturé pour le nombre d’instances GCE.

Avec GKE Autopilot, l’unité fondamentale de déploiement utilisée pour calculer la facture passe de la VM à un pod. Tant que les frais de gestion de cluster fixes restent, vous ne paierez que les ressources de calcul, de mémoire et de stockage consommées par les pods déployés. Par défaut, GKE Autopilot attribue un demi-processeur, 2 Gio de RAM et 1 Gio de stockage à un pod. Bien sûr, cela peut être annulé en mentionnant explicitement les besoins en ressources dans la spécification du pod.

Dans les coulisses, GKE Autopilot met en œuvre une stratégie de mise à l’échelle automatique qui ajoute et supprime dynamiquement les nœuds de calcul pour répondre aux exigences de la charge de travail. Vous ne serez pas facturé pour les nœuds de calcul supplémentaires, car l’unité de déploiement et de facturation est basée sur le nombre de pods et non sur le nombre de nœuds.

GKE Autopilot amène Kubernetes-as-a-Service à un niveau supérieur en faisant abstraction complète de l’infrastructure. Il se rapproche d’un modèle de plate-forme en tant que service où les développeurs sont censés apporter leur code source et repartir avec une URL. J’attends que Google ajoute Istio et Knative à GKE Autopilot, qui apporte de véritables capacités de plate-forme, y compris la possibilité de passer à zéro.

GKE Autopilot est livré avec son propre ensemble de limitations. Si vous avez besoin d’un contrôle et d’une personnalisation absolus de l’environnement, GKE Standard reste le meilleur choix. Par exemple, la configuration de plates-formes de stockage tierces telles que Portworx by Pure Storage ou une stratégie réseau basée sur Tigera Calico n’est pas prise en charge par GKE Autopilot. L’ajout de nœuds avec des accélérateurs IA basés sur GPU ou TPU n’est pas disponible non plus. Le déploiement d’applications à partir du marché est une autre fonctionnalité absente de GKE Autopilot.

Les utilisateurs expérimentés avec des scénarios avancés continueront à utiliser GKE Standard tandis que GKE Autopilot devient le choix des utilisateurs Kubernetes pour la première fois.

Au moment du lancement, seules les fonctionnalités de surveillance Datadog et de GitLab CI / CD sont entièrement intégrées à GKE Autopilot. D’autres services tiers devraient être disponibles à l’avenir.

Il est intéressant de voir le changement dans l’unité de déploiement. Pendant longtemps, la VM est restée l’unité fondamentale de déploiement et de facturation. Avec l’introduction de Kubernetes gérés, les clusters sont devenus l’unité de déploiement. Des services tels que AWS Fargate pour EKS et GKE Autopilot, le pod est devenu le plus petit dénominateur commun en tant qu’unité de déploiement et de facturation.

Avec GKE Autopilot, Google a lancé une autre première dans le secteur qui supprime la complexité de l’exécution de charges de travail cloud natives tout en créant un facteur de différenciation fort pour sa plate-forme cloud.