El software de Google Distributed Cloud se basa únicamente en Kubernetes y puedes desplegarlo de forma local en servidores VMware o bare metal. Aunque Distributed Cloud se ejecuta en las instalaciones, lo diseñamos para que tenga una conexión permanente con Google Cloud por varios motivos, como la monitorización y la gestión. Sin embargo, es posible que necesites saber qué ocurre si, por cualquier motivo, pierdes la conexión con Google Cloud (por ejemplo, debido a un problema técnico). En este documento se describe el impacto de la pérdida de conectividad en los clústeres de una implementación solo de software de Distributed Cloud (en hardware desnudo o en VMware) y las soluciones alternativas que puedes usar en este caso.
Esta información es útil para los arquitectos que necesiten prepararse para una desconexión no planificada u obligatoria de Google Cloud y comprender sus consecuencias. Sin embargo, no deberías usar una implementación de nube distribuida solo de software que esté desconectada deGoogle Cloud como modo de funcionamiento nominal. Recuerda que diseñamos Distributed Cloud para aprovechar la escalabilidad y la disponibilidad de los Google Cloud servicios. Este documento se basa en el diseño y la arquitectura de los distintos componentes de Google Cloud que funcionan de forma compatible con Distributed Cloud durante una interrupción temporal. No podemos garantizar que este documento sea exhaustivo.
En este documento se da por supuesto que conoces GKE. Si no es así, te recomendamos que leas primero la descripción general de GKE.
Validación de licencias y medición
Si has habilitado la API de Anthos (anthos.googleapis.com)
en tu proyecto Google Cloud , el controlador de medición que se ejecuta en el clúster
genera y actualiza el derecho de licencia periódicamente. La tolerancia a la desconexión es de 12 horas. Además, el sistema necesita la conexión para gestionar la medición y la facturación.
En esta tabla se muestra el comportamiento de las funciones relacionadas con las licencias y la medición en caso de desconexión temporal de Google Cloud:
| Función | Comportamiento conectado | Comportamiento de desconexión temporal | Tolerancia máxima de desconexión | Solución alternativa para la pérdida de conectividad |
|---|---|---|---|---|
| Validación de licencia | El controlador de medición genera y actualiza periódicamente el recurso personalizado de derecho de licencia, siempre que anthos.googleapis.com esté habilitado en el proyecto Google Cloud . |
Los componentes que consumen el recurso personalizado de derecho admiten un periodo de gracia: siguen funcionando siempre que el recurso personalizado de derecho se actualice durante el periodo de gracia. | Ilimitado. Una vez que caduca el periodo de gracia, los componentes empiezan a registrar errores. Ya no puedes actualizar tu clúster. | Ninguno |
| Medición y facturación | El controlador de medición informa de la capacidad de vCPU del clúster a la Google Cloud API Service Control con fines de facturación. | Un agente en el clúster conserva los registros de facturación en el clúster durante la desconexión y los recupera cuando el clúster vuelve a conectarse a Google Cloud. | Ilimitado. Sin embargo, se requiere información sobre la medición para cumplir los Términos Específicos del Servicio de "Software Premium". | Ninguno |
Ciclo de vida de los clústeres
En esta sección se describen situaciones como la creación, actualización, eliminación y cambio de tamaño de clústeres, así como la monitorización del estado de estas actividades.
En la mayoría de los casos, puedes usar herramientas de la CLI como bmctl, gkectl y kubectl para realizar operaciones durante una desconexión temporal. También puedes monitorizar el estado de estas operaciones con estas herramientas. Cuando se restablezca la conexión, la consolaGoogle Cloud se actualizará para mostrar los resultados de las operaciones realizadas durante el periodo en el que no había conexión.
| Acción | Comportamiento conectado | Comportamiento de desconexión temporal | Tolerancia máxima de desconexión | Solución alternativa para la pérdida de conectividad |
|---|---|---|---|---|
| Creación de clústeres | Puedes usar las herramientas de la CLI bmctl o gkectl para crear clústeres. Esta operación requiere una conexión a Google Cloud. |
No puedes crear clústeres. | Cero | Ninguno |
| Actualización de clúster | Puedes usar las herramientas de CLI bmctl o gkectl para actualizar los clústeres. Esta operación requiere una conexión a Google Cloud. |
No puedes actualizar clústeres. | Cero | Ninguno |
| Eliminación de clústeres | Puedes usar las herramientas de CLI bmctl o gkectl para eliminar clústeres. Esta operación no requiere una conexión a Google Cloud. |
Puedes eliminar clústeres. | Ilimitado | - |
| Ver el estado de un clúster | Puedes ver información sobre tus clústeres en la consola, en la lista de clústeres de Google Kubernetes Engine. | La información del clúster no se muestra en la consola. | Ilimitado | Usa kubectl para consultar directamente tus clústeres y obtener la información que necesitas. |
| Eliminar nodos de un clúster | No necesitas una conexión a Google Cloud para quitar nodos de un clúster. | Puedes eliminar nodos de un clúster. | Ilimitado | - |
| Añadir nodos a un clúster | El nuevo nodo extrae imágenes de contenedor de Container Registry para funcionar correctamente. Se realiza una comprobación preparatoria para validar que hay conectividad con Google Cloud. | Las comprobaciones previas que se ejecutan al añadir un nuevo nodo validan que haya conectividad con Google Cloud. Por lo tanto, no puedes añadir un nuevo nodo a un clúster cuando no haya conexión. | Cero | Ninguno |
Ciclo de vida de las aplicaciones
Una desconexión temporal de Google Cloud no suele afectar a la gestión de tus aplicaciones que se ejecutan en un clúster local. Solo se ve afectada la pasarela de conexión. Si usas Container Registry, Artifact Registry, Cloud Build o Cloud Deploy para gestionar tus imágenes de contenedor o tus flujos de procesamiento de CI/CD enGoogle Cloud, estos dejarán de estar disponibles en caso de desconexión. Las estrategias para hacer frente a la desconexión de esos productos no se incluyen en este documento.
| Acción | Comportamiento conectado | Comportamiento de desconexión temporal | Tolerancia máxima de desconexión | Solución alternativa para la pérdida de conectividad |
|---|---|---|---|---|
| Implementación de aplicaciones | Puedes desplegar aplicaciones de forma local con kubectl, mediante herramientas de integración continua y entrega continua (CI/CD) o con la pasarela de conexión. |
La pasarela de conexión no está disponible. Todos los demás métodos de implementación siguen funcionando siempre que se conecten directamente a la API de Kubernetes. | Ilimitado | Si usas la pasarela de conexión, cambia a la conexión kubectl local. |
| Retirada de aplicaciones | Puedes quitar aplicaciones de forma local con kubectl, mediante herramientas de CI/CD o con la pasarela de conexión. |
La pasarela de conexión no está disponible. Todos los demás métodos de implementación siguen funcionando siempre que se conecten directamente a la API de Kubernetes. | Ilimitado | Si usas la pasarela de conexión, cambia a la conexión kubectl local. |
| Escalado horizontal de aplicaciones | Puedes ampliar las aplicaciones de forma local con kubectl, mediante herramientas de integración continua y entrega continua o con la pasarela de conexión. |
La pasarela de conexión no está disponible. Todos los demás métodos de implementación siguen funcionando siempre que se conecten directamente a la API de Kubernetes. | Ilimitado | Si usas la pasarela de conexión, cambia a la conexión kubectl local. |
Almacenamiento de registros y monitorización
La auditabilidad ayuda a tu organización a cumplir sus requisitos normativos y sus políticas de cumplimiento. Distributed Cloud ayuda a mejorar la auditabilidad ofreciendo registro de aplicaciones, registro de Kubernetes y registro de auditoría. Muchos clientes eligen usar Cloud Logging y Cloud Monitoring de Google para no tener que gestionar una infraestructura de monitorización y registro on-premise. Otros clientes prefieren centralizar sus registros en un sistema local para agregarlos. Para ayudar a estos clientes, Distributed Cloud admite la integración directa con servicios como Prometheus. En este modo, durante la desconexión temporal de Google Cloud, no se ve afectada la función de registro ni la de monitorización.
| Función | Comportamiento conectado | Comportamiento de desconexión temporal | Tolerancia máxima de desconexión | Solución alternativa para la pérdida de conectividad |
|---|---|---|---|---|
| Registro de aplicaciones con Cloud Logging | El sistema escribe registros en Cloud Logging. | El sistema almacena los registros en el disco local. | 4,5 horas o 4 GiB de búfer local por nodo. Cuando el búfer se llena o la desconexión dura 4,5 horas, el sistema elimina las entradas más antiguas. | Usa una solución de registro local. |
| Registro del sistema o de Kubernetes mediante Cloud Logging | El sistema escribe registros en Cloud Logging. | El sistema almacena los registros en el disco local. | 4,5 horas o 4 GiB de búfer local por nodo. Cuando el búfer se llena o la desconexión dura 4,5 horas, el sistema elimina las entradas más antiguas. | Usa una solución de registro local. |
| Registro de auditoría con registros de auditoría de Cloud | El sistema escribe registros en Cloud Logging. | El sistema almacena los registros en el disco local. | Búfer local de 10 GiB por nodo del plano de control. Cuando el búfer se llena, el sistema elimina las entradas más antiguas. | Configura el reenvío de registros a una solución de registro local. |
| Registro de aplicaciones con otro proveedor | Puedes usar diferentes proveedores externos, como Elastic, Splunk, Datadog o Loki. | Sin impacto | Ilimitado | - |
| Registro del sistema o de Kubernetes con otro proveedor | Puedes usar diferentes proveedores de terceros, como Elastic, Splunk o Datadog. | Sin impacto | Ilimitado | - |
| Métricas de aplicaciones y de Kubernetes escritas en Cloud Monitoring | El sistema escribe métricas en Cloud Monitoring. | El sistema almacena métricas en el disco local. | Búfer local de 24 horas o 6 GiB por nodo para métricas del sistema y búfer local de 1 GiB por nodo para métricas de aplicaciones. Cuando el búfer se llena o la desconexión dura 24 horas, el sistema elimina las entradas más antiguas. | Usa una solución de monitorización local. |
| Acceder y leer datos de monitorización de cargas de trabajo de Kubernetes y aplicaciones | Todas las métricas están disponibles en la consola y a través de la API Cloud Monitoring. | El sistema no actualiza las métricas en Cloud Monitoring durante la desconexión. | Búfer local de 24 horas o 6 GiB por nodo para métricas del sistema y búfer local de 1 GiB por nodo para métricas de aplicaciones. Cuando el búfer se llena o la desconexión dura 24 horas, el sistema elimina las entradas más antiguas. | Usa una solución de monitorización local. |
| Reglas de alertas y de paginación de métricas | Cloud Monitoring admite alertas. Puede crear alertas para cualquier métrica. El sistema puede enviar alertas a través de diferentes canales. | El sistema no activa alertas cuando está desconectado. El sistema solo activa alertas a partir de los datos de métricas que ya se han enviado a Cloud Monitoring. | Usa una solución de monitorización y alertas local. |
Gestión de la configuración y las políticas
Config Sync y Policy Controller te permiten gestionar la configuración y las políticas a gran escala en todos tus clústeres. Almacenas configuraciones y políticas en un repositorio de Git, y el sistema las sincroniza automáticamente con tus clústeres.
Config Sync
Config Sync usa agentes en el clúster para conectarse directamente a un repositorio de Git.
Puede gestionar los cambios en la URL del repositorio o en los parámetros de sincronización con la CLI de Google Cloud o con las herramientas de kubectl.
Durante la desconexión temporal, la sincronización no se ve afectada si los agentes del clúster siguen teniendo acceso al repositorio de Git. Sin embargo, si cambias los parámetros de sincronización con la CLI de gcloud o la consola, el clúster no los aplicará durante la desconexión.
Puedes sobrescribirlos temporalmente de forma local con kubectl. Si se vuelve a conectar, se sobrescribirán los cambios locales.
Policy Controller
Policy Controller permite aplicar políticas totalmente programables en tus clústeres. Estas políticas actúan como "barreras de protección" y evitan que se produzcan cambios que infrinjan los controles de seguridad, operativos o de cumplimiento que hayas definido.
| Acción | Comportamiento conectado | Comportamiento de desconexión temporal | Tolerancia máxima de desconexión | Solución alternativa para la pérdida de conectividad |
|---|---|---|---|---|
| Sincronizar la configuración desde un repositorio de Git | Los agentes del clúster se conectan directamente al repositorio de Git. Puedes cambiar la URL del repositorio o los parámetros de sincronización con una Google Cloud API. | La sincronización de la configuración no se verá afectada. Si cambias los parámetros de sincronización con la CLI de gcloud o en la consola, el clúster no los aplicará durante la desconexión. Puedes sobrescribirlos temporalmente de forma local con
kubectl. Si vuelves a conectar la cuenta, se sobrescribirán los cambios locales. |
Ilimitado | No utilices nunca la API Fleetpara Config Sync y configúrala únicamente mediante la API de Kubernetes. |
| Aplicar políticas en las solicitudes a la API de Kubernetes | El agente del clúster aplica las restricciones gracias a su integración con la API de Kubernetes. Las políticas se gestionan mediante la API de Kubernetes local. La configuración del sistema de Policy Controller se gestiona con una API Google Cloud. | La aplicación de la política no se verá afectada. Seguirás gestionando las políticas con la API de Kubernetes local. El sistema no propaga los cambios en la configuración del sistema de Policy Controller al clúster mediante la API Google Cloud , pero puedes sobrescribirlos temporalmente de forma local. Si vuelves a conectar la cuenta, se sobrescribirán los cambios locales. | Ilimitado | No uses nunca la API Fleetpara Policy Controller y configúrala solo mediante la API de Kubernetes. |
| Instalar, configurar o actualizar Config Sync con la API Google Cloud | Utilizas la API Google Cloud para gestionar la instalación y la actualización de los agentes del clúster. También puedes usar esta API (o la CLI de gcloud o la consola) para gestionar la configuración de estos agentes. | Los agentes del clúster siguen funcionando con normalidad. No puedes instalar, actualizar ni configurar agentes en el clúster con la API Google Cloud . Las instalaciones, actualizaciones o configuraciones pendientes que se hayan realizado mediante la API se completarán cuando se restablezca la conexión. | Cero | No uses nunca la API Fleet para Policy Controller y configúrala solo mediante la API de Kubernetes. |
| Ver el estado del sistema o de la sincronización en la consola | Puedes consultar el estado de los agentes del clúster y el estado de la sincronización mediante una Google Cloud API o la consola. | La información de estado de la Google Cloud API o de la consola se queda obsoleta. La API muestra un error de conexión. Toda la información sigue estando disponible por clúster mediante la API de Kubernetes local. | Cero | Usa la CLI de nomos o la API de Kubernetes local. |
Seguridad
En esta sección se describe cómo afectan a las funciones de seguridad, como la identidad, la autenticación, la autorización y la gestión de secretos, las desconexiones temporales de Google Cloud.
Identidad, autenticación y autorización
Distributed Cloud puede conectarse directamente a Cloud Identity para gestionar los roles de aplicaciones y usuarios, para gestionar cargas de trabajo mediante Connect o para autenticar endpoints mediante OIDC. Si se desconecta de Google Cloud , se interrumpirá la conexión con Cloud Identity y esas funciones dejarán de estar disponibles. En el caso de las cargas de trabajo que requieran una mayor resiliencia mediante una desconexión temporal, puedes usar GKE Identity Service para integrar un proveedor de LDAP u OIDC (incluido ADFS) y configurar la autenticación de usuarios finales.
| Función | Comportamiento conectado | Comportamiento de desconexión temporal | Tolerancia máxima de desconexión | Solución alternativa para la pérdida de conectividad |
|---|---|---|---|---|
| Cloud Identity como proveedor de identidades, mediante la pasarela de conexión | Puedes acceder a los recursos de Distributed Cloud usando Cloud Identity como proveedor de identidades y conectándote a través de la pasarela de conexión. | La pasarela de conexión requiere una conexión a Google Cloud. No podrás conectarte a tus clústeres durante la desconexión. | Cero | Usa el servicio de identidad de GKE para federar con otro proveedor de identidades. |
| Identidad y autenticación mediante un proveedor de identidades externo | Admite OIDC y LDAP. Primero, debes iniciar sesión con la CLI de gcloud.
En el caso de los proveedores de OIDC, puedes usar la consola para iniciar sesión. Después, puedes autenticarte normalmente en la API del clúster (por ejemplo, con kubectl). |
Siempre que el proveedor de identidades siga siendo accesible para ti y para el clúster, podrás autenticarte en la API del clúster. No puedes iniciar sesión a través de la consola. Solo puedes actualizar la configuración de OIDC o LDAP de tus clústeres de forma local. No puedes usar la consola. | Ilimitado | - |
| Autorización | Distributed Cloud admite el control de acceso basado en roles (RBAC). Los roles se pueden asignar a usuarios, grupos o cuentas de servicio. El sistema recupera las identidades de usuario y los grupos del proveedor de identidades. | El sistema de control de acceso basado en roles es local del clúster de Kubernetes y la desconexión de Google Cloud no le afecta. Sin embargo, si depende de identidades procedentes de Cloud Identity, no estarán disponibles en caso de desconexión. | Ilimitado | - |
Gestión de secretos y claves
La gestión de secretos y claves es una parte importante de tu postura de seguridad. El comportamiento de Distributed Cloud en caso de desconexión deGoogle Cloud depende del servicio que estés usando para esas funciones.
| Función | Comportamiento conectado | Comportamiento de desconexión temporal | Tolerancia máxima de desconexión | Solución alternativa para la pérdida de conectividad |
|---|---|---|---|---|
| Gestión de secretos y claves con Cloud Key Management Service y Secret Manager | Utilizas directamente Cloud Key Management Service para tus claves criptográficas y Secret Manager para tus secretos. | Cloud Key Management Service y Secret Manager no están disponibles. | Cero | Usa sistemas locales. |
| Gestión de secretos y claves con HashiCorp Vault y servicios de Google Cloud | Configura HashiCorp Vault para que use Cloud Storage o Spanner para almacenar secretos, y Cloud Key Management Service para gestionar claves. | Si HashiCorp Vault se ejecuta en tu clúster local y la desconexión también le afecta, el almacenamiento de secretos y la gestión de claves no estarán disponibles durante la desconexión. | Cero | En su lugar, usa sistemas locales. |
| Gestión de secretos y claves con HashiCorp Vault y servicios locales | Configuras HashiCorp Vault para que use un backend de almacenamiento local para los secretos y un sistema de gestión de claves local (como un módulo de seguridad de hardware). | La desconexión de Google Cloud no tiene ningún efecto. | Ilimitado | - |
Redes y servicios de red
En esta sección se tratan las redes y los servicios de red de los clústeres locales, así como el impacto que tiene una desconexión temporal deGoogle Clouden ellos. Proporciona información sobre el balanceo de carga, Cloud Service Mesh y otros servicios de red.
Balanceo de carga
Para exponer los servicios de Kubernetes alojados en un clúster local a los usuarios, tienes las siguientes opciones:
Bare metal:
Usa un balanceador de carga agrupado proporcionado, MetalLB o Agrupado con BGP.
Configura manualmente tus clústeres para que usen tu propio balanceador de carga, externo a Distributed Cloud.
VMware:
Usa el balanceador de carga agrupado que se proporciona, MetalLB.
Configura manualmente tus clústeres para que usen tu propio balanceador de carga, externo a Distributed Cloud.
Estas opciones de balanceo de carga siguen operativas aunque se desconecten deGoogle Cloud.
| Función | Comportamiento conectado | Comportamiento de desconexión temporal | Tolerancia máxima de desconexión | Solución alternativa para la pérdida de conectividad |
|---|---|---|---|---|
| Balanceador de carga agrupado L4 | Proporciona balanceo de carga de nivel 4 de forma totalmente local sin depender deGoogle Cloud APIs ni de la red. | Sin cambios | Ilimitado | - |
| Balanceador de carga manual o integrado | Admite F5 BIG-IP y otros que también están alojados en las instalaciones. | Sin cambios | Ilimitado | - |
Cloud Service Mesh
Puedes usar Cloud Service Mesh para gestionar, observar y proteger las comunicaciones entre tus servicios que se ejecutan en un clúster local. Distributed Cloud no admite todas las funciones de Cloud Service Mesh. Consulta la lista de funciones admitidas para obtener más información.
| Función | Comportamiento conectado | Comportamiento de desconexión temporal | Tolerancia máxima de desconexión | Solución alternativa para la pérdida de conectividad |
|---|---|---|---|---|
| Implementar o actualizar políticas (de enrutamiento, autorización, seguridad, auditoría, etc.) | Puedes usar la consola, kubectl, asmcli o istioctl para gestionar las políticas de Cloud Service Mesh. |
Solo puedes usar kubectl o istioctl para gestionar las políticas de Cloud Service Mesh. |
Ilimitado | Usa kubectl o istioctl |
| Autoridad de certificación (CA) | Puedes usar la AC del clúster o la AC de Cloud Service Mesh para gestionar los certificados que usa Cloud Service Mesh. | No habrá ningún impacto si usas la CA del clúster. Si usas la autoridad de certificación de Cloud Service Mesh, los certificados caducarán al cabo de 24 horas. Las nuevas instancias de servicio no pueden recuperar certificados. |
Ilimitado para la AC del clúster. Servicio degradado durante 24 horas y sin servicio después de 24 horas para la autoridad de certificación de Cloud Service Mesh. |
Usa la CA del clúster. |
| Cloud Monitoring para Cloud Service Mesh | Puedes usar Cloud Monitoring para almacenar, explorar y aprovechar las métricas relacionadas con HTTP procedentes de la malla de servicios de Cloud. | Las métricas no se almacenan. | Cero | Usa una solución de monitorización local compatible, como Prometheus. |
| Registro de auditoría de Cloud Service Mesh | Cloud Service Mesh se basa en las funciones de registro de Kubernetes locales. El comportamiento depende de cómo hayas configurado el registro de tu clúster local. | Depende de cómo hayas configurado el registro de tu clúster local. | - | - |
| Pasarela de entrada | Puedes definir IPs externas con Istio Ingress Gateway. | Sin impacto | Ilimitado | - |
| Interfaz de red de contenedores (CNI) de Istio | Puedes configurar Cloud Service Mesh para que use Istio CNI en lugar de iptables para gestionar el tráfico. | Sin impacto | Ilimitado | - |
| Autenticación de usuarios finales de Cloud Service Mesh para aplicaciones web | Puedes usar la pasarela de entrada de Cloud Service Mesh para integrarla con tu propio proveedor de identidades (a través de OIDC) y autenticar y autorizar a los usuarios finales en las aplicaciones web que forman parte de la malla. | Sin impacto | Ilimitado | - |
Otros servicios de red
| Función | Comportamiento conectado | Comportamiento de desconexión temporal | Tolerancia máxima de desconexión | Solución alternativa para la pérdida de conectividad |
|---|---|---|---|---|
| DNS | El servidor DNS de Kubernetes se ejecuta dentro del clúster. | El servicio DNS de Kubernetes funciona con normalidad, ya que se ejecuta dentro del clúster. | Ilimitado | - |
| Proxy de salida | Puedes configurar tus clústeres locales para que usen un proxy en las conexiones de salida. | Si tu proxy se ejecuta de forma local, el clúster podrá seguir usándolo durante una desconexión temporal. Sin embargo, si el proxy pierde la conexión con Google Cloud, se seguirán aplicando todos los casos descritos en este documento. | Ilimitado | - |
Google Cloud Marketplace
| Función | Comportamiento conectado | Comportamiento de desconexión temporal | Tolerancia máxima de desconexión | Solución alternativa para la pérdida de conectividad |
|---|---|---|---|---|
| Desplegar y gestionar aplicaciones y servicios desde Cloud Marketplace | Cloud Marketplace está disponible en la consola y puedes usarlo para descubrir, adquirir e implementar soluciones. | No puedes usar Cloud Marketplace. Es posible que algunas soluciones de Cloud Marketplace tengan sus propios requisitos de conectividad, que no se documentan aquí. | Cero | Ninguno |
Asistencia
En esta sección se describen las situaciones que pueden darse al interactuar con el Google Cloud equipo de Asistencia o con tu partner operativo en un caso relacionado con tus clústeres de GKE en GDC.
| Función | Comportamiento conectado | Comportamiento de desconexión temporal | Tolerancia máxima de desconexión | Solución alternativa para la pérdida de conectividad |
|---|---|---|---|---|
| Compartir una instantánea de un clúster con el equipo de Asistencia | Puedes crear una instantánea de clúster de forma local con los comandos bmctl check
cluster o gkectl diagnose snapshot. Compartirás esta captura de pantalla mediante el proceso de asistencia habitual. |
Puedes seguir generando la captura, ya que es una operación local. Si has perdido el acceso a Google Cloud y a sus interfaces web de asistencia, puedes llamar al equipo de Asistencia si te has suscrito a los planes de Asistencia Mejorada o Premium. | Ilimitado | - |
| Compartir datos de registro relevantes con el equipo de Asistencia | Puedes recoger registros de forma local desde tu clúster y compartirlos mediante el proceso de asistencia habitual. | Puedes seguir recogiendo registros de tu clúster. Si has perdido el acceso a Google Cloud y a sus interfaces web de asistencia, puedes llamar al equipo de Asistencia si te has suscrito a los planes de Asistencia Mejorada o Premium. | Ilimitado | - |