El objetivo principal de la asistencia de Google es resolver los incidentes de producción lo antes posible. Para ello, analizamos tu configuración, los registros y las métricas, y colaboramos con partners para resolver los incidentes rápidamente.
Los servicios de Atención al Cliente de Cloud ofrecen diversos paquetes de asistencia para adaptarse a tus necesidades. Todos los paquetes de asistencia de Cloud Customer Care incluyen asistencia para la edición Enterprise de Google Kubernetes Engine (GKE) y Google Distributed Cloud. Si ya tienes un paquete de asistencia de Cloud Customer Care, también tienes asistencia para la edición Enterprise de Google Kubernetes Engine (GKE) y Google Distributed Cloud.
Para obtener más información, consulta el centro de ayuda de Atención al Cliente de Cloud.
Requisitos para la asistencia de Google Distributed Cloud
Para solucionar de forma eficaz los incidentes críticos para la empresa, debes hacer lo siguiente:
- Comprueba que el entorno esté actualizado con los plazos de finalización del soporte publicados. Para obtener más información, consulta la sección Política de asistencia para versiones.
- Habilita Cloud Logging y Cloud Monitoring para los componentes del sistema. Para obtener más información, consulta la sección Herramientas de asistencia.
- Cuando abras un caso de asistencia, proporciona una instantánea de la configuración mediante el comando
gkectl diagnose snapshot.
Herramientas de asistencia
Para solucionar de forma eficaz los incidentes críticos para la empresa, el equipo de Asistencia de Google Cloud se basa en tres datos:
- Configuración de tu entorno
- Registros de tus clústeres de administrador y de usuario
- Métricas de tus clústeres de administrador y de usuario
Configuración
Cuando abres un caso de asistencia, se te pide que ejecutes el comando gkectl diagnose snapshot
--seed-config y que adjuntes el archivo tar resultante al caso de asistencia.
El comando gkectl diagnose snapshot --seed-config recoge información sobre Kubernetes y tus nodos.
La herramienta es altamente configurable e incluye varios escenarios predefinidos. También puedes enviar un archivo YAML con un conjunto de información personalizada para recoger. Para obtener más información, consulta Diagnóstico de clústeres.
Revise detenidamente la información que recoge la herramienta.
No adjuntes información altamente confidencial o sensible a tu caso de asistencia.
Puedes añadir un campo excludeWords al archivo de configuración para omitir información sensible o confidencial.
Registros
Cuando creas un clúster, los agentes de Cloud Logging se habilitan de forma predeterminada y solo se aplican a los componentes a nivel de sistema. De esta forma, se replican los registros a nivel del sistema en el proyecto Google Cloud asociado al clúster. Los registros a nivel de sistema proceden de pods de Kubernetes que se ejecutan en uno de los siguientes espacios de nombres:
kube-systemgke-systemgke-connectistio-systemconfig-management-systemknative-serving
Las consultas de registros se pueden realizar desde la consola de Cloud Logging.
Para obtener más información, consulta Registros y monitorización.
Métricas
Además de los registros, el agente de Cloud Monitoring también captura métricas. De esta forma, se replican las métricas a nivel de sistema en el Google Cloud proyecto asociado al clúster. Las métricas a nivel de sistema proceden de los pods de Kubernetes que se ejecutan en los mismos espacios de nombres que se indican en Registros.
Para obtener más información, consulta Registros y monitorización.
Google Cloud CLI y acceso a clústeres remotos
Si abres un caso de asistencia, es posible que el equipo de Atención al Cliente de Cloud te pida acceso remoto de solo lectura a tus clústeres para ayudarte a diagnosticar y resolver problemas de forma más eficaz. Para que el equipo de Atención al Cliente de Cloud tenga acceso suficiente para solucionar el problema de tu clúster de forma remota, haz lo siguiente:
Asegúrate de haber instalado y actualizado a la versión más reciente de la CLI de Google Cloud. La CLI de Google Cloud debe tener la versión 401.0.0 o una posterior para conceder a Asistencia de Google Cloud los permisos necesarios. Te recomendamos que actualices Google Cloud CLI con regularidad para obtener los permisos añadidos y otras mejoras. Para instalar los componentes más recientes de la CLI de gcloud, usa el comando
gcloud components update.Asegúrate de que el clúster de destino esté registrado y de que tengas el ID de proyecto, el nombre del miembro y el archivo kubeconfig.
Para obtener el archivo kubeconfig del clúster de usuarios, consulta Cómo volver a crear el archivo kubeconfig del clúster de usuarios.
El nombre del grupo de miembros es el mismo que el del clúster. Para obtener el nombre del clúster de administrador o de usuario, puedes usar lo siguiente:
gkectl list admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG gkectl list clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIGPara conceder acceso al clúster, ejecuta un comando de la CLI de gcloud que genera y muestra un conjunto de políticas de control de acceso basado en roles (RBAC) de Kubernetes y las aplica al clúster de destino. Consulta Revisar las políticas de control de acceso basado en roles con antelación.
Para obtener más información sobre cómo dar acceso remoto de solo lectura a Cloud Customer Care a tus clústeres, consulta el artículo Asistencia de Google Cloud para tus clústeres registrados.
Cómo solucionamos los problemas de tu entorno
Aquí tienes un ejemplo de un incidente de asistencia habitual:
Alguien (por ejemplo, el administrador del clúster) abre un caso de asistencia en la consola o con Atención al cliente de Cloud. Google Cloud
En la consola, ve a la página Resumen de asistencia.
En la sección Información de asistencia, haz clic en Obtener ayuda.
En el campo Selecciona tu producto, introduce lo siguiente:
Google Distributed Cloud Virtual - vSphere (Anthos on VMWare)Haga clic en el elemento de la lista Productos coincidentes y, a continuación, en Seleccionar.
Introduce la información necesaria y adjunta el resultado del comando
gkectl diagnose snapshotal caso.
El caso de asistencia se deriva a un ingeniero de asistencia técnica especializado en Google Distributed Cloud (solo software) para VMware.
El ingeniero del equipo de Asistencia examina el contenido de la instantánea para obtener contexto sobre el entorno.
El ingeniero del equipo de Asistencia examina los registros y las métricas del Google Cloud proyecto e introduce el ID del caso de asistencia como justificación empresarial, que se registra internamente.
El ingeniero del equipo de Asistencia responde al caso con una evaluación y una recomendación. El ingeniero de Asistencia y el usuario siguen solucionando el problema hasta que encuentran una solución.
Partners de asistencia con los que trabajamos
Google mantiene relaciones de asistencia colaborativa con determinados partners para ofrecer una experiencia de asistencia más fluida. Gracias a estas relaciones, Google puede colaborar estrechamente con ese partner en nombre de nuestros clientes compartidos.
Para beneficiarte de la asistencia colaborativa, debes mantener acuerdos de asistencia con Google y con el partner en cuestión.
Google tiene una relación de asistencia colaborativa con los partners especificados en la página Partners de asistencia colaborativa.
Los datos sobre problemas de asistencia se pueden compartir con partners de asistencia colaborativa, tal como se describe en las Directrices de los Servicios de Asistencia Técnica de Google.
¿Qué admite Google?
Por lo general, el equipo de Asistencia de Google Cloud ofrece asistencia para todos los componentes de software que se envían como parte de Google Distributed Cloud (solo software) para VMware. En la siguiente tabla se ofrecen más detalles:
| Cloud Customer Care | Asistencia colaborativa | No admitida |
|---|---|---|
| Kubernetes y el tiempo de ejecución del contenedor |
VMware vSphere (vCenter Server y ESXi) |
Productos de VMware distintos de vSphere |
| Ubuntu canónico para el SO invitado o de nodo |
Balanceadores de carga F5 BIG-IP |
Código de cliente (para obtener más información, consulta la sección Asistencia para desarrolladores) |
| Controlador de vCenter |
Soluciones de hardware e infraestructura hiperconvergente que se indican en la página Partners de asistencia colaborativa |
El cliente elige el SO del host |
| Controlador F5 |
Servidor físico, almacenamiento y red |
|
| Calico y políticas de red relacionadas |
Sistemas externos de DNS, DHCP e identidad |
|
| Controlador de entrada |
Calico Enterprise Edition |
|
| Prometheus y Grafana |
||
| Stackdriver Monitoring, Stackdriver Logging y los agentes de Stackdriver |
||
| Federación de identidades con proveedores compatibles con OIDC |
||
| Hub, Connect y el agente de conexión |
||
| Servicio de Knative/Knative |
||
| LoadBalancer agrupado (Seesaw) |
Funciones compatibles
En este documento se enumeran las funciones de Google Distributed Cloud para las versiones compatibles. La tabla no es una lista exhaustiva, pero destaca algunas de las ventajas de actualizar los clústeres a la versión compatible más reciente.
Las funciones se clasifican según la fase de lanzamiento del producto: Vista Previa o Disponibilidad General. Las funciones que se indican como Vista Previa están cubiertas por los Términos de las Ofertas Previas a la Disponibilidad General de los Google Cloud Términos del Servicio. Los productos en versión de vista previa solo están pensados para usarse en entornos de prueba y pueden tener asistencia limitada. Los cambios que se produzcan en las funciones y los productos previos a la disponibilidad general podrían no ser compatibles con otras versiones también previas a dicha disponibilidad. Todos los clientes pueden usar las funciones de disponibilidad general, que cuentan con asistencia completa. Para obtener más información, consulta el artículo Fases de lanzamiento de los productos.
Para obtener información sobre los componentes de GKE Enterprise admitidos y su compatibilidad, consulta Compatibilidad con versiones y actualizaciones de GKE Enterprise.
1 Los grupos de nodos del SO de Windows Server están obsoletos en la versión 1.32 y no estarán disponibles en la versión 1.33 ni en las posteriores. La asistencia para los grupos de nodos del SO Windows Server finalizará el 25 de mayo del 2026. Te recomendamos que empieces a planificar la migración inmediatamente para que la transición sea fluida antes de que finalice el periodo de asistencia.
Política de compatibilidad de versiones
El objetivo de esta política de asistencia para versiones es ofrecerte la flexibilidad de programar las actualizaciones cuando se adapten a las necesidades de tu empresa, al tiempo que se equilibra la rápida evolución de Kubernetes y Google Distributed Cloud.
El software de Google Distributed Cloud solo sigue el esquema de versiones y el ciclo de lanzamientos de Kubernetes. Las versiones secundarias se publican aproximadamente tres veces al año. Los parches de cada versión secundaria admitida se publican aproximadamente una vez al mes. Al igual que Kubernetes, Google Distributed Cloud admite las tres últimas versiones secundarias simultáneamente.
Google ofrece asistencia para cada versión secundaria de Google Distributed Cloud hasta la fecha posterior de las siguientes:
- 12 meses después del lanzamiento inicial de la versión secundaria.
- El lanzamiento de la tercera versión secundaria posterior.
Por ejemplo, la versión secundaria 1.33 se lanzó el 2 de septiembre del 2025. Esta versión secundaria y todos sus parches se admitirán hasta el 2 de septiembre del 2026 o hasta la fecha de lanzamiento de la versión secundaria 1.36, lo que ocurra más tarde.
Te recomendamos que mantengas tu entorno de Google Distributed Cloud con la última versión secundaria del producto y la versión de parche recomendada.
Esta política de compatibilidad de versiones incluye lo siguiente:
- Asistencia para solucionar problemas de Cloud Customer Care.
- Vulnerabilidades de seguridad de CVE en Kubernetes y componentes relacionados.
- Parches generales de Kubernetes y componentes relacionados.
- Vulnerabilidades de seguridad de CVE en Ubuntu o Container-Optimized OS.
- Parches generales para Ubuntu o Container-Optimized OS.
Cuando tu versión llegue al final de su ciclo de vida, podrás seguir abriendo incidencias para recibir asistencia en los siguientes casos:
- Ayuda con problemas técnicos.
- Asistencia con problemas de facturación.
- Orientación sobre el uso de los productos, incluida ayuda para solucionar problemas y realizar pruebas.
La asistencia ampliada se puede aprobar de forma condicional como un evento único, con fijación de versiones y requisitos de plazos de actualización futuros. Para obtener más información, ponte en contacto con el ingeniero de atención al cliente principal de tu cuenta o con el gestor de cuentas. También puedes enviar una incidencia a través de la Google Cloud consola. Estas solicitudes se derivan al grupo de ingenieros de clientes de tu cuenta.
Periodo de asistencia
En la siguiente tabla se muestran las versiones secundarias compatibles de Google Distributed Cloud y las fechas de finalización del ciclo de vida más tempranas:
| Versión de Google Distributed Cloud | Fecha de lanzamiento | Fecha de finalización del ciclo de vida* |
|---|---|---|
| 1,33 | 2025-09-02 | 2026-09-02 o fecha de lanzamiento de la versión 1.36 |
| 1.32 | 2025-05-06 | 2026-05-06 o fecha de lanzamiento de la versión 1.35 |
| 1.31 | 2024-12-18 | 18-12-2025 o fecha de lanzamiento de la versión 1.34 |
* La fecha de finalización del ciclo de vida será la más tardía de estas dos fechas.
Para obtener más información sobre la compatibilidad de versiones de Google Distributed Cloud y losGoogle Cloud productos relacionados, consulta Compatibilidad de versiones y actualizaciones.
Gestionar versiones de esquemas
Google Distributed Cloud usa el control de versiones semántico de Kubernetes para hacer referencia a las versiones de Kubernetes compatibles, pero añade una versión de parche de GKE. Esto da como resultado un número de versión con el formato x.y.z-gke.N.
- Versión principal de Kubernetes (x)
- Las versiones principales suelen incrementarse si se introducen cambios incompatibles con versiones anteriores en la API pública. Una versión principal
incrementa la versión de Kubernetes de
x.yax+1.y. - Versión secundaria de Kubernetes (y)
- Kubernetes publica una nueva versión secundaria tres veces al año.
Cada ciclo de lanzamiento tiene una duración aproximada de 15 semanas. Las APIs obsoletas se pueden quitar con una nueva versión secundaria. Una versión secundaria incrementa la versión de Kubernetes de
1.ya1.y+1. Por ejemplo, Kubernetes 1. 29 es la versión secundaria que sigue a Kubernetes 1.28. - Lanzamiento de parche de Google Distributed Cloud (z-gke.N)
- Una versión de parche, como 1.28.300-gke.131,
aumenta la versión de parche (z) en 100 e incluye un sufijo
-gke.N, que indica la compilación. Las versiones de parche incluyen actualizaciones de seguridad y correcciones de errores. Una versión de parche de Google Distributed Cloud no se corresponde con una versión de parche de Kubernetes.
Modelo de responsabilidad compartida
Para ejecutar una aplicación de producción esencial para la empresa en Google Distributed Cloud, es necesario que varias partes asuman diferentes responsabilidades. Estas responsabilidades se describen en el artículo Responsabilidad compartida de GKE Enterprise.
Asistencia para desarrolladores
Google no ofrece asistencia específica para tus cargas de trabajo de aplicaciones. Sin embargo, ofrecemos asistencia para desarrolladores de la mejor manera posible para asegurarnos de que tus desarrolladores puedan ejecutar aplicaciones en clústeres creados con Google Distributed Cloud. Creemos que, si se participa en una fase más temprana del desarrollo, se pueden evitar incidentes críticos más adelante en la implementación.
Esta asistencia para desarrolladores de mejor esfuerzo está disponible para los clientes que tengan cualquier paquete de asistencia de pago y se trata como una prioridad P3 si hay un problema que impide el lanzamiento o como una prioridad P4 si se trata de una consulta general. En esta clasificación, el nivel de prioridad 0 es el más alto.