Change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: kube-proxy DaemonSet: Note option Despite option kube-proxy bind port to : Note: What you expected to happen: kube-proxy should bind port (health check server) to 0.0.0.0. Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-06-29T23:15:59Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-06-29T22:55:19Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} OS (e.g. from /etc/os-release): Ubuntu 14.04 Kernel (e.g. ): Linux dev-k8s-deployer-p1 4.4.0-34-generic ~14.04.1-Ubuntu SMP Wed Jul 27 16:56:40 UTC 2016 x8664 x8664 x86_64 GNU/Linux
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <bre.g., for API Machinery<br(2) specifying the label manually: <bre.g., for sig/scalability<br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
Sorry for the confusion, I forgot to update the release note in . In v1.7, kube-proxy's healthz server will serve on (by default) instead, setting flag should affect this port. Meanwhile, will be mainly used for metrics server. For transition, kube-proxy will continue serving on port with , but currently is not adjustable through flag (I think we need a flag though).
/assign please close when the docs are updated
This broke our production deployment because our AWS ELBs were using port for health checks, and with this change kube-proxy is no longer listening for outside connections on this port.
I'm terribly sorry for the production issue you encountered. I'm cherrypicking and also patching in the release note for kube-proxy we should have published with the initial 1.7 release. Hopefully that could prevent more users being hurt by this and make the potential transition easier.
Thanks I know it's hard to avoid breaking changes in software, especially a project as big and complicated as Kubernetes. To be clear, I place no blame on you or any other individual for the mistake. I do think it would be useful to loop in a project manager for a post mortem, cause I thiink it's important to do a post-mortem on issues like this to see how the process can be improved to detect and prevent similar issues in the future. The only manager on the project I know by name is would you be so kind as to let an appropriate person know about this issue for the purposes of a post-mortem?

Discussion:
* Fix Cinder to support http status 300 in pagination ([#47602](https://github.com/kubernetes/kubernetes/pull/47602), [@rootfs](https://github.com/rootfs)) * Automated cherry pick of [#49079](https://github.com/kubernetes/kubernetes/pull/49079) upstream release 1.7 ([#49254](https://github.com/kubernetes/kubernetes/pull/49254), [@feiskyer](https://github.com/feiskyer)) * Fixed GlusterFS volumes taking too long to time out ([#48709](https://github.com/kubernetes/kubernetes/pull/48709), [@jsafrane](https://github.com/jsafrane)) <ins> * The IP address and port for kube-proxy metrics server is now configurable via flag `--metrics-bind-address` ([#48625](https://github.com/kubernetes/kubernetes/pull/48625), [@mrhohn](https://github.com/mrhohn)) * Special notice for kube-proxy in 1.7+ (including 1.7.0): * Healthz server (/healthz) will be served on 0.0.0.0:10256 by default. * Metrics server (/metrics and /proxyMode) will be served on 127.0.0.1:10249 by default. * Metrics server will continue serving /healthz. </ins> # v1.7.2