If you'll forgive a bit of shaking-fist-at-clouds...<p>> Role-aware UI<p>> One problem with many read-write (CRUD) user interfaces is that they are not aware of underlying access controls. For example, displaying the update/delete buttons is misleading if the user has actually no permissions to modify the resource. So Headlamp checks Kubernetes RBAC settings and displays only those controls whose actions can be performed. So, if the user does not have permission to edit a resource, the edit button will not be displayed.<p>> This results in a much better UX, because it is obvious to the operator what actions are available based on their permissions at the time.<p>I strongly disagree. It's quite the opposite, in fact. Hiding UI based on permissions creates an infuriating UX, because there's no way for the operator to tell what actions are possible-but-forbidden, and those they simply can't find in the interface.<p>Click Edit -> "Access denied" -> Ah, I need to ask my admin for additional permissions<p>No Edit button at all -> Where the f... -> Ah, this software sucks<p>Of course, this is not to say the the underlying idea is bad. By all means, check the user's permissions proactively and <i>disable</i> the buttons (with explanation of why the button is disabled). And this is very much a case-by-case thing: it would obviously be silly for Amazon product pages to show everyone a disabled edit button.<p>But please, if you're designing administrative software for power users, don't dumb it down.
I’m very new to k8s, so forgive me if this is a silly question, but how is this different than Lens [0]?<p>One of the first tools I was told to download by a k8s expert friend of mine was Lens, and it has made the experience of learning about clusters, nodes, and pods much easier.<p>Headlamp looks remarkably similar.<p>[0] <a href="https://k8slens.dev/" rel="nofollow">https://k8slens.dev/</a>
> <i>So, if the user does not have permission to edit a resource, the edit button will not be displayed. This results in a much better UX, because it is obvious to the operator what actions are available based on their permissions at the time.</i><p>This results in much <i>worse</i> UX, as the user is oblivious to what actions are unavailable due to their permissions!<p>Back a little over 20 years ago, we would just grey out the button, to indicate that it was "disabled". (I'd also add that I think hovering over such UI ought to offer an explanation as to <i>why</i> that particular action is unavailable, and possibly, what steps to take to effect it.)<p>And it can be downright confusing if someone is giving instructions: are you misinterpreting their instructions, are their instruction wrong, or is it that the software is hiding the UI from you?
The BEST UI for K8S is.... VSCode's K8s plugin. Use it all the time, and it has all the things you want instantly: terminal into container, port forward something, view logs. Beyond that, I guess there might be a different crowd that is more interested in CPU usage and RAM usage.
Seems quite a few people use Lens. So do I and honestly it has everything I'd need from a Kubernetes GUI.<p>I actually didn't realize there was already quite a few options: <a href="https://medium.com/dictcp/kubernetes-gui-clients-in-2020-kube-dashboard-lens-octant-and-kubenav-ce28df9bb0f0" rel="nofollow">https://medium.com/dictcp/kubernetes-gui-clients-in-2020-kub...</a> (+ infra.app)
Are there any powerful tools like these from command line(shell)? I prefer to use GUI to quickly navigate or do some advanced ops over remembering multiple commands.<p>I do use k9s (<a href="https://github.com/derailed/k9s" rel="nofollow">https://github.com/derailed/k9s</a>), however it still lacks lot of functionality.
I use "Lens - The Kubernetes IDE", it is pretty good and free. <a href="https://github.com/lensapp/lens" rel="nofollow">https://github.com/lensapp/lens</a>
The more the merrier, I guess. I've always been comfortable using kubectl. The only UI I am forced to use is the Google Cloud Console one. Which is ok. For newcomers I would recommend using the cli tooling and dive as deep as you can before you zoom back out. If you run k8s, then you are probably big enough a company that you have prometheus or something like that which collects metrics for cpu/ram usage.<p>From a Developers POV it's definitely easier to interact with a GUI.. and I '+1' on what u/rhacker said: the best UI in that case is probably the VSCode plugin.
If you are into that kind of thing I can also recommend Infra App (Mac, Windows, Linux): <a href="https://infra.app" rel="nofollow">https://infra.app</a><p>I'm using it from time to time to quickly log at logs or other things which is sometimes easier than the CLI. I think that design-wise it's the best looking one of the Kubernetes GUIs that I tested. Not affiliated, just a happy user.
At Indeed, we developed something similar that is also open source <a href="https://github.com/indeedeng/k8dash" rel="nofollow">https://github.com/indeedeng/k8dash</a>
How is the performance with larger clusters? We have clusters with 20,000 to 40,000 containers. We have had to use things like Thanos and InfluxDB to get prometheus/grafana to work ok.<p>Does this thing scale well?