router-sharding-blurb

router-sharding-blurb

[[using-router-shards]]
=== Using Router Shards

Each link:../../architecture/core_concepts/projects_and_users.html#projects[project has its own namespace].
By default, a router selects routes from all the namespaces it has
access to. The access controls are based on the service account that the
router is run with.

Using `NAMESPACE_LABELS` and/or `ROUTE_LABELS`, a router can filter out the
namespaces and/or routes that it should service. This enables one to
partition routes amongst multiple router deployments effectively
distributing the set of routes.

Example: A router deployment `finops-router` is run with route selector
        `NAMESPACE_LABELS="name in (finance, ops)"`
        and a router deployment `dev-router` is run with route selector
        `NAMESPACE_LABELS="name=dev"`

        If all routes are in the 3 namespaces `finance`, `ops` or `dev`,
        then this could effectively distribute our routes across two
        router deployments.

In the above scenario, sharding becomes a special case of partitioning
with no overlapping sets. Routes are divided amongst multiple router shards.

The criteria for route selection governs how the routes are distributed - it
is possible to have routes that overlap accross multiple router deployments.

Example: In addition to the `finops-router` and `dev-router` in the example
         above, we also have an `devops-router` which is run with a route
         selector `NAMESPACE_LABELS="name in (dev, ops)"`.

The routes in namespaces `dev` or `ops` now are serviced by two different
router deployments. This becomes a case where we have partitioned the
routes with an overlapping set.


In addition, this enables us to create more complex routing rules ala
divert high priority traffic to the dedicated `finops-router` but send
the lower priority ones to the `devops-router`.

`NAMESPACE_LABELS` allows filtering the projects to service and selecting
all the routes from those projects. But we may want to partition routes
based on other criteria in the routes themselves. The `ROUTE_LABELS`
selector allows you to slice-and-dice the routes themselves.

Example: A router deployment `prod-router` is run with route selector
        `ROUTE_LABELS="mydeployment=prod"`
        and a router deployment `devtest-router` is run with route selector
        `ROUTE_LABELS="mydeployment in (dev, test)"`
        
Example assumes you have all the routes you wish to serviced tagged with a label `"mydeployment=<tag>"`.