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 également disponible sous forme de produit logiciel uniquement qui s'exécute sur votre propre matériel. Le logiciel Google Distributed Cloud peut être installé sur VMware ou sur solution bare metal. Ce guide est destiné au logiciel Google Distributed Cloud qui s'exécute directement sur vos machines Bare Metal.
Le logiciel 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.
Pourquoi utiliser Distributed Cloud (logiciel uniquement) pour Bare Metal ?
L'exécution de Distributed Cloud (logiciel uniquement) pour Bare Metal sur votre infrastructure d'entreprise existante offre un accès direct au matériel, une sécurité d'entreprise et une gestion centralisée dans tous les environnements.
Contrôle direct du matériel et performances
Le déploiement direct sur des serveurs physiques vous permet de contrôler directement l'évolutivité, la latence et les performances des applications, tout en réduisant les coûts grâce à l'utilisation de votre infrastructure existante. Google Distributed Cloud gère le déploiement et l'état des applications dans vos centres de données d'entreprise existants pour un fonctionnement plus efficace. Vous pouvez optimiser les charges de travail pour des types de matériel spécialisés, tels que les GPU et les SSD, et exécuter des applications à faible latence en périphérie du réseau sans surcharge d'hyperviseur.
Sécurité au niveau du système d'exploitation
Comme vous contrôlez directement les systèmes d'exploitation et les configurations réseau de vos nœuds, vous pouvez personnaliser les règles de sécurité en fonction de vos exigences de conformité. Les clusters communiquent avec les API Google via des connexions sécurisées légères, ce qui élimine la complexité des machines virtuelles tout en conservant les contrôles de sécurité existants.
Gestion et surveillance centralisées
Gérez, surveillez et dépannez les clusters depuis la consoleGoogle Cloud à l'aide de Cloud Monitoring et de l'agent Connect. Cette visibilité centralisée vous aide à maintenir la fiabilité et à ajuster l'échelle des applications dans les centres de données distribués.
Fiabilité et opérations d'entreprise
Google Distributed Cloud inclut des fonctionnalités opérationnelles prêtes pour la production :
- Haute disponibilité : la compatibilité avec plusieurs nœuds de plan de contrôle vous permet d'administrer votre environnement même en cas de défaillance d'un nœud.
- Vérifications préliminaires automatisées : la validation intégrée permet de vérifier les configurations de votre matériel et de votre système d'exploitation avant l'installation.
- Équilibrage de charge intégré : les mécanismes d'équilibrage de charge de couche 4 et de couche 7 sont déployés automatiquement lors de la création du cluster.
- Maintenance de la base de données : la défragmentation automatisée (
etcddefrag) récupère de l'espace de stockage pour maintenir l'état et la stabilité deetcd.
Fonctionnement
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 s'exécutant dans votre centre de données, Google Cloud fournit des logiciels d'administration et de plan de contrôle que vous téléchargez et installez sur vos serveurs Linux physiques. Vous gérez ces clusters sur site dans Google Cloud conjointement à vos clusters cloud, dans le cadre d'un parc unifié.
Le schéma suivant illustre l'architecture d'une installation terminée avec un cluster d'administrateur et un cluster d'utilisateur :
Composants clés
Un déploiement Bare Metal logiciel uniquement comprend les composants suivants :
- Cluster d'administrateur : gère le cycle de vie des clusters d'utilisateur à l'aide de Kubernetes Resource Management (KRM). Le déploiement standard se compose d'un cluster d'administrateur qui gère le cycle de vie d'un ou de plusieurs clusters d'utilisateur. Un cluster d'administrateur se compose d'une ou de plusieurs machines Linux physiques qui servent de nœuds de plan de contrôle. Chaque machine de nœud de l'installation possède sa propre adresse IP.
- 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 nœud de calcul.
- Poste de travail administrateur : machine dédiée qui héberge les fichiers de configuration et les outils d'administration :
bmctl: crée, met à jour et gère des clusters.kubectl: interagit avec les clusters d'administrateur et d'utilisateur, et gère les charges de travail.
- API GKE On-Prem : API hébergée sur Google Cloudpour la gestion du cycle de vie des clusters. Les clients, tels que la console Google Cloud , la Google Cloud CLI et Terraform, vous permettent de gérer les clusters sur site sans vous connecter au poste de travail administrateur.
- ConsoleGoogle Cloud : fournit une interface Web pour votre projet Google Cloud, y compris les clusters sur site. La console Google Cloud affiche des métriques clés sur vos clusters pour vous aider à surveiller l'état des clusters et de votre parc.
- Adresses IP virtuelles : adresses IP virtuelles configurées lors de l'installation.
Les administrateurs et les développeurs de clusters utilisent
kubectlpour accéder aux plans de contrôle des clusters via des adresses IP virtuelles de plan de contrôle. 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.
Se connecter au parc
Les clusters d'utilisateur et, éventuellement, les clusters d'administrateur sont enregistrés dans un parc, qui est un regroupement logique de clusters Kubernetes permettant une gestion unifiée dans tous les environnements. 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 les clusters ensemble dans la consoleGoogle Cloud et utiliser les fonctionnalités compatibles avec les parcs 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 à un parc détermine également la facturation de Google Distributed Cloud.
Tarifs
Les clusters sur site créés avec Google Distributed Cloud sont facturés par processeur virtuel. Pour activer la facturation, activez l'API Anthos dans votre projet Google Cloud.
Pour en savoir plus sur les tarifs et les coordonnées de l'équipe commerciale, consultez la page Tarifs de Google Kubernetes Engine.
Versions
Pour en savoir plus sur les versions de Google Distributed Cloud, consultez la Politique de compatibilité avec les 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. Les différences au niveau des exigences et du comportement selon les versions sont indiquées dans la documentation. 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 numéroté pour la documentation de la version mineure précédente. Vous pouvez trouver la documentation archivée pour les versions 1.16 et antérieures en ajoutant le numéro de version mineure dans l'URL suivante :
https://cloud.google.com/anthos/clusters/docs/bare-metal/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.
Installer Distributed Cloud (logiciel uniquement) pour solution Bare Metal
Comme les clusters créés à l'aide de Google Distributed Cloud s'exécutent dans votre propre infrastructure, ils sont hautement configurables. Une fois que vous avez sélectionné le modèle de déploiement répondant 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, d'options d'adressage IP et de fonctionnalités de sécurité compatibles, d'options de connectivité, etc. La configuration d'un cluster implique de prendre des décisions avant et pendant l'installation. Cet ensemble de documentation comprend des guides pour aider votre équipe à choisir les fonctionnalités et les options qui vous conviennent. Pour vous assurer que votre installation répond aux besoins de votre organisation, consultez vos équipes réseau et d'application.
Où vos données sont-elles stockées ?
Lorsque vous exécutez Distributed Cloud sous forme logicielle uniquement pour solution Bare Metal, 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 Cloudsur 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, les backends de stockage local et les données traitées par vos applications.
- Le plan de contrôle (
kube-apiserver,kube-scheduleretkube-controller-manager) et la base de donnéesetcd, qui stocke tous vos objets Kubernetes. - Clés privées des autorités de certification (CA), y compris la CA du cluster, la CA
etcdet la CA du proxy frontal. L'espace de noms du cluster d'utilisateur du cluster d'administrateur stocke les autorités de certification du cluster d'utilisateur. - Les secrets d'application, les jetons OAuth, les clés privées SSH, les identifiants de Container Registry et les fichiers de clé de compte de service sont stockés dans
etcdou sur votre poste de travail administrateur. Elles ne sont pas envoyées à l'API GKE On-Prem, et l'instantané de diagnostic par défaut n'inclut pas les identifiants du cluster. - Votre fichier de configuration de cluster est stocké sur votre poste de travail administrateur. Si un cluster est enregistré dans l'API GKE On-Prem, certains paramètres sont envoyés. Pour en savoir plus, consultez Données envoyées à Google Cloud.
- Les journaux d'audit ne sont écrits sur le disque que si vous désactivez Cloud Audit Logs sur les nœuds du plan de contrôle.
- Si vous configurez un compte de service pour l'importation d'instantanés de diagnostic, le fichier est importé dans Cloud Storage. Vous pouvez choisir de partager ou non un instantané avec Cloud Customer Care.
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) |
|
Gérez les clusters depuis la consoleGoogle Cloud , la passerelle Connect et le parc avec l'agent Connect. | 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. Stockées par l'API GKE On-Prem dans la région définie dans gkeOnPremAPI.location, qui est définie par défaut sur clusterOperations.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 clusterOperations.projectID. Les métriques sont stockées dans la région définie dans clusterOperations.location, et les journaux suivent vos paramètres de routeur de journaux. |
Activé pour les journaux système et les métriques, ce qui est nécessaire 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 (audit-proxy) : 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 votre projet Google Cloud , dans le bucket _Required, et conservés pendant 400 jours. |
On (Activé). Pour la désactiver, définissez clusterOperations.disableCloudAuditLogging sur true.
Les journaux d'audit ne sont alors conservés que sur les disques des nœuds du plan de contrôle. |
Étapes suivantes
Pour commencer à utiliser Google Distributed Cloud, consultez les guides suivants :
- Créer des clusters d'administrateur et d'utilisateur Google Distributed Cloud de démonstration sur des VM Compute Engine
- Planifier une installation de base sur votre matériel
- Créer des clusters de base sur votre matériel