Switch language name 'zh' to 'zh-cn'

This is the first step to rename 'zh' to 'zh-cn'. There are several reasons why we rename the language name.

- The upstream docsy theme changed the language name, leading to many warnings during site build;
  The side-effect is that the i18n strings are no longer working.
- We believe renaming the language is the right thing to do, because this move can make room for other variants of Chinese language, such as 'zh-tw', 'zh-sg' etc.

There would be several follow-ups to this PR, such as fixing the intra-site links, adding redirects etc.

We will lock up changes to zh/zh-cn pages for the moment, until this one gets in.

This PR is based on commit cdad0a7342.

content/zh-cn/docs/concepts/configuration/_index.md

@@ -0,0 +1,5 @@
+---
+title: "配置"
+weight: 80
+description: Kubernetes 为配置 Pods 提供的资源。
+---

content/zh-cn/docs/concepts/configuration/configmap.md

@@ -0,0 +1,471 @@
+---
+title: ConfigMap
+content_type: concept
+weight: 20
+---
+
+<!-- overview -->
+
+{{< glossary_definition term_id="configmap" length="all" >}}
+
+{{< caution >}}
+<!--
+ConfigMap does not provide secrecy or encryption.
+If the data you want to store are confidential, use a
+{{< glossary_tooltip text="Secret" term_id="secret" >}} rather than a ConfigMap,
+or use additional (third party) tools to keep your data private.
+-->
+ConfigMap 并不提供保密或者加密功能。
+如果你想存储的数据是机密的，请使用 {{< glossary_tooltip text="Secret" term_id="secret" >}}，
+或者使用其他第三方工具来保证你的数据的私密性，而不是用 ConfigMap。
+{{< /caution >}}
+
+<!-- body -->
+<!--
+## Motivation
+
+Use a ConfigMap for setting configuration data separately from application code.
+
+For example, imagine that you are developing an application that you can run on your
+own computer (for development) and in the cloud (to handle real traffic).
+You write the code to look in an environment variable named `DATABASE_HOST`.
+Locally, you set that variable to `localhost`. In the cloud, you set it to
+refer to a Kubernetes {{< glossary_tooltip text="Service" term_id="service" >}}
+that exposes the database component to your cluster.
+This lets you fetch a container image running in the cloud and
+debug the exact same code locally if needed.
+-->
+## 动机   {#motivation}
+
+使用 ConfigMap 来将你的配置数据和应用程序代码分开。
+
+比如，假设你正在开发一个应用，它可以在你自己的电脑上（用于开发）和在云上
+（用于实际流量）运行。
+你的代码里有一段是用于查看环境变量 `DATABASE_HOST`，在本地运行时，
+你将这个变量设置为 `localhost`，在云上，你将其设置为引用 Kubernetes 集群中的
+公开数据库组件的 {{< glossary_tooltip text="服务" term_id="service" >}}。
+
+这让你可以获取在云中运行的容器镜像，并且如果有需要的话，在本地调试完全相同的代码。
+
+<!--
+A ConfigMap is not designed to hold large chunks of data. The data stored in a
+ConfigMap cannot exceed 1 MiB. If you need to store settings that are
+larger than this limit, you may want to consider mounting a volume or use a
+separate database or file service.
+-->
+ConfigMap 在设计上不是用来保存大量数据的。在 ConfigMap 中保存的数据不可超过
+1 MiB。如果你需要保存超出此尺寸限制的数据，你可能希望考虑挂载存储卷
+或者使用独立的数据库或者文件服务。
+
+<!--
+## ConfigMap object
+
+A ConfigMap is an API [object](/docs/concepts/overview/working-with-objects/kubernetes-objects/)
+that lets you store configuration for other objects to use. Unlike most
+Kubernetes objects that have a `spec`, a ConfigMap has `data` and `binaryData`
+fields. These fields accept key-value pairs as their values.  Both the `data`
+field and the `binaryData` are optional. The `data` field is designed to
+contain UTF-8 strings while the `binaryData` field is designed to
+contain binary data as base64-encoded strings.
+
+The name of a ConfigMap must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
+-->
+## ConfigMap 对象
+
+ConfigMap 是一个 API [对象](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/)，
+让你可以存储其他对象所需要使用的配置。
+和其他 Kubernetes 对象都有一个 `spec` 不同的是，ConfigMap 使用 `data` 和
+`binaryData` 字段。这些字段能够接收键-值对作为其取值。`data` 和 `binaryData`
+字段都是可选的。`data` 字段设计用来保存 UTF-8 字符串，而 `binaryData`
+则被设计用来保存二进制数据作为 base64 编码的字串。
+
+ConfigMap 的名字必须是一个合法的
+[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
+
+<!--
+Each key under the `data` or the `binaryData` field must consist of
+alphanumeric characters, `-`, `_` or `.`. The keys stored in `data` must not
+overlap with the keys in the `binaryData` field.
+
+Starting from v1.19, you can add an `immutable` field to a ConfigMap
+definition to create an [immutable ConfigMap](#configmap-immutable).
+-->
+`data` 或 `binaryData` 字段下面的每个键的名称都必须由字母数字字符或者
+`-`、`_` 或 `.` 组成。在 `data` 下保存的键名不可以与在 `binaryData`
+下出现的键名有重叠。
+
+从 v1.19 开始，你可以添加一个 `immutable` 字段到 ConfigMap 定义中，
+创建[不可变更的 ConfigMap](#configmap-immutable)。
+
+<!--
+## ConfigMaps and Pods
+
+You can write a Pod `spec` that refers to a ConfigMap and configures the container(s)
+in that Pod based on the data in the ConfigMap. The Pod and the ConfigMap must be in
+the same {{< glossary_tooltip text="namespace" term_id="namespace" >}}.
+-->
+## ConfigMaps 和 Pods
+
+你可以写一个引用 ConfigMap 的 Pod 的 `spec`，并根据 ConfigMap 中的数据在该
+Pod 中配置容器。这个 Pod 和 ConfigMap 必须要在同一个
+{{< glossary_tooltip text="名字空间" term_id="namespace" >}} 中。
+
+<!--
+The `spec` of a {{< glossary_tooltip text="static Pod" term_id="static-pod" >}} cannot refer to a ConfigMap
+or any other API objects.
+-->
+{{< note >}}
+{{< glossary_tooltip text="静态 Pod" term_id="static-pod" >}} 中的 `spec`
+字段不能引用 ConfigMap 或任何其他 API 对象。
+{{< /note >}}
+
+<!--
+Here's an example ConfigMap that has some keys with single values,
+and other keys where the value looks like a fragment of a configuration
+format.
+-->
+这是一个 ConfigMap 的示例，它的一些键只有一个值，其他键的值看起来像是
+配置的片段格式。
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: game-demo
+data:
+  # 类属性键；每一个键都映射到一个简单的值
+  player_initial_lives: "3"
+  ui_properties_file_name: "user-interface.properties"
+
+  # 类文件键
+  game.properties: |
+    enemy.types=aliens,monsters
+    player.maximum-lives=5
+  user-interface.properties: |
+    color.good=purple
+    color.bad=yellow
+    allow.textmode=true
+```
+<!--
+There are four different ways that you can use a ConfigMap to configure
+a container inside a Pod:
+
+1. Inside a container command and args
+1. Environment variables for a container
+1. Add a file in read-only volume, for the application to read
+1. Write code to run inside the Pod that uses the Kubernetes API to read a ConfigMap
+
+These different methods lend themselves to different ways of modeling
+the data being consumed.
+For the first three methods, the
+{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} uses the data from
+the ConfigMap when it launches container(s) for a Pod.
+-->
+你可以使用四种方式来使用 ConfigMap 配置 Pod 中的容器：
+
+1. 在容器命令和参数内
+1. 容器的环境变量
+1. 在只读卷里面添加一个文件，让应用来读取
+1. 编写代码在 Pod 中运行，使用 Kubernetes API 来读取 ConfigMap
+
+这些不同的方法适用于不同的数据使用方式。
+对前三个方法，{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}
+使用 ConfigMap 中的数据在 Pod 中启动容器。
+
+<!--
+The fourth method means you have to write code to read the ConfigMap and its data.
+However, because you're using the Kubernetes API directly, your application can
+subscribe to get updates whenever the ConfigMap changes, and react
+when that happens. By accessing the Kubernetes API directly, this
+technique also lets you access a ConfigMap in a different namespace.
+
+Here's an example Pod that uses values from `game-demo` to configure a Pod:
+-->
+第四种方法意味着你必须编写代码才能读取 ConfigMap 和它的数据。然而，
+由于你是直接使用 Kubernetes API，因此只要 ConfigMap 发生更改，
+你的应用就能够通过订阅来获取更新，并且在这样的情况发生的时候做出反应。
+通过直接进入 Kubernetes API，这个技术也可以让你能够获取到不同的名字空间里的 ConfigMap。
+
+下面是一个 Pod 的示例，它通过使用 `game-demo` 中的值来配置一个 Pod：
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: configmap-demo-pod
+spec:
+  containers:
+    - name: demo
+      image: alpine
+      command: ["sleep", "3600"]
+      env:
+        # 定义环境变量
+        - name: PLAYER_INITIAL_LIVES # 请注意这里和 ConfigMap 中的键名是不一样的
+          valueFrom:
+            configMapKeyRef:
+              name: game-demo           # 这个值来自 ConfigMap
+              key: player_initial_lives # 需要取值的键
+        - name: UI_PROPERTIES_FILE_NAME
+          valueFrom:
+            configMapKeyRef:
+              name: game-demo
+              key: ui_properties_file_name
+      volumeMounts:
+      - name: config
+        mountPath: "/config"
+        readOnly: true
+  volumes:
+    # 你可以在 Pod 级别设置卷，然后将其挂载到 Pod 内的容器中
+    - name: config
+      configMap:
+        # 提供你想要挂载的 ConfigMap 的名字
+        name: game-demo
+        # 来自 ConfigMap 的一组键，将被创建为文件
+        items:
+        - key: "game.properties"
+          path: "game.properties"
+        - key: "user-interface.properties"
+          path: "user-interface.properties"
+```
+
+<!--
+A ConfigMap doesn't differentiate between single line property values and
+multi-line file-like values.
+What matters how Pods and other objects consume those values.
+
+For this example, defining a volume and mounting it inside the `demo`
+container as `/config` creates two files,
+`/config/game.properties` and `/config/user-interface.properties`,
+even though there are four keys in the ConfigMap. This is because the Pod
+definition specifies an `items` array in the `volumes` section.
+If you omit the `items` array entirely, every key  in the ConfigMap becomes
+a file with the same name as the key, and you get 4 files.
+-->
+ConfigMap 不会区分单行属性值和多行类似文件的值，重要的是 Pods
+和其他对象如何使用这些值。
+
+上面的例子定义了一个卷并将它作为 `/config` 文件夹挂载到 `demo` 容器内，
+创建两个文件，`/config/game.properties` 和
+`/config/user-interface.properties`，
+尽管 ConfigMap 中包含了四个键。
+这是因为 Pod 定义中在 `volumes` 节指定了一个 `items` 数组。
+如果你完全忽略 `items` 数组，则 ConfigMap 中的每个键都会变成一个与该键同名的文件，
+因此你会得到四个文件。
+
+<!--
+## Using ConfigMaps
+
+ConfigMaps can be mounted as data volumes. ConfigMaps can also be used by other
+parts of the system, without being directly exposed to the Pod. For example,
+ConfigMaps can hold data that other parts of the system should use for configuration.
+-->
+## 使用 ConfigMap   {#using-configmaps}
+
+ConfigMap 可以作为数据卷挂载。ConfigMap 也可被系统的其他组件使用，
+而不一定直接暴露给 Pod。例如，ConfigMap 可以保存系统中其他组件要使用的配置数据。
+
+<!--
+The most common way to use ConfigMaps is to configure settings for
+containers running in a Pod in the same namespace. You can also use a
+ConfigMap separately.
+
+For example, you
+might encounter {{< glossary_tooltip text="addons" term_id="addons" >}}
+or {{< glossary_tooltip text="operators" term_id="operator-pattern" >}} that
+adjust their behavior based on a ConfigMap.
+-->
+ConfigMap 最常见的用法是为同一命名空间里某 Pod 中运行的容器执行配置。
+你也可以单独使用 ConfigMap。
+
+比如，你可能会遇到基于 ConfigMap 来调整其行为的
+{{< glossary_tooltip text="插件" term_id="addons" >}} 或者
+{{< glossary_tooltip text="operator" term_id="operator-pattern" >}}。
+
+<!--
+### Using ConfigMaps as files from a Pod
+
+To consume a ConfigMap in a volume in a Pod:
+-->
+### 在 Pod 中将 ConfigMap 当做文件使用
+
+要在一个 Pod 的存储卷中使用 ConfigMap:
+
+<!--
+1. Create a ConfigMap or use an existing one. Multiple Pods can reference the
+   same ConfigMap.
+1. Modify your Pod definition to add a volume under `.spec.volumes[]`. Name
+   the volume anything, and have a `.spec.volumes[].configMap.name` field set
+   to reference your ConfigMap object.
+1. Add a `.spec.containers[].volumeMounts[]` to each container that needs the
+   ConfigMap. Specify `.spec.containers[].volumeMounts[].readOnly = true` and
+   `.spec.containers[].volumeMounts[].mountPath` to an unused directory name
+   where you would like the ConfigMap to appear.
+1. Modify your image or command line so that the program looks for files in
+   that directory. Each key in the ConfigMap `data` map becomes the filename
+   under `mountPath`.
+-->
+1. 创建一个 ConfigMap 对象或者使用现有的 ConfigMap 对象。多个 Pod 可以引用同一个
+   ConfigMap。
+1. 修改 Pod 定义，在 `spec.volumes[]` 下添加一个卷。
+   为该卷设置任意名称，之后将 `spec.volumes[].configMap.name` 字段设置为对你的
+   ConfigMap 对象的引用。
+1. 为每个需要该 ConfigMap 的容器添加一个 `.spec.containers[].volumeMounts[]`。
+   设置 `.spec.containers[].volumeMounts[].readOnly=true` 并将
+   `.spec.containers[].volumeMounts[].mountPath` 设置为一个未使用的目录名，
+   ConfigMap 的内容将出现在该目录中。
+1. 更改你的镜像或者命令行，以便程序能够从该目录中查找文件。ConfigMap 中的每个
+   `data` 键会变成 `mountPath` 下面的一个文件名。
+
+<!--
+This is an example of a Pod that mounts a ConfigMap in a volume:
+-->
+下面是一个将 ConfigMap 以卷的形式进行挂载的 Pod 示例：
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: mypod
+spec:
+  containers:
+  - name: mypod
+    image: redis
+    volumeMounts:
+    - name: foo
+      mountPath: "/etc/foo"
+      readOnly: true
+  volumes:
+  - name: foo
+    configMap:
+      name: myconfigmap
+```
+
+<!--
+Each ConfigMap you want to use needs to be referred to in `.spec.volumes`.
+
+If there are multiple containers in the Pod, then each container needs its
+own `volumeMounts` block, but only one `.spec.volumes` is needed per ConfigMap.
+-->
+你希望使用的每个 ConfigMap 都需要在 `spec.volumes` 中被引用到。
+
+如果 Pod 中有多个容器，则每个容器都需要自己的 `volumeMounts` 块，但针对每个
+ConfigMap，你只需要设置一个 `spec.volumes` 块。
+
+<!--
+#### Mounted ConfigMaps are updated automatically
+
+When a ConfigMap currently consumed in a volume is updated, projected keys are eventually updated as well.
+The kubelet checks whether the mounted ConfigMap is fresh on every periodic sync.
+However, the kubelet uses its local cache for getting the current value of the ConfigMap.
+The type of the cache is configurable using the `ConfigMapAndSecretChangeDetectionStrategy` field in
+the [KubeletConfiguration struct](/docs/reference/config-api/kubelet-config.v1beta1/).
+-->
+#### 被挂载的 ConfigMap 内容会被自动更新
+
+当卷中使用的 ConfigMap 被更新时，所投射的键最终也会被更新。
+kubelet 组件会在每次周期性同步时检查所挂载的 ConfigMap 是否为最新。
+不过，kubelet 使用的是其本地的高速缓存来获得 ConfigMap 的当前值。
+高速缓存的类型可以通过
+[KubeletConfiguration 结构](/zh/docs/reference/config-api/kubelet-config.v1beta1/).
+的 `ConfigMapAndSecretChangeDetectionStrategy` 字段来配置。
+
+<!--
+A ConfigMap can be either propagated by watch (default), ttl-based, or by redirecting
+all requests directly to the API server.
+As a result, the total delay from the moment when the ConfigMap is updated to the moment
+when new keys are projected to the Pod can be as long as the kubelet sync period + cache
+propagation delay, where the cache propagation delay depends on the chosen cache type
+(it equals to watch propagation delay, ttl of cache, or zero correspondingly).
+-->
+ConfigMap 既可以通过 watch 操作实现内容传播（默认形式），也可实现基于 TTL
+的缓存，还可以直接经过所有请求重定向到 API 服务器。
+因此，从 ConfigMap 被更新的那一刻算起，到新的主键被投射到 Pod 中去，
+这一时间跨度可能与 kubelet 的同步周期加上高速缓存的传播延迟相等。
+这里的传播延迟取决于所选的高速缓存类型
+（分别对应 watch 操作的传播延迟、高速缓存的 TTL 时长或者 0）。
+
+<!--
+ConfigMaps consumed as environment variables are not updated automatically and require a pod restart.
+-->
+以环境变量方式使用的 ConfigMap 数据不会被自动更新。
+更新这些数据需要重新启动 Pod。
+
+<!--
+A container using a ConfigMap as a [subPath](/docs/concepts/storage/volumes#using-subpath) volume mount will not receive ConfigMap updates.
+-->
+{{< note >}}
+使用 ConfigMap 作为 [subPath](/zh/docs/concepts/storage/volumes#using-subpath) 卷挂载的容器将不会收到 ConfigMap 的更新。
+{{< /note >}}
+
+<!--
+## Immutable ConfigMaps {#configmap-immutable}
+-->
+## 不可变更的 ConfigMap     {#configmap-immutable}
+
+{{< feature-state for_k8s_version="v1.21" state="stable" >}}
+
+<!--
+The Kubernetes feature _Immutable Secrets and ConfigMaps_ provides an option to set
+individual Secrets and ConfigMaps as immutable. For clusters that extensively use ConfigMaps
+(at least tens of thousands of unique ConfigMap to Pod mounts), preventing changes to their
+data has the following advantages:
+-->
+Kubernetes 特性 _Immutable Secret 和 ConfigMaps_ 提供了一种将各个
+Secret 和 ConfigMap 设置为不可变更的选项。对于大量使用 ConfigMap 的集群
+（至少有数万个各不相同的 ConfigMap 给 Pod 挂载）而言，禁止更改
+ConfigMap 的数据有以下好处：
+
+<!--
+- protects you from accidental (or unwanted) updates that could cause applications outages
+- improves performance of your cluster by significantly reducing load on kube-apiserver, by
+  closing watches for ConfigMaps marked as immutable.
+-->
+- 保护应用，使之免受意外（不想要的）更新所带来的负面影响。
+- 通过大幅降低对 kube-apiserver 的压力提升集群性能，
+  这是因为系统会关闭对已标记为不可变更的 ConfigMap 的监视操作。
+
+<!--
+This feature is controlled by the `ImmutableEphemeralVolumes`
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/).
+You can create an immutable ConfigMap by setting the `immutable` field to `true`.
+For example:
+-->
+此功能特性由 `ImmutableEphemeralVolumes`
+[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)来控制。
+你可以通过将 `immutable` 字段设置为 `true` 创建不可变更的 ConfigMap。
+例如：
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  ...
+data:
+  ...
+immutable: true
+```
+
+<!--
+Once a ConfigMap is marked as immutable, it is _not_ possible to revert this change
+nor to mutate the contents of the `data` or the `binaryData` field. You can
+only delete and recreate the ConfigMap. Because existing Pods maintain a mount point
+to the deleted ConfigMap, it is recommended to recreate these pods.
+-->
+一旦某 ConfigMap 被标记为不可变更，则 _无法_ 逆转这一变化，，也无法更改
+`data` 或 `binaryData` 字段的内容。你只能删除并重建 ConfigMap。
+因为现有的 Pod 会维护一个已被删除的 ConfigMap 的挂载点，建议重新创建这些 Pods。
+
+## {{% heading "whatsnext" %}}
+
+<!--
+* Read about [Secrets](/docs/concepts/configuration/secret/).
+* Read [Configure a Pod to Use a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/).
+* Read about [changing a ConfigMap (or any other Kubernetes object)](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)
+* Read [The Twelve-Factor App](https://12factor.net/) to understand the motivation for
+  separating code from configuration.
+-->
+* 阅读 [Secret](/zh/docs/concepts/configuration/secret/)。
+* 阅读[配置 Pod 使用 ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)。
+* 阅读[修改 ConfigMap（或任何其他 Kubernetes 对象）](/zh/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)。
+* 阅读 [Twelve-Factor 应用](https://12factor.net/zh_cn/)来了解将代码和配置分开的动机。

content/zh-cn/docs/concepts/configuration/organize-cluster-access-kubeconfig.md

@@ -0,0 +1,323 @@
+---
+title: 使用 kubeconfig 文件组织集群访问
+content_type: concept
+weight: 60
+---
+<!--
+title: Organizing Cluster Access Using kubeconfig Files
+content_type: concept
+weight: 60
+-->
+
+<!-- overview -->
+
+<!--
+Use kubeconfig files to organize information about clusters, users, namespaces, and
+authentication mechanisms. The `kubectl` command-line tool uses kubeconfig files to
+find the information it needs to choose a cluster and communicate with the API server
+of a cluster.
+-->
+使用 kubeconfig 文件来组织有关集群、用户、命名空间和身份认证机制的信息。
+`kubectl` 命令行工具使用 kubeconfig 文件来查找选择集群所需的信息，并与集群的 API 服务器进行通信。
+
+<!--
+{{< note >}}
+A file that is used to configure access to clusters is called
+a *kubeconfig file*. This is a generic way of referring to configuration files.
+It does not mean that there is a file named `kubeconfig`.
+{{< /note >}}
+-->
+{{< note >}}
+用于配置集群访问的文件称为“kubeconfig 文件”。
+这是引用配置文件的通用方法，并不意味着有一个名为 `kubeconfig` 的文件
+{{< /note >}}
+
+<!--
+{{< warning >}}
+Only use kubeconfig files from trusted sources. Using a specially-crafted kubeconfig file could result in malicious code execution or file exposure.
+If you must use an untrusted kubeconfig file, inspect it carefully first, much as you would a shell script.
+{{< /warning>}}
+-->
+{{< warning >}}
+只使用来源可靠的 kubeconfig 文件。使用特制的 kubeconfig 文件可能会导致恶意代码执行或文件暴露。
+如果必须使用不受信任的 kubeconfig 文件，请首先像检查 shell 脚本一样仔细检查它。
+{{< /warning>}}
+
+<!--
+By default, `kubectl` looks for a file named `config` in the `$HOME/.kube` directory.
+You can specify other kubeconfig files by setting the `KUBECONFIG` environment
+variable or by setting the
+[`-kubeconfig`](/docs/reference/generated/kubectl/kubectl/) flag.
+-->
+默认情况下，`kubectl` 在 `$HOME/.kube` 目录下查找名为 `config` 的文件。
+你可以通过设置 `KUBECONFIG` 环境变量或者设置
+[`--kubeconfig`](/docs/reference/generated/kubectl/kubectl/)参数来指定其他 kubeconfig 文件。
+
+<!--
+For step-by-step instructions on creating and specifying kubeconfig files, see
+[Configure Access to Multiple Clusters](/docs/tasks/access-application-cluster/configure-access-multiple-clusters).
+-->
+有关创建和指定 kubeconfig 文件的分步说明，请参阅
+[配置对多集群的访问](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters)。
+
+<!-- body -->
+
+<!--
+## Supporting multiple clusters, users, and authentication mechanisms
+-->
+## 支持多集群、用户和身份认证机制
+
+<!--
+Suppose you have several clusters, and your users and components authenticate
+in a variety of ways. For example:
+-->
+假设你有多个集群，并且你的用户和组件以多种方式进行身份认证。比如：
+
+<!--
+- A running kubelet might authenticate using certificates.
+- A user might authenticate using tokens.
+- Administrators might have sets of certificates that they provide to individual users.
+-->
+- 正在运行的 kubelet 可能使用证书在进行认证。
+- 用户可能通过令牌进行认证。
+- 管理员可能拥有多个证书集合提供给各用户。
+
+<!--
+With kubeconfig files, you can organize your clusters, users, and namespaces.
+You can also define contexts to quickly and easily switch between
+clusters and namespaces.
+-->
+使用 kubeconfig 文件，你可以组织集群、用户和命名空间。你还可以定义上下文，以便在集群和命名空间之间快速轻松地切换。
+
+<!--
+## Context
+-->
+## 上下文（Context）
+
+<!--
+A *context* element in a kubeconfig file is used to group access parameters
+under a convenient name. Each context has three parameters: cluster, namespace, and user.
+By default, the `kubectl` command-line tool uses parameters from
+the *current context* to communicate with the cluster.
+-->
+通过 kubeconfig 文件中的 *context* 元素，使用简便的名称来对访问参数进行分组。
+每个 context 都有三个参数：cluster、namespace 和 user。
+默认情况下，`kubectl` 命令行工具使用 **当前上下文** 中的参数与集群进行通信。
+
+<!--
+To choose the current context:
+-->
+选择当前上下文
+
+```shell
+kubectl config use-context
+```
+
+<!--
+## The KUBECONFIG environment variable
+-->
+## KUBECONFIG 环境变量
+
+<!--
+The `KUBECONFIG` environment variable holds a list of kubeconfig files.
+For Linux and Mac, the list is colon-delimited. For Windows, the list
+is semicolon-delimited. The `KUBECONFIG` environment variable is not
+required. If the `KUBECONFIG` environment variable doesn't exist,
+`kubectl` uses the default kubeconfig file, `$HOME/.kube/config`.
+-->
+`KUBECONFIG` 环境变量包含一个 kubeconfig 文件列表。
+对于 Linux 和 Mac，列表以冒号分隔。对于 Windows，列表以分号分隔。
+`KUBECONFIG` 环境变量不是必要的。
+如果 `KUBECONFIG` 环境变量不存在，`kubectl` 使用默认的 kubeconfig 文件，`$HOME/.kube/config`。
+
+<!--
+If the `KUBECONFIG` environment variable does exist, `kubectl` uses
+an effective configuration that is the result of merging the files
+listed in the `KUBECONFIG` environment variable.
+-->
+如果 `KUBECONFIG` 环境变量存在，`kubectl` 使用 `KUBECONFIG` 环境变量中列举的文件合并后的有效配置。
+
+<!--
+## Merging kubeconfig files
+-->
+## 合并 kubeconfig 文件
+
+<!--
+To see your configuration, enter this command:
+-->
+要查看配置，输入以下命令：
+
+```shell
+kubectl config view
+```
+
+<!--
+As described previously, the output might be from a single kubeconfig file,
+or it might be the result of merging several kubeconfig files.
+-->
+如前所述，输出可能来自 kubeconfig 文件，也可能是合并多个 kubeconfig 文件的结果。
+
+<!--
+Here are the rules that `kubectl` uses when it merges kubeconfig files:
+-->
+以下是 `kubectl` 在合并 kubeconfig 文件时使用的规则。
+
+<!--
+1. If the `-kubeconfig` flag is set, use only the specified file. Do not merge.
+   Only one instance of this flag is allowed.
+
+   Otherwise, if the `KUBECONFIG` environment variable is set, use it as a
+   list of files that should be merged.
+   Merge the files listed in the `KUBECONFIG` environment variable
+   according to these rules:
+
+   * Ignore empty filenames.
+   * Produce errors for files with content that cannot be deserialized.
+   * The first file to set a particular value or map key wins.
+   * Never change the value or map key.
+     Example: Preserve the context of the first file to set `current-context`.
+     Example: If two files specify a `red-user`, use only values from the first file's `red-user`.
+     Even if the second file has non-conflicting entries under `red-user`, discard them.
+-->
+1. 如果设置了 `--kubeconfig` 参数，则仅使用指定的文件。不进行合并。此参数只能使用一次。
+
+   否则，如果设置了 `KUBECONFIG` 环境变量，将它用作应合并的文件列表。根据以下规则合并 `KUBECONFIG` 环境变量中列出的文件：
+
+   * 忽略空文件名。
+   * 对于内容无法反序列化的文件，产生错误信息。
+   * 第一个设置特定值或者映射键的文件将生效。
+   * 永远不会更改值或者映射键。示例：保留第一个文件的上下文以设置 `current-context`。示例：如果两个文件都指定了 `red-user`，则仅使用第一个文件的 `red-user` 中的值。即使第二个文件在 `red-user` 下有非冲突条目，也要丢弃它们。
+
+<!--
+   For an example of setting the `KUBECONFIG` environment variable, see
+   [Setting the KUBECONFIG environment variable](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable).
+-->
+   有关设置 `KUBECONFIG` 环境变量的示例，请参阅
+   [设置 KUBECONFIG 环境变量](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable)。
+
+<!--
+   Otherwise, use the default kubeconfig file, `$HOME/.kube/config`, with no merging.
+-->
+   否则，使用默认的 kubeconfig 文件， `$HOME/.kube/config`，不进行合并。
+
+<!--
+1. Determine the context to use based on the first hit in this chain:
+
+    1. Use the `-context` command-line flag if it exists.
+    2. Use the `current-context` from the merged kubeconfig files.
+-->
+1. 根据此链中的第一个匹配确定要使用的上下文。
+
+    1. 如果存在，使用 `--context` 命令行参数。
+    2. 使用合并的 kubeconfig 文件中的 `current-context`。
+
+<!--
+   An empty context is allowed at this point.
+-->
+   这种场景下允许空上下文。
+
+<!--
+1. Determine the cluster and user. At this point, there might or might not be a context.
+   Determine the cluster and user based on the first hit in this chain,
+   which is run twice: once for user and once for cluster:
+
+   1. Use a command-line flag if it exists: `--user` or `--cluster`.
+   2. If the context is non-empty, take the user or cluster from the context.
+-->
+1. 确定集群和用户。此时，可能有也可能没有上下文。根据此链中的第一个匹配确定集群和用户，这将运行两次：一次用于用户，一次用于集群。
+
+   1. 如果存在，使用命令行参数：`--user` 或者 `--cluster`。
+   2. 如果上下文非空，从上下文中获取用户或集群。
+
+<!--
+   The user and cluster can be empty at this point.
+-->
+   这种场景下用户和集群可以为空。
+
+<!--
+1. Determine the actual cluster information to use. At this point, there might or
+   might not be cluster information.
+   Build each piece of the cluster information based on this chain; the first hit wins:
+
+   1. Use command line flags if they exist: `--server`, `--certificate-authority`, `--insecure-skip-tls-verify`.
+   2. If any cluster information attributes exist from the merged kubeconfig files, use them.
+   3. If there is no server location, fail.
+-->
+1. 确定要使用的实际集群信息。此时，可能有也可能没有集群信息。基于此链构建每个集群信息；第一个匹配项会被采用：
+
+   1. 如果存在：`--server`、`--certificate-authority` 和 `--insecure-skip-tls-verify`，使用命令行参数。
+   2. 如果合并的 kubeconfig 文件中存在集群信息属性，则使用它们。
+   3. 如果没有 server 配置，则配置无效。
+
+<!--
+2. Determine the actual user information to use. Build user information using the same
+   rules as cluster information, except allow only one authentication
+   technique per user:
+
+   1. Use command line flags if they exist: `--client-certificate`, `--client-key`, `--username`, `--password`, `--token`.
+   2. Use the `user` fields from the merged kubeconfig files.
+   3. If there are two conflicting techniques, fail.
+-->
+2. 确定要使用的实际用户信息。使用与集群信息相同的规则构建用户信息，但每个用户只允许一种身份认证技术：
+
+   1. 如果存在：`--client-certificate`、`--client-key`、`--username`、`--password` 和 `--token`，使用命令行参数。
+   2. 使用合并的 kubeconfig 文件中的 `user` 字段。
+   3. 如果存在两种冲突技术，则配置无效。
+
+<!--
+3. For any information still missing, use default values and potentially
+   prompt for authentication information.
+-->
+3. 对于仍然缺失的任何信息，使用其对应的默认值，并可能提示输入身份认证信息。
+
+<!--
+## File references
+-->
+## 文件引用
+
+<!--
+File and path references in a kubeconfig file are relative to the location of the kubeconfig file.
+File references on the command line are relative to the current working directory.
+In `$HOME/.kube/config`, relative paths are stored relatively, and absolute paths
+are stored absolutely.
+-->
+kubeconfig 文件中的文件和路径引用是相对于 kubeconfig 文件的位置。
+命令行上的文件引用是相对于当前工作目录的。
+在 `$HOME/.kube/config` 中，相对路径按相对路径存储，绝对路径按绝对路径存储。
+
+<!--
+## Proxy
+
+You can configure `kubectl` to use proxy by setting `proxy-url` in the kubeconfig file, like:
+-->
+## 代理
+
+你可以在 `kubeconfig` 文件中设置 `proxy-url` 来为 `kubectl` 使用代理，例如:
+
+```yaml
+apiVersion: v1
+kind: Config
+
+proxy-url: https://proxy.host:3128
+
+clusters:
+- cluster:
+  name: development
+
+users:
+- name: developer
+
+contexts:
+- context:
+  name: development
+
+```
+
+## {{% heading "whatsnext" %}}
+
+<!--
+* [Configure Access to Multiple Clusters](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
+* [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config)
+--->
+* [配置对多集群的访问](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
+* [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config)

content/zh-cn/docs/concepts/configuration/overview.md

@@ -0,0 +1,229 @@
+---
+title: 配置最佳实践
+content_type: concept
+weight: 10
+---
+<!--
+title: Configuration Best Practices
+content_type: concept
+weight: 10
+-->
+
+<!-- overview -->
+<!--
+This document highlights and consolidates configuration best practices that are introduced throughout the user guide, Getting Started documentation, and examples.
+-->
+本文档重点介绍并整合了整个用户指南、入门文档和示例中介绍的配置最佳实践。
+
+<!--
+This is a living document. If you think of something that is not on this list but might be useful to others, please don't hesitate to file an issue or submit a PR.
+-->
+这是一份不断改进的文件。
+如果你认为某些内容缺失但可能对其他人有用，请不要犹豫，提交 Issue 或提交 PR。
+
+<!-- body -->
+<!--
+## General Configuration Tips
+-->
+## 一般配置提示  {#general-configuration-tips}
+
+<!--
+- When defining configurations, specify the latest stable API version.
+-->
+- 定义配置时，请指定最新的稳定 API 版本。
+
+<!--
+- Configuration files should be stored in version control before being pushed to the cluster. This allows you to quickly roll back a configuration change if necessary. It also aids cluster re-creation and restoration.
+-->
+- 在推送到集群之前，配置文件应存储在版本控制中。
+ 这允许你在必要时快速回滚配置更改。
+ 它还有助于集群重新创建和恢复。 
+
+<!--
+- Write your configuration files using YAML rather than JSON. Though these formats can be used interchangeably in almost all scenarios, YAML tends to be more user-friendly.
+-->
+- 使用 YAML 而不是 JSON 编写配置文件。虽然这些格式几乎可以在所有场景中互换使用，但 YAML 往往更加用户友好。
+
+<!--
+- Group related objects into a single file whenever it makes sense. One file is often easier to manage than several. See the [guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/master/guestbook/all-in-one/guestbook-all-in-one.yaml) file as an example of this syntax.
+-->
+- 只要有意义，就将相关对象分组到一个文件中。
+ 一个文件通常比几个文件更容易管理。
+ 请参阅 [guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/master/guestbook/all-in-one/guestbook-all-in-one.yaml) 文件作为此语法的示例。
+
+<!--
+- Note also that many `kubectl` commands can be called on a directory. For example, you can call `kubectl apply` on a directory of config files.
+-->
+- 另请注意，可以在目录上调用许多`kubectl`命令。
+ 例如，你可以在配置文件的目录中调用`kubectl apply`。
+
+<!--
+- Don't specify default values unnecessarily: simple, minimal configuration will make errors less likely.
+-->
+- 除非必要，否则不指定默认值：简单的最小配置会降低错误的可能性。
+
+<!--
+- Put object descriptions in annotations, to allow better introspection.
+-->
+- 将对象描述放在注释中，以便更好地进行内省。
+
+
+<!--
+## "Naked" Pods vs ReplicaSets, Deployments, and Jobs
+-->
+## “Naked” Pods 与 ReplicaSet，Deployment 和 Jobs
+
+<!--
+- Don't use naked Pods (that is, Pods not bound to a [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) or [Deployment](/docs/concepts/workloads/controllers/deployment/)) if you can avoid it. Naked Pods will not be rescheduled in the event of a node failure.
+-->
+- 如果可能，不要使用独立的 Pods（即，未绑定到
+[ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/) 或
+[Deployment](/zh/docs/concepts/workloads/controllers/deployment/) 的 Pod）。
+ 如果节点发生故障，将不会重新调度独立的 Pods。
+
+<!--
+  A Deployment, which both creates a ReplicaSet to ensure that the desired number of Pods is always available, and specifies a strategy to replace Pods (such as [RollingUpdate](/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)), is almost always preferable to creating Pods directly, except for some explicit [`restartPolicy: Never`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) scenarios. A [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) may also be appropriate.
+-->
+
+Deployment 既可以创建一个 ReplicaSet 来确保预期个数的 Pod 始终可用，也可以指定替换 Pod 的策略（例如
+[RollingUpdate](/zh/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)）。
+除了一些显式的 [`restartPolicy: Never`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)
+场景外，Deployment 通常比直接创建 Pod 要好得多。[Job](/zh/docs/concepts/workloads/controllers/job/) 也可能是合适的选择。
+
+<!--
+## Services
+-->
+## 服务   {#services}
+
+<!--
+- Create a [Service](/docs/concepts/services-networking/service/) before its corresponding backend workloads (Deployments or ReplicaSets), and before any workloads that need to access it. When Kubernetes starts a container, it provides environment variables pointing to all the Services which were running when the container was started. For example, if a Service named `foo` exists, all containers will get the following variables in their initial environment:
+-->
+- 在创建相应的后端工作负载（Deployment 或 ReplicaSet），以及在需要访问它的任何工作负载之前创建
+  [服务](/zh/docs/concepts/services-networking/service/)。
+  当 Kubernetes 启动容器时，它提供指向启动容器时正在运行的所有服务的环境变量。
+  例如，如果存在名为 `foo` 的服务，则所有容器将在其初始环境中获得以下变量。
+
+  ```shell
+  FOO_SERVICE_HOST=<the host the Service is running on>
+  FOO_SERVICE_PORT=<the port the Service is running on>
+  ```
+
+<!--
+  *This does imply an ordering requirement* - any `Service` that a `Pod` wants to access must be created before the `Pod` itself, or else the environment variables will not be populated.  DNS does not have this restriction.
+-->
+  *这确实意味着在顺序上的要求* - 必须在 `Pod` 本身被创建之前创建 `Pod` 想要访问的任何 `Service`，
+  否则将环境变量不会生效。DNS 没有此限制。
+
+<!--
+- An optional (though strongly recommended) [cluster add-on](/docs/concepts/cluster-administration/addons/) is a DNS server.  The
+DNS server watches the Kubernetes API for new `Services` and creates a set of DNS records for each.  If DNS has been enabled throughout the cluster then all `Pods` should be able to do name resolution of `Services` automatically.
+-->
+- 一个可选（尽管强烈推荐）的[集群插件](/zh/docs/concepts/cluster-administration/addons/)
+  是 DNS 服务器。DNS 服务器为新的 `Services` 监视 Kubernetes API，并为每个创建一组 DNS 记录。
+  如果在整个集群中启用了 DNS，则所有 `Pods` 应该能够自动对 `Services` 进行名称解析。
+
+<!--
+- Don't specify a `hostPort` for a Pod unless it is absolutely necessary. When you bind a Pod to a `hostPort`, it limits the number of places the Pod can be scheduled, because each <`hostIP`, `hostPort`, `protocol`> combination must be unique. If you don't specify the `hostIP` and `protocol` explicitly, Kubernetes will use `0.0.0.0` as the default `hostIP` and `TCP` as the default `protocol`.
+-->
+- 除非绝对必要，否则不要为 Pod 指定 `hostPort`。
+  将 Pod 绑定到`hostPort`时，它会限制 Pod 可以调度的位置数，因为每个
+  `<hostIP, hostPort, protocol>`组合必须是唯一的。
+  如果你没有明确指定 `hostIP` 和 `protocol`，Kubernetes 将使用 `0.0.0.0` 作为默认
+  `hostIP` 和 `TCP` 作为默认 `protocol`。
+
+<!--
+  If you only need access to the port for debugging purposes, you can use the [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls) or [`kubectl port-forward`](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/).
+-->
+  如果你只需要访问端口以进行调试，则可以使用
+  [apiserver proxy](/zh/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls)或
+  [`kubectl port-forward`](/zh/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)。
+
+<!--
+  If you explicitly need to expose a Pod's port on the node, consider using a [NodePort](/docs/concepts/services-networking/service/#type-nodeport) Service before resorting to `hostPort`.
+-->
+  如果你明确需要在节点上公开 Pod 的端口，请在使用 `hostPort` 之前考虑使用
+  [NodePort](/zh/docs/concepts/services-networking/service/#type-nodeport) 服务。
+
+<!--
+- Avoid using `hostNetwork`, for the same reasons as `hostPort`.
+-->
+- 避免使用 `hostNetwork`，原因与 `hostPort` 相同。
+
+<!--
+- Use [headless Services](/docs/concepts/services-networking/service/#headless-
+services) (which have a `ClusterIP` of `None`) for service discovery when you don't need `kube-proxy` load balancing.
+-->
+- 当你不需要 `kube-proxy` 负载均衡时，使用
+  [无头服务](/zh/docs/concepts/services-networking/service/#headless-services)  
+  (`ClusterIP` 被设置为 `None`)以便于服务发现。
+
+<!--
+## Using Labels
+-->
+## 使用标签   {#using-labels}
+
+<!--
+- Define and use [labels](/docs/concepts/overview/working-with-objects/labels/) that identify __semantic attributes__ of your application or Deployment, such as `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. You can use these labels to select the appropriate Pods for other resources; for example, a Service that selects all `tier: frontend` Pods, or all `phase: test` components of `app: myapp`. See the [guestbook](https://github.com/kubernetes/examples/tree/master/guestbook/) app for examples of this approach.
+-->
+- 定义并使用[标签](/zh/docs/concepts/overview/working-with-objects/labels/)来识别应用程序
+  或 Deployment 的 __语义属性__，例如`{ app: myapp, tier: frontend, phase: test, deployment: v3 }`。
+  你可以使用这些标签为其他资源选择合适的 Pod；
+  例如，一个选择所有 `tier: frontend` Pod 的服务，或者 `app: myapp` 的所有 `phase: test` 组件。
+  有关此方法的示例，请参阅 [guestbook](https://github.com/kubernetes/examples/tree/master/guestbook/) 。
+
+<!--
+A Service can be made to span multiple Deployments by omitting release-specific labels from its selector. [Deployments](/docs/concepts/workloads/controllers/deployment/) make it easy to update a running service without downtime.
+-->
+通过从选择器中省略特定发行版的标签，可以使服务跨越多个 Deployment。
+当你需要不停机的情况下更新正在运行的服务，可以使用[Deployment](/zh/docs/concepts/workloads/controllers/deployment/)。
+
+<!--
+A desired state of an object is described by a Deployment, and if changes to that spec are _applied_, the deployment controller changes the actual state to the desired state at a controlled rate.
+-->
+Deployment 描述了对象的期望状态，并且如果对该规范的更改被成功应用，
+则 Deployment 控制器以受控速率将实际状态改变为期望状态。
+
+<!--
+- Use the [Kubernetes common labels](/docs/concepts/overview/working-with-objects/common-labels/) for common use cases. These standardized labels enrich the metadata in a way that allows tools, including `kubectl` and [dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard), to work in an interoperable way.
+-->
+
+- 对于常见场景，应使用 [Kubernetes 通用标签](/zh/docs/concepts/overview/working-with-objects/common-labels/)。
+  这些标准化的标签丰富了对象的元数据，使得包括 `kubectl` 和
+  [仪表板（Dashboard）](/zh/docs/tasks/access-application-cluster/web-ui-dashboard)
+  这些工具能够以可互操作的方式工作。
+
+<!--
+- You can manipulate labels for debugging. Because Kubernetes controllers (such as ReplicaSet) and Services match to Pods using selector labels, removing the relevant labels from a Pod will stop it from being considered by a controller or from being served traffic by a Service. If you remove the labels of an existing Pod, its controller will create a new Pod to take its place. This is a useful way to debug a previously "live" Pod in a "quarantine" environment. To interactively remove or add labels, use [`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label).
+-->
+- 你可以操纵标签进行调试。
+  由于 Kubernetes 控制器（例如 ReplicaSet）和服务使用选择器标签来匹配 Pod，
+  从 Pod 中删除相关标签将阻止其被控制器考虑或由服务提供服务流量。
+  如果删除现有 Pod 的标签，其控制器将创建一个新的 Pod 来取代它。
+  这是在"隔离"环境中调试先前"活跃"的 Pod 的有用方法。
+  要以交互方式删除或添加标签，请使用 [`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label)。
+
+<!--
+## Using kubectl
+-->
+## 使用 kubectl   {#using-kubectl}
+
+<!--
+- Use `kubectl apply -f <directory>`. This looks for Kubernetes configuration in all `.yaml`, `.yml`, and `.json` files in `<directory>` and passes it to `apply`.
+-->
+- 使用 `kubectl apply -f <directory>`。
+  它在 `<directory>` 中的所有` .yaml`、`.yml` 和 `.json` 文件中查找 Kubernetes 配置，并将其传递给 `apply`。
+
+<!--
+- Use label selectors for `get` and `delete` operations instead of specific object names. See the sections on [label selectors](/docs/concepts/overview/working-with-objects/labels/#label-selectors) and [using labels effectively](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively).
+-->
+- 使用标签选择器进行 `get` 和 `delete` 操作，而不是特定的对象名称。
+- 请参阅[标签选择器](/zh/docs/concepts/overview/working-with-objects/labels/#label-selectors)和
+  [有效使用标签](/zh/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)部分。
+
+<!--
+- Use `kubectl run` and `kubectl expose` to quickly create single-container Deployments and Services. See [Use a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/) for an example.
+-->
+- 使用`kubectl run`和`kubectl expose`来快速创建单容器部署和服务。
+  有关示例，请参阅[使用服务访问集群中的应用程序](/zh/docs/tasks/access-application-cluster/service-access-application-cluster/)。
+
+

content/zh-cn/docs/concepts/configuration/windows-resource-management.md

@@ -0,0 +1,134 @@
+---
+title: Windows 节点的资源管理
+content_type: concept
+weight: 75
+---
+<!--
+reviewers:
+- jayunit100
+- jsturtevant
+- marosset
+- perithompson
+title: Resource Management for Windows nodes
+content_type: concept
+weight: 75
+-->
+
+<!-- overview 
+This page outlines the differences in how resources are managed between Linux and Windows.
+-->
+本页概述了 Linux 和 Windows 在资源管理方式上的区别。
+
+<!-- body -->
+<!--
+On Linux nodes, {{< glossary_tooltip text="cgroups" term_id="cgroup" >}} are used
+as a pod boundary for resource control. Containers are created within that boundary for network, process and file system isolation. The Linux cgroup APIs can be used to gather CPU, I/O, and memory use statistics.
+
+In contrast, Windows uses a [_job object_](https://docs.microsoft.com/windows/win32/procthread/job-objects) per container with a system namespace filter
+to contain all processes in a container and provide logical isolation from the
+host. (Job objects are a Windows process isolation mechanism and are different from what Kubernetes refers to as a {{< glossary_tooltip term_id="job" text="Job" >}}).
+
+There is no way to run a Windows container without the namespace filtering in
+place. This means that system privileges cannot be asserted in the context of the
+host, and thus privileged containers are not available on Windows.
+Containers cannot assume an identity from the host because the Security Account Manager (SAM) is separate.
+-->
+在 Linux 节点上，{{< glossary_tooltip text="cgroup" term_id="cgroup" >}} 用作资源控制的 Pod 边界。
+在这个边界内创建容器以便于隔离网络、进程和文件系统。
+Linux cgroup API 可用于收集 CPU、I/O 和内存使用统计数据。
+
+与此相反，Windows 中每个容器对应一个[**作业对象**](https://docs.microsoft.com/zh-cn/windows/win32/procthread/job-objects)，
+与系统命名空间过滤器一起使用，将所有进程包含在一个容器中，提供与主机的逻辑隔离。
+（作业对象是一种 Windows 进程隔离机制，不同于 Kubernetes 提及的 {{< glossary_tooltip term_id="job" text="Job" >}})。
+
+如果没有命名空间过滤，就无法运行 Windows 容器。
+这意味着在主机环境中无法让系统特权生效，因此特权容器在 Windows 上不可用。
+容器不能使用来自主机的标识，因为安全帐户管理器（Security Account Manager，SAM）是独立的。
+
+<!--
+## Memory management {#resource-management-memory}
+
+Windows does not have an out-of-memory process killer as Linux does. Windows always
+treats all user-mode memory allocations as virtual, and pagefiles are mandatory.
+
+Windows nodes do not overcommit memory for processes. The
+net effect is that Windows won't reach out of memory conditions the same way Linux
+does, and processes page to disk instead of being subject to out of memory (OOM)
+termination. If memory is over-provisioned and all physical memory is exhausted,
+then paging can slow down performance.
+-->
+## 内存管理 {#resource-management-memory}
+
+Windows 不像 Linux 一样提供杀手（killer）机制，杀死内存不足的进程。
+Windows 始终将所有用户态内存分配视为虚拟内存，并强制使用页面文件（pagefile）。
+
+Windows 节点不会为进程过量使用内存。
+最终结果是 Windows 不会像 Linux 那样达到内存不足的情况，Windows 将进程页面放到磁盘，
+不会因为内存不足（OOM）而终止进程。
+如果内存配置过量且所有物理内存都已耗尽，则换页性能就会降低。
+<!--
+## CPU management {#resource-management-cpu}
+
+Windows can limit the amount of CPU time allocated for different processes but cannot
+guarantee a minimum amount of CPU time.
+
+On Windows, the kubelet supports a command-line flag to set the
+[scheduling priority](https://docs.microsoft.com/windows/win32/procthread/scheduling-priorities) of the
+kubelet process: `--windows-priorityclass`. This flag allows the kubelet process to get
+more CPU time slices when compared to other processes running on the Windows host.
+More information on the allowable values and their meaning is available at
+[Windows Priority Classes](https://docs.microsoft.com/en-us/windows/win32/procthread/scheduling-priorities#priority-class).
+To ensure that running Pods do not starve the kubelet of CPU cycles, set this flag to `ABOVE_NORMAL_PRIORITY_CLASS` or above.
+-->
+## CPU 管理 {#resource-management-cpu}
+
+Windows 可以限制为不同进程分配的 CPU 时间长度，但无法保证最小的 CPU 时间长度。
+
+在 Windows 上，kubelet 支持使用命令行标志来设置 kubelet 进程的[调度优先级](https://docs.microsoft.com/zh-cn/windows/win32/procthread/scheduling-priorities)：
+`--windows-priorityclass`。
+与 Windows 主机上运行的其他进程相比，此标志允许 kubelet 进程获取更多的 CPU 时间片。
+有关允许值及其含义的更多信息，请访问 [Windows 优先级类](https://docs.microsoft.com/zh-cn/windows/win32/procthread/scheduling-priorities#priority-class)。
+为了确保运行的 Pod 不会耗尽 kubelet 的 CPU 时钟周期，
+要将此标志设置为 `ABOVE_NORMAL_PRIORITY_CLASS` 或更高。
+
+<!--
+## Resource reservation {#resource-reservation}
+
+To account for memory and CPU used by the operating system, the container runtime, and by
+Kubernetes host processes such as the kubelet, you can (and should) reserve
+memory and CPU resources with the  `--kube-reserved` and/or `--system-reserved` kubelet flags.
+On Windows these values are only used to calculate the node's
+[allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) resources.
+-->
+## 资源预留 {#resource-reservation}
+
+为了满足操作系统、容器运行时和 kubelet 等 Kubernetes 主机进程使用的内存和 CPU，
+你可以（且应该）用 `--kube-reserved` 和/或 `--system-reserved` kubelet 标志来预留内存和 CPU 资源。
+在 Windows 上，这些值仅用于计算节点的[可分配](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)资源。
+
+<!--
+As you deploy workloads, set resource memory and CPU limits on containers.
+This also subtracts from `NodeAllocatable` and helps the cluster-wide scheduler in determining which pods to place on which nodes.
+
+Scheduling pods without limits may over-provision the Windows nodes and in extreme
+cases can cause the nodes to become unhealthy.
+-->
+{{< caution >}}
+在你部署工作负载时，需对容器设置内存和 CPU 资源的限制。
+这也会从 `NodeAllocatable` 中减去，帮助集群范围的调度器决定哪些 Pod 放到哪些节点上。
+
+若调度 Pod 时未设置限制值，可能对 Windows 节点过量配置资源。
+在极端情况下，这会让节点变得不健康。
+{{< /caution >}}
+
+<!--
+On Windows, a good practice is to reserve at least 2GiB of memory.
+
+To determine how much CPU to reserve,
+identify the maximum pod density for each node and monitor the CPU usage of
+the system services running there, then choose a value that meets your workload needs.
+-->
+在 Windows 上，一种好的做法是预留至少 2GiB 的内存。
+
+要决定预留多少 CPU，需明确每个节点的最大 Pod 密度，
+并监控节点上运行的系统服务的 CPU 使用率，然后选择一个满足工作负载需求的值。