Hello friends!
Ivan's here with a traditional monthly update. This time, I've got just one topic, but I'm rather excited to talk about it! 🤩
After a year of (sporadically) posting videos of my secret Kubernetes UI, I'm finally ready to share an MVP with you! Since yesterday, every Kubernetes playground on iximiuz Labs has gotten a new "Explorer" tab, which you can use to access the buggy shiny new piece of UI.
What this new Kubernetes Explorer is for?
Primarily, it's for learning and developing apps on Kubernetes. By no means it's yet another dashboard to manage production clusters. Instead of dumping on you a bunch of boring tables and a myriad of gauges showing the number of unready Deployments and failed Pods, I wanted to build a tool that would visualize Kubernetes objects and their relationships, do it in real-time and help you focus on the right parts of the otherwise overwhelming graph 🧐
Let me show you an example.
I still remember the time when I had to mess with Istio on a daily basis. Istio maintainers do herculean work, providing sample applications to illustrate various aspects of the service mesh functionality. Having these apps available is very helpful for understanding Istio, but since they are meant to illustrate complex concepts like retries, load balancing, and traffic shifting, understanding the apps in the first place can already be a challenge.
For instance, it's easy to follow the Getting Started guide, but do you really know what the Bookinfo app looks like in the end?
Let's see how we can wrap our heads around the Bookinfo app faster using the new Kubernetes Explorer.
The tool is structured like a typical IDE - with a dynamically updating tree view on the left and a built-in web terminal to manipulate your cluster(s) objects. It's reasonable to expect that the Bookinfo app includes at least one Deployment, but can we know its exact constitutes?
All right, it was easy to figure out what Deployments are there in the Bookinfo app. But it's unlikely that the Deployments are the only created objects. Of course, you can go and query Pods, Services, and the like, but can we somehow figure out the involved objects faster?
Using a smart "Related objects" watch preset, we can quickly get a graph of all objects with relation to the selected Deployment (or rather, to any other currently selected object). I have yet to describe the complete graph in the code, but at the moment, you can already see that a Deployment has a connection with one or more Pods running on a Node using a ServiceAccount, possibly exposed by a Service, using several Secrets and ConfigMaps, etc. Make sure you watched the above video - it illustrates the idea much better than any words.
A graph of related objects is helpful, but sometimes it's not exactly what you need. Filtering some "noise" (Namespace, Nodes, Events, etc.) can help improve the visual structure, and picking a Service (instead of a Deployment) as the target object can do wonders for more complex apps. Just check out another recording 😉
Observing objects created, updated, or deleted in real-time is fun, but it also can help understand the dynamics of the application. The next video shows an example of what a Deployment scaling might look like, but there are definitely more use cases for it - I'm especially looking forward to trying it with Kubernetes controllers/operators. Note the color coding in the video - most of the objects are blue-ish, but just-created objects are green, recently updated objects are yellow, and deleted objects are red.
Cannot tell about you, but I definitely became much more familiar with the structure of the Bookinfo app after playing with it in the Kubernetes Explorer. And I grasped the top-level structure literally in no time - thanks to the "Related objects" and "Application" presets.
First off, I'd like to pause the active development for a few weeks and shift the focus to content production. I have a ton of blog posts, tutorials, and mini-courses ideas where the new Kubernetes Explorer will be of huge help for both the author and the students. After that, there are a few key areas of the Explorer where I'd love to invest time:
The development of the explorer has been challenging but rewarding. I'm not afraid of any technical challenges, and I have all the plans to continue the work. However, I cannot call the way it was done so far sustainable - it has all been done in my free time and often at the expense of other important activities. I'm actively looking for ways to fund my work on iximiuz Labs, so if you like this new tool and the platform and want to contribute to their success, please consider becoming a Patron.
Cheers
Ivan
P.S. Patreon membership of this kind is likely reimbursable if your company has a "learning and development" budget.
Building labs.iximiuz.com - a place to help you learn Containers and Kubernetes the fun way 🚀
Hello 👋 Ivan's here with a slightly delayed September roundup of all things Linux, Containers, Kubernetes, and Server Side 🧙 What I was working on This month, I worked on an assorted set of topics. Skill Paths First off, the skill paths! I finally finished the underlying machinery, and now iximiuz Labs supports a new type of content - short roadmaps that you can use to develop or improve a specific skill: how to debug distroless containers, how to copy images from one repository to another,...
Hello friends! Ivan's here with another monthly roundup of all things Linux, Containers, Kubernetes, and Server Side 🧙 The issue's main topic is iximiuz Labs' largest-ever upgrade: Fresher and more streamlined look of the frontend UI 💙 A new 5.10 Linux kernel built with nftables support (finally, we can try out kube-proxy's nftables mode). New default playground user - laborant (yep, rootless containers learning for). New playgrounds: Ubuntu 24.04, Debian Trixie, Fedora, and Incus (yay! more...
Hello friends! Ivan's here with a slightly delayed July roundup of all things Linux, Containers, Kubernetes, and Server Side 🧙 What I was working on This month, I got nerd-sniped by cgroups. It all started when I ran into a pretty significant difference in how Docker and Kubernetes handle the OOM events. When you limit the memory usage of a multi-process Docker container, the OOM killer often terminates only one of the processes if the container runs out of memory. If this process is not the...