-
Notifications
You must be signed in to change notification settings - Fork 216
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge branch 'main' into alex/protocol-detection-edge
- Loading branch information
Showing
35 changed files
with
1,855 additions
and
49 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,26 @@ | ||
| --- | ||
| title: Egress | ||
| --- | ||
|
|
||
| Linkerd features capabilities to monitor and apply policies to egress traffic. | ||
| This allows cluster operators to make use of the `EgressNetwork` CRD to classify | ||
| and visualize traffic. This CRD can be used as a parent reference for | ||
| Gateway API route primitives in order to enable policy and routing configuration. | ||
| Linkerd's egress control is implemented in the sidecar proxy itself; separate | ||
| egress gateways are not required (though they can be supported). | ||
|
|
||
| {{< warning >}} | ||
|
|
||
| No service mesh can provide a strong security guarantee about egress traffic | ||
| by itself; for example, a malicious actor could bypass the Linkerd sidecar - | ||
| and thus Linkerd's egress controls - entirely. Fully restricting egress | ||
| traffic in the presence of arbitrary applications thus typically requires a | ||
| more comprehensive approach. | ||
|
|
||
| {{< /warning >}} | ||
|
|
||
| Related content: | ||
|
|
||
| * [Guide: Managing egress traffic] | ||
| ({{< relref "../tasks/managing-egress-traffic" >}}) | ||
| * [EgressNetwork Reference]({{< relref "../reference/egress-network" >}}) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,55 @@ | ||
| --- | ||
| title: Rate Limiting | ||
| description: Linkerd offers a simple and performant HTTP local rate limiting solution to protect services from misbehaved clients | ||
| --- | ||
|
|
||
| Rate limiting helps protect a service by controlling its inbound traffic flow to | ||
| prevent overload, ensure fair resource use, enhance security, manage costs, | ||
| maintain quality, and comply with SLAs. | ||
|
|
||
| Please check the [Configuring Rate Limiting | ||
| task](../../tasks/configuring-rate-limiting/) for an example guide on deploying | ||
| rate limiting, and the [HTTPLocalRateLimitPolicy reference | ||
| doc](../../reference/rate-limiting/). | ||
|
|
||
| ## Scope | ||
|
|
||
| Linkerd offers a _local_ rate limiting solution, which means that each inbound | ||
| proxy performs the limiting for the pod. This is unlike _global_ rate limiting, | ||
| which takes into account all replicas for each service to track global request | ||
| volume. Global rate limiting requires an additional service to track everything | ||
| and is thus more complex to deploy and maintain. | ||
|
|
||
| ## Fairness | ||
|
|
||
| In the `HTTPLocalRateLimitPolicy` CR you can optionally configure a rate limit | ||
| to apply to all the inbound traffic for a given Server, regardless of the | ||
| source. | ||
|
|
||
| Additionally, you can specify fairness among clients by declaring a limit per | ||
| identity. This avoids specific clients gobbling all the rate limit quota and | ||
| affecting all the other clients. Note that all unmeshed sources (which don't | ||
| have an identity) are treated as a single source. | ||
|
|
||
| Finally, you also have at your disposal the ability to override the config for | ||
| specific clients by their identity. | ||
|
|
||
| ## Algorithm | ||
|
|
||
| Linkerd uses the [Generic cell rate algorithm | ||
| (GCRA)](https://en.wikipedia.org/wiki/Generic_cell_rate_algorithm) to implement | ||
| rate limiting, which is more performant than the token bucket and leaky bucket | ||
| algorithms usually used for rate limiting. | ||
|
|
||
| The GCRA has two parameters: cell rate and tolerance. | ||
|
|
||
| In its virtual scheduling description, the algorithm determines a theoretical | ||
| arrival time, representing the 'ideal' arrival time of a cell (request) if cells | ||
| (requests) were transmitted at equal intervals of time, corresponding to the | ||
| cell rate. How closely the flow of requests should abide to that arrival time is | ||
| determined by the tolerance parameter. | ||
|
|
||
| In Linkerd we derive the cell rate from the `requestsPerSecond` entries in | ||
| `HTTPLocalRateLimitPolicy` and the tolerance is set to one second. This helps | ||
| accommodating small variations or occasional bursts in traffic while ensuring | ||
| the long-term rate remains within limits. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,110 @@ | ||
| --- | ||
| title: EgressNetwork | ||
| --- | ||
|
|
||
| Linkerd's [egress functionality]({{< relref "../features/egress">}}) allows | ||
| you to monitor and control traffic that leaves the cluster. This behavior is | ||
| controlled by creating `EgressNetwork` resources, which describe the properties | ||
| of traffic that leaves a cluster and provide a way to apply policies to it, using | ||
| Gateway API primitives. | ||
|
|
||
| {{< warning >}} | ||
|
|
||
| No service mesh can provide a strong security guarantee about egress traffic | ||
| by itself; for example, a malicious actor could bypass the Linkerd sidecar - | ||
| and thus Linkerd's egress controls - entirely. Fully restricting egress | ||
| traffic in the presence of arbitrary applications thus typically requires a | ||
| more comprehensive approach. | ||
|
|
||
| {{< /warning >}} | ||
|
|
||
| ## EgressNetwork semantics | ||
|
|
||
| An `EgressNetwork` is essentially a description for a set of traffic | ||
| destinations that reside outside the cluster. In that sense, it is comparable | ||
| to a Service, with the main difference being that a Service encompasses a single | ||
| logical destination while an `EgressNetwork` can encompass a set of | ||
| destinations. This set can vary in size - from a single IP address to the entire | ||
| network space that is not within the boundaries of the cluster. | ||
|
|
||
| An `EgressNetwork` resource by default has several namespace semantics that are | ||
| worth outlining. EgressNetworks are namespaced resources, which means that they | ||
| affect only clients within the namespace that they reside in. The only exception | ||
| is EgressNetworks created in the global egress namespace: these EgressNetworks | ||
| affect clients in all namespaces. The namespace-local resources take priority. | ||
| By default the global egress namespace is set to `linkerd-egress`, but can be | ||
| configured by setting the `egress.globalEgressNetworkNamespace` Helm | ||
| value. | ||
|
|
||
| ## EgressNetwork Spec | ||
|
|
||
| An `EgressNetwork` spec may contain the following top level fields: | ||
|
|
||
| {{< keyval >}} | ||
|
|
||
| | field| value | | ||
| |------|-------| | ||
| | `networks`| A set of [network specifications](#networks) that describe the address space that this `EgressNetwork` captures | | ||
| | `trafficPolicy`| the default [traffic policy](#trafficpolicy) for this resource. | | ||
| {{< /keyval >}} | ||
|
|
||
| ### networks | ||
|
|
||
| This field is used to concretely describe the set of outside networks that this | ||
| network captures. All traffic to these destinations will be considered as | ||
| flowing to this `EgressNetwork` and subject to its traffic policy. | ||
| If an `EgressNetwork` does not specify any `networks`, the `EgressNetwork` | ||
| captures the entire IP address space except for the in-cluster networks specified | ||
| by the `clusterNetworks` value provided when Linkerd was installed. | ||
|
|
||
| {{< keyval >}} | ||
|
|
||
| | field| value | | ||
| |------|-------| | ||
| | `cidr`| A subnet in CIDR notation.| | ||
| | `except`| A list of subnets in CIDR notation to exclude.| | ||
| {{< /keyval >}} | ||
|
|
||
| ### trafficPolicy | ||
|
|
||
| This field is required and must be either `Allow` or `Deny`. If `trafficPolicy` | ||
| is set to `Allow`, all traffic through this EgressNetwork will be let through | ||
| even if there is no explicit Gateway API Route that describes it. If | ||
| `trafficPolicy` is set to `Deny`, traffic through this `EgressNetwork` that | ||
| is not explicitly matched by a Route will be refused. | ||
|
|
||
| ## Example | ||
|
|
||
| Below is an example of an `EgressNetwork` resource that will block all external | ||
| traffic except HTTPS traffic to httpbin.org on port 443. The later is done via | ||
| an explicit TLSRoute. | ||
|
|
||
| ```yaml | ||
| apiVersion: policy.linkerd.io/v1alpha1 | ||
| kind: EgressNetwork | ||
| metadata: | ||
| namespace: linkerd-egress | ||
| name: all-egress-traffic | ||
| spec: | ||
| trafficPolicy: Deny | ||
| --- | ||
| apiVersion: gateway.networking.k8s.io/v1alpha2 | ||
| kind: TLSRoute | ||
| metadata: | ||
| name: tls-egress | ||
| namespace: linkerd-egress | ||
| spec: | ||
| hostnames: | ||
| - httpbin.org | ||
| parentRefs: | ||
| - name: all-egress-traffic | ||
| kind: EgressNetwork | ||
| group: policy.linkerd.io | ||
| namespace: linkerd-egress | ||
| port: 443 | ||
| rules: | ||
| - backendRefs: | ||
| - kind: EgressNetwork | ||
| group: policy.linkerd.io | ||
| name: all-egress-traffic | ||
| ``` |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.