[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-09-03。"],[],[],null,["# Canonical Service\n=================\n\n\n**Note:** Canonical Services are supported automatically in Cloud Service Mesh version 1.6.8 and higher.\n\nThis page explains what a Canonical Service is in Cloud Service Mesh.\n\nWhat is a Canonical Service?\n----------------------------\n\nCloud Service Mesh 1.6.8 introduces support for Canonical Services, a conceptual and\narchitectural model for representing your production workloads as a singular\nservice that is easier to observe and manage. These workloads can span multiple\nclusters, disparate backend platforms, and different schemas and configurations.\n\n**For Kubernetes users:** Canonical Service is roughly analogous to the\nKubernetes \"app\" concept and the Application CRD.\n\n**For Serverless users:** Canonical Service is very similar to\n[App Engine service](/appengine/docs/flexible/java/an-overview-of-app-engine#services)\nand [Cloud Run service](/run/docs/resource-model#services) concepts.\nThe one difference is that Google Serverless services are inherently regional\nwhereas Canonical Services are a global / multi-region abstraction.\n\nFor example, the following scenarios all describe ways that you might refer to a\nCanonical Service:\n\n- A service has an outage.\n- A service runs both on-premise and on a public cloud.\n- Deploying a new revision of a service.\n- The service Foo is sending too much traffic and may exceed our capacity.\n\nCanonical Services exist within a single Mesh, which in Cloud Service Mesh means that\nthey are also unique within a\n[fleet](/anthos/multicluster-management/fleets) and a Google Cloud\nProject (all of which are one-to-one with Mesh).\n\nA given workload is only allowed to be part of one Canonical Service.\n\nYou can determine the full scope of a Canonical Service from the group of\nworkloads that define it including:\n\n- **Hostnames and IP addresses**\n- **Network(s)**\n- **Network and security policies**\n- **Routing and load balancing**\n- **VM and container images**\n- **Physical or virtual infrastructure**\n- **Geographic region(s)**\n- **CI/CD system**\n- **Source code**\n- **Telemetry**\n- **Service level objectives and alerts**\n\nYou can view dashboards that display these operational details for each service\non the [Services page](https://console.cloud.google.com/kubernetes/services).\n\nCanonical Service requirements and limitations\n----------------------------------------------\n\nCanonical Services are only available on Cloud Service Mesh version 1.6.8 and\nhigher.\n\nEach Canonical Service exists inside of a single Kubernetes/Istio namespace and\ncannot cross namespace boundaries.\n\nYou must give a Canonical Service a unique name within its parent namespace. For\nmore information, see\n[define a Canonical Service](/service-mesh/v1.23/docs/define-canonical-service).\n\nCanonical Services can exist across multiple clusters and regions. While it is\npossible to break down resources and telemetry by cluster and region, those are\nnot factors in determining the scope or uniqueness of a service.\n\nTherefore, the unique identity of a Canonical Service is determined by: \n\n mesh id + namespace + canonical name.\n\nRevisions\n---------\n\nRevisions refer to incremental changes to a service which you can use to\ndistinguish and identify different \"versions\" or \"releases\" of your services.\n\nDifferentiate between revisions of a Canonical Service by labeling an individual\nworkload with its \"canonical revision.\" This label is an arbitrary string that\nyou can define. While the label may be set automatically in some cases, you or\nthe CI/CD system that deploys the service must apply the label. For guidance on\nsetting this label, see [Define a Canonical Service](/service-mesh/v1.23/docs/define-canonical-service).\n\nNote that multiple revisions can be in production at the same time. Running\nmultiple revisions at once is most often used to accomplish:\n\n- The progressive roll-out of a new binary, a new configuration, or both across all of the instances of one's service. In this case, both the old and new revisions are live during the transition.\n- An \"A/B test\" or \"live experiment,\" in which two different versions of the service are exposed to subsets of downstream callers to test the effect of a change.\n\nWhat's next\n-----------\n\n- [Define a Canonical Service](/service-mesh/v1.23/docs/define-canonical-service).\n- [Canonical Services best practices](/service-mesh/v1.23/docs/canonical-service-best-practices).\n- [Troubleshooting Canonical Services](/service-mesh/v1.23/docs/troubleshooting/troubleshoot-canonical-service)."]]