[zh] fix typo of expose-intro.html

Author: xeathen

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</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>