Application Specification¶
Learn how to define applications for Orchestry using YAML or JSON specifications.
Overview¶
Orchestry uses declarative specifications to define how your applications should be deployed, scaled, and monitored. These specifications are written in YAML or JSON format and contain all the information needed to run your application.
Basic Structure¶
apiVersion: v1
kind: App
metadata:
name: my-application
labels:
app: "my-application"
version: "v1"
environment: "production"
spec:
# Application configuration
type: http
image: "my-app:latest"
ports: []
resources: {}
environment: []
scaling:
# Scaling configuration
mode: auto
minReplicas: 1
maxReplicas: 5
healthCheck:
# Health check configuration
path: "/health"
port: 8080
Complete Reference¶
Root Fields¶
| Field | Type | Required | Description |
|---|---|---|---|
apiVersion |
string | Yes | API version (currently v1) |
kind |
string | Yes | Resource type (currently App) |
metadata |
object | Yes | Application metadata |
spec |
object | Yes | Application specification |
scaling |
object | No | Scaling configuration |
healthCheck |
object | No | Health check configuration |
Metadata¶
The metadata section contains information about your application:
metadata:
name: my-web-app # Required: DNS-compatible name
labels:
app: "my-web-app" # Required: Application identifier
version: "v1.2.3" # Recommended: Version tag
environment: "production" # Optional: Environment label
team: "backend" # Optional: Team ownership
tier: "web" # Optional: Application tier
Fields:
| Field | Type | Required | Description |
|---|---|---|---|
name |
string | Yes | Unique application name (DNS-compatible) |
labels |
object | Yes | Key-value labels for organization |
labels.app |
string | Yes | Application identifier (must match name) |
Label Restrictions: - Must be DNS-compatible (lowercase, alphanumeric, hyphens) - Maximum 63 characters per label value - Cannot start or end with hyphens
Application Spec¶
The spec section defines how your application runs:
spec:
type: http # Application type
image: "nginx:alpine" # Container image
ports: # Port configuration
- containerPort: 80
protocol: HTTP
resources: # Resource limits
cpu: "500m"
memory: "512Mi"
environment: # Environment variables
- name: NODE_ENV
value: "production"
- name: DATABASE_URL
value: "postgresql://..."
command: ["/bin/sh"] # Optional: Override entrypoint
args: ["-c", "nginx -g 'daemon off;'"] # Optional: Command arguments
workingDir: "/app" # Optional: Working directory
volumes: # Optional: Volume mounts
- name: "app-data"
mountPath: "/data"
Application Types¶
| Type | Description | Use Cases |
|---|---|---|
http |
HTTP web applications | Web servers, APIs, SPAs |
Ports Configuration¶
ports:
- containerPort: 8080 # Port inside container
protocol: HTTP # Protocol (HTTP)
name: "web" # Optional: Port name
Protocol Types:
- HTTP: For web applications (enables load balancing)
Resources¶
Define CPU and memory limits:
CPU Units:
- 100m = 0.1 CPU core
- 1 = 1 CPU core
- 2.5 = 2.5 CPU cores
Memory Units:
- 128Mi = 128 MiB
- 1Gi = 1 GiB
- 512M = 512 MB
Environment Variables¶
environment:
# Static value
- name: NODE_ENV
value: "production"
# Orchestry-provided values
- name: INSTANCE_IP
source: sdk
key: "instance.ip"
# From secrets (future feature)
- name: DB_PASSWORD
source: secret
key: "database-credentials"
field: "password"
SDK-Provided Variables:
| Key | Description | Example Value |
|---|---|---|
instance.ip |
Container IP address | 172.20.0.5 |
instance.port |
Primary container port | 8080 |
app.name |
Application name | my-web-app |
app.replicas |
Current replica count | 3 |
Volumes (Future Feature)¶
volumes:
- name: "app-data"
mountPath: "/data"
size: "10Gi"
storageClass: "fast"
- name: "config"
mountPath: "/etc/config"
configMap: "app-config"
Scaling Configuration¶
Control how your application scales:
scaling:
mode: auto # Scaling mode: auto, manual
minReplicas: 1 # Minimum replicas
maxReplicas: 10 # Maximum replicas
# Auto-scaling thresholds
targetRPSPerReplica: 50 # Target requests per second per replica
maxP95LatencyMs: 250 # Maximum 95th percentile latency
maxCPUPercent: 70 # Maximum CPU utilization
maxMemoryPercent: 75 # Maximum memory utilization
maxConnPerReplica: 100 # Maximum connections per replica
# Scaling behavior
scaleOutThresholdPct: 80 # Scale out when metrics exceed this %
scaleInThresholdPct: 30 # Scale in when metrics below this %
windowSeconds: 60 # Metrics evaluation window
cooldownSeconds: 180 # Minimum time between scaling events
Scaling Modes¶
| Mode | Description | When to Use |
|---|---|---|
auto |
Automatic scaling based on metrics | Production workloads |
manual |
Manual scaling only | Development, controlled environments |
Scaling Metrics¶
Orchestry scales based on multiple metrics:
- CPU Utilization: Target 70% average across replicas
- Memory Usage: Target 75% average across replicas
- Requests Per Second: Target 50 RPS per replica
- Response Latency: Keep P95 latency under 250ms
- Active Connections: Target 100 connections per replica
Scaling Behavior¶
scaling:
# Threshold configuration
scaleOutThresholdPct: 80 # Scale out when any metric > 80% of target
scaleInThresholdPct: 30 # Scale in when all metrics < 30% of target
# Timing configuration
windowSeconds: 60 # Evaluate metrics over 60 seconds
cooldownSeconds: 180 # Wait 3 minutes between scaling actions
# Advanced settings (optional)
maxScaleOutStep: 2 # Maximum replicas to add at once
maxScaleInStep: 1 # Maximum replicas to remove at once
stabilizationWindowSeconds: 300 # Wait for stability after scaling
Health Check Configuration¶
Define how Orchestry monitors your application health:
healthCheck:
path: "/health" # Health check endpoint
port: 8080 # Health check port
protocol: HTTP # Protocol (HTTP, TCP)
method: GET # HTTP method (GET, POST)
# Timing configuration
initialDelaySeconds: 30 # Wait before first check
periodSeconds: 10 # Check interval
timeoutSeconds: 5 # Request timeout
# Failure handling
failureThreshold: 3 # Failures before marking unhealthy
successThreshold: 1 # Successes before marking healthy
# Advanced options
headers: # Custom headers
- name: "Authorization"
value: "Bearer token"
expectedStatusCodes: [200, 204] # Expected HTTP status codes
Health Check Types¶
HTTP Health Checks:
healthCheck:
path: "/api/health"
port: 8080
protocol: HTTP
method: GET
expectedStatusCodes: [200]
headers:
- name: "User-Agent"
value: "Orchestry-HealthCheck/1.0"
Custom Health Checks:
healthCheck:
path: "/health/detailed"
port: 8080
protocol: HTTP
method: POST
headers:
- name: "Content-Type"
value: "application/json"
body: '{"check": "full"}'
expectedStatusCodes: [200, 202]
Complete Examples¶
Simple Web Application¶
apiVersion: v1
kind: App
metadata:
name: simple-web
labels:
app: "simple-web"
version: "v1"
spec:
type: http
image: "nginx:alpine"
ports:
- containerPort: 80
protocol: HTTP
resources:
cpu: "100m"
memory: "128Mi"
scaling:
mode: auto
minReplicas: 1
maxReplicas: 3
targetRPSPerReplica: 100
healthCheck:
path: "/"
port: 80
initialDelaySeconds: 5
periodSeconds: 30
Production API Service¶
apiVersion: v1
kind: App
metadata:
name: user-api
labels:
app: "user-api"
version: "v2.1.0"
environment: "production"
team: "backend"
spec:
type: http
image: "myregistry/user-api:v2.1.0"
ports:
- containerPort: 8080
protocol: HTTP
name: "api"
resources:
cpu: "1000m"
memory: "2Gi"
environment:
- name: NODE_ENV
value: "production"
- name: PORT
value: "8080"
- name: DATABASE_URL
source: secret
key: "database-credentials"
- name: REDIS_URL
source: secret
key: "redis-credentials"
- name: INSTANCE_IP
source: sdk
key: "instance.ip"
scaling:
mode: auto
minReplicas: 3
maxReplicas: 20
targetRPSPerReplica: 100
maxP95LatencyMs: 200
maxCPUPercent: 70
maxMemoryPercent: 80
scaleOutThresholdPct: 75
scaleInThresholdPct: 25
windowSeconds: 120
cooldownSeconds: 300
healthCheck:
path: "/api/v2/health"
port: 8080
protocol: HTTP
method: GET
initialDelaySeconds: 45
periodSeconds: 15
timeoutSeconds: 10
failureThreshold: 3
successThreshold: 1
headers:
- name: "Authorization"
value: "Bearer health-check-token"
expectedStatusCodes: [200]
Validation Rules¶
Orchestry validates specifications before deployment:
Required Fields¶
apiVersion: Must bev1kind: Must beAppmetadata.name: Must be DNS-compatiblemetadata.labels.app: Must matchmetadata.namespec.type: Must behttpspec.image: Must be a valid container image reference
Naming Conventions¶
Application Names: - Lowercase letters, numbers, and hyphens only - Must start and end with alphanumeric character - Maximum 253 characters - Must be unique within Orchestry instance
Label Values: - Same rules as application names - Maximum 63 characters
Resource Limits¶
CPU:
- Minimum: 10m (0.01 CPU)
- Maximum: 16 (16 CPUs)
- Must be positive number
Memory:
- Minimum: 64Mi (64 MiB)
- Maximum: 64Gi (64 GiB)
- Must be positive number
Scaling Limits¶
minReplicas: 1-100maxReplicas: 1-100, must be ≥minReplicastargetRPSPerReplica: 1-10000maxP95LatencyMs: 1-30000- Percentages: 1-100
Best Practices¶
Application Design¶
- Stateless Applications: Design apps to be stateless for easy scaling
- Health Endpoints: Always provide meaningful health check endpoints
- Graceful Shutdown: Handle SIGTERM signals for graceful shutdown
- Resource Limits: Set appropriate CPU and memory limits
- Environment Configuration: Use environment variables for configuration
Scaling Configuration¶
- Conservative Limits: Start with conservative scaling limits
- Monitoring: Monitor scaling behavior and adjust thresholds
- Cooldown Periods: Use appropriate cooldown periods to prevent flapping
- Multiple Metrics: Don't rely on a single metric for scaling decisions
Production Readiness¶
- Health Checks: Configure comprehensive health checks
- Resource Monitoring: Set up monitoring and alerting
- Version Tags: Always use specific version tags, not
latest - Security: Use minimal base images and security scanning
- Backup Strategy: Plan for data backup and recovery
Development Workflow¶
- Validate Locally: Test specifications locally before deployment
- Version Control: Store specifications in version control
- Environment Promotion: Use different specifications per environment
- Documentation: Document application-specific configuration
Troubleshooting¶
Common Validation Errors¶
Invalid Name:
Error: metadata.name must be DNS-compatible
Solution: Use lowercase letters, numbers, and hyphens only
Missing Required Fields:
Invalid Resource Format:
Error: resources.cpu must be a valid quantity (e.g., "500m", "1")
Solution: Use proper CPU units (millicores or cores)
Scaling Configuration Issues:
Error: scaling.maxReplicas must be >= scaling.minReplicas
Solution: Ensure maxReplicas is greater than or equal to minReplicas
Deployment Issues¶
Image Pull Errors: - Verify image exists and is accessible - Check registry credentials - Use full image path with registry
Health Check Failures: - Verify health endpoint is accessible - Check port configuration - Increase initial delay if needed
Resource Constraints: - Monitor actual resource usage - Adjust limits based on application needs - Consider node capacity limits
Next Steps: Learn about Configuration and Environment Variables for advanced settings.