Feature request for a "hollow"-node-problem-detector having an empty list of conditions and rules inside kernel monitor config

[shyamjvs]

As part of the effort to make testing using kubemark mimic real clusters as closely as possible, we are planning to add container for a "hollow-node-problem-detector" inside hollow-node alongside the existing containers "hollow-kubelet" and "hollow-kubeproxy". For this, it is required to have a node-problem-detector image which essentially has conditions and rules inside the kernel monitoring config set to an empty list. Also, this image should eventually (once it is tested to work fine in Kubemark) be pushed to gcr.io/google-containers.

@kubernetes/sig-scalability @wojtek-t @gmarek @Random-Liu

[Random-Liu]

Make a NPD with node rules and conditions set SGTM.

However, I would suggest to use a ConfigMap to overwrite the configuration of NPD instead of creating another image http://kubernetes.io/docs/admin/node-problem/#overwrite-the-configuration.

@shyamjvs WDYT?

[shyamjvs]

Yes, that sounds great @lantaol. Making a new NPD image would just be an overkill. Thanks!

…

On Thu, Dec 15, 2016 at 7:45 PM Lantao Liu ***@***.***> wrote: Make a NPD with node rules and conditions set SGTM. However, I would suggest to use a ConfigMap to overwrite the configuration of NPD instead of creating another image http://kubernetes.io/docs/admin/node-problem/#overwrite-the-configuration. @shyamjvs <https://github.com/shyamjvs> WDYT? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#50 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEIhkyWnhb4uczvoIO8e3xVPRa_k9CvUks5rIYq3gaJpZM4LOKdd> .

[shyamjvs]

Ref kubernetes/kubernetes#39245
@Random-Liu What would be the easiest way to achieve this (i.e. make the apiserver IP address that the NPD talks to, overridable through a flag)?
Also, IIUC this should involve building a new docker image for NPD and uploading it to "gcr.io/google_containers/node-problem-detector:v0.2" in such a way that this won't affect other places where NPD is already in use. Esentially, this new image should be able to (optionally) take a flag at the entrypoint of NPD for the apiserver's IP address (which can be made available through an env var using configMap).

[wojtek-t]

@shyamjvs - I don't understand your question. You need to introduce a flag, and build the client based on the value of this flag (if unset, use InClusterConfig, otherwise, use address from the flag). What is your question?

Regarding image - we should NEVER change the image. We already have v0.2 so we should built v0.3 and update all references to the new image.

[shyamjvs]

@wojtek-t I was confirming if overriding the apiserver IP address through a flag indeed the easiest option. But I found out a better solution that does't require us to touch any NPD code or image (described it in comments on kubernetes/kubernetes/issue#39245).

And regarding the last line of my previous comment, I meant that as part of adding this new flag we need to also pass it in the entrypoint of the NPD image (inside the Dockerfile https://github.com/kubernetes/node-problem-detector/blob/master/Dockerfile#L19) because we do not explicitly start the container using a command inside the manifest. And the value of the flag itself has to be passed to the container through an env var using the NPD configMap.

[shyamjvs]

Continuing further discussion about this issue on kubernetes/kubernetes/issue#39245 to avoid confusion between both threads.
We can continue the discussion here if and when we plan to change code in this repo.

[gmarek]

Good to know! Do you have any estimate on when #49 might land?

…

On Thu, Jan 5, 2017 at 11:06 AM, Lantao Liu ***@***.***> wrote: Sorry for the delay. I was on vocation and just come back today. There is an on-going effort by @andyxning <https://github.com/andyxning> to directly reuse the heapster code in NPD. #49 <#49> After this is merged, we should be able to use the same flag with heapster to config the master. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#50 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABn_ogfoU9xxK_gR66tWh8buD-weeSSOks5rPT8bgaJpZM4LOKdd> .

[Random-Liu]

@gmarek I'll do another review today, and I hope it will be in this or next week.