-
Notifications
You must be signed in to change notification settings - Fork 576
Add ambient mode caveats #3517
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
base: master
Are you sure you want to change the base?
Add ambient mode caveats #3517
Conversation
😊 Welcome @Stevenjin8! This is either your first contribution to the Istio api repo, or it's been You can learn more about the Istio working groups, Code of Conduct, and contribution guidelines Thanks for contributing! Courtesy of your friendly welcome wagon. |
@@ -174,6 +174,8 @@ message DestinationRule { | |||
|
|||
// One or more named sets that represent individual versions of a | |||
// service. Traffic policies can be overridden at subset level. | |||
// Note that subsets are not support in ambient mode. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not really true. Its not supported in HTTPRoute. Its supported in waypoints though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok I'm hearing contrasting things. It seems to me like most if not all of VirtualService works with waypoints. it's just alpha. So depending on who you ask, it might not be "supported." Where it gets tricky is when we start mixing Istio APIs and GWAPI. Like httproute and virtual service don't work together, and DR subsets aren't compatible with httproute.
Do most fields in VirtualService do what they say they do? Are there any fields that don't work?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Everything but sourceLabels and sourceVersion works.
Even ignoring VS, its not really that "subsets are not supported". At worst, there is no way to reference a subset in ambient. Which is maybe practically the same thing it just seems odd since you can absolutely create subsets in ambient
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@howardjohn are you saying that the following config wouldn't do anything?
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- match:
- headers:
end-user:
exact: jason
route:
- destination:
host: reviews
subset: v2
- route:
- destination:
host: reviews
subset: v3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also, do you mean sourceNamespace instead of sourceVersion?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sourceNamespace yeah sorry.
And that VS is 100% fine in ambient. What I meant was "At worst [if you exclude VirtualServices due to them being alpha], there is no way to reference a subset". if you include VS, subset is perfectly fine.
258c9b3
to
ca9ed35
Compare
ca9ed35
to
e3c5b91
Compare
* Remove subset notes * Add source_* notes
e3c5b91
to
9eefa13
Compare
no stale |
@@ -595,6 +598,9 @@ message ServiceEntry { | |||
// For a Kubernetes Service, the equivalent effect can be achieved by setting | |||
// the annotation "networking.istio.io/exportTo" to a comma-separated list | |||
// of namespace names. | |||
// | |||
// **Note:** Ambient mode does not support this field. Service entries will | |||
// be exported to all namespaces. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this the temporary limitation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, IIRC one of the big changes in ambient is that we want all workloads to have the same view of the mesh. So the same host corresponds to the same service/serviceentry regardless of the workload namespace
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM - these caveats are really important to call out. Thanks for doing this!
// *Note for Ambient Users*: Support for `VirtualService` in Ambient mode is alpha, and | ||
// there are no plans to increase support. | ||
// Use [Gateway API](https://istio.io/latest/docs/tasks/traffic-management/ingress/gateway-api/#mesh-traffic) | ||
// for a stable traffic management API. | ||
// |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// *Note for Ambient Users*: Support for `VirtualService` in Ambient mode is alpha, and | |
// there are no plans to increase support. | |
// Use [Gateway API](https://istio.io/latest/docs/tasks/traffic-management/ingress/gateway-api/#mesh-traffic) | |
// for a stable traffic management API. | |
// | |
// *Note for ambient mode users*: Waypoints are configured using Gateway API. [`VirtualService` is not supported for configuring waypoint traffic routing](https://istio.io/latest/docs/ambient/usage/l7-features/#virtualservice). | |
// Any use of VirtualService with waypoints is considered Alpha, and may be subject to change in future releases. | |
// Istio’s maintainers do not intend to remove this support, but will not be progressing it to [any further feature phase](https://istio.io/latest/docs/releases/feature-stages/). |
perhaps?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about
// *Note for ambient mode users*: Waypoints should be configured Gateway API and
// any use of [VirtualService with waypoints is alpha](https://istio.io/latest/docs/ambient/usage/l7-features/#virtualservice).
// Istio’s maintainers do not intend to remove virtual service support, but will not be progressing it to [any further feature phase](https://istio.io/latest/docs/releases/feature-stages/).
I think "waypoints are configured using gateway api" is confusing since it suggests that they can only be configured using gwapi.
Similarly "Alpha, and may be subject to change in future releases" suggests that support could become beta, or even unsupport, however "but will not be progressing it to" suggests that it will be alpha forever (which is what we want to say)
@@ -818,6 +823,8 @@ message HTTPMatchRequest { | |||
// | |||
// **Note:** This is not a runtime match, but is a selector; it filters which workloads the | |||
// VirtualService applies to. | |||
// | |||
// **Note:** Ambient mode does not support this field. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We say above that ambient mode doesn't support anything.
How about:
// **Note:** Ambient mode does not support this field. | |
// **Note:** This feature has no effect in ambient mode. |
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. "support" is ambiguous
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about // **Note:** This field has no effect on Waypoint proxies
... mm still doesn't feel too great.
@@ -464,6 +464,9 @@ message ServiceEntry { | |||
// 1. subjectAltNames: In addition to verifying the SANs of the | |||
// service accounts associated with the pods of the service, the | |||
// SANs specified here will also be verified. | |||
// | |||
// **NOTE 3:** Ambient mode does not support wildcard hostsnames. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// **NOTE 3:** Ambient mode does not support wildcard hostsnames. | |
// **NOTE 3:** Wildcard hostnames are not supported in ambient mode. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@craigbox I imagine we get into "this works for ingress but not ztunnel/waypoint" too right?
// **Note:** Ambient mode does not support this field. Service entries will | ||
// be exported to all namespaces. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// **Note:** Ambient mode does not support this field. Service entries will | |
// be exported to all namespaces. | |
// **Note:** In ambient mode, service entries are exported to all namespaces, | |
// and this field has no effect. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@craigbox same question about ingress
@@ -21,8 +21,9 @@ syntax = "proto3"; | |||
// $aliases: [/docs/reference/config/networking/v1alpha3/sidecar] | |||
|
|||
// `Sidecar` describes the configuration of the sidecar proxy that mediates |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// `Sidecar` describes the configuration of the sidecar proxy that mediates | |
// In Istio's sidecar mode, the `Sidecar` resource describes the configuration of the proxy that mediates |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and possibly a "Note 4" that says "Sidecar configuration is not required in ambient mode."?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Its required in sidecar mode either. Its more like, it has no effect in ambient mode
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I so wish that this object had been named "SidecarScope
" (and the same for legacy Gateway
as GatewayConfig
or something too)
// inbound and outbound communication to the workload instance it is attached to. By | ||
// default, Istio will program all sidecar proxies in the mesh with the | ||
// inbound and outbound communication to the workload instance it is attached to. | ||
// `Sidecar` only applies to Sidecar mode. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// `Sidecar` only applies to Sidecar mode. |
https://docs.google.com/document/d/1JjsPzOMJfu_evzgiRp-aJf1KDpa9ImyYrew__y5CTao/edit?tab=t.0#heading=h.8vlgwrna7yow for the broader terminology discussion |
Sidecar
,ServiceEntry.exportTo
andVirtualService.*.source_*
are not used at all. While ServiceEntry wildcard hostnames also aren't supported.