fix(interceptor): clean up direct-pod routing TLS and defaults#1697
Open
Fedosin wants to merge 1 commit into
Open
fix(interceptor): clean up direct-pod routing TLS and defaults#1697Fedosin wants to merge 1 commit into
Fedosin wants to merge 1 commit into
Conversation
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
Fedosin
force-pushed
the
fix/direct-pod-routing-cleanup
branch
2 times, most recently
from
57e5eb5 to
533dbe5
Compare
Contributor
There was a problem hiding this comment.
Pull request overview
Follow-up changes to the interceptor’s direct-pod routing feature, focusing on TLS/SNI handling, default behavior, and clearer documentation around readiness broadcasts and dual-stack limitations.
Changes:
- Default
KEDA_HTTP_DIRECT_POD_ROUTINGtotruein interceptor serving config. - Simplify/adjust outbound TLS dialing by using
DialTLSContextand falling back to the dial address hostname when the context lacks an upstream server name. - Update comments/docs in
ReadyEndpointsCacheto reflect ready-state transition broadcasts and document dual-stack behavior limitations.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| pkg/k8s/ready_endpoints_cache.go | Clarifies notify channel broadcast semantics and documents dual-stack address-family pooling limitation. |
| interceptor/proxy.go | Removes dead TLS forwarding config and updates TLS dialer behavior for SNI selection/fallback. |
| interceptor/proxy_test.go | Updates the TLS dialer test to reflect fallback behavior (but needs stronger assertion coverage per stored comment). |
| interceptor/config/serving.go | Changes direct-pod routing env default to true and adjusts related config comments. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Fedosin
force-pushed
the
fix/direct-pod-routing-cleanup
branch
2 times, most recently
from
eca6f7a to
823dfa3
Compare
- Default DirectPodRouting to true (matching Knative behavior) - Remove dead forwardingTLSCfg/TLSClientConfig code superseded by DialTLSContext - Soften newTLSDialer to fall back to dial-address hostname when context has no server name, instead of hard-failing - Fix notifyCh comment to reflect actual broadcast semantics (ready-state transitions only, not every change) - Document dual-stack limitation in collectServiceState Signed-off-by: Mikhail Fedosin <mfedosin@redhat.com>
Fedosin
force-pushed
the
fix/direct-pod-routing-cleanup
branch
from
823dfa3 to
2d90dbc
Compare
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #1585: address remaining review feedback on the direct-pod routing feature.
KEDA_HTTP_DIRECT_POD_ROUTINGtotrue(matching Knative behavior)forwardingTLSCfg/TLSClientConfigcode that is superseded byDialTLSContextnewTLSDialerto fall back to the dial-address hostname when context has no server name, instead of hard-failingnotifyChcomment to reflect actual broadcast semantics (ready-state transitions only, not every change)collectServiceStateChecklist
README.md, keda-docs)Related to #1473