Skip to content

Commit 7c4c0bf

Browse files
committed
Add SIG Scalability FAQ
1 parent d3ae637 commit 7c4c0bf

File tree

1 file changed

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

1 file changed

+27
-0
lines changed
Lines changed: 27 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,27 @@
1+
# FAQ
2+
3+
### How many QPS kube-apiserver can support?
4+
5+
There is NO single answer to this question. The reason for it is that,
6+
every Kubernetes request is potentially very different. As a result,
7+
kube-apiserver may be able to process N in a given usage pattern, but
8+
may not be able to process even N/5 in a different usage pattern.
9+
10+
To be more specific, the difference is fairly obvious if we compare
11+
GET and LIST requests (e.g. "GET my-pod" vs "LIST all pods").
12+
It's also not counter-intuitive that there is a difference between
13+
ready-only and mutating requests (e.g. "GET my-pod" vs "POST my-pod").
14+
15+
However, even if we focus only on a single type of request (let's say just
16+
POST or just PUT), the differences can be in the orders of magnitude.
17+
The two main reasons to think about are:
18+
- size of the object - there is a huge difference between a small Lease
19+
object (say ~300B) and large custom CRD of e.g. 1MB
20+
- fan-out - if a given object is being watched by N watchers, you
21+
suddenly get a multiplication factor for the cost of your request,
22+
that as a sender of a single API call you don't fully control
23+
24+
As a result, we are consciously not providing any values, because
25+
one can imagine a cluster that handles thousands of QPS and a cluster
26+
that is set up the same way may have troubles handling small tens of
27+
QPS if the requests are fairly expensive.

0 commit comments

Comments
 (0)