Guide pour l'installation de GKE on-prem sur VMware

Dans l'univers du cloud hybride, Google Distributed Cloud (GDC), anciennement connu sous le nom d'Anthos, s'est imposé comme une solution de premier plan. Il promet d'étendre la puissance et l'agilité de Google Kubernetes Engine (GKE) directement dans votre data center. Pour de nombreuses entreprises, GDC sur VMware est la passerelle vers la modernisation applicative sans abandonner leurs investissements sur site.

Mais soyons honnêtes : le déploiement de GDC (ou GKE on-prem) n'est pas une simple formalité. C'est un exercice d'architecture qui exige une planification méticuleuse. En tant qu'experts Google Distributed Cloud, nous avons constaté que la majorité des échecs d'installation proviennent d'une phase de préparation insuffisante.

Ce guide n'est pas une simple copie de la documentation. Nous allons décortiquer le processus d'installation d'une configuration minimale, en mettant l'accent sur les pourquoi et les points de vigilance critiques que seul un expert GDC identifiera.

L'architecture GDC sur VMware : Les 3 piliers

Avant de taper la moindre commande, il est vital de comprendre les trois composants fondamentaux que nous allons construire.

1. Le poste de travail administrateur (Admin Workstation) : C'est une machine virtuelle (VM) dédiée dans votre vSphere qui servira de tour de contrôle. Elle héberge les outils CLI, comme gkeadm et gkectl, ainsi que les fichiers de configuration nécessaires pour créer et gérer vos clusters.
2. Le cluster d'administrateur (Admin Cluster) : C'est le cerveau de votre installation GDC on-prem. Il est lui-même un cluster Kubernetes qui gère le cycle de vie (création, mise à jour, suppression) de vos clusters d'utilisateur.
3. Le cluster d'utilisateur (User Cluster) : C'est ici que la magie opère. Ce cluster exécute vos charges de travail applicatives, exactement comme un cluster GKE standard dans le cloud.

Phase 1 : La planification, clé du succès avec Anthos

Ne sous-estimez jamais cette étape. Une installation de GKE on-prem réussie repose entièrement sur une planification rigoureuse de votre infrastructure existante.

Prérequis vSphere : Au-delà de la simple version

Vous avez besoin d'un environnement vSphere fonctionnel, avec vCenter Server et des hôtes ESXi. La documentation spécifie les versions minimales, typiquement 7.0u2+ ou 8.0+. Cependant, un expert regardera immédiatement la licence. Une licence vSphere Standard est suffisante pour une preuve de concept (POC) minimale. En revanche, une installation de production exige vSphere Enterprise Plus. Pourquoi ? Pour activer des fonctionnalités cruciales comme VMware DRS (Distributed Resource Scheduler) et les règles d'anti-affinité , qui garantissent la haute disponibilité de votre plan de contrôle GDC en répartissant les nœuds sur des hôtes physiques distincts.

L'autre point d'expertise concerne les permissions vCenter. N'utilisez jamais un compte administrateur global pour votre installation. Un expert GDC travaillera avec votre administrateur vSphere pour créer des rôles personnalisés avec les privilèges minimums requis, segmentés par objet vSphere (Datacenter, Cluster, Datastore, Réseau). C'est une question fondamentale de sécurité et de conformité.

Le point de bascule : La planification des adresses IP

C'est ici que 90% des déploiements échouent. GDC en mode "statique" (le plus courant pour une installation minimale avec l'équilibreur de charge MetalLB intégré ) exige une planification IP exhaustive. Vous ne pouvez pas inventer ces adresses au fur et à mesure. Vous devez définir et réserver avant de commencer :

• Une adresse IP pour le poste de travail administrateur.
• Trois adresses IP pour les nœuds du plan de contrôle du cluster d'administrateur.
• Une adresse IP pour le nœud du plan de contrôle du cluster d'utilisateur.
• Plusieurs adresses IP pour les nœuds de calcul (workers) du cluster d'utilisateur .
• Une adresse IP virtuelle (VIP) pour le serveur d'API du cluster d'administrateur.
• Une adresse IP virtuelle (VIP) pour le serveur d'API du cluster d'utilisateur.
• Une adresse IP virtuelle (VIP) pour l'entrée Ingress du cluster d'utilisateur.
• Une plage d'adresses IP virtuelles pour les services de type LoadBalancer.

De plus, vous devez définir vos plages CIDR pour les Pods et les Services de chaque cluster. Ces plages ne doivent absolument pas chevaucher vos réseaux existants (VMs, serveurs vCenter, DNS, etc.) pour éviter des cauchemars de routage .

Phase 2 : Configurer la connexion au cloud Google

Votre installation sur site doit communiquer avec Google Cloud pour télécharger les composants, s'enregistrer et être gérée.

Vous devez d'abord choisir un projet Google Cloud et y activer une série d'APIs essentielles. Les plus importantes sont gkeonprem.googleapis.com (l'API GKE On-Prem), gkehub.googleapis.com (pour enregistrer vos clusters dans un "Fleet") et anthos.googleapis.com.

Ensuite, vient la gestion des identités via les comptes de service (Service Accounts). C'est un point critique. Vous devez en créer manuellement deux:

1. Le compte de service d'accès aux composants (component-access-sa) : C'est lui qui a les droits (comme serviceusage.serviceUsageViewer) pour télécharger les binaires et images de GDC depuis Artifact Registry .
2. Le compte de service de journalisation d'audit (audit-logging-sa) : Il permet à vos clusters on-prem d'envoyer leurs journaux d'audit Kubernetes directement à Google Cloud Audit Logs.

Créez les clés JSON pour ces comptes, elles seront bientôt nécessaires. D'autres comptes de service, comme connect-register et logging-monitoring, seront créés automatiquement par l'outil d'installation gkeadm.

Phase 3 : Création du poste de travail administrateur

Le déploiement commence. Depuis votre machine locale (où gcloud est installé ), vous téléchargerez l'exécutable gkeadm.

La création du poste de travail se fait via deux fichiers de configuration. D'abord, credential.yaml, qui contient simplement vos identifiants vCenter. Ensuite, le fichier principal admin-ws-config.yaml. Ce YAML décrit à gkeadm votre environnement vSphere (datacenter, datastore, réseau) et les détails réseau de la VM du poste de travail (son IP statique, la passerelle, les serveurs DNS) .

Une fois ces fichiers remplis, vous lancez la commande ./gkeadm create admin-workstation. Cet outil va alors se connecter à vCenter, créer la VM, y installer les outils, et, comme mentionné, créer les comptes de service restants dans GCP.

Phase 4 : Déployer le cerveau, le cluster d'administrateur

Connectez-vous en SSH au poste de travail administrateur que vous venez de créer. Vous y trouverez des modèles de configuration, dont le crucial admin-cluster.yaml.

C'est le fichier de configuration le plus dense. Vous devez le remplir avec toutes les informations planifiées : les détails vCenter , les plages CIDR des Pods et Services , la configuration de l'équilibreur de charge MetalLB, les 3 adresses IP statiques pour les nœuds du plan de contrôle du cluster admin , la VIP de son serveur d'API , et les chemins vers les différents fichiers de clés JSON des comptes de service.

Avant la création, une étape indispensable est d'importer les images des OS (les modèles de VM) dans vSphere. Cela se fait avec gkectl prepare --config admin-cluster.yaml.

Enfin, lancez la création avec gkectl create admin --config admin-cluster.yaml. Ce processus est long. Il provisionne trois VM, y installe un cluster Kubernetes haute disponibilité, déploie les opérateurs GDC, et enregistre ce cluster auprès de Google Cloud. Une fois terminé, vous disposez d'un fichier kubeconfig local pour interagir avec votre nouveau cluster d'administrateur.

Étape suivante : Votre premier cluster utilisateur

Votre cluster d'administrateur est l'usine ; il est maintenant prêt à construire des clusters d'utilisateur. Le processus est similaire, en utilisant un fichier user-cluster.yaml ou, de manière plus moderne, en utilisant directement la gcloud CLI, car votre cluster admin est désormais géré par l'API GKE On-Prem. Une commande comme gcloud container vmware clusters create ... pilotera votre cluster d'administrateur on-prem pour qu'il déploie un nouveau cluster utilisateur.

Ce que nous avons couvert est l'installation "minimale". Le véritable travail d'un expert GDC / Anthos commence ici : configurer l'équilibrage de charge avancé (BGP avec MetalLB ou intégration F5), sécuriser les flux, mettre en place l'authentification OIDC, gérer les mises à niveau et assurer la surveillance à l'échelle de la production.

Si cette architecture et ce processus vous semblent complexes, c'est qu'ils le sont. Assurer la robustesse de votre fondation cloud hybride est notre métier. N'hésitez pas à contacter un expert pour sécuriser et accélérer votre parcours vers Google Distributed Cloud.