client-go: share the same transport for generated clientsets#105490
client-go: share the same transport for generated clientsets#105490k8s-ci-robot merged 7 commits intokubernetes:masterfrom
Conversation
8a42af3 to
0c5ce9d
Compare
0c5ce9d to
acb56c2
Compare
0c8187b to
cfe8d4c
Compare
|
/kind bug @fedebongio this supersedes #105432 (comment) This is working now, there was a bug for the clientset generated without a custom transport because it wasn't using the configured Timeout option. |
46cb4a2 to
032d0d6
Compare
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: aojea, liggitt The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/test pull-kubernetes-verify-govet-levee |
|
@aojea: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
/test pull-kubernetes-unit |
that sounds like a flake |
/kind bug
/kind cleanup
Until now, when creating a Kubernetes Clientset, a new RESTClient was created per group/version. Since RESTClient transport can not be cached in some occasions, i.e. when using a custom transport, this has the consequence that each group/version had an independent TCP connection to the API server.
Since the Transport, of the RESTClient can be shared when creating a global Kubernetes Clientset, this PR adds a new RESTClient constructor
RESTClientForConfigAndClientto allow to generate clientsets using the same http client.Fixes #91913, #103225