From 237551019fb6978ac461b3ad3085df219a52eaf6 Mon Sep 17 00:00:00 2001 From: Prasad Katti Date: Wed, 6 May 2020 18:03:06 -0700 Subject: [PATCH] Update feature state for APIListChunking APIListChunking is beta since v1.9 --- content/en/docs/reference/using-api/api-concepts.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/en/docs/reference/using-api/api-concepts.md b/content/en/docs/reference/using-api/api-concepts.md index 4d06194a59..956c31323d 100644 --- a/content/en/docs/reference/using-api/api-concepts.md +++ b/content/en/docs/reference/using-api/api-concepts.md @@ -109,6 +109,7 @@ To mitigate the impact of short history window, we introduced a concept of `book `Bookmark` events can be requested by `allowWatchBookmarks=true` option in watch requests, but clients shouldn't assume bookmarks are returned at any specific interval, nor may they assume the server will send any `bookmark` event. ## Retrieving large results sets in chunks +{{< feature-state for_k8s_version="v1.9" state="beta" >}} On large clusters, retrieving the collection of some resource types may result in very large responses that can impact the server and client. For instance, a cluster may have tens of thousands of pods, each of which is 1-2kb of encoded JSON. Retrieving all pods across all namespaces may result in a very large response (10-20MB) and consume a large amount of server resources. Starting in Kubernetes 1.9 the server supports the ability to break a single large collection request into many smaller chunks while preserving the consistency of the total request. Each chunk can be returned sequentially which reduces both the total size of the request and allows user-oriented clients to display results incrementally to improve responsiveness.