CAST AI Observation-First Onboarding
Overview
Connect one approved cluster with the recommended castctl path, keep optimization automation off initially, and prove identity, telemetry, ownership, and rollback before expanding control.
Prerequisites
- A named kube context for EKS, GKE, AKS, or a supported CAST AI Anywhere environment
- Cluster-admin access for installation and reviewed least-privilege cloud permissions
- metrics-server when Workload Autoscaling will be evaluated
- An owner, maintenance window, rollback decision, and evidence location
Instructions
Step 1: Establish ownership
Use Read and Grep to locate existing CAST AI, autoscaler, Terraform, Helm, and GitOps definitions. Stop if another controller owns node provisioning or workload HPA behavior and no coexistence decision exists.
Step 2: Preview the connection
Use Bash(castctl:*) to verify the installed client, authenticate interactively to the intended organization, and run the documented connection dry-run. Record detected provider, cluster, region, selected features, namespace, and proposed cloud changes without connecting.
Step 3: Review permissions and features
Confirm least-privilege cloud access and the exact cluster context. Cost Monitoring is always enabled; select Node Autoscaling or Workload Autoscaling only when entitlement, metrics, disruption, and ownership prerequisites are met. Use Write or Edit to capture the approved choices in the repository runbook.
Step 4: Connect the cluster
Run the reviewed castctl connection during the approved window. Do not substitute the deprecated script flow for a supported castctl environment. Preserve the console URL and sanitized command receipt, never browser tokens or API keys.
Step 5: Verify observation mode
Use Bash(kubectl:*) to verify namespace workloads, readiness, events, and metrics prerequisites. Confirm the console receives the intended cluster and cost data while automation remains in the approved state. Allow sufficient data before judging savings or recommendations.
Step 6: Hand off automation separately
Document baseline time, current controllers, policy candidates, protected workloads, and rollback owner. Make automation enablement a separate reviewed change using castai-core-workflow-b.
Tool Discipline
Use Read and Grep to establish source-of-truth ownership. Use Write and Edit for the onboarding record and runbook. Use Bash(castctl:) for documented auth, dry-run, connection, and status operations; use Bash(kubectl:) for bounded verification. Never echo credentials or infer permission scope.
Output
- Reviewed dry-run and permission inventory
- One connected cluster with documented feature state
- Agent and telemetry health evidence
- Baseline and automation handoff record
Examples
An EKS team connects Cost Monitoring first, collects a representative baseline, and delays Node Autoscaling until Karpenter ownership is decided. A GKE team verifies metrics-server before selecting Workload Autoscaling.
Error Handling
| Failure | Response |
|---|---|
| castctl detects the wrong cluster | Stop and correct kube context before connecting |
| Existing provisioner ownership is unclear | Keep optimization disabled and resolve architecture |
| Agent is not ready | Collect events and logs; do not enable automation |
| Cost data is incomplete | Verify telemetry and wait for a representative window |