Kubernetes' 'Terrible Query Story' Addressed by Vector Databases and AI

Kubernetes users frequently encounter severe limitations when attempting to query cluster resources, a challenge rooted in its underlying etcd key-value store. The ubiquitous kubectl get all command, often perceived as a comprehensive tool, reportedly retrieves only about 10% of actual cluster resources, omitting critical components like Ingresses and Custom Resources. Attempts to access the remaining 90% typically involve arduous, time-consuming bash loops that are prone to missing vital information and are not intuitive for complex queries, such as identifying all databases across diverse resource types. This inefficiency stems from etcd’s design as a state management system, not a relational database, making complex analytical queries inherently difficult.

A proposed solution aims to rectify this “terrible query story” by integrating Kubernetes metadata with a vector database, such as Qdrant, and an AI agent. This architecture involves controllers that actively sync CRDs and resource metadata from the Kubernetes API into the vector database. The vector database then enables both traditional SQL-like queries and advanced semantic search capabilities, allowing users to ask questions in plain English, like “show me all databases,” and receive accurate, contextually relevant answers regardless of specific naming conventions (e.g., ‘DB’, ‘PostgreSQL’, ‘Cloud Native PG’). The system processes requests via an MCP server, which interfaces with AI agents. These agents can perform semantic searches, traditional queries, and even call kubectl for live data like logs. The output can be dynamically presented through web UIs, offering AI-generated insights, diagrams, tables, and visualizations, fundamentally transforming how developers and operators interact with and understand their Kubernetes environments. The approach focuses on syncing less frequently changing metadata to maintain speed and reliability.