Servicio canónico

Nota: Los servicios canónicos son compatibles de forma automática en Anthos Service Mesh versión 1.6.8 y versiones posteriores.

En esta página, se explica qué es un servicio canónico en Anthos Service Mesh.

¿Qué es un servicio canónico?

Anthos Service Mesh 1.6.8 presenta asistencia para servicios canónicos, un modelo conceptual y de arquitectura para representar las cargas de trabajo de producción como un servicio único que es más fácil de observar y administrar. Estas cargas de trabajo pueden abarcar varios clústeres, plataformas de backend distintas y diferentes esquemas y configuraciones.

Para usuarios de Compute Engine: el servicio canónico es casi similar a los grupos de instancias administrados, aunque un servicio canónico podría ser multirregional.

Para usuarios de Kubernetes: el servicio canónico es casi similar al concepto de “app” de Kubernetes y la CRD de la aplicación.

Para usuarios sin servidores: el servicio canónico es muy similar a los conceptos de servicio de App Engine y servicio de Cloud Run. La única diferencia es que los servicios sin servidores de Google son inherentemente regionales, mientras que los servicios canónicos son una abstracción global o multirregional.

Por ejemplo, en las siguientes situaciones, se describen las formas en que puedes hacer referencia a un servicio canónico:

  • Hay una interrupción de un servicio.
  • Un servicio se ejecuta de manera local y en una nube pública.
  • Se implementa una revisión nueva de un servicio.
  • El servicio Foo está enviando demasiado tráfico y puede exceder nuestra capacidad.

Los servicios canónicos existen dentro de una sola malla, que en Anthos Service Mesh significa que también son únicos dentro de una flota y un proyecto de Google Cloud (todos son uno a uno con Mesh).

Una carga de trabajo determinada solo puede ser parte de un servicio canónico.

Puedes determinar el alcance completo de un servicio canónico del grupo de cargas de trabajo que lo define, incluido lo siguiente:

  • Nombres de host y direcciones IP
  • Redes
  • Políticas de seguridad y de red
  • Enrutamiento y balanceo de cargas
  • Imágenes de VM y de contenedor
  • Infraestructura física o virtual
  • Regiones geográficas
  • Sistema de CI/CD
  • Código fuente
  • Telemetría
  • Alertas y objetivos de nivel de servicio

Puedes ver los paneles que muestran estos detalles operativos de cada servicio en la página de servicios de GKE Enterprise.

Requisitos y limitaciones de servicios canónicos

Los servicios canónicos solo están disponibles en Anthos Service Mesh 1.6.8 y versiones posteriores.

Cada servicio canónico existe dentro de un único espacio de nombres de Kubernetes/Istio y no puede cruzar los límites de espacio de nombres.

Debes asignar a un servicio canónico un nombre único dentro de su espacio de nombres principal. Para obtener más información, consulta Define un servicio canónico.

Los servicios canónicos pueden existir en varios clústeres y regiones. Si bien es posible desglosar los recursos y telemetría por clúster y región, esos no son factores que determinan el alcance o la unicidad de un servicio.

Por lo tanto, la identidad única de un servicio canónico está determinada por los siguientes elementos:

mesh id + namespace + canonical name.

Revisiones

Las revisiones hacen referencia a los cambios incrementales en un servicio que puedes usar para distinguir e identificar diferentes “versiones” o “versiones” de tus servicios.

Diferenciar entre revisiones de un servicio canónico etiquetando una carga de trabajo individual con su “revisión canónica”. Esta etiqueta es una string arbitraria que puedes definir. Si bien la etiqueta se puede configurar de manera automática en algunos casos, tú o el sistema de CI/CD que implementa el servicio deben aplicar la etiqueta. Para obtener orientación sobre cómo configurar esta etiqueta, consulta Define un servicio canónico.

Ten en cuenta que varias revisiones pueden estar en producción al mismo tiempo. La ejecución de varias revisiones a la vez se usa con mayor frecuencia para lograr:

  • El lanzamiento progresivo de un objeto binario nuevo, una configuración nueva o ambas en todas las instancias del servicio. En este caso, tanto la revisión anterior como la revisión nueva se encuentran activas durante la transición.
  • Una “prueba A/B” o “experimento en vivo”, en el que dos versiones diferentes del servicio se exponen a los subconjuntos de emisores descendentes para probar el efecto de un cambio.

¿Qué sigue?