[zh] fix typo in `content/zh-cn/docs/concepts`

Signed-off-by: guiyong.ou <guiyong.ou@daocloud.io>

content/zh-cn/docs/concepts/architecture/garbage-collection.md

@@ -278,7 +278,7 @@ kubelet 会持续删除镜像，直到磁盘用量到达 `LowThresholdPercent`
 -->
 #### 未使用容器镜像的垃圾收集     {#image-maximum-age-gc}
 
-{{< feature-state for_k8s_version="v1.29" state="alpha" >}}
+{{< feature-state feature_gate_name="ImageMaximumGCAge" >}}
 
 <!--
 As an alpha feature, you can specify the maximum time a local image can be unused for,
@@ -344,7 +344,7 @@ they are older than `MinAge`.
 除以上变量之外，kubelet 还会垃圾收集除无标识的以及已删除的容器，通常从最近未使用的容器开始。
 
 当保持每个 Pod 的最大数量的容器（`MaxPerPodContainer`）会使得全局的已死亡容器个数超出上限
-（`MaxContainers`）时，`MaxPerPodContainers` 和 `MaxContainers` 之间可能会出现冲突。
+（`MaxContainers`）时，`MaxPerPodContainer` 和 `MaxContainers` 之间可能会出现冲突。
 在这种情况下，kubelet 会调整 `MaxPerPodContainer` 来解决这一冲突。
 最坏的情形是将 `MaxPerPodContainer` 降格为 `1`，并驱逐最近未使用的容器。
 此外，当隶属于某已被删除的 Pod 的容器的年龄超过 `MinAge` 时，它们也会被删除。

content/zh-cn/docs/concepts/policy/limit-range.md

@@ -78,7 +78,7 @@ LimitRange 的名称必须是合法的
 
 - 管理员在一个命名空间内创建一个 `LimitRange` 对象。
 - 用户在此命名空间内创建（或尝试创建） Pod 和 PersistentVolumeClaim 等对象。
-- 首先，`LimitRanger` 准入控制器对所有没有设置计算资源需求的所有 Pod（及其容器）设置默认请求值与限制值。
+- 首先，`LimitRange` 准入控制器对所有没有设置计算资源需求的所有 Pod（及其容器）设置默认请求值与限制值。
 - 其次，`LimitRange` 跟踪其使用量以保证没有超出命名空间中存在的任意 `LimitRange` 所定义的最小、最大资源使用量以及使用量比值。
 - 若尝试创建或更新的对象（Pod 和 PersistentVolumeClaim）违反了 `LimitRange` 的约束，
   向 API 服务器的请求会失败，并返回 HTTP 状态码 `403 Forbidden` 以及描述哪一项约束被违反的消息。

content/zh-cn/docs/concepts/scheduling-eviction/dynamic-resource-allocation.md

@@ -350,7 +350,7 @@ kube-scheduler, kube-controller-manager and kubelet also need the feature gate.
 -->
 动态资源分配是一个 **Alpha 特性**，只有在启用 `DynamicResourceAllocation`
 [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
-和 `resource.k8s.io/v1alpha1`
+和 `resource.k8s.io/v1alpha2`
 {{< glossary_tooltip text="API 组" term_id="api-group" >}} 时才启用。
 有关详细信息，参阅 `--feature-gates` 和 `--runtime-config`
 [kube-apiserver 参数](/zh-cn/docs/reference/command-line-tools-reference/kube-apiserver/)。

content/zh-cn/docs/concepts/security/api-server-bypass-risks.md

@@ -148,7 +148,7 @@ The default anonymous access doesn't make this assertion with the control plane.
  -->
 kubelet API 可以配置为以多种方式验证请求。
 默认情况下，kubelet 的配置允许匿名访问。大多数 Kubernetes 提供商将默认值更改为使用 Webhook 和证书身份认证。
-这使得控制平面能够确保调用者访问 `Node` API 资源或子资源是经过授权的。但控制平面不能确保默认的匿名访问也是如此。
+这使得控制平面能够确保调用者访问 `nodes` API 资源或子资源是经过授权的。但控制平面不能确保默认的匿名访问也是如此。
 
 <!--
 ### Mitigations
@@ -165,7 +165,7 @@ kubelet API 可以配置为以多种方式验证请求。
   is set to webhook or certificate mode.
 - Ensure that the unauthenticated "read-only" Kubelet port is not enabled on the cluster.
  -->
-- 使用 [RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/) 等机制限制对 `Node` API 对象的子资源的访问。
+- 使用 [RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/) 等机制限制对 `nodes` API 对象的子资源的访问。
   只在有需要时才授予此访问权限，例如监控服务。
 - 限制对 kubelet 端口的访问。只允许指定和受信任的 IP 地址段访问该端口。
 - 确保将