Skip to content

Infrastructure Quota

Public IP addresses, NAT gateways and storage are shared by everyone in an OSC region. To keep a single misbehaving workload — a runaway controller, a looping pipeline, a misconfiguration — from exhausting them for everyone, OSC sets an infrastructure quota on every Seed's infrastructure account.

The quota is a safety limit, not a billing limit. It is sized to be generous for normal operation. Should you need more, you can request an increase in the OSC Dashboard.

Scope of the Quota

The quota belongs to the infrastructure account behind a CredentialsBinding, not to a project or to a single Shoot cluster. Every Shoot cluster, and every other infrastructure resource created with that account, counts against the same quota, even when it lives in another project.

Each Seed has its own infrastructure account, so each Seed your Shoot clusters run on has its own quota.

What Is Limited

Resource Shown in the OSC Dashboard as What counts against it
NAT gateways NAT Gateways One per Shoot cluster for outbound traffic
Public load balancers Public Load Balancers Kubernetes Services of type LoadBalancer with a public IP. Internal load balancers do not count.
Virtual IPs Virtual IPs Public virtual IP addresses
Tier 1 storage Storage (fast) The size of every Tier 1 volume: Persistent Volumes and the root disks of the worker nodes
Tier 1 snapshot storage Snapshot storage (fast) The size of every snapshot taken from a Tier 1 volume
Tier 3 storage Storage (slow) The size of every Tier 3 volume. Only present if Tier 3 storage is available in your region.
Tier 3 snapshot storage Snapshot storage (slow) The size of every snapshot taken from a Tier 3 volume. Only present together with Tier 3 storage.

Storage counts the requested size of a volume, not the data written to it.

The default quota does not limit CPU, memory or the number of worker nodes.

How the Default Quota Is Sized

Every Seed is set up for a maximum number of Shoot clusters, its Shoot limit. The OSC Dashboard shows it next to the Seed of a Shoot cluster, as <used> of <limit> shoots used (see Change Seed for an existing Shoot).

The default quota grants a fixed amount for each Shoot slot of the Seed, plus a small fixed allowance per Seed for resources not tied to one Shoot cluster:

Resource Per Shoot slot Per Seed Example: Shoot limit 10
NAT gateways 1 + 3 13
Public load balancers 1 + 3 13
Virtual IPs — 5 5
Tier 1 storage 1Ti — 10Ti
Tier 1 snapshot storage 50Gi — 500Gi
Tier 3 storage 100Gi — 1000Gi
Tier 3 snapshot storage 50Gi — 500Gi

These are the platform defaults. OSC can agree different values with you per region.

Accounts that already held resources

If an account already held resources when the quota was introduced, nothing that already runs is blocked. For each resource the limit was set to the higher of:

  • the default from the table above, and
  • the usage at that moment plus 20 %, rounded up to a whole object or a whole GiB.

This happens once, when the quota is created. The limit does not grow along with your usage afterwards.

When limits change

Limits are only ever raised automatically, never lowered:

  • If OSC raises the Shoot limit of a Seed, the quota grows with it.
  • Limits raised on your request stay in place.

What Happens When a Limit Is Reached

Creating a resource that would exceed the quota is rejected. Everything that already exists keeps running. Typical symptoms:

  • A Service of type LoadBalancer stays without an external IP.
  • A PersistentVolumeClaim stays Pending.
  • New worker nodes are not created, so scaling up a worker pool fails. A rolling update of a worker pool needs storage too: it creates each new node, with its root disk, before it removes an old one.
  • A new Shoot cluster cannot be created, because it gets no NAT gateway.

Tip

Check the quota before large changes, such as adding worker nodes, upgrading a large worker pool, or creating many Persistent Volumes. Deleting unused LoadBalancer Services, PersistentVolumeClaims and VolumeSnapshots frees quota right away.

Viewing the Quota in the OSC Dashboard

  1. Log in to the OSC Dashboard.
  2. Open a project and select the Quota tab in the Resources group of the project menu.
  3. The view lists one entry per CredentialsBinding of the project. For each resource it shows Used, Limit and Available, together with the time of the last sync.

If the view shows No quota information available for this project, no quota is set for the accounts of this project.

Requesting a Quota Increase

  1. Open the Quota tab as described above.
  2. Click Request Increase below the CredentialsBinding that needs more quota.
  3. Enter the new value for each resource you want to increase. Leave all other fields empty. A requested value must be greater than the current limit.
  4. Explain in Reason why you need the additional quota. A reason is required.
  5. Click Submit Request.

The request is shown as Pending, and OSC operations is notified. Once the new limits are in place, the request changes to Applied automatically. Processed at shows when this happened, and Response may contain a message from OSC.

While a request is Pending, you can withdraw it with Cancel Request.

Using kubectl

The OSC Dashboard reads and writes a Quota object in your project namespace. You can use it directly with the kubeconfig of your Garden project. There is one object per CredentialsBinding, named <credentialsbinding>-quota:

kubectl -n garden-<project> get quotas.gardener.osc.t-systems.com
kubectl -n garden-<project> get quotas.gardener.osc.t-systems.com <credentialsbinding>-quota -o yaml

status.resources holds the limits and the usage. To request a quota increase, set spec.request:

spec:
  request:
    reason: "Two additional production Shoot clusters planned for Q4"
    natGateways: 20
    publicLoadBalancers: 25
    storagePerVolumeClass:
      fast: 15Ti
    snapshotStoragePerVolumeClass:
      fast: 1Ti

status.request.state shows Pending or Applied. Once the request is applied, spec.request is removed automatically.