La edición Google Kubernetes Engine (GKE) Enterprise es la plataforma de modernización de aplicaciones de Google Cloud. Se basa en Kubernetes y se puede implementar en Google Cloud, en otras nubes y de forma local con Google Distributed Cloud (tanto en VMware como en servidores de equipos físicos). Incluso cuando un clúster administrado por GKE Enterprise se ejecuta de forma local, se diseñó para tener una conexión permanente a Google Cloud por varios motivos, como la supervisión y la administración. Sin embargo, es posible que necesites saber qué sucedería si, por algún motivo, se pierde la conexión a Google Cloud (por ejemplo, debido a un problema técnico). En este documento, se describe el impacto de la pérdida de conectividad de los clústeres en una implementación que solo usa software de Google Distributed Cloud (en equipos físicos o en VMware) y qué soluciones alternativas puedes usar en este caso.
Esta información es útil para los arquitectos que necesitan prepararse para una desconexión forzada o no planificada de Google Cloud y comprender sus consecuencias. Sin embargo, no debes planificar usar una implementación de Google Distributed Cloud que solo usa software desconectada de Google Cloud como un modo de trabajo nominal. Recuerda que diseñamos GKE Enterprise para aprovechar la escalabilidad y la disponibilidad de los servicios de Google Cloud. 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 supone que estás familiarizado con GKE Enterprise. Si no es así, te recomendamos que primero leas la descripción general técnica de GKE Enterprise.
Validación y medición de licencias de GKE Enterprise
Si habilitaste GKE Enterprise, lo que significa que la API de Anthos (anthos.googleapis.com) está habilitada en tu proyecto de Google Cloud, el controlador de medición de GKE Enterprise, que se ejecuta en el clúster, genera y actualiza las autorizaciones de GKE Enterprise de forma periódica. La tolerancia a la desconexión es de 12 horas. Además, la medición y la facturación se administran a través de la conexión.
En esta tabla, se describe 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 en una desconexión temporal | Tolerancia máxima a la 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 autorización de GKE Enterprise de forma periódica, siempre que anthos.googleapis.com esté habilitada en el proyecto de Google Cloud. | Los componentes que consumen el recurso personalizado de autorización admiten un período de gracia: continúan funcionando siempre que el recurso personalizado de autorización se actualice dentro del período de gracia. | Actualmente ilimitada. Una vez vencido el período de gracia, los componentes comienzan a registrar errores. Ya no puedes actualizar tu clúster. | Ninguno |
| Medición y facturación | El controlador de medición de GKE Enterprise informa la capacidad de CPU virtual del clúster a la API de Service Control de Google Cloud con fines de facturación. | Existe 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. | Ilimitada. Sin embargo, se requiere la información de medición de GKE Enterprise para el cumplimiento, como se indica en las Condiciones específicas del servicio de “Software Premium”. | Ninguno |
Ciclo de vida del clúster
En esta sección, se abarcan situaciones como la creación, la actualización, la eliminación y el cambio de tamaño de clústeres, así como la supervisió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 supervisar el estado de esas operaciones con estas herramientas. Cuando se restablece la conexión, la consola de Google Cloud se actualiza para mostrar los resultados de las operaciones realizadas durante el período de desconexión.
| Acción | Comportamiento conectado | Comportamiento en una desconexión temporal | Tolerancia máxima a la desconexión | Solución alternativa para la pérdida de conectividad |
|---|---|---|---|---|
| Creación de clústeres | Usa las herramientas de la CLI de 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ústeres | Usa las herramientas de la CLI de bmctl o gkectl para actualizar los clústeres. Esta operación requiere una conexión a Google Cloud. |
No puedes actualizar los clústeres. | Cero | Ninguno |
| Eliminación de clústeres | Usas las herramientas de la CLI de bmctl o gkectl para borrar clústeres. Esta operación no requiere una conexión a Google Cloud. |
Puedes borrar clústeres. | Ilimitado | - |
| Ver el estado de los clústeres | Puedes obtener información sobre tus clústeres en la consola de Google Cloud, en la lista de clústeres de Google Kubernetes Engine. | La información del clúster no se muestra en la consola de Google Cloud. | Ilimitado | Usa kubectl para consultar directamente tus clústeres y obtener la información que necesitas. |
| Quitar 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 | - |
| Agregar nodos a un clúster | El nodo nuevo extrae imágenes de contenedor de Container Registry para funcionar de forma correcta. Se ejecuta una verificación preliminar para validar que haya conectividad a Google Cloud. | Las verificaciones preliminares que se ejecutan cuando se agrega un nodo nuevo validan que haya conectividad a Google Cloud. Por lo tanto, no puedes agregar un nodo nuevo a un clúster cuando no hay conexión. | Cero | Ninguno |
Ciclo de vida de la aplicación
En general, la administración de las aplicaciones que se ejecutan en un clúster local no se ve afectada por una desconexión temporal de Google Cloud. Solo se ve afectada la puerta de enlace de Connect. Si usas Container Registry, Artifact Registry, Cloud Build o Cloud Deploy para administrar tus imágenes de contenedor o las canalizaciones de CI/CD en Google Cloud, ya no están disponibles en caso de desconexión. Las estrategias para lidiar con la desconexión de esos productos están fuera del alcance de este documento.
| Acción | Comportamiento conectado | Comportamiento en una desconexión temporal | Tolerancia máxima a la desconexión | Solución alternativa para la pérdida de conectividad |
|---|---|---|---|---|
| Implementación de la aplicación | Esto se hace de forma local mediante kubectl, a través de herramientas de CI/CD o mediante la puerta de enlace de Connect. |
La puerta de enlace de Connect no está disponible. Todos los demás métodos de implementaciones aún funcionan siempre que se conecten directamente a la API de Kubernetes. | Ilimitado | Si usabas la puerta de enlace de Connect, cámbiala y usa kubectl de forma local. |
| Eliminación de aplicaciones | Esto se hace de forma local mediante kubectl, a través de herramientas de CI/CD o mediante la puerta de enlace de Connect. |
La puerta de enlace de Connect no está disponible. Todos los demás métodos de implementaciones aún funcionan siempre que se conecten directamente a la API de Kubernetes. | Ilimitado | Si usabas la puerta de enlace de Connect, cámbiala y usa kubectl de forma local. |
| Escalamiento horizontal de aplicaciones | Esto se hace de forma local mediante kubectl, a través de herramientas de CI/CD o mediante la puerta de enlace de Connect. |
La puerta de enlace de Connect no está disponible. Todos los demás métodos de implementaciones aún funcionan siempre que se conecten directamente a la API de Kubernetes. | Ilimitado | Si usabas la puerta de enlace de Connect, cámbiala y usa kubectl de forma local. |
Registro y supervisión
La auditabilidad ayuda a tu organización a cumplir con los requisitos reglamentarios y las políticas de cumplimiento. GKE Enterprise ayuda con la auditabilidad, ya que ofrece registro de aplicaciones, registro de Kubernetes y registro de auditoría. Muchos clientes eligen aprovechar Cloud Logging y Cloud Monitoring de Google para evitar la administración local de una infraestructura de registro y supervisión. Otros clientes prefieren centralizar sus registros en un sistema local para su agregación. Para admitir a estos clientes, GKE Enterprise proporciona integración directa a servicios como Prometheus, Elastic, Splunk o Datadog. En este modo, durante una desconexión temporal de Google Cloud, no hay impacto en las funciones de registro y supervisión.
| Función | Comportamiento conectado | Comportamiento en una desconexión temporal | Tolerancia máxima a la 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 búfer en el disco local. | 4.5 h o 4 GiB de búfer local por nodo. Cuando se llena el búfer o la desconexión dura 4.5 horas, se descartan las entradas más antiguas. | Usa una solución de registro local. |
| Registro del sistema o Kubernetes mediante Cloud Logging | Los registros se escriben en Cloud Logging. | Los registros se almacenan en búfer en el disco local. | 4.5 h o 4 GiB de búfer local por nodo. Cuando se llena el búfer o la desconexión dura 4.5 horas, se descartan 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 búfer en el disco local. | 10 GiB de búfer local por nodo del plano de control. Cuando se llena el búfer, se descartan 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 de terceros, como Elastic, Splunk, Datadog o Loki. | No hubo impacto. | Ilimitado | - |
| Registro del sistema o Kubernetes mediante otro proveedor | Puedes usar diferentes proveedores de terceros, como Elastic, Splunk o Datadog. | No hubo impacto. | Ilimitado | - |
| Métricas de aplicaciones y Kubernetes escritas en Cloud Monitoring | Las métricas se escriben en Cloud Monitoring. | Las métricas se almacenan en búfer en el disco local. | Búfer local de 24 h o 6 GiB por nodo para las métricas del sistema y 1 GiB de búfer local por nodo para las métricas de la aplicación. Cuando se llena el búfer o la desconexión dura 24 horas, se descartan las entradas más antiguas. | Usa una solución de supervisión local. |
| Acceder y leer datos de supervisión de Kubernetes y cargas de trabajo de aplicaciones | Todas las métricas están disponibles en la consola de Google Cloud y a través de la API de Cloud Monitoring. | Las métricas no se actualizan en Cloud Monitoring durante la desconexión. | Búfer local de 24 h o 6 GiB por nodo para las métricas del sistema y 1 GiB de búfer local por nodo para las métricas de la aplicación. Cuando se llena el búfer o la desconexión dura 24 horas, se descartan las entradas más antiguas. | Usa una solución de supervisión local. |
| Reglas de alerta y paginación para métricas | Cloud Monitoring admite alertas. Puedes crear alertas para cualquier métrica. Las alertas se pueden enviar a través de diferentes canales. | Las alertas no se activan mientras no haya conexión. Las alertas solo se activan a partir de datos de métricas ya enviados a Cloud Monitoring | Usa una solución local de supervisión y alertas |
Administración de configuración y políticas
El Sincronizador de configuración y Policy Controller te permiten administrar la configuración y las políticas a gran escala en todos tus clústeres. Las configuraciones y las políticas se almacenan en un repositorio de Git y se sincronizan de forma automática con tus clústeres.
Sincronizador de configuración
El Sincronizador de configuración usa agentes en el clúster para conectarse directamente a un repositorio de Git. Puedes administrar los cambios en la URL del repositorio o los parámetros de sincronización mediante las herramientas de gcloud o kubectl.
Durante una desconexión temporal, la sincronización no se ve afectada si los agentes en el clúster aún pueden comunicarse con el repositorio de Git. Sin embargo, si cambias los parámetros de sincronización con Google Cloud CLI o la consola de Google Cloud, no se aplican al clúster durante la desconexión. Puedes reemplazarlos temporalmente de forma local por kubectl. Cualquier cambio local se reemplaza cuando se restablece la conexión.
Policy Controller
Policy Controller permite la aplicación de políticas completamente programables para tus clústeres. Estas políticas actúan como “vallas de contención” y evitan cualquier cambio que infrinja los controles de seguridad, operativos o de cumplimiento que definiste.
| Acción | Comportamiento conectado | Comportamiento en una desconexión temporal | Tolerancia máxima a la desconexión | Solución alternativa para la pérdida de conectividad |
|---|---|---|---|---|
| Sincronizar la configuración desde un repositorio de Git | Los agentes en el clúster se conectan directamente al repositorio de Git. Puedes cambiar la URL del repositorio o los parámetros de sincronización mediante una API de Google Cloud. | La sincronización de las configuraciones no se ve afectada. Si cambias los parámetros de sincronización con gcloud o en la consola de Google Cloud, no se aplicarán al clúster durante la desconexión. Puedes reemplazarlos temporalmente de forma local por kubectl. Cualquier cambio local se reemplaza cuando se restablece la conexión. |
Ilimitado | Nunca uses la API de Fleet para el Sincronizador de configuración, y solo configúrala con la API de Kubernetes. |
| Aplicar políticas en solicitudes a la API de Kubernetes | El agente en el clúster aplica limitaciones gracias a su integración con la API de Kubernetes. Las políticas se administran con la API local de Kubernetes. La configuración del sistema de Policy Controller se administra con una API de Google Cloud. | La aplicación de políticas no se ve afectada. Las políticas se siguen administrando mediante la API local de Kubernetes. Los cambios en la configuración del sistema de Policy Controller mediante la API de Google Cloud no se propagan al clúster, pero puedes reemplazarlos temporalmente de forma local. Cualquier cambio local se reemplaza cuando se restablece la conexión. | Ilimitado | Nunca uses la API de Fleet para Policy Controller, y solo configúrala con la API de Kubernetes. |
| Instala, configura o actualiza el Sincronizador de configuración con la API de Google Cloud | Usas la API de Google Cloud para administrar la instalación y actualización de los agentes en el clúster. También puedes usar esta API (o gcloud, o la consola de Google Cloud) para administrar la configuración de estos agentes. | Los agentes en el clúster siguen funcionando con normalidad. No puedes instalar, actualizar ni configurar agentes en el clúster mediante la API de Google Cloud. Cualquier instalación, actualización o configuración pendiente con la API continúa cuando se restablece la conexión. | Cero | Nunca uses la API de Fleet para Policy Controller, y solo configúrala con la API de Kubernetes. |
| Visualiza el estado del sistema o de la sincronización en la consola de Google Cloud | Puedes ver el estado de los agentes en el clúster y el estado de la sincronización mediante una API de Google Cloud o en la consola de Google Cloud. | La información de estado en la API de Google Cloud o la consola de Google Cloud queda inactiva. La API muestra un error de conexión. Toda la información permanece disponible por clúster mediante la API local de Kubernetes. | Cero | Usa la CLI de nomos o la API local de Kubernetes. |
Seguridad
Identidad, autenticación y autorización
GKE Enterprise puede conectarse directamente a Cloud Identity para roles de usuario y aplicación, a fin de administrar cargas de trabajo mediante Connect o realizar la autenticación de extremos con OIDC. En caso de desconexión de Google Cloud, la conexión a Cloud Identity también se divide, y esas funciones dejan de estar disponibles. Para las cargas de trabajo que requieren resiliencia adicional durante una desconexión temporal, puedes usar GKE Identity Service con el objetivo de integrarlo a un proveedor de OIDC o LDAP (incluido ADFS) para configurar la autenticación del usuario final.
| Función | Comportamiento conectado | Comportamiento en una desconexión temporal | Tolerancia máxima a la desconexión | Solución alternativa para la pérdida de conectividad |
|---|---|---|---|---|
| Cloud Identity como proveedor de identidad, mediante la puerta de enlace de Connect | Puedes acceder a los recursos de GKE Enterprise con Cloud Identity como el proveedor de identidad y conectarte a través de la puerta de enlace de Connect. | La puerta de enlace de Connect requiere una conexión a Google Cloud. No podrás conectarte a los clústeres durante la desconexión. | Cero | Usa GKE Identity Service para federarte con otro proveedor de identidad. |
| Identidad y autenticación con un proveedor de identidad de terceros | Admite OIDC y LDAP. Debes usar la gcloud CLI para acceder por primera vez. En el caso de los proveedores de OIDC, puedes usar la consola de Google Cloud para acceder. Luego, puedes autenticarte normalmente en la API del clúster (por ejemplo, con kubectl). |
Siempre que tú y el clúster puedan acceder al proveedor de identidad, aún puedes autenticarte en la API del clúster. No puedes acceder a través de la consola de Google Cloud. Solo puedes actualizar la configuración de OIDC o LDAP de tus clústeres de forma local; no puedes usar la consola de 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 recuperar desde el proveedor de identidad. | El sistema RBAC es local para el clúster de Kubernetes y no se ve afectado por la desconexión de Google Cloud. Sin embargo, si depende de identidades que provienen de Cloud Identity, no están disponibles en caso de desconexión. | Ilimitado | - |
Administración de claves y secretos
La administración de claves y Secrets 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 uses para esas funciones.
| Función | Comportamiento conectado | Comportamiento en una desconexión temporal | Tolerancia máxima a la desconexión | Solución alternativa para la pérdida de conectividad |
|---|---|---|---|---|
| Administración de Secrets y claves mediante Cloud Key Management Service y Secret Manager | Usas Cloud Key Management Service directamente para tus claves criptográficas y Secret Manager para tus Secrets. | Cloud Key Management Service y Secret Manager no están disponibles. | Cero | En su lugar, usa sistemas locales. |
| Administración de claves y Secrets mediante los servicios de Hashicorp Vault y Google Cloud | Configura Hashicorp Vault a fin de usar Cloud Storage o Cloud Spanner para almacenar Secrets, y Cloud Key Management Service a fin de administrar las 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 administración de claves no estarán disponibles durante la desconexión. | Cero | En su lugar, usa sistemas locales. |
| Administración de Secrets y claves mediante Hashicorp Vault y servicios locales | Configura Hashicorp Vault a fin de usar un backend de almacenamiento local para los secretos y un sistema de administración de claves local (como un módulo de seguridad de hardware). | La desconexión de Google Cloud no tiene ningún impacto. | Ilimitado | - |
Herramientas de redes y servicios de red
Balanceo de cargas
Para exponer los servicios de Kubernetes alojados en un clúster local a los usuarios, tienes la opción de usar el balanceador de cargas en paquetes proporcionado (MetalLB en equipos físicos, Seesaw o MetalLB en VMware) o tu balanceador de cargas, externo a GKE Enterprise. Ambas opciones continúan funcionando en caso de una desconexión de Google Cloud.
| Función | Comportamiento conectado | Comportamiento en una desconexión temporal | Tolerancia máxima a la desconexión | Solución alternativa para la pérdida de conectividad |
|---|---|---|---|---|
| Balanceador de cargas L4 en paquetes | Proporciona balanceo de cargas L4 de forma completamente local sin dependencia de la red o las APIs de Google Cloud. | Sin cambios | Ilimitado | - |
| Balanceador de cargas manual o integrado | Es compatible con BIG-IP de F5 y otros que también se alojan de forma local. | Sin cambios | Ilimitado | - |
Cloud Service Mesh
Puedes usar Cloud Service Mesh para administrar, observar y proteger las comunicaciones en los servicios que se ejecutan en un clúster local. Es posible que no todas las funciones de Cloud Service Mesh sean compatibles con Google Distributed Cloud: consulta la lista de funciones compatibles para obtener más información.
| Función | Comportamiento conectado | Comportamiento en una desconexión temporal | Tolerancia máxima a la desconexión | Solución alternativa para la pérdida de conectividad |
|---|---|---|---|---|
| Implementar o actualizar políticas (enrutamiento, autorización, seguridad, auditoría, etcétera) | Puedes usar la consola de Google Cloud, kubectl, asmcli o istioctl para administrar las políticas de Cloud Service Mesh. |
Solo puedes usar kubectl o istioctl para administrar las políticas de Cloud Service Mesh. |
Ilimitado | Usa kubectl o istioctl |
| Autoridad certificadora (CA) | Puedes usar la CA en el clúster o la autoridad certificadora de Cloud Service Mesh para administrar los certificados que usa Cloud Service Mesh. | No hay ningún impacto si usas la CA en el clúster. Si usas la autoridad certificadora de Cloud Service Mesh, los certificados vencen después de 24 horas. Las instancias de servicio nuevas no pueden recuperar certificados. |
Ilimitado para la CA en el clúster. Servicio degradado durante 24 horas, y ningún servicio después de 24 horas para la autoridad certificadora de Cloud Service Mesh. |
Usa la CA en el clúster. |
| Cloud Monitoring para Cloud Service Mesh | Puedes usar Cloud Monitoring para almacenar, explorar y aprovechar las métricas relacionadas con HTTP que provienen de Cloud Service Mesh. | No se almacenan las métricas. | Cero | Usa una solución de supervisión local compatible, como Prometheus. |
| Registros de auditoría de Cloud Service Mesh | Cloud Service Mesh depende de las instalaciones de registro locales de Kubernetes. El comportamiento depende de cómo configuraste el registro para tu clúster de GKE Enterprise. | Depende de cómo configuraste el registro para tu clúster de GKE Enterprise. | - | - |
| Puerta de enlace de entrada | Puedes definir IP externas con la puerta de enlace de entrada de Istio. | No hubo impacto. | Ilimitado | - |
| Interfaz de red de contenedor (CNI) de Istio | Puedes configurar Cloud Service Mesh para usar la CNI de Istio en lugar de iptables para administrar el tráfico. | No hubo impacto. | Ilimitado | - |
| Autenticación del usuario final de Cloud Service Mesh para aplicaciones web | Puedes usar la puerta de enlace de entrada de Cloud Service Mesh para integrarla en tu propio proveedor de identidad (a través de OIDC) a fin de autenticar y autorizar a los usuarios finales en aplicaciones web que forman parte de la malla. | No hubo impacto. | Ilimitado | - |
Otros servicios de red
| Función | Comportamiento conectado | Comportamiento en una desconexión temporal | Tolerancia máxima a la 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 de DNS de Kubernetes funciona con normalidad, ya que se ejecuta dentro del clúster. | Ilimitado | - |
| Proxy de salida | Puedes configurar GKE Enterprise con el objetivo de usar un proxy para las conexiones de salida. | Si el proxy se ejecuta de forma local, GKE Enterprise aún puede usarlo durante una desconexión temporal. Sin embargo, si el proxy pierde la conexión con Google Cloud, se aplican todas las situaciones de este documento. | Ilimitado | - |
Google Cloud Marketplace
| Función | Comportamiento conectado | Comportamiento en una desconexión temporal | Tolerancia máxima a la desconexión | Solución alternativa para la pérdida de conectividad |
|---|---|---|---|---|
| Implementar y administrar 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 cubren las situaciones que podrían presentarse mientras interactúas con la asistencia de Google Cloud o tu socio operativo para un caso relacionado con tus clústeres de GKE en GDC.
| Función | Comportamiento conectado | Comportamiento en una desconexión temporal | Tolerancia máxima a la desconexión | Solución alternativa para la pérdida de conectividad |
|---|---|---|---|---|
| Compartir una instantánea del clúster con el equipo de asistencia al cliente | Puedes crear una instantánea de clúster de forma local con los comandos bmctl check cluster o gkectl diagnose snapshot. Puedes compartir esta instantánea a través del proceso de asistencia normal. |
Aún puedes generar la instantánea, ya que es una operación local. Si perdiste acceso a Google Cloud y sus interfaces web de asistencia, puedes llamar al equipo de asistencia siempre que te hayas suscrito a los planes de asistencia Mejorada o Premium. | Ilimitado | - |
| Comparte datos de registro relevantes con el equipo de asistencia al cliente | Puedes recopilar registros de forma local de tu clúster y compartirlos a través del proceso de asistencia normal. | Aún puedes recopilar registros desde tu clúster. Si perdiste acceso a Google Cloud y sus interfaces web de asistencia, puedes llamar al equipo de asistencia siempre que te hayas suscrito a los planes de asistencia Mejorada o Premium. | Ilimitado | - |