clarify kube-proxy skew support and upgrade process

[liggitt]

Follow up from #11060, tracked in #12329

Supported skew and upgrade process for kube-proxy is not clear in user-facing documentation:

• what version skew does the kube-proxy component support relative to the apiserver and kubelet? @kubernetes/sig-network-pr-reviews
• is a specific upgrade order between kube-proxy and kubelet required? @kubernetes/sig-network-pr-reviews, @kubernetes/sig-node-pr-reviews

Page to Update:
https://kubernetes.io/docs/setup/version-skew-policy/

[roberthbailey]

It is probably ok to skew it as much as any client (e.g. up to two versions behind the apiserver), but for simplicity it's version is moved in lock step with the kubelet. Even though it may work skewed from the kubelet, I think it would be clearer and simpler to just say that the version of kube-proxy should match the version of the kubelet.

[imkin]

/wg lts

[sftim]

/language en

[danwinship]

kubelet and kube-proxy share 2 iptables chains (KUBE-MARK-MASQ and KUBE-MARK-DROP). Although there have been no conflicts between how they use them in past releases, it's possible that we might want to change things in the future, which might cause some tighter versioning constraints around that release. Other than that, I don't think kube-proxy cares what version of kubelet you're running, and I don't think it cares what version of apiserver you're running any more than any other client.