zalando-incubator / fabric-gateway Goto Github PK

This is not trivial and we might think about how to do this. I guess we should have 1st class support in fabric for this kind.
In case you want to do shadow traffic with a fraction of traffic, you need to create multiple routes as you can see in [1].

The current way fabric works is that we can not add these routes and a common solution is to add a RouteGroup in front of fabric, which doubles the proxy requests:

client -> skipper[RouteGroup] -> skipper[fabric] -> backends

Ideal case would be to be able to drop the RouteGroup, because of complexity.
I would expect, that people deploy a second application (likely with also fabric) and add in their old fabric configuration the new endpoint and a number between [0..1]. Numbers in the interval (0..1) are created in the way [1] is shown. 0 means we do not apply any new route, 1 means we do not to split the routes (tee() is enough).

[1] https://opensource.zalando.com/skipper/tutorials/shadow-traffic/

Many APIs implement hierarchical paths, for instance

/customers
/customers/{id}
/customers/{id}/addresses
/customers/{id}/addresses/{id}

In many scenarios, a class of http ops on the full hierarchy shall be accessible with the same set of rules (e.g. POST/PUT/PATCH/DELETE on /customers, /customers/{id}, etc).

The current path selector allows to select multiple segments, e.g. /customers/**, but this would not select the collection endpoint /customers. The method selector can only select a single method. This leads to a lot of unnecessary duplication of access rules under the above scenario.

My proposal therefore is to be able to combine all or any permutation of the above paths and methods in one selector in order to reduce duplication of access rules.

Possible solutions could be to allow the path selector to be a list or to allow the path selector to be a regular expression. For example:

spec:
  paths:
    "/customers|/customers/**":
      "post|patch|delete":
        x-fabric-privileges:
          ...

...but any other solution you come up with to select multiple paths and methods would of course work as well.

The skipper team have been working on a new filter, called backendRateLimit, designed to address some issues in calculating rate limits for services that autoscale. Broadly, the problem is that the existing rate limits (such as clusterClientRateLimit) define an arbitrary rate limit for the entire service — all discovered endpoints for that service.

For the majority of services they can horizontally scale, and the throughput a service is able to deliver is a function of how many replicas that service is operating with (as well as certain constants; database through capacity for example).

To facilitate this ambiguity, as well as to make the calculation of the "final practical" rate limit much easier, the skipper team implemented backendRateLimit — a limit to how many requests a single destination replica can process over a sliding window.

For applications that are behind "fabric gateway", they currently cannot (easily) use this feature. Given this, this feature request is to expose the feature, similar to how clusterClientRateLimit is now implemented.

Some additional reading is available at:

1. https://opensource.zalando.com/skipper/reference/filters/#backendratelimit
2. https://github.com/zalando/skipper

There is no deployment configuration, YAML files in deploy folder have variables, that need to be replaced by the user.
I would suggest to have a docs/ folder and link to installation docs from the readme.

Show for example a fabric CRD from the user point of view and explain what does it provide as features for the user.

Hi folks @fabric

I would like to suggest adding support for configuring the Skipper fadeIn filter. This filter is highly useful on kubernetes deployments using skipper as Ingress, as it allows traffic to new pods to be switched gradually (i.e. faded in). This helps mitigating startup issues such as latency spikes caused by JVM JIT compilation and/or non-warmed-up connection pools.