[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間:2025-09-02 (世界標準時間)。"],[],[],null,["# Isolation for Cloud Service Mesh\n================================\n\n|\n| **Preview**\n|\n|\n| This product or feature is subject to the \"Pre-GA Offerings Terms\" in the General Service Terms section\n| of the [Service Specific Terms](/terms/service-terms#1).\n|\n| Pre-GA products and features are available \"as is\" and might have limited support.\n|\n| For more information, see the\n| [launch stage descriptions](/products#product-launch-stages).\n\nThis page shows you how to configure your service mesh with\nbetter request isolation for your backend service by creating an isolation\nconfig.\n\nThis feature provides additional isolation support for the backends of your\nservices to prevent cross-region overflow.\n\nBy default, Cloud Service Mesh uses the\n[waterfall by region](/service-mesh/docs/service-routing/advanced-load-balancing-overview#balance-trafic-backends)\nalgorithm to decide where your user traffic should be routed to. With this\nalgorithm, Cloud Service Mesh routes traffic\nto the closest region until the backends are running at their configured\ncapacity limit. After that, traffic will start to overflow into a region that is\nfurther away.\n\nWith this feature, based on your frontend region and configuration of isolation,\ntraffic is limited to the closest or local region and won't overflow if the\nclosest region is running out of capacity. This help you prevent potential\ncascading failures and limit potential outages in the same region. You otherwise\nstill manage your service config at the global level.\n\nWhether or not to use this feature depends on your actual use cases and you\nshould carefully explore the following considerations before using it:\n\n- If your backends in a region are overloaded, Cloud Service Mesh may still send additional traffic to them even if backends in other regions can handle the traffic. This means each individual region is more likely to overload due to additional traffic and you need to plan accordingly.\n- Your traffic is still routed with a global control plane. This means there is still a chance of globally coordinated failures across multiple regions.\n- This feature is configured with the [serviceLbPolicy resource](/load-balancing/docs/service-lb-policy). All restrictions still apply.\n- With the **STRICT** isolation mode, requests fail if there are no serving backends in the same region.\n\nThere are two scenarios after applying this feature: \n\n### Nearest Isolation\n\nNearest Regional Isolation is where a frontend with collocated backends will\nbe isolated to only that region. If no backend available is in the local\nlocation, it will be connected to the backend region while optimizing network\nlatency.\n\n### Strict Isolation\n\nStrict Regional Isolation is where frontend locations can only reach backends\nwithin the local region. Frontends without serving backends in the local\nregion will drop all their traffic.\n\nEnabling isolation\n------------------\n\n### gcloud\n\nPerform the following steps to create an isolation config using\nGoogle Cloud CLI.\n\n1. Run the following command to create a `serviceLbPolicy`:\n\n gcloud network-services service-lb-policies create my-isolation-policy \\\n --isolation-config-granularity=REGION \\\n --isolation-config-mode=\u003cvar translate=\"no\"\u003eISOLATION_MODE\u003c/var\u003e \\\n --location=global\n\n Replace \u003cvar translate=\"no\"\u003eISOLATION_MODE\u003c/var\u003e with one of the following options:\n 1. **NEAREST**: Traffic is sent to the nearest region.\n 2. **STRICT**: Traffic fails if no serving backends are available in the same region as the frontend.\n\n If not explicitly provided, **NEAREST** is the default value. Note that you\n can only specify this field if the `--isolation-granularity` flag is also\n set.\n\n Alternatively, if you have an existing policy, update it with the following\n command: \n\n gcloud network-services service-lb-policies update \u003cvar translate=\"no\"\u003ePOLICY_NAME\u003c/var\u003e \\\n --isolation-config-granularity=REGION \\\n --isolation-config-mode=\u003cvar translate=\"no\"\u003eISOLATION_MODE\u003c/var\u003e \\\n --location=global\n\n Replace \u003cvar translate=\"no\"\u003ePOLICY_NAME\u003c/var\u003e with the name of your existing policy.\n2. Once a `serviceLbPolicy` resource is created or updated, attach it to your\n `backendService` resource:\n\n gcloud compute backend-services update \u003cvar translate=\"no\"\u003eBACKEND_SERVICE_NAME\u003c/var\u003e \\\n ‐‐service-lb-policy POLICY_URL\n\n Replace \u003cvar translate=\"no\"\u003eBACKEND_SERVICE_NAME\u003c/var\u003e with the name of your Backend Service.\n\nDisable isolation\n-----------------\n\nTo disable this feature, you have two options:\n\n1. Set the `isolationConfigs` to unspecified.\n2. Remove `ServiceLbPolicy` from the service if it is the only feature you enabled with this policy\n\n### Set `isolationConfigs` to unspecified\n\nRun the following command to set the `isolationConfigs` to unspecified: \n\n gcloud network-services service-lb-policies update my-isolation-policy \\\n --isolation-config-granularity=unspecified \\\n --isolation-config-mode=unspecified \\\n --location=global\n\n### Remove `ServiceLbPolicy` from the service\n\nRun the following command to remove the `ServiceLbPolicy`: \n\n gcloud network-services service-lb-policies delete my-isolation-policy --location=global\n\nSupportability, Diagnosis, and Troubleshooting\n----------------------------------------------\n\nThis section describes potential issues after turning on this feature.\n\n### Backends overloaded\n\nThis feature provides isolation support, and thus traffic won't be shifted to a\nremote region if the local region is full. So some of your backends could be\noverloaded if this feature is turned on. If this is not the behavior you are\nlooking for, consider turning off this feature. You can also consider\n[enabling autoscaling](/kubernetes-engine/docs/how-to/horizontal-pod-autoscaling)\nto handle backend overloads better.\n\n### Traffic was shifted\n\nThis feature prevents capacity based traffic overflow. So if your backends were\noverloaded before turning this feature on, traffic may already have been shifted\nto a remote region. In that case, turning this feature on could cause these\ntraffic to be shifted back.\n\n### Traffic was not shifted\n\nThis feature prevents capacity based traffic overflow. So if your backends were\nnot overloaded before turning this feature on, it is likely that the closest\nregion is capable of handling all the traffic. In that case, turning this feature\non may not cause traffic shifts in the short term.\n\n### Traffic was shifted after backends are added to or removed from a region\n\nWhen this feature is turned on, traffic may be shifted if new backends are added\nto a region. This is expected as Cloud Service Mesh will try to route traffic\nto these backends to optimize the overall network latency. Similarly when the\nlast backends are removed, Cloud Service Mesh will start sending traffic to a\nremote region. This is also an expected behavior.\n\n### Requests failed\n\nIf **STRICT** isolation mode is enabled and there are no backends serving in the\nsame region as the frontend, traffic is expected to fail. If it is not your\nintended behavior, make sure you have backends in each of the regions\nwhere you expect traffic to be sent."]]