Obtenga asistencia

El objetivo principal de la asistencia de Google es resolver los incidentes de producción lo más rápido posible. Comprender la configuración, analizar los registros y las métricas, y colaborar con los socios nos ayuda a resolver incidentes con rapidez.

Google Cloud ofrece varios paquetes de asistencia para satisfacer tus necesidades. Todos los paquetes de asistencia de Google Cloud incluyen asistencia para clústeres de Anthos y Anthos en equipos físicos. Si tienes un paquete de asistencia de Google Cloud existente, ya tienes asistencia para Anthos y los clústeres de Anthos alojados en equipos físicos.

Para obtener más información, consulta la documentación de Asistencia de Google Cloud.

Requisitos para obtener asistencia con los clústeres de Anthos en equipos físicos

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

Herramientas de asistencia

Para solucionar problemas de los clústeres de Anthos en equipos físicos, la asistencia de Google Cloud se basa en tres datos:

La configuración del entorno

Cuando abres un caso de ayuda, la ejecución de los siguientes comandos proporciona información clave sobre la configuración de tu clúster.

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

  • Para los clústeres independientes, híbridos y de administración, ejecuta el comando bmctl check cluster a fin de verificar el estado del clúster y los nodos. Adjunta los registros resultantes al caso de ayuda. 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. Este 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 finalice el trabajo de verificación de estado para comprobar si se ha terminado de validar el trabajo de verificación de estado. En el caso de ejemplo anterior, el nombre del trabajo de verificación de estado es healthcheck.baremetal.cluster.gke.io/healthcheck-7c4qf. Esta es una prueba de muestra con el comando kubectl que 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 complete, este comando mostrará 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 Pods del trabajo de verificación de estado en un archivo local con el comando kubectl. Este 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 nuevos Anthos alojados en equipos físicos, 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 de 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

Los registros se pueden consultar desde la consola de Cloud Logging.

Para obtener más detalles, consulta Logging y Monitoring.

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 asistencia tenga acceso suficiente a fin de 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. La 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 sobre cómo otorgar acceso de solo lectura a la atención al cliente de Cloud a tus clústeres, consulta Asistencia de Google Cloud para tus clústeres registrados.

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 de sistema provienen de Pods de Kubernetes que se ejecutan en los mismos espacios de nombres que se enumeran en Registros.

Para obtener más detalles, consulta Logging y Monitoring.

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 o Google Cloud Support Center y selecciona Anthos y los clústeres de Anthos en equipos físicos 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 ayuda se enruta a un ingeniero de asistencia técnica especializado en clústeres de Anthos en equipos físicos.
  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 de Google Cloud. Para ello, ingresa el ID del caso de ayuda 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 equipo de asistencia al cliente de Cloud admite todos los componentes de software enviados como parte de los clústeres de Anthos en equipos físicos, así como Anthos Service Mesh y Anthos Config Management. Consulta la siguiente tabla para obtener una lista más completa de lo que se admite y lo que no:

Con la asistencia de Google Cloud 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)
Cloud Operations, 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
Anthos Identity Service
Anthos Service Mesh
Anthos Config Management

Política de asistencia de la versión

La asistencia para los clústeres de Anthos en equipos físicos sigue la política de asistencia de la versión de Anthos. Google admite la versión actual y las dos versiones secundarias (n-2) anteriores de los clústeres de Anthos en equipos físicos.

En la siguiente tabla, se muestran las versiones compatibles y no compatibles de este producto.

Versión secundaria Fecha de lanzamiento Fecha de finalización más temprana Parches disponibles Versión de Kubernetes
1.14 (más reciente) 8 de diciembre de 2022 8 de diciembre de 2023 1,14.1 Versión 1.25.5-gke.1001
1.14.0 v1.25.3‐gke.1400
1,13 29 de septiembre de 2022 29 de junio de 2023 1,13.4 v1.24.9‐gke.2500
1.13.3 v1.24.7‐gke.1700
1.13.2 v1.24.7-gke.300
1.13.1 v1.24.5-gke.400
1.13.0 v1.24.2-gke.1900
1.12 29 de junio de 2022 29 de marzo de 2023 1.12.7 Versión 1.23.15-gke.2400
1,12.6 v1.23.13‐gke.1700
1.12.5 v1.23.13‐gke.1700
1.12.4 v1.23.11-gke.500
1.12.3 v1.23.10-gke.1000
1.12.2 v1.23.5-gke.1505
1.12.1 v1.23.5-gke.1505
1.12.0 v1.23.5-gke.1504
1.11 (no admitido) 21 de Marzo de 2022 21 de diciembre de 2022 1.11.8 v1.22.15-gke.3300
1.11.7 v1.22.14-gke.500
1.11.6 v1.22.8-gke.204
1.11.5 v1.22.8-gke.204
1.11.4 v1.22.8-gke.204
1.11.3 v1.22.8-gke.203
1.11.2 v1.22.8-gke.200
1.11.1 v1.22.8-gke.200
1.11.0 v1.22.8-gke.200
1.10 (no compatible) 10 de diciembre de 2021 10 de septiembre de 2022 1.10.8 v1.21.13-gke.202
1.10.7 v1.21.13-gke.202
1.10.6 v1.21.13-gke.201
1.10.5 v1.21.6-gke.1503
1.10.4 v1.21.6-gke.1503
1.10.3 v1.21.5-gke.1300
1.10.2 v1.21.5-gke.1300
1.10.1 v1.21.5-gke.1200
1.10.0 v1.21.5-gke.1200
1.9 (no compatible) 23 de septiembre de 2021 23 de junio de 2022 1.9.8 v1.21.13-gke.200
1.9.7 v1.21.6-gke.1503
1.9.6 v1.21.5-gke.1300
1.9.5 v1.21.5-gke.1300
1.9.4 v1.21.5-gke.1200
1.9.3 v1.21.5-gke.1200
1.9.2 v1.21.4-gke.201
1.9.1 v1.21.4-gke.201
1.9.0 v1.21.4-gke.200
1.8 (no compatible) 21 de junio de 2021 21 de Marzo de 2022 1.8.9 v1.20.9-gke.102
1.8.8 v1.20.9-gke.102
1.8.7 v1.20.9-gke.102
1.8.6 v1.20.9-gke.102
1.8.5 v1.20.9-gke.102
1.8.4 v1.20.9-gke.101
1.8.3 v1.20.9-gke.101
1.8.2 v1.20.8-gke.1500
1.8.1 v1.20.5-gke.1301
1.8.0 v1.20.5-gke.1301
1.7 (no compatible) 25 de marzo de 2021 25 de diciembre de 2021 1.7.7 v1.19.14-gke.2201
1.7.6 v1.19.14-gke.2201
1.7.5 v1.19.14-gke.2201
1.7.4 v1.19.14-gke.400
1.7.3 v1.19.13-gke.100
1.7.2 v1.19.10-gke.1602
1.7.1 v1.19.7-gke.1200
1.7.0 v1.19.7-gke.1200
1.6 (no compatible) 30 de noviembre de 2020 30 de agosto de 2021 1.6.4 v1.18.20-gke.3000
1.6.3 v1.18.18-gke.100
1.6.2 v1.18.6-gke.6600
1.6.1 v1.18.6-gke.6600
1.6.0 v1.18.6-gke.6600

Funciones admitidas

En este documento, se enumera la disponibilidad de las características y capacidades de los clústeres de Anthos en equipos físicos para las versiones compatibles. La tabla no es una lista exhaustiva, pero destaca algunos de los beneficios de actualizar los clústeres a la versión compatible más reciente.

Las características que se enumeran como Vista previa están cubiertas por las Condiciones de las ofertas de la fase previa a la DG de las Condiciones del Servicio de Google Cloud. Los productos y las características de la fase previa a la DG pueden tener compatibilidad limitada, y los cambios en productos y características de la fase previa a la DG podrían no ser compatibles con otras versiones de la fase previa a la DG. Para obtener más información, consulta las descripciones de la etapa de lanzamiento. Las ofertas de vista previa están diseñadas solo para usarlas en entornos de pruebas.

Las funciones que se enumeran como disponibilidad general (GA) son totalmente compatibles y abiertas para todos los clientes, y están listas para su uso en producción.

Atributo/función 1.11 1.12 1.13 1.14 (más reciente)
Políticas de alertas Vista previa Vista previa Vista previa Vista previa
Entorno de ejecución de VM de Anthos Vista previa DG DG DG
Balanceo de cargas en paquetes con BGP DG DG DG DG
Registros de auditoría de Cloud DG DG DG DG
Compatibilidad con la CLI de copias de seguridad y restablecimiento de clústeres DG DG DG DG
Rotación de autoridades certificadas (CA) de clúster DG DG DG DG
Compatibilidad con la CLI de restablecimiento de nodos de clústeres DG DG DG DG
entorno de ejecución del contenedor containerd DG DG DG DG
IP plana dinámica con protocolo de puerta de enlace fronteriza (BGP) Vista previa Vista previa DG DG
Puerta de enlace NAT de salida DG DG DG DG
Modo IPv4 plano (estático) DG DG DG DG
Compatibilidad con IPv6 plana (modo BGP) Vista previa Vista previa DG DG
Compatibilidad con balanceador de cargas basado en BGP para IPv6 No disponible Vista previa DG DG
Pila doble IPv4/IPv6 DG DG DG DG
Compatibilidad con KSA DG DG DG DG
Recopilador administrado de Google Cloud Managed Service para Prometheus No disponible Vista previa DG DG
Conectividad de varios clústeres Vista previa Vista previa Vista previa Vista previa
Varias NIC para Pods DG DG DG DG
Network Connectivity Gateway No disponible Vista previa Vista previa Vista previa
Detector de problemas de nodos DG DG DG DG
Compatibilidad con la duplicación de registros Vista previa Vista previa DG DG
Herramientas de redes de SR-IOV DG DG DG DG
Resumen de las métricas de la API Vista previa DG DG DG
Workload Identity DG DG DG DG

Modelo de responsabilidad compartida

Ejecutar una aplicación de producción crítica para empresas en clústeres de Anthos en equipos físicos requiere que varias partes asuman diferentes responsabilidades. Si bien no es una lista exhaustiva, en las siguientes secciones se enumeran los roles y las responsabilidades.

Responsabilidades de Google

  • Mantenimiento y distribución del paquete de software de clústeres de Anthos en equipos físicos.
  • Notificar a los usuarios sobre las actualizaciones disponibles para clústeres de Anthos en equipos físicos y producir secuencias de comandos de actualización para la versión anterior. Anthos en equipos físicos solo admite actualizaciones secuenciales (ejemplo: 1.2 → 1.3 → 1.4 y no 1.2 → 1.4).
  • 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, mantener y aplicar parches en la infraestructura del centro de datos, que incluye redes, servidores, sistemas operativos, almacenamiento y conectividad a Google 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 los clústeres de Anthos en versiones de equipos físicos 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

Asistencia para desarrolladores

Google no admite las cargas de trabajo de tu aplicación que se ejecutan en clústeres de Anthos en equipos físicos. Sin embargo, proporcionamos asistencia para desarrolladores de excelente calidad para garantizar que tus desarrolladores puedan ejecutar fácilmente aplicaciones en clústeres de Anthos en equipos físicos. 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 está disponible para los clientes que cuentan con un paquete de asistencia pago, y se trata como prioridad P3 si un problema bloquea un lanzamiento o como prioridad P4 para las consultas generales.