Author: Matt Porter, Lead Software Architect,

Problems with your Kubernetes Cluster?

Visualise your microservice dependencies and restore service faster.

Imagine: no more problem hunting for hours at the command line. A quick look at the cluster, a fix, and you are back to what you wanted to be doing.

One of the best parts of being a DevOps engineer is taking advantage of the new waves of tools appearing on the market. Containers and microservices have taken over our daily lives. We work with pioneering technologies from innovative organisations like Docker and Google. But, we all know that these come with certain challenges, issues and limitations.

Does this sound familiar: You discover there’s a problem with your deployed service, fire up Kubectl to gain command line access to Kubernetes, and then feel a level of frustration with the long-winded multi-step manual search for the root cause of the problem. It’s a common issue, Kubernetes is just a bit … well … clunky. There is so much disparate simplicity, that we are faced with complexity.

Don’t get us wrong, we LOVE Kubernetes

but we found navigating our clusters to identify issues painful from the command line.

We wanted a faster, simpler way to manage Kubernetes clusters. So we set out to cut the time and effort to traverse and explore Kubernetes to short track the diagnosis and resolution of deployment problems. Eighteen months ago we started development and last month our product became generally available.

Resolving issues within your cluster

Cobe creates a live, searchable model that captures all the relationships, performance data and actionable alarms, in full visualised context. Through search, Cobe enables you to identify and surface relevant telemetry so you can quickly identify and diagnose the root cause of issues.

In its most simple form: when you hit an issue, all you need to do is open a browser, login to Cobe and you’ll be presented with a complete topology of your environment.

As more and more microservices are added, there is an increase in the number of moving parts — all of which need to interact. This increases the number of potential points of failure. There are no issues when all the pieces work harmoniously together, but when one of these parts fails, tracing the root of the problem across multiple tiers can be difficult.

You can pinpoint anomalies

and see that problem in the wider context of your cluster with associated potential causes, issues and/or implications between your microservices.

You don’t just find the pod that’s not working in your code; instead you see all the pieces of the puzzle. Which container failed? Why is the app crashing? Is there an issue with the node? Is there a bigger problem? What other things are impacted? All this in visualised Cluster context, minimising the need to go to the command line.

We built Cobe because we were frustrated at interfacing ‘blind’ with Kubernetes from the terminal and believe that this will enable teams to focus on the most urgent services, and restore service faster than ever before.

Author: Matt Porter, Lead Software Architect,

See for yourself, and let us know what you think!

Or take a free 30 day trial:

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.