@k8s-bot pull-kubernetes-unit test this

cc @deads2k @ilackarms

I wonder what would cause those tests to flake. Is there a way I can try to reproduce this locally?

I wasn't able to pin it down, but some possible ideas:

• differences in behavior with content-length vs chunked encoding when there is sufficient data in the system to exceed the 4k response buffer (the filter isn't doing anything with transfer-encoding or content-length, and is assuming the wrapped handler isn't setting those headers)
• something with the gzip filter causing clients to wait for responses to complete, slowing them down, and stacking namespace deletion handling by the controller
• the gzip filter possibly getting put on subresource GET operations unintentionally (hadn't verified this)

for recreation... I would create a bunch of namespaces (50?) with some number of resources in them (including running pods to exercise graceful deletion loops), then delete them all at once and observe the namespace controller's behavior

/lgtm

cc/ @kubernetes/kubernetes-release-managers @foxish, the build cop

e2e: SUCCESS! -- 302 Passed | 0 Failed | 0 Pending | 344 Skipped

unit test failure in https://k8s-gubernator.appspot.com/build/kubernetes-jenkins/pr-logs/pull/47191/pull-kubernetes-unit/35607/ is known flake (#42289)

recommend merging this to fix the gce-e2e job

@k8s-bot pull-kubernetes-unit test this

/lgtm

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dchen1107, liggitt, mikedanese

Associated issue: 47135

The full list of commands accepted by this bot can be found here.

All tests are green. I am going to manually merge the pr for #47135

It sounds like CPU usage issue. gzip is not particularly cheap and thus we shouldn't enable it by default.

@gmarek working on a PR with feature gating to disable gzip by default
cc @simon3z