* Fix a race condition in which kubeadm only waits for the kubelets kubeconfig file when it has performed the TLS bootstrap, but wasn't waiting for certificates to be present in the filesystem ([#72030](https://github.com/kubernetes/kubernetes/pull/72030), [@ereslibre](https://github.com/ereslibre))

- Kubernetes now supports update LoadBalancerSourceRanges for AWS NLB([#74692](https://github.com/kubernetes/kubernetes/pull/74692), [@M00nF1sh](https://github.com/M00nF1sh))
- Kubernetes now supports configure TLS termination for AWS NLB([#74910](https://github.com/kubernetes/kubernetes/pull/74910), [@M00nF1sh](https://github.com/M00nF1sh))

- kubeadm now deletes the bootstrap-kubelet.conf file after TLS bootstrap
  User relying on bootstrap-kubelet.conf should switch to kubelet.conf that contains node credentials ([#80676](https://github.com/kubernetes/kubernetes/pull/80676), [@fabriziopandini](https://github.com/fabriziopandini))

- Added a warning that TLS 1.3 ciphers are not configurable. ([#115399](https://github.com/kubernetes/kubernetes/pull/115399), [@3u13r](https://github.com/3u13r)) [SIG API Machinery and Node]

- `client-go`, using log level 9, traces the following events of a HTTP request:
      - DNS lookup
      - TCP dialing
      - TLS handshake
      - Time to get a connection from the pool
      - Time to process a request ([#105156](https://github.com/kubernetes/kubernetes/pull/105156), [@aojea](https://github.com/aojea))

### Documentation

* Clean up old eclass code ([#71399](https://github.com/kubernetes/kubernetes/pull/71399), [@resouer](https://github.com/resouer))
* Fix a race condition in which kubeadm only waits for the kubelets kubeconfig file when it has performed the TLS bootstrap, but wasn't waiting for certificates to be present in the filesystem ([#72030](https://github.com/kubernetes/kubernetes/pull/72030), [@ereslibre](https://github.com/ereslibre))

  // and the backend insecure. This means the apiserver cannot verify the log data it is receiving came from the real
  // kubelet.  If the kubelet is configured to verify the apiserver's TLS credentials, it does not mean the
  // connection to the real kubelet is vulnerable to a man in the middle attack (e.g. an attacker could not intercept
  // the actual log data coming from the real kubelet).
  // +optional

pkg crypto/ed25519, method (PrivateKey) Sign(io.Reader, []uint8, crypto.SignerOpts) ([]uint8, error)
pkg crypto/ed25519, type PrivateKey []uint8
pkg crypto/ed25519, type PublicKey []uint8
pkg crypto/tls, const Ed25519 = 2055
pkg crypto/tls, const Ed25519 SignatureScheme
pkg crypto/x509, const Ed25519 = 4
pkg crypto/x509, const Ed25519 PublicKeyAlgorithm
pkg crypto/x509, const PureEd25519 = 16
pkg crypto/x509, const PureEd25519 SignatureAlgorithm

- The Kubernetes API server now correctly detects and closes existing TLS connections when its client certificate file for kubelet authentication has been rotated. ([#115566](https://github.com/kubernetes/kubernetes/pull/115566), [@enj](https://github.com/enj)) [SIG API Machinery, Node and Testing]

- When creating a networking.k8s.io/v1 Ingress API object, `spec.tls[*].secretName` values are required to pass validation rules for Secret API object names. ([#93929](https://github.com/kubernetes/kubernetes/pull/93929), [@liggitt](https://github.com/liggitt)) [SIG Network]