Présentation de Distributed Cloud (logiciel uniquement) pour VMware

Distributed Cloud (logiciel uniquement) pour VMware vous permet de déployer et de gérer des clusters Google Kubernetes Engine (GKE) dans un environnement VMware vSphere. Vous pouvez exécuter et mettre à niveau des applications conteneurisées dans votre centre de données tout en utilisant les fonctionnalités et l'infrastructure Google Cloud .

Pour exécuter des clusters logiciels uniquement directement sur des serveurs physiques, consultez la présentation de Distributed Cloud (logiciel uniquement) pour Bare Metal.

Pourquoi utiliser Distributed Cloud (logiciel uniquement) pour VMware ?

L'exécution de Distributed Cloud (logiciel uniquement) pour VMware sur votre infrastructure vSphere existante vous permet de moderniser vos applications avec GKE tout en conservant la plate-forme de virtualisation, le stockage et les processus opérationnels que vos équipes utilisent déjà.

Intégration à votre environnement vSphere

Google Distributed Cloud exécute les nœuds de cluster en tant que machines virtuelles dans votre environnement vCenter existant. Vous pouvez ainsi ajouter des charges de travail conteneurisées aux hôtes vSphere que vous utilisez déjà. Les clusters stockent les données dans des datastores vSphere sauvegardés par vSAN, VMFS ou NFS, et vous pouvez attribuer différents datastores à des pools de nœuds individuels. Le pilote CSI (Container Storage Interface) vSphere provisionne des volumes persistants pour les charges de travail avec état. Pour en savoir plus, consultez Stockage.

Gestion centralisée avec des données sur site

Gérez, surveillez et dépannez les clusters depuis la console Google Cloud , la Google Cloud CLI ou Terraform à l'aide de l'API GKE On-Prem, sans vous connecter au poste de travail administrateur. Vos applications et vos données d'entreprise restent dans votre centre de données. Google Cloud ne reçoit que les métadonnées du cluster, ainsi que les informations d'état et d'utilisation. Pour en savoir plus, consultez Données qui restent dans votre centre de données.

Fiabilité et opérations d'entreprise

Google Distributed Cloud inclut des fonctionnalités opérationnelles prêtes pour la production :

  • Haute disponibilité : les clusters d'administrateur et les plans de contrôle des clusters d'utilisateur à haute disponibilité utilisent trois nœuds de plan de contrôle. Vous pouvez ainsi administrer votre environnement même en cas de défaillance d'un nœud.
  • Réparation automatique des nœuds : des vérifications d'état périodiques détectent les nœuds non opérationnels, et la réparation automatique des nœuds les répare automatiquement. Cette fonctionnalité est activée par défaut.
  • Autoscaling de cluster : l'autoscaler de cluster ajoute ou supprime des nœuds dans un pool de nœuds en fonction des requêtes de ressources de vos charges de travail.
  • Équilibrage de charge flexible : utilisez l'équilibreur de charge MetalLB groupé, qui s'exécute sur les nœuds de votre cluster, ou configurez un équilibreur de charge tiers tel que F5 BIG-IP ou Citrix. Pour en savoir plus, consultez Présentation de l'équilibrage de charge.

Fonctionnement

Google Distributed Cloud étend GKE pour vous permettre de créer des clusters sur des serveurs physiques dans un environnement vSphere. Vous gérez ces clusters sur site dans Google Cloud conjointement à vos clusters cloud, dans le cadre d'un parc unifié.

Dans les clusters GKE exécutés dans Google Cloud, Google gère le plan de contrôle et l'infrastructure réseau Kubernetes. Pour les clusters Google Distributed Cloud exécutés dans votre centre de données, Google Cloud fournit des logiciels d'administration et de plan de contrôle qui sont téléchargés et déployés sur vos machines virtuelles vSphere dans le cadre des processus d'installation et de mise à niveau.

Le schéma suivant illustre l'architecture d'une installation terminée avec un cluster d'administrateur et un cluster d'utilisateur :

Schéma d'un cluster d'administrateur et d'un cluster d'utilisateur
Architecture Google Distributed Cloud sur VMware avec un cluster d'administrateur et un cluster d'utilisateur

Composants clés

Les composants suivants constituent une installation de Distributed Cloud (logiciel uniquement) pour VMware :

  • Cluster d'administrateur : gère un ou plusieurs clusters d'utilisateur. Les clusters d'administrateur se composent d'un ou de plusieurs nœuds de plan de contrôle exécutés sur des machines virtuelles dédiées.
  • Cluster d'utilisateur : exécute vos charges de travail conteneurisées. Chaque cluster d'utilisateur se compose d'au moins un nœud de plan de contrôle et d'un ou de plusieurs nœuds de calcul.
  • Poste de travail administrateur : machine virtuelle dédiée qui inclut les fichiers de configuration du cluster et les outils de gestion :
    • gkectl : crée, met à jour et gère les déploiements de clusters.
    • kubectl : interagit avec les clusters d'administrateur et d'utilisateur pour gérer les charges de travail.
  • ConsoleGoogle Cloud  : interface Web dans Google Cloud permettant d'afficher l'état du cluster et d'effectuer des opérations de cycle de vie sans se connecter au poste de travail administrateur.
  • Adresses IP virtuelles : adresses IP virtuelles configurées lors de l'installation. Les administrateurs et les développeurs de clusters utilisent kubectl et des adresses IP virtuelles de plan de contrôle pour accéder aux plans de contrôle des clusters d'administrateur et d'utilisateur. Les utilisateurs et les développeurs d'applications utilisent des adresses IP virtuelles Service et Ingress pour accéder aux charges de travail et les exposer, respectivement. Pour en savoir plus, consultez Planifier vos adresses IP.

Se connecter au parc

Tous les clusters d'utilisateur sont membres d'un parc, qui est un regroupement logique de clusters Kubernetes offrant une gestion unifiée dans tous les environnements. Les parcs vous permettent d'afficher les clusters ensemble dans la console Google Cloud et d'utiliser les fonctionnalités de parc pour gérer, administrer et exploiter des charges de travail à grande échelle.

Chaque cluster se connecte à Google Cloud via l'agent Connect, qui se déploie automatiquement lors de l'installation du cluster. L'appartenance au parc détermine également la facturation de Distributed Cloud (logiciel uniquement) pour VMware.

Tarifs

Les clusters sur site créés à l'aide de Google Distributed Cloud sont facturés par processeur virtuel. Pour activer la facturation, activez l'API Anthos dans votre projet Google Cloud.

Pour obtenir des informations complètes sur les tarifs, y compris sur la façon de contacter le service commercial, consultez la page Tarifs de Google Kubernetes Engine.

Versions

Cette documentation couvre toutes les versions prises en charge de Google Distributed Cloud. Le cas échéant, Google conserve également dans cette documentation des informations limitées pour les anciennes versions non compatibles.

Pour en savoir plus sur les versions compatibles et les règles de publication, consultez les ressources suivantes :

À 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. Lorsqu'une nouvelle fonctionnalité est disponible, la version compatible de la fonctionnalité est documentée.

La documentation des versions 1.16 et antérieures est archivée à l'adresse 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 :

  • Conteneurs, pods, PersistentVolumes et 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 etcd autosignées, les clés du cluster d'utilisateur et les autorités de certification (CA) du cluster.
  • Secrets d'application, jetons OAuth, clés privées SSH, identifiants de Container Registry, identifiants vCenter et F5 BIG-IP, et fichiers de clés de compte de service, stockés dans etcd ou 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 leur envoi :

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)
  • Identité du cluster : projet Google Cloud , nom de l'appartenance au parc, UID du cluster, clés publiques, version de Kubernetes, taille du cluster et configuration du fournisseur d'identité.
  • Données Kubernetes demandées à partir de la console Google Cloud ou de la passerelle Connect.
  • Votre jeton Kubernetes chiffré dans votre profil utilisateur jusqu'à ce que vous vous déconnectiez de la console Google Cloud .
 Gérez 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)
  • Nom, UID, description, annotations, version, état du cycle de vie et adresse IP virtuelle du plan de contrôle.
  • Noms des pools de nœuds, paramètres d'adresse IP ou DHCP des nœuds, CIDR des pods et des services, adresses IP virtuelles de l'équilibreur de charge, paramètres de l'équilibreur de charge.
  • Adresse vCenter, centre de données, cluster, pool de ressources, datastore, dossier et nom de la règle de stockage (pas les identifiants vCenter).
  • Adresses e-mail des administrateurs du cluster.
 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)
  • Métriques : utilisation du processeur, de la mémoire, du disque et du réseau, métriques kubelet et kube-state-metrics pour les nœuds et les pods système.
  • Journaux de conteneurs et résultats des vérifications d'état de tous les composants du cluster d'administrateur, ainsi que des espaces de noms de cluster d'utilisateur kube-system, gke-system, gke-connect, istio-system et config-management-system.
  • Métadonnées : noms et étiquettes des nœuds, des pods, des déploiements et des services.
 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 couverture complète du service client et du 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.

Étapes suivantes