Graphs in your head, or how to assess a Kubernetes workload

Bart: Every complex Kubernetes system starts with a simple question: How do you know what's actually happening inside it? In this episode of KubeFM, I spoke with Oleksii, a senior architect at Mirantis, about how he approaches workload assessment, from understanding business requirements to mapping infrastructure, dependencies, and resource interactions across clusters. Oleksii breaks down the mindset and tools that make architecture reviews meaningful, from Helm and K9s to visual frameworks that reveal insights text alone cannot. It's a deeply technical conversation that connects theory to real-world operational insight.

This episode is sponsored by StormForge by CloudFold. Ever wonder how much your Kubernetes workloads are really costing you? Or how much you're wasting? StormForge uses machine learning to automatically right-size your apps, so you can cut spend without cutting performance. It's optimization that just runs in the background while you focus on shipping code. Learn more in the episode description.

Now, let's check out the conversation with Oleksii. Welcome to KubeFM. What three emerging Kubernetes tools are you keeping an eye on?

Oleksii: Besides Kubernetes itself, one of the major products Mirantis currently has is the Cluster API. I keep an eye on it. Then I would say K9s, which I widely use in my daily work. And it might be KubeGraph, an interesting thing I'm looking at.

Bart: I notice that the transcript snippet is very short and lacks context about what is being discussed. Without more context, I cannot confidently add hyperlinks. Could you provide more of the surrounding transcript to help me understand the topic?

Oleksii: Cluster API is a multi-cluster manager. The idea is to have a management cluster that runs a system allowing you to create and manage multiple child Kubernetes clusters and their workloads. It enables managing applications that can be either:

• Actual workloads (like a website or user-specific application)

• Enhancements to the management infrastructure

This provides multi-cluster management for both Kubernetes infrastructure and applications running on top of it.

K9s is a terminal-based viewer for Kubernetes. It allows you to browse Kubernetes resources in a visualized form, offering an alternative to the CLI that provides a different perspective on cluster interactions.

KubeGraph is another tool for visualizing Kubernetes internals. While the speaker is not yet deeply familiar with it, they are interested in exploring its capabilities.

Bart: And now for people who don't know you, can you tell us more about who you are, what you do, and where you work?

Note: In this transcript, I noticed a potential link opportunity for Mirantis, which is the company mentioned where the speaker works.

Oleksii: My name is Oleksii Kolodiazhnyi, I'm from Kharkiv, Ukraine. I work at Mirantis as a senior architect. As an architect, I communicate with customers, help them extract their desires and needs, and form these into requirements. I build requirements in a generalized form and then help design solutions for customers. These solutions might not only involve applying Mirantis technologies but also helping customers build information systems based on their specific requirements and needs.

Bart: I noticed that the transcript snippet is very short and doesn't contain much context. Could you provide more of the transcript so I can properly identify terms that might benefit from hyperlinks?

Oleksii: I wanted to add that it includes a variety of technologies: bare metal, networking, OpenStack, Kubernetes, as well. So Kubernetes is not the only technology that I'm working on.

Bart: Good to keep in mind. How did you get into Cloud Native?

Oleksii: Let's start from the beginning and clarify what Cloud Native is. Can you describe what you think Cloud Native is?

Bart: It means many different things to many different people. I'd like to hear your definition.

Oleksii: Cloud native is a certain clustering that brings up a cloud for distributing resources. A cloud native application is an application that runs natively in this cloud configuration, using cloud capabilities, automation tools, and APIs to run smoothly and efficiently on the platform.

I started working closely with clouds around 13 years ago when I joined Mirantis in 2012. I began my IT journey in 2004 as a system administrator, primarily working with servers—Unix and Linux, occasionally Windows. At that time, I mostly managed single servers or specific clusters like MySQL clustering, storage clustering, and web server clustering.

When I joined Mirantis, I started working closely with OpenStack, which focused on virtualization. Around 2017, I began working with Kubernetes. In 2019, Mirantis adopted Kubernetes and containerization as the primary platform for all our solution footprints. When Mirantis acquired Docker Enterprise, we heavily integrated containerization technologies into our entire product chain, including OpenStack.

OpenStack became Mirantis OpenStack for Kubernetes, which meant we transformed OpenStack services into workloads running on Kubernetes. Since then, all Mirantis products have been built on Kubernetes in one way or another. For the past six years, I have been deeply involved with Kubernetes.

Bart: The Kubernetes and cloud-native ecosystem move very quickly. What works best for you to stay up to date with all the changes happening in terms of resources you can use to learn and not get lost?

Oleksii: I was looking for different ways to get information. I have subscriptions to multiple blogs and websites, mainly in the cloud native and Kubernetes space. My main resource is Reddit. I found that Reddit provides the most recent and interesting discussions, giving me the possibility to explore new repositories, technologies, and decisions. It's my primary source for news around Kubernetes.

Bart: Great. And if you could go back in time, what one career tip would you share with your younger self?

Oleksii: This is an interesting question because I was considering my entire career from the very beginning until now, and I found that I'm happy with everything. I wouldn't give any advice for myself because I think that I went from the ground basics—working with networking, plugging switches, doing wiring, and assembling servers—to architecture. It was actually a way that I believe benefits me most to be efficient in my current position. I'm actually happy with all the steps I took.

Bart: As part of our monthly content discovery, we found an article you wrote titled "Graphs in Your Head, or How to Assess a Kubernetes Workload" (assuming the article is on the Mirantis website). Kubernetes has become the standard for running services, and you've developed a specific procedure for assessing Kubernetes workloads. What initially drove you to create this structured approach?

Oleksii: I wouldn't say that I developed it. Maybe I summarized it in a certain way. There are many frameworks and approaches that describe how an information system should be built and its lifecycle. I took the main idea from these and simplified it in a very straightforward way.

There are books and theories around this topic that are quite hard to consume. I realized there are many articles about specific technologies—how to set up a CI/CD platform, create a repository, or build a pipeline—but not enough articles about the theory of building systems from a high-level, academic perspective.

I was fortunate to understand that during my work, I was doing things that could be interesting for others. Once, I completed an assessment for one of the products—the MSR4 mentioned in the article. I took the outcome of my work, simplified it, and decided to put it into an article to be helpful.

My hope is that if someone is searching for guidance on how to assess an information system and build it either from scratch or on top of an existing foundation, they might find the article interesting.

Bart: You mentioned that graphs are one of humanity's great inventions and you always translate assessment results into graphs. Why is visualization so crucial for understanding Kubernetes workloads?

Oleksii: Why graphs? Let's consider a system with multiple moving parts and components that are connected in certain ways. You can create various combinations of how these components integrate, but ultimately you end up with nodes and connections between them. This is essentially what a graph represents.

You can use a simplified graph with nodes and connecting lines, or you can expand it with additional descriptions and connections as needed. Graphs are an easy way to describe a system.

Another advantage is how easily graphs can present information. Compare giving someone a text list versus a diagram: a visual representation allows information to be consumed much faster. Depending on the audience and the specific information you want to convey, you can create a graph that ranges from simplified to highly detailed.

Bart: It's interesting you mentioned that because we do a monthly content analysis report where we look at thousands of pieces of content in terms of blogs and articles moving around in the ecosystem. We've often noticed a trend that work with visual elements accompanies it often performs much better in terms of engagement and people's response. I think there's a lot of truth to that. Your assessment approach follows a top-down strategy, starting from business understanding. Before diving into technical details, can you walk us through why this sequence matters?

Oleksii: First, we need to examine the difference between business and technical language. For an architect, it is important to understand why the system exists. A good engineer might focus on implementation details, discussing how to make the system efficient and elegant. In contrast, a businessman will emphasize the value, which can always be converted into monetary terms.

As an architect, you need to understand the business needs first, because the system will be built to address specific business cases and requirements. The goal is to bring value to the owner and provide the necessary capacity. The system's aesthetic and ideal structure are secondary to delivering this value, so avoid overcomplicating things.

Start by understanding the business needs with a high-level view, treating the system as a black box. Identify input and output data, system controls, users, and other key elements. Gather comprehensive information about the system before diving into details.

Then, progressively decompose the system, identifying different services or service groups. The level of detail depends on your specific needs. You might focus on services or outline areas like networking, security, data storage, and compute resources, depending on the system's complexity.

By systematically detailing each layer, you'll gain a deeper understanding of how an existing system works or how a new system should be constructed.

Bart: In the high-level assessment phase, you gather business cases and use cases before any technical investigation. How do you effectively extract this information, especially when documentation might be sparse?

Oleksii: As an architect, it's crucial to know how to communicate and identify the right people. When starting a project, first get a list of people responsible for different areas. Begin by contacting the product owner or the person responsible for the business needs of the system. Then, identify contact persons for each system component, such as the network architect or engineer. Your communication should span from the business stakeholder to the final person responsible for user onboarding. The main resource you'll obtain is the subject matter experts from the customer's side.

Bart: Moving into infrastructure assessment, you emphasize understanding the installation method first, particularly favoring Helm charts. Why is the installation mechanism so important to understand early on?

Oleksii: When you're coming to an existing system with an established platform and workload implementation, you need to understand how it works. The easiest way is if it's organized formally, with packages, pipelines, or other methods that automate and describe the communication between installed services. It's crucial to understand not only how something was installed, but also where it was installed from and how it was configured.

From one perspective, a system can be installed in an automated fashion using packages or pipelines. From another perspective, it might have been installed manually by a previous employee who has since left the company. You could end up with a server or cluster running something with no clear documentation, which significantly complicates your approach.

Bart: When it comes to discovering resources in a workload, you use both command-line tools and visual IDEs like Lens. How do you decide which tool to use for different situations?

Oleksii: It depends on the convenience. When you need to do something quick and know what you're looking for—like checking the list of namespaces—it's a simple one-liner command. If you need to view policies, pods, or something that doesn't require complicated filtering or comparison of information outputs, you can use the CLI, which is convenient.

On the other hand, when your request becomes more complex and you need to compare outputs, it's easier to use visualized forms. This could be in the console like k9s, a more graphical tool like Lens, or other tools that visualize structures such as Helm charts. It ultimately depends on the output you need and how quickly and conveniently you want to work with that information.

Bart: KubeView is one of your key tools for visualizing resource interactions within a Helm release. What insights does this visualization provide that you might miss with traditional approaches?

Oleksii: Assessing a system is not very quick, and getting feedback on how the workload looks can be challenging. A visualized form that presents information graphically is very convenient when you need to quickly understand what a workload is about. In this case, the workload was installed with Helm charts, and this tool allows you to assess the Helm chart and generate a plot of the communication between resources. The benefit is that by simply running the tool, you get a plot of the service interactions, based on how the app was configured.

Bart: For developers who prefer terminal-based workflows, you mentioned K9s as a powerful option. How does this tool fit into your assessment workflow, especially for configuration deep dives?

Oleksii: This is exactly why I use K9s. I use it for checking configurations instead of just typing commands and switching between instances, like examining pod configurations. It's much easier to navigate with arrow keys and use hotkeys to jump from one pod to another, or from deployment to deployment. It's similar to using a Console File Manager.

The difference is between manually writing console commands to work with files versus using a file manager that allows you to see the file structure and navigate easily. I also use K9s for looking at logs, which is much easier than reviewing logs in the console. You can view logs one at a time, and this CLI visualization provides a much more convenient way of consuming data.

Bart: The Helm dashboard plugin appears valuable for chart management. What advantages does it offer over standard Helm CLI commands during an assessment?

Oleksii: When you use the CLI, it takes more actions to get the answer about what a Helm chart is for and how it is configured. In contrast, a visual tool allows you to consume information much faster. You can just take one glance at the tree view of the Helm chart configuration and immediately understand what it is about, rather than going through different commands to iteratively gather data.

Bart: You break down requirements into network, storage, hardware, and security categories. How do you ensure nothing falls through the cracks when documenting these diverse aspects?

Oleksii: This is a good question because it addresses the general approach to working with architecture and process. The process is very important to ensure nothing is lost. You need a templated approach upfront that you can enhance and adapt for different situations.

I developed this simplified process to assess workloads. With a template, you know where to start, what information you need to gather, what the outcome will be, how the information will be used, and what the next step is. This is crucial.

Similarly, when you decompose different areas to assess—such as networking, storage, security, or compute—you already have a template, either in your mind or stored as a document skeleton. This template guides the information you need to collect and how to document it.

If you encounter a different system or software, you can sit, think, and adapt your approach to meet particular needs and cases.

Bart: Throughout the article, you use Mirantis Source Registry 4 as a concrete example. Could you share how this assessment framework helped uncover specific insights about MSR's architecture?

Oleksii: At some point, I was pulled in to assess the MSR4 application before its release and provide my vision of the reference architecture. I wasn't very familiar with this release, so I had to go from top to bottom to understand what the development team was keeping in mind, what guided them to create this new release, what changes were made compared to the previous version, what services were involved, why they were involved, what use cases were behind the system, what they had already considered, and what they might have missed.

This is the approach I described in the article, which was the framework I used for assessing this application. Starting from the business cases, I went down to the decomposition of the systems, finding out how they work and how they could work better in different use case scenarios. For example, if you use MSR4 just for testing, you can install it in a single node configuration and it doesn't need database replication. But if you need to install it in a high-availability way, you have to install multiple database replicas that should be replicated.

This approach comes from understanding the use cases, services architecture, their interconnection, and configuration. I used this as an example because I already had certain diagrams prepared, and it was fresh in my memory.

Bart: You emphasize that most tools should run remotely without cluster installation. Why is this remote-first approach important for assessment workflows?

Oleksii: If you are an architect coming to an unfamiliar system, you shouldn't be invasive. You should observe it and be as much as possible a side observer. You don't need to intervene or do anything that may harm the system or bring unnecessary differences in logs or alerts. For example, running a privileged container could raise significant security concerns. Instead, you should do this in a read-only form.

This is the best approach when using your fleet of applications in an already created environment, such as your laptop or a VM used for assessment. You simply spin it up, connect to the endpoint, and gather the needed data. Then, your fleet of applications can combine and generate the outcome you are ready to consume.

Bart: The deliverables from your assessment process include various schemas, diagrams, and requirement documents. How do these artifacts benefit teams beyond the initial assessment?

Oleksii: Documentation is a very important part of architectural work. Engineers usually don't like to do it, but it's the main outcome of the work, baked into diagrams and combined into consumable documentation.

By "consumable," I mean that when writing a document, you need to know the target audience. You must write it in a certain fashion with appropriate terminology. For example, if you're creating a presentation for business persons, you don't need to include technical details because they might be misunderstood and waste valuable time.

A system has its lifecycle, and documentation can be useful beyond the initial assessment. You build a documentation schema that can be used later, such as when a new team member—an administrator or DevOps developer—needs to get up to speed. They can use the documentation to understand why the system was created, how it works, and dive deeper into specific areas of interest.

Structuring documentation from top to bottom makes it easier to navigate and find specific information. For instance, if you need to find a database's replication factor, you can follow a logical path: go to the storage section, find the relevant service, and locate the configuration details.

The key aspects are structure, language, and the framework of documentation.

Bart: You mentioned that not all applications are Kubernetes-native, with some having hard-coded configurations buried in containers. How do you adapt your assessment approach for these challenging cases?

Oleksii: When we started our discussion about cloud-native, it's about adopting the platform's functionality and capabilities to organize an application's work in the most efficient form. For example, in Kubernetes, when you're running an application, it uses secrets, volumes, or structural parts of the platform to store its data, and you know where to search.

On the other hand, when you have a legacy application that was simply virtualized or containerized, you have no idea how to find or access its data. The best initial approach is to find someone who has already done this and extract information from that expert. If that's not possible, you need to improvise and use tools to assess the situation.

You should read about the application, understand its best practices, and try to comprehend how the original implementer might have approached it, and then basically improvise.

Bart: For teams looking to implement a similar assessment framework, what would be your key advice for getting started and avoiding common pitfalls?

Oleksii: I suggest first building a structure and understanding the approach to determine if the process is clear for their use case. Once they understand the approach is applicable, they need to go step by step in their minds on how to conduct the assessment.

What's very important is the role-playing game. As an architect, you wear different hats, putting yourself in the positions of different roles and trying to understand how things should be done from various perspectives—a developer's needs, a business owner's viewpoint. It's a constant exercise of changing perspectives.

Also critical is questioning why you're doing something. When you're working on a topic for weeks, you can get burned out and want to finish the task quickly. But you must stop and consider the purpose and the audience. When you're trying to complete something hastily, you might skip important details or miss key insights.

By rereading what you've written or designed from different perspectives—as a consumer or business owner—you can identify gaps and potential pitfalls you might have overlooked. Changing roles and trying to see things from multiple sides is crucial.

Bart: Oleksii, what's next for you?

Oleksii: Currently, I have a very interesting project running around AI—not just developing AI, but AI as a platform and infrastructure. I think the next step for me would be getting deeper into this area, which is fascinating and might provide some passionate topics to write about.

Bart: How can people get in touch with you?

Oleksii: I hope you will share my LinkedIn page and my working email. It's also available on my LinkedIn page. The best way to communicate is through LinkedIn, which is public and convenient.

Bart: It was wonderful speaking to you and learning about your experience. I hope our paths cross again in the future. Take care.