-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
clarify ambient mode installation required for dns-proxy #16230
Conversation
😊 Welcome! This is either your first contribution to the Istio documentation repo, or
Thanks for contributing! Courtesy of your friendly welcome wagon. |
Signed-off-by: ilrudie <[email protected]>
97c0466
to
c2a97ec
Compare
{{< tip >}} | ||
When using the ambient data plane in Istio 1.24 or earlier, DNS Capture is not enabled by default. To enable DNS Capture for ambient set `values.cni.ambient.dnsCapture=true` during installation. | ||
{{< /tip >}} | ||
|
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.
It says "This isn't enabled by default, here's how you enable it"
and now has a tip that says "this isn't enabled by default in 1.24 or earlier in ambient mode"
(a) is this now on by default for everyone in 1.25? or only for ambient mode?
(b) can we reformat the instructions to say "Sidecar mode enablement", "Ambient mode enablement" etc
(c) can the sidecar mode enablement be as simple as the ambient mode enablement?
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.
(a) In 1.25 the cni dns redirect is enabled in the ambient profile as well as the auto-ip controller. IIRC the ztunnel dns proxy just always runs but whether or not it is used depends on the cni redirection. TL;DR These instructions are basically irrelevant for ambient SE functionality in 1.25 ambient.
(b) Maybe, I'm not sure how to do that exactly. Can we get /some/ useful tip up so users don't continue to struggle and take on a wider refresh as a follow up? See above re: whether or not special ambient instructions might be helpful. Maybe we just add a disclaimer/note/section/tip/? at the top that this page isn't really relevant for ambient 1.25+ instead?
(c) For HTTP traffic sidecar sort of already is as easy as ambient 1.25+. We read the headers and can route accordingly. This becomes critical path for some basic Istio functionality in Ambient though when we can't just read headers in ztunnel to figure it out which is why we enable out of the box for Ambient but not for Sidecar (at the moment)
I've made some very presumptuous changes to your PR. Please have a look and see if you're happy with them. (It did involve renaming some headings, so I've had to update the tests too.) I've also learned I did not know how to spell "presumptuous". |
|
||
While Kubernetes provides DNS resolution for Kubernetes `Service`s out of the box, any custom `ServiceEntry`s will not be recognized. With this feature, `ServiceEntry` addresses can be resolved without requiring custom configuration of a DNS server. For Kubernetes `Service`s, the DNS response will be the same, but with reduced load on `kube-dns` and increased performance. | ||
|
||
This functionality is also available for services running outside of Kubernetes. This means that all internal services can be resolved without clunky workarounds to expose Kubernetes DNS entries outside of the cluster. | ||
|
||
## Getting started | ||
|
||
In sidecar mode, all traffic passes through Layer 7 processing, and the `hosts` of a `ServiceEntry` can be matched to a HTTP header without requiring the use of DNS. In ambient mode, the ztunnel only sees traffic at Layer 4, and does not have access to HTTP headers. Therefore, DNS proxying is required to enable resolution of `ServiceEntry` addresses, especially in the case of [sending egress traffic to waypoints](https://github.com/istio/istio/wiki/Troubleshooting-Istio-Ambient#scenario-ztunnel-is-not-sending-egress-traffic-to-waypoints). |
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 think this is fine but to nit pick a little:
Technically sidecars have DNS proxy capability because not all traffic is suitable for this form of routing and that is perhaps unclear in this paragraph. We could consider adding "If routing based on HTTP header is not possible (TCP traffic for instance), DNS proxy can be enabled." or something to this effect but written more clearly.
I think what you wrote is generally a nice improvement over what I had written. I left a possible alteration idea but I'm not convinced it's actually and improvement so much as its, "technically a bit more correct". |
content/en/docs/ops/configuration/traffic-management/dns-proxy/index.md
Outdated
Show resolved
Hide resolved
…/index.md Co-authored-by: Craig Box <[email protected]>
content/en/docs/ops/configuration/traffic-management/dns-proxy/index.md
Outdated
Show resolved
Hide resolved
In response to a cherrypick label: cannot checkout |
In response to a cherrypick label: #16230 failed to apply on top of branch "release-1.24":
|
In response to a cherrypick label: new issue created for failed cherrypick: #16253 |
Description
Reviewers