Development

Kubernetes application dashboard

Giving developers a portal they can use to understand application dependencies, ownership, and more has never been more critical. As you scale your Kubernetes adoption, you want to make sure you avoid service sprawl, and if not done early, application support will become a nightmare.

The Ask

You have put a good amount of effort and time into implementing and scaling Kubernetes in your organization. You have configured pipelines, monitoring, and more. You have also created templates using tools like Terraform so developers can have their applications deployed and more. All is ready.

As soon as you show development teams all the work you’ve put together and how they can now deploy their applications, the first question they ask is: 

How do I see my application post-deployment so I can manage it?

Is there a dashboard for my applications in Kubernetes?

The (not so great) solution

Sure, you can tell them to use kubectl, but that can open a whole can of worms. Maybe most of them do not have the same level of knowledge you have on Kubernetes to understand all the applications’ dependencies and how to access them with kubectl. Describing application and object details and status might not be easy for them, and in the end, it falls back on the DevOps team to help them to that.

You can always rally your platform team to create a simple dashboard for them, which you will find later that there is no such thing as “simple.” This effort will turn into months worth of work, management not being happy, and something that will always create complexity for you to support and keep evolving.

As you scale the number of applications, services, and clusters deployed, mapping who owns what and the status of each application when support is needed can become a nightmare, so the real questions become:

  • How can you implement some service ownership model that you can use to identify who owns what?
  • How can you give developers a dashboard they can use to visualize their application dependency and status?
  • Can you provide SRE teams with a quick way to identify who owns the service, where developers deployed it, the dependencies, and the service status?

Implementing a structured solution

With the questions above defined, let’s now implement a solution that will help you address them and help you structure a framework that will help you scale.

For that, you will need:

  • A Shipa Cloud account. You can create one here
  • Access to a Kubernetes cluster where you have applications deployed

By using Shipa Cloud, you can get a solution in place in a matter of minutes and deliver a big win with your development and SRE teams. In just a few minutes, you will get them something like this:

Application dependency map

Getting Started

With your Shipa Cloud account created, you will be able to deliver this solution in two simple steps. Let’s go through the steps.

You can find the step by step details below as well as the video with detailed instructions here:

Creating a Policy Framework

The first step is to create a policy framework, which you can do by clicking on Frameworks on the left menu.

Policy frameworks are how you can define controls and guardrails around network policy, RBAC, registry control, and more. The policy framework automatically enforces the controls you define to applications your developers bind to this framework.

Although the policy framework enforces controls only to applications deployed using Shipa, we will now focus on the App Discovery part of the process. Shipa will use this section of the policy framework to map your existing namespace and surface the applications and dependencies.

Click on Frameworks on the left menu, then on the add icon. You should see this modal popup:

The App Discovery option is only available when you use Advanced. Click on Next

Moving to the General section of the policy framework creation, in the Kubernetes Namespace section, enter the name of the namespace where you have your applications deployed. I entered blog for this example:

You can move to the following sections and select the default options for the framework. We can explore each of them in detail later. The critical step for you here is the App Discovery one.

Here you can enter the label you assigned to your applications during deployment on Kubernetes:

Shipa will use this label to connect to your existing namespace and map the applications and objects.

You can use the Naming Suffix field if you want Shipa to append a suffix to the application name when it imports them into the dashboard.

You can find your application label by using kubectl or inspecting the manifests you used to deploy the applications. 

Once you complete this step, click on Create.

Binding the Policy Framework

Now that you have your first policy framework let’s bind it to the cluster where the namespace we entered before exists along with the applications.

On the left menu, click on Clusters and the add button.

The first step will prompt you to enter the cluster name and the policy framework. Enter a name for the cluster we are connecting and select the framework you created in the previous step.

Moving to the next step, it will ask you for:

  • Cluster IP address
  • Service account token
  • CA Certificate for the service account

You will need to create a service account for Shipa and then use its token and certificate.

You can find details of finding the cluster IP, creating the service account, and getting its information here.

The cluster connecting and policy framework binding should take about 60 seconds. Once connected, Shipa will take a couple of minutes to complete the mapping process.

You can see the mapped applications by clicking on the Applications menu link:

You will see your existing applications displayed here, along with the status. Click on the application name:

This page will give you information about:

  • Which policy framework and namespace this application belongs to, who owns it, and the teams that have access to it.
  • Information about the application containers and their statuses
  • Where your application is geographically located, which is taken from the cluster location
  • The application dependency map and object details

You can now give access to your developers and SREs so that they can have access to all applications mapped by your policy framework.


You can find detailed information and sample roles and permissions you can use when adding your team members here.

Conclusion

That’s just the first release of Shipa’s application discovery functionality, and we will keep on evolving it. We would love to hear from you and learn more about how we can help you target specific use cases.

As you now have access to Shipa, you can start deploying your applications using Shipa from tools such as Terraform, Pulumi, CI pipelines, and others, which will open many possibilities for all teams.