La edición Enterprise de Google Kubernetes Engine (GKE) es la Google Cloud plataforma de modernización de aplicaciones. Se basa en Kubernetes y se puede implementar en Google Cloud, en otras nubes y on‐premise con Google Distributed Cloud (tanto en VMware como en servidores bare metal). Aunque un clúster gestionado por GKE Enterprise se ejecute de forma local, está diseñado para tener una conexión permanente conGoogle Cloud por varios motivos, como la monitorización y la gestión. Sin embargo, puede que necesites saber qué ocurriría si, por algún motivo, se perdiera 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 Google 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 o forzada de Google Cloud y comprender sus consecuencias. Sin embargo, no deberías plantearte usar una implementación de Google Distributed Cloud solo de software desconectada deGoogle Cloud como modo de funcionamiento nominal. Recuerda que diseñamos GKE Enterprise para aprovechar la escalabilidad y la disponibilidad de losGoogle Cloud servicios. Este documento se basa en el diseño y la arquitectura de los distintos componentes de GKE Enterprise 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 de GKE Enterprise
Si has habilitado GKE Enterprise, lo que significa que la API de Anthos (anthos.googleapis.com) está habilitada en tu proyecto Google Cloud , el controlador de medición de GKE Enterprise, que se ejecuta en el clúster, genera y actualiza el derecho de GKE Enterprise periódicamente. La tolerancia a la desconexión es de 12 horas. Además, la medición y la facturación se gestionan a través de la conexió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 licencias de GKE Enterprise | El controlador de medición de GKE Enterprise genera y actualiza el recurso personalizado de derecho de GKE Enterprise periódicamente, siempre que anthos.googleapis.com esté habilitado en el Google Cloud proyecto. | 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. | Actualmente 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 de GKE Enterprise comunica la capacidad de vCPU del clúster a la Google Cloud API Service Control para la facturación. | Hay un agente en el clúster que conserva los registros de facturación en el clúster cuando se desconecta, y los registros se recuperan una vez que el clúster se vuelve a conectar a Google Cloud. | Ilimitado. Sin embargo, se requiere información de medición de GKE Enterprise para cumplir los Términos Específicos del Servicio de "Software Premium". | Ninguno |
Ciclo de vida del clúster
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 sin 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 | Para actualizar clústeres, usa las herramientas de CLI bmctl o gkectl. Esta operación requiere una conexión a Google Cloud. |
No puedes actualizar clústeres. | Cero | Ninguno |
| Eliminación de clústeres | Para eliminar clústeres, puedes usar las herramientas de CLI bmctl o gkectl. 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 Google Cloud consola en la lista de clústeres de Google Kubernetes Engine. | La información del clúster no se muestra en la Google Cloud 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 quitar 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
La gestión de las aplicaciones que se ejecutan en un clúster local no se ve afectada en gran medida por una desconexión temporal de Google Cloud. Solo se ve afectado el servicio Connect Gateway. Si usas Container Registry, Artifact Registry, Cloud Build o Cloud Deploy para gestionar tus imágenes de contenedor o tus flujos de trabajo de CI/CD enGoogle Cloud, ya no estarán 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 | Se hace de forma local con kubectl, mediante herramientas de CI/CD o con Connect
Gateway. |
La Connect Gateway no está disponible. Todos los demás métodos de despliegue siguen funcionando siempre que se conecten directamente a la API de Kubernetes. | Ilimitado | Si estabas usando la pasarela de conexión, cambia a kubectl local. |
| Retirada de aplicaciones | Se hace de forma local con kubectl, mediante herramientas de CI/CD o con Connect
Gateway. |
La Connect Gateway no está disponible. Todos los demás métodos de despliegue siguen funcionando siempre que se conecten directamente a la API de Kubernetes. | Ilimitado | Si estabas usando la pasarela de conexión, cambia a kubectl local. |
| Escalado horizontal de aplicaciones | Se hace de forma local con kubectl, mediante herramientas de CI/CD o con Connect
Gateway. |
La Connect Gateway no está disponible. Todos los demás métodos de despliegue siguen funcionando siempre que se conecten directamente a la API de Kubernetes. | Ilimitado | Si estabas usando la pasarela de conexión, cambia a 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. GKE Enterprise ayuda a mejorar la auditabilidad ofreciendo registros de aplicaciones, registros de Kubernetes y registros de auditoría. Muchos clientes prefieren usar Cloud Logging y Cloud Monitoring de Google para no tener que gestionar una infraestructura de almacenamiento de registros y monitorización local. Otros clientes prefieren centralizar sus registros en un sistema local para agregarlos. Para ayudar a estos clientes, GKE Enterprise ofrece integración directa con servicios como Prometheus, Elastic, Splunk o Datadog. En este modo, durante la desconexión temporal de Google Cloud, no se ve afectada la funcionalidad de registro ni 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 | Los registros se escriben en Cloud Logging. | Los registros se almacenan 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, se eliminan las entradas más antiguas. | Usa una solución de registro local. |
| Registro del sistema o de Kubernetes mediante Cloud Logging | Los registros se escriben en Cloud Logging. | Los registros se almacenan 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, se eliminan las entradas más antiguas. | Usa una solución de registro local. |
| Registro de auditoría con registros de auditoría de Cloud | Los registros se escriben en Cloud Logging. | Los registros se almacenan en el disco local. | 10 GiB de búfer local por nodo del plano de control. Cuando el búfer se llena, se eliminan 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 | Las métricas se escriben en Cloud Monitoring. | Las métricas se almacenan 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, se eliminan 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 Google Cloud consola y a través de la API Cloud Monitoring. | Las métricas no se actualizan 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, se eliminan 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. Las alertas se pueden enviar a través de diferentes canales. | Las alertas no se activan cuando no hay conexión. Las alertas solo se activan 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 se sincronizan automáticamente con tus clústeres.
Config Sync
Config Sync usa agentes en el clúster para conectarse directamente a un repositorio de Git. Puedes gestionar los cambios en la URL del repositorio o en los parámetros de sincronización con las herramientas gcloud o kubectl.
Durante una 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 Google Cloud CLI o la consola Google Cloud , no se aplicarán al clúster durante la desconexión. Puedes sobrescribirlos temporalmente
de forma local con kubectl. Los cambios locales se sobrescriben al volver a conectarse.
Policy Controller
Policy Controller permite aplicar políticas totalmente programables en tus clústeres. Estas políticas actúan como "prescripciones" 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 las configuraciones no se ve afectada. Si cambias los parámetros de sincronización con gcloud o en la Google Cloud consola, no se aplicarán al clúster durante la desconexión. Puedes sobrescribirlas temporalmente de forma local con kubectl. Los cambios locales se sobrescriben al volver a conectarse. |
Ilimitado | No uses nunca la API Fleet para Config Sync y configúrala solo mediante la API de Kubernetes. |
| Aplicar políticas en las solicitudes a la API de Kubernetes | El agente en el 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 Google Cloud API. | La aplicación de la política no se ve afectada. Las políticas se siguen gestionando mediante la API de Kubernetes local. Los cambios en la configuración del sistema de Policy Controller mediante la APIGoogle Cloud no se propagan al clúster, pero puedes sobrescribirlos temporalmente de forma local. Los cambios locales se sobrescriben al volver a conectarse. | Ilimitado | No uses nunca la API Fleet para Policy Controller y configúrala únicamente con 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 gcloud, o la consola Google Cloud ) 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 mediante la Google Cloud API. 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 únicamente con la API de Kubernetes. |
| Ver el estado del sistema o de la sincronización en la Google Cloud 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 Google Cloud consola. | La información de estado de la Google Cloud API o de la Google Cloud 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
Identidad, autenticación y autorización
GKE Enterprise puede conectarse directamente a Cloud Identity para los roles de aplicaciones y usuarios, para gestionar cargas de trabajo mediante Connect o para la autenticación de endpoints mediante OIDC. Si se desconecta de Google Cloud, también 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 LDAP u OIDC (incluido ADFS) y configurar la autenticación de los 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 GKE Enterprise usando Cloud Identity como proveedor de identidades y conectándote a través de la puerta de enlace Connect. | La pasarela Connect 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 Google Cloud 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 Google Cloud consola. Solo puedes actualizar la configuración de OIDC o LDAP de tus clústeres de forma local. No puedes usar la consola. Google Cloud | Ilimitado | - |
| Autorización | GKE Enterprise admite el control de acceso basado en roles (RBAC). Los roles se pueden atribuir a usuarios, grupos o cuentas de servicio. Las identidades de usuario y los grupos se pueden obtener del proveedor de identidades. | El sistema de control de acceso basado en roles es local del clúster de Kubernetes y no se ve afectado por la desconexión de Google Cloud. 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 GKE Enterprise en caso de desconexión de Google Cloud depende del servicio que utilices 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 de Anthos y también se ve afectado por la desconexión, el almacenamiento de secretos y la gestión de claves no estarán disponibles durante la desconexión. | Cero | 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
Balanceo de carga
Para exponer los servicios de Kubernetes alojados en un clúster local a los usuarios, puedes usar el balanceador de carga incluido (MetalLB en bare metal, Seesaw o MetalLB en VMware) o tu balanceador de carga, que es externo a GKE Enterprise. Ambas opciones siguen funcionando en caso de que se pierda la conexión con 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 |
|---|---|---|---|---|
| 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 | Es compatible con 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. No todas las funciones de Cloud Service Mesh son compatibles con Google Distributed Cloud. Consulta la lista de funciones compatibles 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.) | Puede usar la consola de Google Cloud , 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 obtener 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 de GKE Enterprise. | Depende de cómo hayas configurado el registro de tu clúster de GKE Enterprise. | - | - |
| 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 puerta de enlace 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 GKE Enterprise para que use un proxy en las conexiones de salida. | Si tu proxy se ejecuta de forma local, GKE Enterprise 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 de Google Cloud y puedes usarlo para descubrir, adquirir e implementar soluciones. | No puedes usar Cloud Marketplace. Algunas soluciones de Cloud Marketplace pueden tener 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. Puedes compartir esta captura de pantalla siguiendo 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 | - |