In particular, octets within IPv4 addresses are not allowed to have any leading
  `0`s, and IPv4-mapped IPv6 values (e.g. `::ffff:192.168.0.1`) are forbidden.
  These sorts of values can potentially cause security problems when different
  components interpret the same string as referring to different IP addresses
  (as in CVE-2021-29923).
  
  This tightening applies only to fields in built-in API kinds, and not to

- kubeadm: switched the kube-scheduler static Pod to use the endpoints `/livez` (for startup and liveness probes) and `/readyz` (for the readiness probe). Previously, `/healthz` was used for all probes, which is deprecated behavior in the scope of this component. ([#126945](https://github.com/kubernetes/kubernetes/pull/126945), [@liangyuanpeng](https://github.com/liangyuanpeng)) [SIG Cluster Lifecycle]...

respected. This may result in unexpected behavior since the default timeout (if not specified) is `1s` which may be too small for some exec probes. Ensure that pods relying on this behavior are updated to correctly handle probe timeouts. See [configure probe](https://docs.k8s.io/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes) section of the documentation for more details.

  - This change in behavior may be unexpected for some clusters and can be...

- A new feature was enabled to improve the performance of the iptables mode of `kube-proxy` in large clusters. No action was required, however:
  

// Excerpts from @lsegal - https://github.com/aws/aws-sdk-js/issues/659#issuecomment-120477258
//
//	User-Agent:
//
//	    This is ignored from signing because signing this causes problems with generating pre-signed URLs
//	    (that are executed by other agents) or when customers pass requests through proxies, which may
//	    modify the user-agent.
//
//	Authorization:
//

- Don't use a custom dialer for the kubelet if is not rotating certificates, so we can reuse TCP connections and have only one between the apiserver and the kubelet.

- Fixes a regression introduced in 1.29 where conntrack entries for UDP connections
  to deleted pods did not get cleaned up correctly, which could (among other things)
  cause DNS problems when DNS pods were restarted. ([#127808](https://github.com/kubernetes/kubernetes/pull/127808), [@danwinship](https://github.com/danwinship)) [SIG Network]

- Fixes a regression introduced in 1.29 where conntrack entries for UDP connections
  to deleted pods did not get cleaned up correctly, which could (among other things)
  cause DNS problems when DNS pods were restarted. ([#127806](https://github.com/kubernetes/kubernetes/pull/127806), [@danwinship](https://github.com/danwinship)) [SIG Network]

Vous pouvez alors essayer de les aider à résoudre ces problèmes.

## Créer une Issue

Vous pouvez <a href="https://github.com/fastapi/fastapi/issues/new/choose" class="external-link" target="_blank">créer une Issue</a> dans le dépôt GitHub, par exemple pour :

* Poser une question ou s'informer sur un problème.
* Suggérer une nouvelle fonctionnalité.

**Note** : si vous créez un problème, alors je vais vous demander d'aider aussi les autres. 😉

  stop using `--node-ip`. (In particular, this fixes the problem where people who
  were unnecessarily using `--node-ip` with an external cloud provider in 1.23,
  and then running into problems with 1.24, could not fix the problem by just
  removing the unnecessary `--node-ip` from the kubelet arguments, because