Change:
The UserName in Windows to run the entrypoint of the container process. Defaults to the user specified in image metadata if unspecified. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence. <ins> ### Not allowed - **ports** ([]ContainerPort) *Patch strategy: merge on key `containerPort`* *Map: unique values on keys `containerPort, protocol` will be kept during a merge* Ports are not allowed for ephemeral containers. <a name="ContainerPort"></a> *ContainerPort represents a network port in a single container.* - **ports.containerPort** (int32), required Number of port to expose on the pod's IP address. This must be a valid port number, 0 < x < 65536. - **ports.hostIP** (string) What host IP to bind the external port to. - **ports.hostPort** (int32) Number of port to expose on the host. If specified, this must be a valid port number, 0 < x < 65536. If HostNetwork is specified, this must match ContainerPort. Most containers do not need this. - **ports.name** (string) If specified, this must be an IANA_SVC_NAME and unique within the pod. Each named port in a pod must have a unique name. Name for the port that can be referred to by services. - **ports.protocol** (string) Protocol for port. Must be UDP, TCP, or SCTP. Defaults to "TCP". Possible enum values: - `"SCTP"` is the SCTP protocol. - `"TCP"` is the TCP protocol. - `"UDP"` is the UDP protocol. - **resources** (ResourceRequirements) Resources are not allowed for ephemeral containers. Ephemeral containers use spare resources already allocated to the pod. <a name="ResourceRequirements"></a> *ResourceRequirements describes the compute resource requirements.* - **resources.limits** (map[string]<a href="{{< ref "../common-definitions/quantity#Quantity" >}}">Quantity</a>) Limits describes the maximum amount of compute resources allowed. More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ - **resources.requests** (map[string]<a href="{{< ref "../common-definitions/quantity#Quantity" >}}">Quantity</a>) Requests describes the minimum amount of compute resources required. If Requests is omitted for a container, it defaults to Limits if that is explicitly specified, otherwise to an implementation-defined value. More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ - **lifecycle** (Lifecycle) Lifecycle is not allowed for ephemeral containers. <a name="Lifecycle"></a> *Lifecycle describes actions that the management system should take in response to container lifecycle events. For the PostStart and PreStop lifecycle handlers, management of the container blocks until the action is complete, unless the container process fails, in which case the handler is aborted.* - **lifecycle.postStart** (<a href="{{< ref "../workload-resources/pod-v1#LifecycleHandler" >}}">LifecycleHandler</a>) PostStart is called immediately after a container is created. If the handler fails, the container is terminated and restarted according to its restart policy. Other management of the container blocks until the hook completes. More info: https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks - **lifecycle.preStop** (<a href="{{< ref "../workload-resources/pod-v1#LifecycleHandler" >}}">LifecycleHandler</a>) PreStop is called immediately before a container is terminated due to an API request or management event such as liveness/startup probe failure, preemption, resource contention, etc. The handler is not called if the container crashes or exits. The Pod's termination grace period countdown begins before the PreStop hook is executed. Regardless of the outcome of the handler, the container will eventually terminate within the Pod's termination grace period (unless delayed by finalizers). Other management of the container blocks until the hook completes or until the termination grace period is reached. More info: https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks - **livenessProbe** (<a href="{{< ref "../workload-resources/pod-v1#Probe" >}}">Probe</a>) Probes are not allowed for ephemeral containers. - **readinessProbe** (<a href="{{< ref "../workload-resources/pod-v1#Probe" >}}">Probe</a>) Probes are not allowed for ephemeral containers. </ins> - **startupProbe** (<a href="{{< ref "../workload-resources/pod-v1#Probe" >}}">Probe</a>) Probes are not allowed for ephemeral containers.

Discussion:
This is a Bug Report <!--Required Information--Problem: Setting for ephemeral containers is allowed as of Kubernetes 1.22, but it's still showing up as a "not allowed" field here: Proposed Solution: This page looks to be autogenerated based on the API definition, but I'm not sure how it's detecting not allowed fields. If it's automatic we'll correct the metadata or if it's curated then just reclassify the field in docs. Page to Update:
/assign
The fix is likely to happen within
is autogenerated. I don't think received field updates for v1.22
Track the update of the documentation as an issue in this repository. /triage accepted
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
Looks like this is still happening, and also is showing up under the alpha heading even though its description says (correctly) that it's beta. This dropped off my radar, but I'll take a look at it in the next few days. /remove-lifecycle stale
/priority critical-urgent
/remove-priority critical-urgent /priority important-soon /sig security you're welcome to make a case for raising it back to critical. What would be the motivation there?
Hi I don't wish to make that case. I was just trying to assign a priority according to guidance and . The documentation is wrong for a core feature, which seems like a "fix it now" rather than "fix it in the next release" priority. The priority isn't important to me, though. Happy for it to be whatever you think is best.
This repo uses continuous deployment (we don't wait for a release for fixes). Anyway, yes, it looks important.