Status: Accepted Date: 2024-11-21 Deciders: Platform Architecture Team Technical Story: Initial platform architecture design
We needed to build an AI automation platform that could:
- Execute long-running AI agent sessions
- Isolate execution environments for security
- Scale based on demand
- Integrate with existing OpenShift/Kubernetes infrastructure
- Support multi-tenancy
How should we architect the platform to meet these requirements?
- Multi-tenancy requirement: Need strong isolation between projects
- Enterprise context: Red Hat runs on OpenShift/Kubernetes
- Resource management: AI sessions have varying resource needs
- Security: Must prevent cross-project access and resource interference
- Scalability: Need to handle variable workload
- Operational excellence: Leverage existing K8s operational expertise
- Kubernetes-native with CRDs and Operators
- Traditional microservices on VMs
- Serverless functions (e.g., AWS Lambda, OpenShift Serverless)
- Container orchestration with Docker Swarm
Chosen option: "Kubernetes-native with CRDs and Operators", because:
- Natural multi-tenancy: K8s namespaces provide isolation
- Declarative resources: CRDs allow users to declare desired state
- Built-in scaling: K8s handles pod scheduling and resource allocation
- Enterprise alignment: Matches Red Hat's OpenShift expertise
- Operational maturity: Established patterns for monitoring, logging, RBAC
Positive:
- Strong multi-tenant isolation via namespaces
- Declarative API via Custom Resources (AgenticSession, ProjectSettings, RFEWorkflow)
- Automatic cleanup via OwnerReferences
- RBAC integration for authorization
- Native integration with OpenShift OAuth
- Horizontal scaling of operator and backend components
- Established operational patterns (logs, metrics, events)
Negative:
- Higher learning curve for developers unfamiliar with K8s
- Requires K8s cluster for all deployments (including local dev)
- Operator complexity vs. simpler stateless services
- CRD versioning and migration challenges
- Resource overhead of K8s control plane
Risks:
- CRD API changes require careful migration planning
- Operator bugs can affect many sessions simultaneously
- K8s version skew between dev/prod environments
Architecture Components:
-
Custom Resources (CRDs):
- AgenticSession: Represents AI execution session
- ProjectSettings: Project-scoped configuration
- RFEWorkflow: Multi-agent refinement workflows
-
Operator Pattern:
- Watches CRs and reconciles desired state
- Creates Kubernetes Jobs for session execution
- Updates CR status with results
-
Job-Based Execution:
- Each AgenticSession spawns a Kubernetes Job
- Job runs Claude Code runner pod
- Results stored in CR status, PVCs for workspace
-
Multi-Tenancy:
- Each project = one K8s namespace
- RBAC enforces access control
- Backend validates user tokens before CR operations
Key Files:
components/manifests/base/*-crd.yaml- CRD definitionscomponents/operator/internal/handlers/sessions.go- Operator reconciliationcomponents/backend/handlers/sessions.go- API to CR translation
Success Metrics:
- ✅ Multi-tenant isolation validated via RBAC tests
- ✅ Sessions scale from 1 to 50+ concurrent executions
- ✅ Zero cross-project access violations in testing
- ✅ Operator handles CRD updates without downtime
Lessons Learned:
- OwnerReferences critical for automatic cleanup
- Status subresource prevents race conditions in updates
- Job monitoring requires separate goroutine per session
- Local dev requires kind/CRC for K8s environment
- Kubernetes Operator Pattern
- Custom Resource Definitions
- Related: ADR-0002 (User Token Authentication)