Merge pull request #45719 from asa3311/sync-zh-109

[zh] sync rbac-good-practices autoscaling

Author: k8s-ci-robot

content/zh-cn/docs/concepts/security/rbac-good-practices.md

@@ -369,6 +369,20 @@ mutating webhooks, also mutate admitted objects.
 的用户可以控制能读取任何允许进入集群的对象的 webhook，
 并且在有变更 webhook 的情况下，还可以变更准入的对象。
 
+<!--
+### Namespace modification
+
+Users who can perform **patch** operations on Namespace objects (through a namespaced RoleBinding to a Role with that access) can modify
+labels on that namespace. In clusters where Pod Security Admission is used, this may allow a user to configure the namespace
+for a more permissive policy than intended by the administrators.
+For clusters where NetworkPolicy is used, users may be set labels that indirectly allow
+access to services that an administrator did not intend to allow.
+-->
+### 命名空间修改 {#namespace-modification}
+可以对命名空间对象执行 **patch** 操作的用户（通过命名空间内的 RoleBinding 关联到具有该权限的 Role），
+可以修改该命名空间的标签。在使用 Pod 安全准入的集群中，这可能允许用户将命名空间配置为比管理员预期更宽松的策略。
+对于使用 NetworkPolicy 的集群，用户所设置的标签可能间接导致对某些本不应被允许访问的服务的访问权限被开放。
+
 <!--
 ## Kubernetes RBAC - denial of service risks {#denial-of-service-risks}
 

content/zh-cn/docs/concepts/workloads/autoscaling.md

@@ -266,20 +266,14 @@ If scaling workloads isn't enough to meet your needs, you can also scale your cl
 
 <!--
 Scaling the cluster infrastructure normally means adding or removing {{< glossary_tooltip text="nodes" term_id="node" >}}.
-This can be done using one of two available autoscalers:
 -->
 扩缩集群基础设施通常是指增加或移除{{< glossary_tooltip text="节点" term_id="node" >}}。
-这可以通过以下两种自动扩缩器中的任意一种实现：
-
-- [**Cluster Autoscaler**](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler)
-- [**Karpenter**](https://github.com/kubernetes-sigs/karpenter?tab=readme-ov-file)
 
 <!--
-Both scalers work by watching for pods marked as _unschedulable_ or _underutilized_ nodes and then adding or
-removing nodes as needed.
+Read [cluster autoscaling](/docs/concepts/cluster-administration/cluster-autoscaling/)
+for more information.
 -->
-这两种扩缩器的工作原理都是通过监测节点上被标记为 **unschedulable** 或 **underutilized** 的 Pod 数量，
-然后根据需要增加或移除节点。
+阅读[集群自动扩缩](/zh-cn/docs/concepts/cluster-administration/cluster-autoscaling/)了解更多信息。
 
 ## {{% heading "whatsnext" %}}
 
@@ -289,9 +283,11 @@ removing nodes as needed.
   - [HorizontalPodAutoscaler Walkthrough](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)
 - [Resize Container Resources In-Place](/docs/tasks/configure-pod-container/resize-container-resources/)
 - [Autoscale the DNS Service in a Cluster](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/)
+- Learn about [cluster autoscaling](/docs/concepts/cluster-administration/cluster-autoscaling/)
 -->
 - 了解有关横向扩缩的更多信息
   - [扩缩 StatefulSet](/zh-cn/docs/tasks/run-application/scale-stateful-set/)
   - [HorizontalPodAutoscaler 演练](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)
 - [调整分配给容器的 CPU 和内存资源](/zh-cn/docs/tasks/configure-pod-container/resize-container-resources/)
 - [自动扩缩集群 DNS 服务](/zh-cn/docs/tasks/administer-cluster/dns-horizontal-autoscaling/)
+- 了解[集群自动扩缩]((/zh-cn/docs/concepts/cluster-administration/cluster-autoscaling/))