* To avoid that negative effect only use per pod metrics from pods that are:
    * - ready (so metrics about them should be valid), or
    * - unready but creation and last readiness change timestamps are apart more than 10s (pods that have formerly been ready and so metrics are in at least some cases (pod becoming unready because of overload) very useful).

* Fixes an issue where Portworx volumes cannot be mounted if 9001 port is already in use on the host and users remap 9001 to another port. ([#70392](https://github.com/kubernetes/kubernetes/pull/70392), [@harsh-px](https://github.com/harsh-px))

    kubelet does not start pods that require networking before
    [networking is ready](https://github.com/kubernetes/kubernetes/issues/43014).
    This change may require changes to clients that gate pod creation and/or
    scheduling on the node condition `type` `Ready` `status` being `True` for pods
    that need to run prior to the network being ready.
* **Enhance Kubelet QoS**:

- Fixed a bug in the cronjob controller where already created jobs might be missing from the status. ([#120649](https://github.com/kubernetes/kubernetes/pull/120649), [@andrewsykim](https://github.com/andrewsykim))

- Make sure auto-mounted subpath mount source is already mounted ([#112499](https://github.com/kubernetes/kubernetes/pull/112499), [@andyzhangx](https://github.com/andyzhangx))...

    * Also updates dependencies of users of debian-base.
    * debian-base version 0.3.1 is already available.
* Fix an issue that pods using hostNetwork keep increasing. ([#67456](https://github.com/kubernetes/kubernetes/pull/67456), [@Huang-Wei](https://github.com/Huang-Wei))

- Containers which specify a `startupProbe` but not a `readinessProbe` were previously considered "ready" before the `startupProbe` completed, but are now considered "not-ready". ([#92196](https://github.com/kubernetes/kubernetes/pull/92196), [@thockin](https://github.com/thockin)) [SIG Node]

CVE-2023-39325 for the API server when the client is unauthenticated. The mitigation may be enabled by setting the `UnauthenticatedHTTP2DOSMitigation` feature gate to `true` (it is disabled by default). An API server fronted by an L7 load balancer that already mitigates these http/2 attacks may choose not to enable the kube-apiserver mitigation to avoid disrupting load balancer → kube-apiserver connections if http/2 requests from multiple clients share the same backend connection. An API server on a private...

CVE-2023-39325 for the API server when the client is unauthenticated. The mitigation may be enabled by setting the `UnauthenticatedHTTP2DOSMitigation` feature gate to `true` (it is disabled by default). An API server fronted by an L7 load balancer that already mitigates these http/2 attacks may choose not to enable the kube-apiserver mitigation to avoid disrupting load balancer → kube-apiserver connections if http/2 requests from multiple clients share the same backend connection. An API server on a private...

  // Service should disregard any indications of ready/not-ready.
  // The primary use case for setting this field is for a StatefulSet's Headless Service to
  // propagate SRV DNS records for its Pods for the purpose of peer discovery.
  // The Kubernetes controllers that generate Endpoints and EndpointSlice resources for
  // Services interpret this to mean that all endpoints are considered "ready" even if the