Merge pull request #52088 from my-git9/npa-12089

[zh-cn]sync storage-limits container-runtimes define-environment-variable-container debug

Author: k8s-ci-robot

content/zh-cn/docs/concepts/storage/storage-limits.md

@@ -58,29 +58,6 @@ Kubernetes 调度器对挂接到一个节点的卷数有默认限制：
   <tr><td><a href="https://azure.microsoft.com/en-us/services/storage/main-disks/">Microsoft Azure Disk Storage</a></td><td>16</td></tr>
 </table>
 
-<!--
-## Custom limits
-
-You can change these limits by setting the value of the
-`KUBE_MAX_PD_VOLS` environment variable, and then starting the scheduler.
-CSI drivers might have a different procedure, see their documentation
-on how to customize their limits.
-
-Use caution if you set a limit that is higher than the default limit. Consult
-the cloud provider's documentation to make sure that Nodes can actually support
-the limit you set.
-
-The limit applies to the entire cluster, so it affects all Nodes.
--->
-## 自定义限制   {#custom-limits}
-
-你可以通过设置 `KUBE_MAX_PD_VOLS` 环境变量的值来设置这些限制，然后再启动调度器。
-各个 CSI 驱动可能采用不同的步骤，关于如何自定义其限制请参阅相关文档。
-
-如果设置的限制高于默认限制，请谨慎使用。请参阅云提供商的文档以确保节点可支持你设置的限制。
-
-此限制应用于整个集群，所以它会影响所有节点。
-
 <!--
 ## Dynamic volume limits
 -->
@@ -90,11 +67,6 @@ The limit applies to the entire cluster, so it affects all Nodes.
 
 <!--
 Dynamic volume limits are supported for following volume types.
-
-- Amazon EBS
-- Google Persistent Disk
-- Azure Disk
-- CSI
 -->
 以下卷类型支持动态卷限制。
 
@@ -114,17 +86,18 @@ type and enforces the appropriate maximum number of volumes for the node. For ex
 <a href="https://cloud.google.com/compute/">Google Compute Engine</a>,
 up to 127 volumes can be attached to a node, [depending on the node
 type](https://cloud.google.com/compute/docs/disks/#pdnumberlimits).
+-->
+* 在 <a href="https://cloud.google.com/compute/">Google Compute Engine</a> 环境中，
+  [根据节点类型](https://cloud.google.com/compute/docs/disks/#pdnumberlimits)最多可以将 127 个卷挂接到节点。
 
+<!--
 * For Amazon EBS disks on M5,C5,R5,T3 and Z1D instance types, Kubernetes allows only 25
 volumes to be attached to a Node. For other instance types on
 <a href="https://aws.amazon.com/ec2/">Amazon Elastic Compute Cloud (EC2)</a>,
 Kubernetes allows 39 volumes to be attached to a Node.
 
 * On Azure, up to 64 disks can be attached to a node, depending on the node type. For more details, refer to [Sizes for virtual machines in Azure](https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes).
 -->
-* 在 <a href="https://cloud.google.com/compute/">Google Compute Engine</a> 环境中，
-  [根据节点类型](https://cloud.google.com/compute/docs/disks/#pdnumberlimits)最多可以将 127 个卷挂接到节点。
-
 * 对于 M5、C5、R5、T3 和 Z1D 实例类型的 Amazon EBS 磁盘，Kubernetes 仅允许 25 个卷挂接到节点。
   对于 <a href="https://aws.amazon.com/ec2/">Amazon Elastic Compute Cloud (EC2)</a> 上的其他实例类型，
   Kubernetes 允许 39 个卷挂接至节点。
@@ -149,20 +122,15 @@ Refer to the [CSI specifications](https://github.com/container-storage-interface
 -->
 ### 可变的 CSI 节点可分配数   {#mutable-csi-node-allocatable-count}
 
-{{< feature-state state="alpha" for_k8s_version="v1.33" >}}
+{{< feature-state feature_gate_name="MutableCSINodeAllocatableCount" >}}
 
 <!--
 CSI drivers can dynamically adjust the maximum number of volumes that can be attached to a Node at runtime. This enhances scheduling accuracy and reduces pod scheduling failures due to changes in resource availability.
--->
-CSI 驱动可以在运行时动态调整可以挂载到 Node 的最大卷数量。
-这提高了调度准确性，并减少了由于资源可用性变化导致的 Pod 调度失败。
-
-<!--
-This is an alpha feature and is disabled by default.
 
 To use this feature, you must enable the `MutableCSINodeAllocatableCount` feature gate on the following components:
 -->
-这是一个 Alpha 级别特性，默认情况下是禁用的。
+CSI 驱动可以在运行时动态调整可以挂载到 Node 的最大卷数量。
+这提高了调度准确性，并减少了由于资源可用性变化导致的 Pod 调度失败。
 
 要使用此特性，你必须在以下组件上启用 `MutableCSINodeAllocatableCount`
 特性门控：
@@ -198,7 +166,13 @@ kubelet 将使用 `nodeAllocatableUpdatePeriodSeconds`
 端点来刷新可挂接卷的最大数量。此字段允许的最小值为 10 秒。
 
 <!--
-Additionally, if a volume attachment operation fails with a `ResourceExhausted` error (gRPC code 8), Kubernetes triggers an immediate update to the allocatable volume count for that Node.
+If a volume attachment operation fails with a `ResourceExhausted` error (gRPC code 8),
+Kubernetes triggers an immediate update to the allocatable volume count for that Node.
+Additionally, kubelet marks affected pods as Failed, allowing their controllers to
+handle recreation. This prevents pods from getting stuck indefinitely in the
+`ContainerCreating` state.
 -->
-此外，如果卷挂接操作失败并返回 `ResourceExhausted` 错误（gRPC 代码 8），
-Kubernetes 会立即触发对该 Node 的可分配卷数量的更新。
+如果卷挂载操作失败并返回 `ResourceExhausted` 错误（gRPC 代码 8），
+Kubernetes 会立即触发对此节点可分配卷数量的更新。此外，kubelet
+会将受影响的 Pod 标记为 Failed，从而使它们的控制器处理重新创建。
+这防止了 Pod 无限期地停留在 `ContainerCreating` 状态。

content/zh-cn/docs/setup/production-environment/container-runtimes.md

@@ -263,6 +263,22 @@ and ignores the `cgroupDriver` setting within the kubelet configuration.
 `RuntimeConfig` CRI RPC 的容器运行时，kubelet 会自动从运行时检测适当的 Cgroup
 驱动程序，并忽略 kubelet 配置中的 `cgroupDriver` 设置。
 
+<!--
+However, older versions of container runtimes (specifically,
+containerd 1.y and below) do not support the `RuntimeConfig` CRI RPC, and
+may not respond correctly to this query, and thus the Kubelet falls back to using the
+value in its own `--cgroup-driver` flag.
+
+In Kubernetes 1.36, this fallback behavior will be dropped, and older versions
+of containerd will fail with newer kubelets.
+-->
+然而，较旧版本的容器运行时（特别是 containerd 1.y 及以下版本）
+不支持 `RuntimeConfig` CRI RPC，可能无法正确响应此查询。
+因此，kubelet 会回退到使用其自身的 `--cgroup-driver` 标志中的值。
+
+在 Kubernetes 1.36 中，这种回退行为将被移除，旧版本的 containerd
+将无法与新版本的 kubelet 一起工作。
+
 {{< caution >}}
 <!--
 Changing the cgroup driver of a Node that has joined a cluster is a sensitive operation. 

content/zh-cn/docs/tasks/debug/_index.md

@@ -206,21 +206,21 @@ Turkey | [`#tr-users`](https://kubernetes.slack.com/messages/tr-users), [`#tr-ev
 -->
 国家   | 频道
 :------|:------------
-中国   | [`#cn-users`](https://kubernetes.slack.com/messages/cn-users), [`#cn-events`](https://kubernetes.slack.com/messages/cn-events)
+中国   | [`#cn-users`](https://kubernetes.slack.com/messages/cn-users)、[`#cn-events`](https://kubernetes.slack.com/messages/cn-events)
 芬兰   | [`#fi-users`](https://kubernetes.slack.com/messages/fi-users)
-法国   | [`#fr-users`](https://kubernetes.slack.com/messages/fr-users), [`#fr-events`](https://kubernetes.slack.com/messages/fr-events)
-德国   | [`#de-users`](https://kubernetes.slack.com/messages/de-users), [`#de-events`](https://kubernetes.slack.com/messages/de-events)
-印度   | [`#in-users`](https://kubernetes.slack.com/messages/in-users), [`#in-events`](https://kubernetes.slack.com/messages/in-events)
-意大利 | [`#it-users`](https://kubernetes.slack.com/messages/it-users), [`#it-events`](https://kubernetes.slack.com/messages/it-events)
-日本   | [`#jp-users`](https://kubernetes.slack.com/messages/jp-users), [`#jp-events`](https://kubernetes.slack.com/messages/jp-events)
+法国   | [`#fr-users`](https://kubernetes.slack.com/messages/fr-users)、[`#fr-events`](https://kubernetes.slack.com/messages/fr-events)
+德国   | [`#de-users`](https://kubernetes.slack.com/messages/de-users)、[`#de-events`](https://kubernetes.slack.com/messages/de-events)
+印度   | [`#in-users`](https://kubernetes.slack.com/messages/in-users)、[`#in-events`](https://kubernetes.slack.com/messages/in-events)
+意大利 | [`#it-users`](https://kubernetes.slack.com/messages/it-users)、[`#it-events`](https://kubernetes.slack.com/messages/it-events)
+日本   | [`#jp-users`](https://kubernetes.slack.com/messages/jp-users)、[`#jp-events`](https://kubernetes.slack.com/messages/jp-events)
 韩国   | [`#kr-users`](https://kubernetes.slack.com/messages/kr-users)
 荷兰   | [`#nl-users`](https://kubernetes.slack.com/messages/nl-users)
 挪威   | [`#norw-users`](https://kubernetes.slack.com/messages/norw-users)
 波兰   | [`#pl-users`](https://kubernetes.slack.com/messages/pl-users)
 俄罗斯 | [`#ru-users`](https://kubernetes.slack.com/messages/ru-users)
 西班牙 | [`#es-users`](https://kubernetes.slack.com/messages/es-users)
 瑞典   | [`#se-users`](https://kubernetes.slack.com/messages/se-users)
-土耳其 | [`#tr-users`](https://kubernetes.slack.com/messages/tr-users), [`#tr-events`](https://kubernetes.slack.com/messages/tr-events)
+土耳其 | [`#tr-users`](https://kubernetes.slack.com/messages/tr-users)、[`#tr-events`](https://kubernetes.slack.com/messages/tr-events)
 
 {{< /table >}}
 

content/zh-cn/docs/tasks/inject-data-application/define-environment-variable-container.md

@@ -174,14 +174,11 @@ as a CLI argument passed to the `env-print-demo` container.
 然后再传递给容器 `env-print-demo` 的 CLI 参数中使用。
 
 <!--
-Environment variable names consist of letters, numbers, underscores,
-dots, or hyphens, but the first character cannot be a digit.
-If the `RelaxedEnvironmentVariableValidation` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled,
-all [printable ASCII characters](https://www.ascii-code.com/characters/printable-characters) except "=" may be used for environment variable names.
+Environment variable names may consist of any [printable ASCII characters](https://www.ascii-code.com/characters/printable-characters) except '='.
 -->
-环境变量名由字母、数字、下划线、点或连字符组成，但第一个字符不能是数字。
-如果启用了 `RelaxedEnvironmentVariableValidation` 特性门控，
-则所有可打印的 ASCII 字符（"=" 除外）都可以用于环境变量名。
+环境变量名称可以由除了 '='
+外的任何[可打印的 ASCII](https://www.ascii-code.com/characters/printable-characters)
+字符组成。
 
 ```yaml
 apiVersion: v1
@@ -218,4 +215,3 @@ Upon creation, the command `echo Warm greetings to The Most Honorable Kubernetes
 * 进一步了解[环境变量](/zh-cn/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)
 * 进一步了解[通过环境变量来使用 Secret](/zh-cn/docs/concepts/configuration/secret/#using-secrets-as-environment-variables)
 * 关于 [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core) 资源的信息。
-