Obtener asistencia

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.

Atención al Cliente de Cloud ofrece varios paquetes de asistencia para adaptarse a tus necesidades. Todos los paquetes de Cloud Customer Care incluyen asistencia para GKE y Google Distributed Cloud. Si ya tienes un paquete de asistencia de Cloud Customer Care, también tienes asistencia para GKE y Google Distributed Cloud.

Para obtener más información, consulta el centro de ayuda de Cloud Customer Care.

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 tu entorno esté actualizado y dentro de 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.

Herramientas de asistencia

Para solucionar un incidente de Google Distributed Cloud, el equipo de Asistencia de Google Cloud se basa en tres tipos de información:

• La configuración de tu entorno
• Registros de tus clústeres
• Métricas de tus clústeres

Configuración del entorno

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

• Para todos los tipos de clústeres, obtén información sobre Kubernetes y tus nodos ejecutando el comando bmctl check cluster --snapshot. Adjunta el archivo tar resultante al caso de asistencia.

• En los clústeres de administrador, híbridos y autónomos, comprueba el estado de los clústeres y los nodos ejecutando el comando bmctl check cluster. Adjunta los registros resultantes al caso de asistencia. Los registros deben estar en el directorio bmctl-workspace/[CLUSTER_NAME]/log/check-cluster-[TIMESTAMP].

• En el caso de los clústeres de usuarios, primero crea un archivo YAML de comprobación de estado con el nombre y el espacio de nombres del clúster y, a continuación, aplica el archivo en el clúster de administrador correspondiente:

  1. Crea un archivo YAML con las siguientes propiedades de healthcheck. A continuación, se muestra un ejemplo de contenido de 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 gestiona el clúster de usuario mediante el comando kubectl. A continuación, se muestra un comando de ejemplo que usa el archivo YAML creado en el paso anterior. En el ejemplo, 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 devuelve la siguiente respuesta:

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

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

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

     Cuando se complete la tarea de comprobación de estado, el comando kubectl anterior devolverá lo siguiente:

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

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

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

     El comando devuelve el siguiente resultado:

     NAME                PASS   AGE
     healthcheck-7c4qf   true   17m
     

  4. Recopila todos los registros del pod de la tarea de comprobación de estado en un archivo local mediante el comando kubectl. A continuación, se muestra un ejemplo que usa el trabajo de comprobación del 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 clúster de Google Distributed Cloud, 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 de sistema en el Google Cloud proyecto asociado al clúster. Los registros a nivel de sistema proceden de pods de Kubernetes de los siguientes espacios de nombres:

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

Puedes consultar registros desde el Explorador de registros.

Nota: Si Cloud Logging está inhabilitado, solo se ofrecerá asistencia en la medida de lo posible, y es posible que tu equipo de ingeniería in situ tenga que hacer un esfuerzo adicional considerable.

Para obtener más información, consulta Configurar el registro y la 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 Asistencia de Google Cloud pueda acceder a tu clúster de forma remota y solucionar el problema, 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 frecuencia para obtener los permisos añadidos y otras mejoras.

Para instalar los componentes más recientes de gcloud CLI, usa el comando gcloud components update. Para obtener más información sobre cómo dar acceso remoto de solo lectura a tus clústeres a Cloud Customer Care, 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 recoge 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 la sección Registros del clúster.

Nota: Si Cloud Monitoring está inhabilitado, solo se ofrecerá asistencia en la medida de lo posible, y es posible que tu equipo de ingeniería in situ tenga que hacer un esfuerzo considerable.

Para obtener más información, consulta Configurar el registro y la monitorización.

Cómo solucionamos los problemas de tu entorno

Aquí tienes un ejemplo de un incidente de asistencia habitual:

1. El administrador del clúster abre un caso de asistencia en la consola con Atención al cliente de Cloud. Google Cloud A continuación, seleccionan GKE y Google Distributed Cloud como Categoría y Componente, respectivamente. Introducen la información necesaria y adjuntan los resultados de los comandos bmctl pertinentes al caso.

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

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

4. El ingeniero del equipo de Asistencia examina los registros y las métricas del Google Cloud proyecto. Introducen el ID de asistencia como justificación empresarial, que se registra internamente.

5. 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.

¿Qué admite Google?

Por lo general, el equipo de Asistencia de Google Cloud admite todos los componentes de software que se envían como parte de Google Distributed Cloud, Cloud Service Mesh, Policy Controller, Config Sync y Config Controller. En la siguiente tabla se incluye una lista más completa de lo que se admite y lo que no:

Google Cloud	No compatible
Kubernetes y el entorno de ejecución del contenedor	El cliente elige el balanceador de carga (balanceo de carga manual)
Connect y el agente de Connect	Código de cliente (consulta Asistencia para desarrolladores)
Google Cloud Operaciones, monitorización, registro y agentes	Elección del sistema operativo por parte del cliente
Balanceador de carga agrupado	Servidor, almacenamiento y red físicos o virtuales
Controlador de entrada	Sistemas externos de DNS, DHCP e identidad
Servicio de identidad de GKE
Cloud Service Mesh
Policy Controller
Config Sync
Config Controller

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.

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 versión 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 consola de Google Cloud . 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.y a x+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.y a 1.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 crucial para la empresa en Google Distributed Cloud, es necesario que varias partes asuman diferentes responsabilidades. Aunque no se trata de una lista exhaustiva, en las siguientes secciones se enumeran los roles y las responsabilidades de las distintas partes.

Responsabilidades de Google

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

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

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

• Operar los servicios Connect y Cloud Operations.

• Solucionar problemas, ofrecer soluciones alternativas y corregir la causa raíz de cualquier problema relacionado con los componentes proporcionados por Google.

Responsabilidades de los usuarios

• Administración general del sistema para clústeres locales.
• Mantener cualquier carga de trabajo de aplicación desplegada en el clúster.
• Ejecutar, mantener y parchear la infraestructura del centro de datos, incluidas las redes, los servidores, el sistema operativo, el almacenamiento y la conectividad aGoogle Cloud.
• Ejecutar, mantener y parchear balanceadores de carga de red si se elige la opción de balanceador de carga manual.
• Actualizar las versiones de Google Distributed Cloud con regularidad.
• Monitorización del clúster y las aplicaciones, y respuesta a los incidentes.
• Asegurarse de que los agentes de Cloud Operations se despliegan en los clústeres.
• Proporcionar a Google detalles sobre el entorno para solucionar problemas.

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 Google Distributed Cloud. Creemos que, si se participa antes en el 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.