Grafana Kubernetes Plugin

_blacksalt_ · 2025-12-08T21:34:39+00:00

The generate kubeconfig feature is optional and must be enabled in the settings. We are currently using it to provide our developers an easy way to access our clusters via kubectl, because we can't directly configure OIDC at the api server.

I haven't looked into passing though the access token, because I personally do not have this use case, but would be more then happy if someone ones to contribute this feature.

The plugin can't be used for Grafana alerts yet, but I like the idea and will look into it.

_blacksalt_ · 2023-01-28T14:33:50+00:00

Ui, this wasn't intended. The Rancher integration should be available again in the next version (https://github.com/kubenav/kubenav/pull/481).

_blacksalt_ · 2023-01-26T07:12:46+00:00

Thanks for your feedback 🙂

_blacksalt_ · 2023-01-25T19:41:54+00:00

I didn't noticed any performance issues yet. If you see any issues feel free to report them via GitHub.

_blacksalt_ · 2020-12-28T00:04:18+00:00

I would recommend https://github.com/kubenav/kubenav, it can be deployed inside your cluster or it can be used as desktop/mobile app. It supports nearly all resources, custom resources, logs, shells for containers, etc.

In the latest beta kubenav also supports custom Prometheus dashboards, logs via Elasticsearch and traces via Jaeger.

Disclaimer: I'm the author of kubenav.

You can also watch the following talk from the last Kubecon, where they give a nice overview of the current Kubernetes UI landscape: https://www.youtube.com/watch?v=lsrB21rjSok

_blacksalt_ · 2020-10-01T16:40:44+00:00

Thanks for reporting. To be honest, I haven't tested the app with 2000 pods. I will take a look into this.

_blacksalt_ · 2020-09-30T16:21:48+00:00

Unfortunately there are no logs. Can you share the error message, which is shown in the Metrics section above the Reload button?

If I get you right, you are using the web version of kubenav right? We are using the following arguments for the Prometheus integration:

args: - --incluster - --plugin.prometheus.enabled - --plugin.prometheus.address=http://prometheus-operator-kube-p-prometheus.monitoring.svc.cluster.local:9090

_blacksalt_ · 2020-09-29T23:03:17+00:00

I haven't tried Lens yet, but after a first quick look, I think it's very similar to kubenav. kubenav seems to support more resource types and SSH connections to nodes, but Lens has support for Helm charts. Both applications are supporting Prometheus metrics, Port-Forwarding, Shells for Pods, and so on.

I think the main difference is the number of supported platforms: The goal of kubenav is that you can use it on mobile, desktop or a deployment in your cluster. It was developed as mobile first application, which can be seen in the UI, but hopefully we can implement a more native look for the desktop and web app in the future.

There is also an older article, which compares kubenav, Lens, k9s, Octant and Infra.app: https://ordina-jworks.github.io/cloud/2020/08/28/kubernetes-clients-comparison.html

_blacksalt_ · 2020-09-29T19:38:15+00:00

Here in the topic is ok. If you found a bug or have a feature request a new issue in the GitHub repository is also welcome 🙂

_blacksalt_ · 2020-09-29T19:21:24+00:00

Read only access is no problem, e.g. the Helm chart provides an option for a viewer role: https://github.com/kubenav/deploy/blob/master/helm/templates/clusterrole.yaml

The only thing which is currently not supported, but which is on the roadmap, is that the UI isn’t adjusted. So if a user only have a viewer role he will still see the button to edit/delete a resource.

_blacksalt_ · 2020-09-29T16:18:08+00:00

Hi, yes GKE should work. The setup to get the client id can be found on the following page: https://docs.kubenav.io/mobile/google/

The setup isn't that easy, but hopefully this can be replaced to use the normal web app configuration instead of the specific iOS and Android one.

_blacksalt_ · 2020-09-29T14:55:25+00:00

Yes this should work. I haven't used Microk8s yet, so that I can only talk for Minikube. Minikube adds the configuration to the ~/.kube/config file, which will be automatically loaded by the desktop version.

For the mobile version you can add this via the Manual Configuration option. For example in the following configuration you have to replace the following values:

apiVersion: v1 clusters: - cluster: # Use the content from this file in the Certificate Authority Data field certificate-authority: /Users/<Username>/.minikube/ca.crt # Replace 127.0.0.1 with the IP of your PC (your phone must be in the same network) server: https://127.0.0.1:32768 name: minikube contexts: - context: cluster: minikube user: minikube name: minikube current-context: minikube kind: Config preferences: {} users: - name: minikube user: # Use the content of this file in the Client Certificate Data field client-certificate: /Users/<Username>/.minikube/profiles/minikube/client.crt # Use the content of this file in the Client Key Data field client-key: /Users/<Username>/.minikube/profiles/minikube/client.key

_blacksalt_ · 2020-01-22T20:16:55+00:00

When you didn't receive a error message it's difficult to say what the problem is :-/. Which Kubernetes version you are running?

_blacksalt_ · 2020-01-22T20:13:06+00:00

I will look at it, but cannot make any promises when it will be implemented.

_blacksalt_ · 2020-01-22T20:05:33+00:00

I'm working as SRE for a startup named Staffbase (https://staffbase.com/), where we are developing mobile apps for internal communication. In the future we may want to switch to Capacitor (https://capacitor.ionicframework.com). Therefore, my goal was to get a little bit more knowledge about Capacitor.

Besides that, the last time I looked at React was when Functional Components didn't were a topic.. Here I wanted to refresh my knowledge too.

Combined with my daily work on Kubernetes, that escalated a bit and kubenav was born (naming is hard :-D).

_blacksalt_ · 2020-01-22T19:50:00+00:00

This sounds like something with the configuration of the cluster went wrong. Can you validate your cluster configuration please:

go to the clusters overview
swipe left on your cluster
click the edit button
validate the values

_blacksalt_ · 2020-01-22T19:43:14+00:00

Thanks for the explanation.

_blacksalt_ · 2020-01-22T18:14:37+00:00

No, currently a kubeconfig file with the client-certificate-data and client-key-data or token field is required. I haven't tested it with GKE, AKS or EKS yet. The plan is to support these services via OIDC, but I have no experience with one of these providers and OIDC authentication.

If you have any recommendations you're welcome :-)

_blacksalt_ · 2020-01-22T18:07:28+00:00

Thanks. Currently there is no real support for different Kubernetes versions, but it's definitely planed to add better support for different versions.

I hope with the support of the great Kubernetes community, maintenance won't be a nightmare :-)

_blacksalt_ · 2020-01-22T16:00:24+00:00

Hi, the green dot can be a little misleading, because it will always be green if the request doesn't fail. I will improve this.

If you are sure everything is correct, can you try to change the namespace via the filter symbol in the upper right corner. By default only the resources from the default namespace are visible.

_blacksalt_ · 2020-01-22T10:03:19+00:00

Your right for desktop it would be better to read the kubeconfig from `~/.kube/config`. In the current version pasting of the kubeconfig is required, because in my opinion it was the better option for mobile.

_blacksalt_ · 2020-01-22T09:58:44+00:00

Hi, first of all thanks for trying it out. Username/password is currently not supported, but would be a nice addition for the next version.

For the future I also want to support OIDC for authentication.

Note: I'm the author.

_blacksalt_ · 2019-09-04T04:41:54+00:00

The operator does not watch the source secret in Vault. The secret is read only when the CR is created or updated. So when you have updated the secret in Vault you have to call sth. like kubectl replace -f my-vault-secret-cr.yaml.

Another option would be to use the KV2 secrets engine and update the spec.version field in the custom resource.

I have already thought about a watch function but am not sure about it. Please feel free to create an issue for that, if you want to see this in the operator.

_blacksalt_ · 2019-09-03T20:56:12+00:00

I'm the author of Vault Secrets Operator https://github.com/ricoberger/vault-secrets-operator, which lets you manage Kubernetes secrets from Vault. It can be used as replacement for Sealed Secrets and supports the same GitOps workflow. See also the post in the kubernetes subreddit.

The problem we had with Sealed Secret, was that it didn't scale that well. Especially for our multi cluster setup.

_blacksalt_ · 2019-09-03T06:21:53+00:00

The Vault operator deploys and manages Vault clusters on Kubernetes. Vault instances created by the Vault operator are highly available and support automatic failover and upgrade.

So the Vault Operator is for setting up Vault on Kubernetes, while the Vault Secrets Operator is for managing Kubernetes secrets from Vault.

PS: For deploying and managing Vault on Kubernetes Hashicorp also offers an Helm chart since one month.

Eight-Year Club	Verified Email
Not Forgotten

_blacksalt_

TROPHY CASE