Merge branch 'kubernetes:main' into master

2021-12-09 15:12:00 -05:00
parent 8dfd425486 0a2da8cb46
commit d4388492c5
293 changed files with 69038 additions and 9792 deletions
@@ -6,6 +6,7 @@
    - initContainers
    - imagePullSecrets
    - enableServiceLinks
    - os
  - name: Volumes
    fields:
    - volumes
@@ -154,6 +155,7 @@
    - timeoutSeconds
    - failureThreshold
    - successThreshold
    - grpc
 - definition: io.k8s.api.core.v1.SecurityContext
  field_categories:
@@ -313,6 +315,7 @@
    - revisionHistoryLimit
    - volumeClaimTemplates
    - minReadySeconds
    - persistentVolumeClaimRetentionPolicy
 - definition: io.k8s.api.apps.v1.StatefulSetUpdateStrategy
  field_categories:
@@ -393,6 +396,9 @@
    - completedIndexes
    - conditions
    - uncountedTerminatedPods
  - name: Alpha level
    fields:
    - ready
 - definition: io.k8s.api.batch.v1.CronJobSpec
  field_categories:
@@ -421,6 +427,22 @@
    - value
    - periodSeconds
 - definition: io.k8s.api.autoscaling.v2.HorizontalPodAutoscalerSpec
  field_categories:
  - fields:
    - maxReplicas
    - scaleTargetRef
    - minReplicas
    - behavior
    - metrics
 - definition: io.k8s.api.autoscaling.v2.HPAScalingPolicy
  field_categories:
  - fields:
    - type
    - value
    - periodSeconds
 - definition: io.k8s.api.core.v1.ServiceSpec
  field_categories:
  - fields:
@@ -23,7 +23,7 @@ parts:
    - PodSpec
    - Container
    - EphemeralContainer
-    - Handler
+    - LifecycleHandler
    - NodeAffinity
    - PodAffinity
    - PodAntiAffinity
@@ -60,6 +60,9 @@ parts:
  - name: HorizontalPodAutoscaler
    group: autoscaling
    version: v1
  - name: HorizontalPodAutoscaler
    group: autoscaling
    version: v2
  - name: HorizontalPodAutoscaler
    group: autoscaling
    version: v2beta2
@@ -217,10 +220,10 @@ parts:
    version: v1
  - name: FlowSchema
    group: flowcontrol.apiserver.k8s.io
-    version: v1beta1
+    version: v1beta2
  - name: PriorityLevelConfiguration
    group: flowcontrol.apiserver.k8s.io
-    version: v1beta1
+    version: v1beta2
  - name: Binding
    group: ""
    version: v1
@@ -7,7 +7,7 @@ $announcement-size-adjustment: 8px;
  }
  main {
-    img {
+    *:not(figure) > img {
      max-width: 100%;
    }
@@ -601,7 +601,7 @@ body.td-documentation {
 #announcement {
  > * {
    color: inherit;
-    background: inherit;
+    background: transparent;
  }
  a {
@@ -698,6 +698,26 @@ body.td-documentation {
  }
 }
 figure {
  > figcaption {
    padding-top: 1em;
    margin-bottom: 3em;
  }
 }
 // Clamp size for release logos
 figure.release-logo {
  > figcaption {
    font-size: 1.8em;
  }
  > img {
    max-width: 100%;
    max-height: calc(max(40em,min(80vh,70em)));
    height: auto;
    width: auto;
  }
 }
 // Match Docsy-imposed max width on text body
@media (min-width: 1200px) {
@@ -139,10 +139,10 @@ time_format_default = "January 02, 2006 at 3:04 PM PST"
 description = "Production-Grade Container Orchestration"
 showedit = true
-latest = "v1.22"
+latest = "v1.23"
-fullversion = "v1.22.0"
+fullversion = "v1.23.0"
-version = "v1.22"
+version = "v1.23"
 githubbranch = "main"
 docsbranch = "main"
 deprecated = false
@@ -179,40 +179,40 @@ js = [
 ]
 [[params.versions]]
-fullversion = "v1.22.0"
+fullversion = "v1.23.0"
-version = "v1.22"
+version = "v1.23"
-githubbranch = "v1.22.0"
+githubbranch = "v1.23.0"
 docsbranch = "main"
 url = "https://kubernetes.io"
 [[params.versions]]
-fullversion = "v1.21.4"
+fullversion = "v1.22.4"
 version = "v1.22"
 githubbranch = "v1.22.4"
 docsbranch = "release-1.22"
 url = "https://v1-22.docs.kubernetes.io"
 [[params.versions]]
 fullversion = "v1.21.7"
 version = "v1.21"
-githubbranch = "v1.21.4"
+githubbranch = "v1.21.7"
 docsbranch = "release-1.21"
 url = "https://v1-21.docs.kubernetes.io"
 [[params.versions]]
-fullversion = "v1.20.10"
+fullversion = "v1.20.13"
 version = "v1.20"
-githubbranch = "v1.20.10"
+githubbranch = "v1.20.13"
 docsbranch = "release-1.20"
 url = "https://v1-20.docs.kubernetes.io"
 [[params.versions]]
-fullversion = "v1.19.14"
+fullversion = "v1.19.16"
 version = "v1.19"
-githubbranch = "v1.19.14"
+githubbranch = "v1.19.16"
 docsbranch = "release-1.19"
 url = "https://v1-19.docs.kubernetes.io"
 [[params.versions]]
 fullversion = "v1.18.20"
 version = "v1.18"
 githubbranch = "v1.18.20"
 docsbranch = "release-1.18"
 url = "https://v1-18.docs.kubernetes.io"
 # User interface configuration
 [params.ui]
 # Enable to show the side bar menu in its compact state.
@@ -43,12 +43,12 @@ Kubernetes is open source giving you the freedom to take advantage of on-premise
        <button id="desktopShowVideoButton" onclick="kub.showVideo()">Watch Video</button>
        <br>
        <br>
        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna21" button id="desktopKCButton">Attend KubeCon North America on October 11-15, 2021</a>
        <br>
        <br>
        <br>
        <br>
        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe-2022/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu22" button id="desktopKCButton">Attend KubeCon Europe on May 17-20, 2022</a>
        <br>
        <br>
        <br>
        <br>
        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna21" button id="desktopKCButton">Attend KubeCon North America on October 24-28, 2022</a>
 </div>
 <div id="videoPlayer">
    <iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>
@@ -4,6 +4,8 @@ title:  'Health checking gRPC servers on Kubernetes'
 date: 2018-10-01
 ---
 _Built-in gRPC probes were introduced in Kubernetes 1.23. To learn more, see [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe)._
 **Author**: [Ahmet Alp Balkan](https://twitter.com/ahmetb) (Google)
 [gRPC](https://grpc.io) is on its way to becoming the lingua franca for
@@ -28,7 +28,7 @@ metadata:
  name: shared-cache
 spec:
  accessModes:
-  - ReadWriteMany # Allow many pods to access shared-cache simultaneously.
+  - ReadWriteMany # Allow many nodes to access shared-cache simultaneously.
  resources:
    requests:
      storage: 1Gi
@@ -0,0 +1,199 @@
 ---
 layout: blog
 title: "Kubernetes 1.23 Prevent PersistentVolume leaks when deleting out of order"
 date: 2021-12-15T10:00:00-08:00
 slug: kubernetes-1-23-prevent-persistentvolume-leaks-when-deleting-out-of-order
 ---
 **Author:** Deepak Kinni (VMware)
 [PersistentVolume](/docs/concepts/storage/persistent-volumes/) (or PVs for short) are
 associated with [Reclaim Policy](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#reclaim-policy).
 The Reclaim Policy is used to determine the actions that need to be taken by the storage
 backend on deletion of the PV.
 Where the reclaim policy is `Delete`, the expectation is that the storage backend
 releases the storage resource that was allocated for the PV. In essence, the reclaim
 policy needs to honored on PV deletion.
 With the recent Kubernetes v1.23 release, an alpha feature lets you configure your
 cluster to behave that way and honor the configured reclaim policy.
 ## How did reclaim work in previous Kubernetes releases?
 [PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/#Introduction) (or PVC for short) is
 a request for storage by a user. A PV and PVC are considered [Bound](/docs/concepts/storage/persistent-volumes/#Binding)
 if there is a newly created PV or a matching PV is found. The PVs themselves are
 backed by a volume allocated by the storage backend. 
 Normally, if the volume is to be deleted, then the expectation is to delete the
 PVC for a bound PV-PVC pair. However, there are no restrictions to delete a PV
 prior to deleting a PVC.
 First, I'll demonstrate the behavior for clusters that are running an older version of Kubernetes.
 #### Retrieve an PVC that is bound to a PV
 Retrieve an existing PVC `example-vanilla-block-pvc`
 ```
 kubectl get pvc example-vanilla-block-pvc
 ```
 The following output shows the PVC and it's `Bound` PV, the PV is shown under the `VOLUME` column:
 ```
 NAME                        STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS               AGE
 example-vanilla-block-pvc   Bound    pvc-6791fdd4-5fad-438e-a7fb-16410363e3da   5Gi        RWO            example-vanilla-block-sc   19s
 ```
 #### Delete PV
 When I try to delete a bound PV, the cluster blocks and the `kubectl` tool does
 not return back control to the shell; for example:
 ```
 kubectl delete pv pvc-6791fdd4-5fad-438e-a7fb-16410363e3da
 ```
 ```
 persistentvolume "pvc-6791fdd4-5fad-438e-a7fb-16410363e3da" deleted
 ^C
 ```
 Retrieving the PV:
 ```
 kubectl get pv pvc-6791fdd4-5fad-438e-a7fb-16410363e3da
 ```
 It can be observed that the PV is in `Terminating` state
 ```
 NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS        CLAIM                               STORAGECLASS               REASON   AGE
 pvc-6791fdd4-5fad-438e-a7fb-16410363e3da   5Gi        RWO            Delete           Terminating   default/example-vanilla-block-pvc   example-vanilla-block-sc            2m23s
 ```
 #### Delete PVC
 ```
 kubectl delete pvc example-vanilla-block-pvc
 ```
 The following output is seen if the PVC gets successfully deleted:
 ```
 persistentvolumeclaim "example-vanilla-block-pvc" deleted
 ```
 The PV object from the cluster also gets deleted. When attempting to retrieve the PV
 it will be observed that the PV is no longer found:
 ```
 kubectl get pv pvc-6791fdd4-5fad-438e-a7fb-16410363e3da
 ```
 ```
 Error from server (NotFound): persistentvolumes "pvc-6791fdd4-5fad-438e-a7fb-16410363e3da" not found
 ```
 Although the PV is deleted the underlying storage resource is not deleted, and
 needs to be removed manually.
 To sum it up, the reclaim policy associated with the Persistent Volume is currently
 ignored under certain circumstance. For a `Bound` PV-PVC pair the ordering of PV-PVC
 deletion determines whether the PV reclaim policy is honored. The reclaim policy 
 is honored if the PVC is deleted first, however, if the PV is deleted prior to 
 deleting the PVC then the reclaim policy is not exercised. As a result of this behavior,
 the associated storage asset in the external infrastructure is not removed.
 ## PV reclaim policy with Kubernetes v1.23
 The new behavior ensures that the underlying storage object is deleted from the backend when users attempt to delete a PV manually.
 #### How to enable new behavior?
 To make use of the new behavior, you must have upgraded your cluster to the v1.23 release of Kubernetes.
 You need to make sure that you are running the CSI [`external-provisioner`](https://github.com/kubernetes-csi/external-provisioner) version `4.0.0`, or later.
 You must also enable the `HonorPVReclaimPolicy` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the
 `external-provisioner` and for the `kube-controller-manager`.
 If you're not using a CSI driver to integrate with your storage backend, the fix isn't
 available. The Kubernetes project doesn't have a current plan to fix the bug for in-tree
 storage drivers: the future of those in-tree drivers is deprecation and migration to CSI.
 #### How does it work?
 The new behavior is achieved by adding a finalizer `external-provisioner.volume.kubernetes.io/finalizer` on new and existing PVs, the finalizer is only removed after the storage from backend is deleted.
 An example of a PV with the finalizer, notice the new finalizer in the finalizers list
 ```
 kubectl get pv pvc-a7b7e3ba-f837-45ba-b243-dec7d8aaed53 -o yaml
 ```
 ```yaml
 apiVersion: v1
 kind: PersistentVolume
 metadata:
  annotations:
    pv.kubernetes.io/provisioned-by: csi.vsphere.vmware.com
  creationTimestamp: "2021-11-17T19:28:56Z"
  finalizers:
  - kubernetes.io/pv-protection
  - external-provisioner.volume.kubernetes.io/finalizer
  name: pvc-a7b7e3ba-f837-45ba-b243-dec7d8aaed53
  resourceVersion: "194711"
  uid: 087f14f2-4157-4e95-8a70-8294b039d30e
 spec:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 1Gi
  claimRef:
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: example-vanilla-block-pvc
    namespace: default
    resourceVersion: "194677"
    uid: a7b7e3ba-f837-45ba-b243-dec7d8aaed53
  csi:
    driver: csi.vsphere.vmware.com
    fsType: ext4
    volumeAttributes:
      storage.kubernetes.io/csiProvisionerIdentity: 1637110610497-8081-csi.vsphere.vmware.com
      type: vSphere CNS Block Volume
    volumeHandle: 2dacf297-803f-4ccc-afc7-3d3c3f02051e
  persistentVolumeReclaimPolicy: Delete
  storageClassName: example-vanilla-block-sc
  volumeMode: Filesystem
 status:
  phase: Bound
 ```
 The presence of the finalizer prevents the PV object from being removed from the
 cluster. As stated previously, the finalizer is only removed from the PV object
 after it is successfully deleted from the storage backend. To learn more about
 finalizers, please refer to [Using Finalizers to Control Deletion](/blog/2021/05/14/using-finalizers-to-control-deletion/).
 #### What about CSI migrated volumes?
 The fix is applicable to CSI migrated volumes as well. However, when the feature
 `HonorPVReclaimPolicy` is enabled on 1.23, and CSI Migration is disabled, the finalizer
 is removed from the PV object if it exists.
 ### Some caveats
 1. The fix is applicable only to CSI volumes and migrated volumes. In-tree volumes will exhibit older behavior.
 2. The fix is introduced as an alpha feature in the [external-provisioner](https://github.com/kubernetes-csi/external-provisioner) under the feature gate `HonorPVReclaimPolicy`. The feature is disabled by default, and needs to be enabled explicitly.
 ### References
 * [KEP-2644](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/2644-honor-pv-reclaim-policy)
 * [Volume leak issue](https://github.com/kubernetes-csi/external-provisioner/issues/546)
 ### How do I get involved?
 The Kubernetes Slack channel [SIG Storage communication channels](https://github.com/kubernetes/community/blob/master/sig-storage/README.md#contact) are great mediums to reach out to the SIG Storage and migration working group teams.
 Special thanks to the following people for the insightful reviews, thorough consideration and valuable contribution:
 * Jan Šafránek (jsafrane)
 * Xing Yang (xing-yang)
 * Matthew Wong (wongma7)
 Those interested in getting involved with the design and development of CSI or any part of the Kubernetes Storage system, join the [Kubernetes Storage Special Interest Group (SIG)](https://github.com/kubernetes/community/tree/master/sig-storage). We’re rapidly growing and always welcome new contributors.
@@ -0,0 +1,188 @@
 ---
 layout: blog
 title: 'Kubernetes 1.23: The Next Frontier'
 date: 2021-12-07
 slug: kubernetes-1-23-release-announcement
 ---
 **Authors:** [Kubernetes 1.23 Release Team](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.23/release-team.md)
 We’re pleased to announce the release of Kubernetes 1.23, the last release of 2021!
 This release consists of 47 enhancements: 11 enhancements have graduated to stable, 17 enhancements are moving to beta, and 19 enhancements are entering alpha. Also, 1 feature has been deprecated.     
 ## Major Themes
 ### Deprecation of FlexVolume
 FlexVolume is deprecated. The out-of-tree CSI driver is the recommended way to write volume drivers in Kubernetes. See [this doc](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md#kubernetes-volume-plugin-faq-for-storage-vendors) for more information. Maintainers of FlexVolume drivers should implement a CSI driver and move users of FlexVolume to CSI. Users of FlexVolume should move their workloads to the CSI driver.
 ### Deprecation of klog specific flags
 To simplify the code base, several [logging flags were marked as deprecated](https://kubernetes.io/docs/concepts/cluster-administration/system-logs/#klog) in Kubernetes 1.23. The code which implements them will be removed in a future release, so users of those need to start replacing the deprecated flags with some alternative solutions.
 ### Software Supply Chain SLSA Level 1 Compliance in the Kubernetes Release Process
 Kubernetes releases now generate provenance attestation files describing the staging and release phases of the release process. Artifacts are now verified as they are handed over from one phase to the next. This final piece completes the work needed to comply with Level 1 of the [SLSA security framework](https://slsa.dev/) (Supply-chain Levels for Software Artifacts).
 ### IPv4/IPv6 Dual-stack Networking graduates to GA
 [IPv4/IPv6 dual-stack networking](https://github.com/kubernetes/enhancements/tree/master/keps/sig-network/563-dual-stack) graduates to GA. Since 1.21, Kubernetes clusters have been enabled to support dual-stack networking by default. In 1.23, the `IPv6DualStack` feature gate is removed. The use of dual-stack networking is not mandatory. Although clusters are enabled to support dual-stack networking, Pods and Services continue to default to single-stack. To use dual-stack networking Kubernetes nodes must have routable IPv4/IPv6 network interfaces, a dual-stack capable CNI network plugin must be used, Pods must be configured to be dual-stack and Services must have their `.spec.ipFamilyPolicy` field set to either `PreferDualStack` or `RequireDualStack`.
 ### HorizontalPodAutoscaler v2 graduates to GA
 The HorizontalPodAutscaler `autoscaling/v2` stable API moved to GA in 1.23. The HorizontalPodAutoscaler `autoscaling/v2beta2` API has been deprecated.
 ### Generic Ephemeral Volume feature graduates to GA
 The generic ephemeral volume feature moved to GA in 1.23. This feature allows any existing storage driver that supports dynamic provisioning to be used as an ephemeral volume with the volume’s lifecycle bound to the Pod. All StorageClass parameters for volume provisioning and all features supported with PersistentVolumeClaims are supported.
 ### Skip Volume Ownership change graduates to GA
 The feature to configure volume permission and ownership change policy for Pods moved to GA in 1.23. This allows users to skip recursive permission changes on mount and speeds up the pod start up time.
 ### Allow CSI drivers to opt-in to volume ownership and permission change graduates to GA
 The feature to allow CSI Drivers to declare support for fsGroup based permissions graduates to GA in 1.23.
 ### PodSecurity graduates to Beta
 [PodSecurity](https://kubernetes.io/docs/concepts/security/pod-security-admission/) moves to Beta. `PodSecurity` replaces the deprecated `PodSecurityPolicy` admission controller. `PodSecurity` is an admission controller that enforces Pod Security Standards on Pods in a Namespace based on specific namespace labels that set the enforcement level. In 1.23, the `PodSecurity` feature gate is enabled by default.
 ### Container Runtime Interface (CRI) v1 is default
 The Kubelet now supports the CRI `v1` API, which is now the project-wide default. 
 If a container runtime does not support the `v1` API, Kubernetes will fall back to the `v1alpha2` implementation. There is no intermediate action required by end-users, because `v1` and `v1alpha2` do not differ in their implementation. It is likely that `v1alpha2` will be removed in one of the future Kubernetes releases to be able to develop `v1`.
 ### Structured logging graduate to Beta
 Structured logging reached its Beta milestone. Most log messages from kubelet and kube-scheduler have been converted. Users are encouraged to try out JSON output or parsing of the structured text format and provide feedback on possible solutions for the open issues, such as handling of multi-line strings in log values.
 ### Simplified Multi-point plugin configuration for scheduler
 The kube-scheduler is adding a new, simplified config field for Plugins to allow multiple extension points to be enabled in one spot. The new `multiPoint` plugin field is intended to simplify most scheduler setups for administrators. Plugins that are enabled via `multiPoint` will automatically be registered for each individual extension point that they implement. For example, a plugin that implements Score and Filter extensions can be simultaneously enabled for both. This means entire plugins can be enabled and disabled without having to manually edit individual extension point settings. These extension points can now be abstracted away due to their irrelevance for most users.
 ### CSI Migration updates
 CSI Migration enables the replacement of existing in-tree storage plugins such as `kubernetes.io/gce-pd` or `kubernetes.io/aws-ebs` with a corresponding CSI driver. 
 If CSI Migration is working properly, Kubernetes end users shouldn’t notice a difference. 
 After migration, Kubernetes users may continue to rely on all the functionality of in-tree storage plugins using the existing interface.
 - CSI Migration feature is turned on by default but stays in Beta for GCE PD, AWS EBS, and Azure Disk in 1.23.
 - CSI Migration is introduced as an Alpha feature for Ceph RBD and Portworx in 1.23.
 ### Expression language validation for CRD is alpha
 Expression language validation for CRD is in alpha starting in 1.23. If the `CustomResourceValidationExpressions` feature gate is enabled, custom resources will be validated by validation rules using the [Common Expression Language (CEL)](https://github.com/google/cel-spec).
 ### Server Side Field Validation is Alpha
 If the `ServerSideFieldValidation` feature gate is enabled starting 1.23, users will receive warnings from the server when they send Kubernetes objects in the request that contain unknown or duplicate fields. Previously unknown fields and all but the last duplicate fields would be dropped by the server.
 With the feature gate enabled, we also introduce the `fieldValidation` query parameter so that users can specify the desired behavior of the server on a per request basis. Valid values for the `fieldValidation` query parameter are:
 - Ignore (default when feature gate is disabled, same as pre-1.23 behavior of dropping/ignoring unkonwn fields)
 - Warn (default when feature gate is enabled).
 - Strict (this will fail the request with an Invalid Request error)
 ### OpenAPI v3 is Alpha
 If the `OpenAPIV3` feature gate is enabled starting 1.23, users will be able to request the OpenAPI v3.0 spec for all Kubernetes types. OpenAPI v3 aims to be fully transparent and includes support for a set of fields that are dropped when publishing OpenAPI v2: `default`, `nullable`, `oneOf`, `anyOf`. A separate spec is published per Kubernetes group version (at the `$cluster/openapi/v3/apis/<group>/<version>` endpoint) for improved performance and discovery, for all group versions can be found at the `$cluster/openapi/v3` path.
 ## Other Updates
 ### Graduated to Stable
 - [IPv4/IPv6 Dual-Stack Support](https://github.com/kubernetes/enhancements/issues/563)
 - [Skip Volume Ownership Change](https://github.com/kubernetes/enhancements/issues/695)
 - [TTL After Finished Controller](https://github.com/kubernetes/enhancements/issues/592)
 - [Config FSGroup Policy in CSI Driver object](https://github.com/kubernetes/enhancements/issues/1682)
 - [Generic Ephemeral Inline Volumes](https://github.com/kubernetes/enhancements/issues/1698)
 - [Defend Against Logging Secrets via Static Analysis](https://github.com/kubernetes/enhancements/issues/1933)
 - [Namespace Scoped Ingress Class Parameters](https://github.com/kubernetes/enhancements/issues/2365)
 - [Reducing Kubernetes Build Maintenance](https://github.com/kubernetes/enhancements/issues/2420)
 - [Graduate HPA API to GA](https://github.com/kubernetes/enhancements/issues/2702)
 ### Major Changes
 - [Priority and Fairness for API Server Requests](https://github.com/kubernetes/enhancements/issues/1040)
 ### Release Notes
 Check out the full details of the Kubernetes 1.23 release in our [release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.23.md).
 ### Availability
 Kubernetes 1.23 is available for download on [GitHub](https://github.com/kubernetes/kubernetes/releases/tag/v1.23.0). To get started with Kubernetes, check out these [interactive tutorials](https://kubernetes.io/docs/tutorials/) or run local Kubernetes clusters using Docker container “nodes” with [kind](https://kind.sigs.k8s.io/). You can also easily install 1.23 using [kubeadm](https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/). 
 ### Release Team
 This release was made possible by a very dedicated group of individuals, who came together as a team to deliver technical content, documentation, code, and a host of other components that go into every Kubernetes release.
 A huge thank you to the release lead Rey Lejano for leading us through a successful release cycle, and to everyone else on the release team for supporting each other, and working so hard to deliver the 1.23 release for the community.
 ### Release Theme and Logo 
 **Kubernetes 1.23: The Next Frontier**
 {{< figure src="/images/blog/2021-12-07-kubernetes-release-1.23/kubernetes-1.23.png" alt="" class="release-logo" >}}
 "The Next Frontier" theme represents the new and graduated enhancements in 1.23, Kubernetes' history of Star Trek references, and the growth of community members in the release team.
 Kubernetes has a history of Star Trek references. The original codename for Kubernetes within Google is Project 7, a reference to Seven of Nine from Star Trek Voyager. And of course Borg was the name for the predecessor to Kubernetes. "The Next Frontier" theme continues the Star Trek references. "The Next Frontier" is a fusion of two Star Trek titles, Star Trek V: The Final Frontier and Star Trek the Next Generation.
 "The Next Frontier" represents a line in the SIG Release charter, "Ensure there is a consistent group of community members in place to support the release process across time." With each release team, we grow the community with new release team members and for many it's their first contribution in their open source frontier.
 Reference: https://kubernetes.io/blog/2015/04/borg-predecessor-to-kubernetes/
 Reference: https://github.com/kubernetes/community/blob/master/sig-release/charter.md
 The Kubernetes 1.23 release logo continues with the theme's Star Trek reference. Every star is a helm from the Kubernetes logo. The ship represents the collective teamwork of the release team.
 Rey Lejano designed the logo. 
 ### User Highlights
 - [Findings of the latest CNCF End User Technology Radar](https://www.cncf.io/announcements/2021/09/22/cncf-end-user-technology-radar-provides-insights-into-devsecops/) were themed around DevSecOps. Check out the [Radar Page](https://radar.cncf.io/) for the full details and findings.
 - Learn about how [end user Aegon Life India migrated core processes from its traditional monolith to a microservice-based architecture](https://www.cncf.io/case-studies/aegon-life-india/) in its effort to transform into a leading digital service company.
 - Utilizing multiple cloud native projects, [Seagate engineered edgerX to run Real-time Analytics at the Edge](https://www.cncf.io/case-studies/seagate/). 
 - Check out how [Zambon worked with SparkFabrik to develop 16 websites, with cloud native technologies, to enable stakeholders to easily update content while maintaining a consistent brand identity](https://www.cncf.io/case-studies/zambon/).
 - Using Kubernetes, [InfluxData was able to deliver on the promise of multi-cloud, multi-region service availability](https://www.cncf.io/case-studies/influxdata/) by creating a true cloud abstraction layer that allows for the seamless delivery of InfluxDB as a single application to multiple global clusters across three major cloud providers.
 ### Ecosystem Updates
 - [KubeCon + CloudNativeCon NA 2021](https://www.cncf.io/events/kubecon-cloudnativecon-north-america-2021/) was held in October 2021, both online and in person. All talks are [now available on-demand](https://www.youtube.com/playlist?list=PLj6h78yzYM2Nd1U4RMhv7v88fdiFqeYAP) for anyone that would like to catch up!
 - [Kubernetes and Cloud Native Essentials Training and KCNA Certification are now generally available for enrollment and scheduling](https://www.cncf.io/announcements/2021/11/18/kubernetes-and-cloud-native-essentials-training-and-kcna-certification-now-available/). Additionally, a new online training course, [Kubernetes and Cloud Native Essentials (LFS250)](https://www.cncf.io/announcements/2021/10/13/entry-level-kubernetes-certification-to-help-advance-cloud-careers/), has been released to both prepare individuals for entry-level cloud roles and to sit for the KCNA exam.
 - [New resources are now available from the Inclusive Naming Initiative](https://www.cncf.io/announcements/2021/10/13/inclusive-naming-initiative-announces-new-community-resources-for-a-more-inclusive-future/), including an Inclusive Strategies for Open Source (LFC103) course, Language Evaluation Framework, and Implementation Path.
 ### Project Velocity
 The [CNCF K8s DevStats](https://k8s.devstats.cncf.io/d/12/dashboards?orgId=1&refresh=15m) project aggregates a number of interesting data points related to the velocity of Kubernetes and various sub-projects. This includes everything from individual contributions to the number of companies that are contributing, and is an illustration of the depth and breadth of effort that goes into evolving this ecosystem.
 In the v1.23 release cycle, which ran for 16 weeks (August 23 to December 7), we saw contributions from [1032 companies](https://k8s.devstats.cncf.io/d/9/companies-table?orgId=1&var-period_name=v1.22.0%20-%20now&var-metric=contributions) and [1084 individuals](https://k8s.devstats.cncf.io/d/66/developer-activity-counts-by-companies?orgId=1&var-period_name=v1.22.0%20-%20now&var-metric=contributions&var-repogroup_name=Kubernetes&var-country_name=All&var-companies=All&var-repo_name=kubernetes%2Fkubernetes).
 ### Event Update
 - [KubeCon + CloudNativeCon China 2021](https://www.lfasiallc.com/kubecon-cloudnativecon-open-source-summit-china/) is happening this month from December 9 - 11. After taking a break last year, the event will be virtual this year and includes 105 sessions. Check out the event schedule [here](https://www.lfasiallc.com/kubecon-cloudnativecon-open-source-summit-china/program/schedule/).
 - KubeCon + CloudNativeCon Europe 2022 will take place in Valencia, Spain, May 4 – 7, 2022! You can find more information about the conference and registration on the [event site](https://events.linuxfoundation.org/archive/2021/kubecon-cloudnativecon-europe/).
 - Kubernetes Community Days has upcoming events scheduled in Pakistan, Brazil, Chengdu, and in Australia.
 ### Upcoming Release Webinar
 Join members of the Kubernetes 1.23 release team on January 4, 2022 to learn about the major features of this release, as well as deprecations and removals to help plan for upgrades. For more information and registration, visit the [event page](https://community.cncf.io/e/mrey9h/) on the CNCF Online Programs site.
 ### Get Involved
 The simplest way to get involved with Kubernetes is by joining one of the many [Special Interest Groups](https://github.com/kubernetes/community/blob/master/sig-list.md) (SIGs) that align with your interests. Have something you’d like to broadcast to the Kubernetes community? Share your voice at our weekly [community meeting](https://github.com/kubernetes/community/tree/master/communication), and through the channels below:
 - Find out more about contributing to Kubernetes at the [Kubernetes Contributors](https://www.kubernetes.dev/) website
 - Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for the latest updates
 - Join the community discussion on [Discuss](https://discuss.kubernetes.io/)
 - Join the community on [Slack](http://slack.k8s.io/)
 - Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)
 - Share your Kubernetes [story](https://docs.google.com/a/linuxfoundation.org/forms/d/e/1FAIpQLScuI7Ye3VQHQTwBASrgkjQDSS5TP0g3AXfFhwSM9YpHgxRKFA/viewform)
 - Read more about what’s happening with Kubernetes on the [blog](https://kubernetes.io/blog/)
 - Learn more about the [Kubernetes Release Team](https://github.com/kubernetes/sig-release/tree/master/release-team)
@@ -0,0 +1,56 @@
 ---
 layout: blog
 title: 'Kubernetes 1.23: Dual-stack IPv4/IPv6 Networking Reaches GA'
 date: 2021-12-08
 slug: dual-stack-networking-ga
 ---
 **Author:** Bridget Kromhout (Microsoft)
 "When will Kubernetes have IPv6?" This question has been asked with increasing frequency ever since alpha support for IPv6 was first added in k8s v1.9. While Kubernetes has supported IPv6-only clusters since v1.18, migration from IPv4 to IPv6 was not yet possible at that point. At long last, [dual-stack IPv4/IPv6 networking](https://github.com/kubernetes/enhancements/tree/master/keps/sig-network/563-dual-stack/) has reached general availability (GA) in Kubernetes v1.23.
 What does dual-stack networking mean for you? Let’s take a look…
 ## Service API updates
 [Services](/docs/concepts/services-networking/service/) were single-stack before 1.20, so using both IP families meant creating one Service per IP family. The user experience was simplified in 1.20, when Services were re-implemented to allow both IP families, meaning a single Service can handle both IPv4 and IPv6 workloads. Dual-stack load balancing is possible between services running any combination of IPv4 and IPv6.
 The Service API now has new fields to support dual-stack, replacing the single ipFamily field.
 * You can select your choice of IP family by setting `ipFamilyPolicy` to one of three options: SingleStack, PreferDualStack, or RequireDualStack. A service can be changed between single-stack and dual-stack (within some limits).
 * Setting `ipFamilies` to a list of families assigned allows you to set the order of families used.
 * `clusterIPs` is inclusive of the previous `clusterIP` but allows for multiple entries, so it’s no longer necessary to run duplicate services, one in each of the two IP families. Instead, you can assign cluster IP addresses in both IP families.
 Note that Pods are also dual-stack. For a given pod, there is no possibility of setting multiple IP addresses in the same family.
 ## Default behavior remains single-stack
 Starting in 1.20 with the re-implementation of dual-stack services as alpha, the underlying networking for Kubernetes has included dual-stack whether or not a cluster was configured with the feature flag to enable dual-stack.
 Kubernetes 1.23 removed that feature flag as part of graduating the feature to stable. Dual-stack networking is always available if you want to configure it. You can set your cluster network to operate as single-stack IPv4, as single-stack IPv6, or as dual-stack IPv4/IPv6.
 While Services are set according to what you configure, Pods default to whatever the CNI plugin sets. If your CNI plugin assigns single-stack IPs, you will have single-stack unless `ipFamilyPolicy` specifies PreferDualStack or RequireDualStack. If your CNI plugin assigns dual-stack IPs, `pod.status.PodIPs` defaults to dual-stack.
 Even though dual-stack is possible, it is not mandatory to use it. Examples in the documentation show the variety possible in [dual-stack service configurations](/docs/concepts/services-networking/dual-stack/#dual-stack-service-configuration-scenarios).
 ## Try dual-stack right now
 While upstream Kubernetes now supports [dual-stack networking](/docs/concepts/services-networking/dual-stack/) as a GA or stable feature, each provider’s support of dual-stack Kubernetes may vary. Nodes need to be provisioned with routable IPv4/IPv6 network interfaces. Pods need to be dual-stack. The [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) is what assigns the IP addresses to the Pods, so it's the network plugin being used for the cluster that needs to support dual-stack. Some Container Network Interface (CNI) plugins support dual-stack, as does kubenet.
 Ecosystem support of dual-stack is increasing; you can create [dual-stack clusters with kubeadm](/docs/setup/production-environment/tools/kubeadm/dual-stack-support/), try a [dual-stack cluster locally with KIND](https://kind.sigs.k8s.io/docs/user/configuration/#ip-family), and deploy dual-stack clusters in cloud providers (after checking docs for CNI or kubenet availability).
 ## Get involved with SIG Network
 SIG-Network wants to learn from community experiences with dual-stack networking to find out more about evolving needs and your use cases. The [SIG-network update video from KubeCon NA 2021](https://www.youtube.com/watch?v=uZ0WLxpmBbY&list=PLj6h78yzYM2Nd1U4RMhv7v88fdiFqeYAP&index=4) summarizes the SIG’s recent updates, including dual-stack going to stable in 1.23.
 The current SIG-Network [KEPs](https://github.com/orgs/kubernetes/projects/10) and [issues](https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Asig%2Fnetwork) on GitHub illustrate the SIG’s areas of emphasis. The [dual-stack API server](https://github.com/kubernetes/enhancements/issues/2438) is one place to consider contributing.
 [SIG-Network meetings](https://github.com/kubernetes/community/tree/master/sig-network#meetings) are a friendly, welcoming venue for you to connect with the community and share your ideas. Looking forward to hearing from you!
 ## Acknowledgments
 The dual-stack networking feature represents the work of many Kubernetes contributors. Thanks to all who contributed code, experience reports, documentation, code reviews, and everything in between. Bridget Kromhout details this community effort in [Dual-Stack Networking in Kubernetes](https://containerjournal.com/features/dual-stack-networking-in-kubernetes/). KubeCon keynotes by Tim Hockin & Khaled (Kal) Henidak in 2019 ([The Long Road to IPv4/IPv6 Dual-stack Kubernetes](https://www.youtube.com/watch?v=o-oMegdZcg4)) and by Lachlan Evenson in 2021 ([And Here We Go: Dual-stack Networking in Kubernetes](https://www.youtube.com/watch?v=lVrt8F2B9CM)) talk about the dual-stack journey, spanning five years and a great many lines of code.
@@ -0,0 +1,782 @@
 ---
 layout: blog
 title: 'Pod Security Graduates to Beta'
 date: 2021-12-09
 slug: pod-security-admission-beta
 ---
 **Authors:** Jim Angel (Google), Lachlan Evenson (Microsoft)
 With the release of Kubernetes v1.23, [Pod Security admission](/docs/concepts/security/pod-security-admission/) has now entered beta. Pod Security is a [built-in](/docs/reference/access-authn-authz/admission-controllers/) admission controller that evaluates pod specifications against a predefined set of [Pod Security Standards](/docs/concepts/security/pod-security-standards/) and determines whether to `admit` or `deny` the pod from running.
 Pod Security is the successor to [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/) which was deprecated in the v1.21 release, and will be removed in Kubernetes v1.25. In this article, we cover the key concepts of Pod Security along with how to use it. We hope that cluster administrators and developers alike will use this new mechanism to enforce secure defaults for their workloads.
 ## Why Pod Security
 The overall aim of Pod Security is to let you isolate workloads. You can run a cluster that runs different workloads and, without adding extra third-party tooling, implement controls that require Pods for a workload to restrict their own privileges to a defined bounding set.
 Pod Security overcomes key shortcomings of Kubernetes' existing, but deprecated, PodSecurityPolicy (PSP) mechanism:
   * Policy authorization model — challenging to deploy with controllers.
   * Risks around switching — a lack of dry-run/audit capabilities made it hard to enable PodSecurityPolicy.
   * Inconsistent and Unbounded API — the large configuration surface and evolving constraints led to a complex and confusing API.
 The shortcomings of PSP made it very difficult to use which led the community to reevaluate whether or not a better implementation could achieve the same goals. One of those goals was to provide an out-of-the-box solution to apply security best practices. Pod Security ships with predefined Pod Security levels that a cluster administrator can configure to meet the desired security posture.
 It's important to note that Pod Security doesn't have complete feature parity with the deprecated PodSecurityPolicy. Specifically, it doesn't have the ability to mutate or change Kubernetes resources to auto-remediate a policy violation on behalf of the user. Additionally, it doesn't provide fine-grained control over each allowed field and value within a pod specification or any other Kubernetes resource that you may wish to evaluate. If you need more fine-grained policy control then take a look at these [other](/docs/concepts/security/pod-security-standards/#faq) projects which support such use cases.
 Pod Security also adheres to Kubernetes best practices of declarative object management by denying resources that violate the policy. This requires resources to be updated in source repositories, and tooling to be updated prior to being deployed to Kubernetes.
 ## How Does Pod Security Work?
 Pod Security is a built-in [admission controller](/docs/reference/access-authn-authz/admission-controllers/) starting with Kubernetes v1.22, but can also be run as a standalone [webhook](/docs/concepts/security/pod-security-admission/#webhook). Admission controllers function by intercepting requests in the Kubernetes API server prior to persistence to storage. They can either `admit` or `deny` a request. In the case of Pod Security, pod specifications will be evaluated against a configured policy in the form of a Pod Security Standard. This means that security sensitive fields in a pod specification will only be allowed to have [specific](h/docs/concepts/security/pod-security-standards/#profile-details) values. 
 ## Configuring Pod Security
 ### Pod Security Standards
 In order to use Pod Security we first need to understand [Pod Security Standards](/docs/concepts/security/pod-security-standards/). These standards define three different policy levels that range from permissive to restrictive. These levels are as follows:
   * `privileged` — open and unrestricted
   * `baseline` — Covers known privilege escalations while minimizing restrictions
   * `restricted` — Highly restricted, hardening against known and unknown privilege escalations. May cause compatibility issues
 Each of these policy levels define which fields are restricted within a pod specification and the allowed values. Some of the fields restricted by these policies include:
   * `spec.securityContext.sysctls`
   * `spec.hostNetwork`
   * `spec.volumes[*].hostPath`
   * `spec.containers[*].securityContext.privileged`
 Policy levels are applied via labels on Namespace resources, which allows for granular per-namespace policy selection. The AdmissionConfiguration in the API server can also be configured to set cluster-wide default levels and exemptions.
 ### Policy modes
 Policies are applied in a specific mode. Multiple modes (with different policy levels) can be set on the same namespace. Here is a list of modes:
   * `enforce` — Any Pods that violate the policy will be rejected
   * `audit` — Violations will be recorded as an annotation in the audit logs, but don't affect whether the pod is allowed.
   * `warn` — Violations will send a warning message back to the user, but don't affect whether the pod is allowed.
 In addition to modes you can also pin the policy to a specific version (for example v1.22). Pinning to a specific version allows the behavior to remain consistent if the policy definition changes in future Kubernetes releases.
 ## Hands on demo
 ### Prerequisites
 - [KinD](https://kind.sigs.k8s.io/docs/user/quick-start/#installation)
 - [kubectl](/docs/tasks/tools/)
 - [Docker](https://docs.docker.com/get-docker/) or [Podman](https://podman.io/getting-started/installation) container runtime & CLI
 ### Deploy a kind cluster
 ```shell
 kind create cluster --image kindest/node:v1.23.0
 ```
 It might take a while to start and once it's started it might take a minute or so before the node becomes ready.
 ```shell
 kubectl cluster-info --context kind-kind
 ```
 Wait for the node STATUS to become ready.
 ```shell
 kubectl get nodes
 ```
 The output is similar to this:
 ```
 NAME                 STATUS   ROLES                  AGE   VERSION
 kind-control-plane   Ready    control-plane,master   54m   v1.23.0
 ```
 ### Confirm Pod Security is enabled
 The best way to [confirm the API's default enabled plugins](/docs/reference/access-authn-authz/admission-controllers/#which-plugins-are-enabled-by-default) is to check the Kubernetes API container's help arguments.
 ```shell
 kubectl -n kube-system exec kube-apiserver-kind-control-plane -it -- kube-apiserver -h | grep "default enabled ones"
 ```
 The output is similar to this:
 ```
 ...
      --enable-admission-plugins strings
 admission plugins that should be enabled in addition
 to default enabled ones (NamespaceLifecycle, LimitRanger,
 ServiceAccount, TaintNodesByCondition, PodSecurity, Priority,
 DefaultTolerationSeconds, DefaultStorageClass,
 StorageObjectInUseProtection, PersistentVolumeClaimResize,
 RuntimeClass, CertificateApproval, CertificateSigning,
 CertificateSubjectRestriction, DefaultIngressClass,
 MutatingAdmissionWebhook, ValidatingAdmissionWebhook,
 ResourceQuota).
 ...
 ```
 `PodSecurity` is listed in the group of default enabled admission plugins.
 If using a cloud provider, or if you don't have access to the API server, the best way to check would be to run a quick end-to-end test:
 ```shell
 kubectl create namespace verify-pod-security
 kubectl label namespace verify-pod-security pod-security.kubernetes.io/enforce=restricted
 # The following command does NOT create a workload (--dry-run=server)
 kubectl -n verify-pod-security run test --dry-run=server --image=busybox --privileged
 kubectl delete namespace verify-pod-security
 ```
 The output is similar to this:
 ```
 Error from server (Forbidden): pods "test" is forbidden: violates PodSecurity "restricted:latest": privileged (container "test" must not set securityContext.privileged=true), allowPrivilegeEscalation != false (container "test" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "test" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "test" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "test" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
 ```
 ### Configure Pod Security
 Policies are applied to a namespace via labels. These labels are as follows:
   * `pod-security.kubernetes.io/<MODE>: <LEVEL>` (required to enable pod security)
   * `pod-security.kubernetes.io/<MODE>-version: <VERSION>` (*optional*, defaults to latest)
 A specific version can be supplied for each enforcement mode. The version pins the policy to the version that was shipped as part of the Kubernetes release. Pinning to a specific Kubernetes version allows for deterministic policy behavior while allowing flexibility for future updates to Pod Security Standards. The possible <MODE(S)> are `enforce`, `audit` and `warn`.
 ### When to use `warn`?
 The typical uses for `warn` are to get ready for a future change where you want to enforce a different policy. The most two common cases would be:
 * `warn` at the same level but a different version (e.g. pin `enforce` to *restricted+v1.23* and `warn` at *restricted+latest*)
 * `warn` at a stricter level (e.g. `enforce` baseline, `warn` restricted)
 It's not recommended to use `warn` for the exact same level+version of the policy as `enforce`. In the admission sequence, if `enforce` fails, the entire sequence fails before evaluating the `warn`.
 First, create a namespace called `verify-pod-security` if not created earlier. For the demo, `--overwrite` is used when labeling to allow repurposing a single namespace for multiple examples.
 ```shell
 kubectl create namespace verify-pod-security
 ```
 ### Deploy demo workloads
 Each workload represents a higher level of security that would not pass the profile that comes after it.
 For the following examples, use the `busybox` container runs a `sleep` command for 1 million seconds (≅11 days) or until deleted. Pod Security is not interested in which container image you chose, but rather the Pod level settings and their implications for security.
 ### Privileged level and workload
 For the privileged pod, use the [privileged policy](/docs/concepts/security/pod-security-standards/#privileged). This allows the process inside a container to gain new processes (also known as "privilege escalation") and can be dangerous if untrusted.
 First, let's apply a restricted Pod Security level for a test.
 ```shell
 # enforces a "restricted" security policy and audits on restricted
 kubectl label --overwrite ns verify-pod-security \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/audit=restricted
 ```
 Next, try to deploy a privileged workload in the namespace.
 ```shell
 cat <<EOF | kubectl -n verify-pod-security apply -f -
 apiVersion: v1
 kind: Pod
 metadata:
  name: busybox-privileged
 spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000000"
    securityContext:
      allowPrivilegeEscalation: true
 EOF
 ```
 The output is similar to this:
 ```
 Error from server (Forbidden): error when creating "STDIN": pods "busybox-privileged" is forbidden: violates PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "busybox" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "busybox" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "busybox" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "busybox" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
 ```
 Now let's apply the privileged Pod Security level and try again.
 ```shell
 # enforces a "privileged" security policy and warns / audits on baseline
 kubectl label --overwrite ns verify-pod-security \
  pod-security.kubernetes.io/enforce=privileged \
  pod-security.kubernetes.io/warn=baseline \
  pod-security.kubernetes.io/audit=baseline
 ```
 ```shell
 cat <<EOF | kubectl -n verify-pod-security apply -f -
 apiVersion: v1
 kind: Pod
 metadata:
  name: busybox-privileged
 spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000000"
    securityContext:
      allowPrivilegeEscalation: true
 EOF
 ```
 The output is similar to this:
 ```
 pod/busybox-privileged created
 ```
 We can run `kubectl -n verify-pod-security get pods` to verify it is running. Clean up with:
 ```shell
 kubectl -n verify-pod-security delete pod busybox-privileged
 ```
 ### Baseline level and workload
 The [baseline policy](/docs/concepts/security/pod-security-standards/#baseline) demonstrates sensible defaults while preventing common container exploits.
 Let's revert back to a restricted Pod Security level for a quick test.
 ```shell
 # enforces a "restricted" security policy and audits on restricted
 kubectl label --overwrite ns verify-pod-security \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/audit=restricted
 ```
 Apply the workload.
 ```shell
 cat <<EOF | kubectl -n verify-pod-security apply -f -
 apiVersion: v1
 kind: Pod
 metadata:
  name: busybox-baseline
 spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000000"
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        add:
          - NET_BIND_SERVICE
          - CHOWN
 EOF
 ```
 The output is similar to this:
 ```
 Error from server (Forbidden): error when creating "STDIN": pods "busybox-baseline" is forbidden: violates PodSecurity "restricted:latest": unrestricted capabilities (container "busybox" must set securityContext.capabilities.drop=["ALL"]; container "busybox" must not include "CHOWN" in securityContext.capabilities.add), runAsNonRoot != true (pod or container "busybox" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "busybox" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
 ```
 Let's apply the baseline Pod Security level and try again.
 ```shell
 # enforces a "baseline" security policy and warns / audits on restricted
 kubectl label --overwrite ns verify-pod-security \
  pod-security.kubernetes.io/enforce=baseline \
  pod-security.kubernetes.io/warn=restricted \
  pod-security.kubernetes.io/audit=restricted
 ```
 ```shell
 cat <<EOF | kubectl -n verify-pod-security apply -f -
 apiVersion: v1
 kind: Pod
 metadata:
  name: busybox-baseline
 spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000000"
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        add:
          - NET_BIND_SERVICE
          - CHOWN
 EOF
 ```
 The output is similar to the following. Note that the warnings match the error message from the test above, but the pod is still successfully created.
 ```
 Warning: would violate PodSecurity "restricted:latest": unrestricted capabilities (container "busybox" must set securityContext.capabilities.drop=["ALL"]; container "busybox" must not include "CHOWN" in securityContext.capabilities.add), runAsNonRoot != true (pod or container "busybox" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "busybox" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
 pod/busybox-baseline created
 ```
 Remember, we set the `verify-pod-security` namespace to `warn` based on the restricted profile. We can run `kubectl -n verify-pod-security get pods` to verify it is running.  Clean up with:
 ```shell
 kubectl -n verify-pod-security delete pod busybox-baseline
 ```
 ### Restricted level and workload
 The [restricted policy](/docs/concepts/security/pod-security-standards/#restricted) requires rejection of all privileged parameters. It is the most secure with a trade-off for complexity.
 The restricted policy allows containers to add the `NET_BIND_SERVICE` capability only.
 While we've already tested restricted as a blocking function, let's try to get something running that meets all the criteria.
 First we need to reapply the restricted profile, for the last time.
 ```shell
 # enforces a "restricted" security policy and audits on restricted
 kubectl label --overwrite ns verify-pod-security \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/audit=restricted
 ```
 ```shell
 cat <<EOF | kubectl -n verify-pod-security apply -f -
 apiVersion: v1
 kind: Pod
 metadata:
  name: busybox-restricted
 spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000000"
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        add:
          - NET_BIND_SERVICE
 EOF
 ```
 The output is similar to this:
 ```
 Error from server (Forbidden): error when creating "STDIN": pods "busybox-restricted" is forbidden: violates PodSecurity "restricted:latest": unrestricted capabilities (container "busybox" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "busybox" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "busybox" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
 ```
 This is because the restricted profile explicitly requires that certain values are set to the most secure parameters.
 By requiring explicit values, manifests become more declarative and your entire security model can shift left. With the `restricted` level of enforcement, a company could audit their cluster's compliance based on permitted manifests.
 Let's fix each warning resulting in the following file:
 ```shell
 cat <<EOF | kubectl -n verify-pod-security apply -f -
 apiVersion: v1
 kind: Pod
 metadata:
  name: busybox-restricted
 spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000000"
    securityContext:
      seccompProfile:
        type: RuntimeDefault
      runAsNonRoot: true
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL
        add:
          - NET_BIND_SERVICE
 EOF
 ```
 The output is similar to this:
 ```
 pod/busybox-restricted created
 ```
 Run `kubectl -n verify-pod-security get pods` to verify it is running. The output is similar to this:
 ```
 NAME               READY   STATUS                       RESTARTS   AGE
 busybox-restricted   0/1     CreateContainerConfigError   0          2m26s
 ```
 Let's figure out why the container is not starting with `kubectl -n verify-pod-security describe pod busybox-restricted`. The output is similar to this:
 ```
 Events:
  Type     Reason     Age                    From               Message
  ----     ------     ----                   ----               -------
  Warning  Failed     2m29s (x8 over 3m55s)  kubelet            Error: container has runAsNonRoot and image will run as root (pod: "busybox-restricted_verify-pod-security(a4c6a62d-2166-41a9-b288-20df17cf5c90)", container: busybox)
 ```
 To solve this, set the effective UID (`runAsUser`) to a non-zero (root) value or use the `nobody` UID (65534).
 ```shell
 # delete the original pod
 kubectl -n verify-pod-security delete pod busybox-restricted
 # create the pod again with new runAsUser
 cat <<EOF | kubectl -n verify-pod-security apply -f -
 apiVersion: v1
 kind: Pod
 metadata:
  name: busybox-restricted
 spec:
  securityContext:
    runAsUser: 65534
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000000"
    securityContext:
      seccompProfile:
        type: RuntimeDefault
      runAsNonRoot: true
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL
        add:
          - NET_BIND_SERVICE
 EOF
 ```
 Run `kubectl -n verify-pod-security get pods` to verify it is running. The output is similar to this:
 ```
 NAME                 READY   STATUS    RESTARTS   AGE
 busybox-restricted   1/1     Running   0          25s
 ```
 Clean up the demo (restricted pod and namespace) with:
 ```shell
 kubectl delete namespace verify-pod-security
 ```
 At this point, if you wanted to dive deeper into linux permissions or what is permitted for a certain container, exec into the control plane and play around with `containerd` and `crictl inspect`.
 ```shell
 # if using docker, shell into the control plane
 docker exec -it kind-control-plane bash
 # list running containers
 crictl ps
 # inspect each one by container ID
 crictl inspect <CONTAINER ID>
 ```
 ### Applying a cluster-wide policy
 In addition to applying labels to namespaces to configure policy you can also configure cluster-wide policies and exemptions using the AdmissionConfiguration resource. 
 Using this resource, policy definitions are applied cluster-wide by default and any policy that is applied via namespace labels will take precedence. 
 There is no runtime configurable API for the `AdmissionConfiguration` configuration file so a cluster administrator would need to specify a path to the file below via the `--admission-control-config-file` flag on the API server. 
 In the following resource we are enforcing the baseline policy and warning and auditing the baseline policy. We are also making the kube-system namespace exempt from this policy.
 It's not recommended to alter control plane / clusters after install, so let's build a new cluster with a default policy on all namespaces.
 First, delete the current cluster.
 ```shell
 kind delete cluster
 ```
 Create a Pod Security configuration that `enforce` and `audit` baseline policies while using a restricted profile to `warn` the end user.
 ```shell
 cat <<EOF > pod-security.yaml
 apiVersion: apiserver.config.k8s.io/v1
 kind: AdmissionConfiguration
 plugins:
 - name: PodSecurity
  configuration:
    apiVersion: pod-security.admission.config.k8s.io/v1beta1
    kind: PodSecurityConfiguration
    defaults:
      enforce: "baseline"
      enforce-version: "latest"
      audit: "baseline"
      audit-version: "latest"
      warn: "restricted"
      warn-version: "latest"
    exemptions:
      # Array of authenticated usernames to exempt.
      usernames: []
      # Array of runtime class names to exempt.
      runtimeClasses: []
      # Array of namespaces to exempt.
      namespaces: [kube-system]
 EOF
 ```
 For additional options, check out the official [_standards admission controller_](/docs/tasks/configure-pod-container/enforce-standards-admission-controller/#configure-the-admission-controller) docs.
 We now have a default baseline policy. Next pass it to the kind configuration to enable the `--admission-control-config-file` API server argument and pass the policy file. To pass a file to a kind cluster, use a configuration file to pass additional setup instructions. Kind uses `kubeadm` to provision the cluster and the configuration file has the ability to pass `kubeadmConfigPatches` for further customization. In our case, the local file is mounted into the control plane node as `/etc/kubernetes/policies/pod-security.yaml` which is then mounted into the `apiServer` container. We also pass the `--admission-control-config-file` argument pointing to the policy's location.
 ```shell
 cat <<EOF > kind-config.yaml
 kind: Cluster
 apiVersion: kind.x-k8s.io/v1alpha4
 nodes:
 - role: control-plane
  kubeadmConfigPatches:
  - |
    kind: ClusterConfiguration
    apiServer:
        # enable admission-control-config flag on the API server
        extraArgs:
          admission-control-config-file: /etc/kubernetes/policies/pod-security.yaml
        # mount new file / directories on the control plane
        extraVolumes:
          - name: policies
            hostPath: /etc/kubernetes/policies
            mountPath: /etc/kubernetes/policies
            readOnly: true
            pathType: "DirectoryOrCreate"
  # mount the local file on the control plane
  extraMounts:
  - hostPath: ./pod-security.yaml
    containerPath: /etc/kubernetes/policies/pod-security.yaml
    readOnly: true
 EOF
 ```
 Create a new cluster using the kind configuration file defined above.
 ```shell
 kind create cluster --image kindest/node:v1.23.0 --config kind-config.yaml
 ```
 Let's look at the default namespace.
 ```shell
 kubectl describe namespace default
 ```
 The output is similar to this:
 ```
 Name:         default
 Labels:       kubernetes.io/metadata.name=default
 Annotations:  <none>
 Status:       Active
 No resource quota.
 No LimitRange resource.
 ```
 Let's create a new namespace and see if the labels apply there.
 ```shell
 kubectl create namespace test-defaults
 kubectl describe namespace test-defaults
 ```
 Same.
 ```
 Name:         test-defaults
 Labels:       kubernetes.io/metadata.name=test-defaults
 Annotations:  <none>
 Status:       Active
 No resource quota.
 No LimitRange resource.
 ```
 Can a privileged workload be deployed?
 ```shell
 cat <<EOF | kubectl -n test-defaults apply -f -
 apiVersion: v1
 kind: Pod
 metadata:
  name: busybox-privileged
 spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000000"
    securityContext:
      allowPrivilegeEscalation: true
 EOF
 ```
 Hmm... yep. The default `warn` level is working at least.
 ```
 Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "busybox" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "busybox" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "busybox" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "busybox" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
 pod/busybox-privileged created
 ```
 Let's delete the pod with `kubectl -n test-defaults delete pod/busybox-privileged`.
 Is my config even working?
 ```shell
 # if using docker, shell into the control plane
 docker exec -it kind-control-plane bash
 # cat out the file we mounted
 cat /etc/kubernetes/policies/pod-security.yaml
 # check the api server logs
 cat /var/log/containers/kube-apiserver*.log 
 # check the api server config
 cat /etc/kubernetes/manifests/kube-apiserver.yaml 
 ```
 **UPDATE:** The baseline policy permits `allowPrivilegeEscalation`. While I cannot see the Pod Security default levels of enforcement, they are there. Let's try to provide a manifest that violates the baseline by requesting hostNetwork access.
 ```shell
 # delete the original pod
 kubectl -n test-defaults delete pod busybox-privileged
 cat <<EOF | kubectl -n test-defaults apply -f -
 apiVersion: v1
 kind: Pod
 metadata:
  name: busybox-privileged
 spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000000"
  hostNetwork: true
 EOF
 ```
 The output is similar to this:
 ```
 Error from server (Forbidden): error when creating "STDIN": pods "busybox-privileged" is forbidden: violates PodSecurity "baseline:latest": host namespaces (hostNetwork=true)
 ```
 #### Yes!!! It worked! 🎉🎉🎉 {#it-worked}
 I later found out, another way to check if things are operating as intended is to check the raw API server metrics endpoint.
 Run the following command:
 ```
 kubectl get --raw /metrics | grep pod_security_evaluations_total
 ```
 The output is similar to this:
 ```
 # HELP pod_security_evaluations_total [ALPHA] Number of policy evaluations that occurred, not counting ignored or exempt requests.
 # TYPE pod_security_evaluations_total counter
 pod_security_evaluations_total{decision="allow",mode="enforce",policy_level="baseline",policy_version="latest",request_operation="create",resource="pod",subresource=""} 2
 pod_security_evaluations_total{decision="allow",mode="enforce",policy_level="privileged",policy_version="latest",request_operation="create",resource="pod",subresource=""} 0
 pod_security_evaluations_total{decision="allow",mode="enforce",policy_level="privileged",policy_version="latest",request_operation="update",resource="pod",subresource=""} 0
 pod_security_evaluations_total{decision="deny",mode="audit",policy_level="baseline",policy_version="latest",request_operation="create",resource="pod",subresource=""} 1
 pod_security_evaluations_total{decision="deny",mode="enforce",policy_level="baseline",policy_version="latest",request_operation="create",resource="pod",subresource=""} 1
 pod_security_evaluations_total{decision="deny",mode="warn",policy_level="restricted",policy_version="latest",request_operation="create",resource="controller",subresource=""} 2
 pod_security_evaluations_total{decision="deny",mode="warn",policy_level="restricted",policy_version="latest",request_operation="create",resource="pod",subresource=""} 2
 ```
 A monitoring tool could ingest these metrics too for reporting, assessments, or measuring trends.
 ## Clean up
 When finished, delete the kind cluster.
 ```shell
 kind delete cluster
 ```
 ## Auditing
 Auditing is another way to track what policies are being enforced in your cluster. To set up auditing with kind, review the official docs for [enabling auditing](https://kind.sigs.k8s.io/docs/user/auditing/). As of [version 1.11](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.11.md#sig-auth), Kubernetes audit logs include two annotations that indicate whether or not a request was authorized (`authorization.k8s.io/decision`) and the reason for the decision (`authorization.k8s.io/reason`). Audit events can be streamed to a webhook for monitoring, tracking, or alerting.
 The audit events look similar to the following:
 ```yaml
 {"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":"","pod-security.kubernetes.io/audit":"allowPrivilegeEscalation != false (container \"busybox\" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container \"busybox\" must set securityContext.capabilities.drop=[\"ALL\"]), runAsNonRoot != true (pod or container \"busybox\" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container \"busybox\" must set securityContext.seccompProfile.type to \"RuntimeDefault\" or \"Localhost\")"}}
 ```
 Auditing is also a good first step in evaluating your cluster's current compliance with Pod Security. The Kubernetes Enhancement Proposal (KEP) hints at a future where `baseline` [could be the default for unlabeled namespaces](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/2579-psp-replacement/README.md#rollout-of-baseline-by-default-for-unlabeled-namespaces).
 Example `audit-policy.yaml` configuration tuned for Pod Security events:
 ```
 apiVersion: audit.k8s.io/v1
 kind: Policy
 rules:
 - level: RequestResponse
  resources:
    - group: "" # core API group
      resources: ["pods", "pods/ephemeralcontainers", "podtemplates", "replicationcontrollers"]
    - group: "apps"
      resources: ["daemonsets", "deployments", "replicasets", "statefulsets"]
    - group: "batch"
      resources: ["cronjobs", "jobs"]
  verbs: ["create", "update"]
  omitStages:
    - "RequestReceived"
    - "ResponseStarted"
    - "Panic"
 ```
 Once auditing is enabled, look at the configured local file if using `--audit-log-path` or the destination of a webhook if using `--audit-webhook-config-file`.
 If using a file (`--audit-log-path`), run `cat /PATH/TO/API/AUDIT.log | grep "is forbidden:"` to see all rejected workloads audited.
 ## PSP migrations
 If you're already using PSP, SIG Auth has created a guide and [published the steps to migrate off of PSP](/docs/tasks/configure-pod-container/migrate-from-psp/).
 To summarize the process:
 - Update all existing PSPs to be non-mutating
 - Apply Pod Security policies in `warn` or `audit` mode
 - Upgrade Pod Security policies to `enforce` mode
 - Remove `PodSecurityPolicy` from `--enable-admission-plugins`
 Listed as "optional future extensions" and currently out of scope, SIG Auth has kicked around the idea of providing a tool to assist with migrations. More [details in the KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/2579-psp-replacement/README.md#automated-psp-migration-tooling).
 ## Wrap up
 Pod Security is a promising new feature that provides an out-of-the-box way to allow users to improve the security posture of their workloads. Like any new enhancement that has matured to beta, we ask that you try it out, provide feedback, or share your experience via either raising a Github issue or joining SIG Auth community meetings. It's our hope that Pod Security will be deployed on every cluster in our ongoing pursuit as a community to make Kubernetes security a priority.
 For a step by step guide on how to enable "baseline" Pod Security Standards with Pod Security Admission feature please refer to these dedicated [tutorials](/docs/tutorials/security/) that cover the configuration needed at cluster level and namespace level.
 ## Additional resources
 - [Official Pod Security Docs](/docs/concepts/security/pod-security-admission/)
 - [Enforce Pod Security Standards with Namespace Labels](/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/)
 - [Enforce Pod Security Standards by Configuring the Built-in Admission Controller](/docs/tasks/configure-pod-container/enforce-standards-admission-controller/)
 - [Official Kubernetes Enhancement Proposal](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/2579-psp-replacement/README.md) (KEP)
 - [PodSecurityPolicy Deprecation: Past, Present, and Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)
 - [Hands on with Kubernetes Pod Security](https://medium.com/@LachlanEvenson/hands-on-with-kubernetes-pod-security-admission-b6cac495cd11)
@@ -0,0 +1,105 @@
 ---
 layout: blog
 title: "Using Admission Controllers to Detect Container Drift at Runtime"
 date: 2021-12-21
 slug: admission-controllers-for-container-drift
 ---
 **Author:** Saifuding Diliyaer (Box)
 {{< figure src="intro-illustration.png" alt="Introductory illustration" attr="Illustration by Munire Aireti" >}}
 At Box, we use Kubernetes (K8s) to manage hundreds of micro-services that enable Box to stream data at a petabyte scale. When it comes to the deployment process, we run [kube-applier](https://github.com/box/kube-applier) as part of the GitOps workflows with declarative configuration and automated deployment. Developers declare their K8s apps manifest into a Git repository that requires code reviews and automatic checks to pass, before any changes can get merged and applied inside our K8s clusters. With `kubectl exec` and other similar commands, however, developers are able to directly interact with running containers and alter them from their deployed state. This interaction could then subvert the change control and code review processes that are enforced in our CI/CD pipelines. Further, it allows such impacted containers to continue receiving traffic long-term in production.
 To solve this problem, we developed our own K8s component called [kube-exec-controller](https://github.com/box/kube-exec-controller) along with its corresponding [kubectl plugin](https://github.com/box/kube-exec-controller#kubectl-pi). They function together in detecting and terminating potentially mutated containers (caused by interactive kubectl commands), as well as revealing the interaction events directly to the target Pods for better visibility.
 ## Admission control for interactive kubectl commands
 Once a request is sent to K8s, it needs to be authenticated and authorized by the API server to proceed. Additionally, K8s has a separate layer of protection called [admission controllers](/docs/reference/access-authn-authz/admission-controllers/), which can intercept the request before an object is persisted in *etcd*. There are various predefined admission controls compiled into the API server binary (e.g. ResourceQuota to enforce hard resource usage limits per namespace). Besides, there are two dynamic admission controls named [MutatingAdmissionWebhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook) and [ValidatingAdmissionWebhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook), used for mutating or validating K8s requests respectively. The latter is what we adopted to detect container drift at runtime caused by interactive kubectl commands. This whole process can be divided into three steps as explained in detail below.
 ### 1. Admit interactive kubectl command requests
 First of all, we needed to enable a validating webhook that sends qualified requests to *kube-exec-controller*. To add the new validation mechanism applying to interactive kubectl commands specifically, we configured the webhook’s rules with resources as `[pods/exec, pods/attach]`, and operations as `CONNECT`. These rules tell the cluster's API server that all `exec` and `attach` requests should be subject to our admission control webhook. In the ValidatingAdmissionWebhook that we configured, we specified a `service` reference (could also be replaced with `url` that gives the location of the webhook) and `caBundle` to allow validating its X.509 certificate, both under the `clientConfig` stanza.
 Here is a short example of what our ValidatingWebhookConfiguration object looks like:
 ```yaml
 apiVersion: admissionregistration.k8s.io/v1
 kind: ValidatingWebhookConfiguration
 metadata:
  name: example-validating-webhook-config
 webhooks:
  - name: validate-pod-interaction.example.com
    sideEffects: None
    rules:
      - apiGroups: ["*"]
        apiVersions: ["*"]
        operations: ["CONNECT"]
        resources: ["pods/exec", "pods/attach"]
    failurePolicy: Fail
    clientConfig:
      service:
        # reference to kube-exec-controller service deployed inside the K8s cluster
        name: example-service
        namespace: kube-exec-controller
        path: "/admit-pod-interaction"
      caBundle: "{{VALUE}}" # PEM encoded CA bundle to validate kube-exec-controller's certificate
    admissionReviewVersions: ["v1", "v1beta1"]
 ```
 ### 2. Label the target Pod with potentially mutated containers
 Once a request of `kubectl exec` comes in, *kube-exec-controller* makes an internal note to label the associated Pod. The added labels mean that we can not only query all the affected Pods, but also enable the security mechanism to retrieve previously identified Pods, in case the controller service itself gets restarted.
 The admission control process cannot directly modify the targeted in its admission response. This is because the `pods/exec` request is against a subresource of the Pod API, and the API kind for that subresource is `PodExecOptions`. As a result, there is a separate process in *kube-exec-controller* that patches the labels asynchronously. The admission control always permits the `exec` request, then acts as a client of the K8s API to label the target Pod and to log related events. Developers can check whether their Pods are affected or not using `kubectl` or similar tools. For example:
 ```
 $ kubectl get pod --show-labels
 NAME      READY  STATUS   RESTARTS  AGE  LABELS
 test-pod  1/1    Running  0         2s   box.com/podInitialInteractionTimestamp=1632524400,box.com/podInteractorUsername=username-1,box.com/podTTLDuration=1h0m0s
 $ kubectl describe pod test-pod
 ...
 Events:
 Type       Reason            Age     From                            Message
 ----       ------            ----    ----                            -------
 Warning    PodInteraction    5s      admission-controller-service    Pod was interacted with 'kubectl exec' command by user 'username-1' initially at time 2021-09-24 16:00:00 -0800 PST
 Warning    PodInteraction    5s      admission-controller-service    Pod will be evicted at time 2021-09-24 17:00:00 -0800 PST (in about 1h0m0s).
 ```
 ### 3. Evict the target Pod after a predefined period
 As you can see in the above event messages, the affected Pod is not evicted immediately. At times, developers might have to get into their running containers necessarily for debugging some live issues. Therefore, we define a time to live (TTL) of affected Pods based on the environment of clusters they are running. In particular, we allow a longer time in our dev clusters as it is more common to run `kubectl exec` or other interactive commands for active development.
 For our production clusters, we specify a lower time limit so as to avoid the impacted Pods serving traffic abidingly. The *kube-exec-controller* internally sets and tracks a timer for each Pod that matches the associated TTL. Once the timer is up, the controller evicts that Pod using K8s API. The eviction (rather than deletion) is to ensure service availability, since the cluster respects any configured [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) (PDB). Let's say if a user has defined *x* number of Pods as critical in their PDB, the eviction (as requested by *kube-exec-controller*) does not continue when the target workload has fewer than *x* Pods running.
 Here comes a sequence diagram of the entire workflow mentioned above: 
 {{< figure src="workflow-diagram.svg" alt="Workflow Diagram" class="diagram-medium" >}}
 ## A new kubectl plugin for better user experience
 Our admission controller component works great for solving the container drift issue we had on the platform. It is also able to submit all related Events to the target Pod that has been affected. However, K8s clusters don't retain Events very long (the default retention period is one hour). We need to provide other ways for developers to get their Pod interaction activity. A [kubectl plugin](/docs/tasks/extend-kubectl/kubectl-plugins/) is a perfect choice for us to expose this information. We named our plugin `kubectl pi` (short for `pod-interaction`) and provide two subcommands: `get` and `extend`.
 When the `get` subcommand is called, the plugin checks the metadata attached by our admission controller and transfers it to human-readable information. Here is an example output from running `kubectl pi get`:
 ```
 $ kubectl pi get test-pod
 POD-NAME  INTERACTOR  POD-TTL  EXTENSION  EXTENSION-REQUESTER  EVICTION-TIME
 test-pod  username-1  1h0m0s   /          /                    2021-09-24 17:00:00 -0800 PST
 ```
 The plugin can also be used to extend the TTL for a Pod that is marked for future eviction. This is useful in case developers need extra time to debug ongoing issues. To achieve this, a developer uses the `kubectl pi extend` subcommand, where the plugin patches the relevant *annotations* for the given Pod. These *annotations* include the duration and username who made the extension request for transparency (displayed in the table returned from the `kubectl pi get` command).
 Correspondingly, there is another webhook defined in *kube-exec-controller* which admits valid annotation updates. Once admitted, those updates reset the eviction timer of the target Pod as requested. An example of requesting the extension from the developer side would be:
 ```
 $ kubectl pi extend test-pod --duration=30m
 Successfully extended the termination time of pod/test-pod with a duration=30m
 $ kubectl pi get test-pod
 POD-NAME  INTERACTOR  POD-TTL  EXTENSION  EXTENSION-REQUESTER  EVICTION-TIME
 test-pod  username-1  1h0m0s   30m        username-2           2021-09-24 17:30:00 -0800 PST
 ```
 ## Future improvement
 Although our admission controller service works great in handling interactive requests to a Pod, it could as well evict the Pod while the actual commands are no-op in these requests. For instance, developers sometimes run `kubectl exec` merely to check their service logs stored on hosts. Nevertheless, the target Pods would still get bounced despite the state of their containers not changing at all. One of the improvements here could be adding the ability to distinguish the commands that are passed to the interactive requests, so that no-op commands should not always force a Pod eviction. However, this becomes challenging when developers get a shell to a running container and execute commands inside the shell, since they will no longer be visible to our admission controller service.
 Another item worth pointing out here is the choice of using K8s *labels* and *annotations*. In our design, we decided to have all immutable metadata attached as *labels* for better enforcing the immutability in our admission control. Yet some of these metadata could fit better as *annotations*. For instance, we had a label with the key `box.com/podInitialInteractionTimestamp` used to list all affected Pods in *kube-exec-controller* code, although its value would be unlikely to query for. As a more ideal design in the K8s world, a single *label* could be preferable in our case for identification with other metadata applied as *annotations* instead.
 ## Summary
 With the power of admission controllers, we are able to secure our K8s clusters by detecting potentially mutated containers at runtime, and evicting their Pods without affecting service availability. We also utilize kubectl plugins to provide flexibility of the eviction time and hence, bringing a better and more self-independent experience to service owners. We are proud to announce that we have open-sourced the whole project for the community to leverage in their own K8s clusters. Any contribution is more than welcomed and appreciated. You can find this project hosted on GitHub at https://github.com/box/kube-exec-controller
 *Special thanks to Ayush Sobti and Ethan Goldblum for their technical guidance on this project.*
@@ -0,0 +1,51 @@
 ---
 title: Container Runtime Interface (CRI)
 content_type: concept
 weight: 50
 ---
 <!-- overview -->
 The CRI is a plugin interface which enables the kubelet to use a wide variety of
 container runtimes, without having a need to recompile the cluster components.
 You need a working
 {{<glossary_tooltip text="container runtime" term_id="container-runtime">}} on
 each Node in your cluster, so that the
 {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} can launch
 {{< glossary_tooltip text="Pods" term_id="pod" >}} and their containers.
 {{< glossary_definition term_id="container-runtime-interface" length="all" >}}
 <!-- body -->
 ## The API {#api}
 {{< feature-state for_k8s_version="v1.23" state="stable" >}}
 The kubelet acts as a client when connecting to the container runtime via gRPC.
 The runtime and image service endpoints have to be available in the container
 runtime, which can be configured separately within the kubelet by using the
 `--image-service-endpoint` and `--container-runtime-endpoint` [command line
 flags](/docs/reference/command-line-tools-reference/kubelet)
 For Kubernetes v{{< skew currentVersion >}}, the kubelet prefers to use CRI `v1`.
 If a container runtime does not support `v1` of the CRI, then the kubelet tries to
 negotiate any older supported version.
 The v{{< skew currentVersion >}} kubelet can also negotiate CRI `v1alpha2`, but
 this version is considered as deprecated.
 If the kubelet cannot negotiate a supported CRI version, the kubelet gives up
 and doesn't register as a node.
 ## Upgrading
 When upgrading Kubernetes, then the kubelet tries to automatically select the
 latest CRI version on restart of the component. If that fails, then the fallback
 will take place as mentioned above. If a gRPC re-dial was required because the
 container runtime has been upgraded, then the container runtime must also
 support the initially selected version or the redial is expected to fail. This
 requires a restart of the kubelet.
 ## {{% heading "whatsnext" %}}
 - Learn more about the CRI [protocol definition](https://github.com/kubernetes/cri-api/blob/c75ef5b/pkg/apis/runtime/v1/api.proto)
@@ -402,7 +402,7 @@ Graceful node shutdown is controlled with the `GracefulNodeShutdown`
 enabled by default in 1.21.
 Note that by default, both configuration options described below,
-`ShutdownGracePeriod` and `ShutdownGracePeriodCriticalPods` are set to zero,
+`shutdownGracePeriod` and `shutdownGracePeriodCriticalPods` are set to zero,
 thus not activating Graceful node shutdown functionality.
 To activate the feature, the two kubelet config settings should be configured appropriately and set to non-zero values.
@@ -412,32 +412,116 @@ During a graceful shutdown, kubelet terminates pods in two phases:
 2. Terminate [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) running on the node.
 Graceful node shutdown feature is configured with two [`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/) options:
-* `ShutdownGracePeriod`:
+* `shutdownGracePeriod`:
  * Specifies the total duration that the node should delay the shutdown by. This is the total grace period for pod termination for both regular and [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical).
-* `ShutdownGracePeriodCriticalPods`:
+* `shutdownGracePeriodCriticalPods`:
-  * Specifies the duration used to terminate [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) during a node shutdown. This value should be less than `ShutdownGracePeriod`.
+  * Specifies the duration used to terminate [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) during a node shutdown. This value should be less than `shutdownGracePeriod`.
-For example, if `ShutdownGracePeriod=30s`, and
+For example, if `shutdownGracePeriod=30s`, and
-`ShutdownGracePeriodCriticalPods=10s`, kubelet will delay the node shutdown by
+`shutdownGracePeriodCriticalPods=10s`, kubelet will delay the node shutdown by
 30 seconds. During the shutdown, the first 20 (30-10) seconds would be reserved
 for gracefully terminating normal pods, and the last 10 seconds would be
 reserved for terminating [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical).
 {{< note >}}
-When pods were evicted during the graceful node shutdown, they are marked as failed.
+When pods were evicted during the graceful node shutdown, they are marked as shutdown.
-Running `kubectl get pods` shows the status of the the evicted pods as `Shutdown`.
+Running `kubectl get pods` shows the status of the the evicted pods as `Terminated`.
 And `kubectl describe pod` indicates that the pod was evicted because of node shutdown:
 ```
-Status:         Failed
+Reason:         Terminated
-Reason:         Shutdown
+Message:        Pod was terminated in response to imminent node shutdown.
 Message:        Node is shutting, evicting pods
 ```
 Failed pod objects will be preserved until explicitly deleted or [cleaned up by the GC](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection).
 This is a change of behavior compared to abrupt node termination.
 {{< /note >}}
 ### Pod Priority based graceful node shutdown {#pod-priority-graceful-node-shutdown}
 {{< feature-state state="alpha" for_k8s_version="v1.23" >}}
 To provide more flexibility during graceful node shutdown around the ordering
 of pods during shutdown, graceful node shutdown honors the PriorityClass for
 Pods, provided that you enabled this feature in your cluster. The feature
 allows allows cluster administers to explicitly define the ordering of pods
 during graceful node shutdown based on [priority
 classes](docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass).
 The [Graceful Node Shutdown](#graceful-node-shutdown) feature, as described
 above, shuts down pods in two phases, non-critical pods, followed by critical
 pods. If additional flexibility is needed to explicitly define the ordering of
 pods during shutdown in a more granular way, pod priority based graceful
 shutdown can be used.
 When graceful node shutdown honors pod priorities, this makes it possible to do
 graceful node shutdown in multiple phases, each phase shutting down a
 particular priority class of pods. The kubelet can be configured with the exact
 phases and shutdown time per phase.
 Assuming the following custom pod [priority
 classes](docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass)
 in a cluster,
 |Pod priority class name|Pod priority class value|
 |-------------------------|------------------------|
 |`custom-class-a`         | 100000                 |
 |`custom-class-b`         | 10000                  |
 |`custom-class-c`         | 1000                   |
 |`regular/unset`          | 0                      |
 Within the [kubelet configuration](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)
 the settings for `shutdownGracePeriodByPodPriority` could look like:
 |Pod priority class value|Shutdown period|
 |------------------------|---------------|
 | 100000                 |10 seconds     |
 | 10000                  |180 seconds    |
 | 1000                   |120 seconds    |
 | 0                      |60 seconds     |
 The corresponding kubelet config YAML configuration would be:
 ```yaml
 shutdownGracePeriodByPodPriority:
  - priority: 100000
    shutdownGracePeriodSeconds: 10
  - priority: 10000
    shutdownGracePeriodSeconds: 180
  - priority: 1000
    shutdownGracePeriodSeconds: 120
  - priority: 0
    shutdownGracePeriodSeconds: 60
 ```
 The above table implies that any pod with priority value >= 100000 will get
 just 10 seconds to stop, any pod with value >= 10000 and < 100000 will get 180
 seconds to stop, any pod with value >= 1000 and < 10000 will get 120 seconds to stop.
 Finally, all other pods will get 60 seconds to stop.
 One doesn't have to specify values corresponding to all of the classes. For
 example, you could instead use these settings:
 |Pod priority class value|Shutdown period|
 |------------------------|---------------|
 | 100000                 |300 seconds    |
 | 1000                   |120 seconds    |
 | 0                      |60 seconds     |
 In the above case, the pods with custom-class-b will go into the same bucket
 as custom-class-c for shutdown.
 If there are no pods in a particular range, then the kubelet does not wait
 for pods in that priority range. Instead, the kubelet immediately skips to the
 next priority class value range.
 If this feature is enabled and no configuration is provided, then no ordering
 action will be taken.
 Using this feature, requires enabling the
 `GracefulNodeShutdownBasedOnPodPriority` feature gate, and setting the kubelet
 config's `ShutdownGracePeriodByPodPriority` to the desired configuration
 containing the pod priority class values and their respective shutdown periods.
 ## Swap memory management {#swap-memory}
 {{< feature-state state="alpha" for_k8s_version="v1.22" >}}
@@ -451,6 +535,11 @@ the kubelet, and the `--fail-swap-on` command line flag or `failSwapOn`
 [configuration setting](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)
 must be set to false.
 {{< warning >}}
 When the memory swap feature is turned on, Kubernetes data such as the content
 of Secret objects that were written to tmpfs now could be swapped to disk.
 {{< /warning >}}
 A user can also optionally configure `memorySwap.swapBehavior` in order to
 specify how a node will use swap memory. For example,
@@ -45,6 +45,11 @@ This page lists some of the available add-ons and links to their respective inst
 ## Infrastructure
 * [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation) is an add-on to run virtual machines on Kubernetes. Usually run on bare-metal clusters.
 * The
  [node problem detector](https://github.com/kubernetes/node-problem-detector)
  runs on Linux nodes and reports system issues as either
  [Events](/docs/reference/kubernetes-api/cluster-resources/event-v1/) or
  [Node conditions](/docs/concepts/architecture/nodes/#condition).
 ## Legacy Add-ons
@@ -26,6 +26,10 @@ fair queuing technique so that, for example, a poorly-behaved
 {{< glossary_tooltip text="controller" term_id="controller" >}} need not
 starve others (even at the same priority level).
 This feature is designed to work well with standard controllers, which
 use informers and react to failures of API requests with exponential
 back-off, and other clients that also work this way.
 {{< caution >}}
 Requests classified as "long-running" — primarily watches — are not
 subject to the API Priority and Fairness filter. This is also true for
@@ -102,6 +106,8 @@ name of the matching FlowSchema plus a _flow distinguisher_ — which
 is either the requesting user, the target resource's namespace, or nothing — and the
 system attempts to give approximately equal weight to requests in different
 flows of the same priority level.
 To enable distinct handling of distinct instances, controllers that have
 many instances should authenticate with distinct usernames
 After classifying a request into a flow, the API Priority and Fairness
 feature then may assign the request to a queue.  This assignment uses
@@ -64,7 +64,7 @@ This means that containers within a `Pod` can all reach each other's ports on
 usage, but this is no different from processes in a VM.  This is called the
 "IP-per-pod" model.
-How this is implemented is a detail of the particular container runtime in use.
+How this is implemented is a detail of the particular container runtime in use. Likewise, the networking option you choose may support [dual-stack IPv4/IPv6 networking](/docs/concepts/services-networking/dual-stack/); implementations vary.
 It is possible to request ports on the `Node` itself which forward to your `Pod`
 (called host ports), but this is a very niche operation. How that forwarding is
@@ -169,49 +169,6 @@ With this toolset DANM is able to provide multiple separated network interfaces,
 network that satisfies the Kubernetes requirements. Many
 people have reported success with Flannel and Kubernetes.
 ### Google Compute Engine (GCE)
 For the Google Compute Engine cluster configuration scripts, [advanced
 routing](https://cloud.google.com/vpc/docs/routes) is used to
 assign each VM a subnet (default is `/24` - 254 IPs).  Any traffic bound for that
 subnet will be routed directly to the VM by the GCE network fabric.  This is in
 addition to the "main" IP address assigned to the VM, which is NAT'ed for
 outbound internet access.  A linux bridge (called `cbr0`) is configured to exist
 on that subnet, and is passed to docker's `--bridge` flag.
 Docker is started with:
 ```shell
 DOCKER_OPTS="--bridge=cbr0 --iptables=false --ip-masq=false"
 ```
 This bridge is created by Kubelet (controlled by the `--network-plugin=kubenet`
 flag) according to the `Node`'s `.spec.podCIDR`.
 Docker will now allocate IPs from the `cbr-cidr` block.  Containers can reach
 each other and `Nodes` over the `cbr0` bridge.  Those IPs are all routable
 within the GCE project network.
 GCE itself does not know anything about these IPs, though, so it will not NAT
 them for outbound internet traffic.  To achieve that an iptables rule is used
 to masquerade (aka SNAT - to make it seem as if packets came from the `Node`
 itself) traffic that is bound for IPs outside the GCE project network
 (10.0.0.0/8).
 ```shell
 iptables -t nat -A POSTROUTING ! -d 10.0.0.0/8 -o eth0 -j MASQUERADE
 ```
 Lastly IP forwarding is enabled in the kernel (so the kernel will process
 packets for bridged containers):
 ```shell
 sysctl net.ipv4.ip_forward=1
 ```
 The result of all this is that all `Pods` can reach each other and can egress
 traffic to the internet.
 ### Jaguar
 [Jaguar](https://gitlab.com/sdnlab/jaguar) is an open source solution for Kubernetes's network based on OpenDaylight. Jaguar provides overlay network using vxlan and Jaguar CNIPlugin provides one IP address per pod.
@@ -268,10 +225,6 @@ stateful ACLs, load-balancers etc to build different virtual networking
 topologies.  The project has a specific Kubernetes plugin and documentation
 at [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes).
 ### Romana
 [Romana](https://romana.io) is an open source network and security automation solution that lets you deploy Kubernetes without an overlay network. Romana supports Kubernetes [Network Policy](/docs/concepts/services-networking/network-policies/) to provide isolation across network namespaces.
 ### Weave Net from Weaveworks
 [Weave Net](https://www.weave.works/products/weave-net/) is a
@@ -22,14 +22,62 @@ generates log messages for the Kubernetes system components.
 For more information about klog configuration, see the [Command line tool reference](/docs/reference/command-line-tools-reference/).
-An example of the klog native format:
+Kubernetes is in the process of simplifying logging in its components. The
 following klog command line flags [are
 deprecated](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components)
 starting with Kubernetes 1.23 and will be removed in a future release:
 - `--add-dir-header`
 - `--alsologtostderr`
 - `--log-backtrace-at`
 - `--log-dir`
 - `--log-file`
 - `--log-file-max-size`
 - `--logtostderr`
 - `--one-output`
 - `--skip-headers`
 - `--skip-log-headers`
 - `--stderrthreshold`
 Output will always be written to stderr, regardless of the output
 format. Output redirection is expected to be handled by the component which
 invokes a Kubernetes component. This can be a POSIX shell or a tool like
 systemd.
 In some cases, for example a distroless container or a Windows system service,
 those options are not available. Then the
 [`kube-log-runner`](https://github.com/kubernetes/kubernetes/blob/d2a8a81639fcff8d1221b900f66d28361a170654/staging/src/k8s.io/component-base/logs/kube-log-runner/README.md)
 binary can be used as wrapper around a Kubernetes component to redirect
 output. A prebuilt binary is included in several Kubernetes base images under
 its traditional name as `/go-runner` and as `kube-log-runner` in server and
 node release archives.
 This table shows how `kube-log-runner` invocations correspond to shell redirection:
 | Usage                                    | POSIX shell (such as bash) | `kube-log-runner <options> <cmd>`                           |
 | -----------------------------------------|----------------------------|-------------------------------------------------------------|
 | Merge stderr and stdout, write to stdout | `2>&1`                     | `kube-log-runner` (default behavior)                        |
 | Redirect both into log file              | `1>>/tmp/log 2>&1`         | `kube-log-runner -log-file=/tmp/log`                        |
 | Copy into log file and to stdout         | `2>&1 \| tee -a /tmp/log`  | `kube-log-runner -log-file=/tmp/log -also-stdout`           |
 | Redirect only stdout into log file       | `>/tmp/log`                | `kube-log-runner -log-file=/tmp/log -redirect-stderr=false` |
 ### Klog output
 An example of the traditional klog native format:
 ```
 I1025 00:15:15.525108       1 httplog.go:79] GET /api/v1/namespaces/kube-system/pods/metrics-server-v0.3.1-57c75779f-9p8wg: (1.512ms) 200 [pod_nanny/v0.0.0 (linux/amd64) kubernetes/$Format 10.56.1.19:51756]
 ```
 The message string may contain line breaks:
 ```
 I1025 00:15:15.525108       1 example.go:79] This is a message
 which has a line break.
 ```
 ### Structured Logging
-{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.23" state="beta" >}}
 {{< warning >}}
 Migration to structured log messages is an ongoing process. Not all log messages are structured in this version. When parsing log files, you must also handle unstructured log messages.
@@ -38,9 +86,11 @@ Log formatting and value serialization are subject to change.
 {{< /warning>}}
 Structured logging introduces a uniform structure in log messages allowing for programmatic extraction of information. You can store and process structured logs with less effort and cost.
-New message format is backward compatible and enabled by default.
+The code which generates a log message determines whether it uses the traditional unstructured klog output
 or structured logging.
-Format of structured logs:
+The default formatting of structured log messages is as text, with a format that
 is backward compatible with traditional klog:
 ```ini
 <klog header> "<message>" <key1>="<value1>" <key2>="<value2>" ...
@@ -52,6 +102,13 @@ Example:
 I1025 00:15:15.525108       1 controller_utils.go:116] "Pod status updated" pod="kube-system/kubedns" status="ready"
 ```
 Strings are quoted. Other values are formatted with
 [`%+v`](https://pkg.go.dev/fmt#hdr-Printing), which may cause log messages to
 continue on the next line [depending on the data](https://github.com/kubernetes/kubernetes/issues/106428).
 ```
 I1025 00:15:15.525108       1 example.go:116] "Example" data="This is text with a line break\nand \"quotation marks\"." someInt=1 someFloat=0.1 someStruct={StringField: First line,
 second line.}
 ```
 ### JSON log format
@@ -82,7 +139,7 @@ Example of JSON log format (pretty printed):
 Keys with special meaning:
 * `ts` - timestamp as Unix time (required, float)
-* `v` - verbosity (required, int, default 0)
+* `v` - verbosity (only for info and not for error messages, int)
 * `err` - error string (optional, string)
 * `msg` - message (required, string)
@@ -139,4 +196,5 @@ The `logrotate` tool rotates logs daily, or once the log size is greater than 10
 * Read about the [Kubernetes Logging Architecture](/docs/concepts/cluster-administration/logging/)
 * Read about [Structured Logging](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1602-structured-logging)
 * Read about [deprecation of klog flags](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components)
 * Read about the [Conventions for logging severity](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)
@@ -66,7 +66,7 @@ with `--tracing-config-file=<path-to-config>`. This is an example config that re
 spans for 1 in 10000 requests, and uses the default OpenTelemetry endpoint:
 ```yaml
-apiVersion: apiserver.config.k8s.io/v1alpha1
+apiVersion: apiserver.config.k8s.io/v1beta1
 kind: TracingConfiguration
 # default value
 #endpoint: localhost:4317
@@ -74,7 +74,7 @@ samplingRatePerMillion: 100
 ```
 For more information about the `TracingConfiguration` struct, see
-[API server config API (v1alpha1)](/docs/reference/config-api/apiserver-config.v1alpha1/#apiserver-k8s-io-v1alpha1-TracingConfiguration).
+[API server config API (v1beta1)](/docs/reference/config-api/apiserver-config.v1beta1/#apiserver-k8s-io-v1beta1-TracingConfiguration).
 ## Stability
@@ -116,11 +116,11 @@ CPU is always requested as an absolute quantity, never as a relative quantity;
 Limits and requests for `memory` are measured in bytes. You can express memory as
 a plain integer or as a fixed-point number using one of these suffixes:
-E, P, T, G, M, k. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi,
+E, P, T, G, M, k, m (millis). You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi,
 Mi, Ki. For example, the following represent roughly the same value:
 ```shell
-128974848, 129e6, 129M, 123Mi
+128974848, 129e6, 129M,  128974848000m, 123Mi
 ```
 Here's an example.
@@ -77,7 +77,7 @@ failure.
 In the webhook model, Kubernetes makes a network request to a remote service.
 In the *Binary Plugin* model, Kubernetes executes a binary (program).
 Binary plugins are used by the kubelet (e.g.
-[Flex Volume Plugins](/docs/concepts/storage/volumes/#flexVolume)
+[Flex Volume Plugins](/docs/concepts/storage/volumes/#flexvolume)
 and [Network Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/))
 and by kubectl.
@@ -163,6 +163,8 @@ After a request is authorized, if it is a write operation, it also goes through
 ) allow users to mount volume types without built-in support by having the
 Kubelet call a Binary Plugin to mount the volume.
 FlexVolume is deprecated since Kubernetes v1.23. The Out-of-tree CSI driver is the recommended way to write volume drivers in Kubernetes. See [Kubernetes Volume Plugin FAQ for Storage Vendors](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md#kubernetes-volume-plugin-faq-for-storage-vendors) for more information.
 ### Device Plugins
@@ -197,6 +197,8 @@ service PodResourcesLister {
 }
 ```
 ### `List` gRPC endpoint {#grpc-endpoint-list}
 The `List` endpoint provides information on resources of running pods, with details such as the
 id of exclusively allocated CPUs, device id as it was reported by device plugins and id of
 the NUMA node where these devices are allocated. Also, for NUMA-based machines, it contains the information about memory and hugepages reserved for a container.
@@ -246,10 +248,35 @@ message ContainerDevices {
    TopologyInfo topology = 3;
 }
 ```
 {{< note >}}
 cpu_ids in the `ContainerResources` in the `List` endpoint correspond to exclusive CPUs allocated
 to a partilar container. If the goal is to evaluate CPUs that belong to the shared pool, the `List`
 endpoint needs to be used in conjunction with the `GetAllocatableResources` endpoint as explained
 below:
 1. Call `GetAllocatableResources` to get a list of all the allocatable CPUs
 2. Call `GetCpuIds` on all `ContainerResources` in the system
 3. Subtract out all of the CPUs from the `GetCpuIds` calls from the `GetAllocatableResources` call
 {{< /note >}}
 ### `GetAllocatableResources` gRPC endpoint {#grpc-endpoint-getallocatableresources}
 {{< feature-state state="beta" for_k8s_version="v1.23" >}}
 GetAllocatableResources provides information on resources initially available on the worker node.
 It provides more information than kubelet exports to APIServer.
 {{< note >}}
 `GetAllocatableResources` should only be used to evaluate [allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)
 resources on a node. If the goal is to evaluate free/unallocated resources it should be used in
 conjunction with the List() endpoint. The result obtained by `GetAllocatableResources` would remain
 the same unless the underlying resources exposed to kubelet change. This happens rarely but when
 it does (for example: hotplug/hotunplug, device health changes), client is expected to call
 `GetAlloctableResources` endpoint.
 However, calling `GetAllocatableResources` endpoint is not sufficient in case of cpu and/or memory
 update and Kubelet needs to be restarted to reflect the correct resource capacity and allocatable.
 {{< /note >}}
 ```gRPC
 // AllocatableResourcesResponses contains informations about all the devices known by the kubelet
 message AllocatableResourcesResponse {
@@ -259,6 +286,13 @@ message AllocatableResourcesResponse {
 }
 ```
 Starting from Kubernetes v1.23, the `GetAllocatableResources` is enabled by default.
 You can disable it by turning off the
 `KubeletPodResourcesGetAllocatable` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/).
 Preceding Kubernetes v1.23, to enable this feature `kubelet` must be started with the following flag:
 `--feature-gates=KubeletPodResourcesGetAllocatable=true`
 `ContainerDevices` do expose the topology information declaring to which NUMA cells the device is affine.
 The NUMA cells are identified using a opaque integer ID, which value is consistent to what device
@@ -37,8 +37,11 @@ if you are writing an application using the Kubernetes API.
 Complete API details are documented using [OpenAPI](https://www.openapis.org/).
-The Kubernetes API server serves an OpenAPI spec via the `/openapi/v2` endpoint.
+### OpenAPI V2
-You can request the response format using request headers as follows:
+
 The Kubernetes API server serves an aggregated OpenAPI v2 spec via the
 `/openapi/v2` endpoint. You can request the response format using
 request headers as follows:
 <table>
  <caption style="display:none">Valid request header values for OpenAPI v2 queries</caption>
@@ -77,6 +80,55 @@ about this format, see the [Kubernetes Protobuf serialization](https://github.co
 Interface Definition Language (IDL) files for each schema located in the Go
 packages that define the API objects.
 ### OpenAPI V3
 {{< feature-state state="alpha"  for_k8s_version="v1.23" >}}
 Kubernetes v1.23 offers initial support for publishing its APIs as OpenAPI v3; this is an
 alpha feature that is disabled by default.
 You can enable the alpha feature by turning on the
 [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) named `OpenAPIV3`
 for the kube-apiserver component.
 With the feature enabled, the Kubernetes API server serves an
 aggregated OpenAPI v3 spec per Kubernetes group version at the
 `/openapi/v3/apis/<group>/<version>` endpoint. Please refer to the
 table below for accepted request headers.
 <table>
  <caption style="display:none">Valid request header values for OpenAPI v3 queries</caption>
  <thead>
     <tr>
        <th>Header</th>
        <th style="min-width: 50%;">Possible values</th>
        <th>Notes</th>
     </tr>
  </thead>
  <tbody>
     <tr>
        <td><code>Accept-Encoding</code></td>
        <td><code>gzip</code></td>
        <td><em>not supplying this header is also acceptable</em></td>
     </tr>
     <tr>
        <td rowspan="3"><code>Accept</code></td>
        <td><code>application/com.github.proto-openapi.spec.v3@v1.0+protobuf</code></td>
        <td><em>mainly for intra-cluster use</em></td>
     </tr>
     <tr>
        <td><code>application/json</code></td>
        <td><em>default</em></td>
     </tr>
     <tr>
        <td><code>*</code></td>
        <td><em>serves </em><code>application/json</code></td>
     </tr>
  </tbody>
 </table>
 A discovery endpoint `/openapi/v3` is provided to see a list of all
 group/versions available. This endpoint only returns JSON.
 ## Persistence
 Kubernetes stores the serialized state of objects by writing them into
@@ -85,7 +85,7 @@ of the scheduler:
 * Read about [scheduler performance tuning](/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)
 * Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
 * Read the [reference documentation](/docs/reference/command-line-tools-reference/kube-scheduler/) for kube-scheduler
-* Read the [kube-scheduler config (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) reference
+* Read the [kube-scheduler config (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/) reference
 * Learn about [configuring multiple schedulers](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)
 * Learn about [topology management policies](/docs/tasks/administer-cluster/topology-manager/)
 * Learn about [Pod Overhead](/docs/concepts/scheduling-eviction/pod-overhead/)
@@ -43,7 +43,7 @@ If you set `percentageOfNodesToScore` above 100, kube-scheduler acts as if you
 had set a value of 100.
 To change the value, edit the
-[kube-scheduler configuration file](/docs/reference/config-api/kube-scheduler-config.v1beta2/)
+[kube-scheduler configuration file](/docs/reference/config-api/kube-scheduler-config.v1beta3/)
 and then restart the scheduler.
 In many cases, the configuration file can be found at `/etc/kubernetes/config/kube-scheduler.yaml`.
@@ -161,5 +161,5 @@ After going over all the Nodes, it goes back to Node 1.
 ## {{% heading "whatsnext" %}}
-* Check the [kube-scheduler configuration reference (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/)
+* Check the [kube-scheduler configuration reference (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/)
@@ -13,13 +13,13 @@ min-kubernetes-server-version: v1.22
 <!-- overview -->
-{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.23" state="beta" >}}
 The Kubernetes [Pod Security Standards](/docs/concepts/security/pod-security-standards/) define
 different isolation levels for Pods. These standards let you define how you want to restrict the
 behavior of pods in a clear, consistent fashion.
-As an Alpha feature, Kubernetes offers a built-in _Pod Security_ {{< glossary_tooltip
+As an Beta feature, Kubernetes offers a built-in _Pod Security_ {{< glossary_tooltip
 text="admission controller" term_id="admission-controller" >}}, the successor
 to [PodSecurityPolicies](/docs/concepts/policy/pod-security-policy/). Pod security restrictions
 are applied at the {{< glossary_tooltip text="namespace" term_id="namespace" >}} level when pods
@@ -32,15 +32,40 @@ The PodSecurityPolicy API is deprecated and will be
 <!-- body -->
-## Enabling the Alpha feature
+## Enabling the `PodSecurity` admission plugin
-Setting pod security controls by namespace is an alpha feature. You must enable the `PodSecurity`
+In v1.23, the `PodSecurity` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
-[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) in order to use it.
+is a Beta feature and is enabled by default.
 In v1.22, the `PodSecurity` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
 is an Alpha feature and must be enabled in `kube-apiserver` in order to use the built-in admission plugin.
 ```shell
 --feature-gates="...,PodSecurity=true"
 ```
 ## Alternative: installing the `PodSecurity` admission webhook {#webhook}
 For environments where the built-in `PodSecurity` admission plugin cannot be used,
 either because the cluster is older than v1.22, or the `PodSecurity` feature cannot be enabled,
 the `PodSecurity` admission logic is also available as a Beta [validating admission webhook](https://git.k8s.io/pod-security-admission/webhook).
 A pre-built container image, certificate generation scripts, and example manifests
 are available at [https://git.k8s.io/pod-security-admission/webhook](https://git.k8s.io/pod-security-admission/webhook).
 To install:
 ```shell
 git clone git@github.com:kubernetes/pod-security-admission.git
 cd pod-security-admission/webhook
 make certs
 kubectl apply -k .
 ```
 {{< note >}}
 The generated certificate is valid for 2 years. Before it expires,
 regenerate the certificate or remove the webhook in favor of the built-in admission plugin.
 {{< /note >}}
 ## Pod Security levels
 Pod Security admission places requirements on a Pod's [Security
@@ -52,7 +77,7 @@ page for an in-depth look at those requirements.
 ## Pod Security Admission labels for namespaces
-Provided that you have enabled this feature, you can configure namespaces to define the admission
+Once the feature is enabled or the webhook is installed, you can configure namespaces to define the admission
 control mode you want to use for pod security in each namespace. Kubernetes defines a set of 
 {{< glossary_tooltip term_id="label" text="labels" >}} that you can set to define which of the 
 predefined Pod Security Standard levels you want to use for a namespace. The label you select
@@ -373,6 +373,24 @@ fail validation.
 				</small>
 			</td>
 		</tr>
 		<tr>
 			<td style="white-space: nowrap">Running as Non-root user (v1.23+)</td>
 			<td>
 				<p>Containers must not set <tt>runAsUser</tt> to 0</p>
 				<p><strong>Restricted Fields</strong></p>
 				<ul>
 					<li><code>spec.securityContext.runAsUser</code></li>
 					<li><code>spec.containers[*].securityContext.runAsUser</code></li>
 					<li><code>spec.initContainers[*].securityContext.runAsUser</code></li>
 					<li><code>spec.ephemeralContainers[*].securityContext.runAsUser</code></li>
 				</ul>
 				<p><strong>Allowed Values</strong></p>
 				<ul>
 					<li>any non-zero value</li>
 					<li><code>undefined/null</code></li>
 				</ul>
 			</td>
 		</tr>
 		<tr>
 			<td style="white-space: nowrap">Non-root groups <em>(optional)</em></td>
 			<td>
@@ -16,7 +16,7 @@ weight: 70
 <!-- overview -->
-{{< feature-state for_k8s_version="v1.21" state="beta" >}}
+{{< feature-state for_k8s_version="v1.23" state="stable" >}}
 IPv4/IPv6 dual-stack networking enables the allocation of both IPv4 and IPv6 addresses to {{< glossary_tooltip text="Pods" term_id="pod" >}} and {{< glossary_tooltip text="Services" term_id="service" >}}.
@@ -47,8 +47,6 @@ The following prerequisites are needed in order to utilize IPv4/IPv6 dual-stack
 ## Configure IPv4/IPv6 dual-stack
 To use IPv4/IPv6 dual-stack, ensure the `IPv6DualStack` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled for the relevant components of your cluster. (Starting in 1.21, IPv4/IPv6 dual-stack defaults to enabled.)
 To configure IPv4/IPv6 dual-stack, set dual-stack cluster network assignments:
   * kube-apiserver:
@@ -65,9 +63,6 @@ An example of an IPv4 CIDR: `10.244.0.0/16` (though you would supply your own ad
 An example of an IPv6 CIDR: `fdXY:IJKL:MNOP:15::/64` (this shows the format but is not a valid address - see [RFC 4193](https://tools.ietf.org/html/rfc4193))
 Starting in 1.21, IPv4/IPv6 dual-stack defaults to enabled.
 You can disable it when necessary by specifying `--feature-gates="IPv6DualStack=false"`
 on the kube-apiserver, kube-controller-manager, kubelet, and kube-proxy command line.
 {{< /note >}}
 ## Services
@@ -81,7 +76,7 @@ set the `.spec.ipFamilyPolicy` field to one of the following values:
 * `SingleStack`: Single-stack service. The control plane allocates a cluster IP for the Service, using the first configured service cluster IP range.
 * `PreferDualStack`:
-  * Allocates IPv4 and IPv6 cluster IPs for the Service. (If the cluster has `--feature-gates="IPv6DualStack=false"`, this setting follows the same behavior as `SingleStack`.)
+  * Allocates IPv4 and IPv6 cluster IPs for the Service.
 * `RequireDualStack`: Allocates Service `.spec.ClusterIPs` from both IPv4 and IPv6 address ranges.
  * Selects the `.spec.ClusterIP` from the list of `.spec.ClusterIPs` based on the address family of the first element in the `.spec.ipFamilies` array.
@@ -124,7 +119,7 @@ These examples demonstrate the behavior of various dual-stack Service configurat
 #### Dual-stack defaults on existing Services
-These examples demonstrate the default behavior when dual-stack is newly enabled on a cluster where Services already exist. (Upgrading an existing cluster to 1.21 will enable dual-stack unless `--feature-gates="IPv6DualStack=false"` is set.)
+These examples demonstrate the default behavior when dual-stack is newly enabled on a cluster where Services already exist. (Upgrading an existing cluster to 1.21 or beyond will enable dual-stack.)
 1. When dual-stack is enabled on a cluster, existing Services (whether `IPv4` or `IPv6`) are configured by the control plane to set `.spec.ipFamilyPolicy` to `SingleStack` and set `.spec.ipFamilies` to the address family of the existing Service. The existing Service cluster IP will be stored in `.spec.ClusterIPs`.
@@ -57,12 +57,11 @@ Kubernetes as a project supports and maintains [AWS](https://github.com/kubernet
 ## Using multiple Ingress controllers
-You may deploy [any number of ingress controllers](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers) 
+You may deploy any number of ingress controllers using [ingress class](/docs/concepts/services-networking/ingress/#ingress-class)
-within a cluster. When you create an ingress, you should annotate each ingress with the appropriate
+within a cluster. Note the `.metadata.name` of your ingress class resource. When you create an ingress you would need that name to specify the `ingressClassName` field on your Ingress object (refer to [IngressSpec v1 reference](/docs/reference/kubernetes-api/service-resources/ingress-v1/#IngressSpec). `ingressClassName` is a replacement of the older [annotation method](/docs/concepts/services-networking/ingress/#deprecated-annotation).
 [`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster) 
 to indicate which ingress controller should be used if more than one exists within your cluster.
-If you do not define a class, your cloud provider may use a default ingress controller.
+If you do not specify an IngressClass for an Ingress, and your cluster has exactly one IngressClass marked as default, then Kubernetes [applies](/docs/concepts/services-networking/ingress/#default-ingress-class) the cluster's default IngressClass to the Ingress.
 You mark an IngressClass as default by setting the [`ingressclass.kubernetes.io/is-default-class` annotation](/docs/reference/labels-annotations-taints/#ingressclass-kubernetes-io-is-default-class) on that IngressClass, with the string value `"true"`.
 Ideally, all ingress controllers should fulfill this specification, but the various ingress
 controllers operate slightly differently.
@@ -219,25 +219,98 @@ of the controller that should implement the class.
 {{< codenew file="service/networking/external-lb.yaml" >}}
-IngressClass resources contain an optional parameters field. This can be used to
+The `.spec.parameters` field of an IngressClass lets you reference another
-reference additional implementation-specific configuration for this class.
+resource that provides configuration related to that IngressClass.
-#### Namespace-scoped parameters
+The specific type of parameters to use depends on the ingress controller
 that you specify in the `.spec.controller` field of the IngressClass.
-{{< feature-state for_k8s_version="v1.22" state="beta" >}}
+### IngressClass scope
-`Parameters` field has a `scope` and `namespace` field that can be used to
+Depending on your ingress controller, you may be able to use parameters
-reference a namespace-specific resource for configuration of an Ingress class.
+that you set cluster-wide, or just for one namespace.
 `Scope` field defaults to `Cluster`, meaning, the default is cluster-scoped
 resource. Setting `Scope` to `Namespace` and setting the `Namespace` field
 will reference a parameters resource in a specific namespace:
-Namespace-scoped parameters avoid the need for a cluster-scoped CustomResourceDefinition
+{{< tabs name="tabs_ingressclass_parameter_scope" >}}
-for a parameters resource. This further avoids RBAC-related resources
+{{% tab name="Cluster" %}}
-that would otherwise be required to grant permissions to cluster-scoped
+The default scope for IngressClass parameters is cluster-wide.
 resources.
-{{< codenew file="service/networking/namespaced-params.yaml" >}}
+If you set the `.spec.parameters` field and don't set
 `.spec.parameters.scope`, or if you set `.spec.parameters.scope` to
 `Cluster`, then the IngressClass refers to a cluster-scoped resource.
 The `kind` (in combination the `apiGroup`) of the parameters
 refers to a cluster-scoped API (possibly a custom resource), and
 the `name` of the parameters identifies a specific cluster scoped
 resource for that API.
 For example:
 ```yaml
 ---
 apiVersion: networking.k8s.io/v1
 kind: IngressClass
 metadata:
  name: external-lb-1
 spec:
  controller: example.com/ingress-controller
  parameters:
    # The parameters for this IngressClass are specified in a
    # ClusterIngressParameter (API group k8s.example.net) named
    # "external-config-1". This definition tells Kubernetes to
    # look for a cluster-scoped parameter resource.
    scope: Cluster
    apiGroup: k8s.example.net
    kind: ClusterIngressParameter
    name: external-config-1
 ```
 {{% /tab %}}
 {{% tab name="Namespaced" %}}
 {{< feature-state for_k8s_version="v1.23" state="stable" >}}
 If you set the `.spec.parameters` field and set
 `.spec.parameters.scope` to `Namespace`, then the IngressClass refers
 to a namespaced-scoped resource. You must also set the `namespace`
 field within `.spec.parameters` to the namespace that contains
 the parameters you want to use.
 The `kind` (in combination the `apiGroup`) of the parameters
 refers to a namespaced API (for example: ConfigMap), and
 the `name` of the parameters identifies a specific resource
 in the namespace you specified in `namespace`.
 Namespace-scoped parameters help the cluster operator delegate control over the
 configuration (for example: load balancer settings, API gateway definition)
 that is used for a workload. If you used a cluster-scoped parameter then either:
 - the cluster operator team needs to approve a different team's changes every
  time there's a new configuration change being applied.
 - the cluster operator must define specific access controls, such as
  [RBAC](/docs/reference/access-authn-authz/rbac/) roles and bindings, that let
  the application team make changes to the cluster-scoped parameters resource.
 The IngressClass API itself is always cluster-scoped.
 Here is an example of an IngressClass that refers to parameters that are
 namespaced:
 ```yaml
 ---
 apiVersion: networking.k8s.io/v1
 kind: IngressClass
 metadata:
  name: external-lb-2
 spec:
  controller: example.com/ingress-controller
  parameters:
    # The parameters for this IngressClass are specified in an
    # IngressParameter (API group k8s.example.com) named "external-config",
    # that's in the "external-configuration" configuration namespace.
    scope: Namespace
    apiGroup: k8s.example.com
    kind: IngressParameter
    namespace: external-configuration
    name: external-config
 ```
 {{% /tab %}}
 {{< /tabs >}}
 ### Deprecated annotation
@@ -570,6 +643,6 @@ You can expose a Service in multiple ways that don't directly involve the Ingres
 ## {{% heading "whatsnext" %}}
-* Learn about the [Ingress API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)
+* Learn about the [Ingress](/docs/reference/kubernetes-api/service-resources/ingress-v1/) API
 * Learn about [Ingress controllers](/docs/concepts/services-networking/ingress-controllers/)
 * [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube/)
@@ -68,6 +68,6 @@ When the [feature gate](/docs/reference/command-line-tools-reference/feature-gat
 ## {{% heading "whatsnext" %}}
-* Read about [enabling Topology Aware Hints](/docs/tasks/administer-cluster/enabling-topology-aware-hints)
+* Read about [Topology Aware Hints](/docs/concepts/services-networking/topology-aware-hints)
 * Read about [Service External Traffic Policy](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)
 * Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)
@@ -9,7 +9,7 @@ weight: 45
 <!-- overview -->
-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.23" state="beta" >}}
 _Topology Aware Hints_ enable topology aware routing by including suggestions
 for how clients should consume endpoints. This approach adds metadata to enable
@@ -35,8 +35,7 @@ can then consume those hints, and use them to influence how traffic to is routed
 ## Using Topology Aware Hints
-If you have [enabled](/docs/tasks/administer-cluster/enabling-topology-aware-hints) the
+You can activate Topology Aware Hints for a Service by setting the
 overall feature, you can activate Topology Aware Hints for a Service by setting the
 `service.kubernetes.io/topology-aware-hints` annotation to `auto`. This tells
 the EndpointSlice controller to set topology hints if it is deemed safe.
 Importantly, this does not guarantee that hints will always be set.
@@ -156,5 +155,4 @@ zone.
 ## {{% heading "whatsnext" %}}
 * Read about [enabling Topology Aware Hints](/docs/tasks/administer-cluster/enabling-topology-aware-hints/)
 * Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)
@@ -7,7 +7,7 @@ reviewers:
 - pohly
 title: Ephemeral Volumes
 content_type: concept
-weight: 50
+weight: 30
 ---
 <!-- overview -->
@@ -130,10 +130,7 @@ As a cluster administrator, you can use a [PodSecurityPolicy](/docs/concepts/pol
 ### Generic ephemeral volumes
-{{< feature-state for_k8s_version="v1.21" state="beta" >}}
+{{< feature-state for_k8s_version="v1.23" state="stable" >}}
 This feature requires the `GenericEphemeralVolume` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) to be
 enabled. Because this is a beta feature, it is enabled by default.
 Generic ephemeral volumes are similar to `emptyDir` volumes in the
 sense that they provide a per-pod directory for scratch data that is
@@ -245,7 +242,6 @@ PVCs indirectly if they can create Pods, even if they do not have
 permission to create PVCs directly. Cluster administrators must be
 aware of this. If this does not fit their security model, they have
 two choices:
 - Explicitly disable the feature through the feature gate.
 - Use a [Pod Security
  Policy](/docs/concepts/policy/pod-security-policy/) where the
  `volumes` list does not contain the `ephemeral` volume type
@@ -274,4 +270,3 @@ See [local ephemeral storage](/docs/concepts/configuration/manage-resources-cont
 - For more information on the design, see the
 [Generic ephemeral inline volumes KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1698-generic-ephemeral-volumes/README.md).
 - For more information on further development of this feature, see the [enhancement tracking issue #1698](https://github.com/kubernetes/enhancements/issues/1698).
@@ -10,14 +10,13 @@ feature:
  title: Storage orchestration
  description: >
    Automatically mount the storage system of your choice, whether from local storage, a public cloud provider such as <a href="https://cloud.google.com/storage/">GCP</a> or <a href="https://aws.amazon.com/products/storage/">AWS</a>, or a network storage system such as NFS, iSCSI, Gluster, Ceph, Cinder, or Flocker.
 content_type: concept
 weight: 20
 ---
 <!-- overview -->
-This document describes the current state of _persistent volumes_ in Kubernetes. Familiarity with [volumes](/docs/concepts/storage/volumes/) is suggested.
+This document describes _persistent volumes_ in Kubernetes. Familiarity with [volumes](/docs/concepts/storage/volumes/) is suggested.
 <!-- body -->
@@ -221,19 +220,19 @@ to `Retain`, including cases where you are reusing an existing PV.
 {{< feature-state for_k8s_version="v1.11" state="beta" >}}
-Support for expanding PersistentVolumeClaims (PVCs) is now enabled by default. You can expand
+Support for expanding PersistentVolumeClaims (PVCs) is enabled by default. You can expand
 the following types of volumes:
-* gcePersistentDisk
+* azureDisk
 * azureFile
 * awsElasticBlockStore
-* Cinder
+* cinder (deprecated)
 * {{< glossary_tooltip text="csi" term_id="csi" >}}
 * flexVolume (deprecated)
 * gcePersistentDisk
 * glusterfs
 * rbd
-* Azure File
+* portworxVolume
 * Azure Disk
 * Portworx
 * FlexVolumes
 * {{< glossary_tooltip text="CSI" term_id="csi" >}}
 You can only expand a PVC if its storage class's `allowVolumeExpansion` field is set to true.
@@ -270,8 +269,8 @@ When a volume contains a file system, the file system is only resized when a new
 the PersistentVolumeClaim in `ReadWrite` mode. File system expansion is either done when a Pod is starting up
 or when a Pod is running and the underlying file system supports online expansion.
-FlexVolumes allow resize if the driver is set with the `RequiresFSResize` capability to `true`.
+FlexVolumes (deprecated since Kubernetes v1.23) allow resize if the driver is configured with the
-The FlexVolume can be resized on Pod restart.
+`RequiresFSResize` capability to `true`. The FlexVolume can be resized on Pod restart.
 #### Resizing an in-use PersistentVolumeClaim
@@ -299,6 +298,11 @@ Expanding EBS volumes is a time-consuming operation. Also, there is a per-volume
 #### Recovering from Failure when Expanding Volumes
 If a user specifies a new size that is too big to be satisfied by underlying storage system, expansion of PVC will be continuously retried until user or cluster administrator takes some action. This can be undesirable and hence Kubernetes provides following methods of recovering from such failures.
 {{< tabs name="recovery_methods" >}}
 {{% tab name="Manually with Cluster Administrator access" %}}
 If expanding underlying storage fails, the cluster administrator can manually recover the Persistent Volume Claim (PVC) state and cancel the resize requests. Otherwise, the resize requests are continuously retried by the controller without administrator intervention.
 1. Mark the PersistentVolume(PV) that is bound to the PersistentVolumeClaim(PVC) with `Retain` reclaim policy.
@@ -307,6 +311,30 @@ If expanding underlying storage fails, the cluster administrator can manually re
 4. Re-create the PVC with smaller size than PV and set `volumeName` field of the PVC to the name of the PV. This should bind new PVC to existing PV.
 5. Don't forget to restore the reclaim policy of the PV.
 {{% /tab %}}
 {{% tab name="By requesting expansion to smaller size" %}}
 {{% feature-state for_k8s_version="v1.23" state="alpha" %}}
 {{< note >}}
 Recovery from failing PVC expansion by users is available as an alpha feature since Kubernetes 1.23. The `RecoverVolumeExpansionFailure` feature must be enabled for this feature to work. Refer to the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) documentation for more information.
 {{< /note >}}
 If the feature gates `ExpandPersistentVolumes` and `RecoverVolumeExpansionFailure` are both
 enabled in your cluster, and expansion has failed for a PVC, you can retry expansion with a
 smaller size than the previously requested value. To request a new expansion attempt with a
 smaller proposed size, edit `.spec.resources` for that PVC and choose a value that is less than the
 value you previously tried.
 This is useful if expansion to a higher value did not succeed because of capacity constraint.
 If that has happened, or you suspect that it might have, you can retry expansion by specifying a
 size that is within the capacity limits of underlying storage provider. You can monitor status of resize operation by watching `.status.resizeStatus` and events on the PVC.
 Note that,
 although you can a specify a lower amount of storage than what was requested previously,
 the new value must still be higher than `.status.capacity`.
 Kubernetes does not support shrinking a PVC to less than its current size.
 {{% /tab %}}
 {{% /tabs %}}
 ## Types of Persistent Volumes
@@ -318,7 +346,6 @@ PersistentVolume types are implemented as plugins. Kubernetes currently supports
 * [`cephfs`](/docs/concepts/storage/volumes/#cephfs) - CephFS volume
 * [`csi`](/docs/concepts/storage/volumes/#csi) - Container Storage Interface (CSI)
 * [`fc`](/docs/concepts/storage/volumes/#fc) - Fibre Channel (FC) storage
 * [`flexVolume`](/docs/concepts/storage/volumes/#flexVolume) - FlexVolume
 * [`gcePersistentDisk`](/docs/concepts/storage/volumes/#gcepersistentdisk) - GCE Persistent Disk
 * [`glusterfs`](/docs/concepts/storage/volumes/#glusterfs) - Glusterfs volume
 * [`hostPath`](/docs/concepts/storage/volumes/#hostpath) - HostPath volume
@@ -336,6 +363,8 @@ The following types of PersistentVolume are deprecated. This means that support
 * [`cinder`](/docs/concepts/storage/volumes/#cinder) - Cinder (OpenStack block storage)
  (**deprecated** in v1.18)
 * [`flexVolume`](/docs/concepts/storage/volumes/#flexvolume) - FlexVolume
  (**deprecated** in v1.23)
 * [`flocker`](/docs/concepts/storage/volumes/#flocker) - Flocker storage
  (**deprecated** in v1.22)
 * [`quobyte`](/docs/concepts/storage/volumes/#quobyte) - Quobyte volume
@@ -1,16 +1,16 @@
 ---
 reviewers:
 - sftim
 - marosset
 - jsturtevant
 - zshihang
 title: Projected Volumes
 content_type: concept
 weight: 21 # just after persistent volumes
 ---
 <!-- overview -->
-This document describes the current state of _projected volumes_ in Kubernetes. Familiarity with [volumes](/docs/concepts/storage/volumes/) is suggested.
+This document describes _projected volumes_ in Kubernetes. Familiarity with [volumes](/docs/concepts/storage/volumes/) is suggested.
 <!-- body -->
@@ -7,7 +7,7 @@ reviewers:
 - pohly
 title: Storage Capacity
 content_type: concept
-weight: 45
+weight: 70
 ---
 <!-- overview -->
@@ -16,7 +16,6 @@ Storage capacity is limited and may vary depending on the node on
 which a pod runs: network-attached storage might not be accessible by
 all nodes, or storage is local to a node to begin with.
 {{< feature-state for_k8s_version="v1.19" state="alpha" >}}
 {{< feature-state for_k8s_version="v1.21" state="beta" >}}
 This page describes how Kubernetes keeps track of storage capacity and
@@ -6,7 +6,7 @@ reviewers:
 - msau42
 title: CSI Volume Cloning
 content_type: concept
-weight: 30
+weight: 60
 ---
 <!-- overview -->
@@ -8,7 +8,7 @@ reviewers:
 - yuxiangqian
 title: Volume Snapshot Classes
 content_type: concept
-weight: 30
+weight: 41 # just after volume snapshots
 ---
 <!-- overview -->
@@ -8,7 +8,7 @@ reviewers:
 - yuxiangqian
 title: Volume Snapshots
 content_type: concept
-weight: 20
+weight: 40
 ---
 <!-- overview -->
@@ -830,11 +830,11 @@ GitHub project has [instructions](https://github.com/quobyte/quobyte-csi#quobyte
 ### rbd
 An `rbd` volume allows a
-[Rados Block Device](https://docs.ceph.com/en/latest/rbd/) (RBD) volume to mount into your
+[Rados Block Device](https://docs.ceph.com/en/latest/rbd/) (RBD) volume to mount
-Pod. Unlike `emptyDir`, which is erased when a pod is removed, the contents of
+into your Pod. Unlike `emptyDir`, which is erased when a pod is removed, the
-an `rbd` volume are preserved and the volume is unmounted. This
+contents of an `rbd` volume are preserved and the volume is unmounted. This
-means that a RBD volume can be pre-populated with data, and that data can
+means that a RBD volume can be pre-populated with data, and that data can be
-be shared between pods.
+shared between pods.
 {{< note >}}
 You must have a Ceph installation running before you can use RBD.
@@ -849,6 +849,38 @@ Simultaneous writers are not allowed.
 See the [RBD example](https://github.com/kubernetes/examples/tree/master/volumes/rbd)
 for more details.
 #### RBD CSI migration {#rbd-csi-migration}
 {{< feature-state for_k8s_version="v1.23" state="alpha" >}}
 The `CSIMigration` feature for `RBD`, when enabled, redirects all plugin
 operations from the existing in-tree plugin to the `rbd.csi.ceph.com` {{<
 glossary_tooltip text="CSI" term_id="csi" >}} driver. In order to use this
 feature, the
 [Ceph CSI driver](https://github.com/ceph/ceph-csi)
 must be installed on the cluster and the `CSIMigration` and `CSIMigrationRBD`
 [feature gates](/docs/reference/command-line-tools-reference/feature-gates/)
 must be enabled.
 {{< note >}}
 As a Kubernetes cluster operator that administers storage, here are the
 prerequisites that you must complete before you attempt migration to the
 RBD CSI driver:
 * You must install the Ceph CSI driver (`rbd.csi.ceph.com`), v3.5.0 or above,
  into your Kubernetes cluster.
 * considering the `clusterID` field is a required parameter for CSI driver for
  its operations, but in-tree StorageClass has `monitors` field as a required
  parameter, a Kubernetes storage admin has to create a clusterID based on the
  monitors hash ( ex:`#echo -n
  '<monitors_string>' | md5sum`) in the CSI config map and keep the monitors
  under this clusterID configuration.
 * Also, if the value of `adminId` in the in-tree Storageclass is different from
 `admin`, the `adminSecretName` mentioned in the in-tree Storageclass has to be
  patched with the base64 value of the `adminId` parameter value, otherwise this
  step can be skipped. {{< /note >}}
 ### secret
 A `secret` volume is used to pass sensitive information, such as passwords, to
@@ -1018,6 +1050,16 @@ but new volumes created by the vSphere CSI driver will not be honoring these par
 To turn off the `vsphereVolume` plugin from being loaded by the controller manager and the kubelet, you need to set `InTreePluginvSphereUnregister` feature flag to `true`. You must install a `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} driver on all worker nodes.
 #### Portworx CSI migration
 {{< feature-state for_k8s_version="v1.23" state="alpha" >}}
 The `CSIMigration` feature for Portworx has been added but disabled by default in Kubernetes 1.23 since it's in alpha state.
 It redirects all plugin operations from the existing in-tree plugin to the
 `pxd.portworx.com` Container Storage Interface (CSI) Driver.
 [Portworx CSI Driver](https://docs.portworx.com/portworx-install-with-kubernetes/storage-operations/csi/)
 must be installed on the cluster.
 To enable the feature, set `CSIMigrationPortworx=true` in kube-controller-manager and kubelet.
 ## Using subPath {#using-subpath}
 Sometimes, it is useful to share one volume for multiple uses in a single pod.
@@ -1113,8 +1155,7 @@ To learn about requesting space using a resource specification, see
 ## Out-of-tree volume plugins
 The out-of-tree volume plugins include
-{{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}} (CSI)
+{{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}} (CSI), and also FlexVolume (which is deprecated). These plugins enable storage vendors to create custom storage plugins
 and FlexVolume. These plugins enable storage vendors to create custom storage plugins
 without adding their plugin source code to the Kubernetes repository.
 Previously, all volume plugins were "in-tree". The "in-tree" plugins were built, linked, compiled,
@@ -1247,13 +1288,21 @@ are listed in [Types of Volumes](#volume-types).
 ### flexVolume
-FlexVolume is an out-of-tree plugin interface that has existed in Kubernetes
+{{< feature-state for_k8s_version="v1.23" state="deprecated" >}}
 since version 1.2 (before CSI). It uses an exec-based model to interface with
 drivers. The FlexVolume driver binaries must be installed in a pre-defined volume
 plugin path on each node and in some cases the control plane nodes as well.
-Pods interact with FlexVolume drivers through the `flexvolume` in-tree volume plugin.
+FlexVolume is an out-of-tree plugin interface that uses an exec-based model to interface
-For more details, see the [FlexVolume](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md) examples.
+with storage drivers. The FlexVolume driver binaries must be installed in a pre-defined
 volume plugin path on each node and in some cases the control plane nodes as well.
 Pods interact with FlexVolume drivers through the `flexVolume` in-tree volume plugin.
 For more details, see the FlexVolume [README](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md#readme) document.
 {{< note >}}
 FlexVolume is deprecated. Using an out-of-tree CSI driver is the recommended way to integrate external storage with Kubernetes.
 Maintainers of FlexVolume driver should implement a CSI Driver and help to migrate users of FlexVolume drivers to CSI.
 Users of FlexVolume should move their workloads to use the equivalent CSI Driver.
 {{< /note >}}
 ## Mount propagation
@@ -151,6 +151,8 @@ and set this flag to `false`. For example:
 * For instructions on creating and working with CronJobs, and for an example
  of a CronJob manifest,
  see [Running automated tasks with CronJobs](/docs/tasks/job/automated-tasks-with-cron-jobs/).
 * For instructions to clean up failed or completed jobs automatically,
  see [Clean up Jobs automatically](/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)
 * `CronJob` is part of the Kubernetes REST API.
  Read the {{< api-reference page="workload-resources/cron-job-v1" >}}
  object definition to understand the API for Kubernetes cron jobs.
@@ -32,7 +32,7 @@ The following are typical use cases for Deployments:
 * [Declare the new state of the Pods](#updating-a-deployment) by updating the PodTemplateSpec of the Deployment. A new ReplicaSet is created and the Deployment manages moving the Pods from the old ReplicaSet to the new one at a controlled rate. Each new ReplicaSet updates the revision of the Deployment.
 * [Rollback to an earlier Deployment revision](#rolling-back-a-deployment) if the current state of the Deployment is not stable. Each rollback updates the revision of the Deployment.
 * [Scale up the Deployment to facilitate more load](#scaling-a-deployment).
-* [Pause the Deployment](#pausing-and-resuming-a-deployment) to apply multiple fixes to its PodTemplateSpec and then resume it to start a new rollout.
+* [Pause the rollout of a Deployment](#pausing-and-resuming-a-deployment) to apply multiple fixes to its PodTemplateSpec and then resume it to start a new rollout.
 * [Use the status of the Deployment](#deployment-status) as an indicator that a rollout has stuck.
 * [Clean up older ReplicaSets](#clean-up-policy) that you don't need anymore.
@@ -697,9 +697,12 @@ nginx-deployment-1989198191   7         7         0         7m
 nginx-deployment-618515232    11        11        11        7m
 ```
-## Pausing and Resuming a Deployment
+## Pausing and Resuming a rollout of a Deployment {#pausing-and-resuming-a-deployment}
-You can pause a Deployment before triggering one or more updates and then resume it. This allows you to
+When you update a Deployment, or plan to, you can pause rollouts
 for that Deployment before you trigger one or more updates. When
 you're ready to apply those changes, you resume rollouts for the
 Deployment. This approach allows you to
 apply multiple fixes in between pausing and resuming without triggering unnecessary rollouts.
 * For example, with a Deployment that was created:
@@ -775,10 +778,10 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
    deployment.apps/nginx-deployment resource requirements updated
    ```
-    The initial state of the Deployment prior to pausing it will continue its function, but new updates to
+    The initial state of the Deployment prior to pausing its rollout will continue its function, but new updates to
-    the Deployment will not have any effect as long as the Deployment is paused.
+    the Deployment will not have any effect as long as the Deployment rollout is paused.
-* Eventually, resume the Deployment and observe a new ReplicaSet coming up with all the new updates:
+* Eventually, resume the Deployment rollout and observe a new ReplicaSet coming up with all the new updates:
    ```shell
    kubectl rollout resume deployment/nginx-deployment
    ```
@@ -912,8 +915,8 @@ example, rollback the Deployment to its previous version.
 {{< /note >}}
 {{< note >}}
-If you pause a Deployment, Kubernetes does not check progress against your specified deadline.
+If you pause a Deployment rollout, Kubernetes does not check progress against your specified deadline.
-You can safely pause a Deployment in the middle of a rollout and resume without triggering
+You can safely pause a Deployment rollout in the middle of a rollout and resume without triggering
 the condition for exceeding the deadline.
 {{< /note >}}
@@ -1065,6 +1068,18 @@ allowed, which is the default if not specified.
 `.spec.replicas` is an optional field that specifies the number of desired Pods. It defaults to 1.
 Should you manually scale a Deployment, example via `kubectl scale deployment
 deployment --replicas=X`, and then you update that Deployment based on a manifest
 (for example: by running `kubectl apply -f deployment.yaml`),
 then applying that manifest overwrites the manual scaling that you previously did.
 If a [HorizontalPodAutoscaler](/docs/tasks/run-application/horizontal-pod-autoscale/) (or any
 similar API for horizontal scaling) is managing scaling for a Deployment, don't set `.spec.replicas`.
 Instead, allow the Kubernetes
 {{< glossary_tooltip text="control plane" term_id="control-plane" >}} to manage the
 `.spec.replicas` field automatically.
 ### Selector
 `.spec.selector` is a required field that specifies a [label selector](/docs/concepts/overview/working-with-objects/labels/)
@@ -436,7 +436,10 @@ version of Kubernetes you're using](/docs/home/supported-doc-versions/).
 When a Job is created, the Job controller will immediately begin creating Pods
 to satisfy the Job's requirements and will continue to do so until the Job is
 complete. However, you may want to temporarily suspend a Job's execution and
-resume it later. To suspend a Job, you can update the `.spec.suspend` field of
+resume it later, or start Jobs in suspended state and have a custom controller
 decide later when to start them.
 To suspend a Job, you can update the `.spec.suspend` field of
 the Job to true; later, when you want to resume it again, update it to false.
 Creating a Job with `.spec.suspend` set to true will create it in the suspended
 state.
@@ -522,6 +525,32 @@ directly a result of toggling the `.spec.suspend` field. In the time between
 these two events, we see that no Pods were created, but Pod creation restarted
 as soon as the Job was resumed.
 ### Mutable Scheduling Directives
 {{< feature-state for_k8s_version="v1.23" state="beta" >}}
 {{< note >}}
 In order to use this behavior, you must enable the `JobMutableNodeSchedulingDirectives`
 [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
 on the [API server](/docs/reference/command-line-tools-reference/kube-apiserver/).
 It is enabled by default.
 {{< /note >}}
 In most cases a parallel job will want the pods to run with constraints, 
 like all in the same zone, or all either on GPU model x or y but not a mix of both.
 The [suspend](#suspending-a-job) field is the first step towards achieving those semantics. Suspend allows a 
 custom queue controller to decide when a job should start; However, once a job is unsuspended,
 a custom queue controller has no influence on where the pods of a job will actually land.
 This feature allows updating a Job's scheduling directives before it starts, which gives custom queue
 controllers the ability to influence pod placement while at the same time offloading actual 
 pod-to-node assignment to kube-scheduler. This is allowed only for suspended Jobs that have never 
 been unsuspended before.
 The fields in a Job's pod template that can be updated are node affinity, node selector, 
 tolerations, labels and annotations.
 ### Specifying your own Pod selector
 Normally, when you create a Job object, you do not specify `.spec.selector`.
@@ -591,18 +620,19 @@ mismatch.
 ### Job tracking with finalizers
-{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.23" state="beta" >}}
 {{< note >}}
 In order to use this behavior, you must enable the `JobTrackingWithFinalizers`
 [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
 on the [API server](/docs/reference/command-line-tools-reference/kube-apiserver/)
 and the [controller manager](/docs/reference/command-line-tools-reference/kube-controller-manager/).
-It is disabled by default.
+It is enabled by default.
 When enabled, the control plane tracks new Jobs using the behavior described
-below. Existing Jobs are unaffected. As a user, the only difference you would
+below. Jobs created before the feature was enabled are unaffected. As a user,
-see is that the control plane tracking of Job completion is more accurate.
+the only difference you would see is that the control plane tracking of Job
 completion is more accurate.
 {{< /note >}}
 When this feature isn't enabled, the Job {{< glossary_tooltip term_id="controller" >}}
@@ -77,6 +77,7 @@ spec:
      app: nginx # has to match .spec.template.metadata.labels
  serviceName: "nginx"
  replicas: 3 # by default is 1
  minReadySeconds: 10 # by default is 0
  template:
    metadata:
      labels:
@@ -112,9 +113,24 @@ In the above example:
 The name of a StatefulSet object must be a valid
 [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
-## Pod Selector
+### Pod Selector
-You must set the `.spec.selector` field of a StatefulSet to match the labels of its `.spec.template.metadata.labels`. Prior to Kubernetes 1.8, the `.spec.selector` field was defaulted when omitted. In 1.8 and later versions, failing to specify a matching Pod Selector will result in a validation error during StatefulSet creation.
+You must set the `.spec.selector` field of a StatefulSet to match the labels of its `.spec.template.metadata.labels`. In 1.8 and later versions, failing to specify a matching Pod Selector will result in a validation error during StatefulSet creation.
 ### Volume Claim Templates
 You can set the  `.spec.volumeClaimTemplates` which can provide stable storage using [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) provisioned by a PersistentVolume Provisioner.
 ### Minimum ready seconds
 {{< feature-state for_k8s_version="v1.23" state="beta" >}}
 `.spec.minReadySeconds` is an optional field that specifies the minimum number of seconds for which a newly
 created Pod should be ready without any of its containers crashing, for it to be considered available.
 Please note that this feature is beta and enabled by default. Please opt out by unsetting the StatefulSetMinReadySeconds flag, if you don't
 want this feature to be enabled. This field defaults to 0 (the Pod will be considered 
 available as soon as it is ready). To learn more about when a Pod is considered ready, see [Container Probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes).
 ## Pod Identity
@@ -284,16 +300,100 @@ After reverting the template, you must also delete any Pods that StatefulSet had
 already attempted to run with the bad configuration.
 StatefulSet will then begin to recreate the Pods using the reverted template.
 ### Minimum ready seconds
-{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
+## PersistentVolumeClaim retention
-`.spec.minReadySeconds` is an optional field that specifies the minimum number of seconds for which a newly
+{{< feature-state for_k8s_version="v1.23" state="alpha" >}}
 created Pod should be ready without any of its containers crashing, for it to be considered available.
 This defaults to 0 (the Pod will be considered available as soon as it is ready). To learn more about when
 a Pod is considered ready, see [Container Probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes).
-Please note that this field only works if you enable the `StatefulSetMinReadySeconds` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/).
+The optional `.spec.persistentVolumeClaimRetentionPolicy` field controls if
 and how PVCs are deleted during the lifecycle of a StatefulSet. You must enable the
 `StatefulSetAutoDeletePVC` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
 to use this field. Once enabled, there are two policies you can configure for each
 StatefulSet:
 `whenDeleted`
 : configures the volume retention behavior that applies when the StatefulSet is deleted
 `whenScaled`
 : configures the volume retention behavior that applies when the replica count of
  the StatefulSet   is reduced; for example, when scaling down the set.
 For each policy that you can configure, you can set the value to either `Delete` or `Retain`.
 `Delete`
 : The PVCs created from the StatefulSet `volumeClaimTemplate` are deleted for each Pod
  affected by the policy. With the `whenDeleted` policy all PVCs from the
  `volumeClaimTemplate` are deleted after their Pods have been deleted. With the
  `whenScaled` policy, only PVCs corresponding to Pod replicas being scaled down are
  deleted, after their Pods have been deleted.
 `Retain` (default)
 : PVCs from the `volumeClaimTemplate` are not affected when their Pod is
  deleted. This is the behavior before this new feature.
 Bear in mind that these policies **only** apply when Pods are being removed due to the
 StatefulSet being deleted or scaled down. For example, if a Pod associated with a StatefulSet
 fails due to node failure, and the control plane creates a replacement Pod, the StatefulSet
 retains the existing PVC.  The existing volume is unaffected, and the cluster will attach it to
 the node where the new Pod is about to launch.
 The default for policies is `Retain`, matching the StatefulSet behavior before this new feature.
 Here is an example policy.
 ```yaml
 apiVersion: apps/v1
 kind: StatefulSet
 ...
 spec:
  persistentVolumeClaimRetentionPolicy:
    whenDeleted: Retain
    whenScaled: Delete
 ...
 ```
 The StatefulSet {{<glossary_tooltip text="controller" term_id="controller">}} adds [owner
 references](/docs/concepts/overview/working-with-objects/owners-dependents/#owner-references-in-object-specifications)
 to its PVCs, which are then deleted by the {{<glossary_tooltip text="garbage collector"
 term_id="garbage-collection">}} after the Pod is terminated. This enables the Pod to
 cleanly unmount all volumes before the PVCs are deleted (and before the backing PV and
 volume are deleted, depending on the retain policy).  When you set the `whenDeleted`
 policy to `Delete`, an owner reference to the StatefulSet instance is placed on all PVCs
 associated with that StatefulSet.
 The `whenScaled` policy must delete PVCs only when a Pod is scaled down, and not when a
 Pod is deleted for another reason. When reconciling, the StatefulSet controller compares
 its desired replica count to the actual Pods present on the cluster. Any StatefulSet Pod
 whose id greater than the replica count is condemned and marked for deletion. If the
 `whenScaled` policy is `Delete`, the condemned Pods are first set as owners to the
 associated StatefulSet template PVCs, before the Pod is deleted. This causes the PVCs
 to be garbage collected after only the condemned Pods have terminated.
 This means that if the controller crashes and restarts, no Pod will be deleted before its
 owner reference has been updated appropriate to the policy. If a condemned Pod is
 force-deleted while the controller is down, the owner reference may or may not have been
 set up, depending on when the controller crashed. It may take several reconcile loops to
 update the owner references, so some condemned Pods may have set up owner references and
 other may not. For this reason we recommend waiting for the controller to come back up,
 which will verify owner references before terminating Pods. If that is not possible, the
 operator should verify the owner references on PVCs to ensure the expected objects are
 deleted when Pods are force-deleted.
 ### Replicas
 `.spec.replicas` is an optional field that specifies the number of desired Pods. It defaults to 1.
 Should you manually scale a deployment, example via `kubectl scale
 statefulset statefulset --replicas=X`, and then you update that StatefulSet
 based on a manifest (for example: by running `kubectl apply -f
 statefulset.yaml`), then applying that manifest overwrites the manual scaling
 that you previously did.
 If a [HorizontalPodAutoscaler](/docs/tasks/run-application/horizontal-pod-autoscale/)
 (or any similar API for horizontal scaling) is managing scaling for a
 Statefulset, don't set `.spec.replicas`. Instead, allow the Kubernetes
 {{<glossary_tooltip text="control plane" term_id="control-plane" >}} to manage
 the `.spec.replicas` field automatically.
 ## {{% heading "whatsnext" %}}
@@ -1,75 +1,68 @@
 ---
 reviewers:
 - janetkuo
-title: TTL Controller for Finished Resources
+title: Automatic Clean-up for Finished Jobs 
 content_type: concept
 weight: 70
 ---
 <!-- overview -->
-{{< feature-state for_k8s_version="v1.21" state="beta" >}}
+{{< feature-state for_k8s_version="v1.23" state="stable" >}}
-The TTL controller provides a TTL (time to live) mechanism to limit the lifetime of resource
+TTL-after-finished {{<glossary_tooltip text="controller" term_id="controller">}} provides a 
-objects that have finished execution. TTL controller only handles
+TTL (time to live) mechanism to limit the lifetime of resource objects that 
-{{< glossary_tooltip text="Jobs" term_id="job" >}} for now,
+have finished execution. TTL controller only handles 
-and may be expanded to handle other resources that will finish execution,
+{{< glossary_tooltip text="Jobs" term_id="job" >}}.
 such as Pods and custom resources.
 This feature is currently beta and enabled by default, and can be disabled via 
 [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
 `TTLAfterFinished` in both kube-apiserver and kube-controller-manager.
 <!-- body -->
-## TTL Controller
+## TTL-after-finished Controller
-The TTL controller only supports Jobs for now. A cluster operator can use this feature to clean
+The TTL-after-finished controller is only supported for Jobs. A cluster operator can use this feature to clean
 up finished Jobs (either `Complete` or `Failed`) automatically by specifying the
 `.spec.ttlSecondsAfterFinished` field of a Job, as in this
 [example](/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically).
-The TTL controller will assume that a resource is eligible to be cleaned up
+The TTL-after-finished controller will assume that a job is eligible to be cleaned up
-TTL seconds after the resource has finished, in other words, when the TTL has expired. When the
+TTL seconds after the job has finished, in other words, when the TTL has expired. When the
-TTL controller cleans up a resource, it will delete it cascadingly, that is to say it will delete
+TTL-after-finished controller cleans up a job, it will delete it cascadingly, that is to say it will delete
-its dependent objects together with it. Note that when the resource is deleted,
+its dependent objects together with it. Note that when the job is deleted,
 its lifecycle guarantees, such as finalizers, will be honored.
 The TTL seconds can be set at any time. Here are some examples for setting the
 `.spec.ttlSecondsAfterFinished` field of a Job:
-* Specify this field in the resource manifest, so that a Job can be cleaned up
+* Specify this field in the job manifest, so that a Job can be cleaned up
  automatically some time after it finishes.
-* Set this field of existing, already finished resources, to adopt this new
+* Set this field of existing, already finished jobs, to adopt this new
  feature.
 * Use a
  [mutating admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
-  to set this field dynamically at resource creation time. Cluster administrators can
+  to set this field dynamically at job creation time. Cluster administrators can
-  use this to enforce a TTL policy for finished resources.
+  use this to enforce a TTL policy for finished jobs.
 * Use a
  [mutating admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
-  to set this field dynamically after the resource has finished, and choose
+  to set this field dynamically after the job has finished, and choose
-  different TTL values based on resource status, labels, etc.
+  different TTL values based on job status, labels, etc.
 ## Caveat
 ### Updating TTL Seconds
 Note that the TTL period, e.g. `.spec.ttlSecondsAfterFinished` field of Jobs,
-can be modified after the resource is created or has finished. However, once the
+can be modified after the job is created or has finished. However, once the
 Job becomes eligible to be deleted (when the TTL has expired), the system won't
 guarantee that the Jobs will be kept, even if an update to extend the TTL
 returns a successful API response.
 ### Time Skew
-Because TTL controller uses timestamps stored in the Kubernetes resources to
+Because TTL-after-finished controller uses timestamps stored in the Kubernetes jobs to
 determine whether the TTL has expired or not, this feature is sensitive to time
-skew in the cluster, which may cause TTL controller to clean up resource objects
+skew in the cluster, which may cause TTL-after-finish controller to clean up job objects
 at the wrong time.
-In Kubernetes, it's required to run NTP on all nodes
+Clocks aren't always correct, but the difference should be
 (see [#6159](https://github.com/kubernetes/kubernetes/issues/6159#issuecomment-93844058))
 to avoid time skew. Clocks aren't always correct, but the difference should be
 very small. Please be aware of this risk when setting a non-zero TTL.
@@ -9,22 +9,13 @@ weight: 80
 <!-- overview -->
-{{< feature-state state="alpha" for_k8s_version="v1.22" >}}
+{{< feature-state state="beta" for_k8s_version="v1.23" >}}
 This page provides an overview of ephemeral containers: a special type of container
 that runs temporarily in an existing {{< glossary_tooltip term_id="pod" >}} to
 accomplish user-initiated actions such as troubleshooting. You use ephemeral
 containers to inspect services rather than to build applications.
 {{< warning >}}
 Ephemeral containers are in alpha state and are not suitable for production
 clusters. In accordance with the [Kubernetes Deprecation Policy](
 /docs/reference/using-api/deprecation-policy/), this alpha feature could change
 significantly in the future or be removed entirely.
 {{< /warning >}}
 <!-- body -->
 ## Understanding ephemeral containers
@@ -159,7 +159,7 @@ through which the Pod has or has not passed:
 * `PodScheduled`: the Pod has been scheduled to a node.
 * `ContainersReady`: all containers in the Pod are ready.
 * `Initialized`: all [init containers](/docs/concepts/workloads/pods/init-containers/)
-  have started successfully.
+  have completed successfully.
 * `Ready`: the Pod is able to serve requests and should be added to the load
  balancing pools of all matching Services.
@@ -233,57 +233,87 @@ When a Pod's containers are Ready but at least one custom condition is missing o
 ## Container probes
-A [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) is a diagnostic
+A _probe_ is a diagnostic
 performed periodically by the
 [kubelet](/docs/reference/command-line-tools-reference/kubelet/)
-on a Container. To perform a diagnostic,
+on a container. To perform a diagnostic,
-the kubelet calls a
+the kubelet either executes code within the container, or makes
-[Handler](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core) implemented by
+a network request.
 the container. There are three types of handlers:
-* [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core):
+### Check mechanisms {#probe-check-methods}
-  Executes a specified command inside the container. The diagnostic
+
 There are four different ways to check a container using a probe.
 Each probe must define exactly one of these four mechanisms:
 `exec`
 : Executes a specified command inside the container. The diagnostic
  is considered successful if the command exits with a status code of 0.
-* [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core):
+`grpc`
-  Performs a TCP check against the Pod's IP address on
+: Performs a remote procedure call using [gRPC](https://grpc.io/).
-  a specified port. The diagnostic is considered successful if the port is open.
+  The target should implement
  [gRPC health checks](https://grpc.io/grpc/core/md_doc_health-checking.html).
  The diagnostic is considered successful if the `status`
  of the response is `SERVING`.  
  gRPC probes are an alpha feature and are only available if you
  enable the `GRPCContainerProbe`
  [feature gate](/docs/reference/command-line-tools-reference/feature-gates/).
-* [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core):
+`httpGet`
-  Performs an HTTP `GET` request against the Pod's IP
+: Performs an HTTP `GET` request against the Pod's IP
-  address on a specified port and path. The diagnostic is considered successful
+  address on a specified port and path. The diagnostic is
-  if the response has a status code greater than or equal to 200 and less than 400.
+  considered successful if the response has a status code
  greater than or equal to 200 and less than 400.
 `tcpSocket`
 : Performs a TCP check against the Pod's IP address on
  a specified port. The diagnostic is considered successful if
  the port is open. If the remote system (the container) closes
  the connection immediately after it opens, this counts as healthy.
 ### Probe outcome
 Each probe has one of three results:
-* `Success`: The container passed the diagnostic.
+`Success`
-* `Failure`: The container failed the diagnostic.
+: The container passed the diagnostic.
-* `Unknown`: The diagnostic failed, so no action should be taken.
+
 `Failure`
 : The container failed the diagnostic.
 `Unknown`
 : The diagnostic failed (no action should be taken, and the kubelet
  will make further checks).
 ### Types of probe
 The kubelet can optionally perform and react to three kinds of probes on running
 containers:
-* `livenessProbe`: Indicates whether the container is running. If
+`livenessProbe`
 : Indicates whether the container is running. If
  the liveness probe fails, the kubelet kills the container, and the container
-   is subjected to its [restart policy](#restart-policy). If a Container does not
+  is subjected to its [restart policy](#restart-policy). If a container does not
  provide a liveness probe, the default state is `Success`.
-* `readinessProbe`: Indicates whether the container is ready to respond to requests.
+`readinessProbe`
 : Indicates whether the container is ready to respond to requests.
  If the readiness probe fails, the endpoints controller removes the Pod's IP
  address from the endpoints of all Services that match the Pod. The default
-   state of readiness before the initial delay is `Failure`. If a Container does
+  state of readiness before the initial delay is `Failure`. If a container does
  not provide a readiness probe, the default state is `Success`.
-* `startupProbe`: Indicates whether the application within the container is started.
+`startupProbe`
 : Indicates whether the application within the container is started.
  All other probes are disabled if a startup probe is provided, until it succeeds.
  If the startup probe fails, the kubelet kills the container, and the container
-   is subjected to its [restart policy](#restart-policy). If a Container does not
+ is subjected to its [restart policy](#restart-policy). If a container does not
  provide a startup probe, the default state is `Success`.
 For more information about how to set up a liveness, readiness, or startup probe,
 see [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/).
-### When should you use a liveness probe?
+#### When should you use a liveness probe?
 {{< feature-state for_k8s_version="v1.0" state="stable" >}}
@@ -295,7 +325,7 @@ with the Pod's `restartPolicy`.
 If you'd like your container to be killed and restarted if a probe fails, then
 specify a liveness probe, and specify a `restartPolicy` of Always or OnFailure.
-### When should you use a readiness probe?
+#### When should you use a readiness probe?
 {{< feature-state for_k8s_version="v1.0" state="stable" >}}
@@ -329,7 +359,7 @@ The Pod remains in the unready state while it waits for the containers in the Po
 to stop.
 {{< /note >}}
-### When should you use a startup probe?
+#### When should you use a startup probe?
 {{< feature-state for_k8s_version="v1.20" state="stable" >}}
@@ -451,13 +481,13 @@ This avoids a resource leak as Pods are created and terminated over time.
 ## {{% heading "whatsnext" %}}
 * Get hands-on experience
-  [attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
+  [attaching handlers to container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
 * Get hands-on experience
  [configuring Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/).
 * Learn more about [container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/).
-* For detailed information about Pod / Container status in the API, see [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)
+* For detailed information about Pod and container status in the API, see
-and
+  the API reference documentation covering
-[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core).
+  [`.status`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodStatus) for Pod.
@@ -234,6 +234,8 @@ To overcome this situation, you can either increase the `maxSkew` or modify one
 The scheduler will skip the non-matching nodes from the skew calculations if the incoming Pod has `spec.nodeSelector` or `spec.affinity.nodeAffinity` defined.
 ### Example: TopologySpreadConstraints with NodeAffinity
 Suppose you have a 5-node cluster ranging from zoneA to zoneC:
 {{<mermaid>}}
@@ -349,12 +351,14 @@ Also, the legacy `SelectorSpread` plugin, which provides an equivalent behavior,
 is disabled.
 {{< note >}}
 The `PodTopologySpread` plugin does not score the nodes that don't have
 the topology keys specified in the spreading constraints. This might result
 in a different default behavior compared to the legacy `SelectorSpread` plugin when
 using the default topology constraints.
 If your nodes are not expected to have **both** `kubernetes.io/hostname` and
 `topology.kubernetes.io/zone` labels set, define your own constraints
 instead of using the Kubernetes defaults.
 The `PodTopologySpread` plugin does not score the nodes that don't have
 the topology keys specified in the spreading constraints.
 {{< /note >}}
 If you don't want to use the default Pod spreading constraints for your cluster,
@@ -27,7 +27,7 @@ the documentation, the website style, the processes for reviewing and merging
 pull requests, or other aspects of the documentation. For maximum transparency,
 these types of proposals need to be discussed in a SIG Docs meeting or on the
 [kubernetes-sig-docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
-In addition, it can really help to have some context about the way things
+In addition, it can help to have some context about the way things
 currently work and why past decisions have been made before proposing sweeping
 changes. The quickest way to get answers to questions about how the documentation
 currently works is to ask in the `#sig-docs` Slack channel on
@@ -54,7 +54,7 @@ refer to
 The SIG Docs representative for a given release coordinates the following tasks:
 - Monitor the feature-tracking spreadsheet for new or changed features with an
-  impact on documentation. If documentation for a given feature won't be ready
+  impact on documentation. If the documentation for a given feature won't be ready
  for the release, the feature may not be allowed to go into the release.
 - Attend sig-release meetings regularly and give updates on the status of the
  docs for the release.
@@ -82,12 +82,12 @@ few PR submissions.
 Responsibilities for New Contributor Ambassadors include:
 - Monitoring the [#sig-docs Slack channel](https://kubernetes.slack.com) for questions from new contributors.
- Working with PR wranglers to identify good first issues for new contributors.
+- Working with PR wranglers to identify [good first issues](https://kubernetes.dev/docs/guide/help-wanted/#good-first-issue) for new contributors.
 - Mentoring new contributors through their first few PRs to the docs repo.
 - Helping new contributors create the more complex PRs they need to become Kubernetes members.
 - [Sponsoring contributors](/docs/contribute/advanced/#sponsor-a-new-contributor) on their path to becoming Kubernetes members.
-Current New Contributor Ambassadors are announced at each SIG-Docs meeting, and in the [Kubernetes #sig-docs channel](https://kubernetes.slack.com).
+Current New Contributor Ambassadors are announced at each SIG-Docs meeting and in the [Kubernetes #sig-docs channel](https://kubernetes.slack.com).
 ## Sponsor a new contributor
@@ -122,7 +122,7 @@ Approvers must meet the following requirements to be a co-chair:
 - Understand SIG Docs workflows and tooling: git, Hugo, localization, blog subproject
 - Understand how other Kubernetes SIGs and repositories affect the SIG Docs
  workflow, including:
-  [teams in k/org](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml),
+  [teams in k/org](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml), the
  [process in k/community](https://github.com/kubernetes/community/tree/master/sig-docs),
  plugins in [k/test-infra](https://github.com/kubernetes/test-infra/), and the role of
  [SIG Architecture](https://github.com/kubernetes/community/tree/master/sig-architecture).
@@ -27,7 +27,7 @@ flowchart LR
    direction TB
       T[ ] -.-
       D[Write docs in markdown<br>and build site with Hugo] --- E[source in GitHub]
-       E --- G[_'/content/../docs'_ folder contains docs<br>for multiple languages]
+       E --- G['/content/../docs' folder contains docs<br>for multiple languages]
       G --- H[Review Hugo page content<br>types and shortcodes]
    end
@@ -38,6 +38,7 @@ Anyone can write a blog post and submit it for review.
  - The components of Kubernetes are purposely modular, so tools that use existing integration points like CNI and CSI are on topic. 
  - Posts about other CNCF projects may or may not be on topic. We recommend asking the blog team before submitting a draft.
    - Many CNCF projects have their own blog. These are often a better choice for posts. There are times of major feature or milestone for a CNCF project that users would be interested in reading on the Kubernetes blog.
  - Blog posts about contributing to the Kubernetes project should be in the [Kubernetes Contributors site](https://kubernetes.dev)
 - Blog posts should be original content
  - The official blog is not for repurposing existing content from a third party as new content.
  - The [license](https://github.com/kubernetes/website/blob/main/LICENSE) for the blog allows commercial use of the content for commercial purposes, but not the other way around.
@@ -29,7 +29,13 @@ Each day in a week-long shift as PR Wrangler:
    - You can also tag a [SIG](https://github.com/kubernetes/community/blob/master/sig-list.md) for a review by commenting `@kubernetes/<sig>-pr-reviews` on the PR.
 - Use the `/approve` comment to approve a PR for merging. Merge the PR when ready.
    - PRs should have a `/lgtm` comment from another member before merging.
-    - Consider accepting technically accurate content that doesn't meet the [style guidelines](/docs/contribute/style/style-guide/). Open a new issue with the label `good first issue` to address style concerns.
+    - Consider accepting technically accurate content that doesn't meet the
      [style guidelines](/docs/contribute/style/style-guide/). As you approve the change,
      open a new issue to address the style concern. You can usually write these style fix
      issues as [good first issues](https://kubernetes.dev/docs/guide/help-wanted/#good-first-issue).
    - Using style fixups as good first issues is a good way to ensure a supply of easier tasks
      to help onboard new contributors.
 ### Helpful GitHub queries for wranglers
@@ -121,7 +121,7 @@ finds issues that might need triage.
  `priority/important-longterm` | Do this within 6 months.
  `priority/backlog` | Deferrable indefinitely. Do when resources are available.
  `priority/awaiting-more-evidence` | Placeholder for a potentially good issue so it doesn't get lost.
-  `help` or `good first issue` | Suitable for someone with very little Kubernetes or SIG Docs experience. See [Help Wanted and Good First Issue Labels](https://github.com/kubernetes/community/blob/master/contributors/guide/help-wanted.md) for more information.
+  `help` or `good first issue` | Suitable for someone with very little Kubernetes or SIG Docs experience. See [Help Wanted and Good First Issue Labels](https://kubernetes.dev/docs/guide/help-wanted/) for more information.
  {{< /table >}}
@@ -73,10 +73,10 @@ configure  kubernetes components or tools. Most of these APIs are not exposed
 by the API server in a RESTful way though they are essential for a user or an
 operator to use or manage a cluster.
-* [kube-apiserver configuration (v1alpha1)](/docs/reference/config-api/apiserver-config.v1alpha1/)
+* [kube-apiserver configuration (v1beta1)](/docs/reference/config-api/apiserver-config.v1beta1/)
 * [kubelet configuration (v1beta1)](/docs/reference/config-api/kubelet-config.v1beta1/)
 * [kube-scheduler configuration (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/)
 * [kube-scheduler configuration (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/)
 * [kube-scheduler configuration (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/)
 * [kube-scheduler policy reference (v1)](/docs/reference/config-api/kube-scheduler-policy-config.v1/)
 * [kube-proxy configuration (v1alpha1)](/docs/reference/config-api/kube-proxy-config.v1alpha1/)
 * [`audit.k8s.io/v1` API](/docs/reference/config-api/apiserver-audit.v1/)
@@ -30,9 +30,9 @@ mutating and validating (respectively)
 which are configured in the API.
 Admission controllers may be "validating", "mutating", or both. Mutating
-controllers may modify the objects they admit; validating controllers may not.
+controllers may modify related objects to the requests they admit; validating controllers may not.
-Admission controllers limit requests to create, delete, modify or connect to (proxy). They do not support read requests.
+Admission controllers limit requests to create, delete, modify objects or connect to proxy. They do not limit requests to read objects.
 The admission control process proceeds in two phases. In the first phase,
 mutating admission controllers are run. In the second phase, validating
@@ -583,7 +583,8 @@ subresource of the referenced *owner* can change it.
 This admission controller implements additional validations for checking incoming `PersistentVolumeClaim` resize requests.
 {{< note >}}
-Support for volume resizing is available as an alpha feature. Admins must set the feature gate `ExpandPersistentVolumes`
+Support for volume resizing is available as a beta feature. As a cluster administrator,
 you must ensure that the feature gate `ExpandPersistentVolumes` is set
 to `true` to enable resizing.
 {{< /note >}}
@@ -698,7 +699,7 @@ admission plugin, which allows preventing pods from running on specifically tain
 ### PodSecurity {#podsecurity}
-{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.23" state="beta" >}}
 This is the replacement for the deprecated [PodSecurityPolicy](#podsecuritypolicy) admission controller
 defined in the next section. This admission controller acts on creation and modification of the pod and
@@ -104,7 +104,7 @@ See [Managing Certificates](/docs/tasks/administer-cluster/certificates/) for ho
 ### Static Token File
 The API server reads bearer tokens from a file when given the `--token-auth-file=SOMEFILE` option on the command line.  Currently, tokens last indefinitely, and the token list cannot be
-changed without restarting API server.
+changed without restarting the API server.
 The token file is a csv file with a minimum of 3 columns: token, user name, user uid,
 followed by optional group names.
@@ -134,7 +134,7 @@ The output is similar to this:
 no
 ```
-Similarly, to check whether a Service Account named `dev-sa` in Namespace `dev`
+Similarly, to check whether a ServiceAccount named `dev-sa` in Namespace `dev`
 can list Pods in the Namespace `target`:
 ```bash
@@ -71,20 +71,23 @@ different Kubernetes components.
 | `CSIMigration` | `false` | Alpha | 1.14 | 1.16 |
 | `CSIMigration` | `true` | Beta | 1.17 | |
 | `CSIMigrationAWS` | `false` | Alpha | 1.14 | |
-| `CSIMigrationAWS` | `false` | Beta | 1.17 | |
+| `CSIMigrationAWS` | `false` | Beta | 1.17 | 1.22 |
 | `CSIMigrationAWS` | `true` | Beta | 1.23 | |
 | `CSIMigrationAzureDisk` | `false` | Alpha | 1.15 | 1.18 |
-| `CSIMigrationAzureDisk` | `false` | Beta | 1.19 | |
+| `CSIMigrationAzureDisk` | `false` | Beta | 1.19 | 1.22 |
 | `CSIMigrationAzureDisk` | `true` | Beta | 1.23 | |
 | `CSIMigrationAzureFile` | `false` | Alpha | 1.15 | 1.19 |
 | `CSIMigrationAzureFile` | `false` | Beta | 1.21 | |
 | `CSIMigrationGCE` | `false` | Alpha | 1.14 | 1.16 |
-| `CSIMigrationGCE` | `false` | Beta | 1.17 | |
+| `CSIMigrationGCE` | `false` | Beta | 1.17 | 1.22 |
 | `CSIMigrationGCE` | `true` | Beta | 1.23 | |
 | `CSIMigrationOpenStack` | `false` | Alpha | 1.14 | 1.17 |
 | `CSIMigrationOpenStack` | `true` | Beta | 1.18 | |
 | `CSIMigrationvSphere` | `false` | Beta | 1.19 | |
 | `CSIMigrationPortworx` | `false` | Alpha | 1.23 | |
 | `CSIMigrationRBD` | `false` | Alpha | 1.23 | |
 | `CSIStorageCapacity` | `false` | Alpha | 1.19 | 1.20 |
 | `CSIStorageCapacity` | `true` | Beta | 1.21 | |
 | `CSIVolumeFSGroupPolicy` | `false` | Alpha | 1.19 | 1.19 |
 | `CSIVolumeFSGroupPolicy` | `true` | Beta | 1.20 | |
 | `CSIVolumeHealth` | `false` | Alpha | 1.21 | |
 | `CSRDuration` | `true` | Beta | 1.22 | |
 | `ConfigurableFSGroupPolicy` | `false` | Alpha | 1.18 | 1.19 |
@@ -92,6 +95,7 @@ different Kubernetes components.
 | `ControllerManagerLeaderMigration` | `false` | Alpha | 1.21 | 1.21 |
 | `ControllerManagerLeaderMigration` | `true` | Beta | 1.22 | |
 | `CustomCPUCFSQuotaPeriod` | `false` | Alpha | 1.12 | |
 | `CustomResourceValidationExpressions` | `false` | Alpha | 1.23 | |
 | `DaemonSetUpdateSurge` | `false` | Alpha | 1.21 | 1.21 |
 | `DaemonSetUpdateSurge` | `true` | Beta | 1.22 | |
 | `DefaultPodTopologySpread` | `false` | Alpha | 1.19 | 1.19 |
@@ -108,7 +112,8 @@ different Kubernetes components.
 | `EfficientWatchResumption` | `true` | Beta | 1.21 | |
 | `EndpointSliceTerminatingCondition` | `false` | Alpha | 1.20 | 1.21 |
 | `EndpointSliceTerminatingCondition` | `true` | Beta | 1.22 | |
-| `EphemeralContainers` | `false` | Alpha | 1.16 | |
+| `EphemeralContainers` | `false` | Alpha | 1.16 | 1.22 |
 | `EphemeralContainers` | `true` | Beta | 1.23 | |
 | `ExpandCSIVolumes` | `false` | Alpha | 1.14 | 1.15 |
 | `ExpandCSIVolumes` | `true` | Beta | 1.16 | |
 | `ExpandedDNSConfig` | `false` | Alpha | 1.22 | |
@@ -117,25 +122,24 @@ different Kubernetes components.
 | `ExpandPersistentVolumes` | `false` | Alpha | 1.8 | 1.10 |
 | `ExpandPersistentVolumes` | `true` | Beta | 1.11 | |
 | `ExperimentalHostUserNamespaceDefaulting` | `false` | Beta | 1.5 | |
 | `GenericEphemeralVolume` | `false` | Alpha | 1.19 | 1.20 |
 | `GenericEphemeralVolume` | `true` | Beta | 1.21 | |
 | `GracefulNodeShutdown` | `false` | Alpha | 1.20 | 1.20 |
 | `GracefulNodeShutdown` | `true` | Beta | 1.21 | |
 | `GRPCContainerProbe` | `false` | Alpha | 1.23 | |
 | `HPAContainerMetrics` | `false` | Alpha | 1.20 | |
 | `HPAScaleToZero` | `false` | Alpha | 1.16 | |
 | `IdentifyPodOS` | `false` | Alpha | 1.23 | |
 | `IndexedJob` | `false` | Alpha | 1.21 | 1.21 |
 | `IndexedJob` | `true` | Beta | 1.22 | |
 | `IngressClassNamespacedParams` | `false` | Alpha | 1.21 | 1.21 |
 | `IngressClassNamespacedParams` | `true` | Beta | 1.22 | |
 | `InTreePluginAWSUnregister` | `false` | Alpha | 1.21 | |
 | `InTreePluginAzureDiskUnregister` | `false` | Alpha | 1.21 | |
 | `InTreePluginAzureFileUnregister` | `false` | Alpha | 1.21 | |
 | `InTreePluginGCEUnregister` | `false` | Alpha | 1.21 | |
 | `InTreePluginOpenStackUnregister` | `false` | Alpha | 1.21 | |
 | `InTreePluginvSphereUnregister` | `false` | Alpha | 1.21 | |
-| `IPv6DualStack` | `false` | Alpha | 1.15 | 1.20 |
+| `JobMutableNodeSchedulingDirectives` | `true` | Beta | 1.23 | |
-| `IPv6DualStack` | `true` | Beta | 1.21 | |
+| `JobReadyPods` | `false` | Alpha | 1.23 | |
-| `JobTrackingWithFinalizers` | `false` | Alpha | 1.22 | |
+| `JobTrackingWithFinalizers` | `false` | Alpha | 1.22 | 1.22 |
 | `JobTrackingWithFinalizers` | `true` | Beta | 1.23 | |
 | `KubeletCredentialProviders` | `false` | Alpha | 1.20 | |
 | `KubeletInUserNamespace` | `false` | Alpha | 1.22 | |
 | `KubeletPodResourcesGetAllocatable` | `false` | Alpha | 1.21 | |
@@ -159,7 +163,8 @@ different Kubernetes components.
 | `PodAffinityNamespaceSelector` | `true` | Beta | 1.22 | |
 | `PodOverhead` | `false` | Alpha | 1.16 | 1.17 |
 | `PodOverhead` | `true` | Beta | 1.18 | |
-| `PodSecurity` | `false` | Alpha | 1.22 | |
+| `PodSecurity` | `false` | Alpha | 1.22 | 1.22 |
 | `PodSecurity` | `true` | Beta | 1.23 | |
 | `PreferNominatedNode` | `false` | Alpha | 1.21 | 1.21 |
 | `PreferNominatedNode` | `true` | Beta | 1.22 | |
 | `ProbeTerminationGracePeriod` | `false` | Alpha | 1.21 | 1.21 |
@@ -168,6 +173,7 @@ different Kubernetes components.
 | `ProxyTerminatingEndpoints` | `false` | Alpha | 1.22 | |
 | `QOSReserved` | `false` | Alpha | 1.11 | |
 | `ReadWriteOncePod` | `false` | Alpha | 1.22 | |
 | `RecoverVolumeExpansionFailure` | `false` | Alpha | 1.23 | |
 | `RemainingItemCount` | `false` | Alpha | 1.15 | 1.15 |
 | `RemainingItemCount` | `true` | Beta | 1.16 | |
 | `RemoveSelfLink` | `false` | Alpha | 1.16 | 1.19 |
@@ -183,22 +189,22 @@ different Kubernetes components.
 | `ServiceLoadBalancerClass` | `true` | Beta | 1.22 | |
 | `SizeMemoryBackedVolumes` | `false` | Alpha | 1.20 | 1.21 |
 | `SizeMemoryBackedVolumes` | `true` | Beta | 1.22 | |
-| `StatefulSetMinReadySeconds` | `false` | Alpha | 1.22 | |
+| `StatefulSetMinReadySeconds` | `false` | Alpha | 1.22 | 1.22 |
 | `StatefulSetMinReadySeconds` | `true` | Beta | 1.23 | |
 | `StorageVersionAPI` | `false` | Alpha | 1.20 | |
 | `StorageVersionHash` | `false` | Alpha | 1.14 | 1.14 |
 | `StorageVersionHash` | `true` | Beta | 1.15 | |
 | `SuspendJob` | `false` | Alpha | 1.21 | 1.21 |
 | `SuspendJob` | `true` | Beta | 1.22 | |
-| `TTLAfterFinished` | `false` | Alpha | 1.12 | 1.20 |
+| `TopologyAwareHints` | `false` | Alpha | 1.21 | 1.22 |
-| `TTLAfterFinished` | `true` | Beta | 1.21 | |
+| `TopologyAwareHints` | `true` | Beta | 1.23 | |
 | `TopologyAwareHints` | `false` | Alpha | 1.21 | |
 | `TopologyManager` | `false` | Alpha | 1.16 | 1.17 |
 | `TopologyManager` | `true` | Beta | 1.18 | |
 | `VolumeCapacityPriority` | `false` | Alpha | 1.21 | - |
 | `WinDSR` | `false` | Alpha | 1.14 | |
 | `WinOverlay` | `false` | Alpha | 1.14 | 1.19 |
 | `WinOverlay` | `true` | Beta | 1.20 | |
-| `WindowsHostProcessContainers` | `false` | Alpha | 1.22 | |
+| `WindowsHostProcessContainers` | `false` | Beta | 1.23 | |
 {{< /table >}}
 ### Feature gates for graduated or deprecated features
@@ -227,6 +233,7 @@ different Kubernetes components.
 | `BoundServiceAccountTokenVolume` | `false` | Alpha | 1.13 | 1.20 |
 | `BoundServiceAccountTokenVolume` | `true` | Beta | 1.21 | 1.21 |
 | `BoundServiceAccountTokenVolume` | `true` | GA | 1.22 | - |
 | `ConfigurableFSGroupPolicy` | `true` | GA | 1.23 | |
 | `CRIContainerLogRotation` | `false` | Alpha | 1.10 | 1.10 |
 | `CRIContainerLogRotation` | `true` | Beta | 1.11 | 1.20 |
 | `CRIContainerLogRotation` | `true` | GA | 1.21 | - |
@@ -257,6 +264,9 @@ different Kubernetes components.
 | `CSIServiceAccountToken` | `false` | Alpha | 1.20 | 1.20 |
 | `CSIServiceAccountToken` | `true` | Beta | 1.21 | 1.21 |
 | `CSIServiceAccountToken` | `true` | GA | 1.22 | |
 | `CSIVolumeFSGroupPolicy` | `false` | Alpha | 1.19 | 1.19 |
 | `CSIVolumeFSGroupPolicy` | `true` | Beta | 1.20 | 1.22 |
 | `CSIVolumeFSGroupPolicy` | `true` | GA | 1.23 | |
 | `CronJobControllerV2` | `false` | Alpha | 1.20 | 1.20 |
 | `CronJobControllerV2` | `true` | Beta | 1.21 | 1.21 |
 | `CronJobControllerV2` | `true` | GA | 1.22 | - |
@@ -311,6 +321,9 @@ different Kubernetes components.
 | `ExternalPolicyForExternalIP` | `true` | GA | 1.18 | - |
 | `GCERegionalPersistentDisk` | `true` | Beta | 1.10 | 1.12 |
 | `GCERegionalPersistentDisk` | `true` | GA | 1.13 | - |
 | `GenericEphemeralVolume` | `false` | Alpha | 1.19 | 1.20 |
 | `GenericEphemeralVolume` | `true` | Beta | 1.21 | 1.22 |
 | `GenericEphemeralVolume` | `true` | GA | 1.23 | - |
 | `HugePageStorageMediumSize` | `false` | Alpha | 1.18 | 1.18 |
 | `HugePageStorageMediumSize` | `true` | Beta | 1.19 | 1.21 |
 | `HugePageStorageMediumSize` | `true` | GA | 1.22 | - |
@@ -325,8 +338,14 @@ different Kubernetes components.
 | `ImmutableEphemeralVolumes` | `false` | Alpha | 1.18 | 1.18 |
 | `ImmutableEphemeralVolumes` | `true` | Beta | 1.19 | 1.20 |
 | `ImmutableEphemeralVolumes` | `true` | GA | 1.21 | |
 | `IngressClassNamespacedParams` | `false` | Alpha | 1.21 | 1.21 |
 | `IngressClassNamespacedParams` | `true` | Beta | 1.22 | 1.22 |
 | `IngressClassNamespacedParams` | `true` | GA | 1.23 | - |
 | `Initializers` | `false` | Alpha | 1.7 | 1.13 |
 | `Initializers` | - | Deprecated | 1.14 | - |
 | `IPv6DualStack` | `false` | Alpha | 1.15 | 1.20 |
 | `IPv6DualStack` | `true` | Beta | 1.21 | 1.22 |
 | `IPv6DualStack` | `true` | GA | 1.23 | - |
 | `KubeletConfigFile` | `false` | Alpha | 1.8 | 1.9 |
 | `KubeletConfigFile` | - | Deprecated | 1.10 | - |
 | `KubeletPluginsWatcher` | `false` | Alpha | 1.11 | 1.11 |
@@ -356,6 +375,7 @@ different Kubernetes components.
 | `PersistentLocalVolumes` | `false` | Alpha | 1.7 | 1.9 |
 | `PersistentLocalVolumes` | `true` | Beta | 1.10 | 1.13 |
 | `PersistentLocalVolumes` | `true` | GA | 1.14 | - |
 | `PodAndContainerStatsFromCRI` | `false` | Alpha | 1.23 | |
 | `PodDisruptionBudget` | `false` | Alpha | 1.3 | 1.4 |
 | `PodDisruptionBudget` | `true` | Beta | 1.5 | 1.20 |
 | `PodDisruptionBudget` | `true` | GA | 1.21 | - |
@@ -435,6 +455,9 @@ different Kubernetes components.
 | `SupportPodPidsLimit` | `true` | GA | 1.20 | - |
 | `Sysctls` | `true` | Beta | 1.11 | 1.20 |
 | `Sysctls` | `true` | GA | 1.21 | |
 | `TTLAfterFinished` | `false` | Alpha | 1.12 | 1.20 |
 | `TTLAfterFinished` | `true` | Beta | 1.21 | 1.22 |
 | `TTLAfterFinished` | `true` | GA | 1.23 | - |
 | `TaintBasedEvictions` | `false` | Alpha | 1.6 | 1.12 |
 | `TaintBasedEvictions` | `true` | Beta | 1.13 | 1.17 |
 | `TaintBasedEvictions` | `true` | GA | 1.18 | - |
@@ -615,6 +638,13 @@ Each feature gate is designed for enabling/disabling a specific feature:
  operations from the GCE-PD in-tree plugin to PD CSI plugin. Supports falling
  back to in-tree GCE plugin if a node does not have PD CSI plugin installed and
  configured. Requires CSIMigration feature flag enabled.
 - `CSIMigrationRBD`: Enables shims and translation logic to route volume
  operations from the RBD in-tree plugin to Ceph RBD CSI plugin. Requires
  CSIMigration and CSIMigrationRBD feature flags enabled and Ceph CSI plugin
  installed and configured in the cluster. This flag has been deprecated in
  favor of the
  `InTreePluginRBDUnregister` feature flag which prevents the registration of
  in-tree RBD plugin.
 - `CSIMigrationGCEComplete`: Stops registering the GCE-PD in-tree plugin in
  kubelet and volume controllers and enables shims and translation logic to
  route volume operations from the GCE-PD in-tree plugin to PD CSI plugin.
@@ -641,6 +671,9 @@ Each feature gate is designed for enabling/disabling a specific feature:
  CSIMigrationvSphere feature flags enabled and vSphere CSI plugin installed and
  configured on all nodes in the cluster. This flag has been deprecated in favor
  of the `InTreePluginvSphereUnregister` feature flag which prevents the registration of in-tree vsphere plugin.
 - `CSIMigrationPortworx`: Enables shims and translation logic to route volume operations
  from the Portworx in-tree plugin to Portworx CSI plugin.
  Requires Portworx CSI driver to be installed and configured in the cluster, and feature gate set `CSIMigrationPortworx=true` in kube-controller-manager and kubelet configs.
 - `CSINodeInfo`: Enable all logic related to the CSINodeInfo API object in csi.storage.k8s.io.
 - `CSIPersistentVolume`: Enable discovering and mounting volumes provisioned through a
  [CSI (Container Storage Interface)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md)
@@ -669,6 +702,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
  version 1 of the same controller is selected.
 - `CustomCPUCFSQuotaPeriod`: Enable nodes to change `cpuCFSQuotaPeriod` in
  [kubelet config](/docs/tasks/administer-cluster/kubelet-config-file/).
 - `CustomResourceValidationExpressions`: Enable expression language validation in CRD which will validate customer resource based on validation rules written in `x-kubernetes-validations` extension.
 - `CustomPodDNS`: Enable customizing the DNS settings for a Pod using its `dnsConfig` property.
  Check [Pod's DNS Config](/docs/concepts/services-networking/dns-pod-service/#pods-dns-config)
  for more details.
@@ -758,6 +792,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
  and gracefully terminate pods running on the node. See
  [Graceful Node Shutdown](/docs/concepts/architecture/nodes/#graceful-node-shutdown)
  for more details.
 - `GRPCContainerProbe`: Enables the gRPC probe method for {Liveness,Readiness,Startup}Probe. See [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe).
 - `HPAContainerMetrics`: Enable the `HorizontalPodAutoscaler` to scale based on
  metrics from individual containers in target pods.
 - `HPAScaleToZero`: Enables setting `minReplicas` to 0 for `HorizontalPodAutoscaler`
@@ -769,6 +804,8 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `HyperVContainer`: Enable
  [Hyper-V isolation](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container)
  for Windows containers.
 - `IdentifyPodOS`: Allows the Pod OS field to be specified. This helps in identifying the OS of the pod
  authoritatively during the API server admission time. In Kubernetes {{< skew currentVersion >}}, the allowed values for the `pod.spec.os.name` are `windows` and `linux`.
 - `ImmutableEphemeralVolumes`: Allows for marking individual Secrets and ConfigMaps as
  immutable for better safety and performance.
 - `InTreePluginAWSUnregister`: Stops registering the aws-ebs in-tree plugin in kubelet
@@ -792,6 +829,13 @@ Each feature gate is designed for enabling/disabling a specific feature:
  Initializers admission plugin.
 - `IPv6DualStack`: Enable [dual stack](/docs/concepts/services-networking/dual-stack/)
  support for IPv6.
 - `JobMutableNodeSchedulingDirectives`: Allows updating node scheduling directives in
  the pod template of [Job](/docs/concepts/workloads/controllers/job).
 - `JobReadyPods`: Enables tracking the number of Pods that have a `Ready`
  [condition](/docs/concepts/workloads/pods/pod-lifecycle/#pod-conditions).
  The count of `Ready` pods is recorded in the
  [status](/docs/reference/kubernetes-api/workload-resources/job-v1/#JobStatus)
  of a [Job](/docs/concepts/workloads/controllers/job) status.
 - `JobTrackingWithFinalizers`: Enables tracking [Job](/docs/concepts/workloads/controllers/job)
  completions without relying on Pods remaining in the cluster indefinitely.
  The Job controller uses Pod finalizers and a field in the Job status to keep
@@ -851,6 +895,8 @@ Each feature gate is designed for enabling/disabling a specific feature:
   feature which allows users to influence ReplicaSet downscaling order.
 - `PersistentLocalVolumes`: Enable the usage of `local` volume type in Pods.
  Pod affinity has to be specified if requesting a `local` volume.
 - `PodAndContainerStatsFromCRI`: Configure the kubelet to gather container and pod stats from the CRI container runtime
   rather than gathering them from cAdvisor.
 - `PodDisruptionBudget`: Enable the [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/) feature.
 - `PodAffinityNamespaceSelector`: Enable the [Pod Affinity Namespace Selector](/docs/concepts/scheduling-eviction/assign-pod-node/#namespace-selector)
  and [CrossNamespacePodAffinity](/docs/concepts/policy/resource-quotas/#cross-namespace-pod-affinity-quota) quota scope features.
@@ -880,6 +926,10 @@ Each feature gate is designed for enabling/disabling a specific feature:
  (memory only for now).
 - `ReadWriteOncePod`: Enables the usage of `ReadWriteOncePod` PersistentVolume
  access mode.
 - `RecoverVolumeExpansionFailure`: Enables users to edit their PVCs to smaller sizes so as they can recover from previously issued
  volume expansion failures. See
  [Recovering from Failure when Expanding Volumes](/docs/concepts/storage/persistent-volumes/#recovering-from-failure-when-expanding-volumes)
  for more details.
 - `RemainingItemCount`: Allow the API servers to show a count of remaining
  items in the response to a
  [chunking list request](/docs/reference/using-api/api-concepts/#retrieving-large-results-sets-in-chunks).
@@ -279,6 +279,19 @@ be specified per rule in which case the union of both are omitted.</td>
 </tr>
 <tr><td><code>omitManagedFields</code><br/>
 <code>bool</code>
 </td>
 <td>
   OmitManagedFields indicates whether to omit the managed fields of the request
 and response bodies from being written to the API audit log.
 This is used as a global default - a value of 'true' will omit the managed fileds,
 otherwise the managed fields will be included in the API audit log.
 Note that this can also be specified per rule in which case the value specified
 in a rule will override the global default.</td>
 </tr>
 </tbody>
 </table>
@@ -594,6 +607,21 @@ An empty list means no restrictions will apply.</td>
 </tr>
 <tr><td><code>omitManagedFields</code><br/>
 <code>bool</code>
 </td>
 <td>
   OmitManagedFields indicates whether to omit the managed fields of the request
 and response bodies from being written to the API audit log.
 - a value of 'true' will drop the managed fields from the API audit log
 - a value of 'false' indicates that the managed fileds should be included
  in the API audit log
 Note that the value, if specified, in this rule will override the global default
 If a value is not specified then the global default specified in
 Policy.OmitManagedFields will stand.</td>
 </tr>
 </tbody>
 </table>
@@ -1,53 +1,20 @@
 ---
-title: kube-apiserver Configuration (v1alpha1)
+title: kube-apiserver Configuration (v1beta1)
 content_type: tool-reference
-package: apiserver.k8s.io/v1alpha1
+package: apiserver.k8s.io/v1beta1
 auto_generated: true
 ---
-Package v1alpha1 is the v1alpha1 version of the API.
+Package v1beta1 is the v1beta1 version of the API.
 ## Resource Types 
- [AdmissionConfiguration](#apiserver-k8s-io-v1alpha1-AdmissionConfiguration)
+- [EgressSelectorConfiguration](#apiserver-k8s-io-v1beta1-EgressSelectorConfiguration)
 - [EgressSelectorConfiguration](#apiserver-k8s-io-v1alpha1-EgressSelectorConfiguration)
 - [TracingConfiguration](#apiserver-k8s-io-v1alpha1-TracingConfiguration)
-## `AdmissionConfiguration`     {#apiserver-k8s-io-v1alpha1-AdmissionConfiguration}
+## `EgressSelectorConfiguration`     {#apiserver-k8s-io-v1beta1-EgressSelectorConfiguration}
 AdmissionConfiguration provides versioned configuration for admission controllers.
 <table class="table">
 <thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
 <tbody>
 <tr><td><code>apiVersion</code><br/>string</td><td><code>apiserver.k8s.io/v1alpha1</code></td></tr>
 <tr><td><code>kind</code><br/>string</td><td><code>AdmissionConfiguration</code></td></tr>
 <tr><td><code>plugins</code><br/>
 <a href="#apiserver-k8s-io-v1alpha1-AdmissionPluginConfiguration"><code>[]AdmissionPluginConfiguration</code></a>
 </td>
 <td>
   Plugins allows specifying a configuration per admission control plugin.</td>
 </tr>
 </tbody>
 </table>
 ## `EgressSelectorConfiguration`     {#apiserver-k8s-io-v1alpha1-EgressSelectorConfiguration}
@@ -59,14 +26,14 @@ EgressSelectorConfiguration provides versioned configuration for egress selector
 <thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
 <tbody>
-<tr><td><code>apiVersion</code><br/>string</td><td><code>apiserver.k8s.io/v1alpha1</code></td></tr>
+<tr><td><code>apiVersion</code><br/>string</td><td><code>apiserver.k8s.io/v1beta1</code></td></tr>
 <tr><td><code>kind</code><br/>string</td><td><code>EgressSelectorConfiguration</code></td></tr>
 <tr><td><code>egressSelections</code> <B>[Required]</B><br/>
-<a href="#apiserver-k8s-io-v1alpha1-EgressSelection"><code>[]EgressSelection</code></a>
+<a href="#apiserver-k8s-io-v1beta1-EgressSelection"><code>[]EgressSelection</code></a>
 </td>
 <td>
   connectionServices contains a list of egress selection client configurations</td>
@@ -78,108 +45,14 @@ EgressSelectorConfiguration provides versioned configuration for egress selector
-## `TracingConfiguration`     {#apiserver-k8s-io-v1alpha1-TracingConfiguration}
+## `Connection`     {#apiserver-k8s-io-v1beta1-Connection}
 TracingConfiguration provides versioned configuration for tracing clients.
 <table class="table">
 <thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
 <tbody>
 <tr><td><code>apiVersion</code><br/>string</td><td><code>apiserver.k8s.io/v1alpha1</code></td></tr>
 <tr><td><code>kind</code><br/>string</td><td><code>TracingConfiguration</code></td></tr>
 <tr><td><code>endpoint</code><br/>
 <code>string</code>
 </td>
 <td>
   Endpoint of the collector that's running on the control-plane node.
 The APIServer uses the egressType ControlPlane when sending data to the collector.
 The syntax is defined in https://github.com/grpc/grpc/blob/master/doc/naming.md.
 Defaults to the otlpgrpc default, localhost:4317
 The connection is insecure, and does not support TLS.</td>
 </tr>
 <tr><td><code>samplingRatePerMillion</code><br/>
 <code>int32</code>
 </td>
 <td>
   SamplingRatePerMillion is the number of samples to collect per million spans.
 Defaults to 0.</td>
 </tr>
 </tbody>
 </table>
 ## `AdmissionPluginConfiguration`     {#apiserver-k8s-io-v1alpha1-AdmissionPluginConfiguration}
 **Appears in:**
- [AdmissionConfiguration](#apiserver-k8s-io-v1alpha1-AdmissionConfiguration)
+- [EgressSelection](#apiserver-k8s-io-v1beta1-EgressSelection)
 AdmissionPluginConfiguration provides the configuration for a single plug-in.
 <table class="table">
 <thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
 <tbody>
 <tr><td><code>name</code> <B>[Required]</B><br/>
 <code>string</code>
 </td>
 <td>
   Name is the name of the admission controller.
 It must match the registered admission plugin name.</td>
 </tr>
 <tr><td><code>path</code><br/>
 <code>string</code>
 </td>
 <td>
   Path is the path to a configuration file that contains the plugin's
 configuration</td>
 </tr>
 <tr><td><code>configuration</code><br/>
 <a href="https://godoc.org/k8s.io/apimachinery/pkg/runtime#Unknown"><code>k8s.io/apimachinery/pkg/runtime.Unknown</code></a>
 </td>
 <td>
   Configuration is an embedded configuration object to be used as the plugin's
 configuration. If present, it will be used instead of the path to the configuration file.</td>
 </tr>
 </tbody>
 </table>
 ## `Connection`     {#apiserver-k8s-io-v1alpha1-Connection}
 **Appears in:**
 - [EgressSelection](#apiserver-k8s-io-v1alpha1-EgressSelection)
 Connection provides the configuration for a single egress selection client.
@@ -191,7 +64,7 @@ Connection provides the configuration for a single egress selection client.
 <tr><td><code>proxyProtocol</code> <B>[Required]</B><br/>
-<a href="#apiserver-k8s-io-v1alpha1-ProtocolType"><code>ProtocolType</code></a>
+<a href="#apiserver-k8s-io-v1beta1-ProtocolType"><code>ProtocolType</code></a>
 </td>
 <td>
   Protocol is the protocol used to connect from client to the konnectivity server.</td>
@@ -199,7 +72,7 @@ Connection provides the configuration for a single egress selection client.
 <tr><td><code>transport</code><br/>
-<a href="#apiserver-k8s-io-v1alpha1-Transport"><code>Transport</code></a>
+<a href="#apiserver-k8s-io-v1beta1-Transport"><code>Transport</code></a>
 </td>
 <td>
   Transport defines the transport configurations we use to dial to the konnectivity server.
@@ -212,14 +85,14 @@ This is required if ProxyProtocol is HTTPConnect or GRPC.</td>
-## `EgressSelection`     {#apiserver-k8s-io-v1alpha1-EgressSelection}
+## `EgressSelection`     {#apiserver-k8s-io-v1beta1-EgressSelection}
 **Appears in:**
- [EgressSelectorConfiguration](#apiserver-k8s-io-v1alpha1-EgressSelectorConfiguration)
+- [EgressSelectorConfiguration](#apiserver-k8s-io-v1beta1-EgressSelectorConfiguration)
 EgressSelection provides the configuration for a single egress selection client.
@@ -241,7 +114,7 @@ The "master" egress selector is deprecated in favor of "controlplane"</td>
 <tr><td><code>connection</code> <B>[Required]</B><br/>
-<a href="#apiserver-k8s-io-v1alpha1-Connection"><code>Connection</code></a>
+<a href="#apiserver-k8s-io-v1beta1-Connection"><code>Connection</code></a>
 </td>
 <td>
   connection is the exact information used to configure the egress selection</td>
@@ -253,14 +126,14 @@ The "master" egress selector is deprecated in favor of "controlplane"</td>
-## `ProtocolType`     {#apiserver-k8s-io-v1alpha1-ProtocolType}
+## `ProtocolType`     {#apiserver-k8s-io-v1beta1-ProtocolType}
 (Alias of `string`)
 **Appears in:**
- [Connection](#apiserver-k8s-io-v1alpha1-Connection)
+- [Connection](#apiserver-k8s-io-v1beta1-Connection)
 ProtocolType is a set of valid values for Connection.ProtocolType
@@ -269,14 +142,14 @@ ProtocolType is a set of valid values for Connection.ProtocolType
-## `TCPTransport`     {#apiserver-k8s-io-v1alpha1-TCPTransport}
+## `TCPTransport`     {#apiserver-k8s-io-v1beta1-TCPTransport}
 **Appears in:**
- [Transport](#apiserver-k8s-io-v1alpha1-Transport)
+- [Transport](#apiserver-k8s-io-v1beta1-Transport)
 TCPTransport provides the information to connect to konnectivity server via TCP
@@ -297,7 +170,7 @@ As an example it might be "https://127.0.0.1:8131"</td>
 <tr><td><code>tlsConfig</code><br/>
-<a href="#apiserver-k8s-io-v1alpha1-TLSConfig"><code>TLSConfig</code></a>
+<a href="#apiserver-k8s-io-v1beta1-TLSConfig"><code>TLSConfig</code></a>
 </td>
 <td>
   TLSConfig is the config needed to use TLS when connecting to konnectivity server</td>
@@ -309,14 +182,14 @@ As an example it might be "https://127.0.0.1:8131"</td>
-## `TLSConfig`     {#apiserver-k8s-io-v1alpha1-TLSConfig}
+## `TLSConfig`     {#apiserver-k8s-io-v1beta1-TLSConfig}
 **Appears in:**
- [TCPTransport](#apiserver-k8s-io-v1alpha1-TCPTransport)
+- [TCPTransport](#apiserver-k8s-io-v1beta1-TCPTransport)
 TLSConfig provides the authentication information to connect to konnectivity server
@@ -363,14 +236,14 @@ Must be configured if TCPTransport.URL is prefixed with https://</td>
-## `Transport`     {#apiserver-k8s-io-v1alpha1-Transport}
+## `Transport`     {#apiserver-k8s-io-v1beta1-Transport}
 **Appears in:**
- [Connection](#apiserver-k8s-io-v1alpha1-Connection)
+- [Connection](#apiserver-k8s-io-v1beta1-Connection)
 Transport defines the transport configurations we use to dial to the konnectivity server
@@ -382,7 +255,7 @@ Transport defines the transport configurations we use to dial to the konnectivit
 <tr><td><code>tcp</code><br/>
-<a href="#apiserver-k8s-io-v1alpha1-TCPTransport"><code>TCPTransport</code></a>
+<a href="#apiserver-k8s-io-v1beta1-TCPTransport"><code>TCPTransport</code></a>
 </td>
 <td>
   TCP is the TCP configuration for communicating with the konnectivity server via TCP
@@ -392,7 +265,7 @@ Requires at least one of TCP or UDS to be set</td>
 <tr><td><code>uds</code><br/>
-<a href="#apiserver-k8s-io-v1alpha1-UDSTransport"><code>UDSTransport</code></a>
+<a href="#apiserver-k8s-io-v1beta1-UDSTransport"><code>UDSTransport</code></a>
 </td>
 <td>
   UDS is the UDS configuration for communicating with the konnectivity server via UDS
@@ -405,14 +278,14 @@ Requires at least one of TCP or UDS to be set</td>
-## `UDSTransport`     {#apiserver-k8s-io-v1alpha1-UDSTransport}
+## `UDSTransport`     {#apiserver-k8s-io-v1beta1-UDSTransport}
 **Appears in:**
- [Transport](#apiserver-k8s-io-v1alpha1-Transport)
+- [Transport](#apiserver-k8s-io-v1beta1-Transport)
 UDSTransport provides the information to connect to konnectivity server via UDS
@@ -548,6 +548,8 @@ this always falls back to the userspace proxy.
 - [KubeSchedulerConfiguration](#kubescheduler-config-k8s-io-v1beta2-KubeSchedulerConfiguration)
 - [KubeSchedulerConfiguration](#kubescheduler-config-k8s-io-v1beta3-KubeSchedulerConfiguration)
 - [GenericControllerManagerConfiguration](#controllermanager-config-k8s-io-v1alpha1-GenericControllerManagerConfiguration)
@@ -611,6 +613,8 @@ client.</td>
 **Appears in:**
 - [KubeSchedulerConfiguration](#kubescheduler-config-k8s-io-v1beta3-KubeSchedulerConfiguration)
 - [KubeSchedulerConfiguration](#kubescheduler-config-k8s-io-v1beta2-KubeSchedulerConfiguration)
 - [GenericControllerManagerConfiguration](#controllermanager-config-k8s-io-v1alpha1-GenericControllerManagerConfiguration)
@@ -641,6 +645,75 @@ enableProfiling is true.</td>
 </tr>
 </tbody>
 </table>
 ## `FormatOptions`     {#FormatOptions}
 **Appears in:**
 - [LoggingConfiguration](#LoggingConfiguration)
 FormatOptions contains options for the different logging formats.
 <table class="table">
 <thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
 <tbody>
 <tr><td><code>json</code> <B>[Required]</B><br/>
 <a href="#JSONOptions"><code>JSONOptions</code></a>
 </td>
 <td>
   [Experimental] JSON contains options for logging format "json".</td>
 </tr>
 </tbody>
 </table>
 ## `JSONOptions`     {#JSONOptions}
 **Appears in:**
 - [FormatOptions](#FormatOptions)
 JSONOptions contains options for logging format "json".
 <table class="table">
 <thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
 <tbody>
 <tr><td><code>splitStream</code> <B>[Required]</B><br/>
 <code>bool</code>
 </td>
 <td>
   [Experimental] SplitStream redirects error messages to stderr while
 info messages go to stdout, with buffering. The default is to write
 both to stdout, without buffering.</td>
 </tr>
 <tr><td><code>infoBufferSize</code> <B>[Required]</B><br/>
 <code>k8s.io/apimachinery/pkg/api/resource.QuantityValue</code>
 </td>
 <td>
   [Experimental] InfoBufferSize sets the size of the info stream when
 using split streams. The default is zero, which disables buffering.</td>
 </tr>
 </tbody>
 </table>
@@ -653,6 +726,8 @@ enableProfiling is true.</td>
 - [KubeSchedulerConfiguration](#kubescheduler-config-k8s-io-v1beta2-KubeSchedulerConfiguration)
 - [KubeSchedulerConfiguration](#kubescheduler-config-k8s-io-v1beta3-KubeSchedulerConfiguration)
 - [GenericControllerManagerConfiguration](#controllermanager-config-k8s-io-v1alpha1-GenericControllerManagerConfiguration)
@@ -767,6 +842,35 @@ default value of format is `text`</td>
 </tr>
 <tr><td><code>flushFrequency</code> <B>[Required]</B><br/>
 <a href="https://godoc.org/time#Duration"><code>time.Duration</code></a>
 </td>
 <td>
   Maximum number of seconds between log flushes. Ignored if the
 selected logging backend writes log messages without buffering.</td>
 </tr>
 <tr><td><code>verbosity</code> <B>[Required]</B><br/>
 <code>uint32</code>
 </td>
 <td>
   Verbosity is the threshold that determines which log messages are
 logged. Default is zero which logs only the most important
 messages. Higher values enable additional messages. Error messages
 are always logged.</td>
 </tr>
 <tr><td><code>vmodule</code> <B>[Required]</B><br/>
 <a href="#VModuleConfiguration"><code>VModuleConfiguration</code></a>
 </td>
 <td>
   VModule overrides the verbosity threshold for individual files.
 Only supported for "text" log format.</td>
 </tr>
 <tr><td><code>sanitization</code> <B>[Required]</B><br/>
 <code>bool</code>
 </td>
@@ -776,5 +880,30 @@ Runtime log sanitization may introduce significant computation overhead and ther
 </tr>
 <tr><td><code>options</code> <B>[Required]</B><br/>
 <a href="#FormatOptions"><code>FormatOptions</code></a>
 </td>
 <td>
   [Experimental] Options holds additional parameters that are specific
 to the different logging formats. Only the options for the selected
 format get used, but all of them get validated.</td>
 </tr>
 </tbody>
 </table>
 ## `VModuleConfiguration`     {#VModuleConfiguration}
 (Alias of `[]k8s.io/component-base/config/v1alpha1.VModuleItem`)
 **Appears in:**
 - [LoggingConfiguration](#LoggingConfiguration)
 VModuleConfiguration is a collection of individual file names or patterns
 and the corresponding verbosity threshold.
@@ -89,7 +89,7 @@ of the predicates after it finds one predicate that failed.</td>
 **Appears in:**
- [Extender](#kubescheduler-config-k8s-io-v1beta2-Extender)
+- [Extender](#kubescheduler-config-k8s-io-v1beta1-Extender)
 - [LegacyExtender](#kubescheduler-config-k8s-io-v1-LegacyExtender)
@@ -132,7 +132,7 @@ resource when applying predicates.</td>
 **Appears in:**
- [Extender](#kubescheduler-config-k8s-io-v1beta2-Extender)
+- [Extender](#kubescheduler-config-k8s-io-v1beta1-Extender)
 - [LegacyExtender](#kubescheduler-config-k8s-io-v1-LegacyExtender)
@@ -4,59 +4,58 @@ content_type: tool-reference
 package: kubeadm.k8s.io/v1beta3
 auto_generated: true
 ---
 ## Overview
 Package v1beta3 defines the v1beta3 version of the kubeadm configuration file format.
 This version improves on the v1beta2 format by fixing some minor issues and adding a few new fields.
 A list of changes since v1beta2:
- The deprecated `ClusterConfiguration.useHyperKubeImage` field has been removed.
+- The deprecated "ClusterConfiguration.useHyperKubeImage" field has been removed.
  Kubeadm no longer supports the hyperkube image.
- The `ClusterConfiguration.dns.type` field has been removed since CoreDNS is the only supported
+- The "ClusterConfiguration.DNS.Type" field has been removed since CoreDNS is the only supported
  DNS server type by kubeadm.
 - Include "datapolicy" tags on the fields that hold secrets.
  This would result in the field values to be omitted when API structures are printed with klog.
- Add `InitConfiguration.skipPhases`, `JoinConfiguration.skipPhases` to allow skipping
+- Add "InitConfiguration.SkipPhases", "JoinConfiguration.SkipPhases" to allow skipping
  a list of phases during kubeadm init/join command execution.
- Add `InitConfiguration.nodeRegistration.imagePullPolicy" and
+- Add "InitConfiguration.NodeRegistration.ImagePullPolicy" and "JoinConfiguration.NodeRegistration.ImagePullPolicy"
-  `JoinConfiguration.nodeRegistration.imagePullPolicy` to allow specifying
+  to allow specifying the images pull policy during kubeadm "init" and "join".
-  the images pull policy during kubeadm "init" and "join". The value must be
+  The value must be one of "Always", "Never" or "IfNotPresent".
-  one of "Always", "Never" or "IfNotPresent". "IfNotPresent" is the default,
+  "IfNotPresent" is the default, which has been the existing behavior prior to this addition.
-  which has been the existing behavior prior to this addition.
+- Add "InitConfiguration.Patches.Directory", "JoinConfiguration.Patches.Directory" to allow
- Add `InitConfiguration.patches.directory`, `JoinConfiguration.patches.directory`
+  the user to configure a directory from which to take patches for components deployed by kubeadm.
-  to allow the user to configure a directory from which to take patches for
+- Move the BootstrapToken&lowast; API and related utilities out of the "kubeadm" API group to a new group
-  components deployed by kubeadm.
+  "bootstraptoken". The kubeadm API version v1beta3 no longer contains the BootstrapToken&lowast; structures.
 - Move the `BootstrapToken&lowast;` API and related utilities out of the "kubeadm" API group
  to a new group "bootstraptoken". The kubeadm API version v1beta3 no longer contains
  the `BootstrapToken&lowast;` structures.
-## Migration from old kubeadm config versions
+Migration from old kubeadm config versions
- kubeadm v1.15.x and newer can be used to migrate from the v1beta1 to v1beta2.
+- kubeadm v1.15.x and newer can be used to migrate from v1beta1 to v1beta2.
- kubeadm v1.22.x no longer supports v1beta1 and older APIs, but can be used to migrate v1beta2 to v1beta3.
+- kubeadm v1.22.x and newer no longer support v1beta1 and older APIs, but can be used to migrate v1beta2 to v1beta3.
 ## Basics
-The preferred way to configure kubeadm is to pass an YAML configuration file with the --config option. Some of the
+The preferred way to configure kubeadm is to pass an YAML configuration file with the `--config` option. Some of the
 configuration options defined in the kubeadm config file are also available as command line flags, but only
 the most common/simple use case are supported with this approach.
-A kubeadm config file could contain multiple configuration types separated using three dashes (“---”).
+A kubeadm config file could contain multiple configuration types separated using three dashes (`---`).
 kubeadm supports the following configuration types:
 ```yaml
 apiVersion: kubeadm.k8s.io/v1beta3
 kind: InitConfiguration
---
+
 apiVersion: kubeadm.k8s.io/v1beta3
 kind: ClusterConfiguration
---
+
 apiVersion: kubelet.config.k8s.io/v1beta1
 kind: KubeletConfiguration
---
+
 apiVersion: kubeproxy.config.k8s.io/v1alpha1
 kind: KubeProxyConfiguration
---
+
 apiVersion: kubeadm.k8s.io/v1beta3
 kind: JoinConfiguration
 ```
@@ -69,11 +68,12 @@ kubeadm config print join-defaults
 ```
 The list of configuration types that must be included in a configuration file depends by the action you are
-performing (init or join) and by the configuration options you are going to use (defaults or advanced customization).
+performing (`init` or `join`) and by the configuration options you are going to use (defaults or advanced
 customization).
 If some configuration types are not provided, or provided only partially, kubeadm will use default values; defaults
 provided by kubeadm includes also enforcing consistency of values across components when required (e.g.
-cluster-cidr flag on controller manager and clusterCIDR on kube-proxy).
+`--cluster-cidr` flag on controller manager and `clusterCIDR` on kube-proxy).
 Users are always allowed to override default values, with the only exception of a small subset of setting with
 relevance for security (e.g. enforce authorization-mode Node and RBAC on api server)
@@ -97,8 +97,8 @@ nodeRegistration:
 ```
 The InitConfiguration type should be used to configure runtime settings, that in case of kubeadm init
-are the configuration of the bootstrap token and all the setting which are specific to the node where kubeadm
+are the configuration of the bootstrap token and all the setting which are specific to the node where
-is executed, including:
+kubeadm is executed, including:
 - NodeRegistration, that holds fields that relate to registering the new node to the cluster;
  use it to customize the node name, the CRI socket to use or any other settings that should apply to this
@@ -107,7 +107,7 @@ is executed, including:
 - LocalAPIEndpoint, that represents the endpoint of the instance of the API server to be deployed on this node;
  use it e.g. to customize the API server advertise address.
-  ```yaml
+  ```
  apiVersion: kubeadm.k8s.io/v1beta3
  kind: ClusterConfiguration
  networking:
@@ -126,9 +126,11 @@ The ClusterConfiguration type should be used to configure cluster-wide settings,
 including settings for:
 - Networking, that holds configuration for the networking topology of the cluster; use it e.g. to customize
-  pod subnet or services subnet.
+  Pod subnet or services subnet.
 - Etcd configurations; use it e.g. to customize the local etcd or to configure the API server
  for using an external etcd cluster.
 - kube-apiserver, kube-scheduler, kube-controller-manager configurations; use it to customize control-plane
  components by adding customized setting or overriding kubeadm default settings.
@@ -138,35 +140,36 @@ including settings for:
    ...
  ```
-The KubeProxyConfiguration type should be used to change the configuration passed to kube-proxy instances deployed
+The KubeProxyConfiguration type should be used to change the configuration passed to kube-proxy instances
-in the cluster. If this object is not provided or provided only partially, kubeadm applies defaults.
+deployed in the cluster. If this object is not provided or provided only partially, kubeadm applies defaults.
-See https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/ or https://godoc.org/k8s.io/kube-proxy/config/v1alpha1#KubeProxyConfiguration
+See https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/ or
-for kube proxy official documentation.
+https://godoc.org/k8s.io/kube-proxy/config/v1alpha1#KubeProxyConfiguration
 for kube-proxy official documentation.
 ```yaml
 apiVersion: kubelet.config.k8s.io/v1beta1
 kind: KubeletConfiguration
-...
+  ...
 ```
 The KubeletConfiguration type should be used to change the configurations that will be passed to all kubelet instances
 deployed in the cluster. If this object is not provided or provided only partially, kubeadm applies defaults.
-See https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/ or https://godoc.org/k8s.io/kubelet/config/v1beta1#KubeletConfiguration
+See https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/ or
 https://godoc.org/k8s.io/kubelet/config/v1beta1#KubeletConfiguration
 for kubelet official documentation.
 Here is a fully populated example of a single YAML file containing multiple
 configuration types to be used during a `kubeadm init` run.
 ```yaml
 apiVersion: kubeadm.k8s.io/v1beta3
 kind: InitConfiguration
 bootstrapTokens:
-  - token: "9a08jv.c0izixklcxtmnze7"
+- token: "9a08jv.c0izixklcxtmnze7"
  description: "kubeadm bootstrap token"
  ttl: "24h"
-  - token: "783bde.3f89s0fje9f38fhf"
+- token: "783bde.3f89s0fje9f38fhf"
  description: "another bootstrap token"
  usages:
  - authentication
@@ -182,15 +185,15 @@ nodeRegistration:
    effect: "NoSchedule"
  kubeletExtraArgs:
    v: 4
-  ignorePreflightErrors:
+ignorePreflightErrors:
-    - IsPrivilegedUser
+- IsPrivilegedUser
   imagePullPolicy: "IfNotPresent"
 localAPIEndpoint:
  advertiseAddress: "10.100.0.1"
  bindPort: 6443
 certificateKey: "e6a2eb8581237ab72a4f494f30285ec12a9694d750b9785706a83bfcbbbd2204"
-skipPhases:
+ skipPhases:
-  - add/kube-proxy
+ - addon/kube-proxy
 ---
 apiVersion: kubeadm.k8s.io/v1beta3
 kind: ClusterConfiguration
@@ -214,10 +217,10 @@ etcd:
    # certFile: "/etcd/kubernetes/pki/etcd/etcd.crt"
    # keyFile: "/etcd/kubernetes/pki/etcd/etcd.key"
 networking:
-  serviceSubnet: "10.96.0.0/12"
+  serviceSubnet: "10.96.0.0/16"
-  podSubnet: "10.100.0.1/24"
+  podSubnet: "10.244.0.0/24"
  dnsDomain: "cluster.local"
-kubernetesVersion: "v1.12.0"
+kubernetesVersion: "v1.21.0"
 controlPlaneEndpoint: "10.100.0.1:6443"
 apiServer:
  extraArgs:
@@ -261,27 +264,26 @@ kind: KubeletConfiguration
 apiVersion: kubeproxy.config.k8s.io/v1alpha1
 kind: KubeProxyConfiguration
 # kube-proxy specific options here
 ```
 ## Kubeadm join configuration types
-When executing kubeadm join with the `--config` option, the JoinConfiguration type should be provided.
+When executing `kubeadm join` with the `--config` option, the JoinConfiguration type should be provided.
 ```yaml
 apiVersion: kubeadm.k8s.io/v1beta3
 kind: JoinConfiguration
-...
+  ...
 ```
-The JoinConfiguration type should be used to configure runtime settings, that in case of kubeadm join
+The JoinConfiguration type should be used to configure runtime settings, that in case of `kubeadm join`
 are the discovery method used for accessing the cluster info and all the setting which are specific
 to the node where kubeadm is executed, including:
 - NodeRegistration, that holds fields that relate to registering the new node to the cluster;
  use it to customize the node name, the CRI socket to use or any other settings that should apply to this
  node only (e.g. the node ip).
- APIEndpoint, that represents the endpoint of the instance of the API server to be eventually
+
-  deployed on this node.
+- APIEndpoint, that represents the endpoint of the instance of the API server to be eventually deployed on this node.
 ## Resource Types 
@@ -315,7 +317,7 @@ ClusterConfiguration contains cluster-wide configuration for a kubeadm cluster
 <a href="#kubeadm-k8s-io-v1beta3-Etcd"><code>Etcd</code></a>
 </td>
 <td>
-   `etcd` holds configuration for etcd.</td>
+   Etcd holds configuration for etcd.</td>
 </tr>
@@ -323,7 +325,7 @@ ClusterConfiguration contains cluster-wide configuration for a kubeadm cluster
 <a href="#kubeadm-k8s-io-v1beta3-Networking"><code>Networking</code></a>
 </td>
 <td>
-   `networking` holds configuration for the networking topology of the cluster.</td>
+   Networking holds configuration for the networking topology of the cluster.</td>
 </tr>
@@ -331,7 +333,7 @@ ClusterConfiguration contains cluster-wide configuration for a kubeadm cluster
 <code>string</code>
 </td>
 <td>
-   `kubernetesVersion` is the target version of the control plane.</td>
+   KubernetesVersion is the target version of the control plane.</td>
 </tr>
@@ -339,18 +341,17 @@ ClusterConfiguration contains cluster-wide configuration for a kubeadm cluster
 <code>string</code>
 </td>
 <td>
-   `controlPlaneEndpoint` sets a stable IP address or DNS name for the control plane; it
+   ControlPlaneEndpoint sets a stable IP address or DNS name for the control plane; it
 can be a valid IP address or a RFC-1123 DNS subdomain, both with optional TCP port.
-In case the `controlPlaneEndpoint` is not specified, the `advertiseAddress` + `bindPort`
+In case the ControlPlaneEndpoint is not specified, the AdvertiseAddress + BindPort
-are used; in case the `controlPlaneEndpoint` is specified but without a TCP port,
+are used; in case the ControlPlaneEndpoint is specified but without a TCP port,
-the `bindPort` of the `localAPIEndpoint` is used.
+the BindPort is used.
 Possible usages are:
-
+e.g. In a cluster with more than one control plane instances, this field should be
- In a cluster with more than one control plane instances, this field should be
+assigned the address of the external load balancer in front of the
-  assigned the address of the external load balancer in front of the
+control plane instances.
-  control plane instances.
+e.g.  in environments with enforced node recycling, the ControlPlaneEndpoint
- In environments with enforced node recycling, the ControlPlaneEndpoint
+could be used for assigning a stable DNS to the control plane.</td>
  could be used for assigning a stable DNS to the control plane.</td>
 </tr>
@@ -358,7 +359,7 @@ Possible usages are:
 <a href="#kubeadm-k8s-io-v1beta3-APIServer"><code>APIServer</code></a>
 </td>
 <td>
-   `apiServer` contains extra settings for the API server.</td>
+   APIServer contains extra settings for the API server control plane component</td>
 </tr>
@@ -366,7 +367,7 @@ Possible usages are:
 <a href="#kubeadm-k8s-io-v1beta3-ControlPlaneComponent"><code>ControlPlaneComponent</code></a>
 </td>
 <td>
-   `controllerManager` contains extra settings for the controller manager.</td>
+   ControllerManager contains extra settings for the controller manager control plane component</td>
 </tr>
@@ -374,7 +375,7 @@ Possible usages are:
 <a href="#kubeadm-k8s-io-v1beta3-ControlPlaneComponent"><code>ControlPlaneComponent</code></a>
 </td>
 <td>
-   `scheduler` contains extra settings for the scheduler.</td>
+   Scheduler contains extra settings for the scheduler control plane component</td>
 </tr>
@@ -382,7 +383,7 @@ Possible usages are:
 <a href="#kubeadm-k8s-io-v1beta3-DNS"><code>DNS</code></a>
 </td>
 <td>
-   `dns` defines the options for the DNS add-on.</td>
+   DNS defines the options for the DNS add-on installed in the cluster.</td>
 </tr>
@@ -390,7 +391,7 @@ Possible usages are:
 <code>string</code>
 </td>
 <td>
-   `certificatesDir` specifies where to store or look for all required certificates.</td>
+   CertificatesDir specifies where to store or look for all required certificates.</td>
 </tr>
@@ -398,11 +399,10 @@ Possible usages are:
 <code>string</code>
 </td>
 <td>
-   `imageRepository` sets the container registry to pull images from.
+   ImageRepository sets the container registry to pull images from.
-If empty, `k8s.gcr.io` will be used by default; in case of kubernetes version is
+If empty, `k8s.gcr.io` will be used by default; in case of kubernetes version is a CI build (kubernetes version starts with `ci/`)
-a CI build (kubernetes version starts with `ci/` or `ci-cross/`)
+`gcr.io/k8s-staging-ci-images` will be used as a default for control plane components and for kube-proxy, while `k8s.gcr.io`
-`gcr.io/k8s-staging-ci-images` will be used as a default for control plane
+will be used for all the other images.</td>
 components and for kube-proxy, while `k8s.gcr.io` will be used for all the other images.</td>
 </tr>
@@ -410,7 +410,7 @@ components and for kube-proxy, while `k8s.gcr.io` will be used for all the other
 <code>map[string]bool</code>
 </td>
 <td>
-   Feature gates enabled by the user.</td>
+   FeatureGates enabled by the user.</td>
 </tr>
@@ -418,7 +418,7 @@ components and for kube-proxy, while `k8s.gcr.io` will be used for all the other
 <code>string</code>
 </td>
 <td>
-   The cluster name.</td>
+   The cluster name</td>
 </tr>
@@ -450,8 +450,8 @@ information.
 <a href="#BootstrapToken"><code>[]BootstrapToken</code></a>
 </td>
 <td>
-   `bootstrapTokens` is respected at `kubeadm init` time and describes a set of Bootstrap Tokens to create.
+   BootstrapTokens is respected at `kubeadm init` time and describes a set of Bootstrap Tokens to create.
-This information IS NOT uploaded to the kubeadm cluster configmap, partly because of its sensitive nature.</td>
+This information IS NOT uploaded to the kubeadm cluster configmap, partly because of its sensitive nature</td>
 </tr>
@@ -459,7 +459,7 @@ This information IS NOT uploaded to the kubeadm cluster configmap, partly becaus
 <a href="#kubeadm-k8s-io-v1beta3-NodeRegistrationOptions"><code>NodeRegistrationOptions</code></a>
 </td>
 <td>
-   `nodeRegistration` holds fields that relate to registering the new control-plane node to the cluster</td>
+   NodeRegistration holds fields that relate to registering the new control-plane node to the cluster</td>
 </tr>
@@ -467,7 +467,7 @@ This information IS NOT uploaded to the kubeadm cluster configmap, partly becaus
 <a href="#kubeadm-k8s-io-v1beta3-APIEndpoint"><code>APIEndpoint</code></a>
 </td>
 <td>
-   `localAPIEndpoint` represents the endpoint of the API server instance that's deployed on this control plane node
+   LocalAPIEndpoint represents the endpoint of the API server instance that's deployed on this control plane node
 In HA setups, this differs from ClusterConfiguration.ControlPlaneEndpoint in the sense that ControlPlaneEndpoint
 is the global endpoint for the cluster, which then loadbalances the requests to each individual API server. This
 configuration object lets you customize what IP/DNS name and port the local API server advertises it's accessible
@@ -480,8 +480,8 @@ fails you may set the desired value here.</td>
 <code>string</code>
 </td>
 <td>
-   `certificateKey` sets the key with which certificates and keys are encrypted prior to being uploaded in
+   CertificateKey sets the key with which certificates and keys are encrypted prior to being uploaded in
-a Secret in the cluster during the "uploadcerts" init phase.</td>
+a secret in the cluster during the uploadcerts init phase.</td>
 </tr>
@@ -489,9 +489,9 @@ a Secret in the cluster during the "uploadcerts" init phase.</td>
 <code>[]string</code>
 </td>
 <td>
-   `skipPhases` is a list of phases to skip during command execution.
+   SkipPhases is a list of phases to skip during command execution.
-The list of phases can be obtained with the `kubeadm init --help` command.
+The list of phases can be obtained with the "kubeadm init --help" command.
-The flag `--skip-phases` takes precedence over this field.</td>
+The flag "--skip-phases" takes precedence over this field.</td>
 </tr>
@@ -499,7 +499,7 @@ The flag `--skip-phases` takes precedence over this field.</td>
 <a href="#kubeadm-k8s-io-v1beta3-Patches"><code>Patches</code></a>
 </td>
 <td>
-   `patches` contains options related to applying patches to components deployed by kubeadm during
+   Patches contains options related to applying patches to components deployed by kubeadm during
 "kubeadm init".</td>
 </tr>
@@ -531,8 +531,7 @@ JoinConfiguration contains elements describing a particular node.
 <a href="#kubeadm-k8s-io-v1beta3-NodeRegistrationOptions"><code>NodeRegistrationOptions</code></a>
 </td>
 <td>
-   `nodeRegistration` holds fields that relate to registering the new control-plane
+   NodeRegistration holds fields that relate to registering the new control-plane node to the cluster</td>
 node to the cluster</td>
 </tr>
@@ -540,7 +539,7 @@ node to the cluster</td>
 <code>string</code>
 </td>
 <td>
-   `caCertPath` is the path to the SSL certificate authority used to
+   CACertPath is the path to the SSL certificate authority used to
 secure comunications between node and control-plane.
 Defaults to "/etc/kubernetes/pki/ca.crt".</td>
 </tr>
@@ -550,7 +549,7 @@ Defaults to "/etc/kubernetes/pki/ca.crt".</td>
 <a href="#kubeadm-k8s-io-v1beta3-Discovery"><code>Discovery</code></a>
 </td>
 <td>
-   `discovery` specifies the options for the kubelet to use during the TLS Bootstrap process.</td>
+   Discovery specifies the options for the kubelet to use during the TLS Bootstrap process</td>
 </tr>
@@ -558,8 +557,8 @@ Defaults to "/etc/kubernetes/pki/ca.crt".</td>
 <a href="#kubeadm-k8s-io-v1beta3-JoinControlPlane"><code>JoinControlPlane</code></a>
 </td>
 <td>
-   `controlPlane` defines the additional control plane instance to be deployed on the
+   ControlPlane defines the additional control plane instance to be deployed on the joining node.
-joining node. If nil, no additional control plane instance will be deployed.</td>
+If nil, no additional control plane instance will be deployed.</td>
 </tr>
@@ -567,9 +566,9 @@ joining node. If nil, no additional control plane instance will be deployed.</td
 <code>[]string</code>
 </td>
 <td>
-   `skipPhases` is a list of phases to skip during command execution.
+   SkipPhases is a list of phases to skip during command execution.
-The list of phases can be obtained with the `kubeadm join --help` command.
+The list of phases can be obtained with the "kubeadm join --help" command.
-The flag `--skip-phases` takes precedence over this field.</td>
+The flag "--skip-phases" takes precedence over this field.</td>
 </tr>
@@ -577,8 +576,8 @@ The flag `--skip-phases` takes precedence over this field.</td>
 <a href="#kubeadm-k8s-io-v1beta3-Patches"><code>Patches</code></a>
 </td>
 <td>
-   `patches` contains options related to applying patches to components deployed by kubeadm during
+   Patches contains options related to applying patches to components deployed by kubeadm during
-`kubeadm join`.</td>
+"kubeadm join".</td>
 </tr>
@@ -611,7 +610,7 @@ APIEndpoint struct contains elements of API server instance deployed on a node.
 <code>string</code>
 </td>
 <td>
-   `advertiseAddress` sets the IP address for the API server to advertise.</td>
+   AdvertiseAddress sets the IP address for the API server to advertise.</td>
 </tr>
@@ -619,7 +618,8 @@ APIEndpoint struct contains elements of API server instance deployed on a node.
 <code>int32</code>
 </td>
 <td>
-   `bindPort` sets the secure port for the API Server to bind to. Defaults to 6443.</td>
+   BindPort sets the secure port for the API Server to bind to.
 Defaults to 6443.</td>
 </tr>
@@ -659,7 +659,7 @@ APIServer holds settings necessary for API server deployments in the cluster
 <code>[]string</code>
 </td>
 <td>
-   `certSANs` sets extra Subject Alternative Names for the API Server signing cert.</td>
+   CertSANs sets extra Subject Alternative Names for the API Server signing cert.</td>
 </tr>
@@ -667,7 +667,7 @@ APIServer holds settings necessary for API server deployments in the cluster
 <a href="https://godoc.org/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
 </td>
 <td>
-   `timeoutForControlPlane` controls the timeout that we use for API server to appear</td>
+   TimeoutForControlPlane controls the timeout that we use for API server to appear</td>
 </tr>
@@ -698,7 +698,8 @@ BootstrapTokenDiscovery is used to set the options for bootstrap token based dis
 <code>string</code>
 </td>
 <td>
-   `token` is a token used to validate cluster information fetched from the control-plane.</td>
+   Token is a token used to validate cluster information
 fetched from the control-plane.</td>
 </tr>
@@ -706,8 +707,7 @@ BootstrapTokenDiscovery is used to set the options for bootstrap token based dis
 <code>string</code>
 </td>
 <td>
-   `apiServerEndpoint` is an IP or domain name to the API server from which
+   APIServerEndpoint is an IP or domain name to the API server from which info will be fetched.</td>
 information will be fetched.</td>
 </tr>
@@ -715,13 +715,13 @@ information will be fetched.</td>
 <code>[]string</code>
 </td>
 <td>
-   CACertHashes specifies a set of public key pins to verify when token-based
+   CACertHashes specifies a set of public key pins to verify
-discovery is used. The root CA found during discovery must match one of these
+when token-based discovery is used. The root CA found during discovery
-values. Specifying an empty set disables root CA pinning, which can be unsafe.
+must match one of these values. Specifying an empty set disables root CA
-Each hash is specified as `<type>:<value>`, where the only currently supported
+pinning, which can be unsafe. Each hash is specified as "<type>:<value>",
-type is "sha256". This is a hex-encoded SHA-256 hash of the Subject Public Key
+where the only currently supported type is "sha256". This is a hex-encoded
-Info (SPKI) object in DER-encoded ASN.1. These hashes can be calculated using,
+SHA-256 hash of the Subject Public Key Info (SPKI) object in DER-encoded
-for example, OpenSSL.</td>
+ASN.1. These hashes can be calculated using, for example, OpenSSL.</td>
 </tr>
@@ -729,9 +729,9 @@ for example, OpenSSL.</td>
 <code>bool</code>
 </td>
 <td>
-   `unsafeSkipCAVerification` allows token-based discovery without CA verification
+   UnsafeSkipCAVerification allows token-based discovery
-via `caCertHashes`. This can weaken the security of kubeadm since other nodes
+without CA verification via CACertHashes. This can weaken
-can impersonate the control-plane.</td>
+the security of kubeadm since other nodes can impersonate the control-plane.</td>
 </tr>
@@ -764,9 +764,11 @@ ControlPlaneComponent holds settings common to control plane component of the cl
 <code>map[string]string</code>
 </td>
 <td>
-   `extraArgs` is an extra set of flags to pass to the control plane component.
+   ExtraArgs is an extra set of flags to pass to the control plane component.
 A key in this map is the flag name as it appears on the
-command line except without leading dash(es).</td>
+command line except without leading dash(es).
 TODO: This is temporary and ideally we would like to switch all components to
 use ComponentConfig + ConfigMaps.</td>
 </tr>
@@ -774,7 +776,7 @@ command line except without leading dash(es).</td>
 <a href="#kubeadm-k8s-io-v1beta3-HostPathMount"><code>[]HostPathMount</code></a>
 </td>
 <td>
-   `extraVolumes` is an extra set of host volumes, mounted to the control plane component.</td>
+   ExtraVolumes is an extra set of host volumes, mounted to the control plane component.</td>
 </tr>
@@ -805,7 +807,7 @@ DNS defines the DNS addon that should be used in the cluster
 <a href="#kubeadm-k8s-io-v1beta3-ImageMeta"><code>ImageMeta</code></a>
 </td>
 <td>(Members of <code>ImageMeta</code> are embedded into this type.)
-   `imageMeta` allows to customize the image used for the DNS component.</td>
+   ImageMeta allows to customize the image used for the DNS component</td>
 </tr>
@@ -848,8 +850,8 @@ Discovery specifies the options for the kubelet to use during the TLS Bootstrap
 <a href="#kubeadm-k8s-io-v1beta3-BootstrapTokenDiscovery"><code>BootstrapTokenDiscovery</code></a>
 </td>
 <td>
-   `bootstrapToken` is used to set the options for bootstrap token based discovery.
+   BootstrapToken is used to set the options for bootstrap token based discovery
-`bootstrapToken` and `file` are mutually exclusive.</td>
+BootstrapToken and File are mutually exclusive</td>
 </tr>
@@ -857,8 +859,8 @@ Discovery specifies the options for the kubelet to use during the TLS Bootstrap
 <a href="#kubeadm-k8s-io-v1beta3-FileDiscovery"><code>FileDiscovery</code></a>
 </td>
 <td>
-   `file` specifies a file or URL to a kubeconfig file from which to load cluster information.
+   File is used to specify a file or URL to a kubeconfig file from which to load cluster information
-`bootstrapToken` and `file` are mutually exclusive.</td>
+BootstrapToken and File are mutually exclusive</td>
 </tr>
@@ -866,11 +868,9 @@ Discovery specifies the options for the kubelet to use during the TLS Bootstrap
 <code>string</code>
 </td>
 <td>
-   `tlsBootstrapToken` is a token used for TLS bootstrapping.
+   TLSBootstrapToken is a token used for TLS bootstrapping.
-If `bootstrapToken` is set, this field is defaulted to `bootstrapToken.token`,
+If .BootstrapToken is set, this field is defaulted to .BootstrapToken.Token, but can be overridden.
-but can be overridden.
+If .File is set, this field &lowast;&lowast;must be set&lowast;&lowast; in case the KubeConfigFile does not contain any other authentication information</td>
 If `file` is set, this field &lowast;&lowast;must be set&lowast;&lowast; in case the KubeConfigFile does
 not contain any other authentication information</td>
 </tr>
@@ -878,7 +878,7 @@ not contain any other authentication information</td>
 <a href="https://godoc.org/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
 </td>
 <td>
-   `timeout` modifies the discovery timeout.</td>
+   Timeout modifies the discovery timeout</td>
 </tr>
@@ -909,8 +909,8 @@ Etcd contains elements describing Etcd configuration.
 <a href="#kubeadm-k8s-io-v1beta3-LocalEtcd"><code>LocalEtcd</code></a>
 </td>
 <td>
-   `local` provides configuration knobs for configuring the local etcd instance.
+   Local provides configuration knobs for configuring the local etcd instance
-`local` and `external` are mutually exclusive.</td>
+Local and External are mutually exclusive</td>
 </tr>
@@ -918,8 +918,8 @@ Etcd contains elements describing Etcd configuration.
 <a href="#kubeadm-k8s-io-v1beta3-ExternalEtcd"><code>ExternalEtcd</code></a>
 </td>
 <td>
-   `external` describes how to connect to an external etcd cluster.
+   External describes how to connect to an external etcd cluster
-`local` and `external` are mutually exclusive.</td>
+Local and External are mutually exclusive</td>
 </tr>
@@ -951,7 +951,7 @@ Kubeadm has no knowledge of where certificate files live and they must be suppli
 <code>[]string</code>
 </td>
 <td>
-   `endpoints` are endpoints of etcd members. This field is required.</td>
+   Endpoints of etcd members. Required for ExternalEtcd.</td>
 </tr>
@@ -959,7 +959,7 @@ Kubeadm has no knowledge of where certificate files live and they must be suppli
 <code>string</code>
 </td>
 <td>
-   `caFile` is an SSL Certificate Authority file used to secure etcd communication.
+   CAFile is an SSL Certificate Authority file used to secure etcd communication.
 Required if using a TLS connection.</td>
 </tr>
@@ -968,7 +968,7 @@ Required if using a TLS connection.</td>
 <code>string</code>
 </td>
 <td>
-   `certFile` is an SSL certification file used to secure etcd communication.
+   CertFile is an SSL certification file used to secure etcd communication.
 Required if using a TLS connection.</td>
 </tr>
@@ -977,7 +977,7 @@ Required if using a TLS connection.</td>
 <code>string</code>
 </td>
 <td>
-   `keyFile` is an SSL key file used to secure etcd communication.
+   KeyFile is an SSL key file used to secure etcd communication.
 Required if using a TLS connection.</td>
 </tr>
@@ -1009,8 +1009,7 @@ FileDiscovery is used to specify a file or URL to a kubeconfig file from which t
 <code>string</code>
 </td>
 <td>
-   `kubeConfigPath` specifies the actual file path or URL to the kubeconfig file
+   KubeConfigPath is used to specify the actual file path or URL to the kubeconfig file from which to load cluster information</td>
 from which to load cluster information</td>
 </tr>
@@ -1029,7 +1028,8 @@ from which to load cluster information</td>
 - [ControlPlaneComponent](#kubeadm-k8s-io-v1beta3-ControlPlaneComponent)
-HostPathMount contains elements describing volumes that are mounted from the host.
+HostPathMount contains elements describing volumes that are mounted from the
 host.
 <table class="table">
 <thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
@@ -1041,7 +1041,7 @@ HostPathMount contains elements describing volumes that are mounted from the hos
 <code>string</code>
 </td>
 <td>
-   `name` is the volume name inside the Pod template.</td>
+   Name of the volume inside the pod template.</td>
 </tr>
@@ -1049,7 +1049,8 @@ HostPathMount contains elements describing volumes that are mounted from the hos
 <code>string</code>
 </td>
 <td>
-   `hostPath` is the path in the host that will be mounted inside the Pod.</td>
+   HostPath is the path in the host that will be mounted inside
 the pod.</td>
 </tr>
@@ -1057,7 +1058,7 @@ HostPathMount contains elements describing volumes that are mounted from the hos
 <code>string</code>
 </td>
 <td>
-   `mountPath` is the path inside the Pod where the `hostPath` volume is mounted.</td>
+   MountPath is the path inside the pod where hostPath will be mounted.</td>
 </tr>
@@ -1065,7 +1066,7 @@ HostPathMount contains elements describing volumes that are mounted from the hos
 <code>bool</code>
 </td>
 <td>
-   `readOnly` controls write access to the volume.</td>
+   ReadOnly controls write access to the volume</td>
 </tr>
@@ -1073,7 +1074,7 @@ HostPathMount contains elements describing volumes that are mounted from the hos
 <a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.21/#hostpathtype-v1-core"><code>core/v1.HostPathType</code></a>
 </td>
 <td>
-   `pathType` is the type of the `hostPath` volume.</td>
+   PathType is the type of the HostPath.</td>
 </tr>
@@ -1107,8 +1108,8 @@ originated from the Kubernetes/Kubernetes release process
 <code>string</code>
 </td>
 <td>
-   `imageRepository` sets the container registry to pull images from.
+   ImageRepository sets the container registry to pull images from.
-If not set, the ImageRepository defined in ClusterConfiguration will be used instead.</td>
+if not set, the ImageRepository defined in ClusterConfiguration will be used instead.</td>
 </tr>
@@ -1116,9 +1117,8 @@ If not set, the ImageRepository defined in ClusterConfiguration will be used ins
 <code>string</code>
 </td>
 <td>
-   `imageTag` allows to specify a tag for the image.
+   ImageTag allows to specify a tag for the image.
-In case this value is set, kubeadm does not change automatically the
+In case this value is set, kubeadm does not change automatically the version of the above components during upgrades.</td>
 version of the above components during upgrades.</td>
 </tr>
@@ -1149,8 +1149,7 @@ JoinControlPlane contains elements describing an additional control plane instan
 <a href="#kubeadm-k8s-io-v1beta3-APIEndpoint"><code>APIEndpoint</code></a>
 </td>
 <td>
-   `localAPIEndpoint` represents the endpoint of the API server instance to be deployed
+   LocalAPIEndpoint represents the endpoint of the API server instance to be deployed on this node.</td>
 on this node.</td>
 </tr>
@@ -1158,9 +1157,8 @@ on this node.</td>
 <code>string</code>
 </td>
 <td>
-   `certificateKey` is the key that is used for decryption of certificates after they
+   CertificateKey is the key that is used for decryption of certificates after they are downloaded from the secret
-are downloaded from the secret upon joining a new control plane node. The
+upon joining a new control plane node. The corresponding encryption key is in the InitConfiguration.</td>
 corresponding encryption key is in the InitConfiguration.</td>
 </tr>
@@ -1191,7 +1189,7 @@ LocalEtcd describes that kubeadm should run an etcd cluster locally
 <a href="#kubeadm-k8s-io-v1beta3-ImageMeta"><code>ImageMeta</code></a>
 </td>
 <td>(Members of <code>ImageMeta</code> are embedded into this type.)
-   `ImageMeta` allows to customize the container used for etcd.</td>
+   ImageMeta allows to customize the container used for etcd</td>
 </tr>
@@ -1199,7 +1197,7 @@ LocalEtcd describes that kubeadm should run an etcd cluster locally
 <code>string</code>
 </td>
 <td>
-   `dataDir` is the directory etcd will place its data.
+   DataDir is the directory etcd will place its data.
 Defaults to "/var/lib/etcd".</td>
 </tr>
@@ -1208,10 +1206,10 @@ Defaults to "/var/lib/etcd".</td>
 <code>map[string]string</code>
 </td>
 <td>
-   `extraArgs` are extra arguments provided to the etcd binary
+   ExtraArgs are extra arguments provided to the etcd binary
 when run inside a static pod.
-A key in this map is the flag name as it appears on the command line except
+A key in this map is the flag name as it appears on the
-without leading dash(es).</td>
+command line except without leading dash(es).</td>
 </tr>
@@ -1219,7 +1217,7 @@ without leading dash(es).</td>
 <code>[]string</code>
 </td>
 <td>
-   `serverCertSANs` sets extra Subject Alternative Names for the etcd server signing cert.</td>
+   ServerCertSANs sets extra Subject Alternative Names for the etcd server signing cert.</td>
 </tr>
@@ -1227,7 +1225,7 @@ without leading dash(es).</td>
 <code>[]string</code>
 </td>
 <td>
-   `peerCertSANs` sets extra Subject Alternative Names for the etcd peer signing cert.</td>
+   PeerCertSANs sets extra Subject Alternative Names for the etcd peer signing cert.</td>
 </tr>
@@ -1258,7 +1256,7 @@ Networking contains elements describing cluster's networking configuration
 <code>string</code>
 </td>
 <td>
-   `serviceSubnet` is the subnet used by k8s services. Defaults to "10.96.0.0/12".</td>
+   ServiceSubnet is the subnet used by k8s services. Defaults to "10.96.0.0/12".</td>
 </tr>
@@ -1266,7 +1264,7 @@ Networking contains elements describing cluster's networking configuration
 <code>string</code>
 </td>
 <td>
-   `podSubnet` is the subnet used by Pods.</td>
+   PodSubnet is the subnet used by pods.</td>
 </tr>
@@ -1274,7 +1272,7 @@ Networking contains elements describing cluster's networking configuration
 <code>string</code>
 </td>
 <td>
-   `dnsDomain` is the DNS domain used by k8s services. Defaults to "cluster.local".</td>
+   DNSDomain is the dns domain used by k8s services. Defaults to "cluster.local".</td>
 </tr>
@@ -1307,10 +1305,9 @@ NodeRegistrationOptions holds fields that relate to registering a new control-pl
 <code>string</code>
 </td>
 <td>
-   `name` is the `.metadata.name` field of the Node API object that will be created in this
+   Name is the `.Metadata.Name` field of the Node API object that will be created in this `kubeadm init` or `kubeadm join` operation.
-`kubeadm init` or `kubeadm join` operation.
+This field is also used in the CommonName field of the kubelet's client certificate to the API server.
-This field is also used in the `CommonName` field of the kubelet's client certificate to the
+Defaults to the hostname of the node if not provided.</td>
 API server. Defaults to the hostname of the node if not provided.</td>
 </tr>
@@ -1318,8 +1315,7 @@ API server. Defaults to the hostname of the node if not provided.</td>
 <code>string</code>
 </td>
 <td>
-   `criSocket` is used to retrieve container runtime info. This information will be
+   CRISocket is used to retrieve container runtime info. This information will be annotated to the Node API object, for later re-use</td>
 annotated to the Node API object, for later re-use.</td>
 </tr>
@@ -1327,11 +1323,9 @@ annotated to the Node API object, for later re-use.</td>
 <a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.21/#taint-v1-core"><code>[]core/v1.Taint</code></a>
 </td>
 <td>
-   `taints` specifies the taints the Node API object should be registered with. If
+   Taints specifies the taints the Node API object should be registered with. If this field is unset, i.e. nil, in the `kubeadm init` process
-this field is unset, i.e. nil, in the `kubeadm init` process, it will be defaulted
+it will be defaulted to []v1.Taint{'node-role.kubernetes.io/master=""'}. If you don't want to taint your control-plane node, set this field to an
-to `['"node-role.kubernetes.io/master"=""']`. If you don't want to taint your
+empty slice, i.e. `taints: []` in the YAML file. This field is solely used for Node registration.</td>
 control-plane node, set this field to an empty list, i.e. `taints: []` in the YAML
 file. This field is solely used for Node registration.</td>
 </tr>
@@ -1339,13 +1333,11 @@ file. This field is solely used for Node registration.</td>
 <code>map[string]string</code>
 </td>
 <td>
-   `kubeletExtraArgs` passes through extra arguments to the kubelet. The arguments here
+   KubeletExtraArgs passes through extra arguments to the kubelet. The arguments here are passed to the kubelet command line via the environment file
-are passed to the kubelet command line via the environment file kubeadm writes at
+kubeadm writes at runtime for the kubelet to source. This overrides the generic base-level configuration in the kubelet-config-1.X ConfigMap
-runtime for the kubelet to source. This overrides the generic base-level
+Flags have higher priority when parsing. These values are local and specific to the node kubeadm is executing on.
-configuration in the "kubelet-config-1.X" ConfigMap. Flags have higher priority when
+A key in this map is the flag name as it appears on the
-parsing. These values are local and specific to the node kubeadm is executing on.
+command line except without leading dash(es).</td>
 A key in this map is the flag name as it appears on the command line except without
 leading dash(es).</td>
 </tr>
@@ -1353,8 +1345,7 @@ leading dash(es).</td>
 <code>[]string</code>
 </td>
 <td>
-   `ignorePreflightErrors` provides a slice of pre-flight errors to be ignored when
+   IgnorePreflightErrors provides a slice of pre-flight errors to be ignored when the current node is registered.</td>
 the current node is registered.</td>
 </tr>
@@ -1362,11 +1353,9 @@ the current node is registered.</td>
 <a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.21/#pullpolicy-v1-core"><code>core/v1.PullPolicy</code></a>
 </td>
 <td>
-   `imagePullPolicy` specifies the policy for image pulling during `kubeadm init` and
+   ImagePullPolicy specifies the policy for image pulling during kubeadm "init" and "join" operations.
 `kubeadm join` operations.
 The value of this field must be one of "Always", "IfNotPresent" or "Never".
-If this field is unset kubeadm will default it to "IfNotPresent", or pull the required
+If this field is unset kubeadm will default it to "IfNotPresent", or pull the required images if not present on the host.</td>
 images if not present on the host.</td>
 </tr>
@@ -1399,13 +1388,12 @@ Patches contains options related to applying patches to components deployed by k
 <code>string</code>
 </td>
 <td>
-   `directory` is a path to a directory that contains files named
+   Directory is a path to a directory that contains files named "target[suffix][+patchtype].extension".
-`target[suffix][+patchtype].extension`.
+For example, "kube-apiserver0+merge.yaml" or just "etcd.json". "target" can be one of
-For example, `kube-apiserver0+merge.yaml` or just `etcd.json`. `target` can be one of
+"kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd". "patchtype" can be one
-"kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd". `patchtype` can be one
+of "strategic" "merge" or "json" and they match the patch formats supported by kubectl.
-of "strategic", "merge" or "json" and they match the patch formats supported by kubectl.
+The default "patchtype" is "strategic". "extension" must be either "json" or "yaml".
-The default `patchtype` is "strategic". `extension` must be either "json" or "yaml".
+"suffix" is an optional string that can be used to determine which patches are applied
 `suffix` is an optional string that can be used to determine which patches are applied
 first alpha-numerically.</td>
 </tr>
@@ -493,14 +493,13 @@ Default: "5m"</td>
 <code>int32</code>
 </td>
 <td>
-   nodeLeaseDurationSeconds is the duration the Kubelet will set on its corresponding Lease,
+   nodeLeaseDurationSeconds is the duration the Kubelet will set on its corresponding Lease.
-when the NodeLease feature is enabled. This feature provides an indicator of node
+NodeLease provides an indicator of node health by having the Kubelet create and
-health by having the Kubelet create and periodically renew a lease, named after the node,
+periodically renew a lease, named after the node, in the kube-node-lease namespace.
-in the kube-node-lease namespace. If the lease expires, the node can be considered unhealthy.
+If the lease expires, the node can be considered unhealthy.
-The lease is currently renewed every 10s, per KEP-0009. In the future, the lease renewal interval
+The lease is currently renewed every 10s, per KEP-0009. In the future, the lease renewal
-may be set based on the lease duration.
+interval may be set based on the lease duration.
 The field value must be greater than 0.
 Requires the NodeLease feature gate to be enabled.
 If DynamicKubeletConfig (deprecated; default off) is on, when
 dynamically updating this field, consider that
 decreasing the duration may reduce tolerance for issues that temporarily prevent
@@ -514,11 +513,9 @@ Default: 40</td>
 </td>
 <td>
   imageMinimumGCAge is the minimum age for an unused image before it is
-garbage collected.
+garbage collected. If DynamicKubeletConfig (deprecated; default off)
-If DynamicKubeletConfig (deprecated; default off) is on, when
+is on, when dynamically updating this field, consider that  it may trigger or
-dynamically updating this field, consider that
+delay garbage collection, and may change the image overhead on the node.
 it may trigger or delay garbage collection, and may change the image overhead
 on the node.
 Default: "2m"</td>
 </tr>
@@ -693,7 +690,7 @@ Valid values include:
  requested resources;
 - `best-effort`: kubelet will favor pods with NUMA alignment of CPU and device
  resources;
- `none`: kublet has no knowledge of NUMA alignment of a pod's CPU and device resources.
+- `none`: kubelet has no knowledge of NUMA alignment of a pod's CPU and device resources.
 - `single-numa-node`: kubelet only allows pods with a single NUMA alignment
  of CPU and device resources.
@@ -819,6 +816,7 @@ If DynamicKubeletConfig (deprecated; default off) is on, when
 dynamically updating this field, consider that
 changes will only take effect on Pods created after the update. Draining
 the node is recommended before changing this field.
 If set to the empty string, will override the default and effectively disable DNS lookups.
 Default: "/etc/resolv.conf"</td>
 </tr>
@@ -1417,6 +1415,39 @@ Default: "0s"</td>
 </tr>
 <tr><td><code>shutdownGracePeriodByPodPriority</code><br/>
 <a href="#kubelet-config-k8s-io-v1beta1-ShutdownGracePeriodByPodPriority"><code>[]ShutdownGracePeriodByPodPriority</code></a>
 </td>
 <td>
   shutdownGracePeriodByPodPriority specifies the shutdown grace period for Pods based
 on their associated priority class value.
 When a shutdown request is received, the Kubelet will initiate shutdown on all pods
 running on the node with a grace period that depends on the priority of the pod,
 and then wait for all pods to exit.
 Each entry in the array represents the graceful shutdown time a pod with a priority
 class value that lies in the range of that value and the next higher entry in the
 list when the node is shutting down.
 For example, to allow critical pods 10s to shutdown, priority>=10000 pods 20s to
 shutdown, and all remaining pods 30s to shutdown.
 shutdownGracePeriodByPodPriority:
  - priority: 2000000000
    shutdownGracePeriodSeconds: 10
  - priority: 10000
    shutdownGracePeriodSeconds: 20
  - priority: 0
    shutdownGracePeriodSeconds: 30
 The time the Kubelet will wait before exiting will at most be the maximum of all
 shutdownGracePeriodSeconds for each priority class range represented on the node.
 When all pods have exited or reached their grace periods, the Kubelet will release
 the shutdown inhibit lock.
 Requires the GracefulNodeShutdown feature gate to be enabled.
 This configuration must be empty if either ShutdownGracePeriod or ShutdownGracePeriodCriticalPods is set.
 Default: nil</td>
 </tr>
 <tr><td><code>reservedMemory</code><br/>
 <a href="#kubelet-config-k8s-io-v1beta1-MemoryReservation"><code>[]MemoryReservation</code></a>
 </td>
@@ -1485,6 +1516,26 @@ Default: 0.8</td>
 </tr>
 <tr><td><code>registerWithTaints</code><br/>
 <a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.21/#taint-v1-core"><code>[]core/v1.Taint</code></a>
 </td>
 <td>
   registerWithTaints are an array of taints to add to a node object when
 the kubelet registers itself. This only takes effect when registerNode
 is true and upon the initial registration of the node.
 Default: nil</td>
 </tr>
 <tr><td><code>registerNode</code><br/>
 <code>bool</code>
 </td>
 <td>
   registerNode enables automatic registration with the apiserver.
 Default: true</td>
 </tr>
 </tbody>
 </table>
@@ -1881,8 +1932,116 @@ managers (secret, configmap) are discovering object changes.
 ## `ShutdownGracePeriodByPodPriority`     {#kubelet-config-k8s-io-v1beta1-ShutdownGracePeriodByPodPriority}
 **Appears in:**
 - [KubeletConfiguration](#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)
 ShutdownGracePeriodByPodPriority specifies the shutdown grace period for Pods based on their associated priority class value
 <table class="table">
 <thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
 <tbody>
 <tr><td><code>priority</code> <B>[Required]</B><br/>
 <code>int32</code>
 </td>
 <td>
   priority is the priority value associated with the shutdown grace period</td>
 </tr>
 <tr><td><code>shutdownGracePeriodSeconds</code> <B>[Required]</B><br/>
 <code>int64</code>
 </td>
 <td>
   shutdownGracePeriodSeconds is the shutdown grace period in seconds</td>
 </tr>
 </tbody>
 </table>
 ## `FormatOptions`     {#FormatOptions}
 **Appears in:**
 - [LoggingConfiguration](#LoggingConfiguration)
 FormatOptions contains options for the different logging formats.
 <table class="table">
 <thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
 <tbody>
 <tr><td><code>json</code> <B>[Required]</B><br/>
 <a href="#JSONOptions"><code>JSONOptions</code></a>
 </td>
 <td>
   [Experimental] JSON contains options for logging format "json".</td>
 </tr>
 </tbody>
 </table>
 ## `JSONOptions`     {#JSONOptions}
 **Appears in:**
 - [FormatOptions](#FormatOptions)
 JSONOptions contains options for logging format "json".
 <table class="table">
 <thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
 <tbody>
 <tr><td><code>splitStream</code> <B>[Required]</B><br/>
 <code>bool</code>
 </td>
 <td>
   [Experimental] SplitStream redirects error messages to stderr while
 info messages go to stdout, with buffering. The default is to write
 both to stdout, without buffering.</td>
 </tr>
 <tr><td><code>infoBufferSize</code> <B>[Required]</B><br/>
 <code>k8s.io/apimachinery/pkg/api/resource.QuantityValue</code>
 </td>
 <td>
   [Experimental] InfoBufferSize sets the size of the info stream when
 using split streams. The default is zero, which disables buffering.</td>
 </tr>
 </tbody>
 </table>
 ## `LoggingConfiguration`     {#LoggingConfiguration}
@@ -1911,6 +2070,35 @@ default value of format is `text`</td>
 </tr>
 <tr><td><code>flushFrequency</code> <B>[Required]</B><br/>
 <a href="https://godoc.org/time#Duration"><code>time.Duration</code></a>
 </td>
 <td>
   Maximum number of seconds between log flushes. Ignored if the
 selected logging backend writes log messages without buffering.</td>
 </tr>
 <tr><td><code>verbosity</code> <B>[Required]</B><br/>
 <code>uint32</code>
 </td>
 <td>
   Verbosity is the threshold that determines which log messages are
 logged. Default is zero which logs only the most important
 messages. Higher values enable additional messages. Error messages
 are always logged.</td>
 </tr>
 <tr><td><code>vmodule</code> <B>[Required]</B><br/>
 <a href="#VModuleConfiguration"><code>VModuleConfiguration</code></a>
 </td>
 <td>
   VModule overrides the verbosity threshold for individual files.
 Only supported for "text" log format.</td>
 </tr>
 <tr><td><code>sanitization</code> <B>[Required]</B><br/>
 <code>bool</code>
 </td>
@@ -1920,5 +2108,30 @@ Runtime log sanitization may introduce significant computation overhead and ther
 </tr>
 <tr><td><code>options</code> <B>[Required]</B><br/>
 <a href="#FormatOptions"><code>FormatOptions</code></a>
 </td>
 <td>
   [Experimental] Options holds additional parameters that are specific
 to the different logging formats. Only the options for the selected
 format get used, but all of them get validated.</td>
 </tr>
 </tbody>
 </table>
 ## `VModuleConfiguration`     {#VModuleConfiguration}
 (Alias of `[]k8s.io/component-base/config/v1alpha1.VModuleItem`)
 **Appears in:**
 - [LoggingConfiguration](#LoggingConfiguration)
 VModuleConfiguration is a collection of individual file names or patterns
 and the corresponding verbosity threshold.
@@ -0,0 +1,22 @@
 ---
 title: Container Runtime Interface
 id: container-runtime-interface
 date: 2021-11-24
 full_link: /docs/concepts/architecture/cri
 short_description: >
  The main protocol for the communication between the kubelet and Container Runtime.
 aka:
 tags:
  - cri
 ---
 The main protocol for the communication between the kubelet and Container Runtime.
 <!--more-->
 The Kubernetes Container Runtime Interface (CRI) defines the main
 [gRPC](https://grpc.io) protocol for the communication between the
 [cluster components](/docs/concepts/overview/components/#node-components)
 {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} and
 {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}.
@@ -4,14 +4,14 @@ id: flexvolume
 date: 2018-06-25
 full_link: /docs/concepts/storage/volumes/#flexvolume
 short_description: >
-    FlexVolume is an interface for creating out-of-tree volume plugins. The {{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}} is a newer interface which addresses several problems with FlexVolumes.
+    FlexVolume is a deprecated interface for creating out-of-tree volume plugins. The {{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}} is a newer interface that addresses several problems with FlexVolume.
 aka: 
 tags:
 - storage 
 ---
- FlexVolume is an interface for creating out-of-tree volume plugins. The {{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}} is a newer interface which addresses several problems with FlexVolumes.
+ FlexVolume is a deprecated interface for creating out-of-tree volume plugins. The {{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}} is a newer interface that addresses several problems with FlexVolume.
 <!--more--> 
@@ -15,4 +15,4 @@ tags:
 <!--more--> 
-Allows for more control over how sensitive information is used and reduces the risk of accidental exposure, including [encryption](/docs/tasks/administer-cluster/encrypt-data/#ensure-all-secrets-are-encrypted) at rest.  A {{< glossary_tooltip text="Pod" term_id="pod" >}} references the secret as a file in a volume mount or by the kubelet pulling images for a pod. Secrets are great for confidential data and [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) for non-confidential data.
+Allows for more control over how sensitive information is used and reduces the risk of accidental exposure. Secret values are encoded as base64 strings and stored unencrypted by default, but can be configured to be [encrypted at rest](/docs/tasks/administer-cluster/encrypt-data/#ensure-all-secrets-are-encrypted). A {{< glossary_tooltip text="Pod" term_id="pod" >}} references the secret as a file in a volume mount or by the kubelet pulling images for a pod. Secrets are great for confidential data and [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) for non-confidential data.
@@ -311,8 +311,7 @@ kubectl logs -f my-pod                              # stream pod logs (stdout)
 kubectl logs -f my-pod -c my-container              # stream pod container logs (stdout, multi-container case)
 kubectl logs -f -l name=myLabel --all-containers    # stream all pods logs with label name=myLabel (stdout)
 kubectl run -i --tty busybox --image=busybox -- sh  # Run pod as interactive shell
-kubectl run nginx --image=nginx -n 
+kubectl run nginx --image=nginx -n mynamespace      # Start a single instance of nginx pod in the namespace of mynamespace
 mynamespace                                         # Run pod nginx in a specific namespace
 kubectl run nginx --image=nginx                     # Run pod nginx and write its spec into a file called pod.yaml
 --dry-run=client -o yaml > pod.yaml
@@ -213,6 +213,11 @@ CertificateSigningRequestStatus contains conditions used to indicate approved/de
    Only one condition of a given type is allowed.
    Possible enum values:
     - `"Approved"` Approved indicates the request was approved and should be issued by the signer.
     - `"Denied"` Denied indicates the request was denied and should not be issued by the signer.
     - `"Failed"` Failed indicates the signer failed to issue the certificate.
  - **conditions.lastTransitionTime** (Time)
    lastTransitionTime is the time the condition last transitioned from one status to another. If unset, when a new condition type is added or an existing condition's status is changed, the server defaults this to the current time.
@@ -449,6 +454,11 @@ POST /apis/certificates.k8s.io/v1/certificatesigningrequests
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -496,6 +506,11 @@ PUT /apis/certificates.k8s.io/v1/certificatesigningrequests/{name}
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -541,6 +556,11 @@ PUT /apis/certificates.k8s.io/v1/certificatesigningrequests/{name}/approval
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -586,6 +606,11 @@ PUT /apis/certificates.k8s.io/v1/certificatesigningrequests/{name}/status
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -631,6 +656,11 @@ PATCH /apis/certificates.k8s.io/v1/certificatesigningrequests/{name}
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **force** (*in query*): boolean
  <a href="{{< ref "../common-parameters/common-parameters#force" >}}">force</a>
@@ -681,6 +711,11 @@ PATCH /apis/certificates.k8s.io/v1/certificatesigningrequests/{name}/approval
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **force** (*in query*): boolean
  <a href="{{< ref "../common-parameters/common-parameters#force" >}}">force</a>
@@ -731,6 +766,11 @@ PATCH /apis/certificates.k8s.io/v1/certificatesigningrequests/{name}/status
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **force** (*in query*): boolean
  <a href="{{< ref "../common-parameters/common-parameters#force" >}}">force</a>
@@ -298,6 +298,11 @@ POST /api/v1/namespaces/{namespace}/serviceaccounts
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -350,6 +355,11 @@ PUT /api/v1/namespaces/{namespace}/serviceaccounts/{name}
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -400,6 +410,11 @@ PATCH /api/v1/namespaces/{namespace}/serviceaccounts/{name}
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **force** (*in query*): boolean
  <a href="{{< ref "../common-parameters/common-parameters#force" >}}">force</a>
@@ -161,6 +161,11 @@ POST /api/v1/namespaces/{namespace}/serviceaccounts/{name}/token
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -152,6 +152,11 @@ POST /apis/authentication.k8s.io/v1/tokenreviews
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -243,6 +243,11 @@ POST /apis/rbac.authorization.k8s.io/v1/clusterrolebindings
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -290,6 +295,11 @@ PUT /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/{name}
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -335,6 +345,11 @@ PATCH /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/{name}
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **force** (*in query*): boolean
  <a href="{{< ref "../common-parameters/common-parameters#force" >}}">force</a>
@@ -70,7 +70,7 @@ ClusterRole is a cluster level, logical grouping of PolicyRules that can be refe
  - **rules.verbs** ([]string), required
-    Verbs is a list of Verbs that apply to ALL the ResourceKinds and AttributeRestrictions contained in this rule. '*' represents all verbs.
+    Verbs is a list of Verbs that apply to ALL the ResourceKinds contained in this rule. '*' represents all verbs.
  - **rules.resourceNames** ([]string)
@@ -239,6 +239,11 @@ POST /apis/rbac.authorization.k8s.io/v1/clusterroles
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -286,6 +291,11 @@ PUT /apis/rbac.authorization.k8s.io/v1/clusterroles/{name}
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -331,6 +341,11 @@ PATCH /apis/rbac.authorization.k8s.io/v1/clusterroles/{name}
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **force** (*in query*): boolean
  <a href="{{< ref "../common-parameters/common-parameters#force" >}}">force</a>
@@ -94,6 +94,11 @@ POST /apis/authorization.k8s.io/v1/namespaces/{namespace}/localsubjectaccessrevi
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -326,6 +326,11 @@ POST /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/rolebindings
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -378,6 +383,11 @@ PUT /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/rolebindings/{name
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -428,6 +438,11 @@ PATCH /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/rolebindings/{na
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **force** (*in query*): boolean
  <a href="{{< ref "../common-parameters/common-parameters#force" >}}">force</a>
@@ -59,7 +59,7 @@ Role is a namespaced, logical grouping of PolicyRules that can be referenced as
  - **rules.verbs** ([]string), required
-    Verbs is a list of Verbs that apply to ALL the ResourceKinds and AttributeRestrictions contained in this rule. '*' represents all verbs.
+    Verbs is a list of Verbs that apply to ALL the ResourceKinds contained in this rule. '*' represents all verbs.
  - **rules.resourceNames** ([]string)
@@ -311,6 +311,11 @@ POST /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/roles
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -363,6 +368,11 @@ PUT /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/roles/{name}
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -413,6 +423,11 @@ PATCH /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/roles/{name}
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **force** (*in query*): boolean
  <a href="{{< ref "../common-parameters/common-parameters#force" >}}">force</a>
@@ -149,6 +149,11 @@ POST /apis/authorization.k8s.io/v1/selfsubjectaccessreviews
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -153,6 +153,11 @@ POST /apis/authorization.k8s.io/v1/selfsubjectrulesreviews
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -191,6 +191,11 @@ POST /apis/authorization.k8s.io/v1/subjectaccessreviews
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -336,6 +336,11 @@ POST /apis/apiregistration.k8s.io/v1/apiservices
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -383,6 +388,11 @@ PUT /apis/apiregistration.k8s.io/v1/apiservices/{name}
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -428,6 +438,11 @@ PUT /apis/apiregistration.k8s.io/v1/apiservices/{name}/status
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -473,6 +488,11 @@ PATCH /apis/apiregistration.k8s.io/v1/apiservices/{name}
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **force** (*in query*): boolean
  <a href="{{< ref "../common-parameters/common-parameters#force" >}}">force</a>
@@ -523,6 +543,11 @@ PATCH /apis/apiregistration.k8s.io/v1/apiservices/{name}/status
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **force** (*in query*): boolean
  <a href="{{< ref "../common-parameters/common-parameters#force" >}}">force</a>
@@ -90,6 +90,11 @@ POST /api/v1/namespaces/{namespace}/bindings
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -142,6 +147,11 @@ POST /api/v1/namespaces/{namespace}/pods/{name}/binding
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -374,6 +374,11 @@ POST /apis/events.k8s.io/v1/namespaces/{namespace}/events
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -426,6 +431,11 @@ PUT /apis/events.k8s.io/v1/namespaces/{namespace}/events/{name}
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -476,6 +486,11 @@ PATCH /apis/events.k8s.io/v1/namespaces/{namespace}/events/{name}
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **force** (*in query*): boolean
  <a href="{{< ref "../common-parameters/common-parameters#force" >}}">force</a>
@@ -1,11 +1,11 @@
 ---
 api_metadata:
-  apiVersion: "flowcontrol.apiserver.k8s.io/v1beta1"
+  apiVersion: "flowcontrol.apiserver.k8s.io/v1beta2"
-  import: "k8s.io/api/flowcontrol/v1beta1"
+  import: "k8s.io/api/flowcontrol/v1beta2"
  kind: "FlowSchema"
 content_type: "api_reference"
 description: "FlowSchema defines the schema of a group of flows."
-title: "FlowSchema v1beta1"
+title: "FlowSchema v1beta2"
 weight: 7
 auto_generated: true
 ---
@@ -21,9 +21,9 @@ guide. You can file document formatting bugs against the
 [reference-docs](https://github.com/kubernetes-sigs/reference-docs/) project.
 -->
-`apiVersion: flowcontrol.apiserver.k8s.io/v1beta1`
+`apiVersion: flowcontrol.apiserver.k8s.io/v1beta2`
-`import "k8s.io/api/flowcontrol/v1beta1"`
+`import "k8s.io/api/flowcontrol/v1beta2"`
 ## FlowSchema {#FlowSchema}
@@ -32,7 +32,7 @@ FlowSchema defines the schema of a group of flows. Note that a flow is made up o
 <hr>
- **apiVersion**: flowcontrol.apiserver.k8s.io/v1beta1
+- **apiVersion**: flowcontrol.apiserver.k8s.io/v1beta2
 - **kind**: FlowSchema
@@ -42,11 +42,11 @@ FlowSchema defines the schema of a group of flows. Note that a flow is made up o
  `metadata` is the standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
- **spec** (<a href="{{< ref "../cluster-resources/flow-schema-v1beta1#FlowSchemaSpec" >}}">FlowSchemaSpec</a>)
+- **spec** (<a href="{{< ref "../cluster-resources/flow-schema-v1beta2#FlowSchemaSpec" >}}">FlowSchemaSpec</a>)
  `spec` is the specification of the desired behavior of a FlowSchema. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
- **status** (<a href="{{< ref "../cluster-resources/flow-schema-v1beta1#FlowSchemaStatus" >}}">FlowSchemaStatus</a>)
+- **status** (<a href="{{< ref "../cluster-resources/flow-schema-v1beta2#FlowSchemaStatus" >}}">FlowSchemaStatus</a>)
  `status` is the current status of a FlowSchema. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
@@ -179,7 +179,7 @@ FlowSchemaSpec describes how the FlowSchema's specification looks like.
    `resourceRules` is a slice of ResourcePolicyRules that identify matching requests according to their verb and the target resource. At least one of `resourceRules` and `nonResourceRules` has to be non-empty.
    <a name="ResourcePolicyRule"></a>
-    *ResourcePolicyRule is a predicate that matches some resource requests, testing the request's verb and the target resource. A ResourcePolicyRule matches a resource request if and only if: (a) at least one member of verbs matches the request, (b) at least one member of apiGroups matches the request, (c) at least one member of resources matches the request, and (d) least one member of namespaces matches the request.*
+    *ResourcePolicyRule is a predicate that matches some resource requests, testing the request's verb and the target resource. A ResourcePolicyRule matches a resource request if and only if: (a) at least one member of verbs matches the request, (b) at least one member of apiGroups matches the request, (c) at least one member of resources matches the request, and (d) either (d1) the request does not specify a namespace (i.e., `Namespace==""`) and clusterScope is true or (d2) the request specifies a namespace and least one member of namespaces matches the request's namespace.*
    - **rules.resourceRules.apiGroups** ([]string), required
@@ -261,7 +261,7 @@ FlowSchemaList is a list of FlowSchema objects.
 <hr>
- **apiVersion**: flowcontrol.apiserver.k8s.io/v1beta1
+- **apiVersion**: flowcontrol.apiserver.k8s.io/v1beta2
 - **kind**: FlowSchemaList
@@ -271,7 +271,7 @@ FlowSchemaList is a list of FlowSchema objects.
  `metadata` is the standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
- **items** ([]<a href="{{< ref "../cluster-resources/flow-schema-v1beta1#FlowSchema" >}}">FlowSchema</a>), required
+- **items** ([]<a href="{{< ref "../cluster-resources/flow-schema-v1beta2#FlowSchema" >}}">FlowSchema</a>), required
  `items` is a list of FlowSchemas.
@@ -294,7 +294,7 @@ FlowSchemaList is a list of FlowSchema objects.
 #### HTTP Request
-GET /apis/flowcontrol.apiserver.k8s.io/v1beta1/flowschemas/{name}
+GET /apis/flowcontrol.apiserver.k8s.io/v1beta2/flowschemas/{name}
 #### Parameters
@@ -313,7 +313,7 @@ GET /apis/flowcontrol.apiserver.k8s.io/v1beta1/flowschemas/{name}
 #### Response
-200 (<a href="{{< ref "../cluster-resources/flow-schema-v1beta1#FlowSchema" >}}">FlowSchema</a>): OK
+200 (<a href="{{< ref "../cluster-resources/flow-schema-v1beta2#FlowSchema" >}}">FlowSchema</a>): OK
 401: Unauthorized
@@ -322,7 +322,7 @@ GET /apis/flowcontrol.apiserver.k8s.io/v1beta1/flowschemas/{name}
 #### HTTP Request
-GET /apis/flowcontrol.apiserver.k8s.io/v1beta1/flowschemas/{name}/status
+GET /apis/flowcontrol.apiserver.k8s.io/v1beta2/flowschemas/{name}/status
 #### Parameters
@@ -341,7 +341,7 @@ GET /apis/flowcontrol.apiserver.k8s.io/v1beta1/flowschemas/{name}/status
 #### Response
-200 (<a href="{{< ref "../cluster-resources/flow-schema-v1beta1#FlowSchema" >}}">FlowSchema</a>): OK
+200 (<a href="{{< ref "../cluster-resources/flow-schema-v1beta2#FlowSchema" >}}">FlowSchema</a>): OK
 401: Unauthorized
@@ -350,7 +350,7 @@ GET /apis/flowcontrol.apiserver.k8s.io/v1beta1/flowschemas/{name}/status
 #### HTTP Request
-GET /apis/flowcontrol.apiserver.k8s.io/v1beta1/flowschemas
+GET /apis/flowcontrol.apiserver.k8s.io/v1beta2/flowschemas
 #### Parameters
@@ -409,7 +409,7 @@ GET /apis/flowcontrol.apiserver.k8s.io/v1beta1/flowschemas
 #### Response
-200 (<a href="{{< ref "../cluster-resources/flow-schema-v1beta1#FlowSchemaList" >}}">FlowSchemaList</a>): OK
+200 (<a href="{{< ref "../cluster-resources/flow-schema-v1beta2#FlowSchemaList" >}}">FlowSchemaList</a>): OK
 401: Unauthorized
@@ -418,12 +418,12 @@ GET /apis/flowcontrol.apiserver.k8s.io/v1beta1/flowschemas
 #### HTTP Request
-POST /apis/flowcontrol.apiserver.k8s.io/v1beta1/flowschemas
+POST /apis/flowcontrol.apiserver.k8s.io/v1beta2/flowschemas
 #### Parameters
- **body**: <a href="{{< ref "../cluster-resources/flow-schema-v1beta1#FlowSchema" >}}">FlowSchema</a>, required
+- **body**: <a href="{{< ref "../cluster-resources/flow-schema-v1beta2#FlowSchema" >}}">FlowSchema</a>, required
@@ -438,6 +438,11 @@ POST /apis/flowcontrol.apiserver.k8s.io/v1beta1/flowschemas
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -447,11 +452,11 @@ POST /apis/flowcontrol.apiserver.k8s.io/v1beta1/flowschemas
 #### Response
-200 (<a href="{{< ref "../cluster-resources/flow-schema-v1beta1#FlowSchema" >}}">FlowSchema</a>): OK
+200 (<a href="{{< ref "../cluster-resources/flow-schema-v1beta2#FlowSchema" >}}">FlowSchema</a>): OK
-201 (<a href="{{< ref "../cluster-resources/flow-schema-v1beta1#FlowSchema" >}}">FlowSchema</a>): Created
+201 (<a href="{{< ref "../cluster-resources/flow-schema-v1beta2#FlowSchema" >}}">FlowSchema</a>): Created
-202 (<a href="{{< ref "../cluster-resources/flow-schema-v1beta1#FlowSchema" >}}">FlowSchema</a>): Accepted
+202 (<a href="{{< ref "../cluster-resources/flow-schema-v1beta2#FlowSchema" >}}">FlowSchema</a>): Accepted
 401: Unauthorized
@@ -460,7 +465,7 @@ POST /apis/flowcontrol.apiserver.k8s.io/v1beta1/flowschemas
 #### HTTP Request
-PUT /apis/flowcontrol.apiserver.k8s.io/v1beta1/flowschemas/{name}
+PUT /apis/flowcontrol.apiserver.k8s.io/v1beta2/flowschemas/{name}
 #### Parameters
@@ -470,7 +475,7 @@ PUT /apis/flowcontrol.apiserver.k8s.io/v1beta1/flowschemas/{name}
  name of the FlowSchema
- **body**: <a href="{{< ref "../cluster-resources/flow-schema-v1beta1#FlowSchema" >}}">FlowSchema</a>, required
+- **body**: <a href="{{< ref "../cluster-resources/flow-schema-v1beta2#FlowSchema" >}}">FlowSchema</a>, required
@@ -485,6 +490,11 @@ PUT /apis/flowcontrol.apiserver.k8s.io/v1beta1/flowschemas/{name}
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -494,9 +504,9 @@ PUT /apis/flowcontrol.apiserver.k8s.io/v1beta1/flowschemas/{name}
 #### Response
-200 (<a href="{{< ref "../cluster-resources/flow-schema-v1beta1#FlowSchema" >}}">FlowSchema</a>): OK
+200 (<a href="{{< ref "../cluster-resources/flow-schema-v1beta2#FlowSchema" >}}">FlowSchema</a>): OK
-201 (<a href="{{< ref "../cluster-resources/flow-schema-v1beta1#FlowSchema" >}}">FlowSchema</a>): Created
+201 (<a href="{{< ref "../cluster-resources/flow-schema-v1beta2#FlowSchema" >}}">FlowSchema</a>): Created
 401: Unauthorized
@@ -505,7 +515,7 @@ PUT /apis/flowcontrol.apiserver.k8s.io/v1beta1/flowschemas/{name}
 #### HTTP Request
-PUT /apis/flowcontrol.apiserver.k8s.io/v1beta1/flowschemas/{name}/status
+PUT /apis/flowcontrol.apiserver.k8s.io/v1beta2/flowschemas/{name}/status
 #### Parameters
@@ -515,7 +525,7 @@ PUT /apis/flowcontrol.apiserver.k8s.io/v1beta1/flowschemas/{name}/status
  name of the FlowSchema
- **body**: <a href="{{< ref "../cluster-resources/flow-schema-v1beta1#FlowSchema" >}}">FlowSchema</a>, required
+- **body**: <a href="{{< ref "../cluster-resources/flow-schema-v1beta2#FlowSchema" >}}">FlowSchema</a>, required
@@ -530,6 +540,11 @@ PUT /apis/flowcontrol.apiserver.k8s.io/v1beta1/flowschemas/{name}/status
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -539,9 +554,9 @@ PUT /apis/flowcontrol.apiserver.k8s.io/v1beta1/flowschemas/{name}/status
 #### Response
-200 (<a href="{{< ref "../cluster-resources/flow-schema-v1beta1#FlowSchema" >}}">FlowSchema</a>): OK
+200 (<a href="{{< ref "../cluster-resources/flow-schema-v1beta2#FlowSchema" >}}">FlowSchema</a>): OK
-201 (<a href="{{< ref "../cluster-resources/flow-schema-v1beta1#FlowSchema" >}}">FlowSchema</a>): Created
+201 (<a href="{{< ref "../cluster-resources/flow-schema-v1beta2#FlowSchema" >}}">FlowSchema</a>): Created
 401: Unauthorized
@@ -550,7 +565,7 @@ PUT /apis/flowcontrol.apiserver.k8s.io/v1beta1/flowschemas/{name}/status
 #### HTTP Request
-PATCH /apis/flowcontrol.apiserver.k8s.io/v1beta1/flowschemas/{name}
+PATCH /apis/flowcontrol.apiserver.k8s.io/v1beta2/flowschemas/{name}
 #### Parameters
@@ -575,6 +590,11 @@ PATCH /apis/flowcontrol.apiserver.k8s.io/v1beta1/flowschemas/{name}
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **force** (*in query*): boolean
  <a href="{{< ref "../common-parameters/common-parameters#force" >}}">force</a>
@@ -589,9 +609,9 @@ PATCH /apis/flowcontrol.apiserver.k8s.io/v1beta1/flowschemas/{name}
 #### Response
-200 (<a href="{{< ref "../cluster-resources/flow-schema-v1beta1#FlowSchema" >}}">FlowSchema</a>): OK
+200 (<a href="{{< ref "../cluster-resources/flow-schema-v1beta2#FlowSchema" >}}">FlowSchema</a>): OK
-201 (<a href="{{< ref "../cluster-resources/flow-schema-v1beta1#FlowSchema" >}}">FlowSchema</a>): Created
+201 (<a href="{{< ref "../cluster-resources/flow-schema-v1beta2#FlowSchema" >}}">FlowSchema</a>): Created
 401: Unauthorized
@@ -600,7 +620,7 @@ PATCH /apis/flowcontrol.apiserver.k8s.io/v1beta1/flowschemas/{name}
 #### HTTP Request
-PATCH /apis/flowcontrol.apiserver.k8s.io/v1beta1/flowschemas/{name}/status
+PATCH /apis/flowcontrol.apiserver.k8s.io/v1beta2/flowschemas/{name}/status
 #### Parameters
@@ -625,6 +645,11 @@ PATCH /apis/flowcontrol.apiserver.k8s.io/v1beta1/flowschemas/{name}/status
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **force** (*in query*): boolean
  <a href="{{< ref "../common-parameters/common-parameters#force" >}}">force</a>
@@ -639,9 +664,9 @@ PATCH /apis/flowcontrol.apiserver.k8s.io/v1beta1/flowschemas/{name}/status
 #### Response
-200 (<a href="{{< ref "../cluster-resources/flow-schema-v1beta1#FlowSchema" >}}">FlowSchema</a>): OK
+200 (<a href="{{< ref "../cluster-resources/flow-schema-v1beta2#FlowSchema" >}}">FlowSchema</a>): OK
-201 (<a href="{{< ref "../cluster-resources/flow-schema-v1beta1#FlowSchema" >}}">FlowSchema</a>): Created
+201 (<a href="{{< ref "../cluster-resources/flow-schema-v1beta2#FlowSchema" >}}">FlowSchema</a>): Created
 401: Unauthorized
@@ -650,7 +675,7 @@ PATCH /apis/flowcontrol.apiserver.k8s.io/v1beta1/flowschemas/{name}/status
 #### HTTP Request
-DELETE /apis/flowcontrol.apiserver.k8s.io/v1beta1/flowschemas/{name}
+DELETE /apis/flowcontrol.apiserver.k8s.io/v1beta2/flowschemas/{name}
 #### Parameters
@@ -700,7 +725,7 @@ DELETE /apis/flowcontrol.apiserver.k8s.io/v1beta1/flowschemas/{name}
 #### HTTP Request
-DELETE /apis/flowcontrol.apiserver.k8s.io/v1beta1/flowschemas
+DELETE /apis/flowcontrol.apiserver.k8s.io/v1beta2/flowschemas
 #### Parameters
@@ -324,6 +324,11 @@ POST /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -376,6 +381,11 @@ PUT /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name}
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -426,6 +436,11 @@ PATCH /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name}
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **force** (*in query*): boolean
  <a href="{{< ref "../common-parameters/common-parameters#force" >}}">force</a>
@@ -91,6 +91,13 @@ NamespaceStatus is information about the current status of a Namespace.
    Type of namespace controller condition.
    Possible enum values:
     - `"NamespaceContentRemaining"` contains information about resources remaining in a namespace.
     - `"NamespaceDeletionContentFailure"` contains information about namespace deleter errors during deletion of resources.
     - `"NamespaceDeletionDiscoveryFailure"` contains information about namespace deleter errors during resource discovery.
     - `"NamespaceDeletionGroupVersionParsingFailure"` contains information about namespace deleter errors parsing GV for legacy types.
     - `"NamespaceFinalizersRemaining"` contains information about which finalizers are on resources remaining in a namespace.
  - **conditions.lastTransitionTime** (Time)
@@ -107,6 +114,10 @@ NamespaceStatus is information about the current status of a Namespace.
  Phase is the current lifecycle phase of the namespace. More info: https://kubernetes.io/docs/tasks/administer-cluster/namespaces/
  Possible enum values:
   - `"Active"` means the namespace is available for use in the system
   - `"Terminating"` means the namespace is undergoing graceful termination
@@ -294,6 +305,11 @@ POST /api/v1/namespaces
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -341,6 +357,11 @@ PUT /api/v1/namespaces/{name}
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -386,6 +407,11 @@ PUT /api/v1/namespaces/{name}/finalize
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -431,6 +457,11 @@ PUT /api/v1/namespaces/{name}/status
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -476,6 +507,11 @@ PATCH /api/v1/namespaces/{name}
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **force** (*in query*): boolean
  <a href="{{< ref "../common-parameters/common-parameters#force" >}}">force</a>
@@ -526,6 +562,11 @@ PATCH /api/v1/namespaces/{name}/status
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **force** (*in query*): boolean
  <a href="{{< ref "../common-parameters/common-parameters#force" >}}">force</a>
@@ -121,6 +121,11 @@ NodeSpec describes the attributes that a node is created with.
    Required. The effect of the taint on pods that do not tolerate the taint. Valid effects are NoSchedule, PreferNoSchedule and NoExecute.
    Possible enum values:
     - `"NoExecute"` Evict any already-running pods that do not tolerate the taint. Currently enforced by NodeController.
     - `"NoSchedule"` Do not allow new pods to schedule onto the node unless they tolerate the taint, but allow all pods submitted to Kubelet without going through the scheduler to start, and allow all already-running pods to continue running. Enforced by the scheduler.
     - `"PreferNoSchedule"` Like TaintEffectNoSchedule, but the scheduler tries not to schedule new pods onto the node, rather than prohibiting new pods from scheduling onto the node entirely. Enforced by the scheduler.
  - **taints.key** (string), required
    Required. The taint key to be applied to a node.
@@ -167,6 +172,13 @@ NodeStatus is information about the current status of a node.
    Node address type, one of Hostname, ExternalIP or InternalIP.
    Possible enum values:
     - `"ExternalDNS"` identifies a DNS name which resolves to an IP address which has the characteristics of a NodeExternalIP. The IP it resolves to may or may not be a listed NodeExternalIP address.
     - `"ExternalIP"` identifies an IP address which is, in some way, intended to be more usable from outside the cluster then an internal IP, though no specific semantics are defined. It may be a globally routable IP, though it is not required to be. External IPs may be assigned directly to an interface on the node, like a NodeInternalIP, or alternatively, packets sent to the external IP may be NAT'ed to an internal node IP rather than being delivered directly (making the IP less efficient for node-to-node traffic than a NodeInternalIP).
     - `"Hostname"` identifies a name of the node. Although every node can be assumed to have a NodeAddress of this type, its exact syntax and semantics are not defined, and are not consistent between different clusters.
     - `"InternalDNS"` identifies a DNS name which resolves to an IP address which has the characteristics of a NodeInternalIP. The IP it resolves to may or may not be a listed NodeInternalIP address.
     - `"InternalIP"` identifies an IP address which is assigned to one of the node's network interfaces. Every node should have at least one address of this type. An internal IP is normally expected to be reachable from every other node, but may not be visible to hosts outside the cluster. By default it is assumed that kube-apiserver can reach node internal IPs, though it is possible to configure clusters where this is not the case. NodeInternalIP is the default type of node IP, and does not necessarily imply that the IP is ONLY reachable internally. If a node has multiple internal IPs, no specific semantics are assigned to the additional IPs.
 - **allocatable** (map[string]<a href="{{< ref "../common-definitions/quantity#Quantity" >}}">Quantity</a>)
  Allocatable represents the resources of a node that are available for scheduling. Defaults to Capacity.
@@ -192,6 +204,13 @@ NodeStatus is information about the current status of a node.
    Type of node condition.
    Possible enum values:
     - `"DiskPressure"` means the kubelet is under pressure due to insufficient available disk.
     - `"MemoryPressure"` means the kubelet is under pressure due to insufficient available memory.
     - `"NetworkUnavailable"` means that network for the node is not correctly configured.
     - `"PIDPressure"` means the kubelet is under pressure due to insufficient available PID.
     - `"Ready"` means kubelet is healthy and ready to accept pods.
  - **conditions.lastHeartbeatTime** (Time)
    Last time we got an update on a given condition.
@@ -411,6 +430,11 @@ NodeStatus is information about the current status of a node.
  NodePhase is the recently observed lifecycle phase of the node. More info: https://kubernetes.io/docs/concepts/nodes/node/#phase The field is never populated, and now is deprecated.
  Possible enum values:
   - `"Pending"` means the node has been created/added by the system, but not configured.
   - `"Running"` means the node has been configured and has Kubernetes components running.
   - `"Terminated"` means the node has been removed from the cluster.
 - **volumesAttached** ([]AttachedVolume)
  List of volumes that are attached to the node.
@@ -617,6 +641,11 @@ POST /api/v1/nodes
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -664,6 +693,11 @@ PUT /api/v1/nodes/{name}
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -709,6 +743,11 @@ PUT /api/v1/nodes/{name}/status
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -754,6 +793,11 @@ PATCH /api/v1/nodes/{name}
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **force** (*in query*): boolean
  <a href="{{< ref "../common-parameters/common-parameters#force" >}}">force</a>
@@ -804,6 +848,11 @@ PATCH /api/v1/nodes/{name}/status
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **force** (*in query*): boolean
  <a href="{{< ref "../common-parameters/common-parameters#force" >}}">force</a>
@@ -1,11 +1,11 @@
 ---
 api_metadata:
-  apiVersion: "flowcontrol.apiserver.k8s.io/v1beta1"
+  apiVersion: "flowcontrol.apiserver.k8s.io/v1beta2"
-  import: "k8s.io/api/flowcontrol/v1beta1"
+  import: "k8s.io/api/flowcontrol/v1beta2"
  kind: "PriorityLevelConfiguration"
 content_type: "api_reference"
 description: "PriorityLevelConfiguration represents the configuration of a priority level."
-title: "PriorityLevelConfiguration v1beta1"
+title: "PriorityLevelConfiguration v1beta2"
 weight: 8
 auto_generated: true
 ---
@@ -21,9 +21,9 @@ guide. You can file document formatting bugs against the
 [reference-docs](https://github.com/kubernetes-sigs/reference-docs/) project.
 -->
-`apiVersion: flowcontrol.apiserver.k8s.io/v1beta1`
+`apiVersion: flowcontrol.apiserver.k8s.io/v1beta2`
-`import "k8s.io/api/flowcontrol/v1beta1"`
+`import "k8s.io/api/flowcontrol/v1beta2"`
 ## PriorityLevelConfiguration {#PriorityLevelConfiguration}
@@ -32,7 +32,7 @@ PriorityLevelConfiguration represents the configuration of a priority level.
 <hr>
- **apiVersion**: flowcontrol.apiserver.k8s.io/v1beta1
+- **apiVersion**: flowcontrol.apiserver.k8s.io/v1beta2
 - **kind**: PriorityLevelConfiguration
@@ -42,11 +42,11 @@ PriorityLevelConfiguration represents the configuration of a priority level.
  `metadata` is the standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
- **spec** (<a href="{{< ref "../cluster-resources/priority-level-configuration-v1beta1#PriorityLevelConfigurationSpec" >}}">PriorityLevelConfigurationSpec</a>)
+- **spec** (<a href="{{< ref "../cluster-resources/priority-level-configuration-v1beta2#PriorityLevelConfigurationSpec" >}}">PriorityLevelConfigurationSpec</a>)
  `spec` is the specification of the desired behavior of a "request-priority". More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
- **status** (<a href="{{< ref "../cluster-resources/priority-level-configuration-v1beta1#PriorityLevelConfigurationStatus" >}}">PriorityLevelConfigurationStatus</a>)
+- **status** (<a href="{{< ref "../cluster-resources/priority-level-configuration-v1beta2#PriorityLevelConfigurationStatus" >}}">PriorityLevelConfigurationStatus</a>)
  `status` is the current status of a "request-priority". More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
@@ -163,7 +163,7 @@ PriorityLevelConfigurationList is a list of PriorityLevelConfiguration objects.
 <hr>
- **apiVersion**: flowcontrol.apiserver.k8s.io/v1beta1
+- **apiVersion**: flowcontrol.apiserver.k8s.io/v1beta2
 - **kind**: PriorityLevelConfigurationList
@@ -173,7 +173,7 @@ PriorityLevelConfigurationList is a list of PriorityLevelConfiguration objects.
  `metadata` is the standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
- **items** ([]<a href="{{< ref "../cluster-resources/priority-level-configuration-v1beta1#PriorityLevelConfiguration" >}}">PriorityLevelConfiguration</a>), required
+- **items** ([]<a href="{{< ref "../cluster-resources/priority-level-configuration-v1beta2#PriorityLevelConfiguration" >}}">PriorityLevelConfiguration</a>), required
  `items` is a list of request-priorities.
@@ -196,7 +196,7 @@ PriorityLevelConfigurationList is a list of PriorityLevelConfiguration objects.
 #### HTTP Request
-GET /apis/flowcontrol.apiserver.k8s.io/v1beta1/prioritylevelconfigurations/{name}
+GET /apis/flowcontrol.apiserver.k8s.io/v1beta2/prioritylevelconfigurations/{name}
 #### Parameters
@@ -215,7 +215,7 @@ GET /apis/flowcontrol.apiserver.k8s.io/v1beta1/prioritylevelconfigurations/{name
 #### Response
-200 (<a href="{{< ref "../cluster-resources/priority-level-configuration-v1beta1#PriorityLevelConfiguration" >}}">PriorityLevelConfiguration</a>): OK
+200 (<a href="{{< ref "../cluster-resources/priority-level-configuration-v1beta2#PriorityLevelConfiguration" >}}">PriorityLevelConfiguration</a>): OK
 401: Unauthorized
@@ -224,7 +224,7 @@ GET /apis/flowcontrol.apiserver.k8s.io/v1beta1/prioritylevelconfigurations/{name
 #### HTTP Request
-GET /apis/flowcontrol.apiserver.k8s.io/v1beta1/prioritylevelconfigurations/{name}/status
+GET /apis/flowcontrol.apiserver.k8s.io/v1beta2/prioritylevelconfigurations/{name}/status
 #### Parameters
@@ -243,7 +243,7 @@ GET /apis/flowcontrol.apiserver.k8s.io/v1beta1/prioritylevelconfigurations/{name
 #### Response
-200 (<a href="{{< ref "../cluster-resources/priority-level-configuration-v1beta1#PriorityLevelConfiguration" >}}">PriorityLevelConfiguration</a>): OK
+200 (<a href="{{< ref "../cluster-resources/priority-level-configuration-v1beta2#PriorityLevelConfiguration" >}}">PriorityLevelConfiguration</a>): OK
 401: Unauthorized
@@ -252,7 +252,7 @@ GET /apis/flowcontrol.apiserver.k8s.io/v1beta1/prioritylevelconfigurations/{name
 #### HTTP Request
-GET /apis/flowcontrol.apiserver.k8s.io/v1beta1/prioritylevelconfigurations
+GET /apis/flowcontrol.apiserver.k8s.io/v1beta2/prioritylevelconfigurations
 #### Parameters
@@ -311,7 +311,7 @@ GET /apis/flowcontrol.apiserver.k8s.io/v1beta1/prioritylevelconfigurations
 #### Response
-200 (<a href="{{< ref "../cluster-resources/priority-level-configuration-v1beta1#PriorityLevelConfigurationList" >}}">PriorityLevelConfigurationList</a>): OK
+200 (<a href="{{< ref "../cluster-resources/priority-level-configuration-v1beta2#PriorityLevelConfigurationList" >}}">PriorityLevelConfigurationList</a>): OK
 401: Unauthorized
@@ -320,12 +320,12 @@ GET /apis/flowcontrol.apiserver.k8s.io/v1beta1/prioritylevelconfigurations
 #### HTTP Request
-POST /apis/flowcontrol.apiserver.k8s.io/v1beta1/prioritylevelconfigurations
+POST /apis/flowcontrol.apiserver.k8s.io/v1beta2/prioritylevelconfigurations
 #### Parameters
- **body**: <a href="{{< ref "../cluster-resources/priority-level-configuration-v1beta1#PriorityLevelConfiguration" >}}">PriorityLevelConfiguration</a>, required
+- **body**: <a href="{{< ref "../cluster-resources/priority-level-configuration-v1beta2#PriorityLevelConfiguration" >}}">PriorityLevelConfiguration</a>, required
@@ -340,6 +340,11 @@ POST /apis/flowcontrol.apiserver.k8s.io/v1beta1/prioritylevelconfigurations
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -349,11 +354,11 @@ POST /apis/flowcontrol.apiserver.k8s.io/v1beta1/prioritylevelconfigurations
 #### Response
-200 (<a href="{{< ref "../cluster-resources/priority-level-configuration-v1beta1#PriorityLevelConfiguration" >}}">PriorityLevelConfiguration</a>): OK
+200 (<a href="{{< ref "../cluster-resources/priority-level-configuration-v1beta2#PriorityLevelConfiguration" >}}">PriorityLevelConfiguration</a>): OK
-201 (<a href="{{< ref "../cluster-resources/priority-level-configuration-v1beta1#PriorityLevelConfiguration" >}}">PriorityLevelConfiguration</a>): Created
+201 (<a href="{{< ref "../cluster-resources/priority-level-configuration-v1beta2#PriorityLevelConfiguration" >}}">PriorityLevelConfiguration</a>): Created
-202 (<a href="{{< ref "../cluster-resources/priority-level-configuration-v1beta1#PriorityLevelConfiguration" >}}">PriorityLevelConfiguration</a>): Accepted
+202 (<a href="{{< ref "../cluster-resources/priority-level-configuration-v1beta2#PriorityLevelConfiguration" >}}">PriorityLevelConfiguration</a>): Accepted
 401: Unauthorized
@@ -362,7 +367,7 @@ POST /apis/flowcontrol.apiserver.k8s.io/v1beta1/prioritylevelconfigurations
 #### HTTP Request
-PUT /apis/flowcontrol.apiserver.k8s.io/v1beta1/prioritylevelconfigurations/{name}
+PUT /apis/flowcontrol.apiserver.k8s.io/v1beta2/prioritylevelconfigurations/{name}
 #### Parameters
@@ -372,7 +377,7 @@ PUT /apis/flowcontrol.apiserver.k8s.io/v1beta1/prioritylevelconfigurations/{name
  name of the PriorityLevelConfiguration
- **body**: <a href="{{< ref "../cluster-resources/priority-level-configuration-v1beta1#PriorityLevelConfiguration" >}}">PriorityLevelConfiguration</a>, required
+- **body**: <a href="{{< ref "../cluster-resources/priority-level-configuration-v1beta2#PriorityLevelConfiguration" >}}">PriorityLevelConfiguration</a>, required
@@ -387,6 +392,11 @@ PUT /apis/flowcontrol.apiserver.k8s.io/v1beta1/prioritylevelconfigurations/{name
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -396,9 +406,9 @@ PUT /apis/flowcontrol.apiserver.k8s.io/v1beta1/prioritylevelconfigurations/{name
 #### Response
-200 (<a href="{{< ref "../cluster-resources/priority-level-configuration-v1beta1#PriorityLevelConfiguration" >}}">PriorityLevelConfiguration</a>): OK
+200 (<a href="{{< ref "../cluster-resources/priority-level-configuration-v1beta2#PriorityLevelConfiguration" >}}">PriorityLevelConfiguration</a>): OK
-201 (<a href="{{< ref "../cluster-resources/priority-level-configuration-v1beta1#PriorityLevelConfiguration" >}}">PriorityLevelConfiguration</a>): Created
+201 (<a href="{{< ref "../cluster-resources/priority-level-configuration-v1beta2#PriorityLevelConfiguration" >}}">PriorityLevelConfiguration</a>): Created
 401: Unauthorized
@@ -407,7 +417,7 @@ PUT /apis/flowcontrol.apiserver.k8s.io/v1beta1/prioritylevelconfigurations/{name
 #### HTTP Request
-PUT /apis/flowcontrol.apiserver.k8s.io/v1beta1/prioritylevelconfigurations/{name}/status
+PUT /apis/flowcontrol.apiserver.k8s.io/v1beta2/prioritylevelconfigurations/{name}/status
 #### Parameters
@@ -417,7 +427,7 @@ PUT /apis/flowcontrol.apiserver.k8s.io/v1beta1/prioritylevelconfigurations/{name
  name of the PriorityLevelConfiguration
- **body**: <a href="{{< ref "../cluster-resources/priority-level-configuration-v1beta1#PriorityLevelConfiguration" >}}">PriorityLevelConfiguration</a>, required
+- **body**: <a href="{{< ref "../cluster-resources/priority-level-configuration-v1beta2#PriorityLevelConfiguration" >}}">PriorityLevelConfiguration</a>, required
@@ -432,6 +442,11 @@ PUT /apis/flowcontrol.apiserver.k8s.io/v1beta1/prioritylevelconfigurations/{name
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -441,9 +456,9 @@ PUT /apis/flowcontrol.apiserver.k8s.io/v1beta1/prioritylevelconfigurations/{name
 #### Response
-200 (<a href="{{< ref "../cluster-resources/priority-level-configuration-v1beta1#PriorityLevelConfiguration" >}}">PriorityLevelConfiguration</a>): OK
+200 (<a href="{{< ref "../cluster-resources/priority-level-configuration-v1beta2#PriorityLevelConfiguration" >}}">PriorityLevelConfiguration</a>): OK
-201 (<a href="{{< ref "../cluster-resources/priority-level-configuration-v1beta1#PriorityLevelConfiguration" >}}">PriorityLevelConfiguration</a>): Created
+201 (<a href="{{< ref "../cluster-resources/priority-level-configuration-v1beta2#PriorityLevelConfiguration" >}}">PriorityLevelConfiguration</a>): Created
 401: Unauthorized
@@ -452,7 +467,7 @@ PUT /apis/flowcontrol.apiserver.k8s.io/v1beta1/prioritylevelconfigurations/{name
 #### HTTP Request
-PATCH /apis/flowcontrol.apiserver.k8s.io/v1beta1/prioritylevelconfigurations/{name}
+PATCH /apis/flowcontrol.apiserver.k8s.io/v1beta2/prioritylevelconfigurations/{name}
 #### Parameters
@@ -477,6 +492,11 @@ PATCH /apis/flowcontrol.apiserver.k8s.io/v1beta1/prioritylevelconfigurations/{na
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **force** (*in query*): boolean
  <a href="{{< ref "../common-parameters/common-parameters#force" >}}">force</a>
@@ -491,9 +511,9 @@ PATCH /apis/flowcontrol.apiserver.k8s.io/v1beta1/prioritylevelconfigurations/{na
 #### Response
-200 (<a href="{{< ref "../cluster-resources/priority-level-configuration-v1beta1#PriorityLevelConfiguration" >}}">PriorityLevelConfiguration</a>): OK
+200 (<a href="{{< ref "../cluster-resources/priority-level-configuration-v1beta2#PriorityLevelConfiguration" >}}">PriorityLevelConfiguration</a>): OK
-201 (<a href="{{< ref "../cluster-resources/priority-level-configuration-v1beta1#PriorityLevelConfiguration" >}}">PriorityLevelConfiguration</a>): Created
+201 (<a href="{{< ref "../cluster-resources/priority-level-configuration-v1beta2#PriorityLevelConfiguration" >}}">PriorityLevelConfiguration</a>): Created
 401: Unauthorized
@@ -502,7 +522,7 @@ PATCH /apis/flowcontrol.apiserver.k8s.io/v1beta1/prioritylevelconfigurations/{na
 #### HTTP Request
-PATCH /apis/flowcontrol.apiserver.k8s.io/v1beta1/prioritylevelconfigurations/{name}/status
+PATCH /apis/flowcontrol.apiserver.k8s.io/v1beta2/prioritylevelconfigurations/{name}/status
 #### Parameters
@@ -527,6 +547,11 @@ PATCH /apis/flowcontrol.apiserver.k8s.io/v1beta1/prioritylevelconfigurations/{na
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **force** (*in query*): boolean
  <a href="{{< ref "../common-parameters/common-parameters#force" >}}">force</a>
@@ -541,9 +566,9 @@ PATCH /apis/flowcontrol.apiserver.k8s.io/v1beta1/prioritylevelconfigurations/{na
 #### Response
-200 (<a href="{{< ref "../cluster-resources/priority-level-configuration-v1beta1#PriorityLevelConfiguration" >}}">PriorityLevelConfiguration</a>): OK
+200 (<a href="{{< ref "../cluster-resources/priority-level-configuration-v1beta2#PriorityLevelConfiguration" >}}">PriorityLevelConfiguration</a>): OK
-201 (<a href="{{< ref "../cluster-resources/priority-level-configuration-v1beta1#PriorityLevelConfiguration" >}}">PriorityLevelConfiguration</a>): Created
+201 (<a href="{{< ref "../cluster-resources/priority-level-configuration-v1beta2#PriorityLevelConfiguration" >}}">PriorityLevelConfiguration</a>): Created
 401: Unauthorized
@@ -552,7 +577,7 @@ PATCH /apis/flowcontrol.apiserver.k8s.io/v1beta1/prioritylevelconfigurations/{na
 #### HTTP Request
-DELETE /apis/flowcontrol.apiserver.k8s.io/v1beta1/prioritylevelconfigurations/{name}
+DELETE /apis/flowcontrol.apiserver.k8s.io/v1beta2/prioritylevelconfigurations/{name}
 #### Parameters
@@ -602,7 +627,7 @@ DELETE /apis/flowcontrol.apiserver.k8s.io/v1beta1/prioritylevelconfigurations/{n
 #### HTTP Request
-DELETE /apis/flowcontrol.apiserver.k8s.io/v1beta1/prioritylevelconfigurations
+DELETE /apis/flowcontrol.apiserver.k8s.io/v1beta2/prioritylevelconfigurations
 #### Parameters
@@ -87,6 +87,10 @@ RuntimeClass defines a class of container runtime supported in the cluster. The
      Operator represents a key's relationship to the value. Valid operators are Exists and Equal. Defaults to Equal. Exists is equivalent to wildcard for value, so that a pod can tolerate all taints of a particular category.
      Possible enum values:
       - `"Equal"`
       - `"Exists"`
    - **scheduling.tolerations.value** (string)
      Value is the taint value the toleration matches to. If the operator is Exists, the value should be empty, otherwise just a regular string.
@@ -95,6 +99,11 @@ RuntimeClass defines a class of container runtime supported in the cluster. The
      Effect indicates the taint effect to match. Empty means match all taint effects. When specified, allowed values are NoSchedule, PreferNoSchedule and NoExecute.
      Possible enum values:
       - `"NoExecute"` Evict any already-running pods that do not tolerate the taint. Currently enforced by NodeController.
       - `"NoSchedule"` Do not allow new pods to schedule onto the node unless they tolerate the taint, but allow all pods submitted to Kubelet without going through the scheduler to start, and allow all already-running pods to continue running. Enforced by the scheduler.
       - `"PreferNoSchedule"` Like TaintEffectNoSchedule, but the scheduler tries not to schedule new pods onto the node, rather than prohibiting new pods from scheduling onto the node entirely. Enforced by the scheduler.
    - **scheduling.tolerations.tolerationSeconds** (int64)
      TolerationSeconds represents the period of time the toleration (which must be of effect NoExecute, otherwise this field is ignored) tolerates the taint. By default, it is not set, which means tolerate the taint forever (do not evict). Zero and negative values will be treated as 0 (evict immediately) by the system.
@@ -258,6 +267,11 @@ POST /apis/node.k8s.io/v1/runtimeclasses
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -305,6 +319,11 @@ PUT /apis/node.k8s.io/v1/runtimeclasses/{name}
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **pretty** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty</a>
@@ -350,6 +369,11 @@ PATCH /apis/node.k8s.io/v1/runtimeclasses/{name}
  <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager</a>
 - **fieldValidation** (*in query*): string
  <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation</a>
 - **force** (*in query*): boolean
  <a href="{{< ref "../common-parameters/common-parameters#force" >}}">force</a>
@@ -38,6 +38,14 @@ A node selector requirement is a selector that contains values, a key, and an op
  Represents a key's relationship to a set of values. Valid operators are In, NotIn, Exists, DoesNotExist. Gt, and Lt.
  Possible enum values:
   - `"DoesNotExist"`
   - `"Exists"`
   - `"Gt"`
   - `"In"`
   - `"Lt"`
   - `"NotIn"`
 - **values** ([]string)
  An array of string values. If the operator is In or NotIn, the values array must be non-empty. If the operator is Exists or DoesNotExist, the values array must be empty. If the operator is Gt or Lt, the values array must have a single element, which will be interpreted as an integer. This array is replaced during a strategic merge patch.
@@ -78,6 +78,16 @@ A selector to restrict the list of returned objects by their fields. Defaults to
 ## fieldValidation {#fieldValidation}
 fieldValidation determines how the server should respond to unknown/duplicate fields in the object in the request. Introduced as alpha in 1.23, older servers or servers with the `ServerSideFieldValidation` feature disabled will discard valid values specified in  this param and not perform any server side field validation. Valid values are: - Ignore: ignores unknown/duplicate fields. - Warn: responds with a warning for each unknown/duplicate field, but successfully serves the request. - Strict: fails the request on unknown/duplicate fields.
 <hr>
 ## force {#force}
 Force is going to "force" Apply requests. It means user will re-acquire conflicting fields owned by other people. Force flag must be unset for non-apply patch requests.
--- a/Show More
+++ b/Show More
`@@ -15,4 +15,4 @@ tags:`

	`<!--more-->`	`<!--more-->`

	Allows for more control over how sensitive information is used and reduces the risk of accidental exposure, including [encryption](/docs/tasks/administer-cluster/encrypt-data/#ensure-all-secrets-are-encrypted) at rest. A {{< glossary_tooltip text="Pod" term_id="pod" >}} references the secret as a file in a volume mount or by the kubelet pulling images for a pod. Secrets are great for confidential data and [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) for non-confidential data.	Allows for more control over how sensitive information is used and reduces the risk of accidental exposure. Secret values are encoded as base64 strings and stored unencrypted by default, but can be configured to be [encrypted at rest](/docs/tasks/administer-cluster/encrypt-data/#ensure-all-secrets-are-encrypted). A {{< glossary_tooltip text="Pod" term_id="pod" >}} references the secret as a file in a volume mount or by the kubelet pulling images for a pod. Secrets are great for confidential data and [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) for non-confidential data.