multicluster traffic management #10486

stevenctl · 2021-11-09T21:56:34Z

https://deploy-preview-10486--preliminary-istio.netlify.app/latest/docs/ops/configuration/traffic-management/multicluster/

istio-policy-bot · 2021-11-09T21:56:36Z

😊 Welcome! This is either your first contribution to the Istio documentation repo, or
it's been awhile since you've been here. A few things you should know:

You can learn about how we write and maintain documentation, about our style guidelines,
and about all the available web site features by visiting Contributing to the Docs.
In the next few minutes, an automatic preview of your change will be
built as a full copy of the istio.io website. You can find this preview by clicking on
the Details link next to the deploy/netlify entry in the Status section of this
page.
We care about quality, so we've put in place a number of checks to ensure our documentation
is top notch. We do spell checking, we sanitize the markdown, we ensure all hyperlinks point
to valid location, and more. If your PR doesn't pass one of these checks, you'll see a red X in the
status section of the page. Click on the Details link to get a list of the problems with your PR.
Fix those problems and push an update to your PR. This will automatically rerun the tests and
hopefully this time everything will be perfect.
Once your changes are accepted and merged into the repository, they will initially show up
on https://preliminary.istio.io. The changes will be published to https://istio.io
the next time we do a major release (which typically happens every 3 months or so).

Thanks for contributing!

Courtesy of your friendly welcome wagon.

istio-testing · 2021-11-09T21:56:50Z

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

stevenctl · 2021-11-09T21:57:19Z

content/en/docs/ops/configuration/traffic-management/multicluster/index.md

+spec:
+  hosts:
+  - mysvc.myns.svc.cluster.local
+  http:


without sourceLabels support the VS has to be different in each cluster... and doesn't really work for primary-remote

Are you still working on the fix? Can this doc wait until that lands?

istio/istio#35998

It actually already works :)

stevenctl · 2021-11-09T21:58:11Z

content/en/docs/ops/configuration/traffic-management/multicluster/index.md

+load-balanced across all clusters in the mesh for a given service. In some cases, that behavior is not desirable, and
+this document describes the different options for overriding that default.
+
+## Cluster Local Services


should we also have a section that highlights locality load balancing as an option? and is this header correct?

I don't think we actually define cluster-local as a term. Perhaps you could call this something like Keeping traffic in-cluster?

Backing up a bit, the DR section is actually more generic than "cluster-local" anyway. You could use it for any sort of partitioning by label (network, cluster, etc.). Maybe we should frame it like that?

So the outline might be something like:

Keeping traffic in-cluster

Partitioning Service Endpoints (i.e. Subsetting)

Services that are not the same

And the partitioning example could effectively also be a cluster-local example, just doing it a different way. And just explain that it's actually a more flexible tool and can do more than just cluster-local.

stevenctl · 2021-11-09T21:59:11Z

content/en/docs/ops/configuration/traffic-management/multicluster/index.md

+test: no
+---
+
+Within a multicluster mesh, [namespace sameness](https://github.com/kubernetes/community/blob/master/sig-multicluster/namespace-sameness-position-statement.md)


Is this the right place for the sameness note? Or should it live in deployment models? Or both?

This should definitely go in deployment models. Maybe we need a glossary entry as well for namespace sameness. I'm fine duplicating the link here.

nmittler · 2021-11-09T22:51:16Z

content/en/docs/ops/configuration/traffic-management/multicluster/index.md

+load-balanced across all clusters in the mesh for a given service. In some cases, that behavior is not desirable, and
+this document describes the different options for overriding that default.
+
+## Cluster Local Services


I don't think we actually define cluster-local as a term. Perhaps you could call this something like Keeping traffic in-cluster?

Backing up a bit, the DR section is actually more generic than "cluster-local" anyway. You could use it for any sort of partitioning by label (network, cluster, etc.). Maybe we should frame it like that?

So the outline might be something like:

Keeping traffic in-cluster

Partitioning Service Endpoints (i.e. Subsetting)

Services that are not the same

And the partitioning example could effectively also be a cluster-local example, just doing it a different way. And just explain that it's actually a more flexible tool and can do more than just cluster-local.

nmittler · 2021-11-09T22:56:18Z

content/en/docs/ops/configuration/traffic-management/multicluster/index.md

+spec:
+  hosts:
+  - mysvc.myns.svc.cluster.local
+  http:


Are you still working on the fix? Can this doc wait until that lands?

nmittler · 2021-11-09T23:01:37Z

content/en/docs/ops/configuration/traffic-management/multicluster/index.md

+
+### Per-cluster `Service` or `Namespace`
+
+If `Services` aren't meant to be used cross-cluster at all, it may make sense to simply give them unique names in each


Can we come up with a more concrete example for this? I'm having trouble picturing how this is different from cluster-local.

hzxuzhonghu · 2021-11-12T02:03:21Z

content/en/docs/ops/configuration/traffic-management/multicluster/index.md

+### Keeping traffic in-cluster
+
+In some cases the default cross-cluster load balancing behavior is not desirable. To keep traffic "cluster-local" (i.e.
+traffic sent from `cluster-a` will only reach destinations in `cluster-a`), there are multiple-approaches.


there is another approach localityloadbalancing.FailoverPriority

Locality load balancing is a slightly different topic. Locality LB allows spill over into other localities. Here we're specifically protecting against that in order to draw strict partitions within the mesh. Any locality LB would apply within the partitions.

Yes! Definitely want to fit that in.

hzxuzhonghu · 2021-11-13T02:34:37Z

content/en/docs/ops/configuration/traffic-management/multicluster/index.md

+
+On top of default locality components of `region/zone/subzone`, you can use [`failoverPriority`](/docs/reference/config/networking/destination-rule/#LocalityLoadBalancerSetting)
+to failover based on the cluster or network explicitly. Using the following destination rule, traffic will prefer first
+in-cluster traffic, then in-network, then in-region, etc.


Not exactly, matching all the labels first, then second, match the first N-1 labels.

nmittler · 2021-11-11T15:03:49Z

content/en/docs/ops/configuration/traffic-management/multicluster/index.md


-## Cluster Local Services
+If there is no case where this traffic should be sent across clusters, consider giving the services a different name in each cluster.


This sounds like cluster-local services could apply here too ... in which case they are the same service, but happen to be stateful.

nmittler · 2021-11-11T15:06:54Z

content/en/docs/ops/configuration/traffic-management/multicluster/index.md

@@ -7,15 +7,16 @@ owner: istio/wg-networking-maintainers
 test: no
 ---

+### Services that are not the same


Maybe just call this Namespace Sameness?

nmittler · 2021-11-11T15:08:14Z

content/en/docs/ops/configuration/traffic-management/multicluster/index.md

+
+If there is no case where this traffic should be sent across clusters, consider giving the services a different name in each cluster.
+
+### Partitioning Service Endpoints (i.e. creating subsets) 


Maybe just call this Partitioning a Service

nmittler · 2021-11-11T15:09:10Z

content/en/docs/ops/configuration/traffic-management/multicluster/index.md

+
+### Partitioning Service Endpoints (i.e. creating subsets) 
+
+Using the label `topology.istio.io/cluster` in the subset selector for a DestinationRule, you can create


Let's begin by making a more general statement that you can partition anyway you like by label, using subsets. Maybe we can even link to the list of labels in the API? Then as the example, we can build a cluster-local service using the cluster label.

+1 I think a list of the available built-in labels that one can use, would be really good.

Sgtm. Would be cool if we included something in /reference/config/labels/ that additionally highlights the which ones are built-in.

nmittler · 2021-11-11T15:18:02Z

content/en/docs/ops/configuration/traffic-management/multicluster/index.md

+        subset: cluster-2
+{{< /text >}}
+
+#### Global `MeshConfig` settings


I actually think this should be a top-level section along side the Partitioning a Service section. The partitioning section is all about subsets .... this is different.

Maybe we call this something like Keeping Traffic In-Cluster? We've never actually defined cluster-local AFAIK :).

So I'm thinking we could re-arrange the contents to:

Namespace Sameness

Here we just keep you section as-is .. just introduce/re-introduce the concept.

Keeping Traffic In-Cluster

The mesh-config solution.

Service Partitioning

We describe that this is a general way of partitioning your service endpoints and we'll re-do the "Keeping Traffic In-Cluster" using subsets as an example.

WDYT?

That sounds good to me. It would be good to also explain that service partitioning can also be used to keep traffic in-cluster and maybe touch on why use one vs the other.

I've put things in this structure, but I can't really think of a good way to word the pros/cons of each of the "cluster-local" approaches.

On one hand, the subsetting approach allows a bit more granular control, but it also starts to mix service-level policy with topology-level policy. For example, a config that sends 10% of traffic to v2 now needs 2x subsets (i.e. cluster-1-v2, cluster-2-v2)

Rather than pros/cons I was thinking just a high level statement, maybe along the lines of what you just said. The one is generally more appropriate for setting topology-level policy, while the other is more service focused.

added a section at the bottom

nmittler · 2021-11-12T15:05:49Z

content/en/docs/ops/configuration/traffic-management/multicluster/index.md

+### Keeping traffic in-cluster
+
+In some cases the default cross-cluster load balancing behavior is not desirable. To keep traffic "cluster-local" (i.e.
+traffic sent from `cluster-a` will only reach destinations in `cluster-a`), there are multiple-approaches.


Locality load balancing is a slightly different topic. Locality LB allows spill over into other localities. Here we're specifically protecting against that in order to draw strict partitions within the mesh. Any locality LB would apply within the partitions.

stevenctl · 2021-11-15T19:34:44Z

Locality load balancing is a slightly different topic.

I think it still has a place here but I don't feel strongly.

nmittler · 2021-11-15T19:41:58Z

Locality load balancing is a slightly different topic.

I think it still has a place here but I don't feel strongly.

We already have docs (a task) for locality LB. We could mention it somewhere here and link to the docs?

stevenctl · 2021-11-15T20:15:48Z

Locality load balancing is a slightly different topic.

I think it still has a place here but I don't feel strongly.

We already have docs (a task) for locality LB. We could mention it somewhere here and link to the docs?

Probably just need to update it with details/examples for the new failoverPriority API.

hzxuzhonghu · 2021-11-16T06:50:23Z

content/en/docs/ops/configuration/traffic-management/multicluster/index.md

+
+On top of default locality components of `region/zone/subzone`, you can use [`failoverPriority`](/docs/reference/config/networking/destination-rule/#LocalityLoadBalancerSetting)
+to failover based on the cluster or network explicitly. Using the following destination rule, traffic will prefer first
+in-cluster traffic, then in-network, then in-region, etc.


This desc is not quite right

hzxuzhonghu · 2021-11-16T06:51:17Z

content/en/docs/ops/configuration/traffic-management/multicluster/index.md

+        - "topology.istio.io/cluster"
+        - "topology.istio.io/network"
+        - "topology.kubernetes.io/region"
+        - "topology.kubernetes.io/zone"
+        - "topology.istio.io/subzone"


maybe you can remove the region/zone/subzone

content/en/docs/ops/configuration/traffic-management/multicluster/index.md

frankbu · 2021-12-06T21:08:14Z

content/en/docs/ops/configuration/traffic-management/multicluster/index.md

+  clusterLocal: true
+  hosts:
+    - "mysvc.myns.svc.cluster.local"


This should be indented more?

btw, where is the proto for this?

good catch – and I'm not sure what you mean by where is the proto?

frankbu · 2021-12-06T21:08:42Z

content/en/docs/ops/configuration/traffic-management/multicluster/index.md

+
+{{< tab name="per-service" category-value="service" >}}
+
+{{< text yaml >}}


Should give more context. What CRD is this, and were is it applied?

…ter/index.md Co-authored-by: Frank Budinsky <frankb@ca.ibm.com>

content/en/docs/ops/configuration/traffic-management/multicluster/index.md

…ter/index.md Co-authored-by: Frank Budinsky <frankb@ca.ibm.com>

frankbu · 2022-01-10T18:54:42Z

/test gencheck_istio.io

content/en/docs/ops/configuration/traffic-management/multicluster/index.md

…ter/index.md Co-authored-by: Frank Budinsky <frankb@ca.ibm.com>

* feat/content/zh/docs/ops/configuration/traffic-management/multicluster/index.md * feat/content/zh/docs/ops/configuration/traffic-management/multicluster/index.md * feat/multicluster traffic management docs * fix/content/zh/docs/releases/bugs/index.md * "2"

multicluster traffic management

82627ab

istio-testing added the do-not-merge/work-in-progress Block merging of a PR because it isn't ready yet. label Nov 9, 2021

google-cla bot added the cla: yes Set by the Google CLA bot to indicate the author of a PR has signed the Google CLA. label Nov 9, 2021

istio-testing added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Nov 9, 2021

stevenctl commented Nov 9, 2021

View reviewed changes

nmittler reviewed Nov 9, 2021

View reviewed changes

restructure

5da67fa

hzxuzhonghu reviewed Nov 12, 2021

View reviewed changes

locality section

8890deb

stevenctl marked this pull request as ready for review November 12, 2021 20:30

stevenctl requested a review from a team as a code owner November 12, 2021 20:30

istio-testing removed the do-not-merge/work-in-progress Block merging of a PR because it isn't ready yet. label Nov 12, 2021

hzxuzhonghu reviewed Nov 13, 2021

View reviewed changes

nmittler reviewed Nov 15, 2021

View reviewed changes

restructure istio#2

51d5ff4

hzxuzhonghu reviewed Nov 16, 2021

View reviewed changes

Steven Landow and others added 5 commits November 16, 2021 10:21

remove locality

1f2c246

top level headers

f18964b

touchup

b986db5

s/subsettings/subset/

54893f0

blanks

b9d4379

hzxuzhonghu approved these changes Dec 6, 2021

View reviewed changes

frankbu reviewed Dec 6, 2021

View reviewed changes

content/en/docs/ops/configuration/traffic-management/multicluster/index.md Show resolved Hide resolved

frankbu reviewed Dec 6, 2021

View reviewed changes

Update content/en/docs/ops/configuration/traffic-management/multiclus…

fe45fe2

…ter/index.md Co-authored-by: Frank Budinsky <frankb@ca.ibm.com>

frankbu reviewed Dec 6, 2021

View reviewed changes

content/en/docs/ops/configuration/traffic-management/multicluster/index.md Outdated Show resolved Hide resolved

frankbu reviewed Jan 4, 2022

View reviewed changes

content/en/docs/ops/configuration/traffic-management/multicluster/index.md Outdated Show resolved Hide resolved

Steven Landow and others added 2 commits January 5, 2022 12:04

Update content/en/docs/ops/configuration/traffic-management/multiclus…

f1e173d

…ter/index.md Co-authored-by: Frank Budinsky <frankb@ca.ibm.com>

Update content/en/docs/ops/configuration/traffic-management/multiclus…

4d40b03

…ter/index.md Co-authored-by: Frank Budinsky <frankb@ca.ibm.com>

frankbu approved these changes Jan 10, 2022

View reviewed changes

frankbu added the do-not-merge Block automatic merging of a PR. label Jan 10, 2022

frankbu reviewed Jan 10, 2022

View reviewed changes

content/en/docs/ops/configuration/traffic-management/multicluster/index.md Outdated Show resolved Hide resolved

Update content/en/docs/ops/configuration/traffic-management/multiclus…

744f94d

…ter/index.md Co-authored-by: Frank Budinsky <frankb@ca.ibm.com>

frankbu removed the do-not-merge Block automatic merging of a PR. label Jan 11, 2022

istio-testing merged commit 337c78b into istio:master Jan 11, 2022


		### Per-cluster `Service` or `Namespace`

		If `Services` aren't meant to be used cross-cluster at all, it may make sense to simply give them unique names in each


		## Cluster Local Services
		If there is no case where this traffic should be sent across clusters, consider giving the services a different name in each cluster.


		If there is no case where this traffic should be sent across clusters, consider giving the services a different name in each cluster.

		### Partitioning Service Endpoints (i.e. creating subsets)


		### Partitioning Service Endpoints (i.e. creating subsets)

		Using the label `topology.istio.io/cluster` in the subset selector for a DestinationRule, you can create


		{{< tab name="per-service" category-value="service" >}}

		{{< text yaml >}}

multicluster traffic management #10486

multicluster traffic management #10486

Uh oh!

Conversation

stevenctl commented Nov 9, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

istio-policy-bot commented Nov 9, 2021

Uh oh!

istio-testing commented Nov 9, 2021

Uh oh!

stevenctl Nov 9, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

stevenctl commented Nov 15, 2021

Uh oh!

nmittler commented Nov 15, 2021

Uh oh!

stevenctl commented Nov 15, 2021

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

stevenctl commented Nov 9, 2021 •

edited

Loading

stevenctl Nov 9, 2021 •

edited

Loading