✨ Add httpserver.Server and pkg/debug for pprof support

[clamoriniere]

The idea is to have an Http.Server as a manager.Runnable component
On which other components can register http.Handler.

The main benefice is to have only one http.Listener with multiples
http.Handler:

• Add new httpserver.Server Runnable component
• Add metrics handler registration function
• Add debug package with pprof Handler registration function

I saw a discussion on another PullRequest that seems to agree with this approach: #664 (comment)

[k8s-ci-robot]

Welcome @clamoriniere!

It looks like this is your first PR to kubernetes-sigs/controller-runtime 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/controller-runtime has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @clamoriniere. 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 /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

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.

[DirectXMan12]

We've thus far resisted a generic "http server" runnable, mainly because we didn't want to be responsible for generic HTTP serving in CR.

[clamoriniere]

Hi @DirectXMan12,
thanks for looking into this PR.

We've thus far resisted a generic "http server" runnable, mainly because we didn't want to be responsible for generic HTTP serving in CR.

I can update the PR to have the httpserver more conservative and allow to register/activate only internal CR handlers.
And allow the usage of "internal" CR handlers (like /metrics) with an external http.Server

What do you think?

[DirectXMan12]

It should totally be possible to use "internal" handlers (like /metrics) with an external HTTP server. That's something I'd like to see.

Unifying all internal handlers into a single HTTP server seems like it could be reasonable. We'd have to figure out if we want to allow people to put different things on different ports though (probably).

[gerred]

Is this something that should be handled at by CR rather than the end controller level level (re: different ports @DirectXMan12?) it seems like CR may be able to offer an http.Server interface that can be used by end controllers, but I'm not so certain about having CR actually be the thing that calls ListenAndServe in this case.

[DirectXMan12]

So, I think I'd like to see this, off the top of my head:

1. if you do nothing, you get sane defaults -- metrics, health, etc started & managed by CR for you
2. If you want, you can customize what port (ports?) they serve on. For compat reasons, we might have to make this separate ports
3. If you want to do anything more complicated, you have to manage your own HTTP server and call ListenAndServe yourself, but we expose the helpers to add things like /metrics and /healthz to those servers.

[DirectXMan12]

(so I think I'm agreeing with you, at least partially, @gerred)

[dbenque]

So, I think I'd like to see this, off the top of my head:

1. if you do nothing, you get sane defaults -- metrics, health, etc started & managed by CR for you
2. If you want, you can customize what port (ports?) they serve on. For compat reasons, we might have to make this separate ports
3. If you want to do anything more complicated, you have to manage your own HTTP server and call ListenAndServe yourself, but we expose the helpers to add things like /metrics and /healthz to those servers.

I would really like to see 3. Somehow I already achieve it by ManagerOptions.MetricsBindAddress = "0" and running my own server in a Runnable. But as CR continues to add features I would really love to be able to register handler of CR like /healthz to my own server.

[clamoriniere]

Thanks all for your comments.
I will work on it soon.

[alenkacz]

@clamoriniere are you still working on this or may I take over?

[clamoriniere]

@clamoriniere are you still working on this or may I take over?

Hi @alenkacz ,
Unfortunately, I will not able to work on it during the coming weeks. So if you have time to take over feel free to do it :)

[alenkacz]

@DirectXMan12 I am working on this functionality and I was following the discussion here. We currently expose metricsExtraHandlers which is basically "server anything you want on the metrics server". Do we want to remove it? Because if we keep it, it's basically what this PR was doing...

[DirectXMan12]

@alenkacz yeah, I think we should deprecate that in favor of the piece of functionality described by bullet 3 above. I had completely forgotten that existed, thanks for the reminder :-P

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: clamoriniere
To complete the pull request process, please assign joelanford
You can assign the PR to them by writing /assign @joelanford in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[DirectXMan12]

closing as per #743 (comment)

[hectorj2f]

I know this issue got closed but I am wondering why pprof is not considered as a by default server to serve as part of controller-runtime. It'd be beneficial for everyone here, 1st for controller-runtime to keep track of the cpu.mem profiles and avoid potential regressions in that regard, and controller-runtime users to have that server available (or enabled=false) when needed on production.