0f2c2bd847
Automatic merge from submit-queue (batch tested with PRs 51480, 49616, 50123, 50846, 50404) Kubectl to use http caching to cache openapi responses from the server **What this PR does / why we need it**: This PR is trying to address the problems raised in #50254 > * uses a disk-based cache that is not safe between processes (does not use atomic fs operations) > * writes get/list responses to disk that should not be cached (like kubectl get secrets) > * is vulnerable to partially written cache responses being used as responses to future requests > * breaks uses of the client transport that make use of websockets > * defaults to enabling the cache for any client builder using RecommendedConfigOverrideFlags or DefaultClientConfig which affects more components than just kubectl All of these points are addressed by this pull-request: 1. It now uses atomic fs operations 2. Doesn't cache by default, only if requested by the client (and it's only done by openapi client) 3. Fixed because of atomic fs operations 4. Found the reason for the bug: Cache wrapper couldn't be unwrapped. I implemented the `WrappedRoundTripper` interface. 5. Since 2. is fixed, I think that should be fine @smarterclayton @liggitt **Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes #50254 **Special notes for your reviewer**: **Release note**: ```release-note Allows kubectl to use http caching mechanism for the OpenAPI schema. The cache directory can be configured through `--cache-dir` command line flag to kubectl. If set to empty string, caching will be disabled. ```
External Repository Staging Area
This directory is the staging area for packages that have been split to their own repository. The content here will be periodically published to respective top-level k8s.io repositories.
Repositories currently staged here:
k8s.io/apiextensions-apiserverk8s.io/apik8s.io/apimachineryk8s.io/apiserverk8s.io/client-gok8s.io/kube-aggregatork8s.io/code-generator(about to be published)k8s.io/metricsk8s.io/sample-apiserver
The code in the staging/ directory is authoritative, i.e. the only copy of the code. You can directly modify such code.
Using staged repositories from Kubernetes code
Kubernetes code uses the repositories in this directory via symlinks in the
vendor/k8s.io directory into this staging area. For example, when
Kubernetes code imports a package from the k8s.io/client-go repository, that
import is resolved to staging/src/k8s.io/client-go relative to the project
root:
// pkg/example/some_code.go
package example
import (
"k8s.io/client-go/dynamic" // resolves to staging/src/k8s.io/client-go/dynamic
)
Once the change-over to external repositories is complete, these repositories
will actually be vendored from k8s.io/<package-name>.