Flow
Overview
The Flow resource type allows you to orchestrate scaling across multiple K8s and Gcp resources with timing delays. Instead of managing individual scalers independently, a Flow groups them together and coordinates their scaling with optional start and end time offsets per resource.
This is useful for scenarios where resources need to be scaled in a specific order, such as shutting down frontend services before backend databases, or starting databases before application servers.
Spec Structure
apiVersion: kubecloudscaler.cloud/v1alpha3
kind: Flow
metadata:
name: my-flow # Cluster-scoped, no namespace needed
spec:
periods: # Required: time-based scaling rules (with names)
- type: "down"
name: "night" # Name is used to reference periods in flows
time: { ... }
resources: # Required: define the K8s and Gcp resources
k8s:
- name: "my-k8s-resource"
resources: { ... }
config: { ... }
gcp:
- name: "my-gcp-resource"
resources: { ... }
config: { ... }
flows: # Optional: define per-period resource orchestration
- periodName: "night"
resources:
- name: "my-k8s-resource"
startTimeDelay: "0m"
endTimeDelay: "0m"How Flows Work
- Periods define the time windows (same as K8s and Gcp resources)
- Resources define the K8s and Gcp resources to manage, each with their own configuration
- Flows map periods to resources with optional timing delays
When a period becomes active, KubeCloudScaler creates the corresponding K8s and/or Gcp scaler resources automatically. The startTimeDelay and endTimeDelay fields allow staggering the scaling of different resources.
Timing Delays
startTimeDelay: Delays the start of the period for this specific resource. For example,"10m"means this resource starts scaling 10 minutes after the period begins.endTimeDelay: Delays the end of the period for this specific resource. For example,"5m"means this resource stops scaling 5 minutes after the period ends.
Both fields accept a duration in minutes (e.g., "0m", "5m", "30m").
Resource Definitions
K8s Resources in a Flow
Each K8s resource entry defines a named Kubernetes scaler with its own resource selection and configuration:
resources:
k8s:
- name: "frontend-apps" # Unique name for this resource group
resources:
types:
- deployments
labelSelector:
matchLabels:
tier: frontend
config:
namespaces:
- production
restoreOnDelete: trueThe resources and config fields follow the same structure as a standalone K8s resource.
Gcp Resources in a Flow
Each Gcp resource entry defines a named GCP scaler with its own resource selection and configuration:
resources:
gcp:
- name: "dev-vms" # Unique name for this resource group
resources:
types:
- vm-instances
labelSelector:
matchLabels:
environment: development
config:
projectId: my-project
region: us-central1
restoreOnDelete: trueThe resources and config fields follow the same structure as a standalone Gcp resource.
Complete Configuration Examples
Example 1: Coordinated Dev Environment Shutdown
Shut down frontend services first, then backend, then stop GCP VMs:
apiVersion: kubecloudscaler.cloud/v1alpha3
kind: Flow
metadata:
name: dev-environment-flow
spec:
periods:
- type: "down"
name: "night-shutdown"
time:
recurring:
days:
- monday
- tuesday
- wednesday
- thursday
- friday
startTime: "19:00"
endTime: "07:00"
timezone: "Europe/Paris"
resources:
k8s:
- name: "frontend"
resources:
types:
- deployments
labelSelector:
matchLabels:
tier: frontend
config:
namespaces:
- development
restoreOnDelete: true
- name: "backend"
resources:
types:
- deployments
- statefulsets
labelSelector:
matchLabels:
tier: backend
config:
namespaces:
- development
restoreOnDelete: true
gcp:
- name: "dev-vms"
resources:
types:
- vm-instances
labelSelector:
matchLabels:
env: dev
config:
projectId: my-dev-project
region: europe-west1
restoreOnDelete: true
flows:
- periodName: "night-shutdown"
resources:
- name: "frontend"
startTimeDelay: "0m" # Frontend scales down immediately
endTimeDelay: "10m" # Frontend scales up 10min after period ends
- name: "backend"
startTimeDelay: "5m" # Backend scales down 5min after frontend
endTimeDelay: "5m" # Backend scales up 5min after period ends
- name: "dev-vms"
startTimeDelay: "10m" # VMs stop 10min after backend
endTimeDelay: "0m" # VMs start immediately when period endsExample 2: Weekend Shutdown with Staggered Start
Coordinate a weekend shutdown with staggered startup on Monday:
apiVersion: kubecloudscaler.cloud/v1alpha3
kind: Flow
metadata:
name: weekend-flow
spec:
periods:
- type: "down"
name: "weekend"
time:
recurring:
days:
- saturday
- sunday
startTime: "00:00"
endTime: "23:59"
timezone: "Europe/Paris"
resources:
k8s:
- name: "apps"
resources:
types:
- deployments
config:
namespaces:
- staging
restoreOnDelete: true
gcp:
- name: "staging-vms"
resources:
types:
- vm-instances
labelSelector:
matchLabels:
env: staging
config:
projectId: my-project
region: europe-west1
restoreOnDelete: true
flows:
- periodName: "weekend"
resources:
- name: "staging-vms"
startTimeDelay: "0m"
endTimeDelay: "0m" # VMs start first
- name: "apps"
startTimeDelay: "0m"
endTimeDelay: "5m" # Apps start 5min after VMsStatus Monitoring
The Flow resource uses standard Kubernetes conditions to report its state:
status:
conditions:
- type: Available
status: "True"
lastTransitionTime: "2026-02-19T10:00:00Z"
reason: ReconcileSuccess
message: "Flow resources are in sync"
- type: Progressing
status: "False"
lastTransitionTime: "2026-02-19T10:00:00Z"
reason: ReconcileComplete
message: "All resources reconciled"To check the status of individual K8s and Gcp resources created by the Flow, inspect the child resources directly:
# List all K8s scalers (includes those created by flows)
kubectl get k8s
# List all Gcp scalers (includes those created by flows)
kubectl get gcpBest Practices
- Name your periods: Flow resources reference periods by name in the
flowssection, so always set thenamefield on periods - Use timing delays wisely: Start databases before applications, stop frontends before backends
- Test with dry-run: Use
dryRun: trueon individual resource configs before deploying flows - Monitor child resources: The Flow creates K8s and Gcp resources – monitor their status for errors
- Keep delays reasonable: Large delays can cause resources to be out of sync for extended periods
- Use RestoreOnDelete: Enable
restoreOnDeleteon all resource configs to ensure clean cleanup