Comments (7)
I have some questions about how we need to handle hostname for E/W traffic; I'm not sure that field makes total sense in a mesh context.
Drive by comment from an Istio developer (speaking without consensus from Istio community) - IMO it should work like this:
A Route is bound to a Service (TODO how exactly this fits in the API). What this means is "All requests to this Service should use this route". This should be identified by the Service IP.
Once we have a route selected, we follow the standard route matching. For HTTP hostname
, that means we can match additional Host
headers. For example,
kind: HTTPRoute
parentRef:
- Service foo # TODO on syntax
hostname: [bar.com]
...
This would mean curl foo
would get a 404, and curl foo -H "Host: bar.com"
would match.
Similar applies to SNI for TLSRoute.
Note that this means that using Hostname with mesh would likely be pretty rare. It could maybe be useful for a service like, say, nginx that is doing its own vhost routing so you would call it with different Host headers, but definitely an exception.
This is not what Istio is doing here, but I want to change it. Today Istio doesn't do any IP matching at all for HTTP, so everything is host header based. This has caused various issues described in https://docs.google.com/document/d/1NAccj8WyjBXOUsMdOHW9sWW6PeCnrIWpc3muBHd4Cs8/.
from smi-spec.
Yeah and on top of all of that, we need to make sure our solution handles the Gateway -> Mesh case smoothly. What does it look like for an HTTPRoute that has a parentRef of Gateway and a backendRef to service A and another HTTPRoute with a parentRef of Service A? Do we allow nested traffic splitting, one policy at ingress and then another policy at the mesh level?
Lots of fun questions to tackle 😄
from smi-spec.
For the proposed switch to HTTPRoute
, it was discussed in last community meeting how the owner of a service should be configuring an HTTPRoute
to allow incoming connections - we should clarify how the parentRefs
and backendRefs
fields would be used, as this is a bit of the inverse of how HTTPRoute
is used in the Gateway API, where routes bind to a Gateway
with a parentRef
, and require a ReferencePolicy
for a backendRef
to direct traffic to a service in a different namespace.
Multiple backendRefs
can be defined on an HTTPRouteRule
, and each backendRef
includes a weight which could be used for balancing traffic e.g. between v1 and v2 k8s services of a single logical service (this could point to separate IdentityBinding
objects if we don't want to introduce weighting within the IdentityBinding
?)
An HTTPRoute can also define multiple parentRefs
, which I think would offer sufficient granularity to be used to allow traffic from, e.g. { kind: IdentityBinding, name: fooBinding, namespace: api }
or simply from a specific namespace.
We've focused mostly on HTTPRoute
for directing L7 traffic, would we also want TCPRoute for L4 traffic, or just use the default behavior of and HTTPRoute
routing all traffic when the scope is not narrowed with an HTTPRouteMatch
?
from smi-spec.
I have some questions about how we need to handle hostname
for E/W traffic; I'm not sure that field makes total sense in a mesh context.
Additionally, I'm currently of the opinion that parentRef
should only be a reference to the mesh and that identity shouldn't come into play here. In other words, I think traffic routing (HTTPRoute
) and traffic policy (TrafficTarget
) should stay separate
from smi-spec.
I never thought about binding the route to service, but the more I think about it, the more it makes sense... I also agree that too much reliance on host headers likely leads to an inconsistent experience for users. SMI still has yet to answer the question "what is a service" in the spec, and the future parentRef API implementation may give us that.
The natural question though is how to handle headless services, but I imagine we could develop a consistent spec for how mesh implementations should translate the headless service to its endpoint IPs for matching purposes.
from smi-spec.
I only mentioned Service, but I think binding to "workload"/Pod also makes sense. For example, I could want to apply some route to all requests to a specific pod (again, matched by IP). Now no one really wants to select a single Pod probably, but there are ways to group pods (Headless service is a great example, or even something that says "Workloads of this Service" or some of the higher constructs like Deployment, etc. Or a custom type - lot of options).
FWIW Today Istio doesn't even really handle traffic directly to pods (except in headless service, and even then pretty poorly), so all of this is pretty aspirational from our perspective.
from smi-spec.
BTW @nicholasjackson the issue title has a wording error; it should start with “Deprecation”.
from smi-spec.
Related Issues (20)
- when to validate traffic target
- `Matches` in `TrafficSplit` is unclear HOT 12
- Add the (required) `apiVersion` field to all YAML file examples HOT 1
- Clarify behavior of overlapping rules and routing resolution in TrafficSplit HOT 1
- Support API/Interface
- Support Exact and Prefix matches for URI path in HTTPRouteGroup
- The Header Match format in HTTPRouteGroup description is not consistent with smi-sdk-go HOT 2
- TrafficTarget should be created in same namespace as destination
- No warning if incorrect yaml is applied for Traffic Split HOT 1
- Logical relationships between multiple match condition in TrafficSplit resource HOT 1
- Trafficsplit based on sourcelabel? HOT 3
- CRD installation HOT 1
- support queryParams in TrafficSpec HOT 1
- Question about A/B testing with traffic splits HOT 1
- Does the TrafficSplit spec allow for identification of a default route for unmatched traffic? HOT 3
- Question: Header-based TrafficSplit
- Any plans for mirroring?
- State of SMI Spec HOT 6
- CNCF TOC annual review due HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from smi-spec.