Merge pull request #52744 from Jimmykhangnguyen/merged-main-dev-1.35

Merge main branch into dev-1.35

Author: k8s-ci-robot

content/en/blog/_posts/2025-05-22-wg-policy-spotlight.md renamed to content/en/blog/_posts/2025-10-18-wg-policy-spotlight.md

@@ -2,9 +2,8 @@
 layout: blog
 title: "Spotlight on Policy Working Group"
 slug: wg-policy-spotlight-2025
-draft: true
-date: 2025-05-22
-author: "Arujjwal Negi"
+date: 2025-10-18
+author: Arujjwal Negi
 ---  
 
 *(Note: The Policy Working Group has completed its mission and is no longer active. This article reflects its work, accomplishments, and insights into how a working group operates.)*
@@ -18,7 +17,7 @@ Through collaborative methods, this working group strove to bring clarity and co
 This blog post dives deeper into the work of the Policy Working Group, guided by insights from its former co-chairs:
 
 -   [Jim Bugwadia](https://twitter.com/JimBugwadia)
--   [Poonam Lamba](https://twitter.com/poonam-lamba)
+-   [Poonam Lamba](https://twitter.com/poonam_lamba)
 -   [Andy Suderman](https://twitter.com/sudermanjr)
 
 _Interviewed by [Arujjwal Negi](https://twitter.com/arujjval)._
@@ -71,7 +70,7 @@ We worked on several Kubernetes policy-related projects. Our initiatives include
 
 The charter of the Policy WG was to help standardize policy management for Kubernetes and educate the community on best practices.
 
-To accomplish this we updated the Kubernetes documentation ([Policies | Kubernetes](https://kubernetes.io/docs/concepts/policy)), produced several whitepapers ([Kubernetes Policy Management](https://github.com/kubernetes/sig-security/blob/main/sig-security-docs/papers/policy/CNCF_Kubernetes_Policy_Management_WhitePaper_v1.pdf), [Kubernetes GRC](https://github.com/kubernetes/sig-security/blob/main/sig-security-docs/papers/policy_grc/Kubernetes_Policy_WG_Paper_v1_101123.pdf)), and created the Policy Reports API ([API reference](https://htmlpreview.github.io/?https://github.com/kubernetes-sigs/wg-policy-prototypes/blob/master/policy-report/docs/index.html)) which standardizes reporting across various tools. Several popular tools such as Falco, Trivy, Kyverno, kube-bench, and others support the Policy Report API. A major milestone for the Policy WG was promoting the Policy Reports API to a SIG-level API or finding it a stable home.
+To accomplish this we updated the Kubernetes documentation ([Policies | Kubernetes](https://kubernetes.io/docs/concepts/policy)), produced several whitepapers ([Kubernetes Policy Management](https://github.com/kubernetes/sig-security/blob/main/sig-security-docs/papers/policy/CNCF_Kubernetes_Policy_Management_WhitePaper_v1.pdf), [Kubernetes GRC](https://github.com/kubernetes/sig-security/blob/main/sig-security-docs/papers/policy_grc/Kubernetes_Policy_WG_Paper_v1_101123.pdf)), and created the Policy Reports API ([API reference](https://github.com/kubernetes-retired/wg-policy-prototypes/blob/master/policy-report/docs/api-docs.md)) which standardizes reporting across various tools. Several popular tools such as Falco, Trivy, Kyverno, kube-bench, and others support the Policy Report API. A major milestone for the Policy WG was promoting the Policy Reports API to a SIG-level API or finding it a stable home.
 
 Beyond that, as [ValidatingAdmissionPolicy](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/) and [MutatingAdmissionPolicy](https://kubernetes.io/docs/reference/access-authn-authz/mutating-admission-policy/) approached GA in Kubernetes, a key goal of the WG was to guide and educate the community on the tradeoffs and appropriate usage patterns for these built-in API objects and other CNCF policy management solutions like OPA/Gatekeeper and Kyverno.
 

content/en/docs/concepts/configuration/overview.md

@@ -116,7 +116,7 @@ for a comprehensive list.
   MyApp, tier: frontend, phase: test, deployment: v3 }`. You can use these labels to select the
   appropriate Pods for other resources; for example, a Service that selects all `tier: frontend`
   Pods, or all `phase: test` components of `app.kubernetes.io/name: MyApp`.
-  See the [guestbook](https://github.com/kubernetes/examples/tree/master/guestbook/) app
+  See the [guestbook](https://github.com/kubernetes/examples/tree/master/web/guestbook/) app
   for examples of this approach.
 
   A Service can be made to span multiple Deployments by omitting release-specific labels from its

content/en/docs/concepts/workloads/controllers/job.md

@@ -1185,10 +1185,6 @@ Another pattern is for a single Job to create a Pod which then creates other Pod
 of custom controller for those Pods. This allows the most flexibility, but may be somewhat
 complicated to get started with and offers less integration with Kubernetes.
 
-One example of this pattern would be a Job which starts a Pod which runs a script that in turn
-starts a Spark master controller (see [spark example](https://github.com/kubernetes/examples/tree/master/staging/spark/README.md)),
-runs a spark driver, and then cleans up.
-
 An advantage of this approach is that the overall process gets the completion guarantee of a Job
 object, but maintains complete control over what Pods are created and how work is assigned to them.
 

content/en/docs/reference/command-line-tools-reference/feature-gates/ComponentSLIs.md

@@ -13,15 +13,11 @@ stages:
   - stage: beta
     defaultValue: true
     fromVersion: "1.27"
-    toVersion: "1.28"
+    toVersion: "1.31"
   - stage: stable
     defaultValue: true
     locked: true
-    fromVersion: "1.29"
-    toVersion: "1.31"
-
-removed: true
-
+    fromVersion: "1.32"
 ---
 Enable the `/metrics/slis` endpoint on Kubernetes components like
 kubelet, kube-scheduler, kube-proxy, kube-controller-manager, cloud-controller-manager

content/en/docs/reference/command-line-tools-reference/feature-gates/SizeMemoryBackedVolumes.md

@@ -16,11 +16,8 @@ stages:
     toVersion: "1.31"
   - stage: stable
     defaultValue: true
+    locked: true
     fromVersion: "1.32"
-    toVersion: "1.33"
-
-removed: true
-
 ---
 Enable kubelets to determine the size limit for
 memory-backed volumes (mainly `emptyDir` volumes).

content/en/docs/reference/kubectl/kuberc.md

@@ -55,7 +55,7 @@ In this example, the following settings were used:
 With this alias, running `kubectl getn pods` will default JSON output. However,
 if you execute `kubectl getn pods -oyaml`, the output will be in YAML format.
 
-Full `kuberc` schema is available [here](/docs/reference/config-api/kubelet-config.v1beta1/).
+Full `kuberc` schema is available [here](/docs/reference/config-api/kuberc.v1beta1/).
 
 ### prependArgs
 

content/en/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md

@@ -16,14 +16,6 @@ All of these options are possible via the kubeadm configuration API.
 For more details on each field in the configuration you can navigate to our
 [API reference pages](/docs/reference/config-api/kubeadm-config.v1beta4/).
 
-{{< note >}}
-Customizing the CoreDNS deployment of kubeadm is currently not supported. You must manually
-patch the `kube-system/coredns` {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}}
-and recreate the CoreDNS {{< glossary_tooltip text="Pods" term_id="pod" >}} after that. Alternatively,
-you can skip the default CoreDNS deployment and deploy your own variant.
-For more details on that see [Using init phases with kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm-init/#init-phases).
-{{< /note >}}
-
 {{< note >}}
 To reconfigure a cluster that has already been created see
 [Reconfiguring a kubeadm cluster](/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure).
@@ -173,8 +165,8 @@ patches:
 The directory must contain files named `target[suffix][+patchtype].extension`.
 For example, `kube-apiserver0+merge.yaml` or just `etcd.json`.
 
-- `target` can be one of `kube-apiserver`, `kube-controller-manager`, `kube-scheduler`, `etcd`
-and `kubeletconfiguration`.
+- `target` can be one of `kube-apiserver`, `kube-controller-manager`, `kube-scheduler`, `etcd`,
+`kubeletconfiguration` and `corednsdeployment`.
 - `suffix` is an optional string that can be used to determine which patches are applied first
 alpha-numerically.
 - `patchtype` can be one of `strategic`, `merge` or `json` and these must match the patching formats
@@ -217,3 +209,29 @@ For more details you can navigate to our [API reference pages](/docs/reference/c
 kubeadm deploys kube-proxy as a {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}, which means
 that the `KubeProxyConfiguration` would apply to all instances of kube-proxy in the cluster.
 {{< /note >}}
+
+## Customizing CoreDNS
+
+kubeadm allows you to customize the CoreDNS Deployment with patches against the
+[`corednsdeployment` patch target](#patches).
+
+Patches for other CoreDNS related API objects like the `kube-system/coredns`
+{{< glossary_tooltip text="ConfigMap" term_id="configmap" >}} are currently not supported.
+You must manually patch any of these objects using kubectl and recreate the CoreDNS
+{{< glossary_tooltip text="Pods" term_id="pod" >}} after that.
+
+Alternatively, you can disable the kubeadm CoreDNS deployment by including the following
+option in your `ClusterConfiguration`:
+
+```yaml
+dns:
+  disabled: true
+```
+
+Also, by executing the following command:
+
+```shell
+kubeadm init phase addon coredns --print-manifest --config my-config.yaml`
+```
+
+you can obtain the manifest file kubeadm would create for CoreDNS on your setup.

content/en/docs/tasks/configure-pod-container/security-context.md

@@ -191,7 +191,7 @@ kubectl exec -it security-context-demo -- sh
 Check the process identity:
 
 ```shell
-$ id
+id
 ```
 
 The output is similar to this:
@@ -207,7 +207,7 @@ inside the container image.
 Check the `/etc/group` in the container image:
 
 ```shell
-$ cat /etc/group
+cat /etc/group
 ```
 
 You can see that uid `1000` belongs to group `50000`.

content/es/docs/concepts/storage/volumes.md

@@ -293,8 +293,6 @@ Debes configurar FC SAN zoning para asignar y enmascarar esos (volúmenes) LUNs
 para que los hosts Kubernetes pueda acceder a ellos.
 {{< /note >}}
 
-Revisa el [ejemplo de canal de fibra](https://github.com/kubernetes/examples/tree/master/staging/volumes/fibre_channel) para más detalles.
-
 ### flocker (deprecado) {#flocker}
 
 [Flocker](https://github.com/ClusterHQ/flocker) es un administrador open-source de volúmenes de contenedor agrupado por clúster.
@@ -561,8 +559,6 @@ Esto significa que puedes pre-poblar un volumen con tu conjunto de datos y servi
 Desafortunadamente, los volúmenes ISCSI solo se pueden montar por un único consumidor en modo lectura-escritura.
 Escritores simultáneos no está permitido.
 
-Mira el [ejemplo iSCSI](https://github.com/kubernetes/examples/tree/master/volumes/iscsi) para más detalles.
-
 ### local
 
 Un volumen `local` representa un dispositivo de almacenamiento local como un disco, una partición o un directorio.
@@ -635,8 +631,6 @@ NFS puede ser montado por múltiples escritores simultáneamente.
 Debes tener tu propio servidor NFS en ejecución con el recurso compartido exportado antes de poder usarlo.
 {{< /note >}}
 
-Mira el [ ejemplo NFS ](https://github.com/kubernetes/examples/tree/master/staging/volumes/nfs) para más información.
-
 ### persistentVolumeClaim {#persistentvolumeclaim}
 
 Un volumen `persistenceVolumeClain` se utiliza para montar un [PersistentVolume](/docs/concepts/storage/persistent-volumes/) en tu Pod. PersistentVolumeClaims son una forma en que el usuario "reclama" almacenamiento duradero (como un PersistentDisk GCE o un volumen ISCSI) sin conocer los detalles del entorno de la nube en particular.
@@ -675,8 +669,6 @@ spec:
 Asegúrate de tener un PortworxVolume con el nombre `pxvol` antes de usarlo en el Pod.
 {{< /note >}}
 
-Para más detalles, mira los ejemplos de [volumen Portworx](https://github.com/kubernetes/examples/tree/master/staging/volumes/portworx/README.md).
-
 ### projected
 
 Un volumen `projected` mapea distintas fuentes de volúmenes existentes en un mismo directorio.

content/es/docs/concepts/workloads/controllers/statefulset.md

@@ -36,7 +36,7 @@ proporcione un conjunto de réplicas sin estado, como un
 
 ## Limitaciones
 
-* El almacenamiento de un determinado Pod debe provisionarse por un [Provisionador de PersistentVolume](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/README.md) basado en la `storage class` requerida, o pre-provisionarse por un administrador.
+* El almacenamiento de un determinado Pod debe provisionarse por un [Provisionador de PersistentVolume](/docs/concepts/storage/persistent-volumes/) basado en la `storage class` requerida, o pre-provisionarse por un administrador.
 * Eliminar y/o reducir un StatefulSet *no* eliminará los volúmenes asociados con el StatefulSet. Este comportamiento es intencional y sirve para garantizar la seguridad de los datos, que da más valor que la purga automática de los recursos relacionados del StatefulSet.
 * Los StatefulSets actualmente necesitan un [Servicio Headless](/docs/concepts/services-networking/service/#headless-services) como responsable de la identidad de red de los Pods. Es tu responsabilidad crear este Service.
 * Los StatefulSets no proporcionan ninguna garantía de la terminación de los pods cuando se elimina un StatefulSet. Para conseguir un término de los pods ordenado y controlado en el StatefulSet, es posible reducir el StatefulSet a 0 réplicas justo antes de eliminarlo.