Change:
Overhead represents the resource overhead associated with running a pod for a given RuntimeClass. This field will be autopopulated at admission time by the RuntimeClass admission controller. If the RuntimeClass admission controller is enabled, overhead must not be set in Pod create requests. The RuntimeClass admission controller will reject Pod create requests which have the overhead already set. If RuntimeClass is configured and selected in the PodSpec, Overhead will be set to the value defined in the corresponding RuntimeClass, otherwise it will remain unset and treated as zero. More info: https://git.k8s.io/enhancements/keps/sig-node/688-pod-overhead/README.md This field is beta-level as of Kubernetes v1.18, and is only honored by servers that enable the PodOverhead feature. <del> ### Alpha level - **ephemeralContainers** ([]<a href="{{< ref "../workload-resources/pod-v1#EphemeralContainer" >}}">EphemeralContainer</a>) *Patch strategy: merge on key `name`* List of ephemeral containers run in this pod. Ephemeral containers may be run in an existing pod to perform user-initiated actions such as debugging. This list cannot be specified when creating a pod, and it cannot be modified by updating the pod spec. In order to add an ephemeral container to an existing pod, use the pod's ephemeralcontainers subresource. This field is beta-level and available on clusters that haven't disabled the EphemeralContainers feature gate. </del> ### Deprecated

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.