From abc95532840fb6f0f1dda93ffc12cd0e6323c7f1 Mon Sep 17 00:00:00 2001
From: zhuzhenghao <zhenghao.zhu@daocloud.io>
Date: Fri, 24 Mar 2023 20:24:13 +0800
Subject: [PATCH] sync minor differences in /concepts

---
 .../concepts/architecture/cloud-controller.md | 65 ++++++++++---------
 .../manage-resources-containers.md            |  9 ++-
 .../services-networking/endpoint-slices.md    | 21 +++---
 3 files changed, 46 insertions(+), 49 deletions(-)

diff --git a/content/zh-cn/docs/concepts/architecture/cloud-controller.md b/content/zh-cn/docs/concepts/architecture/cloud-controller.md
index e2c63cc7e8..98d27f509a 100644
--- a/content/zh-cn/docs/concepts/architecture/cloud-controller.md
+++ b/content/zh-cn/docs/concepts/architecture/cloud-controller.md
@@ -308,45 +308,46 @@ rules:
 ## {{% heading "whatsnext" %}}
 
 <!--
-[Cloud Controller Manager Administration](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)
-has instructions on running and managing the cloud controller manager.
+* [Cloud Controller Manager Administration](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)
+  has instructions on running and managing the cloud controller manager.
 
-To upgrade a HA control plane to use the cloud controller manager, see
-[Migrate Replicated Control Plane To Use Cloud Controller Manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/).
+* To upgrade a HA control plane to use the cloud controller manager, see
+  [Migrate Replicated Control Plane To Use Cloud Controller Manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/).
 
-Want to know how to implement your own cloud controller manager, or extend an existing project?
+* Want to know how to implement your own cloud controller manager, or extend an existing project?
 -->
-[云控制器管理器的管理](/zh-cn/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)
+* [云控制器管理器的管理](/zh-cn/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)
 给出了运行和管理云控制器管理器的指南。
 
-要升级 HA 控制平面以使用云控制器管理器，
+* 要升级 HA 控制平面以使用云控制器管理器，
 请参见[将复制的控制平面迁移以使用云控制器管理器](/zh-cn/docs/tasks/administer-cluster/controller-manager-leader-migration/)。
 
-想要了解如何实现自己的云控制器管理器，或者对现有项目进行扩展么？
+* 想要了解如何实现自己的云控制器管理器，或者对现有项目进行扩展么？
 
-<!--
-The cloud controller manager uses Go interfaces to allow implementations from any cloud to be plugged in.
-Specifically, it uses the `CloudProvider` interface defined in
-[`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.26/cloud.go#L43-L69) from
-[kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider).
--->
-云控制器管理器使用 Go 语言的接口，从而使得针对各种云平台的具体实现都可以接入。
-其中使用了在 [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider)
-项目中 [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.26/cloud.go#L43-L69)
-文件所定义的 `CloudProvider` 接口。
+  <!--
+  - The cloud controller manager uses Go interfaces, specifically, `CloudProvider` interface defined in
+    [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.21/cloud.go#L42-L69)
+    from [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider) to allow
+    implementations from any cloud to be plugged in.
+  -->
+  - 云控制器管理器使用 Go 语言的接口（具体指在
+    [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider)
+    项目中 [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.26/cloud.go#L43-L69)
+    文件中所定义的 `CloudProvider` 接口），从而使得针对各种云平台的具体实现都可以接入。
 
-<!--
-The implementation of the shared controllers highlighted in this document (Node, Route, and Service),
-and some scaffolding along with the shared cloudprovider interface, is part of the Kubernetes core.
-Implementations specific to cloud providers are outside the core of Kubernetes and implement the
-`CloudProvider` interface.
+  <!--
+  - The implementation of the shared controllers highlighted in this document (Node, Route, and Service),
+    and some scaffolding along with the shared cloudprovider interface, is part of the Kubernetes core.
+    Implementations specific to cloud providers are outside the core of Kubernetes and implement
+    the `CloudProvider` interface.
+  -->
+  - 本文中列举的共享控制器（节点控制器、路由控制器和服务控制器等）的实现以及其他一些生成具有
+    CloudProvider 接口的框架的代码，都是 Kubernetes 的核心代码。
+    特定于云驱动的实现虽不是 Kubernetes 核心成分，仍要实现 `CloudProvider` 接口。
 
-For more information about developing plugins, see
-[Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/).
--->
-本文中列举的共享控制器（节点控制器、路由控制器和服务控制器等）的实现以及其他一些生成具有
-CloudProvider 接口的框架的代码，都是 Kubernetes 的核心代码。
-特定于云驱动的实现虽不是 Kubernetes 核心成分，仍要实现 `CloudProvider` 接口。
-
-关于如何开发插件的详细信息，
-可参考[开发云控制器管理器](/zh-cn/docs/tasks/administer-cluster/developing-cloud-controller-manager/)文档。
+  <!--
+  - For more information about developing plugins,
+    see [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/).
+  -->
+  - 关于如何开发插件的详细信息，
+    可参考[开发云控制器管理器](/zh-cn/docs/tasks/administer-cluster/developing-cloud-controller-manager/)文档。
diff --git a/content/zh-cn/docs/concepts/configuration/manage-resources-containers.md b/content/zh-cn/docs/concepts/configuration/manage-resources-containers.md
index ecf9121e9c..22c64cc586 100644
--- a/content/zh-cn/docs/concepts/configuration/manage-resources-containers.md
+++ b/content/zh-cn/docs/concepts/configuration/manage-resources-containers.md
@@ -810,7 +810,7 @@ For example, XFS and ext4fs offer project quotas.
 项目配额（Project Quota）是一个操作系统层的功能特性，用来管理文件系统中的存储用量。
 在 Kubernetes 中，你可以启用项目配额以监视存储用量。
 你需要确保节点上为 `emptyDir` 提供存储的文件系统支持项目配额。
-例如，XFS 和 ext4fs  文件系统都支持项目配额。
+例如，XFS 和 ext4fs 文件系统都支持项目配额。
 
 {{< note >}}
 <!--
@@ -1038,7 +1038,7 @@ extender.
   "apiVersion": "v1",
   "extenders": [
     {
-      "urlPrefix":"<extender-endpoint>",
+      "urlPrefix": "<extender-endpoint>",
       "bindVerb": "bind",
       "managedResources": [
         {
@@ -1289,10 +1289,10 @@ resource, including a configured ResourceQuota.
 包括所配置的 ResourceQuota。
 
 <!--
-### My Container is terminated
+### My container is terminated
 
 Your container might get terminated because it is resource-starved. To check
-whether a Container is being killed because it is hitting a resource limit, call
+whether a container is being killed because it is hitting a resource limit, call
 `kubectl describe pod` on the Pod of interest:
 -->
 
@@ -1384,4 +1384,3 @@ memory limit (and possibly request) for that container.
 * 阅读 XFS 中[配额](https://xfs.org/index.php/XFS_FAQ#Q:_Quota:_Do_quotas_work_on_XFS.3F)的文档
 * 进一步阅读 [kube-scheduler 配置参考 (v1beta3)](/zh-cn/docs/reference/config-api/kube-scheduler-config.v1beta3/)
 * 进一步阅读 [Pod 的服务质量等级](/zh-cn/docs/concepts/workloads/pods/pod-qos/)
-
diff --git a/content/zh-cn/docs/concepts/services-networking/endpoint-slices.md b/content/zh-cn/docs/concepts/services-networking/endpoint-slices.md
index fa3610cafc..615728a216 100644
--- a/content/zh-cn/docs/concepts/services-networking/endpoint-slices.md
+++ b/content/zh-cn/docs/concepts/services-networking/endpoint-slices.md
@@ -1,7 +1,7 @@
 ---
 title: EndpointSlice
 content_type: concept
-weight: 45
+weight: 60
 description: >-
   EndpointSlice API 是 Kubernetes 用于扩缩 Service
   以处理大量后端的机制，还允许集群高效更新其健康后端的列表。
@@ -12,7 +12,7 @@ reviewers:
 - freehan
 title: EndpointSlices
 content_type: concept
-weight: 45
+weight: 60
 description: >-
   The EndpointSlice API is the mechanism that Kubernetes uses to let your Service
   scale to handle large numbers of backends, and allows the cluster to update its
@@ -161,18 +161,18 @@ Services will always have the `ready` condition set to `true`.
 <!--
 #### Serving
 
-{{< feature-state for_k8s_version="v1.22" state="beta" >}}
+{{< feature-state for_k8s_version="v1.26" state="stable" >}}
 
-`serving` is identical to the `ready` condition, except it does not account for terminating states.
-Consumers of the EndpointSlice API should check this condition if they care about pod readiness while
+The `serving` condition is almost identical to the `ready` condition. The difference is that
+consumers of the EndpointSlice API should check the `serving` condition if they care about pod readiness while
 the pod is also terminating.
 -->
 #### Serving（服务中）
 
-{{< feature-state for_k8s_version="v1.22" state="beta" >}}
+{{< feature-state for_k8s_version="v1.26" state="stable" >}}
 
-`serving` 状况与 `ready` 状况相同，不同之处在于它不考虑终止状态。
-如果 EndpointSlice API 的使用者关心 Pod 终止时的就绪情况，就应检查此状况。
+`serving` 状况几乎与 `ready` 状况相同，不同之处在于它不考虑终止状态。
+如果 EndpointSlice API 的使用者关心 Pod 终止时的就绪情况，就应检查 `serving` 状况。
 
 {{< note >}}
 <!--
@@ -191,7 +191,7 @@ for terminating pods independent of the existing semantics for `ready`.
 的现有语义来跟踪处于终止中的 Pod 的就绪情况。
 {{< /note >}}
 
-<!-- 
+<!--
 #### Terminating
 
 {{< feature-state for_k8s_version="v1.22" state="beta" >}}
@@ -470,7 +470,6 @@ less noticeable; even then, some use cases of Kubernetes weren't well served.
 对象可能变得非常巨大。对于保持稳定的服务（长时间使用同一组端点），影响不太明显；
 即便如此，Kubernetes 的一些使用场景也没有得到很好的服务。
 
-
 <!--
 When a Service had a lot of backend endpoints and the workload was either
  scaling frequently, or rolling out new changes frequently, each update to
@@ -507,5 +506,3 @@ EndpointSlices 还支持围绕双栈网络和拓扑感知路由等新功能的
 * 遵循[使用 Service 连接到应用](/zh-cn/docs/tutorials/services/connect-applications-service/)教程
 * 阅读 EndpointSlice API 的 [API 参考](/zh-cn/docs/reference/kubernetes-api/service-resources/endpoint-slice-v1/)
 * 阅读 Endpoints API 的 [API 参考](/zh-cn/docs/reference/kubernetes-api/service-resources/endpoints-v1/)
-
-