Visualizing Kubernetes Resources
Everyone who is working with Kubernetes knows that Kubernetes eats YAML manifests, and it eats lots of those. Every Kubernetes resource is defined in a separate YAML manifest. For a user, it’s really hard to spot any errors when it comes to the relation of Kubernetes resources from those manifest files. Manifests can be totally valid and resources are created in the cluster, but something still may not be working correctly. With existing tools, users investigate the issue by running many Kubectl commands, in order to better understand what’s going on.
To help users identify these issues, I’ve created the Resource Map extension for Lens IDE, an OSS project developed by Team Lens. Lens IDE is a popular desktop application built to manage multiple Kubernetes clusters. The extension visualizes Kubernetes resources and their relations in the form of force-directed graph.
The Resource Map extension puts the main focus on Kubernetes pods, this is because pods are the fundamental resource of Kubernetes. The extension will show secrets, configmaps and persistent volume claims, that are defined in pod spec, as connected resources.
The example below showcases a WordPress pod deployed from Bitnami’s WordPress Helm chart. The pod belongs to the deployment, which is coming from the Helm release. The pod has two secrets and one persistent volume claim. There’s also one service serving the cluster network traffic to the pod, and that service is exposed via the ingress resource that comes with TLS secret.
If you don’t see secrets, configmaps or persistent volume claims connected to the pod, you can check the pod spec and review what is misconfigured.
The Resource Manifest will display the connection between the pod and the service and which selector property matches the pod’s labels. This will help identify that service selector is correctly configured. If an Ingress resource is referencing to a service, you will see it connected to that service. On the next example below, you can see that there is a missing connection between the service and the pod. Most likely, something is off with the service’s selector.
The Resource Map extension allows users to easily view and understand when there is a dangling persistent volume claim. For example, when removing a Helm release, it will not automatically remove the persistent volumes from the cluster. The Resource Manifest can save you time and resources when working with Kubernetes.
These visualizations are available on the workloads overview page within the Lens IDE cluster dashboard. Additionally, almost every Kubernetes object details pane contains a graph focusing on the selected Kubernetes resource.
Latest version (1.0) of Resource map extension focuses on compatibility with Lens 5. The extension supports now also light theme and adds graphs to Kubernetes resource details.
How Get Started?
To get started with Resource Map extensions, you first need to install Lens IDE. If you have already done that, you are good to go. To install the extension:
Switch to the Extensions view (CMD+SHIFT+E on macOS).
- Enter the name of this extension, @nevalla/kube-resource-map, into the Installation Extension box.
- Click on the Install button.
After the extension is installed successfully, you are able to see Resource Map page on a cluster dashboard and graphs appearing on Workloads Overview page and on details drawers.
What is still missing?
The Resource Map extension is still a young and I expect to have several more releases before the extension is fully matured. Not every resource is visible on the resource map yet. For example, jobs are still missing and only native Kubernetes resources are supported. Adding support to custom resources would nice. So expect to see these improvements in the future.
If you have any ideas on what is still missing or what you would like to see, feel free to reach me on Twitter (@nevalau) or open an issue on GitHub. I’m happy to discuss it further.
About Me
Lauri Nevala started his journey to the world of containers in 2015 when Docker was new and cool. He was co-founder of Kontena, Inc. which made adopting containers easier for developers and originally created Lens application. Currently Lauri Nevala is core developer of Lens application at Mirantis.
