-
Notifications
You must be signed in to change notification settings - Fork 578
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
✨ Feat: ELBv2/TGs - Add health check customization #4849
✨ Feat: ELBv2/TGs - Add health check customization #4849
Conversation
Hi @mtulio. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
fwiw @vincepri @patrickdillon @r4f4 |
cf16eea
to
6063882
Compare
The provision of API and additional listeners are working as expected, I am investigating unit failures for fuzzy test [1] e2e deployment w/ custom target health check [2] fuzzy test failures
|
6063882
to
7f36dc3
Compare
7f36dc3
to
75c2074
Compare
75c2074
to
36a6ef8
Compare
/lgtm as well |
@richardcase would you mind taking a look in this proposal, please? |
/test pull-cluster-api-provider-aws-e2e |
Thanks for this @mtulio . Once both the e2e passes we can unhold /hold From my side this looks good, so: /approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: richardcase The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Timed out, retrying in case its a flake: /test pull-cluster-api-provider-aws-e2e |
Yet another time out with GPU instances... /test pull-cluster-api-provider-aws-e2e |
@nrb is there a bug/issue for the GPU tests? |
Not specifically yet, just #4937 and #4783 (comment) |
@richardcase @nrb e2e* are now passing. 🎉 |
/unhold |
Add tests to validate optional health check override for all ELBv2 instances and it's listeners (api and additionals).
Some deployments requires customizations in the health check configurations, such as protocol, probe periods and checks. This change introduce health check override for all Load Balancers and listeners (API and additional). The override for the API target group are limited to the probe configuration, and customizing the Path, Port and Protocol for the Target Group for the Kube API Server is not allowed.
Expose the target health check attributes/API allowing customizations for both API (default from LB), and additional listeners, for each Load Balancer. Considering the risk of wrong configurations, the The customization for the target group attributes of API listener is limited to the health check probe configurations (interval, timeout, threshold, etc). The health check for the additional listeners can be customized, including health check protocol, port, path, etc
@mtulio seems like the same problem here: needs a rebase on top of master. |
97489d2
to
5b2dabf
Compare
Rebased to fix codegen issue |
@nrb passing now. Would you mind to res-stamp lgtm cleaned after rebase? Thanks :) |
/lgtm |
What type of PR is this?
/kind feature
/kind api-change
What this PR does / why we need it:
This change exposes the health check configuration for listeners of both load balancers, primary and secondary. When the target group is created for the API, the user will be able to customize only the health check probes, according to the limit ranges allowed by AWS.
It will allow providers to customize the API and additional listeners' target health checks to ensure existing implementations.
A significant improvement will be in the additional listeners which is currently set with basic health checks following the same protocol of the listener (TCP). Exposing this value will allow customized health check.
The example below shows how we are using to customize the API target group (from the default provided by CAPA), alongside setting custom health check parameters for additional listeners, like overriding the protocol to
HTTPS
, check path/healthz
, setting custom probe timers:This PR is creating dedicated the health check structures, a more restricted one to API and field-free for additional listeners, protecting to expose the API target group for both load balancers when changing standardized fields like protocol, port and path..
Which issue(s) this PR fixes:
Fixes #4884
Special notes for your reviewer:
Checklist:
Release note: