Overview

This topic summarizes the limits for objects in OpenShift Origin.

In most cases, exceeding these thresholds results in lower overall performance. It does not necessarily mean that the cluster will fail.

Some of the limits represented in this topic are given for the largest possible cluster. For smaller clusters, the limits are proportionally lower.

There are many factors that influence the stated thresholds, including the etcd version or storage data format.

OpenShift Origin 3.7 Cluster Limits

Limit Type Current Limit

Number of nodes [1]

2,000

Number of pods [2]

120,000

Number of pods per node

250

Number of pods per core

10 is the default value. The maximum supported value is the number of pods per node.

Number of namespaces

10,000

Number of pods per namespace [3]

15,000

Number of services [4]

10,000

Number of back-ends per service

5,000

Number of deployments per namespace [3]

20,000

Planning Your Environment According to Cluster Limits

Oversubscribing the physical resources on a node affects resource guarantees the Kubernetes scheduler makes during pod placement. Learn what measures you can take to avoid memory swapping.

While planning your environment, determine how many pods are expected to fit per node:

Maximum Pods per Cluster / Expected Pods per Node = Total Number of Nodes

The number of pods expected to fit on a node is dependent on the application itself. Consider the application’s memory, CPU, and storage requirements.

Example Scenario

If you want to scope your cluster for 2200 pods per cluster, you would need at least nine nodes, assuming that there are 250 maximum pods per node:

2200 / 250 = 8.8

If you increase the number of nodes to 20, then the pod distribution changes to 110 pods per node:

2200 / 20 = 110

Planning Your Environment According to Application Requirements

Consider an example application environment:

Pod Type Pod Quantity Max Memory CPU Cores Persistent Storage

apache

100

500MB

0.5

1GB

node.js

200

1GB

1

1GB

postgresql

100

1GB

2

10GB

JBoss EAP

100

1GB

1

1GB

Extrapolated requirements: 550 CPU cores, 450GB RAM, and 1.4TB storage.

Instance size for nodes can be modulated up or down, depending on your preference. Nodes are often resource overcommitted. In this deployment scenario, you can choose to run additional smaller nodes or fewer larger nodes to provide the same amount of resources. Factors such as operational agility and cost-per-instance should be considered.

Node Type Quantity CPUs RAM (GB)

Nodes (option 1)

100

4

16

Nodes (option 2)

50

8

32

Nodes (option 3)

25

16

64

Some applications lend themselves well to overcommitted environments, and some do not. Most Java applications and applications that use huge pages are examples of applications that would not allow for overcommitment. That memory can not be used for other applications. In the example above, the environment would be roughly 30 percent overcommitted, a common ratio.


1. Clusters with more than the stated limit are not supported. Consider splitting into multiple clusters.
2. The pod count displayed here is the number of test pods. The actual number of pods depends on the application’s memory, CPU, and storage requirements.
3. There are a number of control loops in the system that need to iterate over all objects in a given namespace as a reaction to some changes in state. Having a large number of objects of a given type in a single namespace can make those loops expensive and slow down processing given state changes.
4. Each service port and each service back-end has a corresponding entry in iptables. The number of back-ends of a given service impact the size of the endpoints objects, which impacts the size of data that is being sent all over the system.