From d5f160df09629b38dbc53b4bcb5fb8c084b09406 Mon Sep 17 00:00:00 2001
From: Qiming Teng <tengqm@outlook.com>
Date: Thu, 29 Apr 2021 12:11:57 +0800
Subject: [PATCH] [zh] Resync concepts section (13)

---
 .../overview/working-with-objects/labels.md   |  13 +-
 .../overview/working-with-objects/names.md    |   9 ++
 .../working-with-objects/namespaces.md        |  30 ++++-
 .../working-with-objects/object-management.md | 120 +++++++++---------
 4 files changed, 104 insertions(+), 68 deletions(-)

diff --git a/content/zh/docs/concepts/overview/working-with-objects/labels.md b/content/zh/docs/concepts/overview/working-with-objects/labels.md
index 30e2635695..2714cb3f7b 100644
--- a/content/zh/docs/concepts/overview/working-with-objects/labels.md
+++ b/content/zh/docs/concepts/overview/working-with-objects/labels.md
@@ -100,10 +100,17 @@ _标签_ 是键值对。有效的标签键有两个段：可选的前缀和名
 `kubernetes.io/` 前缀是为 Kubernetes 核心组件保留的。
 
 <!--
-Valid label values must be 63 characters or less and must be empty or begin and end with an alphanumeric character (`[a-z0-9A-Z]`) with dashes (`-`), underscores (`_`), dots (`.`), and alphanumerics between.
+Valid label value:
+
+* must be 63 characters or less (can be empty),
+* unless empty, must begin and end with an alphanumeric character (`[a-z0-9A-Z]`),
+* could contain dashes (`-`), underscores (`_`), dots (`.`), and alphanumerics between.
 -->
-有效标签值必须为 63 个字符或更少，并且必须为空或以字母数字字符（`[a-z0-9A-Z]`）开头和结尾，
-中间可以包含破折号（`-`）、下划线（`_`）、点（`.`）和字母或数字。
+有效标签值：
+
+* 必须为 63 个字符或更少（可以为空）
+* 除非标签值为空，必须以字母数字字符（`[a-z0-9A-Z]`）开头和结尾
+* 包含破折号（`-`）、下划线（`_`）、点（`.`）和字母或数字。
 
 <!--
 ## Label selectors
diff --git a/content/zh/docs/concepts/overview/working-with-objects/names.md b/content/zh/docs/concepts/overview/working-with-objects/names.md
index 6075e0273c..5e0c59ae6d 100644
--- a/content/zh/docs/concepts/overview/working-with-objects/names.md
+++ b/content/zh/docs/concepts/overview/working-with-objects/names.md
@@ -36,6 +36,15 @@ For non-unique user-provided attributes, Kubernetes provides [labels](/docs/user
 
 {{< glossary_definition term_id="name" length="all" >}}
 
+{{< note >}}
+<!--
+In cases when objects represent a physical entity, like a Node representing a physical host, when the host is re-created under the same name without deleting and re-creating the Node, Kubernetes treats the new host as the old one, which may lead to inconsistencies.
+-->
+当对象所代表的是一个物理实体（例如代表一台物理主机的 Node）时，
+如果在 Node 对象未被删除并重建的条件下，创新创建了同名的物理主机，
+则 Kubernetes 会将新的主机看作是老的主机，这可能会带来某种不一致性。
+{{< /note >}}
+
 <!--
 Below are three types of commonly used name constraints for resources.
 -->
diff --git a/content/zh/docs/concepts/overview/working-with-objects/namespaces.md b/content/zh/docs/concepts/overview/working-with-objects/namespaces.md
index d7ea89b644..38f947f6d1 100644
--- a/content/zh/docs/concepts/overview/working-with-objects/namespaces.md
+++ b/content/zh/docs/concepts/overview/working-with-objects/namespaces.md
@@ -51,13 +51,14 @@ Namespaces are a way to divide cluster resources between multiple users (via [re
 名字空间是在多个用户之间划分集群资源的一种方法（通过[资源配额](/zh/docs/concepts/policy/resource-quotas/)）。
 
 <!--
-It is not necessary to use multiple namespaces just to separate slightly different
+It is not necessary to use multiple namespaces to separate slightly different
 resources, such as different versions of the same software: use
-[labels](/docs/concepts/overview/working-with-objects/labels/) to distinguish
+{{< glossary_tooltip text="labels" term_id="label" >}} to distinguish
 resources within the same namespace.
 -->
-不需要使用多个名字空间来分隔轻微不同的资源，例如同一软件的不同版本：
-使用[标签](/zh/docs/concepts/overview/working-with-objects/labels)来区分同一名字空间中的不同资源。
+不必使用多个名字空间来分隔仅仅轻微不同的资源，例如同一软件的不同版本：
+应该使用{{< glossary_tooltip text="标签" term_id="label" >}}
+来区分同一名字空间中的不同资源。
 
 <!--
 ## Working with Namespaces
@@ -160,7 +161,7 @@ Kubernetes 会创建一个相应的 [DNS 条目](/zh/docs/concepts/services-netw
 
 <!--
 This entry is of the form `<service-name>.<namespace-name>.svc.cluster.local`, which means
-that if a container just uses `<service-name>`, it will resolve to the service which
+that if a container only uses `<service-name>`, it will resolve to the service which
 is local to a namespace.  This is useful for using the same configuration across
 multiple namespaces such as Development, Staging and Production.  If you want to reach
 across namespaces, you need to use the fully qualified domain name (FQDN).
@@ -197,6 +198,25 @@ kubectl api-resources --namespaced=true
 kubectl api-resources --namespaced=false
 ```
 
+<!--
+## Automatic labelling
+-->
+## 自动打标签   {#automatic-labelling}
+
+{{< feature-state state="beta" for_k8s_version="1.21" >}}
+
+<!--
+The Kubernetes control plane sets an immutable {{< glossary_tooltip text="label" term_id="label" >}}
+`kubernetes.io/metadata.name` on all namespaces, provided that the `NamespaceDefaultLabelName`
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled.
+The value of the label is the namespace name.
+-->
+Kubernetes 控制面会为所有名字空间设置一个不可变更的
+{{< glossary_tooltip text="标签" term_id="label" >}}
+`kubernetes.io/metadata.name`，只要 `NamespaceDefaultLabelName` 这一
+[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
+被启用。标签的值是名字空间的名称。
+ 
 ## {{% heading "whatsnext" %}}
 
 <!--
diff --git a/content/zh/docs/concepts/overview/working-with-objects/object-management.md b/content/zh/docs/concepts/overview/working-with-objects/object-management.md
index e7bcf9af09..b1dd99ca60 100644
--- a/content/zh/docs/concepts/overview/working-with-objects/object-management.md
+++ b/content/zh/docs/concepts/overview/working-with-objects/object-management.md
@@ -11,8 +11,10 @@ Kubernetes objects. This document provides an overview of the different
 approaches. Read the [Kubectl book](https://kubectl.docs.kubernetes.io) for
 details of managing objects by Kubectl.
 -->
-`kubectl` 命令行工具支持多种不同的方式来创建和管理 Kubernetes 对象。本文档概述了不同的方法。阅读 [Kubectl book](https://kubectl.docs.kubernetes.io) 来了解 kubectl 管理对象的详细信息。
-
+`kubectl` 命令行工具支持多种不同的方式来创建和管理 Kubernetes 对象。
+本文档概述了不同的方法。
+阅读 [Kubectl book](https://kubectl.docs.kubernetes.io) 来了解 kubectl
+管理对象的详细信息。
 
 <!-- body -->
 
@@ -29,30 +31,39 @@ and matching techniques for the same object results in undefined behavior.
 应该只使用一种技术来管理 Kubernetes 对象。混合和匹配技术作用在同一对象上将导致未定义行为。
 {{< /warning >}}
 
+<!--
 | Management technique             | Operates on          |Recommended environment | Supported writers  | Learning curve |
 |----------------------------------|----------------------|------------------------|--------------------|----------------|
 | Imperative commands              | Live objects         | Development projects   | 1+                 | Lowest         |
 | Imperative object configuration  | Individual files     | Production projects    | 1                  | Moderate       |
 | Declarative object configuration | Directories of files | Production projects    | 1+                 | Highest        |
+-->
+| 管理技术       | 作用于   | 建议的环境 | 支持的写者 | 学习难度 |
+|----------------|----------|------------|------------|----------|
+| 指令式命令     | 活跃对象 | 开发项目   | 1+         | 最低     |
+| 指令式对象配置 | 单个文件 | 生产项目   | 1          | 中等     |
+| 声明式对象配置 | 文件目录 | 生产项目   | 1+         | 最高     |
 
 <!--
 ## Imperative commands
 -->
-## 命令式命令
+## 指令式命令
 
 <!--
 When using imperative commands, a user operates directly on live objects
 in a cluster. The user provides operations to
 the `kubectl` command as arguments or flags.
 -->
-使用命令式命令时，用户可以在集群中的活动对象上进行操作。用户将操作传给 `kubectl` 命令作为参数或标志。
+使用指令式命令时，用户可以在集群中的活动对象上进行操作。用户将操作传给
+`kubectl` 命令作为参数或标志。
 
 <!--
-This is the simplest way to get started or to run a one-off task in
+This is the recommended way to get started or to run a one-off task in
 a cluster. Because this technique operates directly on live
 objects, it provides no history of previous configurations.
 -->
-这是开始或者在集群中运行一次性任务的最简单方法。因为这个技术直接在活动对象上操作，所以它不提供以前配置的历史记录。
+这是开始或者在集群中运行一次性任务的推荐方法。因为这个技术直接在活跃对象
+上操作，所以它不提供以前配置的历史记录。
 
 <!--
 ### Examples
@@ -64,15 +75,6 @@ Run an instance of the nginx container by creating a Deployment object:
 -->
 通过创建 Deployment 对象来运行 nginx 容器的实例：
 
-```sh
-kubectl run nginx --image nginx
-```
-
-<!--
-Do the same thing using a different syntax:
--->
-使用不同的语法来达到同样的上面的效果：
-
 ```sh
 kubectl create deployment nginx --image nginx
 ```
@@ -84,27 +86,25 @@ kubectl create deployment nginx --image nginx
 
 <!--
 Advantages compared to object configuration:
--->
-与对象配置相比的优点：
 
-<!--
 - Commands are simple, easy to learn and easy to remember.
 - Commands require only a single step to make changes to the cluster.
 -->
+与对象配置相比的优点：
+
 - 命令简单，易学且易于记忆。
 - 命令仅需一步即可对集群进行更改。
 
 <!--
 Disadvantages compared to object configuration:
--->
-与对象配置相比的缺点：
 
-<!--
 - Commands do not integrate with change review processes.
 - Commands do not provide an audit trail associated with changes.
 - Commands do not provide a source of records except for what is live.
 - Commands do not provide a template for creating new objects.
 -->
+与对象配置相比的缺点：
+
 - 命令不与变更审查流程集成。
 - 命令不提供与更改关联的审核跟踪。
 - 除了实时内容外，命令不提供记录源。
@@ -113,7 +113,7 @@ Disadvantages compared to object configuration:
 <!--
 ## Imperative object configuration
 -->
-## 命令式对象配置
+## 指令式对象配置
 
 <!--
 In imperative object configuration, the kubectl command specifies the
@@ -121,13 +121,15 @@ operation (create, replace, etc.), optional flags and at least one file
 name. The file specified must contain a full definition of the object
 in YAML or JSON format.
 -->
-在命令式对象配置中，kubectl 命令指定操作（创建，替换等），可选标志和至少一个文件名。指定的文件必须包含 YAML 或 JSON 格式的对象的完整定义。
+在指令式对象配置中，kubectl 命令指定操作（创建，替换等），可选标志和
+至少一个文件名。指定的文件必须包含 YAML 或 JSON 格式的对象的完整定义。
 
 <!--
 See the [API reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
 for more details on object definitions.
 -->
-有关对象定义的详细信息，请查看 [API 参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)。
+有关对象定义的详细信息，请查看
+[API 参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)。
 
 {{< warning >}}
 <!--
@@ -138,17 +140,19 @@ types whose specs are updated independently of the configuration file.
 Services of type `LoadBalancer`, for example, have their `externalIPs` field updated
 independently from the configuration by the cluster.
 -->
-`replace` 命令式命令将现有规范替换为新提供的规范，并删除对配置文件中缺少的对象的所有更改。此方法不应与规范独立于配置文件进行更新的资源类型一起使用。比如类型为 `LoadBalancer` 的服务，它的 `externalIPs` 字段就是独立于集群配置进行更新。
+`replace` 指令式命令将现有规范替换为新提供的规范，并放弃对配置文件中
+缺少的对象的所有更改。此方法不应与对象规约被独立于配置文件进行更新的
+资源类型一起使用。比如类型为 `LoadBalancer` 的服务，它的 `externalIPs` 
+字段就是独立于集群配置进行更新。
 {{< /warning >}}
 
 <!--
 ### Examples
+
+Create the objects defined in a configuration file:
 -->
 ### 例子
 
-<!--
-Create the objects defined in a configuration file:
--->
 创建配置文件中定义的对象：
 
 ```sh
@@ -181,52 +185,48 @@ kubectl replace -f nginx.yaml
 
 <!--
 Advantages compared to imperative commands:
--->
-与命令式命令相比的优点：
 
-<!--
 - Object configuration can be stored in a source control system such as Git.
 - Object configuration can integrate with processes such as reviewing changes before push and audit trails.
 - Object configuration provides a template for creating new objects.
 -->
+与指令式命令相比的优点：
+
 - 对象配置可以存储在源控制系统中，比如 Git。
 - 对象配置可以与流程集成，例如在推送和审计之前检查更新。
 - 对象配置提供了用于创建新对象的模板。
 
 <!--
 Disadvantages compared to imperative commands:
--->
-与命令式命令相比的缺点：
 
-<!--
 - Object configuration requires basic understanding of the object schema.
 - Object configuration requires the additional step of writing a YAML file.
 -->
+与指令式命令相比的缺点：
+
 - 对象配置需要对对象架构有基本的了解。
 - 对象配置需要额外的步骤来编写 YAML 文件。
 
 <!--
 Advantages compared to declarative object configuration:
--->
-与声明式对象配置相比的优点：
 
-<!--
 - Imperative object configuration behavior is simpler and easier to understand.
 - As of Kubernetes version 1.5, imperative object configuration is more mature.
 -->
-- 命令式对象配置行为更加简单易懂。
-- 从 Kubernetes 1.5 版本开始，命令式对象配置更加成熟。
+与声明式对象配置相比的优点：
+
+- 指令式对象配置行为更加简单易懂。
+- 从 Kubernetes 1.5 版本开始，指令对象配置更加成熟。
 
 <!--
 Disadvantages compared to declarative object configuration:
--->
-与声明式对象配置相比的缺点：
 
-<!--
 - Imperative object configuration works best on files, not directories.
 - Updates to live objects must be reflected in configuration files, or they will be lost during the next replacement.
 -->
-- 命令式对象配置更适合文件，而非目录。
+与声明式对象配置相比的缺点：
+
+- 指令式对象配置更适合文件，而非目录。
 - 对活动对象的更新必须反映在配置文件中，否则会在下一次替换时丢失。
 
 <!--
@@ -241,7 +241,10 @@ operations to be taken on the files. Create, update, and delete operations
 are automatically detected per-object by `kubectl`. This enables working on
 directories, where different operations might be needed for different objects.
 -->
-使用声明式对象配置时，用户对本地存储的对象配置文件进行操作，但是用户未定义要对该文件执行的操作。`kubectl` 会自动检测每个文件的创建、更新和删除操作。这使得配置可以在目录上工作，根据目录中配置文件对不同的对象执行不同的操作。
+使用声明式对象配置时，用户对本地存储的对象配置文件进行操作，但是用户
+未定义要对该文件执行的操作。
+`kubectl` 会自动检测每个文件的创建、更新和删除操作。
+这使得配置可以在目录上工作，根据目录中配置文件对不同的对象执行不同的操作。
 
 {{< note >}}
 <!--
@@ -251,7 +254,9 @@ This is possible by using the `patch` API operation to write only
 observed differences, instead of using the `replace`
 API operation to replace the entire object configuration.
 -->
-声明式对象配置保留其他编写者所做的修改，即使这些更改并未合并到对象配置文件中。可以通过使用 `patch` API 操作仅写入观察到的差异，而不是使用 `replace` API 操作来替换整个对象配置来实现。
+声明式对象配置保留其他编写者所做的修改，即使这些更改并未合并到对象配置文件中。
+可以通过使用 `patch` API 操作仅写入观察到的差异，而不是使用 `replace` API
+操作来替换整个对象配置来实现。
 {{< /note >}}
 
 <!--
@@ -264,7 +269,8 @@ Process all object configuration files in the `configs` directory, and create or
 patch the live objects. You can first `diff` to see what changes are going to be
 made, and then apply:
 -->
-处理 `configs` 目录中的所有对象配置文件，创建并更新活动对象。可以首先使用 `diff` 子命令查看将要进行的更改，然后在进行应用：
+处理 `configs` 目录中的所有对象配置文件，创建并更新活跃对象。
+可以首先使用 `diff` 子命令查看将要进行的更改，然后在进行应用：
 
 ```sh
 kubectl diff -f configs/
@@ -283,35 +289,30 @@ kubectl apply -R -f configs/
 
 <!--
 ### Trade-offs
--->
-### 权衡
 
-<!--
 Advantages compared to imperative object configuration:
--->
-与命令式对象配置相比的优点：
 
-<!--
 - Changes made directly to live objects are retained, even if they are not merged back into the configuration files.
 - Declarative object configuration has better support for operating on directories and automatically detecting operation types (create, patch, delete) per-object.
 -->
+### 权衡
+
+与指令式对象配置相比的优点：
+
 - 对活动对象所做的更改即使未合并到配置文件中，也会被保留下来。
 - 声明性对象配置更好地支持对目录进行操作并自动检测每个文件的操作类型（创建，修补，删除）。
 
 <!--
 Disadvantages compared to imperative object configuration:
--->
-与命令式对象配置相比的缺点：
 
-<!--
 - Declarative object configuration is harder to debug and understand results when they are unexpected.
 - Partial updates using diffs create complex merge and patch operations.
 -->
+与指令式对象配置相比的缺点：
+
 - 声明式对象配置难于调试并且出现异常时结果难以理解。
 - 使用 diff 产生的部分更新会创建复杂的合并和补丁操作。
 
-
-
 ## {{% heading "whatsnext" %}}
 
 
@@ -324,12 +325,11 @@ Disadvantages compared to imperative object configuration:
 - [Kubectl Book](https://kubectl.docs.kubernetes.io)
 - [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
 -->
-- [使用命令式命令管理 Kubernetes 对象](/zh/docs/tasks/manage-kubernetes-objects/imperative-command/)
-- [使用对象配置管理 Kubernetes 对象（命令式）](/zh/docs/tasks/manage-kubernetes-objects/imperative-config/)
+- [使用指令式命令管理 Kubernetes 对象](/zh/docs/tasks/manage-kubernetes-objects/imperative-command/)
+- [使用对象配置管理 Kubernetes 对象（指令式）](/zh/docs/tasks/manage-kubernetes-objects/imperative-config/)
 - [使用对象配置管理 Kubernetes 对象（声明式）](/zh/docs/tasks/manage-kubernetes-objects/declarative-config/)
 - [使用 Kustomize（声明式）管理 Kubernetes 对象](/zh/docs/tasks/manage-kubernetes-objects/kustomization/)
 - [Kubectl 命令参考](/docs/reference/generated/kubectl/kubectl-commands/)
 - [Kubectl Book](https://kubectl.docs.kubernetes.io)
 - [Kubernetes API 参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
 
-