Update release notes draft to version v1.38.0-alpha.2

[whtssub]

What type of PR is this?
/kind documentation

What this PR does / why we need it:
This PR updates the Release Notes Draft to k/k v1.38.0-alpha.2

Which issue(s) this PR fixes:

Special notes for your reviewer:
This is an automated PR generated from krel The Kubernetes Release Toolbox

Metrics: Across the full v1.38 cycle so far, there are 200 PRs flagged by Krel, of which 174 are now covered by map files and 26 are left untouched. This PR touches 40 release notes map files for the v1.38.0-alpha.2 cycle: 35 new, 4 deleted, 1 edited.

Note: release-notes-draft.md and release-notes-draft.json are generated from the maps in releases/release-1.38/release-notes/maps/ and will regenerate automatically on the next krel run.

Reviewer Note:
Checklist

• krel release-notes validate is successful
• .json validation
• Successfully parsed release notes maps for 174 PRs

cc: @Caesarsage @yashasvimisra2798 @ChieloChi @AnshumanTripathi @abalso0 @sreeram-venkitesh @rayandas @adilGhaffarDev

[kubernetes-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: whtssub
Once this PR has been reviewed and has the lgtm label, please assign rayandas for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• releases/release-1.38/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: whtssub / name: whtssub (6042698, fcd402e)

[whtssub]

Found a bug in krel while regenerating this draft: do_not_publish: true set inside a release-notes map is silently ignored once that map applies any other override to the note which is always, since that field only exists inside a map. In pkg/notes/document/document.go, the suppression check is if !note.IsMapped && note.DoNotPublish, but IsMapped is already true for any note with a map, so the note never gets skipped.

Concretely, these four PRs have do_not_publish: true in their maps but still show up in the rendered draft: #141817, #141663, #141203, #142395

Was this already known?

cc @Caesarsage @sreeram-venkitesh

[Caesarsage]

Thank you @whtssub

There are still some work that need to be done before it can be ready for review. Check the step 8 on this guide to clean up the maps

https://caesarsage.github.io/v1.38-docs-onboarding/training/release-notes-walkthrough.html

[Caesarsage]

Found a bug in krel while regenerating this draft: do_not_publish: true set inside a release-notes map is silently ignored once that map applies any other override to the note which is always, since that field only exists inside a map. In pkg/notes/document/document.go, the suppression check is if !note.IsMapped && note.DoNotPublish, but IsMapped is already true for any note with a map, so the note never gets skipped.

Concretely, these four PRs have do_not_publish: true in their maps but still show up in the rendered draft: #141817, #141663, #141203, #142395

Was this already known?

cc @Caesarsage @sreeram-venkitesh

Yes, it's tracked in kubernetes/release#4456. For now: delete the four maps and get release-note-none on each k/k PR.

[Caesarsage]

Thanks @whtssub. Left inline style suggestions; please batch-commit them. Also update the description: drop the "Hidden" section, and change the counts to 174 maps, 26 untouched, 40 files touched. The four removed maps still need /release-note-none on their k/k PRs.

[Caesarsage]

Suggested change

	text: |-
	DRA: fixed a deadlock when an `ErrorHandler` calls `Update`, or a `kubelet` plugin's `HandleError` calls `PublishResources`, in response to pools that do not match `ReconcilePoolWithName`. Such resources now replace the desired state instead of being rejected; the other pools are reported to the error handler and are not published. Initial resources with other pools no longer cause a panic. Also fixed a deadlock when a `kubelet` plugin's `HandleError` calls `PublishResources` while the plugin stops.
	text: |-
	Fixed a DRA deadlock when an `ErrorHandler` calls `Update`, or a `kubelet` plugin's `HandleError` calls `PublishResources`, in response to pools that do not match `ReconcilePoolWithName`. Such resources replace the desired state instead of being rejected; the other pools are reported to the error handler and are not published. Initial resources with other pools no longer cause a panic. Also fixed a deadlock when a `kubelet` plugin's `HandleError` calls `PublishResources` while the plugin stops.

[Caesarsage]

Suggested change

	Fixed `kube-apiserver` and other servers built on `k8s.io/apiserver` so they accept up to 16384 request header values. Without this, the Go 1.27 default limit of 500 header values rejects impersonated or proxied users with about 500 or more groups with HTTP 431. Releases built with Go 1.26 had no separate header-count limit.
	Fixed `kube-apiserver` and other servers built on `k8s.io/apiserver` so they accept up to 16384 request header values. Without this, the Go `v1.27` default limit of 500 header values rejects impersonated or proxied users with about 500 or more groups with HTTP 431. Releases built with Go `v1.26` had no separate header-count limit.

[Caesarsage]

Suggested change

	Fixed `kubelet` so that pods with `dnsPolicy` set to Default no longer inherit scoped IPv6 link-local nameservers (for example `fe80::1%3`) from the node resolver configuration unless the pod uses the host network namespace.
	Fixed the `kubelet` so that Pods with `dnsPolicy` set to Default no longer inherit scoped IPv6 link-local nameservers (for example `fe80::1%3`) from the node resolver configuration unless the Pod uses the host network namespace.

[Caesarsage]

Suggested change

	Graduated HPA `observedGeneration` to GA. The `HPAGeneration` feature gate is locked to enabled.
	Graduated the HorizontalPodAutoscaler `observedGeneration` field to GA. The `HPAGeneration` feature gate is locked to enabled.

[Caesarsage]

Suggested change

	Added support for quantum crypto keys and certs to `hack/local-up-cluster.sh` for testing.
	Added support for post-quantum keys and certificates to `hack/local-up-cluster.sh` for testing.

[Caesarsage]

Suggested change

Changed validation to reject creating or updating a resource.k8s.io object with a qualified name that contains more than one slash, such as the device attribute key `a/b/c`. Objects that already store such a name remain updatable as long as the field holding it is left unchanged; for a ResourceSlice, as long as `spec.devices` is unchanged, since any change to that atomic list revalidates every device in it.

Changed validation to reject creating or updating a `resource.k8s.io` object with a qualified name that contains more than one slash, such as the device attribute key `a/b/c`. Objects that already store such a name remain updatable as long as the field holding it is left unchanged; for a ResourceSlice, as long as `spec.devices` is unchanged, since any change to that atomic list revalidates every device in it.

[Caesarsage]

Suggested change

	Updated node local DNS to version `1.27.1`.
	Updated NodeLocal DNSCache to `1.27.1`.

[Caesarsage]

Suggested change

	Fixed several bugs in the ID range handling for pods using user namespaces
	(`spec.hostUsers: false`).
	The `kubelet` no longer fails to start when the `kubelet` user exists but the `getsubids` binary
	is not installed. It now falls back to the default ID range, as documented.
	Pods are no longer assigned the ID range ending at 4294967295 (2^32-1). The kernel treats that
	ID as invalid and refuses to map it, so a pod assigned that range failed to start. The default
	range now ends one `idsPerPod` block lower.
	ACTION REQUIRED: The `kubelet` now refuses to start if the subordinate ID range configured for the
	`kubelet` user in `/etc/subuid` and `/etc/subgid` ends at or past 4294967295, since such a range
	either contains the unmappable ID or extends past the end of the 32-bit ID space. Nodes
	configured this way, for example `kubelet:65536:4294901760`, must reduce the count by at least
	one `idsPerPod` (65536 by default) before upgrading.
	ACTION REQUIRED: If a pod on the node was assigned the invalid ID range by an earlier `kubelet`,
	that range is still recorded in the pod's directory, and the upgraded `kubelet` refuses to start:
	create user namespace manager: record pod mappings for existing pod "<uid>": id 4294901760 is out of range
	Delete any pod stuck in `ContainerCreating` with a `FailedCreatePodSandBox` event, or drain the
	node, before upgrading the `kubelet`.
	ACTION REQUIRED: Fixed several bugs in the ID range handling for Pods using user namespaces (`spec.hostUsers: false`). Before upgrading the `kubelet`:
	- If the subordinate ID range for the `kubelet` user in `/etc/subuid` and `/etc/subgid` ends at or past 4294967295, for example `kubelet:65536:4294901760`, reduce the count by at least one `idsPerPod` (65536 by default). Such a range contains an ID the kernel can't map, and the `kubelet` refuses to start with it.
	- Delete any Pod stuck in `ContainerCreating` with a `FailedCreatePodSandBox` event, or drain the node. An earlier `kubelet` may have assigned such a Pod the invalid range, and the upgraded `kubelet` refuses to start with `create user namespace manager: record pod mappings for existing pod "<uid>": id 4294901760 is out of range`.
	The `kubelet` also no longer fails to start when the `kubelet` user exists but the `getsubids` binary is not installed; it falls back to the default ID range, as documented. Pods are no longer assigned the ID range ending at 4294967295 (2^32-1), which the kernel refuses to map, so the default range ends one `idsPerPod` block lower.

[Caesarsage]

Suggested change

	Fixed the HorizontalPodAutoscaler utilization and usage calculations wrapping to a wrong or negative current value when pod metric or request totals exceeded `int64` or the utilization percentage exceeded `int32`; the reported percentage now saturates at the `int32` limit.
	Fixed the HorizontalPodAutoscaler utilization and usage calculations wrapping to a wrong or negative current value when pod metric or request totals exceeded `int64` or the utilization percentage exceeded `int32`; the reported percentage saturates at the `int32` limit.

[Caesarsage]

Suggested change

	Fixed DRA consumable capacity requests failing when the request used a fully-qualified capacity name. Requests now work with both the unqualified name, as published by drivers (typically without the driver name prefix), and the fully-qualified name. A related, less likely problem also occurred when a DRA driver changed how it published capacity after some capacity had already been allocated.
	Fixed DRA consumable capacity requests failing when the request used a fully-qualified capacity name. Requests work with both the unqualified name, as published by drivers (typically without the driver name prefix), and the fully-qualified name. A related, less likely problem also occurred when a DRA driver changed how it published capacity after some capacity had already been allocated.

[Caesarsage]

/lgtm

Follow-up before alpha.3: /release-note-none on #141817, #141663, #141203 and #142395.

[yashasvimisra2798]

/lgtm

[thc1006]

#141203 is now marked release-note-none.