Google nous offre donc une nouvelle manière de penser GKE à travers une offre allant plus loin dans le management des entités Kubernetes.
Nous allons voir en quoi consiste ce support supplémentaire et comment notre choix peut s'orienter vers tel ou tel mode de fonctionnement GKE.
Conçu pour alléger la charge opérationnelle liée à la gestion de cluster Kubernetes, Autopilot va mettre à disposition et gérer pour nous l’infrastructure liée au cluster GKE de façon prod ready, en ayant toutes les recommandations de GKE (nœuds, masters, pools de nœuds) tout en gérant son autoscaling, le réseau, la sécurité et son monitoring. Cela va nous permettre de nous focaliser sur la partie applicative au sein de Kubernetes sans nous soucier de la partie infrastructure. Ce nouveau mode s'apparente à un produit serverless, puisque nous ne nous occupons pas de la partie infrastructure.
Autopilot est compatible avec la plupart des APIs, outils et éléments du vaste écosystème Kubernetes. Nous restons dans GKE sans avoir à interagir avec les API, les CLI ou l'interface utilisateur de Compute Engine. En effet, les nœuds ne sont pas accessibles via Compute Engine, comme c'est le cas en mode Standard. Le cluster GKE autopilot est hébergé sur une infrastructure managée par Google sur laquelle nous n’avons pas la main.
Ce qui va aussi différencier les deux modes sera la facturation, car nous ne paierons plus les ressources au niveau des nœuds, le coût se fera uniquement sur les ressources consommées par les pods lors de leur exécution (processeur, mémoire, stockage, réseau).
Nous pouvons voir ci-dessous un schéma récapitulant les parties devant être gérées par l’utilisateur selon tel ou tel mode :
GKE standard :
GKE Autopilot :
Les fonctionnalités de cluster GKE suivantes ne sont pas compatibles avec les clusters Autopilot :
Voici le lien si vous voulez voir les différentes contraintes liées à l’utilisation de la fonctionnalité Autopilot sont listées ici :
Autopilot ne fonctionne pas avec les services suivants :
Les ressources pour les pods sont aussi limitées avec le mode Autopilot, mais restent largement suffisantes pour les cas usuels. Les processeurs virtuels des pods sont disponibles par incrément de 0,25 processeur virtuel. Outre les valeurs minimales, le ratio entre le processeur et la mémoire doit être compris entre 1 processeur virtuel pour 1 Gio au minimum et 1 processeur virtuel pour 6,5 Gio au maximum. Les ressources se trouvant en dehors des plages de ratio autorisées sont mises à l'échelle :
S’il n’y a aucune valeur définie dans la spécification des pods (ressources quota et limite) , Autopilot va appliquer par défaut ces valeurs à vos pods :
Il existe deux raisons principales pour lesquelles nous pouvons préférer le mode de fonctionnement standard au mode Autopilot :
Nous avons vu les différences techniques entre les différents modes. Abordons maintenant l’aspect tarification. Pour rappel avec Autopilot on ne paye qu’à l’utilisation de ressources au niveau pods.
Les frais de gestion des clusters de 0,10 $ par cluster et par heure (facturés à la seconde) s'appliquent à tous les clusters GKE indépendamment du mode de fonctionnement, de la taille ou de la topologie du cluster.
Faisons un petit comparatif entre les deux modes GKE. (cette simulation de prix a été faite via le simulateur de prix de GCP mis à jour le 13 mai 2021).
Pour le cluster GKE en mode standard nous sommes partis sur 3 nœuds dans un pools de nœuds basé sur la région Belgique avec l’instance type suivante : n1-standard-4 (4CPU et 15GB de RAM) pour un nœud. Puisque nous disposons de 3 nœuds nous avons donc 12 CPU et 45 GB de RAM au total avec une exécution de ses nœuds 24/24h 7/7j. Voici le résultat de la simulation pour GKE en mode standard :
Côté GKE Autopilot nous sommes partis sur 12 réplicas de pods avec une consommation de 1 CPU et 3.75 GB de RAM tournant 24/24h et 7/7j, avec 12 réplicas nous arrivons aux même valeurs CPU et RAM que sur le GKE en mode standard, voici le résultat du simulateur pour GKE Autopilot :
En comparant les 2 résultats, à temps d'exécution et ressources égales, nous sommes à 265.39 euros mensuel pour le cluster GKE en mode standard contre 357.87 euros pour le cluster GKE Autopilot.
L’aspect managé du mode Autopilot de GKE se ressent dans la facture. Du moins sur le papier.
Dans la réalité, cela est moins vrai car nous aurons à disposition des nœuds qui n'utiliseront pas l'entièreté de leurs ressources comme dans notre exemple. La calculatrice ne permet pas de prendre en compte ce non déterminisme d’accès aux ressources et cela avantage GKE classique.
Si nous prenons l’exemple avec un nœud qui monte sur le cluster GKE standard et que son utilisation est à peine de 2%, nous paierons quand même 100% des ressources allouées au nœud même s’il n’en utilise que 2 ou 10%, ce qui au final peut entraîner un coût plus élevé ou au même prix que GKE Autopilot.
Bien sûr, nous pouvons gérer le profil d’autoscaling que nous voulons avoir pour que les ressources soient bien réparties, mais nous aurons toujours une partie des ressources non utilisées que nous paierons quand même.
Avec GKE Autopilot nous n’allons payer que les ressources utilisées et non allouées pour un nœud ce qui peut changer rapidement la perspective au niveau du prix final. Toute cette optimisation vous est offerte par défaut sur Autopilot, là où GKE classique vous imposera de négocier des committed discount ou de vous baser sur des instances préemptibles et donc de gérer de la complexité opérationnelle supplémentaire.
Pour créer un cluster GKE avec le mode Autopilot nous devons aller sur la console GCP, après nous irons sur le service “Kubernetes Engine”.
Après avoir cliqué sur “Create”, nous avons la fenêtre de dialogue suivante afin de choisir le type de cluster GKE que nous souhaitons :
Puis, après avoir cliqué sur “Configure” pour Autopilot nous aurons la fenêtre suivante :
On remarque qu’il y a déjà beaucoup moins de possibilités que lors de la création d’un cluster GKE en mode standard. Nous ne pouvons créer un cluster GKE Autopilot qu’en mode régional (limitations de GKE Autopilot), on a alors le choix entre un cluster public ou privé. Dans “Networking Options”, nous pouvons définir la taille que nous voulons utiliser pour les ranges d’ip des pods et des services. La seule autre option que nous pouvons configurer est la plage de maintenance pour le cluster.
Dans la ressource “google_container_cluster” il nous suffit de mettre cet argument “enable_autopilot” avec la valeur à "true" (cette option est sortie dans Terraform il y a 1 mois dans la version du provider google suivant : v3.63.0) comme sur l’exemple ci-dessous :
resource "google_container_cluster" "primary" {
name = "my-gke-cluster"
location = "us-central1"
remove_default_node_pool = true
initial_node_count = 1
enable_autopilot = true
}
resource "google_container_node_pool" "primary_preemptible_nodes" {
name = "my-node-pool"
location = "us-central1"
cluster = google_container_cluster.primary.name
node_count = 1
node_config {
machine_type = "e2-medium"
}
}
Voici la commande de création d’un cluster GKE en mode Autopilot via la commande line de GCP :
gcloud container clusters create-auto CLUSTER_NAME \
--region REGION \
--project PROJECT_ID
Si nous regardons maintenant la commande pour la création d’un cluster GKE en mode standard, nous avons :
gcloud container clusters create cluster-name \
--release-channel channel \
--zone compute-zone \
--project PROJECT_ID \
--node-locations compute-zone,compute-zone,[...]
Si nous comparons en détail, il doit y avoir de nombreux arguments différents mais la commande reste principalement la même.
Le nouveau mode GKE Autopilot est intéressant car il propose de nouvelles perspectives qui peuvent permettre à des entreprises de partir plus rapidement sur Kubernetes sans se soucier de la partie infrastructure et de sa gestion. Cela permet aussi un suivi de sa consommation au plus proche de la réalité. Malgré tout, cela ajoute aussi son lot de contraintes. Je dirais que le choix entre tel ou tel mode dépendra du niveau d’expertise et des besoins du projet, comme toujours.