Merge pull request #32635 from tengqm/zh-resync-working-with-objs

[zh] Resync pages under working-with-objects

content/zh/docs/concepts/overview/working-with-objects/_index.md

@@ -1,6 +1,7 @@
 ---
-title: "使用 Kubernetes 对象"
+title: 使用 Kubernetes 对象
 weight: 40
 description: >
-  Kubernetes 对象是 Kubernetes 系统中的持久性实体。Kubernetes 使用这些实体表示您的集群状态。了解 Kubernetes 对象模型以及如何使用这些对象。
+  Kubernetes 对象是 Kubernetes 系统中的持久性实体。Kubernetes 使用这些实体表示你的集群状态。
+  了解 Kubernetes 对象模型以及如何使用这些对象。
 ---

content/zh/docs/concepts/overview/working-with-objects/finalizers.md

@@ -32,32 +32,37 @@ Kubernetes 自动指定了一些 Finalizers，但你也可以指定你自己的
 
 When you create a resource using a manifest file, you can specify finalizers in
 the `metadata.finalizers` field. When you attempt to delete the resource, the
-controller that manages it notices the values in the `finalizers` field and does
-the following: 
+API server handling the delete request notices the values in the `finalizers` field
+and does the following: 
 
   * Modifies the object to add a `metadata.deletionTimestamp` field with the
     time you started the deletion.
-  * Marks the object as read-only until its `metadata.finalizers` field is empty.
+  * Prevents the object from being removed until its `metadata.finalizers` field is empty.
+  * Returns a `202` status code (HTTP "Accepted")
 -->
 ## Finalizers 如何工作   {#how-finalizers-work}
 
 当你使用清单文件创建资源时，你可以在 `metadata.finalizers` 字段指定 Finalizers。
-当你试图删除该资源时，管理该资源的控制器会注意到 `finalizers` 字段中的值，
+当你试图删除该资源时，处理删除请求的 API 服务器会注意到 `finalizers` 字段中的值，
 并进行以下操作：
 
   * 修改对象，将你开始执行删除的时间添加到 `metadata.deletionTimestamp` 字段。
-  * 将该对象标记为只读，直到其 `metadata.finalizers` 字段为空。
+  * 禁止对象被删除，直到其 `metadata.finalizers` 字段为空。
+  * 返回 `202` 作为状态码（HTTP "Accepted"）。
 
 <!--
+The controller managing that finalizer notices the update to the object setting the
+`metadata.deletionTimestamp`, indicating deletion of the object has been requested.
 The controller then attempts to satisfy the requirements of the finalizers
 specified for that resource. Each time a finalizer condition is satisfied, the
 controller removes that key from the resource's `finalizers` field. When the
-field is empty, garbage collection continues. You can also use finalizers to
-prevent deletion of unmanaged resources.
+`finalizers` field is emptied, an object with a `deletionTimestamp` field set
+is automatically deleted. You can also use finalizers to prevent deletion of unmanaged resources.
 -->
-然后，控制器试图满足资源的 Finalizers 的条件。
+管理 finalizer 的控制器注意到对象上发生的更新操作，对象的 `metadata.deletionTimestamp`
+被设置，意味着已经请求删除该对象。然后，控制器会试图满足资源的 Finalizers 的条件。
 每当一个 Finalizer 的条件被满足时，控制器就会从资源的 `finalizers` 字段中删除该键。
-当该字段为空时，垃圾收集继续进行。
+当 `finalizers` 字段为空时，`deletionTimestamp` 字段被设置的对象会被自动删除。
 你也可以使用 Finalizers 来阻止删除未被管理的资源。
 
 <!--
@@ -111,7 +116,7 @@ Kubernetes also processes finalizers when it identifies owner references on a
 resource targeted for deletion. 
 
 In some situations, finalizers can block the deletion of dependent objects,
-which can cause the targeted owner object to remain in a read-only state for
+which can cause the targeted owner object to remain for
 longer than expected without being fully deleted. In these situations, you
 should check finalizers and owner references on the target owner and dependent
 objects to troubleshoot the cause. 
@@ -123,20 +128,24 @@ Kubernetes 会使用属主引用（而不是标签）来确定集群中哪些 Po
 当 Kubernetes 识别到要删除的资源上的属主引用时，它也会处理 Finalizers。
 
 在某些情况下，Finalizers 会阻止依赖对象的删除，
-这可能导致目标属主对象，保持在只读状态的时间比预期的长，且没有被完全删除。
+这可能导致目标属主对象被保留的时间比预期的长，而没有被完全删除。
 在这些情况下，你应该检查目标属主和附属对象上的 Finalizers 和属主引用，来排查原因。
 
-{{<note>}}
+{{< note >}}
 <!--
-In cases where objects are stuck in a deleting state, try to avoid manually
+In cases where objects are stuck in a deleting state, avoid manually
 removing finalizers to allow deletion to continue. Finalizers are usually added
 to resources for a reason, so forcefully removing them can lead to issues in
-your cluster. 
--->
-在对象卡在删除状态的情况下，尽量避免手动移除 Finalizers，以允许继续删除操作。
-Finalizers 通常因为特殊原因被添加到资源上，所以强行删除它们会导致集群出现问题。
-{{</note>}}
+your cluster. This should only be done when the purpose of the finalizer is
+understood and is accomplished in another way (for example, manually cleaning
+up some dependent object).
 
+-->
+在对象卡在删除状态的情况下，要避免手动移除 Finalizers，以允许继续删除操作。
+Finalizers 通常因为特殊原因被添加到资源上，所以强行删除它们会导致集群出现问题。
+只有了解 finalizer 的用途时才能这样做，并且应该通过一些其他方式来完成
+（例如，手动清除其余的依赖对象）。
+{{< /note >}}
 
 ## {{% heading "whatsnext" %}}
 
@@ -144,4 +153,5 @@ Finalizers 通常因为特殊原因被添加到资源上，所以强行删除它
 * Read [Using Finalizers to Control Deletion](/blog/2021/05/14/using-finalizers-to-control-deletion/)
   on the Kubernetes blog.
 -->
-* 阅读 Kubernetes 博客的[使用 Finalizers 控制删除](/blog/2021/05/14/using-finalizers-to-control-deletion/)。
+* 在 Kubernetes 博客上阅读[使用 Finalizers 控制删除](/blog/2021/05/14/using-finalizers-to-control-deletion/)。
+

content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md

@@ -140,7 +140,7 @@ in the `kubectl` command-line interface, passing the `.yaml` file as an argument
 将 `.yaml` 文件作为参数。下面是一个示例：
 
 ```shell
-kubectl apply -f https://k8s.io/examples/application/deployment.yaml --record
+kubectl apply -f https://k8s.io/examples/application/deployment.yaml
 ```
 
 <!--
@@ -173,19 +173,35 @@ In the `.yaml` file for the Kubernetes object you want to create, you'll need to
 
 <!--
 The precise format of the object `spec` is different for every Kubernetes object, and contains nested fields specific to that object. The [Kubernetes API Reference](https://kubernetes.io/docs/reference/kubernetes-api/) can help you find the spec format for all of the objects you can create using Kubernetes.
-
-For example, the reference for Pod details the [`spec` field](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec)
-for a Pod in the API, and the reference for Deployment details the [`spec` field](/docs/reference/kubernetes-api/workload-resources/deployment-v1/#DeploymentSpec) for Deployments.
-In those API reference pages you'll see mention of PodSpec and DeploymentSpec. These names are implementation details of the Golang code that Kubernetes uses to implement its API.
 -->
 对象 `spec` 的精确格式对每个 Kubernetes 对象来说是不同的，包含了特定于该对象的嵌套字段。
 [Kubernetes API 参考](https://kubernetes.io/docs/reference/kubernetes-api/)
 能够帮助我们找到任何我们想创建的对象的规约格式。
 
-例如，Pod 参考文档详细说明了 API 中 Pod 的 [`spec` 字段](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec)，
-Deployment 的参考文档则详细说明了 Deployment 的 [`spec` 字段](/docs/reference/kubernetes-api/workload-resources/deployment-v1/#DeploymentSpec)。
-在这些 API 参考页面中，你将看到提到的 PodSpec 和 DeploymentSpec。
-这些名字是 Kubernetes 用来实现其 API 的 Golang 代码的实现细节。
+<!--
+For example, see the [`spec` field](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec)
+for the Pod API reference.
+For each Pod, the `.spec` field specifies the pod and its desired state (such as the container image name for
+each container within that pod).
+Another example of an object specification is the
+[`spec` field](/docs/reference/kubernetes-api/workload-resources/stateful-set-v1/#StatefulSetSpec)
+for the StatefulSet API. For StatefulSet, the `.spec` field specifies the StatefulSet and
+its desired state.
+Within the `.spec` of a StatefulSet is a [template](/docs/concepts/workloads/pods/#pod-templates)
+for Pod objects. That template describes Pods that the StatefulSet controller will create in order to
+satisfy the StatefulSet specification.
+Different kinds of object can also have different `.status`; again, the API reference pages
+detail the structure of that `.status` field, and its content for each different type of object.
+-->
+例如，参阅 Pod API 参考文档中
+[`spec` 字段](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec)。
+对于每个 Pod，其 `.spec` 字段设置了 Pod 及其期望状态（例如 Pod 中每个容器的容器镜像名称）。
+另一个对象规约的例子是 StatefulSet API 中的
+[`spec` 字段](/docs/reference/kubernetes-api/workload-resources/stateful-set-v1/#StatefulSetSpec)。
+对于 StatefulSet 而言，其 `.spec` 字段设置了 StatefulSet 及其期望状态。
+在 StatefulSet 的 `.spec` 内，有一个为 Pod 对象提供的[模板](/zh/docs/concepts/workloads/pods/#pod-templates)。该模板描述了 StatefulSet 控制器为了满足 StatefulSet 规约而要创建的 Pod。
+不同类型的对象可以由不同的 `.status` 信息。API 参考页面给出了 `.status` 字段的详细结构，
+以及针对不同类型 API 对象的具体内容。
 
 ## {{% heading "whatsnext" %}}
 

content/zh/docs/concepts/overview/working-with-objects/namespaces.md

@@ -16,12 +16,12 @@ weight: 30
 <!-- overview -->
 
 <!--
-Kubernetes supports multiple virtual clusters backed by the same physical cluster.
-These virtual clusters are called namespaces.
+In Kubernetes, _namespaces_ provides a mechanism for isolating groups of resources within a single cluster. Names of resources need to be unique within a namespace, but not across namespaces. Namespace-based scoping is applicable only for namespaced objects _(e.g. Deployments, Services, etc)_ and not for cluster-wide objects _(e.g. StorageClass, Nodes, PersistentVolumes, etc)_.
 -->
-Kubernetes 支持多个虚拟集群，它们底层依赖于同一个物理集群。
-这些虚拟集群被称为名字空间。
-在一些文档里名字空间也称为命名空间。
+在 Kubernetes 中，“名字空间（Namespace）”提供一种机制，将同一集群中的资源划分为相互隔离的组。
+同一名字空间内的资源名称要唯一，但跨名字空间时没有这个要求。
+名字空间作用域仅针对带有名字空间的对象，例如 Deployment、Service 等，
+这种作用域对集群访问的对象不适用，例如 StorageClass、Node、PersistentVolume 等。
 
 <!-- body -->
 
@@ -175,6 +175,42 @@ across namespaces, you need to use the fully qualified domain name (FQDN).
 `<服务名称>`，它将被解析到本地名字空间的服务。这对于跨多个名字空间（如开发、分级和生产）
 使用相同的配置非常有用。如果你希望跨名字空间访问，则需要使用完全限定域名（FQDN）。
 
+<!--
+As a result, all namespace names must be valid
+[RFC 1123 DNS labels](/docs/concepts/overview/working-with-objects/names/#dns-label-names).
+-->
+因此，所有的名字空间名称都必须是合法的
+[RFC 1123 DNS 标签](/zh/docs/concepts/overview/working-with-objects/names/#dns-label-names)。
+
+{{< warning >}}
+<!--
+By creating namespaces with the same name as [public top-level
+domains](https://data.iana.org/TLD/tlds-alpha-by-domain.txt), Services in these
+namespaces can have short DNS names that overlap with public DNS records.
+Workloads from any namespace performing a DNS lookup without a [trailing dot](https://datatracker.ietf.org/doc/html/rfc1034#page-8) will
+be redirected to those services, taking precedence over public DNS.
+-->
+通过创建与[公共顶级域名](https://data.iana.org/TLD/tlds-alpha-by-domain.txt)
+同名的名字空间，这些名字空间中的服务可以拥有与公共 DNS 记录重叠的、较短的 DNS 名称。
+所有名字空间中的负载在执行 DNS 查找时，如果查找的名称没有
+[尾部句点](https://datatracker.ietf.org/doc/html/rfc1034#page-8)，
+就会被重定向到这些服务上，因此呈现出比公共 DNS 更高的优先序。
+
+<!--
+To mitigate this, limit privileges for creating namespaces to trusted users. If
+required, you could additionally configure third-party security controls, such
+as [admission
+webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/),
+to block creating any namespace with the name of [public
+TLDs](https://data.iana.org/TLD/tlds-alpha-by-domain.txt).
+-->
+为了缓解这类问题，需要将创建名字空间的权限授予可信的用户。
+如果需要，你可以额外部署第三方的安全控制机制，例如以
+[准入 Webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/)
+的形式，阻止用户创建与公共 [TLD](https://data.iana.org/TLD/tlds-alpha-by-domain.txt)
+同名的名字空间。
+{{< /warning >}}
+
 <!--
 ## Not All Objects are in a Namespace
 -->