Skip to content

Commit 2b68bee

Browse files
committed
Add SIG Scalability FAQ about object sizes
1 parent d703440 commit 2b68bee

File tree

1 file changed

+36
-0
lines changed
  • sig-scalability/configs-and-limits

1 file changed

+36
-0
lines changed

sig-scalability/configs-and-limits/faq.md

Lines changed: 36 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -27,6 +27,42 @@ that is set up the same way may have troubles handling small tens of
2727
QPS if the requests are fairly expensive.
2828

2929

30+
### What is the ideal size for API objects we should target?
31+
32+
Technically, the only hard limit that we have is the one of 1.5MB for
33+
the size of individual objects. That said, approaching that limit is
34+
definitely not recommended unless absolutely necessary.
35+
36+
In typical usecases, huge majority of objects doesn't exceed ~20KB of
37+
size and this is the usecase that is best tested and many optimizations
38+
assume (which are done based on existing tests) silently assume that.
39+
40+
If we look into individual objects larger than 20kB, significant majority
41+
of cases that we've seen were representing a single pattern of grouping
42+
multiple "subobjects" into a single object. The best example of that
43+
from the core Kubernetes is `Endpoints` API, which is effectively grouping
44+
all endpoints backing a given Kubernetes Service into a single object.
45+
Those kind of APIs proved to be problematic for multiple different reasons,
46+
including:
47+
- the objects become large and even small change (of a single subobject)
48+
becomes expensive from the system perspective
49+
- they become a contention point if different agents are updating different
50+
subobjects
51+
- they become wasteful as we are able to get/watch only full objects and
52+
many agents may not need information about all subobjects
53+
As a result, this pattern should really be avoided.
54+
In case of `Endpoints` API, we introduce the `EndpointSlice` API and if
55+
singular objects are problematic for your usecase, this is the pattern
56+
you should explore.
57+
58+
So from scalability/performance perspective, the rule of thumb can be
59+
summarized as:
60+
- try to keep your object size below ~20kB
61+
- if really needed, you can get to 100kB if it's not changing frequently
62+
- if you can't keep your object size below 100kB, reach out to SIG
63+
Scalability and discuss the usecase to see how we can make it performant
64+
65+
3066
### How do you setup clusters for scalability testing?
3167

3268
We are testing Kubernetes on two levels of scale: 100 nodes and 5000 nodes.

0 commit comments

Comments
 (0)