Steampipe is an open-source tool that helps users query, explore, and visualize their cloud environments. Relationship graphs in Steampipe are helpful visualizations that provide quick context and highlight important information about your resources. You can use these dashboards to visualize your AWS resources and also your AWS Elastic Kubernetes Service (EKS) clusters.

AWS EKS is a managed Kubernetes service that makes it easier to deploy, manage, and scale containerized applications using Kubernetes. Using Steampipe with EKS, you can visualize inside the cluster to gain insights:

• How many resources do I have?
• How old are my resources?
• What are the various configurations of my resources?
• What are the relationships between closely connected resources like clusters, nodes, pods, deployments, and jobs?
• Who can perform operations like list, get, read, etc., on my resources?

Getting started

To get started with visualizing your EKS clusters through interactive dashboards, you can install Steampipe in your terminal.

First, install Steampipe:

sudo /bin/sh -c "$(curl -fsSL https://raw.githubusercontent.com/turbot/steampipe/main/install.sh)"

Then, install the Kubernetes plugin:

steampipe plugin install kubernetes

Finally, install the Kubernetes Insights mod by following these steps:

git clone https://github.com/turbot/steampipe-mod-kubernetes-insights
cd steampipe-mod-kubernetes-insights
steampipe dashboard

Now visit localhost:9194 in your browser to view and interact with the dashboards.

If you already have an AWS EKS Kubernetes cluster in ~/.kube/config, Steampipe will automatically pick up your default context. If you would like to set up multiple clusters, you can update your Steampipe configurations to aggregate multiple contexts at once.

Kubernetes Relationship Graphs

In this section, we will explore various dashboards provided by Steampipe to visualize different aspects of your EKS clusters. We will look at the Namespace, Deployment, Service, Pod, Service Account, and Role dashboards, and discuss how they can help you better understand and manage your AWS EKS Kubernetes resources.

Namespace dashboard

Here's a high-level view of the kube-system namespace in the Namespace Detail dashboard.

The application runs as a Service. On initial view, the dashboard folds them all into an individual node, and folds the related DaemonSets, ReplicaSets and Deployments into their own individual nodes.

Deployment dashboard

If we open Deployments and click on the coredns Deployment we land in the Deployment Detail dashboard where we see the kube-dns Service linked to that Deployment. On hover we see details for one of the 2 pods in that Deployment's ReplicaSet: it's running, and it uses the coredns service account.

Service dashboard

Clicking into the kube-dns Service takes us to the Service Detail dashboard where we can see the path from a load balancer to the wordpress service to the wordpress Deployment with its ReplicaSet consisting of a single pod.

Pod dashboard

Visiting the Pod takes us to the Pod Detail dashboard. Here we can see, from another perspective, that it runs as the coredns service account. We can also see the single container in the pod, and we can see there are multiple read-only volumes mounted.

Service Account dashboard

The coredns service account is pretty simple. Here coredns runs as the service account. If we open that in the Service Account Detail dashboard, we see the 2 pods that run as that service account. However we can see the service account does not have any role bindings or secrets associated, which may indicate these pods may not have the necessary credentials needed.

Role dashboard

The role shown here, is again simple, so let's open a more interesting one in the Role Detail dashboard. Here we see that the eks:certificate-controller role has broader permissions to all resources, but specific get and update permissions on a specific certificate resource.

Making Kubernetes legible

These interconnected graphs work hand-in-hand with their dashboards' infocards, charts, and tables to make Kubernetes systems legible in a whole new way. Which of these seem most useful to you? What other kinds of relationships will help you understand your K8s environments and manage them more effectively? We look forward to hearing about your experiences with Kubernetes Insights, and our Slack community is the place to share them.