Maximum Pods per Cluster / Expected Pods per Node = Total Number of Nodes
×
Cluster Limits
Overview
This topic summarizes the limits for objects in OKD.
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.
OKD Cluster Limits
| Limit Type | 3.7 Limit | 3.9 Limit |
|---|---|---|
Number of nodes [1] |
2,000 |
2,000 |
Number of pods [2] |
120,000 |
120,000 |
Number of pods per node |
250 |
250 |
Number of pods per core |
10 is the default value. The maximum supported value is the number of pods per node. |
10 is the default value. The maximum supported value is the number of pods per node. |
Number of namespaces |
10,000 |
10,000 |
Number of pods per namespace [3] |
3,000 |
3,000 |
Number of services [4] |
10,000 |
10,000 |
Number of back-ends per service |
5,000 |
5,000 |
Number of deployments per namespace [3] |
2,000 |
2,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:
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.