---
title: "Scaling & Autoscaling"
canonical: "https://kb.uconn.edu/space/IKB/28727935058/Scaling%20%26%20Autoscaling"
format: markdown
---
OpenShift makes it easy to scale your application up or down — manually or automatically based on CPU/memory usage. This guide covers both approaches.

---

## Manual Scaling

### Via Web Console

1. Go to **Workloads → Deployments** and select your deployment.
2. Click the **up/down arrows** next to the pod count, or click **Actions → Edit pod count**.
3. Set the desired number of replicas and click **Save**.

### Via CLI

```shell
# Scale to 3 replicas
oc scale deployment/my-app --replicas=3

# Verify pods are running
oc get pods -l app=my-app

# Scale back to 1
oc scale deployment/my-app --replicas=1
```

> **Tip:** Scaling to 0 replicas effectively stops the application without deleting any configuration. Scale back up when ready.

---

## Resource Requests & Limits

Before enabling autoscaling, you must set resource requests. These tell OpenShift how much CPU and memory each pod needs.

```shell
# Set requests and limits
oc set resources deployment/my-app \
  --requests=cpu=100m,memory=256Mi \
  --limits=cpu=500m,memory=512Mi
```

### Understanding the Values

| Resource | Unit | Example | Meaning |
| --- | --- | --- | --- |
| CPU | Millicores | `100m` | 10% of one CPU core |
| CPU | Cores | `1` | One full CPU core |
| Memory | Mebibytes | `256Mi` | 256 MB of RAM |
| Memory | Gibibytes | `1Gi` | 1 GB of RAM |

| Field | Purpose |
| --- | --- |
| **Requests** | Guaranteed minimum — used for scheduling and autoscaling decisions |
| **Limits** | Maximum allowed — pod gets OOMKilled or throttled if exceeded |

> **Best Practice:** Always set requests. Start with requests = 50% of limits, then adjust based on actual usage from monitoring.

---

## Horizontal Pod Autoscaler (HPA)

The HPA automatically adjusts the number of pod replicas based on observed CPU or memory utilization.

### Create an HPA via CLI

```shell
# Autoscale based on CPU (target 70% utilization, 2-10 pods)
oc autoscale deployment/my-app \
  --min=2 \
  --max=10 \
  --cpu-percent=70
```

### Create an HPA with Memory Target (YAML)

```yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80
```

```shell
# Apply the HPA
oc apply -f my-app-hpa.yaml
```

### Monitor the HPA

```shell
# Check HPA status
oc get hpa

# Detailed view with current metrics
oc describe hpa my-app-hpa

# Watch scaling in real time
oc get hpa -w
```

Example output:

```
NAME         REFERENCE           TARGETS           MINPODS   MAXPODS   REPLICAS
my-app-hpa   Deployment/my-app   45%/70%, 60%/80%  2         10        3
```

---

## How Autoscaling Works

| Phase | What Happens |
| --- | --- |
| **Monitor** | HPA checks metrics every 15 seconds (default) |
| **Calculate** | Compares current utilization against target percentage |
| **Scale Up** | If usage exceeds target, adds pods (up to max) |
| **Scale Down** | If usage drops below target, removes pods (down to min) after a stabilization window |
| **Cooldown** | Waits ~5 min before scaling down again to avoid flapping |

---

## Scaling Best Practices

| Practice | Why |
| --- | --- |
| Always set resource **requests** | HPA can't work without them |
| Set **minReplicas ≥ 2** for production | Ensures high availability |
| Use **readiness probes** | Prevents traffic hitting pods that aren't ready |
| Start with **CPU-based scaling** | Simpler and more predictable than memory |
| Monitor before setting targets | Use actual metrics to choose sensible thresholds |
| Don't set maxReplicas too high | Protects against runaway scaling and resource exhaustion |

---

## Scaling to Zero (Knative / Serverless)

If your application has periods of zero traffic, OpenShift Serverless (based on Knative) can scale all the way to zero and spin up on demand. This is not enabled by default — contact UConn ITS if you're interested.

---

## Quick Reference

```shell
# Manual scale
oc scale deployment/my-app --replicas=3

# Set resource requests (required for HPA)
oc set resources deployment/my-app --requests=cpu=100m,memory=256Mi --limits=cpu=500m,memory=512Mi

# Create CPU-based autoscaler
oc autoscale deployment/my-app --min=2 --max=10 --cpu-percent=70

# Check autoscaler status
oc get hpa
oc describe hpa my-app-hpa

# Delete autoscaler
oc delete hpa my-app-hpa
```

---

*UConn ITS Infrastructure Services — OpenShift Knowledge Base*