Cómo obtener asistencia

El objetivo principal de la asistencia de Google es resolver los incidentes de producción lo más rápido posible. Para ello, comprendemos la configuración, analizamos los registros y las métricas y colaboramos con los socios a fin de resolver los incidentes con rapidez.

La Atención al cliente de Cloud ofrece varios paquetes de asistencia para satisfacer tus necesidades. Todos los paquetes de Atención al cliente de Cloud incluyen asistencia para GKE y Google Distributed Cloud. Si tienes un paquete de asistencia de Atención al cliente de Cloud existente, ya tienes asistencia para GKE y Google Distributed Cloud.

Para obtener más información, consulta el centro de Atención al cliente de Cloud.

Requisitos para la asistencia de Google Distributed Cloud

Para solucionar de manera eficaz los incidentes críticos de la empresa, debes hacer lo siguiente:

• Verifica que tu entorno sea actual y que esté dentro de los períodos de fin de la asistencia publicados. Para obtener más información, consulta la sección Política de asistencia de la versión.
• Habilita Cloud Logging y Cloud Monitoring para los componentes del sistema. Para obtener más información, consulta la siguiente sección Herramientas de asistencia.

Herramientas de asistencia

Para solucionar un incidente de Google Distributed Cloud, la Atención al cliente de Cloud se basa en tres datos:

• La configuración del entorno
• Los registros de tus clústeres
• Las métricas de tus clústeres

La configuración del entorno

Cuando abras un caso de ayuda, proporciona información clave sobre la configuración de tu clúster ejecutando los siguientes comandos:

• En todos tus tipos de clústeres, ejecuta el comando bmctl check cluster --snapshot para capturar información sobre Kubernetes y tus nodos. Adjunta el archivo tar resultante al caso de ayuda.

• Para los clústeres independientes, híbridos y de administración, ejecuta el comando bmctl check cluster para verificar el estado del clúster y los nodos. Adjunta los registros resultantes al caso de ayuda. Los registros deben existir en el directorio bmctl-workspace/[CLUSTER_NAME]/log/check-cluster-[TIMESTAMP].

• Para los clústeres de usuario, primero crea un archivo YAML de verificación de estado con el nombre del clúster y el espacio de nombres y, luego, aplica el archivo en el clúster de administrador correspondiente:

  1. Crea un archivo YAML con las siguientes propiedades de healthcheck. El siguiente es un ejemplo del contenido para un clúster llamado user1 en el espacio de nombres cluster-user1:

     apiVersion: baremetal.cluster.gke.io/v1
     kind: HealthCheck
     metadata:
       generateName: healthcheck-
       namespace: cluster-user1
     spec:
       clusterName: user1
     

  2. Después de crear el archivo YAML, aplica el recurso personalizado en el clúster de administrador que administra el clúster de usuarios con el comando kubectl. El siguiente es un comando de muestra que usa el archivo YAML creado en el paso anterior. En la muestra, la variable ADMIN_KUBECONFIG especifica la ruta al archivo kubeconfig del clúster de administrador:

     kubectl --kubeconfig ADMIN_KUBECONFIG create -f healthcheck-user1.yaml
     

     El comando muestra la siguiente respuesta:

     healthcheck.baremetal.cluster.gke.io/healthcheck-7c4qf created
     

  3. Espera hasta que se complete el trabajo de verificación de estado. Para ello, comprueba si el trabajo de verificación de estado terminó de validar. En el caso de ejemplo anterior, el nombre del trabajo de verificación de estado es healthcheck.baremetal.cluster.gke.io/healthcheck-7c4qf. A continuación, se muestra una prueba de muestra que usa el comando kubectl y espera 30 minutos hasta que se completa el trabajo de verificación de estado:

     kubectl --kubeconfig ADMIN_KUBECONFIG wait healthcheck healthcheck-7c4qf \
         -n cluster-user1 --for=condition=Reconciling=False --timeout=30m
     

     Cuando se completa el trabajo de verificación de estado, el comando kubectl anterior devuelve lo siguiente:

     healthcheck.baremetal.cluster.gke.io/healthcheck-7c4qf condition met
     

     Puedes ver los resultados del trabajo de verificación de estado con el siguiente comando:

     kubectl --kubeconfig ADMIN_KUBECONFIG get healthcheck healthcheck-7c4qf \
         -n cluster-user1
     

     El comando muestra el siguiente resultado:

     NAME                PASS   AGE
     healthcheck-7c4qf   true   17m
     

  4. Recopila todos los registros del Pod del trabajo de verificación de estado en un archivo local con el comando kubectl. El siguiente es un ejemplo que usa el trabajo de verificación de estado de muestra anterior:

     kubectl --kubeconfig ADMIN_KUBECONFIG logs -n cluster-user1 \
         -l baremetal.cluster.gke.io/check-name=healthcheck-7c4qf --tail=-1 > \
         healthcheck-7c4qf.log
     

Registros del clúster

Cuando creas un nuevo clúster de Google Distributed Cloud, los agentes de Cloud Logging se habilitan de forma predeterminada y tienen permiso para acceder solo a los componentes a nivel del sistema. Esto replica los registros a nivel del sistema en el proyecto Google Cloud asociado con el clúster. Los registros a nivel del sistema provienen de Pods de Kubernetes en los siguientes espacios de nombres:

• kube-system
• gke-system
• gke-connect
• istio-system
• config-management-system
• gatekeeper-system
• cnrm-system
• knative-serving

Puedes consultar los registros desde el Explorador de registros.

Nota: Si Cloud Logging está inhabilitado, la asistencia se ofrece solo en función de la mejor calidad y podría requerir un esfuerzo adicional significativo de tu equipo de ingeniería en las instalaciones.

Para obtener más detalles, consulta Configura el registro y la supervisión.

Google Cloud CLI y acceso a clústeres remotos

Si abres un caso de ayuda, es posible que la Atención al cliente de Cloud te solicite acceso remoto de solo lectura a tus clústeres para diagnosticar y resolver problemas de manera más efectiva. Para que el equipo de Atención al cliente de Cloud tenga acceso suficiente para solucionar los problemas de tu clúster de forma remota, asegúrate de haber instalado y actualizado la versión más reciente de la Google Cloud CLI. Google Cloud CLI debe estar en la versión 401.0.0 o una superior para otorgar a la Atención al cliente de Cloud los permisos necesarios. Te recomendamos que actualices Google Cloud CLI de forma periódica para obtener los permisos adicionales y otras mejoras.

Para instalar los componentes más recientes de la gcloud CLI, usa el comando gcloud components update. Si deseas obtener más información para otorgar acceso de solo lectura a tus clústeres a la Atención al cliente de Cloud, consulta Asistencia remota para clústeres de GKE.

Métricas del clúster

Además de los registros, el agente de Cloud Monitoring también captura métricas. Esto replica las métricas a nivel del sistema en el proyecto de Google Cloud asociado con el clúster. Las métricas a nivel del sistema provienen de Pods de Kubernetes que se ejecutan en los mismos espacios de nombres que se enumeran en la sección Registros del clúster.

Nota: Si Cloud Monitoring está inhabilitado, se asistirá al usuario solo en función del "mejor esfuerzo", y se podría requerir un esfuerzo adicional significativo de tu equipo de ingeniería en las instalaciones.

Para obtener más detalles, consulta Configura el registro y la supervisión.

Cómo solucionamos los problemas de tu entorno

A continuación, se muestra un ejemplo de un incidente de asistencia típico:

1. El administrador del clúster abre un caso de asistencia en la consola de Google Cloud con Atención al cliente de Cloud. Luego, seleccionan GKE y Google Distributed Cloud como Categoría y Componente, respectivamente. Ingresa la información requerida y adjunta el resultado de los comandos bmctl relevantes al caso.

2. El caso de asistencia se enruta a un ingeniero de asistencia técnica especializado en Google Distributed Cloud.

3. El ingeniero de asistencia examina el contenido de la instantánea para obtener el contexto del entorno.

4. El ingeniero de asistencia examina los registros y las métricas del proyecto Google Cloud. Ingresa el ID del caso de asistencia como justificación empresarial, que se registra de forma interna.

5. El ingeniero de asistencia responde al caso con una evaluación y una recomendación. El ingeniero de asistencia y el usuario continúan con la solución de problemas hasta llegar a una solución.

¿Qué hace la Atención al cliente de Google?

Por lo general, el Atención al cliente de Cloud admite todos los componentes de software enviados como parte de Google Distributed Cloud y Cloud Service Mesh, Policy Controller, Sincronizador de configuración y Config Controller. En la siguiente tabla, se proporciona una lista más completa de lo que se admite y lo que no:

Google Cloud compatible	No compatible
Kubernetes y el entorno de ejecución del contenedor	Elección por parte del cliente del balanceador de cargas (balanceo de cargas manual)
Connect y agente Connect	Código del cliente (consulta Asistencia para programadores)
Google Cloud operaciones, Monitoring, Logging y agentes	Elección por parte del cliente del sistema operativo
Balanceador de cargas en paquetes	Servidor, almacenamiento y red virtuales o físicos
Controlador de Ingress	DNS externo, DHCP y sistemas de identidad
GKE Identity Service
Cloud Service Mesh
Policy Controller
Sincronizador de configuración
Config Controller

Política de asistencia de la versión

El objetivo de esta política de asistencia de la versión es brindarte la flexibilidad para que programes las actualizaciones cuando sean convenientes para tu empresa, a la vez que equilibras la evolución rápida de Kubernetes y Google Distributed Cloud.

El software de Google Distributed Cloud solo sigue el esquema de versiones y el ciclo de lanzamiento de Kubernetes. Las versiones secundarias se lanzan aproximadamente tres veces al año. Los parches para cada versión secundaria compatible se lanzan aproximadamente una vez al mes. Al igual que Kubernetes, Google Distributed Cloud admite las tres versiones secundarias más recientes de forma simultánea.

Google admite cada versión secundaria de Google Distributed Cloud durante el siguiente período:

• 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 de 2025. Esta versión secundaria y todos sus parches se admiten hasta el 2 de septiembre de 2026 o la fecha de lanzamiento de la versión secundaria 1.36, la que sea posterior.

Te recomendamos mantener tu entorno de Google Distributed Cloud con la actualización secundaria más reciente del producto y la versión de parche recomendada.

Esta política de asistencia de la versión incluye lo siguiente:

• Asistencia para la solución de problemas de la Atención al cliente de Cloud
• Vulnerabilidades de seguridad de CVE en Kubernetes y componentes relacionados
• Parches generales a Kubernetes y componentes relacionados

Cuando tu versión llegue al final del ciclo de vida, podrás seguir abriendo casos para recibir asistencia en los siguientes temas:

• Ayuda con problemas técnicos
• Asistencia con problemas de facturación
• Orientación sobre el uso del producto, incluida ayuda para solucionar problemas y realizar pruebas

El soporte extendido se puede aprobar de forma condicional como un evento único, con fijación de versiones y requisitos de cronograma de actualización futuros. Para obtener más información, comunícate con el ingeniero de clientes principal de tu cuenta o con el administrador de cuentas. Como alternativa, puedes presentar un caso de asistencia a través de la consola de Google Cloud . Estas solicitudes se enrutan al grupo de ingeniería de clientes de tu cuenta.

Período de asistencia

En la siguiente tabla, se muestran las versiones secundarias compatibles con Google Distributed Cloud y las fechas de final del ciclo de vida (EOL) más antiguas:

Versión de Google Distributed Cloud	Fecha de lanzamiento	Fecha de final del ciclo de vida^*
1.33	2025-09-02	Fecha de lanzamiento 2026-09-02 o 1.36
1.32	2025-05-06	Fecha de lanzamiento 2026-05-06 o 1.35
1.31	2024-12-18	Fecha de lanzamiento 2025-12-18 o 1.34

* El EOL será la última de estas dos fechas.

Para obtener más información sobre la compatibilidad de versiones de Google Distributed Cloud y los productos relacionados deGoogle Cloud , consulta Compatibilidad con versiones y actualizaciones.

Esquema del control de versiones

Google Distributed Cloud usa el control de versiones semántico de Kubernetes para hacer referencia a las versiones de Kubernetes compatibles, pero agrega una versión de parche de GKE. Esto da como resultado un número de versión con el siguiente formato: x.y.z-gke.N.

Versión principal de Kubernetes (x)

Por lo general, las versiones principales se incrementan si se ingresan cambios incompatibles con versiones anteriores en la API pública. Una versión principal aumenta la versión de Kubernetes de x.y a x+1.y.

Versión secundaria de Kubernetes (Y)

Kubernetes lanza una versión secundaria nueva 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 versión secundaria nueva. Una versión secundaria incrementa la versión de Kubernetes de 1.y a 1.y+1. Por ejemplo, Kubernetes 1. 29 es la versión secundaria que sigue a Kubernetes 1.28.

Versión de parche de Google Distributed Cloud (z-gke.N)

Una actualización de parche, como 1.28.300-gke.131, incrementa la versión de parche (z) en 100 y, además, 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 correlaciona con una versión de parche de Kubernetes.

Modelo de responsabilidad compartida

La ejecución de una aplicación de producción fundamental para la empresa en Google Distributed Cloud requiere que varias partes tengan diferentes responsabilidades. Si bien no es una lista exhaustiva, en las siguientes secciones se enumeran los roles y las responsabilidades de las diferentes partes.

Responsabilidades de Google

• Mantenimiento y distribución del paquete de software de Google Distributed Cloud

• Notificar a los usuarios sobre las actualizaciones disponibles para Google Distributed Cloud y producir secuencias de comandos de actualización para la versión anterior

  Google Distributed Cloud solo admite actualizaciones secuenciales del clúster (por ejemplo, 1.31 → 1.32 → 1.33, pero no 1.31 → 1.33). Cuando actualizas grupos de nodos, en algunos casos, puedes omitir una versión secundaria. Para obtener más información sobre la lógica de actualización, consulta Reglas de versión.

• Operar los servicios de Connect y Cloud Operations.

• Solucionar problemas, brindar soluciones alternativas y corregir la causa raíz de cualquier problema relacionado con los componentes que proporciona Google.

Responsabilidades del usuario

• Administrar de forma general el sistema para clústeres locales
• Mantener cualquier carga de trabajo de la aplicación que se implementa en el clúster
• Ejecutar y mantener la infraestructura del centro de datos y aplicar parches en ella, incluidas las herramientas de redes, los servidores, el sistema operativo, el almacenamiento y la conectividad aGoogle Cloud
• Ejecutar, mantener y aplicar parches en los balanceadores de cargas de red si se elige la opción de balanceador de cargas manual
• Actualizar las versiones de Google Distributed Cloud con regularidad
• Supervisar el clúster y las aplicaciones, y responder a cualquier incidente
• Garantizar que los agentes de Cloud Operations se implementen en los clústeres
• Proporcionar detalles del entorno a Google para solucionar problemas

Equipo de asistencia para desarrolladores

Google no proporciona asistencia específica para las cargas de trabajo de tu aplicación. Sin embargo, proporcionamos asistencia para desarrolladores de excelente calidad para garantizar que tus desarrolladores puedan ejecutar aplicaciones en Google Distributed Cloud. Creemos que la interacción temprana durante el desarrollo puede evitar incidentes críticos más adelante en la implementación.

Esta asistencia para desarrolladores de mejor esfuerzo está disponible para los clientes que cuentan con cualquier paquete de asistencia pago y se trata como prioridad P3 si un problema bloquea un lanzamiento o como prioridad P4 para las consultas generales. En esta clasificación, la prioridad 0 es la prioridad más alta.