Impacto de la desconexión temporal de Google Cloud

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 de forma manual.
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 el Policy Controller, y solo configúrala de forma manual.
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 el Policy Controller, y solo configúrala de forma manual.
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 -