Cette page décrit le fonctionnement de Google Distributed Cloud, y compris des informations sur son infrastructure, son matériel, son stockage et ses capacités de mise en réseau.
Google Distributed Cloud se compose des éléments suivants :
- L'infrastructure Distributed Cloud. Google fournit, déploie et gère le matériel Distributed Cloud, y compris la gestion à distance par une équipe Google dédiée.
- Le service Distributed Cloud. Ce service vous permet de gérer vos clusters et pools de nœuds Distributed Cloud à l'aide de la Google Cloud CLI et de l'API Distributed Cloud Edge Container.
Les clusters Distributed Cloud sont enregistrés dans votre parc et vous pouvez utiliser l'outil CLI Kubernetes
kubectlpour interagir avec eux.
Infrastructure de cloud distribué
Google fournit, déploie, exploite et gère un rack de matériel dédié qui exécute votre zone Distributed Cloud. Ce matériel se compose de serveurs montés en rack et de deux commutateurs top-of-rack (ToR) qui interconnectent les machines à votre réseau local. Les nœuds Distributed Cloud qui exécutent vos charges de travail s'exécutent exclusivement sur ce matériel.
Le matériel exécute un certain nombre de nœuds regroupés dans des pools de nœuds, que vous pouvez attribuer à des clusters dans votre zone Distributed Cloud. Vous pouvez configurer votre réseau de sorte que les charges de travail exécutées sur des clusters Distributed Cloud ne soient disponibles que pour vos utilisateurs locaux ou accessibles depuis Internet. Vous pouvez également configurer votre réseau pour autoriser uniquement les nœuds Distributed Cloud à utiliser les ressources locales ou à communiquer avec les charges de travail, telles que les instances de machine virtuelle (VM) Compute Engine et les pods Kubernetes exécutés dans un réseau de cloud privé virtuel (VPC) via une connexion réseau Cloud VPN sécurisée à un réseau VPC.
Gestion du cloud distribué
Les nœuds Distributed Cloud ne sont pas des ressources autonomes et doivent rester connectés à Google Cloud à des fins de gestion et de surveillance du plan de contrôle. Les nœuds du plan de contrôle Distributed Cloud sont hébergés dans la région Google Cloud désignée. Les nœuds Distributed Cloud sur site nécessitent une connexion réseau constante à Google Cloud.
Google gère à distance les machines physiques et les commutateurs ToR qui constituent votre installation Distributed Cloud. Cela inclut l'installation de mises à jour logicielles et de correctifs de sécurité, ainsi que la résolution des problèmes de configuration. Votre administrateur réseau peut également surveiller l'état et les performances des clusters et des nœuds Distributed Cloud, et collaborer avec Google pour résoudre les éventuels problèmes.
Une fois que Google a déployé le matériel Distributed Cloud à l'emplacement désigné, l'administrateur de votre cluster peut commencer à configurer le cluster Distributed Cloud de la même manière qu'un cluster Kubernetes classique. Ils peuvent attribuer des machines à des pools de nœuds, et des pools de nœuds à des clusters, et accorder l'accès aux propriétaires d'applications selon les besoins de leurs rôles. Toutefois, l'administrateur du cluster doit tenir compte des limites de traitement et de stockage des machines de votre rack Distributed Cloud, et planifier la configuration du cluster et de la charge de travail en conséquence.
Distributed Cloud fournit une API pour configurer les clusters et les pools de nœuds.
Accès à la zone Distributed Cloud
Vous pouvez configurer votre réseau pour autoriser le niveau d'accès souhaité à votre zone Distributed Cloud, à la fois depuis votre réseau local et depuis Internet.
Vous pouvez également accorder à votre zone Distributed Cloud l'accès aux servicesGoogle Cloud en la connectant à votre réseau VPC. Distributed Cloud utilise Cloud VPN pour se connecter aux points de terminaison des services Google. Votre administrateur réseau doit configurer votre réseau pour autoriser cette opération.
Personnes utilisant Distributed Cloud
Les personas suivants sont impliqués dans le déploiement et le fonctionnement de votre zone Distributed Cloud :
Technicien Google sur le terrain : Livrent, installent et activent le matériel Distributed Cloud à l'emplacement désigné. Votre administrateur réseau collabore avec les techniciens Google pour brancher le matériel à votre source d'alimentation et le connecter à votre réseau.
Ingénieur en fiabilité des sites (SRE) chez Google. Surveille et gère le matériel Distributed Cloud. Cela inclut la résolution des problèmes de configuration, l'installation de correctifs et de mises à jour, et le maintien de la sécurité.
Administrateur réseau Configure et maintient la connectivité réseau et le contrôle des accès entre le matériel Distributed Cloud et votre réseau local. Cela inclut la configuration de vos règles de routage et de pare-feu pour vous assurer que tous les types de trafic réseau requis peuvent circuler librement entre le matériel Distributed Cloud, Google Cloud, les clients qui consomment vos charges de travail Distributed Cloud, les dépôts de données internes et externes, etc. L'administrateur réseau doit avoir accès à la console Google Cloud pour surveiller l'état de vos machines Distributed Cloud. L'administrateur réseau configure également les fonctionnalités de mise en réseau Distributed Cloud.
Administrateur du cluster. Déploie et gère les clusters Distributed Cloud au sein de votre organisation. Cela inclut la configuration des autorisations, la journalisation et le provisionnement des charges de travail pour chaque cluster. L'administrateur de cluster attribue des nœuds à des pools de nœuds, et des pools de nœuds à des clusters Distributed Cloud. L'administrateur de cluster doit comprendre les différences opérationnelles entre le cluster Distributed Cloud et un cluster Kubernetes traditionnel, telles que les capacités de traitement et de stockage du matériel Distributed Cloud, afin de configurer et de déployer correctement vos charges de travail.
Propriétaire de l'application : Ingénieur logiciel chargé de développer, déployer et/ou surveiller une application s'exécutant sur un cluster Distributed Cloud. Les propriétaires d'applications qui possèdent des applications sur un cluster Distributed Cloud doivent comprendre les limites de taille et d'emplacement des clusters, ainsi que les conséquences du déploiement d'une application en périphérie, telles que les performances et la latence.
Matériel Distributed Cloud
La figure 1 illustre une configuration Distributed Cloud typique.
Les composants d'une installation Distributed Cloud sont les suivants :
Google Cloud : le trafic entre votre installation Distributed Cloud et Google Cloud inclut le trafic de gestion du matériel, le trafic du plan de contrôle et le trafic Cloud VPN vers les services Google Cloudet toutes les charges de travail que vous y exécutez. Il peut également inclure le trafic VPC, le cas échéant.
Internet Le trafic chiffré du plan de gestion et de contrôle entre votre installation Distributed Cloud et Google Cloudtransite sur Internet. Distributed Cloud n'accepte pas les connexions Internet par proxy.
Réseau local : Réseau local externe au rack Distributed Cloud qui connecte les routeurs périphériques d'appairage à Internet.
Routeurs de bordure d'appairage Routeurs de votre réseau local qui s'interfacent avec les commutateurs ToR du cloud distribué. En fonction de l'emplacement physique que vous choisissez pour votre installation Distributed Cloud, les routeurs périphériques d'appairage peuvent appartenir à votre organisation ou à votre centre de colocation, et être gérés par l'un ou l'autre. Vous devez configurer ces routeurs pour qu'ils utilisent le protocole BGP (Border Gateway Protocol) afin de s'appairer avec les commutateurs ToR et annoncer une route par défaut à votre matériel Distributed Cloud. Vous devez également configurer ces routeurs, ainsi que les pare-feu correspondants, pour autoriser le trafic de gestion des appareils Google, le trafic du plan de contrôle Distributed Cloud et le trafic Cloud VPN, le cas échéant.
En fonction des besoins de votre entreprise, vous pouvez configurer ces routeurs comme suit :
- Permettez à vos nœuds Distributed Cloud d'accéder à Internet en utilisant la traduction d'adresse réseau (NAT) publique ou l'exposition directe aux adresses IP publiques.
- Autorisez une connexion VPN à votre réseau VPC et à tous les servicesGoogle Cloud souhaités.
Commutateurs en haut du rack (ToR, Top-of-Rack) : Commutateurs de couche 3 qui connectent les machines du rack et s'interfacent avec votre réseau local. Ces commutateurs sont des speakers BGP et gèrent le trafic réseau entre le rack Distributed Cloud et votre équipement réseau local. Ils se connectent aux routeurs périphériques d'appairage à l'aide de bundles LACP (Link Aggregation Control Protocol).
Machines : Machines physiques qui exécutent le logiciel Distributed Cloud et vos charges de travail. Chaque machine physique est un nœud du cluster Distributed Cloud.
Service Distributed Cloud
Le service Distributed Cloud s'exécute sur Google Cloud et sert de plan de contrôle pour les nœuds et les clusters exécutés sur votre matériel Distributed Cloud. Distributed Cloud doit pouvoir se connecter àGoogle Cloud à tout moment et ne peut pas fonctionner sans cette connexion.
Ce plan de contrôle instancie et configure votre zone Distributed Cloud. Le centre de données Google spécifique auquel votre matériel Distributed Cloud se connecte pour la gestion est choisi en fonction de sa proximité avec votre installation Distributed Cloud.
Une zone Distributed Cloud se compose de plusieurs machines, soit autant que de machines physiques installées dans votre rack Distributed Cloud. Vous pouvez attribuer ces machines, instanciées en tant que nœuds Kubernetes, à un pool de nœuds, et le pool de nœuds à un cluster Distributed Cloud.
La figure 2 illustre l'organisation logique des entités Distributed Cloud.
Voici les entités :
Google Cloud region. La régionGoogle Cloud de votre zone Distributed Cloud est déterminée par l'emplacement du centre de données Google le plus proche de votre installation Distributed Cloud.
Plan de contrôle cloud Kubernetes Par défaut, le plan de contrôle Kubernetes de chaque cluster Distributed Cloud s'exécute à distance dans un centre de données Google de la région Google Cloud à laquelle votre cluster Distributed Cloud est attribué. Cela permet au Distributed Cloud de bénéficier d'un plan de contrôle sécurisé et hautement disponible sans utiliser de capacité de traitement sur les machines physiques Distributed Cloud.
Plan de contrôle Kubernetes local À partir de la version 1.5.0 de Google Distributed Cloud, vous pouvez configurer un cluster Distributed Cloud pour qu'il utilise un plan de contrôle local au lieu du plan de contrôle cloud par défaut. Un cluster de plan de contrôle local peut passer en mode de survie lorsque la connexion àGoogle Cloud est temporairement perdue, ce qui permet à vos charges de travail de continuer à s'exécuter jusqu'à ce que la connexion soit rétablie. Pour en savoir plus, consultez Mode de survie.
Zone Distributed Cloud. Abstraction logique qui représente le matériel Distributed Cloud installé dans votre rack Distributed Cloud. Une zone Distributed Cloud couvre un seul rack de matériel Distributed Cloud. Les machines physiques de la zone sont instanciées en tant que machines Distributed Cloud dans la console Google Cloud . Les machines d'une zone de cloud distribué partagent un seul maillage réseau ou un seul domaine de panne. Google crée vos machines avant de vous livrer votre matériel Distributed Cloud. Vous ne pouvez pas créer, supprimer ni modifier des machines Distributed Cloud.
Nœud. Un nœud est une ressource Kubernetes qui instancie une machine physique Distributed Cloud dans le domaine Kubernetes lorsque vous créez un pool de nœuds, ce qui le rend disponible pour exécuter des charges de travail en attribuant le pool de nœuds à un cluster Distributed Cloud. Le plan de contrôle Kubernetes de chaque nœud s'exécute sur Google Cloud.
Pool de nœuds Il s'agit d'un regroupement logique de nœuds Distributed Cloud dans une même zone Distributed Cloud, qui vous permet d'attribuer des nœuds Distributed Cloud à des clusters Distributed Cloud.
Cluster Un cluster Distributed Cloud composé d'un plan de contrôle et d'un ou plusieurs pools de nœuds.
Une connexion VPN. Tunnel VPN vers un réseau VPC s'exécutant dans un projetGoogle Cloud . Ce tunnel permet à vos charges de travail Distributed Cloud d'accéder aux ressources Compute Engine connectées à ce réseau VPC. Vous devez créer au moins un pool de nœuds dans votre zone avant de pouvoir créer une connexion VPN.
Stockage
Distributed Cloud fournit 3,3 Tio de stockage par machine physique dans le rack Distributed Cloud. Ce stockage est configuré en tant que volumes logiques Linux. Lorsque vous créez un cluster, Distributed Cloud crée un ou plusieurs PersistentVolumes et les expose en tant que volumes de blocs que vous pouvez attribuer à une charge de travail à l'aide de PersistentVolumeClaims. N'oubliez pas que ces PersistentVolumes n'assurent pas la durabilité des données et ne conviennent qu'aux données éphémères. Pour en savoir plus sur l'utilisation des volumes de blocs, consultez PersistentVolumeClaim demandant un volume de blocs bruts.
Sécurité du stockage
Distributed Cloud utilise LUKS pour chiffrer le stockage local des machines et est compatible avec les clés de chiffrement gérées par le client (CMEK). Pour en savoir plus, consultez les bonnes pratiques de sécurité.
Intégration de Symcloud Storage
Vous pouvez configurer Distributed Cloud pour qu'il utilise Rakuten Symcloud Storage, qui sert de couche d'abstraction de stockage local sur chaque nœud Distributed Cloud et met son stockage local à la disposition des charges de travail s'exécutant sur d'autres nœuds Distributed Cloud.
Pour en savoir plus, consultez Configurer Distributed Cloud pour Symcloud Storage.
Mise en réseau
Cette section décrit les exigences et les fonctionnalités de connectivité réseau de Distributed Cloud.
Google préconfigure certains composants de mise en réseau virtuel Distributed Cloud pour votre installation avant de vous expédier le matériel Distributed Cloud. Vous ne pouvez pas modifier les paramètres préconfigurés une fois le matériel livré.
La figure 3 illustre la topologie du réseau virtuel Distributed Cloud.
Les composants du réseau virtuel Distributed Cloud sont les suivants :
Réseau Réseau virtuel avec un espace d'adressage privé dans votre zone Distributed Cloud. Un réseau est isolé au niveau de la couche 3 des autres réseaux virtuels de la zone et peut contenir un ou plusieurs sous-réseaux. Le réseau virtuel couvre toutes les machines physiques du rack Distributed Cloud. Une seule zone Distributed Cloud peut accepter un maximum de 20 réseaux.
Sous-réseau. Sous-réseau VLAN de couche 2 et de couche 3 dans un réseau Distributed Cloud. Un sous-réseau possède son propre domaine de diffusion et une ou plusieurs plages d'adresses IPv4 de votre choix. Les sous-réseaux d'un même réseau sont isolés au niveau de la couche 2, mais peuvent communiquer entre eux au niveau de la couche 3. Les nœuds de différents sous-réseaux au sein du même réseau peuvent communiquer entre eux à l'aide de leurs adresses IP. Toutefois, les nœuds des sous-réseaux de différents réseaux ne peuvent pas communiquer entre eux.
Routeur Instance de routeur virtuel qui régit le trafic au sein d'un réseau Distributed Cloud. Votre administrateur réseau utilise un routeur pour configurer une session d'appairage BGP sur une pièce jointe d'interconnexion entre un réseau Distributed Cloud et votre réseau local. Les pods Distributed Cloud peuvent ainsi annoncer leurs préfixes réseau sur votre réseau local. Par défaut, les routeurs annoncent à nouveau les routes reçues des sous-réseaux Distributed Cloud. Distributed Cloud est compatible avec un routeur par réseau.
Interconnexion Liaison logique groupée entre un réseau Distributed Cloud et votre réseau local. Une interconnexion se compose d'un ou de plusieurs liens physiques. Lors du démarrage initial, Google crée les interconnexions que vous avez demandées lorsque vous avez commandé Distributed Cloud. Une fois le rack Distributed Cloud opérationnel, vous ne pouvez plus créer, modifier ni supprimer d'interconnexions. Par défaut, Google crée quatre interconnexions pour assurer la haute disponibilité de votre installation.
Rattachement d'interconnexion : Liaison virtuelle entre une interconnexion et un routeur qui isole le réseau Distributed Cloud correspondant de votre réseau local. Le trafic transitant par un rattachement d'interconnexion peut être non tagué ou tagué avec un ID de VLAN de votre choix. Vous créez des rattachements d'interconnexion en fonction des besoins de votre entreprise.
Les composants réseau Distributed Cloud partagent des similitudes avec leurs équivalents Google Cloud , mais présentent les différences suivantes :
Les composants réseau Distributed Cloud sont locaux à la zone Distributed Cloud dans laquelle ils sont instanciés.
Un réseau Distributed Cloud n'est pas directement connecté à un réseau VPC.
Par défaut, les réseaux Distributed Cloud ne sont pas connectés entre eux dans les différentes zones Distributed Cloud. Vous pouvez configurer explicitement la mise en réseau multizone.
Votre administrateur réseau configure les composants réseau Distributed Cloud, à l'exception des interconnexions, que Google configure avant de vous expédier le matériel Distributed Cloud.
Votre administrateur réseau doit disposer du rôle Administrateur de réseau Edge (roles/edgenetwork.admin) sur le projet Google Cloud cible, tandis que les développeurs d'applications qui déploient des charges de travail sur Distributed Cloud doivent disposer du rôle Lecteur de réseau Edge (roles/edgenetwork.viewer) sur le projet Google Cloud cible.
Connectivité à votre réseau local
Pour le trafic sortant vers les ressources de votre réseau local, les pods d'un cluster Distributed Cloud utilisent les routes par défaut annoncées par vos routeurs périphériques d'appairage. Distributed Cloud utilise son NAT intégré pour connecter les pods à ces ressources.
Pour le trafic entrant provenant des ressources de votre réseau local, votre administrateur réseau doit configurer des règles de routage qui correspondent aux exigences de votre entreprise afin de contrôler l'accès aux pods de chacun de vos clusters Distributed Cloud. Cela signifie qu'au minimum, vous devez suivre les étapes décrites dans Configuration du pare-feu et configurer des règles supplémentaires selon les besoins de vos charges de travail. Par exemple, vous pouvez configurer des règles d'autorisation/de refus pour des sous-réseaux de nœuds individuels ou des adresses IP virtuelles exposées par l'équilibreur de charge intégré dans Distributed Cloud. Les blocs CIDR du pod et du service Distributed Cloud ne sont pas directement accessibles.
Connectivité à Internet
Pour le trafic sortant vers des ressources sur Internet, les pods d'un cluster Distributed Cloud utilisent la route par défaut annoncée par vos routeurs vers les commutateurs ToR Distributed Cloud. Cela signifie que vous devez au minimum suivre les étapes de la section Configuration du pare-feu et configurer des règles supplémentaires selon les besoins de vos charges de travail. Distributed Cloud utilise son NAT intégré pour connecter les pods à ces ressources. Vous pouvez éventuellement configurer votre propre couche NAT en plus de celle intégrée à Distributed Cloud.
Pour le trafic entrant, vous devez configurer vos routeurs WAN en fonction de vos besoins commerciaux. Ces exigences déterminent le niveau d'accès que vous devez fournir depuis l'Internet public aux pods de vos clusters Distributed Cloud. Distributed Cloud utilise son NAT intégré pour les blocs CIDR de pod et les blocs CIDR de gestion des services. Ces blocs CIDR ne sont donc pas accessibles depuis Internet.
Connectivité à un réseau VPC
Distributed Cloud inclut une solution VPN intégrée qui vous permet de connecter un cluster Distributed Cloud directement à une instance VPC si cette instance se trouve dans le même projetGoogle Cloud que le cluster Distributed Cloud.
Si vous utilisez Cloud Interconnect pour connecter votre réseau local à une instance VPC, vos clusters Distributed Cloud peuvent accéder à cette instance à l'aide de l'appairage eBGP standard vers le nord. Vos routeurs périphériques d'appairage doivent pouvoir atteindre les préfixes VPC appropriés, et vos routeurs Cloud Interconnect doivent annoncer correctement vos préfixes Distributed Cloud, tels que les sous-réseaux Distributed Cloud pour l'équilibrage de charge, la gestion et le système.
Une fois que vous avez établi une connexion VPN entre votre cluster Distributed Cloud et votre réseau VPC, les règles de connectivité suivantes s'appliquent par défaut :
- Votre réseau VPC peut accéder à tous les pods du cluster Distributed Cloud.
- Tous les pods du cluster Distributed Cloud peuvent accéder à tous les pods de vos clusters natifs au VPC. Pour les clusters basés sur des routes, vous devez configurer manuellement les routes annoncées personnalisées.
- Tous les pods du cluster Distributed Cloud peuvent accéder aux sous-réseaux de machines virtuelles de votre réseau VPC.
Connectivité aux API et services Google Cloud
Une fois que vous avez configuré une connexion VPN à votre réseau VPC, les charges de travail exécutées sur votre installation Distributed Cloud peuvent accéder aux API et aux services Google Cloud .
Vous pouvez également configurer les fonctionnalités suivantes si vos besoins commerciaux l'exigent :
- Accès privé à Google pour accéder aux API et services Google Cloud
- Private Service Connect pour utiliser des points de terminaison de service privés afin d'accéder aux API Google Cloud
Sécurité du réseau
Vos exigences commerciales et la règle de sécurité réseau de votre organisation déterminent les étapes nécessaires pour sécuriser le trafic réseau entrant et sortant de votre installation Distributed Cloud. Pour en savoir plus, consultez les bonnes pratiques de sécurité.
Autres fonctionnalités réseau
Distributed Cloud est compatible avec les fonctionnalités réseau suivantes :
Prise en charge des réseaux hautes performances
Distributed Cloud permet d'exécuter des charges de travail qui nécessitent les meilleures performances réseau possibles. À cette fin, Distributed Cloud est fourni avec un opérateur de fonction réseau spécialisé et un ensemble de définitions de ressources personnalisées (CRD) Kubernetes qui implémentent les fonctionnalités requises pour l'exécution de charges de travail hautes performances.
Distributed Cloud permet également de virtualiser les interfaces réseau à l'aide de SR-IOV.
Compatibilité avec les charges de travail des machines virtuelles
Distributed Cloud peut exécuter des charges de travail dans des machines virtuelles en plus des conteneurs. Pour en savoir plus, consultez Gérer les machines virtuelles.
Pour découvrir comment les machines virtuelles constituent un composant essentiel de la plate-forme Google Distributed Cloud, consultez Étendre GKE Enterprise pour gérer les VM périphériques sur site.
Compatibilité avec les charges de travail GPU
Distributed Cloud peut exécuter des charges de travail basées sur des GPU NVIDIA Tesla T4. Vous devez spécifier cette exigence lorsque vous commandez votre matériel Distributed Cloud. Pour en savoir plus, consultez Gérer les charges de travail GPU.