Microsoft recently held its first company-wide hackathon
, where we created a new visualizer tool for Kubernetes deployment on Azure. Alongside today’s announcement that Kubernetes can be used to manage your Docker containers on Microsoft Azure, we have also today released the code for the visualizer tool, which can be found here: Azure Kubernetes Visualizer GitHub Repository
The Hackathon Project
Our project was to build a visualization system for what Kubernetes is doing when managing Docker on Azure. Kubernetes
is a declarative cluster management system for a containerization technology called Docker
. As described here
, Docker offers “a portable, lightweight runtime and … enables apps to be quickly assembled…” The goal was to visually demonstrate some Docker and Kubernetes concepts such as containers, pods, labels, minions, and replication controllers. You can see the result in the screenshot below.
A Kubernetes cluster is made up of a master, and any number of minions. The master is responsible for managing the cluster as a whole – issuing requests to be performed by the minions, and providing the API layer for Kubernetes. The minions are what actually run Docker, and thus the end-user workloads. Pods run on the minions inside the containers and are balanced across the minions by the master. The Kubernetes visualizer allows you to create pods by assigning it a name and specifying how many copies of that pod you would like created.
Upon clicking the “Create!” button users can update a JSON “Pod Template.” This template defines what containers should be associated with the pod, what images should be running in each container, and any port mappings so that these services are available to the outside world.
Because the goal of this visualizer tool is to help in understanding Kubernetes, we enabled editing the Pod template that was created in the backend automatically. To do this, click on the “Pod Source” and the RC Source button. As you can see, the Pod source shows an Nginx instance with the port number automatically assigned.
If you edit this Pod Template, you can create other configurations like in the first screenshot of the visualizer, where you can see blue and pink pods that are running both Nginx and Redis. As shown below, you can also see the source for an equivalent Replication Controller that contains the same pod template but specifies the number of copies we would like of the Pod.
The last thing that our visualizer does is help show the Kubernetes concept of labels. You can assign arbitrary key-value pairs to pods to help organize everything that you have running within Kubernetes. This is how the visualizer colors Pods – by looking at the name (that the user specified) that is stored in a label tied to that Pod. Each distinct name gets a different color.
Learnings from Kubernetes and Docker
One thing that quickly became apparent after playing with Kubernetes and Docker, was that Docker caches Pod creation to speed up repeat containers. The first time we create a Pod on a minion, it takes up to a couple minutes for it to come up. This is mainly due to the fact that we’re waiting for Docker to download the Ubuntu and Nginx images. However, the next time we create a Pod on that minion it is significantly faster as the image is already cached. This is promising as we expect that most often the architecture of an application being run on Kubernetes will not change is core components often. In this sample, for example, it will always be based on Ubuntu and Nginx with just the source code changing. This means Kubernetes will usually be very fast in bringing up and revving the application given Docker’s caching.
Lastly, we decided to stress test the cluster and see how Kubernetes might react to us spinning up a large number of pods. After some playing around we found that it handled our first tries of 30-50 pods at once quite well, and can scale up to 200 pods. In the below screenshot, you can see the demo in action, about a third of the way through creating 200 copies of Nginx. The black boxes with blue spinners are pods that are in the process of starting up. The first row shows pods whose pod create requests have gone through, but who have not yet been assigned to a minion. The columns then show the pods that have already been assigned to a minion. Lastly, the colored pods are those that have finished turning up and are ready.
If you’re interested in learning more, don’t miss the video demonstration of this tool in our latest Cloud Cover show at Channel 9
or better yet grab our code on GitHub
and run the visualizer with your own cluster on Azure. We hope that this tool can be valuable for first-timers to Kubernetes, Docker or Azure.
Thank you for reading.
Michael Blouin and Madhan Arumugam Ramakrishnan (on-behalf of the hackathon team)