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.