Kubernetes Integration
How Bluebricks discovers managed Kubernetes clusters through your cloud connections and indexes live cluster state for the agent and context layer.
Kubernetes integration extends the context layer beyond cloud APIs and static Helm chart templates. After you connect AWS, Azure, or GCP with discovery enabled, Bluebricks finds managed clusters in those accounts, polls their APIs, and indexes live workload state so the agent can answer questions about what is actually running.
You do not connect Kubernetes as a separate cloud provider in the app today. Cluster visibility uses the same discovery collection and cloud account as your AWS, GCP, or Azure connection. For cloud connection basics, see Connect your Cloud.
Ask the agent. Query live cluster state through natural conversation after discovery completes. See Agent overview.
What this integration includes
Cluster detection
Managed clusters (EKS, GKE, AKS) are discovered during cloud inventory scans
Live object indexing
Workloads such as Deployments, Jobs, Pods, Services, Ingresses, and ConfigMaps are synced into the context layer
Helm correlation
Live objects link to Helm releases and chart templates when standard Helm labels are present
Cloud linkage
Objects connect to the underlying cluster and load balancers already modeled as cloud resources
This is distinct from Helm orchestration (deploying charts through environments) and from the self-hosted runner (running the Bluebricks Deployments Controller inside your cluster).
How it works
Connect a cloud account with discovery on a collection, using AWS, GCP, or Azure.
Bluebricks runs a read-only cloud scan and discovers managed Kubernetes clusters in that account or project.
For each cluster, Bluebricks syncs live workload state from the Kubernetes API using credentials from your cloud connection. No agent pod runs inside your cluster.
Synced objects enter the context layer and link to Helm releases, infrastructure code, and related cloud resources. You query those relationships through the agent, not through the Cloud Graph canvas.
Supported managed clusters
AWS
Amazon EKS
GCP
Google Kubernetes Engine (GKE)
Azure
Azure Kubernetes Service (AKS) and Arc-connected clusters
Clusters that never appear in cloud discovery for a connected account are outside this integration. That includes on-premises kubeconfig-only clusters and local development clusters not registered with EKS, GKE, or AKS. Use the self-hosted runner when you need orchestration against a cluster Bluebricks does not discover from a public cloud API.
Chart intent vs live cluster state
The context layer has long reflected Kubernetes intent from Helm chart sources in your connected repositories. Kubernetes integration adds live state:
Source
Chart files in connected Git repos
Kubernetes API on discovered clusters
Represents
What the chart declares
What is running now (status, failures, labels)
Example question
"What does this chart deploy?"
"Why did this Job fail in production?"
The agent can relate a failed Job to its Helm release, the blueprint or Terraform that owns the cluster, and cloud resources such as load balancers fronting an Ingress.
Prerequisites
A collection linked to AWS, GCP, or Azure with discovery enabled on the cloud connection
At least one managed Kubernetes cluster in that account or project that cloud discovery can list
Discovery credentials that can authenticate to the cluster API through the cloud provider
For discovery vs orchestration permission types, see Connect your Cloud.
Required permissions
Kubernetes integration reuses discovery permissions on your cloud connection; it does not add a separate permission type in the app.
Your discovery role or service account must be able to:
List and describe managed Kubernetes clusters in the cloud API (for example EKS, GKE, or AKS control planes)
Obtain short-lived credentials to call the Kubernetes API for those clusters through the provider's supported mechanism
If cluster objects never appear after a successful cloud connection, verify discovery can see the cluster in the cloud console and that the discovery role has not been scoped down to exclude Kubernetes services.
Network access and IP whitelisting
Kubernetes indexing calls your cluster API from the Bluebricks platform over HTTPS (port 443). Traffic is outbound from Bluebricks to your API server endpoint, not from a pod inside your cluster.
If the control plane is private or restricted by IP allowlists, allow the Bluebricks egress IP ranges on the cluster API before live object sync can succeed. Cloud discovery may still list the cluster even when API polling is blocked.
Apply those ranges using your provider's control plane access settings:
AWS (EKS)
Public endpoint access and security groups or EKS public endpoint CIDR restrictions on the cluster API
GCP (GKE)
Authorized networks on the control plane
Azure (AKS)
Authorized IP ranges on the API server
Private-only API servers If the Kubernetes API is reachable only inside a VPC or private link with no path from the public internet, Bluebricks cannot poll it with the current managed-cluster integration. You will still see the cluster in cloud inventory, but live workload indexing will not run until API access from the whitelisted Bluebricks IPs is possible. For private endpoints or other restricted topologies, contact support to discuss a custom connection.
Verify integration is working
After discovery completes on the collection:
Open the agent and ask a cluster-scoped question, for example: "List failed Jobs in the production EKS cluster" or "Which Ingress fronts this load balancer?"
Confirm the agent returns answers grounded in live status (pod phases, Job conditions, Ingress hostnames), not only chart YAML
That is the supported way to validate live workload indexing. Indexed Kubernetes objects feed the context layer behind the agent; there is no separate in-app graph for browsing Pods, Jobs, or Ingress relationships.
The Cloud Graph is a separate surface. It visualizes collections, environments, and cloud resources from discovery (managed vs. unmanaged, codification). You may see a managed cluster there as a cloud resource (for example an EKS cluster in inventory), but the Cloud Graph does not chart live Pods, Jobs, Ingresses, or Helm-to-workload relationships. Use the agent for that.
Indexing runs on a schedule with cloud discovery. New clusters may take until the next discovery cycle to appear.
Limitations
These constraints match what Connect your Cloud supports today. They apply to live workload indexing for the agent and context layer, not to Helm deployments or the self-hosted runner.
No Kubernetes-only cloud connection
The app connects AWS, GCP, or Azure accounts only. There is no separate flow to attach a cluster by kubeconfig or API URL alone. Enable discovery on one of those cloud connections first.
Managed clusters from cloud inventory
Live indexing runs for EKS, GKE, and AKS (including Arc-connected clusters) that cloud discovery lists in your account or project. If the cluster does not show up in the provider console as a managed cluster resource, Bluebricks cannot index its workloads through this feature.
No in-cluster discovery software
Bluebricks polls the Kubernetes API from its platform. You do not install a Bluebricks DaemonSet, operator, or agent in the cluster for this integration.
Built-in resource kinds only
Standard types such as Deployments, Jobs, Pods, Services, Ingresses, ConfigMaps, StatefulSets, and CronJobs are synced. Custom resources (CRDs) are not indexed.
Agent, not Cloud Graph, for live workloads
The Cloud Graph shows cloud inventory and orchestration structure, not an interactive graph of in-cluster objects. Live Kubernetes questions and cross-links (Job to Helm release, Ingress to load balancer) are available through the agent.
Related documentation
Connect your Cloud: cloud providers and discovery vs orchestration permissions
Cloud Graph: cloud resource inventory and environments (not live in-cluster workload graph)
Helm artifacts: deploying to connected clusters through orchestration
Network access requirements: domain and IP whitelist for Bluebricks services
Self-hosted runner: running deployments inside your own cluster
Last updated
Was this helpful?