Google Distributed Cloud est une solution matérielle et logicielle entièrement gérée qui étend l'infrastructure et les servicesGoogle Cloud à votre centre de données. Google Distributed Cloud est disponible dans des configurations connectées et sous air gap qui s'exécutent sur du matériel fourni par Google. Google Distributed Cloud est également disponible sous forme de produit logiciel uniquement qui s'exécute sur votre propre matériel, sur VMware ou sur Bare Metal. Ce guide est destiné au logiciel Google Distributed Cloud qui s'exécute sur votre propre matériel dans un environnement VMware vSphere.
Google Distributed Cloud est basé sur Google Kubernetes Engine (GKE), avec son propre package Kubernetes qui étend GKE pour une utilisation dans un environnement sur site. Avec Google Distributed Cloud, vous pouvez créer, gérer et mettre à niveau des clusters GKE sur site tout en utilisant les fonctionnalitésGoogle Cloud , et déployer et exploiter des applications conteneurisées sur vos clusters à grande échelle à l'aide de l'infrastructure de Google.
Une fois le logiciel Google Distributed Cloud installé, vous pouvez utiliser de nombreuses fonctionnalitésGoogle Cloud pour gouverner, gérer et exploiter des charges de travail conteneurisées à grande échelle. Pour en savoir plus sur les fonctionnalités disponibles sur VMware, consultez la présentation de GKE.
Cette page présente le fonctionnement de Google Distributed Cloud sur VMware, et vous fournit les informations dont vous avez besoin avant de procéder à une installation minimale ou de production.
Fonctionnement
Google Distributed Cloud étend GKE pour vous permettre de créer des clusters GKE dans un environnement vSphere sur votre propre site, et de les gérer dans Google Cloud conjointement à vos clusters GKE standards et à ceux hébergés dans d'autres environnements, dans le cadre d'un parc.
Étant donné que le logiciel Google Distributed Cloud s'exécute dans votre centre de données plutôt que surGoogle Cloud, vous devez installer des logiciels d'administration et de plan de contrôle en plus du logiciel GKE lui-même. Le logiciel exécuté dans votre centre de données est téléchargé lors du processus d'installation et de mise à niveau.
Le schéma suivant illustre le résultat simplifié d'une installation terminée.
Composants clés
Les composants suivants constituent une installation logicielle uniquement sur VMware de Google Distributed Cloud :
Un cluster d'utilisateur est l'endroit où s'exécutent les charges de travail qui implémentent vos applications, comme dans GKE sur Google Cloud. Les nœuds qui exécutent vos charges de travail sont appelés nœuds de calcul. Un cluster d'utilisateur comporte également un ou plusieurs nœuds de plan de contrôle. Dans le schéma précédent, le cluster d'utilisateur comporte un nœud de plan de contrôle.
Le cluster d'administrateur gère un ou plusieurs clusters d'utilisateur. Dans le schéma précédent, le cluster d'administrateur comporte trois nœuds de plan de contrôle.
Le poste de travail administrateur est une machine distincte qui inclut les outils dont les créateurs et les développeurs de clusters ont besoin pour gérer leur installation :
- L'exécution de
gkectlà partir du poste de travail administrateur vous permet de créer et de mettre à jour des clusters, et d'effectuer d'autres tâches d'administration. - L'exécution de
kubectlà partir du poste de travail administrateur vous permet d'interagir avec vos clusters d'administrateur et d'utilisateur, y compris de déployer et de gérer des charges de travail.
- L'exécution de
La console Google Cloud fournit une interface Web pour votre projet Google Cloud , y compris vos clusters sur VMware. Vous pouvez effectuer un sous-ensemble de tâches d'administration, y compris la création de clusters, à partir de la console Google Cloud , au lieu d'exécuter des commandes sur le poste de travail administrateur.
Les administrateurs et les développeurs de clusters utilisent
kubectlet des adresses IP virtuelles (VIP) pour accéder aux plans de contrôle des clusters d'administrateur et d'utilisateur. Vous configurez les adresses IP virtuelles lors de la création du cluster. Les utilisateurs et les développeurs qui appellent des charges de travail dans vos clusters d'utilisateurs utilisent des adresses IP virtuelles Service et Ingress. Chaque nœud de l'installation possède également sa propre adresse IP. Pour en savoir plus sur la planification des adresses IP pour Google Distributed Cloud, consultez Planifier vos adresses IP.
Se connecter au parc
Tous les clusters Google Distributed Cloud sont membres d'un parc : un regroupement logique de clusters Kubernetes. Les parcs facilitent la gestion de votre entreprise avec des groupes de clusters plutôt que des clusters individuels, et peuvent aider vos équipes à adopter les bonnes pratiques similaires à celles utilisées chez Google. Vous pouvez afficher et gérer les clusters de parc ensemble dans la console Google Cloud , et utiliser des fonctionnalités compatibles avec les parcs pour vous aider à gérer, gouverner et exploiter vos charges de travail à grande échelle. Vous pouvez consulter la liste complète des fonctionnalités de parc disponibles pour les environnements sur site.
La connexion de chaque cluster de parc à Google Cloud est gérée par un agent Connect, qui est déployé dans le cadre du processus d'installation de Google Distributed Cloud. Pour en savoir plus sur le fonctionnement de cet agent, consultez la présentation de l'agent Connect.
L'appartenance à un parc permet également de gérer la tarification de Google Distributed Cloud, comme décrit dans la section suivante.
Tarifs
Les clusters GKE sur site créés dans le cadre de Google Distributed Cloud sont facturés par processeur virtuel. Pour activer la facturation, vous devez activer l'API Anthos dans votre projet Google Cloud .
Pour en savoir plus sur les tarifs, y compris sur la façon de contacter le service commercial, consultez la page Tarifs de GKE.
Installer Google Distributed Cloud sur VMware
Étant donné que le logiciel Google Distributed Cloud s'exécute dans votre propre infrastructure, il est hautement configurable pour répondre aux besoins de votre organisation et de votre cas d'utilisation spécifiques : vous pouvez choisir parmi un éventail de modes d'équilibrage de charge, de configurations vSphere, d'options d'adressage IP, de fonctionnalités de sécurité, d'options de connectivité, etc. Cela signifie que la configuration de Google Distributed Cloud implique de prendre des décisions avant et pendant l'installation, en concertation avec vos équipes réseau, vSphere et d'application, afin de vous assurer que votre installation répond à vos besoins. Cet ensemble de documentation comprend des guides pour aider votre équipe à prendre ces décisions.
Toutefois, si vous avez simplement besoin de voir Google Distributed Cloud en action, nous fournissons également un chemin d'installation de base pour une petite installation de test dans laquelle nous avons fait beaucoup de ces choix pour vous, ce qui vous permet de mettre rapidement en place une charge de travail.
Dans chaque cas, le processus d'installation est le suivant :
- Planifiez votre installation. Au minimum, vous devez vous assurer que vous pouvez répondre aux exigences des ressources et de vSphere pour Google Distributed Cloud, ainsi que planifier vos adresses IP.
- Configurez votre environnement sur site pour qu'il soit compatible avec Google Distributed Cloud, y compris en configurant les objets d'inventaire vSphere et votre connexion à Google.
- Configurez les ressources Google Cloud , y compris le projet Google Cloud que vous utiliserez lors de la configuration et de la gestion de Google Distributed Cloud.
- Créez un poste de travail administrateur avec les ressources et les outils dont vous avez besoin pour créer des clusters.
- Créez un cluster d'administrateur pour créer, gérer et mettre à jour des clusters d'utilisateur.
- Créez des clusters d'utilisateur pour exécuter vos charges de travail.
Versions compatibles
Cette documentation couvre toutes les versions prises en charge de Google Distributed Cloud. Le cas échéant, nous conservons également dans cette documentation des informations limitées pour les anciennes versions non compatibles. Les différences au niveau des exigences et du comportement selon les versions sont indiquées dans la documentation. De même, lorsqu'une nouvelle fonctionnalité est disponible, la version compatible de la fonctionnalité est documentée.
Pour obtenir la liste des versions mineures compatibles et des correctifs disponibles, consultez la page Gestion des versions.
À partir de la version 1.29, nous ne créons plus de répertoire pour la version mineure précédente. Les différences de comportement sont indiquées dans la documentation. De même, lorsqu'une nouvelle fonctionnalité est disponible, la version compatible de la fonctionnalité est documentée.
Vous pouvez trouver la documentation complète d'une version antérieure en ajoutant le numéro de version mineure dans l'URL suivante :
https://cloud.google.com/anthos/clusters/docs/on-prem/VERSION/
Remplacez VERSION par une version mineure comprise entre 1.0 et 1.16, puis copiez l'URL dans la barre d'adresse de votre navigateur.
Où vos données sont-elles stockées ?
Lorsque vous exécutez Distributed Cloud (logiciel uniquement) pour VMware, vos clusters, vos applications et vos données d'entreprise restent dans votre centre de données. Par défaut, Google Distributed Cloud envoie des informations Google Cloud sur vos clusters, telles que leurs paramètres, leur état et leur utilisation, mais il n'envoie pas les données de votre application.
Données qui restent dans votre centre de données
Les données suivantes restent dans votre centre de données :
- Les conteneurs, les pods, les PersistentVolumes et les données traitées par vos applications.
- Tous les objets Kubernetes sont stockés dans votre plan de contrôle et votre base de données
etcd. - Le plan de contrôle du cluster d'administrateur stocke les clés privées
etcdautosignées, les clés de cluster d'utilisateur et les autorités de certification (CA) du cluster. - Les secrets d'application, les jetons OAuth, les clés privées SSH, les identifiants de Container Registry, les identifiants vCenter et F5 BIG-IP, ainsi que les fichiers de clé de compte de service, stockés dans
etcdou sur votre poste de travail administrateur. Elles ne sont pas envoyées à l'API GKE On-Prem et sont supprimées des instantanés de diagnostic. - Les fichiers de configuration de votre cluster d'administrateur, de votre cluster d'utilisateur et de vos identifiants sont stockés sur votre poste de travail administrateur.
- Les journaux d'audit sont écrits sur le disque des nœuds du plan de contrôle du cluster d'administrateur et des clusters d'utilisateur.
- Vous pouvez choisir d'importer des instantanés de diagnostic dans Cloud Storage.
Données envoyées à Google Cloud
Le tableau suivant indique ce qui est envoyé, comment ces données sont utilisées et stockées, et si vous pouvez désactiver cette fonctionnalité :
| Données | Quelles données sont envoyées | Utilisation et stockage | Par défaut |
|---|---|---|---|
| Connexion et enregistrement du parc ( gkehub.googleapis.com,
gkeconnect.googleapis.com) |
|
Gérer les clusters depuis la consoleGoogle Cloud , la passerelle Connect et le parc avec l'agent Connect. Votre kube-apiserver authentifie, autorise et consigne chaque requête dans un journal d'audit. |
Obligatoire |
| Paramètres et état du cluster ( gkeonprem.googleapis.com) |
|
Vous permet de gérer les clusters à l'aide de la console Google Cloud , de Google Cloud CLI ou de Terraform. L'API GKE On-Prem stocke ces données dans la région définie dans gkeOnPremAPI.location. |
Activé dans la version 1.16 et les versions ultérieures, si l'API GKE On-Prem est activée dans votre projet Google Cloud . Pour la désactiver, définissez gkeOnPremAPI.enabled sur false. |
| Utilisation de la facturation ( anthos.googleapis.com) |
Capacité de vCPU, nombre de nœuds et état des droits de licence. | Utilisé pour la mesure, la facturation et les vérifications de licence. | Obligatoire. Les enregistrements de facturation sont mis en mémoire tampon pendant une panne et envoyés ultérieurement. |
| Données de santé du système ( logging.googleapis.com, monitoring.googleapis.com,
opsconfigmonitoring.googleapis.com) |
|
Utilisé pour Cloud Monitoring, les vues d'état de la console Google Cloud et le dépannage par le service client. Stocké dans le projet Google Cloud défini dans stackdriver.projectID. Les métriques sont stockées dans la région stackdriver.clusterLocation, et les journaux suivent vos paramètres de routeur de journaux. |
Activé pour les journaux système et les métriques, ce qui est requis pour bénéficier d'une assistance complète du service client et d'une couverture SLA. Désactivé pour les journaux et les métriques d'application, sauf si vous définissez enableCloudLoggingForApplications ou enableGMPForApplications sur true dans la ressource Stackdriver. |
| Journaux d'audit ( anthosaudit.googleapis.com) |
Journaux d'audit des activités d'administration : qui a modifié quoi via kube-apiserver, et quand. Les entrées incluent l'heure, le cluster, l'hôte ou la VM, l'utilisateur ou le compte de service, le rôle RBAC, l'opération et le résultat. Les requêtes de lecture ne sont pas enregistrées. |
Stockés dans Cloud Audit Logs dans le projet Google Cloud défini dans cloudAuditLogging.projectID, dans le bucket _Required, et conservés pendant 400 jours. |
Facultatif. Pour l'activer, remplissez la section cloudAuditLogging. Pour les clusters d'administrateur, vous ne pouvez l'activer qu'au moment de la création. Pour la désactiver pour un cluster d'utilisateur, supprimez la section et mettez à jour le cluster. |
Étape suivante
- Pour démarrer une installation de démonstration de faisabilité minimale, consultez Configurer une infrastructure minimale.
- Pour découvrir les points à prendre en compte pour planifier une installation Google Distributed Cloud, démarrer une installation de production, ou les deux, consultez la présentation de l'installation.