[zh] modify links to en-docs in tutorials to zh-docs

Author: DangHT

content/zh/docs/tutorials/kubernetes-basics/explore/explore-intro.html

@@ -43,7 +43,7 @@ <h2>Kubernetes Pods</h2>
 <!--
         <p>When you created a Deployment in Module <a href="/docs/tutorials/kubernetes-basics/deploy-intro/">2</a>, Kubernetes created a <b>Pod</b> to host your application instance. A Pod is a Kubernetes abstraction that represents a group of one or more application containers (such as Docker), and some shared resources for those containers. Those resources include:</p>
 -->
-        <p>在模块 <a href="/zh/docs/tutorials/kubernetes-basics/deploy-intro/">2</a>创建 Deployment 时, Kubernetes 添加了一个 <b>Pod</b> 来托管你的应用实例。Pod 是 Kubernetes 抽象出来的，表示一组一个或多个应用程序容器（如 Docker），以及这些容器的一些共享资源。这些资源包括:</p>
+        <p>在模块 <a href="/zh/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/">2</a>创建 Deployment 时, Kubernetes 添加了一个 <b>Pod</b> 来托管你的应用实例。Pod 是 Kubernetes 抽象出来的，表示一组一个或多个应用程序容器（如 Docker），以及这些容器的一些共享资源。这些资源包括:</p>
 <!--
         <ul>
           <li>Shared storage, as Volumes</li>
@@ -169,7 +169,7 @@ <h2>使用 kubectl 进行故障排除</h2>
 <!--
         <p>In Module <a href="/docs/tutorials/kubernetes-basics/deploy/deploy-intro/">2</a>, you used Kubectl command-line interface. You'll continue to use it in Module 3 to get information about deployed applications and their environments. The most common operations can be done with the following kubectl commands:</p>
 -->
-        <p>在模块 <a href="/zh/docs/tutorials/kubernetes-basics/deploy/deploy-intro/">2</a>,您使用了 Kubectl 命令行界面。 您将继续在第3单元中使用它来获取有关已部署的应用程序及其环境的信息。 最常见的操作可以使用以下 kubectl 命令完成：</p>
+        <p>在模块 <a href="/zh/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/">2</a>,您使用了 Kubectl 命令行界面。 您将继续在第3单元中使用它来获取有关已部署的应用程序及其环境的信息。 最常见的操作可以使用以下 kubectl 命令完成：</p>
 <!--
         <ul>
           <li><b>kubectl get</b> - list resources</li>

content/zh/docs/tutorials/kubernetes-basics/expose/expose-intro.html

@@ -35,7 +35,7 @@ <h3>目标</h3>
         <h3>Kubernetes Service 总览</h3>
 
 <!--        <p>Kubernetes <a href="/docs/concepts/workloads/pods/pod-overview/">Pods</a> are mortal. Pods in fact have a <a href="/docs/concepts/workloads/pods/pod-lifecycle/">lifecycle</a>. When a worker node dies, the Pods running on the Node are also lost. A <a href="/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a> might then dynamically drive the cluster back to desired state via creation of new Pods to keep your application running. As another example, consider an image-processing backend with 3 replicas. Those replicas are exchangeable; the front-end system should not care about backend replicas or even if a Pod is lost and recreated. That said, each Pod in a Kubernetes cluster has a unique IP address, even Pods on the same Node, so there needs to be a way of automatically reconciling changes among Pods so that your applications continue to function.</p>-->
-        <p> Kubernetes <a href="/zh/docs/concepts/workloads/pods/pod-overview/">Pod</a> 是转瞬即逝的。 Pod 实际上拥有 <a href="/zh/docs/concepts/workloads/pods/pod-lifecycle/">生命周期</a>。 当一个工作 Node 挂掉后, 在 Node 上运行的 Pod 也会消亡。 <a href="/zh/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a> 会自动地通过创建新的 Pod 驱动集群回到目标状态，以保证应用程序正常运行。 换一个例子，考虑一个具有3个副本数的用作图像处理的后端程序。这些副本是可替换的; 前端系统不应该关心后端副本，即使 Pod 丢失或重新创建。也就是说，Kubernetes 集群中的每个 Pod (即使是在同一个 Node 上的 Pod )都有一个惟一的 IP 地址，因此需要一种方法自动协调 Pod 之间的变更，以便应用程序保持运行。</p>
+        <p> Kubernetes <a href="/zh/docs/concepts/workloads/pods/">Pod</a> 是转瞬即逝的。 Pod 实际上拥有 <a href="/zh/docs/concepts/workloads/pods/pod-lifecycle/">生命周期</a>。 当一个工作 Node 挂掉后, 在 Node 上运行的 Pod 也会消亡。 <a href="/zh/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a> 会自动地通过创建新的 Pod 驱动集群回到目标状态，以保证应用程序正常运行。 换一个例子，考虑一个具有3个副本数的用作图像处理的后端程序。这些副本是可替换的; 前端系统不应该关心后端副本，即使 Pod 丢失或重新创建。也就是说，Kubernetes 集群中的每个 Pod (即使是在同一个 Node 上的 Pod )都有一个惟一的 IP 地址，因此需要一种方法自动协调 Pod 之间的变更，以便应用程序保持运行。</p>
 
 <!--        <p>A Service in Kubernetes is an abstraction which defines a logical set of Pods and a policy by which to access them. Services enable a loose coupling between dependent Pods. A Service is defined using YAML <a href="/docs/concepts/configuration/overview/#general-configuration-tips">(preferred)</a> or JSON, like all Kubernetes objects. The set of Pods targeted by a Service is usually determined by a <i>LabelSelector</i> (see below for why you might want a Service without including <code>selector</code> in the spec).</p>-->
         <p> Kubernetes 中的服务(Service)是一种抽象概念，它定义了 Pod 的逻辑集和访问 Pod 的协议。Service 使从属 Pod 之间的松耦合成为可能。 和其他 Kubernetes 对象一样, Service 用 YAML <a href="/zh/docs/concepts/configuration/overview/#general-configuration-tips">(更推荐)</a> 或者 JSON 来定义. Service 下的一组 Pod 通常由 <i>LabelSelector</i> (请参阅下面的说明为什么您可能想要一个 spec 中不包含<code>selector</code>的服务)来标记。</p>

content/zh/docs/tutorials/kubernetes-basics/scale/scale-intro.html

@@ -33,7 +33,7 @@ <h3>扩缩应用程序</h3>
 						<!-- <p>In the previous modules we created a <a href="/docs/concepts/workloads/controllers/deployment/"> Deployment</a>,
 							and then exposed it publicly via a <a href="/docs/concepts/services-networking/service/">Service</a>.
 							The Deployment created only one Pod for running our application.  When traffic increases, we will need to scale the application to keep up with  user demand.</p> -->
-						<p>在之前的模块中，我们创建了一个 <a href="/zh/docs/user-guide/deployments/"> Deployment</a>，然后通过 <a href="/zh/docs/user-guide/services/">Service</a>让其可以开放访问。Deployment 仅为跑这个应用程序创建了一个 Pod。 当流量增加时，我们需要扩容应用程序满足用户需求。</p>
+						<p>在之前的模块中，我们创建了一个 <a href="/zh/docs/concepts/workloads/controllers/deployment/"> Deployment</a>，然后通过 <a href="/zh/docs/concepts/services-networking/service/">Service</a>让其可以开放访问。Deployment 仅为跑这个应用程序创建了一个 Pod。 当流量增加时，我们需要扩容应用程序满足用户需求。</p>
 
 						<!-- <p><b>Scaling</b> is accomplished by changing the number of replicas in a Deployment</p> -->
 						<p><b>扩缩</b> 是通过改变 Deployment 中的副本数量来实现的。</p>
@@ -99,7 +99,7 @@ <h2 style="color: #3771e3;">扩缩概述</h2>
 
                 <!-- <p>Scaling out a Deployment will ensure new Pods are created and scheduled to Nodes with available resources. Scaling in will reduce the number of Pods to the new desired state. Kubernetes also supports
 									<a href="/docs/user-guide/horizontal-pod-autoscaling/">autoscaling</a> of Pods, but it is outside of the scope of this tutorial. Scaling to zero is also possible, and it will terminate all Pods of the specified Deployment.</p> -->
-								<p>扩展 Deployment 将创建新的 Pods，并将资源调度请求分配到有可用资源的节点上，收缩 会将 Pods 数量减少至所需的状态。Kubernetes 还支持 Pods 的<a href="/zh/docs/user-guide/horizontal-pod-autoscaling/">自动缩放</a>，但这并不在本教程的讨论范围内。将 Pods 数量收缩到0也是可以的，但这会终止 Deployment 上所有已经部署的 Pods。</p>
+								<p>扩展 Deployment 将创建新的 Pods，并将资源调度请求分配到有可用资源的节点上，收缩 会将 Pods 数量减少至所需的状态。Kubernetes 还支持 Pods 的<a href="/zh/docs/tasks/run-application/horizontal-pod-autoscale/">自动缩放</a>，但这并不在本教程的讨论范围内。将 Pods 数量收缩到0也是可以的，但这会终止 Deployment 上所有已经部署的 Pods。</p>
 
 								<!-- <p>Running multiple instances of an application will require a way to distribute the traffic to all of them. Services have an integrated load-balancer that will distribute network traffic to all Pods of an exposed Deployment.
 									Services will monitor continuously the running Pods using endpoints, to ensure the traffic is sent only to available Pods.</p> -->