- Kubelet TCP and HTTP probes are now more effective using networking resources:
  conntrack entries, sockets. This is achieved by reducing the `TIME-WAIT` state
  of the connection to 1 second, instead of the defaults 60 seconds. This allows
  kubelet to free the socket, and free conntrack entry and ephemeral port associated. ([#115143](https://github.com/kubernetes/kubernetes/pull/115143), [@aojea](https://github.com/aojea))

  For more information, see [#57198](https://github.com/kubernetes/kubernetes/issues/57198).

*   Mutating and validating webhook configurations are continuously polled by the API server (once per second). This issue will be fixed in a future release.

  For more information, see [#56357](https://github.com/kubernetes/kubernetes/issues/56357).

### CSI Health Monitoring

* Update Cluster Autoscaler to version 1.3.7. ([#74136](https://github.com/kubernetes/kubernetes/pull/74136), [@jkaniuk](https://github.com/jkaniuk))
* Fix watch to not send the same set of events multiple times causing watcher to go back in time ([#73845](https://github.com/kubernetes/kubernetes/pull/73845), [@wojtek-t](https://github.com/wojtek-t))

* Fix watch to not send the same set of events multiple times causing watcher to go back in time ([#73845](https://github.com/kubernetes/kubernetes/pull/73845), [@wojtek-t](https://github.com/wojtek-t))

- Fix: use force detach for azure disk ([#91948](https://github.com/kubernetes/kubernetes/pull/91948), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider]
- Fixes a problem with 63-second or 1-second connection delays with some VXLAN-based
  network plugins which was first widely noticed in 1.16 (though some users saw it
  earlier than that, possibly only with specific network plugins). If you were previously

- Fix: use force detach for azure disk ([#91948](https://github.com/kubernetes/kubernetes/pull/91948), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider]
- Fixes a problem with 63-second or 1-second connection delays with some VXLAN-based
  network plugins which was first widely noticed in 1.16 (though some users saw it
  earlier than that, possibly only with specific network plugins). If you were previously

identified in large-scale clusters when deleting thousands of pods simultaneously across hundreds of nodes. Kubelets in this scenario can encounter temporarily increased latency of `delete pod` API calls -- above the target service level objective of 1 second. If you run clusters with this usage pattern and if pod deletion latency could be an issue for you, you might want to wait until the issue is resolved before you upgrade.

For more information and for updates on resolution of this issue,...

* Move HighWaterMark to the top of the struct in order to fix arm ([#33117](https://github.com/kubernetes/kubernetes/pull/33117), [@luxas](https://github.com/luxas))
* Move HighWaterMark to the top of the struct in order to fix arm, second time ([#33376](https://github.com/kubernetes/kubernetes/pull/33376), [@luxas](https://github.com/luxas))



# v1.4.0

### Documentation

- Added a new internal metric `kubelet_first_network_pod_start_sli_duration_second` in the kubelet that allowed developers to understand the source of the latency problems on node startups.
   ([#121720](https://github.com/kubernetes/kubernetes/pull/121720), [@aojea](https://github.com/aojea))