Google Kubernetes Engine (GKE) Enterprise Edition est la plate-forme de modernisation d'applications de Google Cloud. Il est basé sur Kubernetes et peut être déployé sur Google Cloud, sur d'autres clouds, sur VMware et sur des serveurs bare metal. Même lorsqu'un cluster géré par GKE Enterprise s'exécute sur site dans le cadre de Google Distributed Cloud Virtual, il est conçu pour disposer d'une connexion permanente à Google Cloud pour plusieurs raisons, y compris la surveillance et la gestion. Cependant, vous aurez peut-être besoin de savoir ce qui se produira si, pour une raison quelconque, la connexion à Google Cloud est perdue (par exemple en raison d'un problème technique). Ce document décrit l'impact d'une perte de connectivité pour GKE sur les clusters Google Distributed Cloud (GKE sur Bare Metal et GKE sur VMware), et les solutions de contournement que vous pouvez utiliser dans cet éventualité.
Ces informations sont utiles pour les architectes qui doivent se préparer à une déconnexion non planifiée ou forcée de Google Cloud, et comprendre les conséquences que cela engendre. Toutefois, vous ne devriez pas prévoir d'utiliser un cloud virtuel distribué déconnecté de Google Cloud comme mode de travail nominal. N'oubliez pas que nous développons GKE Enterprise pour tirer parti de l'évolutivité et de la disponibilité des services Google Cloud. Ce document s'appuie sur la conception et l'architecture des différents composants GKE Enterprise lors d'une interruption temporaire. Nous ne pouvons pas garantir l'exhaustivité de ce document.
Dans ce document, nous partons du principe que vous connaissez bien GKE Enterprise. Si ce n'est pas le cas, nous vous recommandons de commencer par lire la présentation technique de GKE Enterprise.
Validation et mesure des licences GKE Enterprise
Si vous avez activé GKE Enterprise, ce qui signifie que l'API Anthos (anthos.googleapis.com) est activée dans votre projet Google Cloud, le contrôleur de mesure GKE Enterprise, en cours d'exécution dans le cluster, génère et actualise régulièrement les droits d'accès GKE Enterprise. La tolérance à la déconnexion est de 12 heures. De plus, la mesure et la facturation sont gérées via la connexion.
Ce tableau répertorie le comportement des fonctionnalités liées à l'attribution de licences et aux mesures en cas de déconnexion temporaire de Google Cloud.
| Fonctionnalité | Comportement connecté | Comportement en cas de déconnexion temporaire | Tolérance maximale à la déconnexion | Solution en cas de perte de connectivité |
|---|---|---|---|---|
| Validation des licences GKE Enterprise | Le contrôleur de mesure GKE Enterprise génère et actualise régulièrement la ressource personnalisée de droit d'accès à GKE Enterprise tant que anthos.googleapis.com est activé dans le projet Google Cloud. | Les composants qui utilisent la ressource personnalisée des droits d'accès sont compatibles avec un délai de grâce : ils continuent de fonctionner tant que la ressource personnalisée de droit d'accès est actualisée pendant le délai de grâce. | Actuellement illimité. Une fois le délai de grâce écoulé, les composants commencent à consigner les erreurs. Vous ne pouvez plus mettre à niveau votre cluster. | Aucune |
| Mesure et facturation | Le contrôleur de mesure GKE Enterprise indique la capacité du processeur virtuel du cluster disponible pour l'API Google Cloud Service Control à des fins de facturation. | Un agent intégré au cluster conserve les enregistrements de facturation dans le cluster une fois déconnecté, et les enregistrements sont récupérés lorsque le cluster se reconnecte à Google Cloud. | Illimité Toutefois, les informations de mesure de GKE Enterprise sont requises pour assurer la conformité, comme indiqué dans les Conditions spécifiques du service pour les "logiciels Premium". | Aucune |
Cycle de vie du cluster
Cette section couvre les scénarios suivants : création, mise à jour, suppression et redimensionnement des clusters, surveillance de l'état de ces activités.
Dans la plupart des scénarios, vous pouvez utiliser des outils CLI tels que bmctl, gkectl et kubectl pour effectuer des opérations pendant une déconnexion temporaire. Vous pouvez également surveiller l'état de ces opérations à l'aide de ces outils. Lors de la reconnexion, Google Cloud Console se met à jour pour afficher les résultats des opérations effectuées pendant la période de déconnexion.
| Action | Comportement connecté | Comportement en cas de déconnexion temporaire | Tolérance maximale à la déconnexion | Solution en cas de perte de connectivité |
|---|---|---|---|---|
| Création du cluster | Vous utilisez les outils CLI bmctl ou gkectl pour créer des clusters. Cette opération nécessite une connexion à Google Cloud. |
Vous ne pouvez pas créer des clusters. | Zéro | Aucune |
| Mise à niveau du cluster | Vous utilisez les outils CLI bmctl ou gkectl pour mettre à niveau des clusters. Cette opération nécessite une connexion à Google Cloud. |
Vous ne pouvez pas mettre à niveau des clusters. | Zéro | Aucune |
| Suppression du cluster | Vous utilisez les outils CLI bmctl ou gkectl pour supprimer des clusters. Cette opération ne nécessite pas de connexion à Google Cloud. |
Vous pouvez supprimer des clusters. | Illimité | - |
| Afficher l'état du cluster | Vous pouvez afficher des informations sur vos clusters dans la console Google Cloud, dans la liste des clusters Google Kubernetes Engine. | Les informations sur le cluster ne s'affichent pas dans la console Google Cloud. | Illimité | Utilisez kubectl pour interroger directement vos clusters et obtenir les informations dont vous avez besoin. |
| Supprimer des nœuds d'un cluster | Vous n'avez pas besoin de connexion à Google Cloud pour supprimer des nœuds d'un cluster. | Vous pouvez supprimer des nœuds d'un cluster. | Illimité | - |
| Ajouter des nœuds à un cluster | Le nouveau nœud extrait les images de conteneur à partir de Container Registry pour fonctionner correctement. Une vérification préliminaire s'exécute pour vérifier qu'il existe une connectivité à Google Cloud. | Les vérifications préliminaires qui s'exécutent lors de l'ajout d'un nouveau nœud confirment la connectivité à Google Cloud. Par conséquent, vous ne pouvez pas ajouter un nouveau nœud à un cluster lorsqu'il est déconnecté. | Zéro | Aucune |
Cycle de vie de l'application
La gestion de vos applications exécutées dans un cluster GKE sur Google Distributed Cloud n'est pratiquement pas affectée par une déconnexion temporaire de Google Cloud. Seule la passerelle Connect est affectée. Si vous utilisez Container Registry, Artifact Registry, Cloud Build ou Cloud Deploy pour gérer vos images de conteneurs ou vos pipelines CI/CD dans Google Cloud, ils ne sont plus disponibles en cas de déconnexion. Les stratégies permettant de gérer les déconnexions pour ces produits ne sont pas traitées dans ce document.
| Action | Comportement connecté | Comportement en cas de déconnexion temporaire | Tolérance maximale à la déconnexion | Solution en cas de perte de connectivité |
|---|---|---|---|---|
| Déploiement des applications | Effectué en local à l'aide de kubectl, via des outils CI/CD ou à l'aide de la passerelle Connect. |
La passerelle Connect n'est pas disponible. Toutes les autres méthodes de déploiement continuent de fonctionner tant qu'elles se connectent directement à l'API Kubernetes. | Illimité | Si vous utilisiez la passerelle Connect, optez pour l'utilisation de kubectl en local. |
| Suppression des applications | Effectué en local à l'aide de kubectl, via des outils CI/CD ou à l'aide de la passerelle Connect. |
La passerelle Connect n'est pas disponible. Toutes les autres méthodes de déploiement continuent de fonctionner tant qu'elles se connectent directement à l'API Kubernetes. | Illimité | Si vous utilisiez la passerelle Connect, optez pour l'utilisation de kubectl en local. |
| Scaling horizontal des applications | Effectué en local à l'aide de kubectl, via des outils CI/CD ou à l'aide de la passerelle Connect. |
La passerelle Connect n'est pas disponible. Toutes les autres méthodes de déploiement continuent de fonctionner tant qu'elles se connectent directement à l'API Kubernetes. | Illimité | Si vous utilisiez la passerelle Connect, optez pour l'utilisation de kubectl en local. |
Journalisation et surveillance
La possibilité de réaliser des audits aide votre organisation à respecter ses exigences réglementaires et ses règles de conformité. GKE Enterprise facilite la réalisation d'audits en proposant une journalisation des applications, la journalisation Kubernetes et des journaux d'audit. De nombreux clients choisissent de tirer parti de Cloud Logging et de Cloud Monitoring de Google afin d'éviter d'avoir à gérer une infrastructure de journalisation et de surveillance sur site. D'autres clients préfèrent centraliser leurs journaux dans un système sur site pour l'agrégation. Pour aider ces clients, GKE Enterprise offre une intégration directe à des services tels que Prometheus, Elastic, Splunk ou Datadog. Dans ce mode, il n'y a aucun impact sur la fonctionnalité de journalisation ou de surveillance lors d'une déconnexion temporaire de Google Cloud.
| Fonctionnalité | Comportement connecté | Comportement en cas de déconnexion temporaire | Tolérance maximale à la déconnexion | Solution en cas de perte de connectivité |
|---|---|---|---|---|
| Journalisation des applications à l'aide de Cloud Logging | Les journaux sont écrits dans Cloud Logging. | Les journaux sont mis en mémoire tampon sur le disque local. | Tampon local de 4,5 h ou 4 Gio par nœud. Lorsque le tampon est rempli ou que la déconnexion dure 4,5 heures, les entrées les plus anciennes sont supprimées. | Utilisez une solution de journalisation locale. |
| Journalisation système/Kubernetes à l'aide de Cloud Logging | Les journaux sont écrits dans Cloud Logging. | Les journaux sont mis en mémoire tampon sur le disque local. | Tampon local de 4,5 h ou 4 Gio par nœud. Lorsque le tampon est rempli ou que la déconnexion dure 4,5 heures, les entrées les plus anciennes sont supprimées. | Utilisez une solution de journalisation locale. |
| Journaux d'audit à l'aide de Cloud Audit Log | Les journaux sont écrits dans Cloud Logging. | Les journaux sont mis en mémoire tampon sur le disque local. | Tampon local de 10 Gio par nœud de plan de contrôle. Une fois le tampon rempli, les entrées les plus anciennes sont supprimées. | Configurez le transfert de journal vers une solution de journalisation locale. |
| Journalisation des applications à l'aide d'un autre fournisseur | Vous pouvez faire appel à différents fournisseurs tiers, tels que Elastic, Splunk, Datadog ou Loki. | Aucun impact | Illimité | - |
| Journalisation système/Kubernetes à l'aide d'un autre fournisseur | Vous pouvez faire appel à différents fournisseurs tiers, tels que Elastic, Splunk ou Datadog. | Aucun impact | Illimité | - |
| Métriques des applications et Kubernetes écrites dans Cloud Monitoring | Les métriques sont écrites dans Cloud Monitoring. | Les métriques sont mises en mémoire tampon sur le disque local. | Tampon local de 24 h ou 6 Gio par nœud pour les métriques système et de 1 Gio de tampon local par nœud pour les métriques d'application. Lorsque le tampon est rempli ou que la déconnexion dure 24 heures, les entrées les plus anciennes sont supprimées. | Utilisez une solution de surveillance locale. |
| Accès et lecture des données de surveillance de Kubernetes et des charges de travail d'applications | Toutes les métriques sont disponibles dans la console Google Cloud et via l'API Cloud Monitoring. | Les métriques ne sont pas mises à jour dans Cloud Monitoring pendant la déconnexion. | Tampon local de 24 h ou 6 Gio par nœud pour les métriques système et de 1 Gio de tampon local par nœud pour les métriques d'application. Lorsque le tampon est rempli ou que la déconnexion dure 24 heures, les entrées les plus anciennes sont supprimées. | Utilisez une solution de surveillance locale. |
| Règles d'alerte et pagination pour les métriques | Cloud Monitoring prend en charge les alertes. Vous pouvez créer des alertes pour n'importe quelle métrique. Les alertes peuvent être envoyées via différents canaux. | Les alertes ne sont pas déclenchées pendant la déconnexion. Les alertes ne sont déclenchées qu'à partir des données de métriques déjà envoyées dans Cloud Monitoring | Utilisez une solution locale de surveillance et d'alerte. |
Gestion de la configuration et des règles
Config Sync et Policy Controller vous permettent de gérer la configuration et les règles à grande échelle, sur l'ensemble de vos clusters. Vous stockez les configurations et les règles dans un dépôt Git, et elles sont automatiquement synchronisées avec vos clusters.
Config Sync
Config Sync utilise des agents intégrés au cluster pour se connecter directement à un dépôt Git. Vous pouvez gérer les modifications apportées à l'URL du dépôt ou aux paramètres de synchronisation à l'aide des outils gcloud ou kubectl.
Lors d'une déconnexion temporaire, la synchronisation n'est pas affectée si les agents de cluster peuvent toujours atteindre le dépôt Git. Toutefois, si vous modifiez les paramètres de synchronisation avec Google Cloud CLI ou la console Google Cloud, ils ne sont pas appliqués au cluster pendant la déconnexion. Vous pouvez les écraser localement en utilisant kubectl. Toutes les modifications locales sont écrasées lors de la reconnexion.
Policy Controller
Policy Controller permet d'appliquer des règles entièrement programmables pour vos clusters. Ces règles servent de "garde-fous" et empêchent toute modification qui enfreint les contrôles de sécurité, opérationnels ou de conformité que vous avez définis.
| Action | Comportement connecté | Comportement en cas de déconnexion temporaire | Tolérance maximale à la déconnexion | Solution en cas de perte de connectivité |
|---|---|---|---|---|
| Synchroniser la configuration à partir d'un dépôt Git | Les agents intégrés au cluster se connectent directement au dépôt Git. Vous pouvez modifier l'URL du dépôt ou les paramètres de synchronisation avec une API Google Cloud. | La synchronisation des configurations n'est pas affectée. Si vous modifiez les paramètres de synchronisation avec gcloud ou dans la console Google Cloud, ils ne sont pas appliqués au cluster pendant la déconnexion. Vous pouvez les écraser localement en utilisant kubectl. Toutes les modifications locales sont écrasées lors de la reconnexion. |
Illimité | N'utilisez jamais l'API Fleet pour Config Sync et configurez-le uniquement manuellement. |
| Appliquer des règles aux requêtes adressées à l'API Kubernetes | L'agent intégré au cluster applique des contraintes grâce à son intégration à l'API Kubernetes. Vous pouvez gérer les règles à l'aide de l'API Kubernetes locale. Vous gérez la configuration système de Policy Controller avec une API Google Cloud. | L'application des règles n'est pas affectée. Les règles sont toujours gérées à l'aide de l'API Kubernetes locale. Les modifications apportées à la configuration système de Policy Controller à l'aide de l'API Google Cloud ne sont pas propagées au cluster, mais vous pouvez les écraser temporairement en local. Toutes les modifications locales sont écrasées lors de la reconnexion. | Illimité | N'utilisez jamais l'API Fleet pour Policy Controller et configurez-le uniquement manuellement. |
| Installer, configurer ou mettre à niveau Config Sync à l'aide de l'API Google Cloud | Vous utilisez l'API Google Cloud pour gérer l'installation et la mise à niveau des agents intégrés au cluster. Vous pouvez également utiliser cette API (ou gcloud, ou la console Google Cloud) pour gérer la configuration de ces agents. | Les agents intégrés au cluster continuent de fonctionner normalement. Vous ne pouvez pas installer, mettre à jour ni configurer des agents intégrés au cluster à l'aide de l'API Google Cloud. Toutes les installations, mises à niveau ou configurations en attente effectuées à l'aide de l'API ont lieu lors de la reconnexion. | Zéro | N'utilisez jamais l'API Fleet pour Policy Controller et configurez-le uniquement manuellement. |
| Afficher l'état du système ou de la synchronisation dans la console Google Cloud | Vous pouvez afficher l'état des agents intégrés au cluster ainsi que l'état de la synchronisation à l'aide de l'API Google Cloud ou de la console Google Cloud. | Les informations d'état dans l'API Google Cloud ou la console Google Cloud deviennent obsolètes. L'API affiche une erreur de connexion. Toutes les informations restent disponibles par cluster à l'aide de l'API Kubernetes locale. | Zéro | Utilisez la CLI nomos ou l'API Kubernetes locale. |
Sécurité
Identité, authentification et autorisation
GKE Enterprise peut se connecter directement à Cloud Identity pour les rôles d'application et d'utilisateur, pour gérer les charges de travail à l'aide d'Anthos Connect ou pour l'authentification des points de terminaison à l'aide d'OIDC. En cas de déconnexion de Google Cloud, la connexion à Cloud Identity est également interrompue, et ces fonctionnalités ne sont plus disponibles. Pour les charges de travail nécessitant une résilience supplémentaire en cas de déconnexion temporaire, vous pouvez utiliser GKE Enterprise Identity Service pour l'intégration d'un fournisseur LDAP ou OIDC (y compris ADFS) afin de configurer l'authentification des utilisateurs finaux.
| Fonctionnalité | Comportement connecté | Comportement en cas de déconnexion temporaire | Tolérance maximale à la déconnexion | Solution en cas de perte de connectivité |
|---|---|---|---|---|
| Cloud Identity en tant que fournisseur d'identité, à l'aide de la passerelle Connect | Vous pouvez accéder aux ressources GKE Enterprise en utilisant Cloud Identity en tant que fournisseur d'identité et en vous connectant via la passerelle Connect. | La passerelle Connect nécessite une connexion à Google Cloud. Vous ne pouvez pas vous connecter à vos clusters pendant la déconnexion. | Zéro | Utilisez GKE Identity Service pour fédérer avec un autre fournisseur d'identité. |
| Identité et authentification à l'aide d'un fournisseur d'identité tiers | Compatible avec OIDC et LDAP. Vous utilisez gcloud CLI pour vous connecter en premier. Pour les fournisseurs OIDC, vous pouvez utiliser la console Google Cloud pour vous connecter. Vous pouvez ensuite vous authentifier normalement auprès de l'API du cluster (par exemple, à l'aide de kubectl). |
Tant que le fournisseur d'identité reste accessible à la fois pour vous et pour le cluster, vous pouvez toujours vous authentifier auprès de l'API du cluster. Vous ne pouvez pas vous connecter via la console Google Cloud. Vous ne pouvez mettre à jour la configuration OIDC ou LDAP de vos clusters qu'en local. Vous ne pouvez pas utiliser la console Google Cloud. | Illimité | - |
| Autorisation | GKE Enterprise est compatible avec le contrôle des accès basé sur les rôles (RBAC). Les rôles peuvent être attribués à des utilisateurs, à des groupes ou à des comptes de service. Les identités et les groupes d'utilisateurs peuvent être récupérés à partir du fournisseur d'identité. | Le système RBAC est local au cluster Kubernetes et n'est pas affecté par la déconnexion de Google Cloud. Toutefois, s'il s'appuie sur des identités provenant de Cloud Identity, elles ne sont pas disponibles en cas de déconnexion. | Illimité | - |
Gestion des secrets et des clés
La gestion des secrets et des clés est un élément important de votre stratégie de sécurité. Le comportement de GKE Enterprise en cas de déconnexion de Google Cloud dépend du service que vous utilisez pour ces fonctionnalités.
| Fonctionnalité | Comportement connecté | Comportement en cas de déconnexion temporaire | Tolérance maximale à la déconnexion | Solution en cas de perte de connectivité |
|---|---|---|---|---|
| Gestion des secrets et des clés à l'aide de Cloud Key Management Service et de Secret Manager | Vous utilisez directement Cloud Key Management Service pour les clés cryptographiques et Secret Manager pour vos secrets. | Cloud Key Management Service et Secret Manager ne sont pas disponibles. | Zéro | Utilisez des systèmes locaux à la place. |
| Gestion des secrets et des clés à l'aide de Hashicorp Vault et de services Google Cloud | Vous configurez Hashicorp Vault pour utiliser Cloud Storage ou Spanner pour stocker les secrets, et Cloud Key Management Service pour gérer les clés. | Si Hashicorp Vault s'exécute sur votre cluster Anthos et est également affecté par la déconnexion, le stockage de secrets et la gestion des clés ne sont pas disponibles pendant la déconnexion. | Zéro | Utilisez des systèmes locaux à la place. |
| Gestion des secrets et des clés à l'aide de Hashicorp Vault et de services sur site | Vous configurez HashiCorp Vault pour utiliser un backend de stockage sur site pour les secrets, et un système de gestion des clés sur site (tel qu'un module de sécurité matériel). | La déconnexion de Google Cloud n'a aucun impact. | Illimité | - |
Mise en réseau et services réseau
Équilibrage de charge
Pour exposer les services Kubernetes hébergés dans un cluster GKE sur Google Distributed Cloud aux utilisateurs, vous pouvez utiliser un équilibreur de charge groupé (Google Distributed Cloud Virtual pour Bare Metal avec MetalLB, Google Distributed Cloud Virtual avec Seesaw ou MetalLB) ou votre équilibreur de charge externe à GKE Enterprise Les deux options continuent de fonctionner en cas de déconnexion de Google Cloud.
| Fonctionnalité | Comportement connecté | Comportement en cas de déconnexion temporaire | Tolérance maximale à la déconnexion | Solution en cas de perte de connectivité |
|---|---|---|---|---|
| Équilibreur de charge groupé L4 | Fournit un équilibrage de charge L4 entièrement local, sans aucune dépendance sur les API ou le réseau Google Cloud. | Aucun changement | Illimité | - |
| Équilibreur de charge manuel ou intégré | Compatible avec F5 BIG-IP et d'autres également hébergés sur site. | Aucun changement | Illimité | - |
Anthos Service Mesh
Vous pouvez utiliser Anthos Service Mesh pour gérer, observer et sécuriser les communications entre vos services exécutés dans un cluster GKE sur le cloud distribué de Google. Les fonctionnalités d'Anthos Service Mesh ne sont pas toutes compatibles avec GKE sur Bare Metal et GKE sur VMware : consultez la liste des fonctionnalités compatibles pour en savoir plus.
| Fonctionnalité | Comportement connecté | Comportement en cas de déconnexion temporaire | Tolérance maximale à la déconnexion | Solution en cas de perte de connectivité |
|---|---|---|---|---|
| Déployer ou mettre à jour des règles (routage, autorisation, sécurité, audit, etc.) | Vous pouvez utiliser la console Google Cloud, kubectl, asmcli ou istioctl pour gérer les règles Anthos Service Mesh. |
Vous ne pouvez utiliser que kubectl ou istioctl pour gérer les règles Anthos Service Mesh. |
Illimité | Utilisez kubectl ou istioctl. |
| Autorité de certification (CA, Certificate Authority) | Vous pouvez utiliser l'autorité de certification intégrée au cluster ou l'autorité de certification Mesh pour gérer les certificats utilisés par Anthos Service Mesh. | Il n'y a aucun impact si vous utilisez l'autorité de certification intégrée au cluster. Si vous utilisez l'autorité de certification Mesh, les certificats expirent au bout de 24 heures. Les nouvelles instances de service ne peuvent pas récupérer les certificats. |
Illimité pour l'autorité de certification au sein du cluster. Service dégradé pendant 24 heures, et aucun service après 24 heures pour l'autorité de certification Mesh. |
Utilisez l'autorité de certification intégrée au cluster. |
| Cloud Monitoring pour Anthos Service Mesh | Vous pouvez utiliser Cloud Monitoring pour stocker, explorer et exploiter les métriques liées au protocole HTTP provenant d'Anthos Service Mesh. | Les métriques ne sont pas stockées. | Zéro | Utilisez une solution de surveillance locale compatible, telle que Prometheus. |
| Journaux d'audit d'Anthos Service Mesh | Anthos Service Mesh s'appuie sur les installations de journalisation Kubernetes locales. Le comportement dépend de la configuration de la journalisation pour votre cluster GKE Enterprise. | Dépend de la configuration de la journalisation pour votre cluster GKE Enterprise. | - | - |
| Passerelle d'entrée | Vous pouvez définir des adresses IP externes avec la passerelle d'entrée Istio. | Aucun impact | Illimité | - |
| CNI (Container Network Interface) Istio | Vous pouvez configurer Anthos Service Mesh pour utiliser la CNI Istio au lieu d'iptables pour gérer le trafic. | Aucun impact | Illimité | - |
| Authentification de l'utilisateur final d'Anthos Service Mesh pour les applications Web | Vous pouvez utiliser la passerelle d'entrée d'Anthos Service Mesh pour intégrer votre propre fournisseur d'identité (via OIDC) afin d'authentifier et autoriser les utilisateurs finaux sur les applications Web faisant partie du maillage. | Aucun impact | Illimité | - |
Autres services réseau
| Fonctionnalité | Comportement connecté | Comportement en cas de déconnexion temporaire | Tolérance maximale à la déconnexion | Solution en cas de perte de connectivité |
|---|---|---|---|---|
| DNS | Le serveur DNS Kubernetes s'exécute au sein du cluster. | Le service DNS Kubernetes fonctionne normalement lorsqu'il s'exécute dans le cluster lui-même. | Illimité | - |
| Proxy de sortie | Vous pouvez configurer GKE Enterprise afin d'utiliser un proxy pour les connexions de sortie. | Si votre proxy s'exécute sur site, GKE Enterprise peut toujours l'utiliser pendant une déconnexion temporaire. Toutefois, si le proxy perd la connexion à Google Cloud, tous les scénarios de ce document restent applicables. | Illimité | - |
Google Cloud Marketplace
| Fonctionnalité | Comportement connecté | Comportement en cas de déconnexion temporaire | Tolérance maximale à la déconnexion | Solution en cas de perte de connectivité |
|---|---|---|---|---|
| Déployer et gérer des applications et des services depuis Cloud Marketplace | Cloud Marketplace est disponible dans la console Google Cloud. Vous pouvez l'utiliser pour découvrir, acquérir et déployer des solutions. | Vous ne pouvez pas utiliser Cloud Marketplace. Certaines solutions de Cloud Marketplace peuvent avoir leurs propres exigences de connectivité qui ne sont pas décrites ici. | Zéro | Aucune |
Assistance
Cette section décrit les scénarios que vous êtes susceptible de rencontrer lors de vos interactions avec l'assistance Google Cloud ou votre partenaire d'exploitation pour un dossier lié à vos clusters GKE sur Google Distributed Cloud.
| Fonctionnalité | Comportement connecté | Comportement en cas de déconnexion temporaire | Tolérance maximale à la déconnexion | Solution en cas de perte de connectivité |
|---|---|---|---|---|
| Partager un instantané de cluster avec l'équipe d'assistance | Vous pouvez créer un instantané de cluster en local à l'aide des commandes bmctl check cluster ou gkectl diagnose snapshot. Vous partagez cet instantané via le processus d'assistance normal. |
Vous pouvez toujours générer l'instantané puisqu'il s'agit d'une opération locale. Si vous avez perdu l'accès à Google Cloud et à ses interfaces d'assistance Web, vous pouvez contacter l'équipe d'assistance par téléphone, à condition que vous ayez souscrit aux formules d'assistance Advanced ou Premium. | Illimité | - |
| Partager les données de journal pertinentes avec l'équipe d'assistance | Vous pouvez collecter les journaux localement à partir de votre cluster et les partager via le processus d'assistance normal. | Vous pouvez toujours collecter des journaux à partir de votre cluster. Si vous avez perdu l'accès à Google Cloud et à ses interfaces d'assistance Web, vous pouvez contacter l'équipe d'assistance par téléphone, à condition que vous ayez souscrit aux formules d'assistance Advanced ou Premium. | Illimité | - |