Monitoring Kubernetes With Sysdig Cloud

Our mission at Sysdig is to enable container and microservice usage in production and all the benefits that can come with that. This aligns remarkably well with Kubernetes’ goals, and therefore it’s probably no surprise that we’re huge fans of Kubernetes here at Sysdig. Despite being a young project, we strongly believe Kubernetes is on a trajectory to become one of those game changing technologies that happen only once every 10 years.

We’ve spent quite a lot of time adding Kubernetes support to open source sysdig, as well as enhancing Sysdig Cloud to make it the best Kubernetes monitoring solution you can find. Today we are rolling out the results of our effort.

I’m proud to announce that Sysdig Cloud now offers comprehensive Kubernetes visibility, including the ability to monitor and alert at any level of your application stack, from namespaces and services (see below if you’re not familiar), down to hosts, pods, containers and processes. All of this with zero configuration and no need to instrument any of your containers or pods with agents.

This blog post is going to showcase how Kubernetes support in Sysdig Cloud works, including some useful features and use cases. But first…

A Bit of Background on Kubernetes

Kubernetes is an open-source project, started by Google, designed to manage service-oriented applications using containers distributed across clusters of hosts. Kubernetes provides mechanisms for application deployment, service discovery, scheduling, updating, maintenance, and scaling.

From the physical/infrastructure point of view, a Kubernetes cluster is made up of a set of minion machines overseen by a master machine. The master’s tasks include orchestrating containers across minions, keeping track of state and exposing cluster control through a REST API and a UI.

On the other hand, from the logical/application point of view, Kubernetes clusters are arranged in the hierarchical fashion shown in this picture:

All containers run inside pods. A pod can host a single container, or multiple cooperating containers; in the latter case, the containers in the pod are guaranteed to be co-located on the same machine and can share resources.

• Pods typically sit behind services, which take care of balancing the traffic, and also expose the set of pods as a single discoverable IP address/port.
• Services are scaled horizontally by replication controllers (“RCs”) which create/destroy pods for each service as needed.
• Namespaces are virtual clusters that can include one or more services.

So, just to be clear, multiple services and even multiple namespaces can be scattered across the same physical infrastructure. This can lead to some pretty impressive complexity in terms of monitoring and visibility in even a modest Kubernetes deployment.

Kubernetes Monitoring With Sysdig Cloud

After talking to hundreds of Kubernetes users, it seems that the typical cluster administrator is often interested in looking at things from the physical point of view, while service/application developers tend to be more interested in seeing things from the logical point of view.

With both these use-cases in mind, Sysdig Cloud’s support for Kubernetes now works like this:

1. By connecting to a Kubernetes’ cluster API Server and querying the API (both the regular and the watch API), we’re now able to infer both the physical and the logical structure of your microservice application.
2. In addition, we transparently extract important metadata such as labels.
3. This information is combined with our patent-pending ContainerVision technology, which makes it possible to inspect applications running inside containers without requiring any instrumentation of the container or application.

Based on this, Sysdig Cloud can now provide rich visibility and context from both an infrastructure-centric and an application-centric point of view. The best of both worlds!

Let’s check out what this actually looks like…

One of the core features of Sysdig Cloud is groups. You’re now able to group and explore your containers based on their physical hierarchy (for example, physical cluster > minion machine > pod > container) or based on their logical microservice hierarchy (for example, namespace > replication controller > pod > container — as you can see in this example).

If you’re interested in the utilization of your underlying physical resource–e.g. identifying noisy neighbors–then the physical hierarchy is great. But if you’re looking to explore the performance of your applications and microservices, then the logical hierarchy is often the best place to start.

For example: here you can see the overall performance of our WordPress service:

Keep in mind that the pods implementing this service are scattered across multiple machines, but we can still total request counts, response times, and URLs statistics aggregated together for this service. And, don’t forget: this doesn’t require any configuration or instrumentation of WordPress, Apache, or the underlying containers!

And, from this view, I can now easily create alerts for these service-level metrics, and I can dig down into any individual container for deep inspection–down to the process level–whenever I want, including back in time!

Visualizing Your Kubernetes Services

Just as with our recently announced support for Amazon ECS, we’ve updated Sysdig Cloud’s famous topology view with Kubernetes awareness, at both the physical and logical level.

The two pictures below show the exact same infrastructure and services. But, the first one depicts the physical hierarchy, with a master node and three minion nodes; while the second one groups containers into namespaces, services, and pods, while abstracting the physical location of the containers.

Hopefully, it’s self-evident how much more natural and intuitive the second (services-oriented) view is. The structure of the application and the various dependencies are immediately clear. The interactions between various microservices become obvious, despite the fact that these microservices are intermingled across our machine cluster!

Conclusion

The main conclusion is: if you have a non-trivial Kubernetes deployment, you’ve got to try this! You can sign up for a 2 week free trial here–no commitment, no credit card needed.

I’m pretty confident that what we are delivering here represents a huge leap in visibility into Kubernetes environments and it won’t disappoint you. I also hope it can be a useful tool enabling you to use Kubernetes in production with a little more peace of mind. Like I said at the start of this post, Kubernetes is awesome, and we want to help you use it for real!