Impact d'une déconnexion temporaire de Google Cloud

Google Distributed Cloud (logiciel uniquement) est basé sur Kubernetes. Vous pouvez le déployer sur site sur des serveurs VMware ou Bare Metal. Bien que Distributed Cloud s'exécute sur site, nous le concevons pour qu'il dispose 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, vous perdez la connexion à Google Cloud (par exemple en raison d'un problème technique). Ce document décrit l'impact d'une perte de connectivité pour les clusters dans un déploiement Distributed Cloud exclusivement logiciel (sur Bare Metal ou VMware) et les solutions de contournement que vous pouvez utiliser dans cette é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 déploiement Distributed Cloud exclusivement logiciel déconnecté deGoogle Cloud comme mode de fonctionnement nominal. N'oubliez pas que nous développons Distributed Cloud 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 Google Cloud qui fonctionnent de manière compatible avec Distributed Cloud 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. Si ce n'est pas le cas, nous vous recommandons de commencer par lire la présentation de GKE.

Validation et mesure des licences

Si vous avez activé l'API Anthos (anthos.googleapis.com) dans votre projet Google Cloud , le contrôleur de mesure exécuté dans le cluster génère et actualise périodiquement les droits d'accès à la licence. La tolérance à la déconnexion est de 12 heures. De plus, le système a besoin de la connexion pour gérer la mesure et la facturation.

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 de déconnexion Solution en cas de perte de connectivité
Validation de la licence Le contrôleur de mesure génère et actualise régulièrement la ressource personnalisée de droit d'accès à la licence 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. Illimité Une fois le délai de grâce écoulé, les composants commencent à consigner les erreurs. Vous ne pouvez plus mettre à niveau votre cluster. Aucun
Mesure et facturation Le contrôleur de mesure indique la capacité du processeur virtuel du cluster disponible pour l'API Service Control Google Cloud à des fins de facturation. Un agent intégré au cluster conserve les enregistrements de facturation dans le cluster pendant la déconnexion et les récupère lorsque le cluster se reconnecte à Google Cloud. Illimité Toutefois, les informations de mesure sont requises pour assurer la conformité, comme indiqué dans les Conditions spécifiques du service pour les "logiciels Premium". Aucun

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, la consoleGoogle Cloud 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 de 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 de 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 les 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, dans la liste des clusters Google Kubernetes Engine. Les informations sur le cluster ne s'affichent pas dans la console. 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

Une déconnexion temporaire de Google Cloud n'a généralement pas d'incidence sur la gestion de vos applications exécutées dans un cluster sur site. Seule la passerelle Connect est concerné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 dansGoogle 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 de déconnexion Solution en cas de perte de connectivité
Déploiement de l'application Vous déployez des applications 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 utilisez la passerelle Connect, optez pour l'utilisation de kubectl en local.
Suppression des applications Vous supprimez les applications 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 utilisez la passerelle Connect, optez pour l'utilisation de kubectl en local.
Scaling horizontal des applications Vous pouvez effectuer un scaling horizontal les applications localement à 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 utilisez 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é. Distributed Cloud facilite la réalisation d'audits en proposant une journalisation des applications, la journalisation Kubernetes et des journaux d'audit. De nombreux clients choisissent d'utiliser Cloud Logging et 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, Distributed Cloud est compatible avec l'intégration directe à des services tels que Prometheus. 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 de déconnexion Solution en cas de perte de connectivité
Journalisation des applications à l'aide de Cloud Logging Le système écrit les journaux dans Cloud Logging. Le système met en mémoire tampon les journaux 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 Le système écrit les journaux dans Cloud Logging. Le système met en mémoire tampon les journaux 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 Le système écrit les journaux dans Cloud Logging. Le système met en mémoire tampon les journaux sur le disque local. Tampon local de 10 Gio par nœud de plan de contrôle. Une fois le tampon rempli, le système supprime les entrées les plus anciennes. 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 Le système écrit les métriques dans Cloud Monitoring. Le système met en mémoire tampon les métriques 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, le système supprime les entrées les plus anciennes. Utilisez une solution de surveillance locale.
Accéder aux données de surveillance de Kubernetes et des charges de travail d'applications et les lire Toutes les métriques sont disponibles dans la console et via l'API Cloud Monitoring. Le système ne met pas à jour les métriques 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, le système supprime les entrées les plus anciennes. 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. Le système peut envoyer des alertes via différents canaux. Le système ne déclenche pas d'alertes lorsqu'il est déconnecté. Le système ne déclenche des alertes 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 le système les synchronise automatiquement 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 de la Google Cloud CLI ou des outils 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 gcloud CLI ou la console, le cluster ne les applique pas pendant la déconnexion. Vous pouvez les écraser localement en utilisant kubectl. La reconnexion écrase toutes les modifications locales.

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 de 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 CLI ou dans la console, le cluster ne les applique pas pendant la déconnexion. Vous pouvez les écraser localement en utilisant kubectl. La reconnexion écrase toutes les modifications locales. Illimité N'utilisez jamais l'API Fleet pour Config Sync et configurez-le uniquement à l'aide de l'API Kubernetes.
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. Vous gérez toujours les règles à l'aide de l'API Kubernetes locale. Le système ne propage pas au cluster les modifications apportées à la configuration système de Policy Controller à l'aide de l'API Google Cloud , mais vous pouvez les écraser temporairement en local. La reconnexion écrase toutes les modifications locales. Illimité N'utilisez jamais l'API Fleet pour Policy Controller et configurez-le uniquement à l'aide de l'API Kubernetes.
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 CLI, ou la console) 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 à niveau 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 à l'aide de l'API Kubernetes.
Afficher l'état du système ou de la synchronisation dans la console Vous pouvez afficher l'état des agents intégrés au cluster ainsi que l'état de la synchronisation à l'aide d'une API Google Cloud ou de la console. Les informations d'état dans l'API Google Cloud ou la console 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é

Cette section explique comment les fonctionnalités de sécurité, y compris la gestion des identités, de l'authentification, des autorisations et des secrets, sont affectées par une déconnexion temporaire de Google Cloud.

Identité, authentification et autorisation

Distributed Cloud peut se connecter directement à Cloud Identity pour les rôles d'application et d'utilisateur, pour gérer les charges de travail à l'aide de Connect ou pour l'authentification des points de terminaison à l'aide d'OIDC. Une déconnexion de Google Cloud interrompt la connexion à Cloud Identity, ce qui rend ces fonctionnalités indisponibles. Pour les charges de travail nécessitant une résilience supplémentaire en cas de déconnexion temporaire, vous pouvez utiliser GKE 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 de 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 Distributed Cloud 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 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. Vous ne pouvez mettre à jour la configuration OIDC ou LDAP de vos clusters qu'en local. Vous ne pouvez pas utiliser la console. Illimité -
Autorisation Distributed Cloud 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. Le système récupère les identités et les groupes d'utilisateurs auprès du fournisseur d'identité. Le système RBAC est local au cluster Kubernetes. La déconnexion de Google Cloud n'a aucune incidence sur celui-ci. 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 Distributed Cloud en cas de déconnexion deGoogle 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 de 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 des 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 sur site et que la déconnexion l'affecte également, 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

Cette section aborde la mise en réseau et les services réseau pour les clusters sur site, y compris leur impact en cas de déconnexion temporaire deGoogle Cloud. Il fournit des informations sur l'équilibrage de charge, Cloud Service Mesh et d'autres services réseau.

Équilibrage de charge

Pour exposer les services Kubernetes hébergés dans un cluster sur site aux utilisateurs, vous avez les options suivantes :

Ces options d'équilibrage de charge restent opérationnelles même si elles sont déconnectées deGoogle Cloud.

Fonctionnalité Comportement connecté Comportement en cas de déconnexion temporaire Tolérance maximale de 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éseauGoogle Cloud . Aucune modification 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é -

Cloud Service Mesh

Vous pouvez utiliser Cloud Service Mesh pour gérer, observer et sécuriser les communications entre vos services exécutés dans un cluster sur site. Distributed Cloud n'est pas compatible avec toutes les fonctionnalités de Cloud Service Mesh. Pour en savoir plus, consultez la liste des fonctionnalités compatibles.

Fonctionnalité Comportement connecté Comportement en cas de déconnexion temporaire Tolérance maximale de 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, kubectl, asmcli ou istioctl pour gérer les règles Cloud Service Mesh. Vous ne pouvez utiliser que kubectl ou istioctl pour gérer les règles Cloud 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 Cloud Service Mesh pour gérer les certificats utilisés par Cloud 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 Cloud Service 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 Cloud Service Mesh.		 Utilisez l'autorité de certification intégrée au cluster.
Cloud Monitoring pour Cloud Service Mesh Vous pouvez utiliser Cloud Monitoring pour stocker, explorer et exploiter les métriques liées au protocole HTTP provenant de Cloud Service Mesh. Les métriques ne sont pas stockées. Zéro Utilisez une solution de surveillance locale compatible, telle que Prometheus.
Journalisation d'audit Cloud Service Mesh Cloud Service Mesh s'appuie sur les installations de journalisation Kubernetes locales. Le comportement dépend de la configuration de la journalisation pour votre cluster sur site. Dépend de la configuration de la journalisation pour votre cluster sur site. - -
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 Cloud Service Mesh pour utiliser la CNI Istio au lieu d'iptables pour gérer le trafic. Aucun impact Illimité -
Authentification de l'utilisateur final de Cloud Service Mesh pour les applications Web Vous pouvez utiliser la passerelle d'entrée Cloud 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 de 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 vos clusters sur site afin d'utiliser un proxy pour les connexions de sortie. Si votre proxy s'exécute sur site, le cluster 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 de 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. 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'assistanceGoogle Cloud ou votre partenaire d'exploitation pour un dossier lié à vos clusters GKE sur GDC.

Fonctionnalité Comportement connecté Comportement en cas de déconnexion temporaire Tolérance maximale de 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é -