Introducing Plural's Tree View: A Technical Deep Dive
Your monitoring dashboard shows 66 out of 67 services as healthy. But your application is down, users are complaining, and alerts are firing across multiple channels. This is THE question that keeps platform engineers awake at night: which specific component in your sprawling Kubernetes infrastructure is actually broken?
While Kubernetes organizes resources in clear hierarchical relationships, there's no API to actually query these relationships. The deeper your resource hierarchies go, the more painful troubleshooting becomes. What should be a quick diagnosis turns into a forensic investigation across multiple terminal windows.
At Plural, we've experienced this pain firsthand while building our infrastructure deployment platform. That's why we built our new Tree View feature—a visual representation that shows you exactly which resources created which, their current health status, and where failures are actually occurring.
In this article, we'll cover the engineering decisions behind building this system, why SQLite became our persistence layer of choice and show you how this approach transforms both human and AI-powered infrastructure analysis.
Architecture Overview: Building the Caching Layer
Tree View tackles the limitations of the Kubernetes API head-on by creating a local cache of your entire cluster state. Instead of making individual API calls every time you need to trace resource relationships, we maintain a complete, queryable representation of all Kubernetes objects and their owner references locally.
The architecture centers on three core components working together. First, we integrate with Kubernetes Watch APIs to stream real-time changes for every resource type in your cluster, including custom resources that might be added while our agent runs. This ensures our local cache stays synchronized with cluster state without the overhead of polling.
Second, we persist this data in SQLite, which serves as both our storage and indexing layer. We store the minimal metadata needed for relationship mapping: resource identity, owner references, and health status. SQLite's embedded nature means no external database dependencies, while its indexing capabilities enable efficient queries across arbitrarily complex resource hierarchies.
Third, we built a recursive query engine that reconstructs resource trees on demand. When you want to see all child resources of a failing Deployment, we use SQL's WITH RECURSIVE syntax to traverse owner reference chains and build complete hierarchical views.
Real-time Data Streaming
For every resource type in Kubernetes (pods, deployments, services, ingresses), there's a corresponding watch API that establishes an event stream of all changes happening to those resources. You can watch all pods in a namespace, all deployments across a cluster, or any other combination of resources and scopes.
That's how we keep Tree View up to date: we watch every single API resource type, including custom resource definitions (CRDs). This is important because new API resources can be dynamically added to your cluster while our agent is running. When someone installs a new operator or adds a custom resource, we automatically discover it and begin streaming those changes as well.
Rather than storing complete resource manifests, we compress the data to just what we need for relationship mapping. Each resource gets reduced to its essential identity information (namespace, name, API version, and kind) plus its owner references and current health status. This compression keeps our SQLite database lean while maintaining all the data necessary for tree reconstruction.
The event stream approach means that our local cache reflects the true state of your infrastructure, without the need to constantly poll for changes. But streaming all these resource changes is only half the equation—we need a robust way to store, index, and query this data for rapid tree reconstruction. That's where SQLite comes in.
SQLite Integration
We stream all these resource changes into an in-memory SQLite database. This choice might seem unconventional for a real-time system, but SQLite provides exactly what we need: a robust, indexable persistence layer that requires no external dependencies and enables complex recursive queries.
Running SQLite in memory gives us the performance benefits of RAM-based access while maintaining the reliability and query capabilities of a proper database. We need structured data with relationships that can be efficiently queried and indexed.
Our schema design focuses specifically on enabling owner reference relationships, with the real power coming from how we index this data.
SQLite's indexing capabilities let us create efficient lookups on owner references, which is crucial for the recursive queries that reconstruct resource trees. With the right indexes in place, we can quickly find all child resources of any given parent, or traverse up the ownership chain to find root resources.
This database gives us a single source of truth for our agent's understanding of your cluster state, updated in real-time from the watch API streams and optimized for the tree traversal queries that power the Tree View interface.
Tree Reconstruction Algorithm
With our SQLite database populated and indexed, reconstructing resource trees becomes a straightforward SQL operation. When you want to see the complete hierarchy for a Plural service, we use SQL's WITH RECURSIVE syntax to traverse the owner reference chains and build the entire tree structure.
The process works on-demand: we start with the list of parent resources that were created when you instantiated a Plural service, then recursively query for all their child resources.
And whether your service creates a simple three-level hierarchy or a complex ten-level tree with custom operators and CRDs, this recursive traversal scales efficiently. The SQLite indices enable fast lookups at each level of recursion, preventing the query from slowing down as it traverses deeper into the ownership chain.
This allows us to generate the entire tree with current health statuses in a single query operation, no matter how deeply your resources are nested. No multiple API calls, no manual correlation of kubectl outputs—just one SQL query that gives you the complete picture of which resources are healthy and which are failing, all organized in their proper hierarchical relationships.
What This Means for You
Enhanced Troubleshooting
Tree View transforms the troubleshooting experience by giving you complete object relationships at a glance. Instead of running multiple kubectl commands and mentally correlating outputs, you can immediately see which component in your infrastructure is broken and how it relates to your top-level services.
Without Tree View, this is an in-depth detective investigation.
With Tree View, the failure attribution is immediate and visual. You can see that your healthy service is actually composed of multiple child resources (deployments, replica sets, pods, ingresses, monitoring scrapes), and quickly identify which specific component is failing.
This visual hierarchy is particularly valuable for complex service deployments that involve custom resources and operators and gives you the debugging superpowers you need, whether you have one resource or 100.
AI-powered Infrastructure Analysis
Beyond improving human troubleshooting, Tree View provides crucial context for AI-powered infrastructure analysis. When our AI engine encounters a failure, it can use the complete tree hierarchy to understand relationships between resources, even when dealing with custom resources that it hasn't been specifically trained to recognize.
This is particularly valuable for CRDs and operator-managed resources. When investigating a failure, our AI engine can examine parent resources for configuration issues, check sibling resources for patterns, and drill down into child resources to identify root causes. This contextual understanding leads to more comprehensive infrastructure insights, especially in complex environments with deep resource hierarchies and custom operators.
Looking to the Future
Tree View represents more than just better debugging—it's the foundation for AI-powered infrastructure tooling. As AI systems become more sophisticated at managing infrastructure, the patterns we've established (local caching, real-time synchronization, and efficient relationship querying) will likely become standard in AI-driven infrastructure platforms.
As Kubernetes environments grow more complex with deeper operator hierarchies, manual kubectl correlation becomes untenable. Tools providing visual, queryable resource relationships will shift from nice-to-have to essential. For platform engineering teams, this infrastructure introspection enables better internal developer platforms with the visibility needed for reliable self-service capabilities.
While tools like ArgoCD have tackled similar challenges, our approach provides a general solution that works for any Kubernetes resources, regardless of how they were deployed.
Wrapping Up
Building Tree View required overcoming a fundamental limitation in the Kubernetes API—the inability to query resource relationships that clearly exist in the system. Our solution—combining Watch APIs, SQLite caching, and recursive SQL queries—demonstrates that seemingly intractable infrastructure problems often have elegant technical solutions when approached creatively.
The practical impact extends beyond debugging interfaces. By providing both human operators and AI systems with queryable infrastructure relationships, Tree View enables more effective troubleshooting and opens new possibilities for intelligent infrastructure management.
The broader lesson: when existing APIs don't provide the data you need, building the right caching and querying layer can unlock capabilities that transform how teams interact with their systems. As Kubernetes environments grow more complex and AI becomes more central to operations, this pattern will become increasingly valuable.
Try Tree View today
Ready to simplify how your team manages microservices?
Book a demo to see Tree View in action, or sign up to get started with Plural.