-
Notifications
You must be signed in to change notification settings - Fork 37
docs: Add Envoy Gateway install section #891
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: main
Are you sure you want to change the base?
Conversation
|
Skipping CI for Draft Pull Request. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: kahirokunn The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #891 +/- ##
=======================================
Coverage 76.45% 76.45%
=======================================
Files 17 17
Lines 1253 1253
=======================================
Hits 958 958
Misses 261 261
Partials 34 34 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
59762e0 to
5f6b8e6
Compare
5f6b8e6 to
f1ff035
Compare
|
@dprotaso Hello! I'd be grateful if you could leave a review when you have a moment! 🙏 |
Signed-off-by: kahirokunn <[email protected]>
f1ff035 to
e71dfc9
Compare
test/e2e-common.sh
Outdated
| function setup_envoy_gateway() { | ||
| kubectl apply --server-side -f https://github.com/envoyproxy/gateway/releases/download/${ENVOY_GATEWAY_VERSION}/install.yaml | ||
| # Install Envoy Gateway via Helm with GatewayNamespace deployment to align Service namespaces | ||
| helm repo add envoyproxy https://charts.envoyproxy.io |
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 there a way to do this without helm?
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.
| - class: eg-external | ||
| gateway: eg-external/eg-external | ||
| service: envoy-gateway-system/knative-external | ||
| service: eg-external/knative-external |
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 interesting - did they change where services are created?
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.
Envoy Gateway now has a new feature where it creates Services and Deployments in the Gateway resource's Namespace and assigns OwnerReferences.
This is the same implementation as many other Gateway controllers.
To utilize this, the following values are required:
third_party/envoy-gateway/helm/values-eg.yaml
I believe that using the GatewayNamespace is the best configuration, so I used Helm this time. What are your thoughts on this, @dprotaso ?
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.
Sorry was at kubecon back now.
I'm wondering if we can keep the old installation and just remove the explicit overrides we have in EnvoyProxy etc in the external.yaml and internal.yaml file
| namespace: envoy-gateway-system |
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 recall before that the name of the svc and namespace wasn't predictable
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.
Though if we do that change then it might break upgrades which makes everything more complex.
Actually checking now we don't release the envoy yamls as part of the release so maybe we're ok in terms of what backwards compatibility we support.
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.
Glad to hear you were at KubeCon. I heard there were many exciting announcements this year, so I’m honestly a bit jealous you could attend.
With the namespaces separated in this way, the names of the created Services (and related resources) become fully predictable. Since we are not currently publishing the Envoy YAMLs as part of the official release artifacts, my feeling is that it would be better for the community if we focus less on backward compatibility here and instead present a clear best-practice configuration from the start.
What do you think about taking this approach?
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.
if we focus less on backward compatibility here and instead present a clear best-practice configuration from the start.
Yeah I'm good with that approach
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.
Can we still drop helm and just apply the single yaml file :P
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.
@dprotaso
I've completed it. Cloud you review again? 🙏
Co-authored-by: Dave Protasowski <[email protected]>
17592b6 to
9e4c1e1
Compare
Signed-off-by: kahirokunn <[email protected]>
9e4c1e1 to
62bf6e7
Compare
Changes
README/kind documentation
Fixes #
Release Note
Docs