Start deprecation process for StreamingProxyRedirects

[tallclair]

What type of PR is this?
/kind deprecation

What this PR does / why we need it:

Implements the first stage of the StreamingProxyRedirects deprecation, simply marking the feature & flag as deprecated. See https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20191205-container-streaming-requests.md#rollout-plan

Which issue(s) this PR fixes:
For kubernetes/enhancements#1558

Does this PR introduce a user-facing change?:

The StreamingProxyRedirects feature and `--redirect-container-streaming` flag are deprecated, and will be removed in a future release. The default behavior (proxy streaming requests through the kubelet) will be the only supported option.
ACTION REQUIRED: If you are setting `--redirect-container-streaming=true`, then you must migrate off this configuration. The flag will no longer be able to be enabled starting in v1.20. If you are not setting the flag, no action is necessary.

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

- [KEP]: https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20191205-container-streaming-requests.md

/sig node
/assign @Random-Liu @derekwaynecarr

[mattjmcnaughton]

Thanks for the pr :)

I'm convinced this PR does the work outlined in your KEP. Thanks for such a clearly written KEP :)
LGTM modulo the test failures... feel free to ping me once the test failures are fixed and I will add the lgtm label again.

/lgtm

[mattjmcnaughton]

Just to confirm I'm understanding the KEP - do we ever intend to mark ValidateProxyRedirects as deprecated? Or as that unnecessary because its only utilized in conjunction with StreamingProxyRedirects, and we are marking StreamingProxyRedirects as deprecated (so when the time comes, we can just delete StreamingProxyRedirects)?

[tallclair]

Good question, I was thinking about it a bit more when writing this change. The original KEP moved ValidateProxyRedirects to GA first, but folks thought that was weird since it would then be deleted. It might be more appropriate to mark it as deprecated, since it's going away, but I don't want people to see "oh this is deprecated, I should disable it", since it's dangerous to disable it before removing streaming proxy redirects.

I'm thinking of just leaving it as Beta, and marking it as deprecated once the behavior is removed (the feature gate can be removed a few releases after that). WDYT?

[mattjmcnaughton]

That rationale makes sense to me! Mind capturing what yousaid above either in the KEP, commit message, or PR body? Or even a comment?

Thanks :)

[fejta-bot]

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to fejta).

Review the full test history for this PR.

Silence the bot with an /lgtm cancel or /hold comment for consistent failures.

[tallclair]

Ah, I forgot to update the copy of the feature in the core package. Tests should pass now (hopefully).

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: tallclair

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

The pull request process is described here

Needs approval from an approver in each of these files:

• pkg/features/OWNERS [tallclair]
• pkg/kubelet/OWNERS [tallclair]
• staging/src/k8s.io/apiserver/pkg/features/OWNERS [tallclair]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[mattjmcnaughton]

/lgtm