Show HN: Goldpinger – Visualize Kubernetes cluster connectivity | Hacker News Reader

Show HN: Goldpinger – Visualize Kubernetes cluster connectivity

github.com

158 pointsseeker8920 comments

Is there any rationale for running docker with sudo (assuing the non uid0 user is in the docker group)? https://github.com/bloomberg/goldpinger/blob/master/Makefile

Not really, but note that adding your user to the docker group is precisely identical to disabling sudo's password authentication for your user (adding users to the docker group gives a free privilege escalation from that user to root).

Now, that said, the Docker client does quite a few things (such as unpacking archives) that you might not want to be done as root. Especially if the client is running on a different machine.

is there any easy way to give each user their own docker runtime? I always thought it would be very useful, this way you can give all of your users the ability to easily run all the software they want.

Yes, but it'd currently require giving root access to your users. Rootless containers[1] is a project I started a while ago, and now (with some patches) you can run Docker (and Kubernetes) as an unprivileged user. There are some caveats, but I'd recommend checking it out.

[1]: https://github.com/rootless-containers

https://github.com/opencontainers/runc

As the other comment indicated, giving someone docker access is equivalent to giving them sudo. A lot of people are unaware of that, so some systems enforce sudo usage to make it clear.

Based on the simplicity of the build it's doing, there's basically no reason to invoke Docker to produce the image at all. You could use a tool like ko[0] to simply build the Go binary and place it on top of a base image (or keep it based on scratch) without requiring privileges at all, using `ko publish`.

[0] https://github.com/google/go-containerregistry/blob/master/c... [1] https://github.com/google/go-containerregistry/blob/master/c...

No, just a common scenario

+1 for the clever naming, got me grinning

thanks, gets me every time :D

Just wondering, other than the visualization - what other functionalities/use-cases does this differ from say node_exporter -> prometheus -> grafana?

This solves the reachability problem. In Kubernetes clusters, as well as traditional virtulaized data center setups, it is possible to encounter a network partition pretty easily. If your assertion is that all nodes and pods running on those nodes are mutually reachable then we need to make sure that’s the case. Pinger makes sure that is true!

Hmm, in the case of node_exporters, prometheus can be configured to pull metrics every X interval and if the target is down it can be alerted through that way too right?

Yes, but that just tests the connectivity prometheus -> node, which won't detect some network partitions, for example

I always wanted to visualize this as well ;)

Is the goal here visual debugging and management? Where I can simply click on a node to alleviate pressure / restart ?

Currently the goal is to 1) alert (via prometheus), 2) visualise to quickly troubleshoot a cluster.

There is no action built into goldpinger - but feel free to suggest what you had in mind via issues on github !

Love it! I have a similiar idea on my backlog, love to see that it's come to life. :D

That's the best feeling.

Backlogged issue resolved!

Sweet, glad we could help ! :D

Ok this is cool.

Reply on news.ycombinator.com