networking
networking copied to clipboard
Add system-internal-tls-allow-serve-mode configuration option
Hi,
related serving PR: https://github.com/knative/serving/pull/16183
this PR adds a new configuration field to allow Serve mode when system-internal-tls is enabled. By default, enabling system-internal-tls forces all traffic to use Proxy mode because not all Knative ingress implementations support Serve mode with TLS enabled.
The new system-internal-tls-allow-serve-mode option allows users to enable Serve mode when their ingress implementation supports direct TLS connections to application containers.
Configuration:
- Default: Disabled (forces Proxy mode for compatibility, current behavior)
- Enabled: Allows Serve mode even with TLS enabled
I added the option to the network config as it makes IMO sense to put it close to the relevant system-internal-tls option, even if the effect is not really related to it.
Changes
- :gift: Allow enabling Serve mode when using system-internal-tls (alpha)
/kind enhancement
Release Note
Allow enabling Serve mode when using system-internal-tls (alpha)
- Adds a new configuration option `system-internal-tls-allow-serve-mode` to allow
Serve mode when system-internal-tls is enabled. This is useful for ingress
implementations that support direct TLS connections to application containers (e.g. kourier or istio).
- This is an alpha feature. Only enable if your ingress implementation
supports Serve mode with TLS.
Questions:
- Do we want/need to stage this flag starting as alpha right now?
- Is a release note in this PR something we want do for a) config options and b) alpha options?
- Config option name is maybe a bit lengthy, let me know if I should improve this (possibly with suggestions).
Docs
Thanks for the feedback!
/cc @Fedosin
Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all
Codecov Report
:white_check_mark: All modified and coverable lines are covered by tests.
:white_check_mark: Project coverage is 93.16%. Comparing base (0bde191) to head (94883fd).
:warning: Report is 1 commits behind head on main.
Additional details and impacted files
@@ Coverage Diff @@
## main #1093 +/- ##
==========================================
+ Coverage 93.14% 93.16% +0.02%
==========================================
Files 36 36
Lines 1255 1259 +4
==========================================
+ Hits 1169 1173 +4
Misses 72 72
Partials 14 14
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
:rocket: New features to boost your workflow:
- :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
Hey! Thanks for the work you've done. The code is good, so I'm happy to put LGTM when you are ready.
Wrt your questions:
Do we want/need to stage this flag starting as alpha right now?
I think so, yes. The feature enables a potentially breaking behavior change for users whose ingress implementations don't support Serve mode with TLS, so this should be marked as alpha.
Is a release note in this PR something we want do for a) config options and b) alpha options?
For config options - yes, as release notes are valuable as they help users discover new configuration capabilities. For alpha options - also yes, but clearly mark as alpha/experimental.
AI suggested this release note:
Allow enabling Serve mode when using system-internal-tls (alpha)
Adds a new configuration option `system-internal-tls-allow-serve-mode` to allow
Serve mode when system-internal-tls is enabled. This is useful for ingress
implementations that support direct TLS connections to application containers.
Note: This is an alpha feature. Only enable if your ingress implementation
supports Serve mode with TLS.
Config option name is maybe a bit lengthy, let me know if I should improve this (possibly with suggestions).
Imo, it's okay. If we really need something shorter, it can be allow-serve-mode-with-tls
Thanks for the review, I updated the PR description and the other related PR.
/remove-approve - was added automatically as I'm co-release lead.
[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: Once this PR has been reviewed and has the lgtm label, please assign dprotaso for approval. For more information see the Code Review Process.
The full list of commands accepted by this bot can be found here.
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment
/check-cla
Could you please take a look @dprotaso ?