castai-reference-architectureDesign a CAST AI reference architecture that separates hosted control-plane services, in-cluster components, cloud permissions, delivery ownership, and Kubernetes scaling controls. Use when reviewing architecture, planning multi-cluster rollout, or mapping responsibilities. Trigger with: "design CAST AI architecture", "map CAST AI components", "review CAST …
Independent GitHub snapshot · Automated classification · Original documentation governs
name: castai-reference-architecture description: 'Design a CAST AI reference architecture that separates hosted control-plane services, in-cluster components, cloud permissions, delivery ownership, and Kubernetes scaling controls. Use when reviewing architecture, planning multi-cluster rollout, or mapping responsibilities. Trigger with: "design CAST AI architecture", "map CAST AI components", "review CAST AI control planes".' allowed-tools: Read, Grep, Write, Edit version: 2.0.0 argument-hint: '[estate-or-cluster-scope]' model: inherit effort: high license: MIT author: Jeremy Longshore jeremy@intentsolutions.io tags:
Describe the real control and data paths for one estate. Avoid a generic vendor diagram: show where identity, telemetry, recommendations, mutations, cloud provisioning, GitOps, and operator approvals actually cross boundaries.
Use Read and Grep to map CAST AI hosted services, regional API base, enterprise or organization identity, cloud accounts, Kubernetes API servers, CI, GitOps controllers, secret managers, and operator workstations.
Represent the unified umbrella chart and its selected tag mode. Shared components include the agent, spot handler, and Kvisor; automation modes add controllers, evictor, pod mutator, workload autoscaler/exporter, pod pinner, or live-migration components as documented. Do not show every component as present unconditionally.
Separate observation snapshots, cost telemetry, workload recommendations, mutating admission, Eviction API operations, native HPA management, pending-pod observation, node provisioning, and cloud API calls. Label which paths read, recommend, mutate, or provision.
Show human castctl login, service API keys, enterprise child-organization targeting, Kubernetes service accounts, cloud IAM, and optional Kvisor capabilities. Link each privilege to a feature and identify the revocation owner.
Use Write or Edit to declare whether castctl, Terraform, Helm GitOps, console, or workload annotations own each setting. Highlight conflicts with Karpenter, cloud autoscalers, native HPAs, and manual console changes.
Include regional API loss, agent disconnect, missing metrics, webhook failure, exhausted cloud quota, unsatisfied node template, PDB denial, and bad policy rollout. Show observation continuity, fail-safe behavior, escalation, and rollback authority.
Use Read and Grep for repository and environment evidence. Use Write and Edit for the architecture record and diagram source. Do not infer selected features, components, permissions, or network reachability from a default installation.
A read-only cluster shows telemetry components but no node provisioner. A full-mode cluster shows CAST AI workload recommendations and node provisioning while GitOps remains the sole authority for chart values and policy definitions.
| Failure | Response |
|---|---|
| Selected umbrella mode is unknown | Mark components unresolved and inspect the release |
| Two systems own the same control | Surface an architecture decision, not a silent merge |
| Network path is assumed | Label it unverified until tested |
| Permission cannot be tied to a feature | Treat it as excess privilege for review |