-
Notifications
You must be signed in to change notification settings - Fork 215
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(healthchecks): Adding Agent Health Checks for legacy & hubble control planes #1092
base: main
Are you sure you want to change the base?
Conversation
Co-authored-by: Timothy J. Raymond <[email protected]> Signed-off-by: Mereta <[email protected]>
deploy/hubble/manifests/controller/helm/retina/templates/agent/daemonset.yaml
Show resolved
Hide resolved
@@ -86,6 +86,7 @@ daemonset: | |||
metricsBindAddress: ":18080" | |||
ports: | |||
containerPort: 10093 | |||
healthPort: 18081 |
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.
Why create a new port? and not reuse the existing 10093 ? since we are a hostnet: true pod, any port number we use comes with restrictions as it takes away from nodes usable port ranges. In AKS, we will have to pre register the ports we will be using to make sure customers are also aware of the ports they should not use to avoid any conflict.
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 seems to be already configured in Legacy & Hubble control planes as default HealthProbeBindAddress.
Its always provided when we set up k8s controller runtime options.
Hubble:
retina/pkg/config/hubble_config_linux.go
Line 42 in 4b12472
HealthProbeBindAddress: ":18001", |
I think also @rbtr mentioned having a configurable port.
Do you think we should change to 10093?
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.
Ok I did some testing and got errors when using port 10093.
I don't think we can reuse the Retina port, some findings below:
We start a http api server with that port in controller manager:
// create HTTP server for API server |
And the trail for setting up health check is:
The HealthProbeBindAddress we pass as part of options in the ctrl manager ends up here where a listener is created.
comment:
This will throw an error if the bind address is invalid or already in use.
(same logic as providing pprof address below)
https://github.com/kubernetes-sigs/controller-runtime/blob/aea2e32a936584b06ae6f7992f856fe7292b0297/pkg/manager/manager.go#L407
If listener exists k8s tries to add HealthProbeServer:
https://github.com/kubernetes-sigs/controller-runtime/blob/aea2e32a936584b06ae6f7992f856fe7292b0297/pkg/manager/internal.go#L400
addHealthProverServer() definition - creates a new server:
https://github.com/kubernetes-sigs/controller-runtime/blob/aea2e32a936584b06ae6f7992f856fe7292b0297/pkg/manager/internal.go#L290
Description
Using Kubernetes api health check with a custom example.
Related Issue
#1047
Checklist
git commit -S -s ...
). See this documentation on signing commits.Screenshots (if applicable) or Testing Completed
Testing was completed manually for legacy & hubble control planes.
Windows image tested with legacy retina, hubble retina N/A.
Additional Notes
Add any additional notes or context about the pull request here.
Please refer to the CONTRIBUTING.md file for more information on how to contribute to this project.