Merge pull request #50589 from kubernetes/dev-1.33

Official 1.33 Release Docs

Author: reylejano

content/en/docs/concepts/cluster-administration/coordinated-leader-election.md

@@ -10,7 +10,7 @@ weight: 200
 
 {{< feature-state feature_gate_name="CoordinatedLeaderElection" >}}
 
-Kubernetes {{< skew currentVersion >}} includes an alpha feature that allows {{<
+Kubernetes {{< skew currentVersion >}} includes a beta feature that allows {{<
 glossary_tooltip text="control plane" term_id="control-plane" >}} components to
 deterministically select a leader via _coordinated leader election_.
 This is useful to satisfy Kubernetes version skew constraints during cluster upgrades.
@@ -23,15 +23,16 @@ version, followed by creation timestamp.
 Ensure that `CoordinatedLeaderElection` [feature
 gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled
 when you start the {{< glossary_tooltip text="API Server"
-term_id="kube-apiserver" >}}: and that the `coordination.k8s.io/v1alpha1` API group is
+term_id="kube-apiserver" >}}: and that the `coordination.k8s.io/v1beta1` API group is
 enabled.
 
 This can be done by setting flags `--feature-gates="CoordinatedLeaderElection=true"` and
-`--runtime-config="coordination.k8s.io/v1alpha1=true"`.
+`--runtime-config="coordination.k8s.io/v1beta1=true"`.
 
 ## Component configuration
+
 Provided that you have enabled the `CoordinatedLeaderElection` feature gate _and_  
-have the `coordination.k8s.io/v1alpha1` API group enabled, compatible control plane  
+have the `coordination.k8s.io/v1beta1` API group enabled, compatible control plane  
 components automatically use the LeaseCandidate and Lease APIs to elect a leader  
 as needed.  
 

content/en/docs/concepts/cluster-administration/system-metrics.md

@@ -177,6 +177,36 @@ ClusterRole with the `get` verb for the `/metrics/resources` non-resource URL.
 On Kubernetes 1.21 you must use the `--show-hidden-metrics-for-version=1.20`
 flag to expose these alpha stability metrics.
 
+### kubelet Pressure Stall Information (PSI) metrics
+
+{{< feature-state for_k8s_version="v1.33" state="alpha" >}}
+
+As an alpha feature, Kubernetes lets you configure kubelet to collect Linux kernel
+[Pressure Stall Information](https://docs.kernel.org/accounting/psi.html)
+(PSI) for CPU, memory and IO usage.
+The information is collected at node, pod and container level.
+The metrics are exposed at the `/metrics/cadvisor` endpoint with the following names:
+
+```
+container_pressure_cpu_stalled_seconds_total
+container_pressure_cpu_waiting_seconds_total
+container_pressure_memory_stalled_seconds_total
+container_pressure_memory_waiting_seconds_total
+container_pressure_io_stalled_seconds_total
+container_pressure_io_waiting_seconds_total
+```
+
+You must enable the `KubeletPSI` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
+to use this feature. The information is also exposed in the
+[Summary API](/docs/reference/instrumentation/node-metrics#psi).
+
+#### Requirements
+
+Pressure Stall Information requires:
+
+- [Linux kernel versions 4.20 or later](/docs/reference/node/kernel-version-requirements#requirements-psi).
+- [cgroup v2](/docs/concepts/architecture/cgroups)
+
 ## Disabling metrics
 
 You can explicitly turn off metrics via command line flag `--disabled-metrics`. This may be
@@ -223,4 +253,4 @@ is encountered that is not allowed with respect to the allow-list constraints.
 * Read about the [Prometheus text format](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format)
   for metrics
 * See the list of [stable Kubernetes metrics](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml)
-* Read about the [Kubernetes deprecation policy](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior)
+* Read about the [Kubernetes deprecation policy](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior)

content/en/docs/concepts/containers/container-lifecycle-hooks.md

@@ -47,6 +47,14 @@ parameters are passed to the handler.
 A more detailed description of the termination behavior can be found in
 [Termination of Pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination).
 
+`StopSignal`
+
+The StopSignal lifecycle can be used to define a stop signal which would be sent to the container when it is
+stopped. If you set this, it overrides any `STOPSIGNAL` instruction defined within the container image.
+
+A more detailed description of termination behaviour with custom stop signals can be found in
+[Stop Signals](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination-stop-signals).
+
 ### Hook handler implementations
 
 Containers can access a hook by implementing and registering a handler for that hook.
@@ -56,17 +64,20 @@ There are three types of hook handlers that can be implemented for Containers:
 Resources consumed by the command are counted against the Container.
 * HTTP - Executes an HTTP request against a specific endpoint on the Container.
 * Sleep - Pauses the container for a specified duration. 
-  This is a beta-level feature default enabled by the `PodLifecycleSleepAction` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/). 
+  This is a beta-level feature default enabled by the `PodLifecycleSleepAction`
+  [feature gate](/docs/reference/command-line-tools-reference/feature-gates/). 
 
 {{< note >}}
-Enable the `PodLifecycleSleepActionAllowZero` feature gate if you want to set a sleep duration of zero seconds (effectively a no-op) for your Sleep lifecycle hooks.
+The beta level `PodLifecycleSleepActionAllowZero` feature gate which is enabled by default from v1.33.
+It allows you to set a sleep duration of zero seconds (effectively a no-op) for your Sleep lifecycle hooks.
 {{< /note >}}
 
 ### Hook handler execution
 
 When a Container lifecycle management hook is called,
 the Kubernetes management system executes the handler according to the hook action,
-`httpGet`, `tcpSocket` ([deprecated](/docs/reference/generated/kubernetes-api/v1.31/#lifecyclehandler-v1-core)) and `sleep` are executed by the kubelet process, and `exec` is executed in the container.
+`httpGet`, `tcpSocket` ([deprecated](/docs/reference/generated/kubernetes-api/v1.31/#lifecyclehandler-v1-core))
+and `sleep` are executed by the kubelet process, and `exec` is executed in the container.
 
 The `PostStart` hook handler call is initiated when a container is created,
 meaning the container ENTRYPOINT and the `PostStart` hook are triggered simultaneously. 
@@ -110,7 +121,9 @@ The logs for a Hook handler are not exposed in Pod events.
 If a handler fails for some reason, it broadcasts an event.
 For `PostStart`, this is the `FailedPostStartHook` event,
 and for `PreStop`, this is the `FailedPreStopHook` event.
-To generate a failed `FailedPostStartHook` event yourself, modify the [lifecycle-events.yaml](https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/lifecycle-events.yaml) file to change the postStart command to "badcommand" and apply it.
+To generate a failed `FailedPostStartHook` event yourself, modify the
+[lifecycle-events.yaml](https://k8s.io/examples/pods/lifecycle-events.yaml)
+file to change the postStart command to "badcommand" and apply it.
 Here is some example output of the resulting events you see from running `kubectl describe pod lifecycle-demo`:
 
 ```

content/en/docs/concepts/containers/images.md

@@ -367,7 +367,10 @@ you must ensure all nodes in the cluster have the same pre-pulled images.
 This can be used to preload certain images for speed or as an alternative to authenticating to a
 private registry.
 
-All pods will have read access to any pre-pulled images.
+{{< note >}}
+{{< feature-state feature_gate_name="KubeletEnsureSecretPulledImages" >}}
+Access to pre-pulled images may be authorized according to [image pull credential verification](#ensureimagepullcredentialverification)
+{{< /note >}}
 
 ### Specifying imagePullSecrets on a Pod
 
@@ -380,6 +383,43 @@ Kubernetes supports specifying container image registry keys on a Pod.
 `imagePullSecrets` must all be in the same namespace as the Pod. The referenced
 Secrets must be of type `kubernetes.io/dockercfg` or `kubernetes.io/dockerconfigjson`.
 
+#### Ensure Image Pull Credential Verification {#ensureimagepullcredentialverification}
+
+{{< feature-state feature_gate_name="KubeletEnsureSecretPulledImages" >}}
+
+If the `KubeletEnsureSecretPulledImages` feature gate is enabled, Kubernetes will validate 
+image credentials for every image that requires credentials to be pulled,
+even if that image is already present on the node.
+This validation ensures that images in a pod request which have not been successfully pulled
+with the provided credentials must re-pull the images from the registry.
+Additionally, image pulls that re-use the same credentials
+which previously resulted in a successful image pull will not need to re-pull from the registry
+and are instead validated locally without accessing the registry
+(provided the image is available locally).
+This is controlled by the`imagePullCredentialsVerificationPolicy` field in the
+[Kubelet configuration](/docs/reference/config-api/kubelet-config.v1beta1#ImagePullCredentialsVerificationPolicy).
+
+This configuration controls when image pull credentials must be verified if the
+image is already present on the node:
+
+ * `NeverVerify`: Mimics the behavior of having this feature gate disabled.
+   If the image is present locally, image pull credentials are not verified.
+ * `NeverVerifyPreloadedImages`: Images pulled outside the kubelet are not verified,
+ but all other images will have their credentials verified. This is the default behavior.
+ * `NeverVerifyAllowListedImages`: Images pulled outside the kubelet and mentioned within the 
+   `preloadedImagesVerificationAllowlist` specified in the kubelet config are not verified.
+ * `AlwaysVerify`: All images will have their credentials verified
+   before they can be used.
+
+This verification applies to [pre-pulled images](#pre-pulled-images),
+images pulled using node-wide secrets, and images pulled using pod-level secrets.
+
+{{< note >}}
+In the case of credential rotation, the credentials previously used to pull the image
+will continue to verify without the need to access the registry. New or rotated credentials
+will require the image to be re-pulled from the registry.
+{{< /note >}}
+
 #### Creating a Secret with a Docker config
 
 You need to know the username, registry password and client email address for authenticating

content/en/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md

@@ -49,6 +49,7 @@ let you meet it.
 * To get the aggregator working in your environment, [configure the aggregation layer](/docs/tasks/extend-kubernetes/configure-aggregation-layer/).
 * Then, [setup an extension api-server](/docs/tasks/extend-kubernetes/setup-extension-api-server/) to work with the aggregation layer.
 * Read about [APIService](/docs/reference/kubernetes-api/cluster-resources/api-service-v1/) in the API reference
+*   Learn about [Declarative Validation Concepts](/docs/reference/using-api/declarative-validation.md), an internal mechanism for defining validation rules that in the future will help support validation for extension API server development.
 
 Alternatively: learn how to
 [extend the Kubernetes API using Custom Resource Definitions](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/).

content/en/docs/concepts/policy/node-resource-managers.md

@@ -196,14 +196,14 @@ listed in alphabetical order:
 : Allocate virtual cores, sometimes called hardware threads, across different physical cores
   (available since Kubernetes v1.31)
 
-`distribute-cpus-across-numa` (alpha, hidden by default)
+`distribute-cpus-across-numa` (beta, visible by default)
 : Spread CPUs across different NUMA domains, aiming for an even balance between the selected domains
   (available since Kubernetes v1.23)
 
-`full-pcpus-only` (beta, visible by default)
-: Always allocate full physical cores (available since Kubernetes v1.22)
+`full-pcpus-only` (GA, visible by default)
+: Always allocate full physical cores (available since Kubernetes v1.22, GA since Kubernetes v1.33)
 
-`strict-cpu-reservation` (alpha, hidden by default)
+`strict-cpu-reservation` (beta, visible by default)
 : Prevent all the pods regardless of their Quality of Service class to run on reserved CPUs
   (available since Kubernetes v1.32)