Impacto de la desconexión temporal de Google Cloud

El software de Google Distributed Cloud solo se basa en Kubernetes y puedes implementarlo de forma local en servidores de VMware o de equipos físicos. Aunque Distributed Cloud se ejecuta de forma local, lo diseñamos para que tenga 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é sucede si, por algún motivo, pierdes 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 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 Distributed Cloud que solo usa software desconectada deGoogle Cloud como un modo de trabajo nominal. Recuerda que diseñamos Distributed Cloud 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 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 supone que estás familiarizado con GKE. Si no es así, te recomendamos que primero leas la descripción general de GKE.

Validación y medición de licencias

Si habilitaste la API de Anthos (anthos.googleapis.com) en tu proyecto de Google Cloud , el controlador de medición que se ejecuta en el clúster genera y actualiza la autorización de licencia de forma periódica. La tolerancia a la desconexión es de 12 horas. Además, el sistema requiere la conexión para administrar la medición y la facturació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 de desconexión temporal Tolerancia máxima a la desconexión Solución alternativa para la pérdida de conectividad
Validación de licencias El controlador de medición genera y actualiza el recurso personalizado de autorización de licencia de forma periódica, siempre que anthos.googleapis.com esté habilitado 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. 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 informa la capacidad de CPU virtual del clúster a la API de Google Cloud 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 recupera los registros una vez que el clúster se vuelve a conectar a Google Cloud. Ilimitada. Sin embargo, se requiere la información de medición 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 deGoogle Cloud se actualiza para mostrar los resultados de las operaciones realizadas durante el período de desconexión.

Acción Comportamiento conectado Comportamiento de desconexión temporal Tolerancia máxima a la desconexión Solución alternativa para la pérdida de conectividad
Creación del clúster Usas 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 del clúster Usas las herramientas de la CLI de bmctl o gkectl para actualizar clústeres. Esta operación requiere una conexión a Google Cloud. No puedes actualizar 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, 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.
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, una desconexión temporal de Google Cloud no afecta la administración de las aplicaciones que se ejecutan en un clúster local. 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 enGoogle Cloud, dejarán de estar 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 de 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 Implementas aplicaciones de forma local con kubectl, a través de herramientas de CI/CD o con 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 usas la puerta de enlace de Connect, cámbiala y usa kubectl de forma local.
Eliminación de aplicaciones Quitas aplicaciones de forma local con kubectl, a través de herramientas de CI/CD o con 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 usas la puerta de enlace de Connect, cámbiala y usa kubectl de forma local.
Escalamiento horizontal de aplicaciones Puedes escalar horizontalmente las aplicaciones de forma local con kubectl, a través de herramientas de CI/CD o con 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 usas 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. Distributed Cloud ayuda con la auditabilidad, ya que ofrece registro de aplicaciones, registro de Kubernetes y registro de auditoría. Muchos clientes eligen usar 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, Distributed Cloud admite la integración directa a servicios como Prometheus. 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 de 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 El sistema escribe registros en Cloud Logging. El sistema almacena los registros 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, el sistema descarta las entradas más antiguas. Usa una solución de registro local.
Registro del sistema o Kubernetes mediante Cloud Logging El sistema escribe registros en Cloud Logging. El sistema almacena los registros 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, el sistema descarta 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 búfer en el disco local. 10 GiB de búfer local por nodo del plano de control. Cuando se llena el búfer, el sistema descarta 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 El sistema escribe métricas en Cloud Monitoring. El sistema almacena las métricas 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, el sistema descarta 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 y a través de la API de Cloud Monitoring. El sistema no actualiza las métricas 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, el sistema descarta 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. El sistema puede enviar alertas a través de diferentes canales. El sistema no activa alertas mientras no haya conexión. El sistema solo activa alertas 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. Almacenas configuraciones y políticas en un repositorio de Git, y el sistema las sincroniza automáticamente 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 con Google Cloud CLI o las herramientas de 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 gcloud CLI o la consola, el clúster no los aplica durante la desconexión. Puedes reemplazarlos temporalmente de forma local con kubectl. Cuando se restablece la conexión, se reemplazan los cambios locales.

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 de 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 con una API de Google Cloud . La sincronización de la configuración no se ve afectada. Si cambias los parámetros de sincronización con gcloud CLI o en la consola, el clúster no los aplica durante la desconexión. Puedes reemplazarlos temporalmente de forma local con kubectl. Cuando se restablece la conexión, se reemplazan los cambios locales. 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 con la API local de Kubernetes. El sistema no propaga los cambios en la configuración del sistema de Policy Controller a través de la API de Google Cloud al clúster, pero puedes reemplazarlos temporalmente de forma local. Cuando se restablece la conexión, se reemplazan los cambios locales. Ilimitado Nunca uses la API de Fleet para el Controlador de políticas 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 CLI, o la consola) 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 con 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 el Controlador de políticas, y solo configúrala con la API de Kubernetes.
Ver el estado del sistema o de la sincronización en la consola Puedes ver el estado de los agentes en el clúster y el estado de la sincronización con una Google Cloud API o en la consola. La información de estado en la API 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 a través de la API local de Kubernetes. Cero Usa la CLI de nomos o la API local de Kubernetes.

Seguridad

En esta sección, se describe cómo las funciones de seguridad, incluidas la identidad, la autenticación, la autorización y la administración de secretos, se ven afectadas por una desconexión temporal de Google Cloud.

Identidad, autenticación y autorización

Distributed Cloud puede conectarse directamente a Cloud Identity para roles de usuario y aplicación, a fin de administrar cargas de trabajo con Connect o realizar la autenticación de extremos con OIDC. Una desconexión de Google Cloud interrumpe la conexión a Cloud Identity, lo que hace que esas funciones no estén disponibles. Para las cargas de trabajo que requieren resiliencia adicional durante una desconexión temporal, puedes usar GKE Identity Service para integrarlo con un proveedor de OIDC o LDAP (incluido ADFS) para configurar la autenticación del usuario final.

Función Comportamiento conectado Comportamiento de 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, a través de la puerta de enlace de Connect Puedes acceder a los recursos de Distributed Cloud con Cloud Identity como 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 gcloud CLI para acceder por primera vez. En el caso de los proveedores de OIDC, puedes usar la consola 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. 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 atribuir a usuarios, grupos o cuentas de servicio. El sistema recupera las identidades de usuario y los grupos del proveedor de identidad. El sistema RBAC es local para el clúster de Kubernetes, y la desconexión de Google Cloud no lo afecta. 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 Distributed Cloud en caso de desconexión deGoogle Cloud depende del servicio que uses para esas funciones.

Función Comportamiento conectado Comportamiento de 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 con Hashicorp Vault y servicios de 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 local y la desconexión también lo afecta, 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

En esta sección, se abordan los servicios de red y redes para clústeres locales, incluido el impacto de una desconexión temporal deGoogle Cloud. Proporciona información sobre el balanceo de cargas, Cloud Service Mesh y otros servicios de red.

Balanceo de cargas

Para exponer los servicios de Kubernetes alojados en un clúster local a los usuarios, tienes las siguientes opciones:

Estas opciones de balanceo de cargas siguen operativas incluso si se desconectan deGoogle Cloud.

Función Comportamiento conectado Comportamiento de 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 deGoogle 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. Distributed Cloud no admite todas las funciones de Cloud Service Mesh: consulta la lista de funciones compatibles para obtener más información.

Función Comportamiento conectado Comportamiento de 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, 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.
Registro 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 local. Depende de cómo configuraste el registro para tu clúster local. - -
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 de 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 tus clústeres locales para que usen un proxy para las conexiones de salida. Si el proxy se ejecuta de forma local, el clúster 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 de 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 y puedes usarlo para descubrir, adquirir y, también, 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 deGoogle Cloud o tu socio operativo para un caso relacionado con tus clústeres de GKE en GDC.

Función Comportamiento conectado Comportamiento de 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 -