[zh-cn]sync assign-pod-level-resources allocate-devices-dra

Signed-off-by: xin.li <[email protected]>

Author: my-git9

content/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd.md

@@ -166,39 +166,22 @@ Edit the file `/var/lib/kubelet/kubeadm-flags.env` and add the containerd runtim
 `--container-runtime-endpoint=unix:///run/containerd/containerd.sock`。
 
 <!--
-Users using kubeadm should be aware that the `kubeadm` tool stores the CRI socket for each host as
-an annotation in the Node object for that host. To change it you can execute the following command
-on a machine that has the kubeadm `/etc/kubernetes/admin.conf` file.
--->
-使用 `kubeadm` 的用户应该知道，`kubeadm` 工具将每个主机的 CRI 套接字保存在该主机对应的
-Node 对象的注解中。
-要更改这一注解信息，你可以在一台包含 kubeadm `/etc/kubernetes/admin.conf` 文件的机器上执行以下命令：
+Users using kubeadm should be aware that the kubeadm tool stores the host's CRI socket in the
+`/var/lib/kubelet/instance-config.yaml` file on each node. You can create this `/var/lib/kubelet/instance-config.yaml` file on the node.
 
-```shell
-kubectl edit no <node-name>
-```
+The `/var/lib/kubelet/instance-config.yaml` file allows setting the `containerRuntimeEndpoint` parameter.
 
-<!--
-This will start a text editor where you can edit the Node object.
-To choose a text editor you can set the `KUBE_EDITOR` environment variable.
-
-- Change the value of `kubeadm.alpha.kubernetes.io/cri-socket` from `/var/run/dockershim.sock`
-  to the CRI socket path of your choice (for example `unix:///run/containerd/containerd.sock`).
-   
-  Note that new CRI socket paths must be prefixed with `unix://` ideally.
-
-- Save the changes in the text editor, which will update the Node object.
+You can set this parameter's value to the path of your chosen CRI socket (for example `unix:///run/containerd/containerd.sock`).
 -->
-这一命令会打开一个文本编辑器，供你在其中编辑 Node 对象。
-要选择不同的文本编辑器，你可以设置 `KUBE_EDITOR` 环境变量。
-
-- 更改 `kubeadm.alpha.kubernetes.io/cri-socket` 值，将其从
-  `/var/run/dockershim.sock` 改为你所选择的 CRI 套接字路径
-  （例如：`unix:///run/containerd/containerd.sock`）。
+使用 kubeadm 的用户应注意，kubeadm 工具在每个节点的
+`/var/lib/kubelet/instance-config.yaml` 文件中存储主机的
+CRI 套接字。你可以在节点上创建这个 `/var/lib/kubelet/instance-config.yaml` 文件。
 
-  注意新的 CRI 套接字路径必须带有 `unix://` 前缀。
+`/var/lib/kubelet/instance-config.yaml` 文件允许设置
+`containerRuntimeEndpoint` 参数。
 
-- 保存文本编辑器中所作的修改，这会更新 Node 对象。
+你可以将此参数的值设置为你所选择的 CRI
+套接字的路径（例如 `unix:///run/containerd/containerd.sock`）。
 
 <!--
 ## Restart the kubelet

content/zh-cn/docs/tasks/configure-pod-container/assign-pod-level-resources.md

@@ -2,13 +2,13 @@
 title: 分配 Pod 级别 CPU 和内存资源
 content_type: task
 weight: 30
-min-kubernetes-server-version: 1.32
+min-kubernetes-server-version: 1.34
 ---
 <!--
 title: Assign Pod-level CPU and memory resources
 content_type: task
 weight: 30
-min-kubernetes-server-version: 1.32
+min-kubernetes-server-version: 1.34
 -->
 
 <!-- overview -->
@@ -73,6 +73,37 @@ for your control plane and for all nodes in your cluster.
 你必须为集群中的控制平面和所有节点启用 `PodLevelResources`
 [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。
 
+<!--
+## Limitations
+
+For Kubernetes {{< skew currentVersion >}}, resizing pod-level resources has the
+following limitations:
+-->
+## 限制     {#limitations}
+
+对于 Kubernetes {{< skew currentVersion >}}，调整 Pod 级别资源的大小有以下限制：
+
+<!--
+* **Resource Types:** Only CPU, memory and hugepages resources can be specified at pod-level.
+* **Operating System:** Pod-level resources are not supported for Windows
+  pods.
+* **Resource Managers:** The Topology Manager, Memory Manager and CPU Manager do not
+  align pods and containers based on pod-level resources as these resource managers 
+  don't currently support pod-level resources.
+* **[In-Place
+  Resize](https://kubernetes.io/docs/tasks/configure-pod-container/resize-container-resources/):**
+  In-place resize of pod-level resources is not supported. Modifying the pod-level resource
+  limits or requests on a pod result in a field.Forbidden error. The error message
+  explicitly states, "pods with pod-level resources cannot be resized."
+-->
+* **资源类型：** 仅支持在 Pod 级别指定 CPU、内存和大页内存资源。
+* **操作系统：** Windows Pod 不支持 Pod 级别资源。
+* **资源管理器：** 拓扑管理器、内存管理器和 CPU 管理器不根据 Pod
+  级别资源对齐 Pod 和容器，因为这些资源管理器目前不支持 Pod 级别资源。
+* **[原地调整大小](/zh-cn/docs/tasks/configure-pod-container/resize-container-resources/)：** 
+  不支持 Pod 级别资源的原地调整大小。修改 Pod 级别的资源限制或请求会导致
+  `field.Forbidden` 错误。错误信息明确指出："pods with pod-level resources cannot be resized"。
+
 <!-- steps -->
 
 <!--

content/zh-cn/docs/tasks/configure-pod-container/assign-resources/allocate-devices-dra.md

@@ -1,13 +1,13 @@
 ---
 title: 使用 DRA 为工作负载分配设备
 content_type: task
-min-kubernetes-server-version: v1.32
+min-kubernetes-server-version: v1.34
 weight: 20
 ---
 <!--
 title: Allocate Devices to Workloads with DRA
 content_type: task
-min-kubernetes-server-version: v1.32
+min-kubernetes-server-version: v1.34
 weight: 20
 -->
 
@@ -25,10 +25,10 @@ with DRA terminology like
 For more information, see
 [Dynamic Resource Allocation (DRA)](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/).
 -->
-本文介绍如何使用**动态资源分配（DRA）**为 Pod 分配设备。
+本文介绍如何使用**动态资源分配（DRA）** 为 Pod 分配设备。
 这些指示说明面向工作负载运维人员。在阅读本文之前，请先了解 DRA 的工作原理以及相关术语，例如
-{{< glossary_tooltip text="ResourceClaims" term_id="resourceclaim" >}} 和
-{{< glossary_tooltip text="ResourceClaimTemplates" term_id="resourceclaimtemplate" >}}。
+{{< glossary_tooltip text="ResourceClaim" term_id="resourceclaim" >}} 和
+{{< glossary_tooltip text="ResourceClaimTemplate" term_id="resourceclaimtemplate" >}}。
 更多信息参阅[动态资源分配（DRA）](/zh-cn/docs/concepts/scheduling-eviction/dynamic-resource-allocation/)。
 
 <!-- body -->
@@ -113,7 +113,7 @@ create a ResourceClaim, do one of the following:
 ## 申领资源 {#claim-resources}
 
 你可以通过
-{{< glossary_tooltip text="ResourceClaims" term_id="resourceclaim" >}}
+{{< glossary_tooltip text="ResourceClaim" term_id="resourceclaim" >}}
 请求某个 DeviceClass 的资源。要创建 ResourceClaim，可以采用以下方式之一：
 
 <!--
@@ -270,6 +270,31 @@ claims in different containers.
    kubectl apply -f https://k8s.io/examples/dra/dra-example-job.yaml
    ```
 
+<!--
+Try the following troubleshooting steps:
+
+1. When the workload does not start as expected, drill down from Job
+   to Pods to ResourceClaims and check the objects
+   at each level with `kubectl describe` to see whether there are any
+   status fields or events which might explain why the workload is
+   not starting.
+1. When creating a Pod fails with `must specify one of: resourceClaimName,
+   resourceClaimTemplateName`, check that all entries in `pod.spec.resourceClaims`
+   have exactly one of those fields set. If they do, then it is possible
+   that the cluster has a mutating Pod webhook installed which was built
+   against APIs from Kubernetes < 1.32. Work with your cluster administrator
+   to check this.
+-->
+尝试以下故障排查步骤：
+
+1. 当工作负载未如预期启动时，从 Job 到 Pod 再到 ResourceClaim 逐步深入检查，
+   并使用 `kubectl describe` 检查每个层级的对象，
+   查看是否有状态字段或事件可以解释工作负载为何没有启动。
+2. 当创建 Pod 失败并显示 `must specify one of：resourceClaimName, resourceClaimTemplateName` 时，
+   检查 `pod.spec.resourceClaims` 中的所有条目是否正好设置了这些字段之一。如果是这样，
+   那么可能是集群安装了一个针对 Kubernetes < 1.32 的 API 构建的 Pod 变更 Webhook。
+   请与你的集群管理员合作检查这个问题。
+
 <!--
 ## Clean up {#clean-up}