01
Kubernetes clusters
Resources, status, placement and supported changes
One official provider instance per cluster
IT & platform operations
Operate across clusters, APIs and databases as one model.
Platform teams already have the data. The hard part is resolving a service, its owner, its deployments and its current incidents across systems that were never designed to answer together.
operational question
Which failing deployments affect customer-facing services, and who owns the next action?
useful answer
Join live Kubernetes resources to application inventory, ownership and incident data. The result stays traceable to each source, and supported changes go back through the provider that owns them.
statecontextaction
The systems involved
Trace the service across the systems that define it.
Cluster state is only one part of the answer. Ownership, repositories and incidents stay authoritative in their own systems.
02
Service APIs
Repositories, incidents, deployments and business state
OpenAPI provider
03
Operational databases
Applications, customers, ownership and policy
Native database sources or providers
04
Other Kubling domains
Models already owned by another team or site
Instance-to-instance federation
The operational model
Follow a service.
The model carries identity across source boundaries. A service can resolve to its deployment, cluster, repository, incident and owner without an agent guessing how those names relate.
service
deployed_as
workload
workload
runs_in
cluster
repository
produces
deployment
incident
affects
service
team
owns
service
01
Start with the service
Resolve a business-facing service to the workloads, repositories and teams behind it.
02
Read current state
Query the clusters and APIs in place instead of reasoning over another delayed copy.
03
Use advertised capabilities
The planner pushes down only the operations each provider says it can preserve.
A real federation pattern
API state and cluster state in one query.
The screenshot below is a real federated query pattern: an API, application inventory and Kubernetes data resolved by one engine plan.
Deployment topology
Let each platform domain keep a clear boundary.
A global view is an option for cross-team questions, not a prerequisite for every cluster query.
Cluster or system view
One clear owner
Give a cluster, API group or platform system its own deployable Kubling boundary.
Platform domain view
Join related systems
Aggregate the instances needed for a team, region or internal platform.
Organization view, if useful
No mandatory center
Federate domains for cross-team questions without forcing every query through one global instance.
System, domain and cross-domain describe roles in a topology, not products you must deploy as a fixed stack. A Kubling instance can use local providers, federate other Kubling instances, or do both.
Available now
Build from current capabilities.
Kubernetes and OpenAPI are current external providers. Both expose their exact model and capabilities through the same public provider contract.
Kubernetes provider
Discovers listable resources dynamically and keeps the cluster identity stable in the federated model.
Inspect the providerOpenAPI provider
Discovers safe reads from OpenAPI 3.x and enables writes only through explicit mappings.
Inspect the providerProvider quickstart
The in-memory sample exercises health, schema import, queries and mutations through the production provider contract.
Run it locallyStart with proof
Prove it with one source. Grow without changing the execution model.
Query and mutate through a local provider, then replace the source when you are ready. The engine still plans against the same schema and capability contract.