[zh] Sync reference file (7)

tengqm · tengqm · commit 955ae25dd392 · 2021-06-26T20:27:51.000+08:00
This is the last one for our batch sync of the reference section.
diff --git a/content/zh/docs/reference/command-line-tools-reference/_index.md b/content/zh/docs/reference/command-line-tools-reference/_index.md
@@ -1,4 +1,8 @@
 ---
-title: 命令行工具参考
+title: 组件工具
 weight: 60
 ---
+<!--
+title: Component tools
+weight: 60
+-->
diff --git a/content/zh/docs/reference/command-line-tools-reference/feature-gates.md b/content/zh/docs/reference/command-line-tools-reference/feature-gates.md
@@ -1349,7 +1349,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `ValidateProxyRedirects`: This flag controls whether the API server should
   validate that redirects are only followed to the same host. Only used if the
   `StreamingProxyRedirects` flag is enabled.
-- 'VolumeCapacityPriority`: Enable support for prioritizing nodes in different
+- `VolumeCapacityPriority`: Enable support for prioritizing nodes in different
   topologies based on available PV capacity.
 - `VolumePVCDataSource`: Enable support for specifying an existing PVC as a DataSource.
 - `VolumeScheduling`: Enable volume topology aware scheduling and make the
@@ -1361,7 +1361,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
 -->
 - `ValidateProxyRedirects`： 这个标志控制 API 服务器是否应该验证只跟随到相同的主机的重定向。
   仅在启用 `StreamingProxyRedirects` 标志时被使用。
-- 'VolumeCapacityPriority`: 基于可用 PV 容量的拓扑，启用对不同节点的优先级支持。
+- `VolumeCapacityPriority`: 基于可用 PV 容量的拓扑，启用对不同节点的优先级支持。
 - `VolumePVCDataSource`：启用对将现有 PVC 指定数据源的支持。
 - `VolumeScheduling`：启用卷拓扑感知调度，并使 PersistentVolumeClaim（PVC）
   绑定能够了解调度决策；当与 PersistentLocalVolumes 特性门控一起使用时，
diff --git a/content/zh/docs/reference/command-line-tools-reference/kube-apiserver.md b/content/zh/docs/reference/command-line-tools-reference/kube-apiserver.md
@@ -96,7 +96,8 @@ the host's default interface will be used.
 The map from metric-label to value allow-list of this label. The key's format is &lt;MetricName&gt;,&lt;LabelName&gt;. The value's format is &lt;allowed_value&gt;,&lt;allowed_value&gt;...e.g. metric1,label1='v1,v2,v3', metric1,label2='v1,v2,v3' metric2,label1='v1,v2,v3'.
 -->
 允许使用的指标标签到指标值的映射列表。键的格式为 &lt;MetricName&gt;,&lt;LabelName&gt;.
-值得格式为 &lt;allowed_value&gt;,&lt;allowed_value&gt;...。 例如：<code>metric1,label1='v1,v2,v3', metric1,label2='v1,v2,v3' metric2,label1='v1,v2,v3'</code>。
+值的格式为 &lt;allowed_value&gt;,&lt;allowed_value&gt;...。 
+例如：<code>metric1,label1='v1,v2,v3', metric1,label2='v1,v2,v3' metric2,label1='v1,v2,v3'</code>。
 </p></td>
 </tr>
 
@@ -2251,7 +2252,7 @@ are permanently removed in the release after that.
 -->
 你要显示隐藏指标的先前版本。仅先前的次要版本有意义，不允许其他值。
 格式为 &lt;major&gt;.&lt;minor&gt;，例如："1.16"。
-这种格式的目的是确保您有机会注意到下一个版本是否隐藏了其他指标，
+这种格式的目的是确保你有机会注意到下一个版本是否隐藏了其他指标，
 而不是在此之后将它们从发行版中永久删除时感到惊讶。
 </td>
 </tr>
diff --git a/content/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md b/content/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md
@@ -299,8 +299,7 @@ A kubelet authenticating using bootstrap tokens is authenticated as a user in th
 <!--
 As this feature matures, you
 should ensure tokens are bound to a Role Based Access Control (RBAC) policy
-which limits requests (using the [bootstrap
-token](/docs/reference/access-authn-authz/bootstrap-tokens/)) strictly to client
+which limits requests (using the [bootstrap token](/docs/reference/access-authn-authz/bootstrap-tokens/)) strictly to client
 requests related to certificate provisioning. With RBAC in place, scoping the
 tokens to a group allows for great flexibility. For example, you could disable a
 particular bootstrap group's access when you are done provisioning the nodes.
@@ -335,7 +334,7 @@ The process is two-fold:
 
 <!--
 From the kubelet's perspective, one token is like another and has no special meaning.
-From the kube-apiserver's perspective, however, the bootstrap token is special. Due to its `Type`, `namespace` and `name`, kube-apiserver recognizes it as a special token,
+From the kube-apiserver's perspective, however, the bootstrap token is special. Due to its `type`, `namespace` and `name`, kube-apiserver recognizes it as a special token,
 and grants anyone authenticating with that token special bootstrap rights, notably treating them as a member of the `system:bootstrappers` group. This fulfills a basic requirement
 for TLS bootstrapping.
 -->
@@ -354,7 +353,7 @@ If you want to use bootstrap tokens, you must enable it on kube-apiserver with t
 
 如果你希望使用启动引导令牌，你必须在 kube-apiserver 上使用下面的标志启用之：
 
-```
+```console
 --enable-bootstrap-token-auth=true
 ```
 
@@ -373,7 +372,7 @@ kube-apiserver 能够将令牌视作身份认证依据。
 至少 128 位混沌数据。这里的随机数生成器可以是现代 Linux 系统上的
 `/dev/urandom`。生成令牌的方式有很多种。例如：
 
-```
+```shell
 head -c 16 /dev/urandom | od -An -t x | tr -d ' '
 ```
 
@@ -388,7 +387,7 @@ values can be anything and the quoted group name should be as depicted:
 令牌文件看起来是下面的例子这样，其中前面三个值可以是任何值，用引号括起来
 的组名称则只能用例子中给的值。
 
-```
+```console
 02b50b05283e98dd0fd71db496ef01e8,kubelet-bootstrap,10001,"system:bootstrappers"
 ```
 
@@ -406,9 +405,13 @@ further details.
 <!--
 ### Authorize kubelet to create CSR
 
-Now that the bootstrapping node is _authenticated_ as part of the `system:bootstrappers` group, it needs to be _authorized_ to create a certificate signing request (CSR) as well as retrieve it when done. Fortunately, Kubernetes ships with a `ClusterRole` with precisely these (and just these) permissions, `system:node-bootstrapper`.
+Now that the bootstrapping node is _authenticated_ as part of the
+`system:bootstrappers` group, it needs to be _authorized_ to create a
+certificate signing request (CSR) as well as retrieve it when done.
+Fortunately, Kubernetes ships with a `ClusterRole` with precisely these (and
+only these) permissions, `system:node-bootstrapper`.
 
-To do this, you just need to create a `ClusterRoleBinding` that binds the `system:bootstrappers` group to the cluster role `system:node-bootstrapper`.
+To do this, you only need to create a `ClusterRoleBinding` that binds the `system:bootstrappers` group to the cluster role `system:node-bootstrapper`.
 -->
 ### 授权 kubelet 创建 CSR    {#authorize-kubelet-to-create-csr}
 
@@ -420,7 +423,7 @@ To do this, you just need to create a `ClusterRoleBinding` that binds the `syste
 为了实现这一点，你只需要创建 `ClusterRoleBinding`，将 `system:bootstrappers`
 组绑定到集群角色 `system:node-bootstrapper`。
 
-```
+```yaml
 # 允许启动引导节点创建 CSR
 apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRoleBinding
@@ -495,7 +498,7 @@ kubelet 身份认证，很重要的一点是为控制器管理器所提供的 CA
 
 要将 Kubernetes CA 密钥和证书提供给 kube-controller-manager，可使用以下标志：
 
-```
+```shell
 --cluster-signing-cert-file="/etc/path/to/kubernetes/ca/ca.crt" --cluster-signing-key-file="/etc/path/to/kubernetes/ca/ca.key"
 ```
 
@@ -504,7 +507,7 @@ For example:
 -->
 例如：
 
-```
+```shell
 --cluster-signing-cert-file="/var/lib/kubernetes/ca.pem" --cluster-signing-key-file="/var/lib/kubernetes/ca-key.pem"
 ```
 
@@ -513,7 +516,7 @@ The validity duration of signed certificates can be configured with flag:
 -->
 所签名的证书的合法期限可以通过下面的标志来配置：
 
-```
+```shell
 --cluster-signing-duration
 ```
 
@@ -602,7 +605,7 @@ collection.
 -->
 作为 [kube-controller-manager](/zh/docs/reference/generated/kube-controller-manager/)
 的一部分的 `csrapproving` 控制器是自动被启用的。
-该控制器使用 [`SubjectAccessReview` API](/docs/reference/access-authn-authz/authorization/#checking-api-access)
+该控制器使用 [`SubjectAccessReview` API](/zh/docs/reference/access-authn-authz/authorization/#checking-api-access)
 来确定是否某给定用户被授权请求 CSR，之后基于鉴权结果执行批复操作。
 为了避免与其它批复组件发生冲突，内置的批复组件不会显式地拒绝任何 CSRs。
 该组件仅是忽略未被授权的请求。
@@ -682,7 +685,7 @@ The important elements to note are:
 
 <!--
 The format of the token does not matter, as long as it matches what kube-apiserver expects. In the above example, we used a bootstrap token.
-As stated earlier, _any_ valid authentication method can be used, not just tokens.
+As stated earlier, _any_ valid authentication method can be used, not only tokens.
 
 Because the bootstrap `kubeconfig` _is_ a standard `kubeconfig`, you can use `kubectl` to generate it. To create the above example file:
 -->
diff --git a/content/zh/docs/reference/command-line-tools-reference/kubelet.md b/content/zh/docs/reference/command-line-tools-reference/kubelet.md
@@ -8,13 +8,15 @@ weight: 28
 
 
 <!--
-The kubelet is the primary "node agent" that runs on each node. It can register the node with the apiserver using one of: the hostname; a flag to override the hostname; or specific logic for a cloud provider.
+The kubelet is the primary "node agent" that runs on each
+node. It can register the node with the apiserver using one of: the hostname; a flag to override the hostname; or specific logic for a cloud provider.
 -->
 kubelet 是在每个 Node 节点上运行的主要 “节点代理”。它可以使用以下之一向 apiserver 注册：
 主机名（hostname）；覆盖主机名的参数；某云驱动的特定逻辑。
 
 <!--
-The kubelet works in terms of a PodSpec. A PodSpec is a YAML or JSON object that describes a pod. The kubelet takes a set of PodSpecs that are provided through various mechanisms (primarily through the apiserver) and ensures that the containers described in those PodSpecs are running and healthy. The kubelet doesn't manage containers which were not created by Kubernetes.
+The kubelet works in terms of a PodSpec. A PodSpec is a YAML or JSON object
+that describes a pod. The kubelet takes a set of PodSpecs that are provided through various mechanisms (primarily through the apiserver) and ensures that the containers described in those PodSpecs are running and healthy. The kubelet doesn't manage containers which were not created by Kubernetes.
 -->
 kubelet 是基于 PodSpec 来工作的。每个 PodSpec 是一个描述 Pod 的 YAML 或 JSON 对象。
 kubelet 接受通过各种机制（主要是通过 apiserver）提供的一组 PodSpec，并确保这些
@@ -431,9 +433,9 @@ kubelet 将从此标志所指的文件中加载其初始配置。此路径可以
 <tr>
 <td></td><td style="line-height: 130%; word-wrap: break-word;">
 <!--
-&lt;Warning: Beta feature&gt; Set the maximum number of container log files that can be present for a container. The number must be &ge; 2. This flag can only be used with `--container-runtime=remote`. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
+Set the maximum number of container log files that can be present for a container. The number must be &ge; 2. This flag can only be used with `--container-runtime=remote`. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
 -->
-&lt;警告：beta 特性&gt; 设置容器的日志文件个数上限。此值必须不小于 2。
+设置容器的日志文件个数上限。此值必须不小于 2。
 此标志只能与 <code>--container-runtime=remote</code> 标志一起使用。
 已弃用：应在 <code>--config</code> 所给的配置文件中进行设置。
 （<a href="https://kubernetes.io/zh/docs/tasks/administer-cluster/kubelet-config-file/">进一步了解</a>）
@@ -446,10 +448,9 @@ kubelet 将从此标志所指的文件中加载其初始配置。此路径可以
 <tr>
 <td></td><td style="line-height: 130%; word-wrap: break-word;">
 <!--
-&lt;Warning: Beta feature&gt; Set the maximum size (e.g. 10Mi) of container log file before it is rotated. This flag can only be used with `--container-runtime=remote`.  (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
+Set the maximum size (e.g. 10Mi) of container log file before it is rotated. This flag can only be used with `--container-runtime=remote`.  (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
 -->
-&lt;警告：beta 特性&gt; 设置容器日志文件在轮换生成新文件时之前的最大值
-（例如，<code>10Mi</code>）。
+设置容器日志文件在轮换生成新文件时之前的最大值（例如，<code>10Mi</code>）。
 此标志只能与 <code>--container-runtime=remote</code> 标志一起使用。
 已弃用：应在 <code>--config</code> 所给的配置文件中进行设置。
 （<a href="https://kubernetes.io/zh/docs/tasks/administer-cluster/kubelet-config-file/">进一步了解</a>）
@@ -892,7 +893,6 @@ AppArmor=true|false (BETA - default=true)<br/>
 BalanceAttachedNodeVolumes=true|false (ALPHA - default=false)<br/>
 BoundServiceAccountTokenVolume=true|false (ALPHA - default=false)<br/>
 CPUManager=true|false (BETA - default=true)<br/>
-CRIContainerLogRotation=true|false (BETA - default=true)<br/>
 CSIInlineVolume=true|false (BETA - default=true)<br/>
 CSIMigration=true|false (BETA - default=true)<br/>
 CSIMigrationAWS=true|false (BETA - default=false)<br/>
@@ -984,7 +984,6 @@ AppArmor=true|false (BETA - 默认值为 true)<br/>
 BalanceAttachedNodeVolumes=true|false (ALPHA - 默认值为 false)<br/>
 BoundServiceAccountTokenVolume=true|false (ALPHA - 默认值为 false)<br/>
 CPUManager=true|false (BETA - 默认值为 true)<br/>
-CRIContainerLogRotation=true|false (BETA - 默认值为 true)<br/>
 CSIInlineVolume=true|false (BETA - 默认值为 true)<br/>
 CSIMigration=true|false (BETA - 默认值为 true)<br/>
 CSIMigrationAWS=true|false (BETA - 默认值为 false)<br/>
@@ -1814,10 +1813,12 @@ The CIDR to use for pod IP addresses, only used in standalone mode. In cluster m
 <tr>
 <td></td><td style="line-height: 130%; word-wrap: break-word;">
 <!--
-The image whose network/IPC namespaces containers in each pod will use. This docker-specific flag only works when container-runtime is set to `docker`.
+ Specified image will not be pruned by the image garbage collector. When container-runtime is set to `docker`, all containers in each pod will use the network/ipc namespaces from this image. Other CRI implementations have their own configuration to set this image.
 -->
-指定基础设施镜像，Pod 内所有容器与其共享网络和 IPC 命名空间。
-仅当容器运行环境设置为 <code>docker</code> 时，此特定于 docker 的参数才有效。
+所指定的镜像不会被镜像垃圾收集器删除。
+当容器运行环境设置为 <code>docker</code> 时，各个 Pod 中的所有容器都会
+使用此镜像中的网络和 IPC 名字空间。
+其他 CRI 实现有自己的配置来设置此镜像。
 </td>
 </tr>
 
