Servicio canónico
Nota: Los servicios canónicos se admiten automáticamente en Cloud Service Mesh 1.6.8 y versiones 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 presenta la compatibilidad con los servicios canónicos, un concepto y de arquitectura para representar tus cargas de trabajo de producción como una sola 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 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 única malla, lo que en Cloud Service Mesh significa que sino que también son únicos fleet y una instancia de Google Cloud Proyecto (todos estos 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 paneles en los que se muestran estos detalles operativos de cada servicio en la página Servicios.
Requisitos y limitaciones de servicios canónicos
Los servicios canónicos solo están disponibles en las versiones 1.6.8 y 1.6.8 de Cloud Service Mesh mayores.
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 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 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?
- Define un servicio canónico.
- Prácticas recomendadas de servicios canónicos.
- Solución de problemas de los servicios canónicos