There are many alternatives to the Kuberenetes Dashboard, all of which have various strengths and weaknesses but aim to build upon the functionality of the K8s dashboard. Some of the most popular include:
Spacelift allows you to automate, audit, secure, and continuously deliver your infrastructure. It helps overcome common state management issues and adds several must-have features for infrastructure management.
The Kubernetes Dashboard is a web-based user interface for Kubernetes. You can use it to get an overview of applications running on a cluster, deploy containerized applications to a Kubernetes cluster, and manage cluster resources. It also enables troubleshooting for containerized applications, providing information about the health of Kubernetes resources in your cluster and any errors that have occurred.
The Kubernetes Dashboard makes it possible to create or modify individual Kubernetes resources, such as deployments, jobs, DaemonSets, and StatefulSets. It can also be used to directly manage Kubernetes pods.
Clicking on a namespace directs you to a dedicated view of that namespace. Currently, this view only displays recent events, but you can access other namespace-specific information in the general overview.
Clicking on a specific node directs you to a detailed page for that node. This page contains several sections providing extensive information about the node, including machine ID, addresses, allocated resources, pods, conditions, and events.
You can click on a specific pod to see a detailed overview of that pod. The pod overview provides details about the pod, including its attached labels, QoS class, and status. It also shows which containers belong to the specific pod, its condition, which controller created the pod, attached persistent volume claims, and events.
kubectl creates deployment resources including a dedicated Kubernetes Dashboard namespace, service accounts, configuration maps, pods, cluster roles, services, and RBAC roles, enabling the Kubernetes dashboard to function.
The Kubernetes Dashboard solution shipped with the open source Kubernetes distribution is useful, but many do not consider it a full-featured observability solution. Several commercial and open source alternatives have emerged that can help you gain comprehensive visibility over your Kubernetes clusters.
Komodor is the solution for managing Kubernetes at scale. The platform continuously monitors, analyzes, and visualizes your Kubernetes environment, providing clear, actionable insights that simplify reliability maintenance, real-time troubleshooting, and cost optimization across complex, multi-cluster, and hybrid setups.
By bridging the Kubernetes knowledge gap, Komodor empowers infrastructure and application teams to move beyond firefighting and focus on operational efficiency, reducing MTTR, and accelerating development. With robust RBAC, SSO, and auditing capabilities, Komodor is the trusted platform for innovative enterprises throughout their Kubernetes journey, from migration to Day-2 operations.
Lens provides many of the same features provided by the official Kubernetes Dashboard, including the ability to view and edit namespaces, ReplicaSets, services, and other Kubernetes resources. It offers granular access control for dashboard users via role-based access control (RBAC).
In addition, Lens is integrated with Prometheus out of the box to provide multi-user visibility. As soon as it is deployed in a cluster, it automatically discovers Prometheus and starts displaying cluster metrics and visualizations in its dashboard, including resource utilization graphs and CPU, memory, network, and request metrics. These graphs and metrics are displayed in the context of a specific cluster.
K9s is a terminal-based UI designed to facilitate the navigation, observation, and management of your Kubernetes clusters. This project aims to simplify interactions with deployed applications, offering a streamlined and efficient CLI tool for Kubernetes administrators. Key features includ:
Rancher is an open source Kubernetes management tool that can be used to manage multiple Kubernetes clusters. Part of the Rancher platform is the Rancher Dashboard, a stateless client written in Vue.js and NextJS. The dashboard is bundled by default with the Rancher distribution.
The Rancher Dashboard shows Kubernetes types, namespaces, and operations that the current user has access to. By default, it shows a Details view with raw YAML obtained from the Kubernetes API, and a Table view with the data provided by the command kubectl get -o.
I ran into the same problem yesterday. Apparently Kubernetes Dashboard versions from 7.0.0 and above use Kong, a cloud-native API gateway that manages distributed applications. The new implementation of the Dashboard consists of a few microservices and Kong proxies the incoming requests to these services. That means you should expose the port of the kubernetes-dashboard-kong-proxy Service, which by default is 8443, like so:
I forgot to reply it here but I also managed to figure it out. Thank your answer. I found an article that really helped me, maybe it will help someone else too so i will leave it here: Kubernetes Dashboard - Deploy and Visualize your Kubernetes Cluster (kerno.io)
Using cert-manager I've obtained certificates for the dashboard domain and reflected these into the kubernetes-dashboard namespace. I have then configured kubernetes-dashboard to use these following this guide: dashboard/installation.md at master kubernetes/dashboard GitHub
There isn't anything in the traefik logs but it seems these might be restricted to errors only and I'm not sure how to change that, some debug logging would be useful. Edit: I have since managed to get debug logs and can see level=debug msg="'500 Internal Server Error' caused by: x509: cannot validate certificate for 10.42.0.3 because it doesn't contain any IP SANs"
From googling around it does appear to be an issue with the fact that the dashboard is using a https backend. However having read Forwarding to https backend fails Issue #7462 traefik/traefik GitHub I think Traefik should be able to recognize the backend is https and not to attempt to connect over http, by the port number being 443 and also the annotation. I also found this traefik - SSL issue while reaching kubernetes dashboard - DevOps Stack Exchange but not sure it applies as I am not using the self-signed certs of the dashboard. Nevertheless I did try making an IngressRoute and ServiceTransport, but having deleted the ingress above any applying these I just get a 404.
I think this causes traefik to be started with that insecureSkipVerify option which means it doesn't validate SSL certs. It's debatable as to whether that's the best option security-wise but it was fine for my use case, as my cluster is single-node and traffic only passes through the internal network.
In the meantime I figured out that you can create a ServersTransport object that can be added to an IngressRoute that does exactly that, but only for a specific IngressRoute. I'll write my solution down in case anyone else runs into the same problem.
I wanted to understand this a bit further, why can't Traefik use my self signed wildcard certificate and trust it so I don't have to skip TLS verification if I'm using that same wildcard cert for kubernetes-dashboard as well?
I've added the below config to try and get traefik to recognize the ca below. what I don't understand is why openssl client does not have the IP SANs issues using the same certificate and from an IP address? If I trust the CA in my browser I'm able to browse to any Traefik ingress for any app securely, seeing my self signed cert so I know Traefik is correctly dealing with my self signed cert. it almost seems like Traefik is not using the same self signed cert to talk to the Kubernetes Dashboard.
I had similar connection refused issues connecting to the private docker registry shipped with microk8s, setup to listen on 32000. When I set it up instead to use a custom private registry I put together on localhost:5000 it worked fine. Any idea what might be the case?
Yes - I have been following the instructions from the addon-dashboard link - I tried it on 10443 to begin with and encountered the issue, so retried on another port that I use and know to be free, to be sure (ie the one I mentioned in my post).
In an RBAC enabled setup you need to create a ServiceAccount for the Dashboard dashboard/creating-sample-user.md at master kubernetes/dashboard GitHub
then generate the Bearer Token kubectl -n kubernetes-dashboard create token admin-user, the token will expire after a short time. For Newcomers, create the Bearer Token with 99999 hours duration kubectl -n kubernetes-dashboard create token admin-user --duration=999999h
I am currently trying to expose the kubernetes dashboard via an internal ingress. I have this working for other services which do not utilize TLS themselves, but am unable to get this to work for the dashboard which has its own self signed cert. Below is what I have configured.
The Kubernetes Dashboard is a web-based UI that allows administrators to perform basic operating tasks and review cluster events. You can use the dashboard as a quick tool for viewing and monitoring the cluster, submitting manifests, inspecting logs, and getting system information.
In this extended article, we will take a deep dive into the Kubernetes dashboard. We will explain how to install it, how to access it from inside or outside the cluster, and how to administer it remotely.
To follow along, you will need to have access to a Kubernetes cluster. You can use Kind to create local Kubernetes clusters for testing purposes. (Just follow their instructions to install and deploy your sample cluster.) Alternatively, you can use a managed service like Digital Ocean or GCloud to simulate a real-world example.
The Kubernetes dashboard, which is maintained by the official Kubernetes team, is a general-purpose web application that you can deploy on your cluster. It consists of two main components: a front-end and a back-end.
c80f0f1006