Servicio canónico

Nota: Los servicios canónicos se admiten automáticamente en Cloud Service Mesh versión 1.6.8 y posteriores.

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

¿Qué es un servicio canónico?

Cloud Service Mesh 1.6.8 introduce la compatibilidad con los servicios canónicos, un modelo conceptual y arquitectónico para representar tus cargas de trabajo de producción como un servicio único que es más fácil de observar y gestionar. Estas cargas de trabajo pueden abarcar varios clústeres, plataformas backend dispares y diferentes esquemas y configuraciones.

Para los usuarios de Kubernetes: Canonical Service es aproximadamente análogo al concepto de "aplicación" de Kubernetes y al CRD de Application.

Para los usuarios de Serverless: Canonical Service es muy similar a los conceptos de servicio de App Engine y servicio de Cloud Run. La única diferencia es que los servicios sin servidor 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 describe cómo puedes hacer referencia a un servicio canónico:

  • Un servicio tiene una interrupción.
  • Un servicio se ejecuta tanto en las instalaciones como en una nube pública.
  • Desplegar una nueva revisión de un servicio.
  • El servicio Foo está enviando demasiado tráfico y puede superar nuestra capacidad.

Los servicios canónicos se encuentran en una sola malla, lo que en Cloud Service Mesh significa que también son únicos en una flota y en un proyecto (todos ellos son uno a uno con la malla). Google Cloud

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

Puedes determinar el ámbito completo de un servicio canónico a partir del grupo de cargas de trabajo que lo definen, entre las que se incluyen las siguientes:

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

Puedes ver los paneles de control que muestran estos detalles operativos de cada servicio en la página Servicios.

Requisitos y limitaciones de los servicios canónicos

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

Cada servicio canónico se encuentra en un único espacio de nombres de Kubernetes o Istio y no puede cruzar los límites de los espacios de nombres.

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

Los servicios canónicos pueden existir en varios clústeres y regiones. Aunque es posible desglosar los recursos y la telemetría por clúster y región, estos no son factores que determinen el ámbito o la singularidad de un servicio.

Por lo tanto, la identidad única de un servicio canónico se determina por lo siguiente:

mesh id + namespace + canonical name.

Revisiones

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

Diferencia entre las revisiones de un servicio canónico etiquetando una carga de trabajo individual con su "revisión canónica". Esta etiqueta es una cadena arbitraria que puedes definir. Aunque la etiqueta se puede definir automáticamente en algunos casos, tú o el sistema de integración continua y entrega continua que despliega el servicio debéis aplicar la etiqueta. Para obtener información sobre cómo definir esta etiqueta, consulta Definir un servicio canónico.

Ten en cuenta que puede haber varias revisiones en producción al mismo tiempo. Ejecutar varias revisiones a la vez se suele usar para lo siguiente:

  • Lanzamiento progresivo de un nuevo archivo binario, una nueva configuración o ambos en todas las instancias de un servicio. En este caso, tanto la revisión antigua como la nueva estarán activas durante la transición.
  • Una "prueba A/B" o un "experimento activo", en el que se muestran dos versiones diferentes del servicio a subconjuntos de los llamantes de nivel inferior para probar el efecto de un cambio.

Siguientes pasos