Scaling pods and understanding your quota

What this is

How to run more or fewer copies of your application, and how to read the quota that limits how far you can go.

Before you start

You need an application deployed and running. See Deploying your first application.

Your quota on an evaluation environment

An evaluation or proof of concept tenant is capped at:

These numbers are set deliberately so that a trial does not consume production scale resource. They are not platform limits, and they are changed for paying customers.

How to scale

Scaling means changing how many copies of your application are running. Each copy is a pod.

Step 1. Open your cluster and find your running workload.

Step 2. Use the scale up and scale down controls next to it.

Step 3. Enter the number of pods you want, and apply.

Step 4. Watch the pod count and the consumption figures change.

Screenshot needed: workload with scale controls and current pod count.

Reading your consumption

The dashboard shows live application usage next to your compute quota, so you can see how much of your allowance you are actually using rather than guessing.

Real figures from a ByteDC test, which are useful as a sense of scale:

The unit 600m means 600 millicores, which is 0.6 of one vCPU. Kubernetes measures CPU in thousandths of a core, so 2000m is the same as your 2 vCPU ceiling.

The pattern to take away is that consumption tracks pod count fairly directly. Three pods used roughly three times what one pod used. That makes your own usage reasonably predictable: measure one pod, then multiply.

Screenshot needed: consumption dashboard showing CPU and memory against quota.

When you hit the ceiling

Scale past your pod limit and the platform refuses and tells you that you are at capacity. On an evaluation environment that happens at 10 pods.

This is the quota doing its job. Nothing is broken, and your running pods are unaffected.

Screenshot needed: the capacity message shown when the pod limit is reached.

You have three options:

1. Use fewer, larger pods. If your application can do more work per copy, you get more capacity out of the same pod count.

2. Check you are not over provisioned. Idle pods still count against the limit. Scale down what is not doing work.

3. Ask for more quota. Quota is set per customer by ByteDC. Prospects get a standard small allowance managed centrally. Named accounts go through a separate approval route owned by account management, because your account manager understands your actual requirement. So this is a conversation with your account manager, not a setting in the portal.

What you should see when it works

You can change the pod count in both directions, the count updates, and the CPU and memory figures move with it. When you deliberately exceed your pod limit you get the capacity message rather than a silent failure.

Common problems

Scaling up did nothing. Check whether you are already at your pod ceiling. If you are below it and pods are still not starting, the pods may be starting and failing rather than not starting, so read the logs. See Reading logs and events to debug your app.

I am at capacity but I only have a few pods. The pod count is one limit and CPU and memory are separate limits. If each pod requests a large amount of CPU or memory, you exhaust those before you reach 10 pods.

Can I scale to 50 pods? Not on an evaluation environment. The ceiling is 10. Higher limits are available on paid accounts and are agreed with your account manager.

Scaling up increased my consumption and I did not expect that. More pods means more resource, which means more consumption. Scale back down when you are finished testing, and remember that deleting the cluster stops consumption entirely.