Serve diagnostic endpoints independently of the k8s exporter

[css521]

/kind bug

What this PR does / why we need it:

/healthz, /conditions and /debug/pprof were registered inside k8sexporter.NewExporterOrDie, which returns early when --enable-k8s-exporter=false. Running NPD outside a cluster — where that flag is what avoids a panic at startup — therefore lost all three endpoints even with --port set, while --prometheus-port kept working because the Prometheus exporter starts its own server.

README already documents --port as "The port to bind the node problem detector server. Use 0 to disable.", so this makes the implementation match the flag it is documented under.

This PR moves the server to pkg/httpserver, started from npdMain next to the Prometheus exporter it mirrors, controlled by --port alone.

Which issue(s) this PR fixes:

Fixes #1332

Special notes for your reviewer:

• Where the conditions come from. The Kubernetes exporter still owns them; it now exposes GetConditions() and satisfies the optional httpserver.ConditionsGetter interface, which npdMain passes to the server when that exporter is enabled. That keeps the condition manager private to the exporter and avoids handing the HTTP server a Kubernetes dependency it otherwise does not need.
• /conditions with the exporter disabled. It serves no conditions rather than 404, so the endpoint's presence does not depend on the flag. The body is byte-identical to what an enabled exporter returns before it has recorded any condition (null, from util.ReturnHTTPJson on a nil slice), so no client can tell the two apart by parsing — there is a test pinning exactly that. Happy to switch it to 404 or an explicit empty array if you would rather the two be distinguishable.
• Not fixed here. The startup panic that makes --enable-k8s-exporter=false necessary in the first place is untouched; this only stops that flag from taking the diagnostic endpoints down with it.

Verification — ran the issue's reproduction against both binaries, --enable-k8s-exporter=false --port=20256 --prometheus-port=20257 --config.custom-plugin-monitor=config/custom-plugin-monitor.json:

endpoint	before	after
:20256/healthz	connection refused	200 ok
:20256/conditions	connection refused	200 null
:20256/debug/pprof/cmdline	connection refused	200
:20257/metrics	200	200

go build ./..., go vet and the tests for the touched packages are clean. One pre-existing note: gofmt -l ./cmd reports node_problem_detector_test.go on unmodified master as well, so I left it alone rather than mixing a reformat into this change.

Does this PR introduce a user-facing change?:

The `/healthz`, `/conditions` and `/debug/pprof` endpoints on `--port` are now served regardless of `--enable-k8s-exporter`. With the Kubernetes exporter disabled, `/conditions` reports no conditions.

[kubernetes-prow]

Welcome @css521!

It looks like this is your first PR to kubernetes/node-problem-detector 🎉. 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/node-problem-detector 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. 😃

[kubernetes-prow]

Hi @css521. Thanks for your PR.

I'm waiting for a kubernetes 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.

Details

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-sigs/prow repository.

[kubernetes-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: css521
Once this PR has been reviewed and has the lgtm label, please assign hakman for approval. For more information see the Code Review Process.

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

Details

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