Merge branch 'main' of https://github.com/ductnn/website into glossary-persistence-volume

Author: ductnn

content/de/docs/tutorials/hello-minikube.md

@@ -71,7 +71,7 @@ Deployments sind die empfohlene Methode zum Verwalten der Erstellung und Skalier
 Der Pod führt einen Container basierend auf dem bereitgestellten Docker-Image aus.
 
     ```shell
-    kubectl create deployment hello-node --image=registry.k8s.io/echoserver:1.4
+    kubectl create deployment hello-node --image=registry.k8s.io/e2e-test-images/agnhost:2.53 -- /agnhost netexec --http-port=8080
     ```
 
 2. Anzeigen des Deployments:

content/en/blog/_posts/2025-09-08-volume-attributes-class-ga/index.md

@@ -27,9 +27,9 @@ This means you can now:
 
 There are two major enhancements from beta.
 
-### Cancel support from infeasible errors
+### Cancellation support when errors occur
 
-To improve resilience and user experience, the GA release introduces explicit cancel support when a requested volume modification becomes infeasible. If the underlying storage system or CSI driver indicates that the requested changes cannot be applied (e.g., due to invalid arguments), users can cancel the operation and revert the volume to its previous stable configuration, preventing the volume from being left in an inconsistent state.
+To improve resilience and user experience, the GA release introduces explicit cancel support when a requested volume modification encounters an error. If the underlying storage system or CSI driver indicates that the requested changes cannot be applied (e.g., due to invalid arguments), users can cancel the operation and revert the volume to its previous stable configuration, preventing the volume from being left in an inconsistent state.
 
 
 ### Quota support based on scope

content/it/docs/tutorials/hello-minikube.md

@@ -76,7 +76,7 @@ modalità raccomandata per gestire la creazione e lo scaling dei Pods.
 eseguirà un Container basato sulla Docker image specificata.
 
     ```shell
-    kubectl create deployment hello-node --image=registry.k8s.io/echoserver:1.4
+    kubectl create deployment hello-node --image=registry.k8s.io/e2e-test-images/agnhost:2.53 -- /agnhost netexec --http-port=8080
     ```
 
 2. Visualizza il Deployment:

content/pl/_index.html

@@ -50,7 +50,7 @@ <h2>Przewodnik dla absolutnie początkujących po Cloud Native</h2>
 </div>
 {{< /blocks/section >}}
 {{< blocks/section id="upcoming-events" >}}
-<h2>Weź udział w nadchodzących wydarzeniach KubeCon + CloudNativeCon</h3>
+<h2>Weź udział w nadchodzących wydarzeniach KubeCon + CloudNativeCon</h2>
   <!-- TODO: change this to a shortcode that auto-updates from a schedule -->
   <div>
     <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/" class="desktopKCButton"><strong>Ameryka Północna</strong> (Atlanta, 10-13 listopada)</a>

content/pl/docs/tutorials/_index.md

@@ -57,6 +57,7 @@ kroków. Przed zapoznaniem się z samouczkami warto stworzyć zakładkę do
 
 ## Zarządzanie Klastrem {#cluster-management}
 
+* [Configuring Swap Memory on Kubernetes Nodes](/docs/tutorials/cluster-management/provision-swap-memory/)
 * [Running Kubelet in Standalone Mode](/docs/tutorials/cluster-management/kubelet-standalone/)
 * [Install Drivers and Allocate Devices with DRA](/docs/tutorials/cluster-management/install-use-dra/)
 

content/pl/docs/tutorials/hello-minikube.md

@@ -91,7 +91,7 @@ Użycie Deploymentu to rekomendowana metoda zarządzania tworzeniem i skalowanie
 wykorzystując podany obraz Dockera.
 
     ```shell
-    kubectl create deployment hello-node --image=registry.k8s.io/e2e-test-images/agnhost:2.39 -- /agnhost netexec --http-port=8080
+    kubectl create deployment hello-node --image=registry.k8s.io/e2e-test-images/agnhost:2.53 -- /agnhost netexec --http-port=8080
     ```
 
 2. Sprawdź stan Deploymentu:

content/zh-cn/docs/concepts/scheduling-eviction/topology-spread-constraints.md

@@ -127,9 +127,9 @@ spec:
       topologyKey: <string>
       whenUnsatisfiable: <string>
       labelSelector: <object>
-      matchLabelKeys: <list> # 可选；自从 v1.27 开始成为 Beta
-      nodeAffinityPolicy: [Honor|Ignore] # 可选；自从 v1.26 开始成为 Beta
-      nodeTaintsPolicy: [Honor|Ignore] # 可选；自从 v1.26 开始成为 Beta
+      matchLabelKeys: <list> # 可选；从 v1.27 开始成为 Beta
+      nodeAffinityPolicy: [Honor|Ignore] # 可选；从 v1.26 开始成为 Beta
+      nodeTaintsPolicy: [Honor|Ignore] # 可选；从 v1.26 开始成为 Beta
   ### 其他 Pod 字段置于此处
 ```
 
@@ -248,32 +248,48 @@ your cluster. Those fields are:
   有关详细信息，请参考[标签选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/#label-selectors)。
 
 <!--
-- **matchLabelKeys** is a list of pod label keys to select the pods over which
-  spreading will be calculated. The keys are used to lookup values from the pod labels,
-  those key-value labels are ANDed with `labelSelector` to select the group of existing
-  pods over which spreading will be calculated for the incoming pod. The same key is
-  forbidden to exist in both `matchLabelKeys` and `labelSelector`. `matchLabelKeys` cannot
-  be set when `labelSelector` isn't set. Keys that don't exist in the pod labels will be
-  ignored. A null or empty list means only match against the `labelSelector`.
+- **matchLabelKeys** is a list of pod label keys to select the group of pods over which 
+  the spreading skew will be calculated. At a pod creation, 
+  the kube-apiserver uses those keys to lookup values from the incoming pod labels,
+  and those key-value labels will be merged with any existing `labelSelector`.
+  The same key is forbidden to exist in both `matchLabelKeys` and `labelSelector`. 
+  `matchLabelKeys` cannot be set when `labelSelector` isn't set. 
+  Keys that don't exist in the pod labels will be ignored. 
+  A null or empty list means only match against the `labelSelector`.
+-->
+- - **matchLabelKeys** 是一个 Pod 标签键的列表，用于选择计算分布偏差的 Pod 组。在创建 Pod 时，
+  kube-apiserver 使用这些键从传入的 Pod 标签中查找值，并将这些键值标签与现有的 `labelSelector` 合并。
+  相同的键不允许同时出现在 `matchLabelKeys` 和 `labelSelector` 中。
+  当 `labelSelector` 未设置时，不能设置 `matchLabelKeys`。
+  如果键在 Pod 标签中不存在，则会被忽略。
+  一个空或 `null` 的列表意味着仅与 `labelSelector` 匹配。
+
+  {{< caution >}}
+  <!--
+  It's not recommended to use `matchLabelKeys` with labels that might be updated directly on pods.
+  Even if you edit the pod's label that is specified at `matchLabelKeys` **directly**,
+  (that is, you edit the Pod and not a Deployment),
+  kube-apiserver doesn't reflect the label update onto the merged `labelSelector`.
+  -->
+  不建议将 `matchLabelKeys` 与可能直接在 Pod 上更新的标签一起使用。
+  即使你**直接**编辑了位于 `matchLabelKeys` 中指定的 Pod 标签，
+  （也就是说，你编辑的是 Pod 而不是 Deployment），
+  kube-apiserver 不会将标签更新反映到合并的 `labelSelector` 上。
+  {{< /caution >}}
 
+
+<!--
   With `matchLabelKeys`, you don't need to update the `pod.spec` between different revisions.
   The controller/operator just needs to set different values to the same label key for different
-  revisions. The scheduler will assume the values automatically based on `matchLabelKeys`. For
-  example, if you are configuring a Deployment, you can use the label keyed with
+  revisions. For example, if you are configuring a Deployment, you can use the label keyed with
   [pod-template-hash](/docs/concepts/workloads/controllers/deployment/#pod-template-hash-label), which
   is added automatically by the Deployment controller, to distinguish between different revisions
   in a single Deployment.
 -->
-- **matchLabelKeys** 是一个 Pod 标签键的列表，用于选择需要计算分布方式的 Pod 集合。
-  这些键用于从 Pod 标签中查找值，这些键值标签与 `labelSelector` 进行逻辑与运算，以选择一组已有的 Pod，
-  通过这些 Pod 计算新来 Pod 的分布方式。`matchLabelKeys` 和 `labelSelector` 中禁止存在相同的键。
-  未设置 `labelSelector` 时无法设置 `matchLabelKeys`。Pod 标签中不存在的键将被忽略。
-  null 或空列表意味着仅与 `labelSelector` 匹配。
-
   借助 `matchLabelKeys`，你无需在变更 Pod 修订版本时更新 `pod.spec`。
   控制器或 Operator 只需要将不同修订版的标签键设为不同的值。
-  调度器将根据 `matchLabelKeys` 自动确定取值。例如，如果你正在配置一个 Deployment，
-  则你可以使用由 Deployment 控制器自动添加的、以
+  例如，如果你正在配置一个 Deployment，则可以使用由 Deployment
+  控制器自动添加的、以
   [pod-template-hash](/zh-cn/docs/concepts/workloads/controllers/deployment/#pod-template-hash-label)
   为键的标签来区分同一个 Deployment 的不同修订版。
 
@@ -297,6 +313,17 @@ your cluster. Those fields are:
   `matchLabelKeys` 字段是 1.27 中默认启用的一个 Beta 级别字段。
   你可以通过禁用 `MatchLabelKeysInPodTopologySpread`
   [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)来禁用此字段。
+
+  <!--
+  Before v1.34, `matchLabelKeys` was handled implicitly.
+  Since v1.34, key-value labels corresponding to `matchLabelKeys` are explicitly merged into `labelSelector`.
+  You can disable it and revert to the previous behavior by disabling the `MatchLabelKeysInPodTopologySpreadSelectorMerge` 
+  [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) of kube-apiserver.
+  -->
+  在 v1.34 之前，`matchLabelKeys` 是隐式处理的。
+  从 v1.34 开始，与 `matchLabelKeys` 对应的键值标签会被明确地合并到 `labelSelector` 中。
+  你可以通过禁用 kube-apiserver 的 `MatchLabelKeysInPodTopologySpreadSelectorMerge`
+  [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)来禁用此行为并恢复到之前的行为。
   {{< /note >}}
 
 <!--

content/zh-cn/docs/reference/access-authn-authz/node.md

@@ -55,15 +55,9 @@ Read operations:
 {{< feature-state feature_gate_name="AuthorizeNodeWithSelectors" >}}
 
 <!--
-When the `AuthorizeNodeWithSelectors` feature is enabled
-(along with the pre-requisite `AuthorizeWithSelectors` feature),
-kubelets are only allowed to read their own Node objects,
-and are only allowed to read pods bound to their node.
--->
-当启用 `AuthorizeNodeWithSelectors` 特性
-（以及作为先决条件的 `AuthorizeWithSelectors` 特性）时，
-kubelet 只允许读取它们自己的 Node 对象，
-并且只允许读取绑定到其节点的 Pod。
+Kubelets are limited to reading their own Node objects, and only reading pods bound to their node.
+-->
+kubelet 仅限于读取自己的节点对象，以及与节点绑定的 Pod。
 
 <!--
 Write operations:

content/zh-cn/docs/reference/command-line-tools-reference/feature-gates/KubeletPodResourcesDynamicResources.md

@@ -8,17 +8,20 @@ _build:
 stages:
   - stage: alpha
     defaultValue: false
-    fromVersion: "1.27"  
+    fromVersion: "1.27"
+    toVersion: "1.33"
+  - stage: beta
+    defaultValue: true
+    fromVersion: "1.34"
 ---
 
 <!--
-Extend the kubelet's pod resources gRPC endpoint to
-to include resources allocated in `ResourceClaims` via `DynamicResourceAllocation` API.
-See [resource allocation reporting](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#monitoring-device-plugin-resources) for more details.
-with information about the allocatable resources, enabling clients to properly
-track the free compute resources on a node.
+Extend the kubelet's
+[pod resources monitoring gRPC API](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md)
+endpoints List and Get to include resources allocated in ResourceClaims
+via [Dynamic Resource Allocation](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/).
 -->
-扩展 kubelet 的 Pod 资源 gRPC 端点以包括通过
-`DynamicResourceAllocation` API 在 `ResourceClaims` 中分配的资源。
-详情参见[资源分配报告](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#monitoring-device-plugin-resources)。
-包含有关可分配资源的信息，使客户端能够正确跟踪节点上的可用计算资源。
+扩展 kubelet 的 [Pod 资源监控 gRPC API](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
+端点 List 和 Get，
+以包括通过[资源分配报告](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#monitoring-device-plugin-resources)在
+ResourceClaim 中分配的资源。