[zh] fix links in concept section

2020-08-12 19:26:12 +08:00
parent 50007b21d2
commit 11cc9e007a
29 changed files with 82 additions and 82 deletions
@@ -20,7 +20,7 @@ A _Cron Job_ creates [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-com
 One CronJob object is like one line of a _crontab_ (cron table) file. It runs a job periodically
 on a given schedule, written in [Cron](https://en.wikipedia.org/wiki/Cron) format.
 -->
-_Cron Job_ 创建基于时间调度的 [Jobs](/zh/docs/concepts/workloads/controllers/jobs-run-to-completion/)。
+_Cron Job_ 创建基于时间调度的 [Jobs](/zh/docs/concepts/workloads/controllers/job/)。

 一个 CronJob 对象就像 _crontab_ (cron table) 文件中的一行。
 它用 [Cron](https://en.wikipedia.org/wiki/Cron) 格式进行编写，
@@ -199,7 +199,7 @@ If you do not specify either, then the DaemonSet controller will create Pods on
 -->
 ### 仅在某些节点上运行 Pod

-如果指定了 `.spec.template.spec.nodeSelector`，DaemonSet Controller 将在能够与 [Node Selector](/docs/concepts/configuration/assign-pod-node/) 匹配的节点上创建 Pod。类似这种情况，可以指定 `.spec.template.spec.affinity`，然后 DaemonSet Controller 将在能够与 [node Affinity](/docs/concepts/configuration/assign-pod-node/) 匹配的节点上创建 Pod。
+如果指定了 `.spec.template.spec.nodeSelector`，DaemonSet Controller 将在能够与 [Node Selector](/zh/docs/concepts/scheduling-eviction/assign-pod-node/) 匹配的节点上创建 Pod。类似这种情况，可以指定 `.spec.template.spec.affinity`，然后 DaemonSet Controller 将在能够与 [node Affinity](/zh/docs/concepts/scheduling-eviction/assign-pod-node/) 匹配的节点上创建 Pod。
 如果根本就没有指定，则 DaemonSet Controller 将在所有节点上创建 Pod。

 <!--
@@ -232,7 +232,7 @@ DaemonSet 确保所有符合条件的节点都运行该 Pod 的一个副本。

 * Pod 行为的不一致性：正常 Pod 在被创建后等待调度时处于 `Pending` 状态，
  DaemonSet Pods 创建后不会处于 `Pending` 状态下。这使用户感到困惑。
-* [Pod 抢占](/zh/docs/concepts/configuration/pod-priority-preemption/)
+* [Pod 抢占](/docs/concepts/configuration/pod-priority-preemption/)
  由默认调度器处理。启用抢占后，DaemonSet 控制器将在不考虑 Pod 优先级和抢占
  的情况下制定调度决策。

@@ -1030,7 +1030,7 @@ deployment.apps/nginx-deployment scaled
 in your cluster, you can setup an autoscaler for your Deployment and choose the minimum and maximum number of
 Pods you want to run based on the CPU utilization of your existing Pods.
 -->
-假设启用[水平自动缩放 Pod](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)在集群中，可以为 Deployment 设置自动缩放器，并选择最小和最大
+假设启用[水平自动缩放 Pod](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)在集群中，可以为 Deployment 设置自动缩放器，并选择最小和最大
 要基于现有 Pods 的 CPU 利用率运行的 Pods。

 ```shell
@@ -1738,7 +1738,7 @@ can create multiple Deployments, one for each release, following the canary patt
 For general information about working with config files, see [deploying applications](/docs/tutorials/stateless-application/run-stateless-application-deployment/),
 configuring containers, and [using kubectl to manage resources](/docs/concepts/overview/working-with-objects/object-management/) documents.
 -->
-同其他 Kubernetes 配置， Deployment 需要 `apiVersion`， `kind`， 和 `metadata` 字段。有关配置文件的其他信息，参考 [应用 Deployment ](/docs/tutorials/stateless-application/run-stateless-application-deployment/)，配置容器，和 [使用 kubectl 管理资源](/zh/docs/concepts/overview/working-with-objects/object-management/) 相关文档。
+同其他 Kubernetes 配置， Deployment 需要 `apiVersion`， `kind`， 和 `metadata` 字段。有关配置文件的其他信息，参考 [应用 Deployment ](/zh/docs/tasks/run-application/run-stateless-application-deployment/)，配置容器，和 [使用 kubectl 管理资源](/zh/docs/concepts/overview/working-with-objects/object-management/) 相关文档。

 <!--
 A Deployment also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
@@ -1792,7 +1792,7 @@ allowed, which is the default if not specified.
 `.spec.selector` is an required field that specifies a [label selector](/docs/concepts/overview/working-with-objects/labels/)
 for the Pods targeted by this Deployment.
 -->
-`.spec.selector` 是指定本次 Deployment  Pods [标签选择器](/docs/concepts/overview/working-with-objects/labels/)的必要字段。
+`.spec.selector` 是指定本次 Deployment  Pods [标签选择器](/zh/docs/concepts/overview/working-with-objects/labels/)的必要字段。

 <!--
 `.spec.selector` must match `.spec.template.metadata.labels`, or it will be rejected by the API.
@@ -1857,7 +1857,7 @@ the default value.
 fashion when `.spec.strategy.type==RollingUpdate`. You can specify `maxUnavailable` and `maxSurge` to control
 the rolling update process.
 -->
- Deployment 会在 `.spec.strategy.type==RollingUpdate`时，采取 [滚动更新](/docs/tasks/run-application/rolling-update-replication-controller/)的方式更新Pods。可以指定 `maxUnavailable` 和 `maxSurge` 来控制滚动更新操作。
+ Deployment 会在 `.spec.strategy.type==RollingUpdate`时，采取滚动更新的方式更新Pods。可以指定 `maxUnavailable` 和 `maxSurge` 来控制滚动更新操作。

 <!--
 ##### Max Unavailable
@@ -812,7 +812,7 @@ for pods with `RestartPolicy` equal to `OnFailure` or `Never`.
 -->
 ### 副本控制器    {#replication-controller}

-Job 与[副本控制器](/docs/user-guide/replication-controller)是彼此互补的。
+Job 与[副本控制器](/zh/docs/concepts/workloads/controllers/replicationcontroller/)是彼此互补的。
 副本控制器管理的是那些不希望被终止的 Pod （例如，Web 服务器），
 Job 管理的是那些希望被终止的 Pod（例如，批处理作业）。

@@ -81,9 +81,9 @@ their ReplicaSets.
 -->
 ## 怎样使用 ReplicaSet   {#how-to-use-a-replicaset}

-大多数支持 Replication Controllers 的[`kubectl`](/docs/user-guide/kubectl/)命令也支持 ReplicaSets。但[`rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) 命令是个例外。如果您想要滚动更新功能请考虑使用 Deployment。[`rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) 命令是必需的，而 Deployment 是声明性的，因此我们建议通过 [`rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout)命令使用 Deployment。
+大多数支持 Replication Controllers 的[`kubectl`](/zh/docs/reference/kubectl/kubectl/)命令也支持 ReplicaSets。但[`rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) 命令是个例外。如果您想要滚动更新功能请考虑使用 Deployment。[`rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) 命令是必需的，而 Deployment 是声明性的，因此我们建议通过 [`rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout)命令使用 Deployment。

-虽然 ReplicaSets 可以独立使用，但今天它主要被[Deployments](/docs/concepts/workloads/controllers/deployment/) 用作协调 Pod 创建、删除和更新的机制。
+虽然 ReplicaSets 可以独立使用，但今天它主要被[Deployments](/zh/docs/concepts/workloads/controllers/deployment/) 用作协调 Pod 创建、删除和更新的机制。
 当您使用 Deployment 时，您不必担心还要管理它们创建的 ReplicaSet。Deployment 会拥有并管理它们的 ReplicaSet。

 <!--
@@ -171,7 +171,7 @@ A ReplicaSet also needs a [`.spec` section](https://git.k8s.io/community/contrib

 ## 编写 ReplicaSet Spec

-与所有其他 Kubernetes API 对象一样，ReplicaSet  也需要 `apiVersion`、`kind`、和 `metadata` 字段。有关使用清单的一般信息，请参见 [使用 kubectl 管理对象](/docs/concepts/overview/object-management-kubectl/overview/)。
+与所有其他 Kubernetes API 对象一样，ReplicaSet  也需要 `apiVersion`、`kind`、和 `metadata` 字段。有关使用清单的一般信息，请参见 [使用 kubectl 管理对象](/zh/docs/concepts/overview/working-with-objects/object-management/)。

 ReplicaSet 也需要 [`.spec`](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status) 部分。

@@ -195,7 +195,7 @@ for example the [Kubelet](/docs/admin/kubelet/) or Docker.

 ### Pod 模版

-`.spec.template` 是 `.spec` 唯一需要的字段。`.spec.template` 是 [Pod 模版](/zh/docs/concepts/workloads/pods/pod-overview/#pod-templates)。它和 [Pod](/zh/docs/concepts/workloads/pods/) 的语法几乎完全一样，除了它是嵌套的并没有 `apiVersion` 和 `kind`。
+`.spec.template` 是 `.spec` 唯一需要的字段。`.spec.template` 是 [Pod 模版](/zh/docs/concepts/workloads/pods/#pod-templates)。它和 [Pod](/zh/docs/concepts/workloads/pods/) 的语法几乎完全一样，除了它是嵌套的并没有 `apiVersion` 和 `kind`。

 除了所需的 Pod 字段之外，ReplicaSet 中的 Pod 模板必须指定适当的标签和适当的重启策略。

@@ -203,7 +203,7 @@ for example the [Kubelet](/docs/admin/kubelet/) or Docker.

 对于 [重启策略](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)，`.spec.template.spec.restartPolicy` 唯一允许的取值是 `Always`，这也是默认值.

-对于本地容器重新启动，ReplicaSet 委托给了节点上的代理去执行，例如[Kubelet](/docs/admin/kubelet/) 或 Docker 去执行。
+对于本地容器重新启动，ReplicaSet 委托给了节点上的代理去执行，例如[Kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 或 Docker 去执行。

 <!--
 ### Pod Selector
@@ -221,7 +221,7 @@ In Kubernetes 1.9 the API version `apps/v1` on the ReplicaSet kind is the curren

 ### Pod 选择器

-`.spec.selector` 字段是[标签选择器](/docs/concepts/overview/working-with-objects/labels/)。ReplicaSet 管理所有标签匹配与标签选择器的 Pod。它不区分自己创建或删除的 Pod 和其他人或进程创建或删除的pod。这允许在不影响运行中的 Pod 的情况下替换副本集。
+`.spec.selector` 字段是[标签选择器](/zh/docs/concepts/overview/working-with-objects/labels/)。ReplicaSet 管理所有标签匹配与标签选择器的 Pod。它不区分自己创建或删除的 Pod 和其他人或进程创建或删除的pod。这允许在不影响运行中的 Pod 的情况下替换副本集。

 `.spec.template.metadata.labels` 必须匹配 `.spec.selector`，否则它将被 API 拒绝。

@@ -279,7 +279,7 @@ When using the REST API or the `client-go` library, you must set `propagationPol
 ### 删除 ReplicaSet 和它的 Pod

 要删除 ReplicaSet 和它的所有 Pod，使用[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) 命令。
-默认情况下，[垃圾收集器](/docs/concepts/workloads/controllers/garbage-collection/) 自动删除所有依赖的 Pod。
+默认情况下，[垃圾收集器](/zh/docs/concepts/workloads/controllers/garbage-collection/) 自动删除所有依赖的 Pod。

 当使用 REST API 或 `client-go` 库时，您必须在删除选项中将 `propagationPolicy` 设置为 `Background` 或 `Foreground`。例如：

@@ -405,9 +405,9 @@ application using a Deployment, please read [Run a Stateless Application Using a

 ### Deployment （推荐）

-[`Deployment`](/docs/concepts/workloads/controllers/deployment/) 是一个高级 API 对象，它以 `kubectl rolling-update` 的方式更新其底层副本集及其Pod。
+[`Deployment`](/zh/docs/concepts/workloads/controllers/deployment/) 是一个高级 API 对象，它以 `kubectl rolling-update` 的方式更新其底层副本集及其Pod。
 如果您需要滚动更新功能，建议使用 Deployment，因为 Deployment 与 `kubectl rolling-update` 不同的是：它是声明式的、服务器端的、并且具有其他特性。
-有关使用 Deployment 来运行无状态应用的更多信息，请参阅 [使用 Deployment 运行无状态应用](/docs/tasks/run-application/run-stateless-application-deployment/)。
+有关使用 Deployment 来运行无状态应用的更多信息，请参阅 [使用 Deployment 运行无状态应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/)。

 <!--
 ### Bare Pods
@@ -431,7 +431,7 @@ Use a [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) instead o

 ### Job

-使用[`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) 代替ReplicaSet，可以用于那些期望自行终止的 Pod。
+使用[`Job`](/zh/docs/concepts/workloads/controllers/job/) 代替ReplicaSet，可以用于那些期望自行终止的 Pod。

 <!--
 ### DaemonSet
@@ -444,7 +444,7 @@ safe to terminate when the machine is otherwise ready to be rebooted/shutdown.

 ### DaemonSet

-对于管理那些提供主机级别功能（如主机监控和主机日志）的容器，就要用[`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) 而不用 ReplicaSet。
+对于管理那些提供主机级别功能（如主机监控和主机日志）的容器，就要用[`DaemonSet`](/zh/docs/concepts/workloads/controllers/daemonset/) 而不用 ReplicaSet。
 这些 Pod 的寿命与主机寿命有关：这些 Pod 需要先于主机上的其他 Pod 运行，并且在机器准备重新启动/关闭时安全地终止。


@@ -211,7 +211,7 @@ for example the [Kubelet](/docs/admin/kubelet/) or Docker.
 只允许 [`.spec.template.spec.restartPolicy`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 等于 `Always`，如果没有指定，这是默认值。

 对于本地容器重启，ReplicationController 委托给节点上的代理，
-例如 [Kubelet](/docs/reference/command-line-toolls-reference/kubelet/) 或 Docker。
+例如 [Kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 或 Docker。

 <!--
 ### Labels on the ReplicationController
@@ -546,7 +546,7 @@ Use a [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) instead o
 ### Job

 对于预期会自行终止的 Pod (即批处理任务)，使用
-[`Job`](/docs/concepts/workloads/controllers/job/) 而不是 ReplicationController。
+[`Job`](/zh/docs/concepts/workloads/controllers/job/) 而不是 ReplicationController。

 <!--
 ### DaemonSet
@@ -140,7 +140,7 @@ spec:
 * 名为 `nginx` 的 Headless Service 用来控制网络域名。
 * 名为 `web` 的 StatefulSet 有一个 Spec，它表明将在独立的 3 个 Pod 副本中启动 nginx 容器。
 * `volumeClaimTemplates` 将通过 PersistentVolumes 驱动提供的
-  [PersistentVolumes](/zh/docs/concepts/storage/persistent-volumes/) 来提供稳定的存储。
+  [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) 来提供稳定的存储。

 <!--
 ## Pod Selector
@@ -232,7 +232,7 @@ This must be done manually.
 -->
 ### 稳定的存储  {#stable-storage}

-Kubernetes 为每个 VolumeClaimTemplate 创建一个 [PersistentVolume](/zh/docs/concepts/storage/persistent-volumes/)。
+Kubernetes 为每个 VolumeClaimTemplate 创建一个 [PersistentVolumes](/docs/concepts/storage/persistent-volumes/)。
 在上面的 nginx 示例中，每个 Pod 将会得到基于 StorageClass `my-storage-class` 提供的
 1 Gib 的 PersistentVolume。如果没有声明 StorageClass，就会使用默认的 StorageClass。
 当一个 Pod 被调度（重新调度）到节点上时，它的 `volumeMounts` 会挂载与其 
@@ -48,7 +48,7 @@ up finished Jobs (either `Complete` or `Failed`) automatically by specifying the

 TTL 控制器现在只支持 Job。集群操作员可以通过指定 Job 的 `.spec.ttlSecondsAfterFinished`
 字段来自动清理已结束的作业（`Complete` 或 `Failed`），如
-[示例](/zh/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)
+[示例](/zh/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)
 所示。

 <!--