Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

outbound: Introduce 'ingress mode' #728

Merged
merged 11 commits into from
Oct 26, 2020
Merged

outbound: Introduce 'ingress mode' #728

merged 11 commits into from
Oct 26, 2020

Conversation

olix0r
Copy link
Member

@olix0r olix0r commented Oct 23, 2020

When the LINKERD2_PROXY_INGRESS_MODE environment variable is set to
true, the outbound proxy alters its discovery behavior as follows:

  • All outbound traffic is assumed to be HTTP traffic or unmeshed opaque
    TCP traffic. Discovery, routing, balancing, and mTLS is only applied
    for outbound THTTP traffic.
  • The l5d-dst-override request header is used to specify the target
    authority.
  • If the header is not present, the original dst address is used.
  • Service profiles, traffic split, and balancing are only applied when
    the header is present or when the original dst addr refers to a service
    address (and not a pod address).

linkerd/app/outbound/src/ingress.rs Outdated Show resolved Hide resolved
linkerd/app/src/lib.rs Show resolved Hide resolved
},
} = config.clone();

let http = svc::stack(http)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't looked closely yet but it feels like there's probably some common code between the ingress-mode and normal mode http stacks that we might want to share. nbd if not, but adding more places that future changes will have to update always worries me a little bit...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, but deduping things is easier said than done. If you can get it working, I'll merge it ;)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i'm not sure if it makes sense here or not, but i can take a look.

When the LINKERD2_PROXY_INGRESS_MODE environment variable is set to
`true`, the outbound proxy alters its discovery behavior as follows:

* All outbound traffic is assumed to be HTTP traffic or unmeshed opaque
  TCP traffic. Discovery, routing, balancing, and mTLS is only applied
  for outbound THTTP traffic.
* The `l5d-dst-override` request header is used to specify the target
  authority.
* If the header is not present, the original dst address is used.
* Service profiles, traffic split, and balancing are only applied when
  the header is present or when the original dst addr refers to a service
  address (and not a pod address).
@olix0r olix0r changed the title Ver/ingress outbound outbound: Introduce 'ingress mode' Oct 26, 2020
@olix0r olix0r marked this pull request as ready for review October 26, 2020 14:53
@olix0r olix0r requested a review from a team October 26, 2020 14:53
Copy link
Contributor

@hawkw hawkw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this seems good to me!

i'd like to figure out if we could factor out some of the repeated code between the ingress and non-ingress stacks but it's definitely not a blocker, and we can come back and clean it up later. other than that, just some minor style nits you can feel free to ignore.

it would also be good to have some tests for the ingress mode behavior, as well, but that can also land in a follow-up.

Comment on lines +162 to +163
pub fn from_logical(reason: tls::ReasonForNoPeerName) -> impl (Fn(Logical<P>) -> Self) + Clone {
move |logical| Self {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

image

Comment on lines +43 to +46
// In "ingress mode", we assume we are always routing HTTP requests and do
// not perform per-target-address discovery. Non-HTTP connections are
// forwarded without discovery/routing/mTLS.
pub ingress_mode: bool,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

very nitpicky: shouldn't this go on the outbound config, or do we intend to change inbound behavior based on ingress mode as well? what would we do differently on inbound? my guess is most/all inbound traffic to an ingress is just gonna be metrics scrapes, readiness probes, and similar...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this was put here intentionally because we may opt to change inbound behavior in the future; and, more importantly, nothing in the outbound crate needs to be aware of this flag currently.

linkerd/app/src/lib.rs Outdated Show resolved Hide resolved
fn recognize(&self, req: &http::Request<B>) -> Self::Key {
Target {
accept: self.0,
dst: http_request_l5d_override_dst_addr(req).unwrap_or_else(|_| self.0.orig_dst.into()),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit/TIOLI: it might be worth having a debug event indicating whether or not we saw the override header, or something, since this is kinda load-bearing?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should be pretty obvious based on the resulting target, which is ends up in span metadata

@olix0r olix0r merged commit 4b48dbd into main Oct 26, 2020
@olix0r olix0r deleted the ver/ingress-outbound branch October 26, 2020 17:48
olix0r added a commit to linkerd/linkerd2 that referenced this pull request Oct 26, 2020
This release adds an 'ingress mode' to support per-request routing for
HTTP ingresses.

Additionally, the performance impact of logging should be reduced when
the proxy log level is not set to `debug` or `trace`.

---

* router: Use NewService instead of MakeService (linkerd/linkerd2-proxy#724)
* outbound: Split TCP stack into dedicated modules (linkerd/linkerd2-proxy#725)
* trace: update `tracing-subscriber` to 0.2.14 (linkerd/linkerd2-proxy#726)
* outbound: Extract HTTP and server modules (linkerd/linkerd2-proxy#727)
* outbound: Introduce 'ingress mode' (linkerd/linkerd2-proxy#728)
* Reduce tracing spans to the debug level (linkerd/linkerd2-proxy#730)
olix0r added a commit to linkerd/linkerd2 that referenced this pull request Oct 26, 2020
This release adds an 'ingress mode' to support per-request routing for
HTTP ingresses.

Additionally, the performance impact of logging should be reduced,
especially when the proxy log level is not set to `debug` or `trace`.

---

* router: Use NewService instead of MakeService (linkerd/linkerd2-proxy#724)
* outbound: Split TCP stack into dedicated modules (linkerd/linkerd2-proxy#725)
* trace: update `tracing-subscriber` to 0.2.14 (linkerd/linkerd2-proxy#726)
* outbound: Extract HTTP and server modules (linkerd/linkerd2-proxy#727)
* outbound: Introduce 'ingress mode' (linkerd/linkerd2-proxy#728)
* Reduce tracing spans to the debug level (linkerd/linkerd2-proxy#730)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants