[zh]Update tutorials pages for links with '/zh/' prefix, using new prefix '/zh-cn/'
This commit is contained in:
howieyuen
@@ -38,7 +38,7 @@ weight: 20
|
||||
</div>
|
||||
<div class="row">
|
||||
<div class="col-md-12">
|
||||
<a class="btn btn-lg btn-success" href="/zh/docs/tutorials/kubernetes-basics/scale/scale-intro/" role="button">继续阅读第5单元<span class="btn__next">›</span></a>
|
||||
<a class="btn btn-lg btn-success" href="/zh-cn/docs/tutorials/kubernetes-basics/scale/scale-intro/" role="button">继续阅读第5单元<span class="btn__next">›</span></a>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
@@ -35,10 +35,10 @@ weight: 10
|
||||
<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-cn/docs/concepts/workloads/pods/">Pod</a> 是转瞬即逝的。 Pod 实际上拥有 <a href="/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/">生命周期</a>。 当一个工作 Node 挂掉后, 在 Node 上运行的 Pod 也会消亡。 <a href="/zh-cn/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>
|
||||
<p> Kubernetes 中的服务(Service)是一种抽象概念，它定义了 Pod 的逻辑集和访问 Pod 的协议。Service 使从属 Pod 之间的松耦合成为可能。 和其他 Kubernetes 对象一样, Service 用 YAML <a href="/zh-cn/docs/concepts/configuration/overview/#general-configuration-tips">(更推荐)</a> 或者 JSON 来定义. Service 下的一组 Pod 通常由 <i>LabelSelector</i> (请参阅下面的说明为什么你可能想要一个 spec 中不包含<code>selector</code>的服务)来标记。</p>
|
||||
|
||||
<!-- <p>Although each Pod has a unique IP address, those IPs are not exposed outside the cluster without a Service. Services allow your applications to receive traffic. Services can be exposed in different ways by specifying a <code>type</code> in the ServiceSpec:</p>-->
|
||||
<p>尽管每个 Pod 都有一个唯一的 IP 地址，但是如果没有 Service ，这些 IP 不会暴露在集群外部。Service 允许你的应用程序接收流量。Service 也可以用在 ServiceSpec 标记<code>type</code>的方式暴露</p>
|
||||
@@ -53,7 +53,7 @@ weight: 10
|
||||
<li><i>ExternalName</i> - 通过返回带有该名称的 CNAME 记录，使用任意名称(由 spec 中的<code>externalName</code>指定)公开 Service。不使用代理。这种类型需要<code>kube-dns</code>的v1.7或更高版本。</li>
|
||||
</ul>
|
||||
<!-- <p>More information about the different types of Services can be found in the <a href="/docs/tutorials/services/source-ip/">Using Source IP</a> tutorial. Also see <a href="/docs/concepts/services-networking/connect-applications-service">Connecting Applications with Services</a>.</p>-->
|
||||
<p>更多关于不同 Service 类型的信息可以在<a href="/zh/docs/tutorials/services/source-ip/">使用源 IP </a> 教程。 也请参阅 <a href="/zh/docs/concepts/services-networking/connect-applications-service">连接应用程序和 Service </a>。</p>
|
||||
<p>更多关于不同 Service 类型的信息可以在<a href="/zh-cn/docs/tutorials/services/source-ip/">使用源 IP </a> 教程。 也请参阅 <a href="/zh-cn/docs/concepts/services-networking/connect-applications-service">连接应用程序和 Service </a>。</p>
|
||||
<!-- <p>Additionally, note that there are some use cases with Services that involve not defining <code>selector</code> in the spec. A Service created without <code>selector</code> will also not create the corresponding Endpoints object. This allows users to manually map a Service to specific endpoints. Another possibility why there may be no selector is you are strictly using <code>type: ExternalName</code>.</p>-->
|
||||
<p>另外，需要注意的是有一些 Service 的用例没有在 spec 中定义<code>selector</code>。 一个没有<code>selector</code>创建的 Service 也不会创建相应的端点对象。这允许用户手动将服务映射到特定的端点。没有 selector 的另一种可能是你严格使用<code>type: ExternalName</code>来标记。</p>
|
||||
</div>
|
||||
@@ -95,7 +95,7 @@ weight: 10
|
||||
<!-- <p>A Service routes traffic across a set of Pods. Services are the abstraction that allow pods to die and replicate in Kubernetes without impacting your application. Discovery and routing among dependent Pods (such as the frontend and backend components in an application) is handled by Kubernetes Services.</p>-->
|
||||
<p>Service 通过一组 Pod 路由通信。Service 是一种抽象，它允许 Pod 死亡并在 Kubernetes 中复制，而不会影响应用程序。在依赖的 Pod (如应用程序中的前端和后端组件)之间进行发现和路由是由Kubernetes Service 处理的。</p>
|
||||
<!-- <p>Services match a set of Pods using <a href="/docs/concepts/overview/working-with-objects/labels">labels and selectors</a>, a grouping primitive that allows logical operation on objects in Kubernetes. Labels are key/value pairs attached to objects and can be used in any number of ways:</p>-->
|
||||
<p>Service 匹配一组 Pod 是使用 <a href="/zh/docs/concepts/overview/working-with-objects/labels">标签(Label)和选择器(Selector)</a>, 它们是允许对 Kubernetes 中的对象进行逻辑操作的一种分组原语。标签(Label)是附加在对象上的键/值对，可以以多种方式使用:</p>
|
||||
<p>Service 匹配一组 Pod 是使用 <a href="/zh-cn/docs/concepts/overview/working-with-objects/labels">标签(Label)和选择器(Selector)</a>, 它们是允许对 Kubernetes 中的对象进行逻辑操作的一种分组原语。标签(Label)是附加在对象上的键/值对，可以以多种方式使用:</p>
|
||||
<ul>
|
||||
<!-- <li>Designate objects for development, test, and production</li>-->
|
||||
<!-- <li>Embed version tags</li>-->
|
||||
@@ -132,7 +132,7 @@ weight: 10
|
||||
<div class="row">
|
||||
<div class="col-md-12">
|
||||
<!-- <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/expose/expose-interactive/" role="button">Start Interactive Tutorial<span class="btn__next">›</span></a>-->
|
||||
<a class="btn btn-lg btn-success" href="/zh/docs/tutorials/kubernetes-basics/expose/expose-interactive/" role="button">开始交互式教程<span class="btn__next">›</span></a>
|
||||
<a class="btn btn-lg btn-success" href="/zh-cn/docs/tutorials/kubernetes-basics/expose/expose-interactive/" role="button">开始交互式教程<span class="btn__next">›</span></a>
|
||||
</div>
|
||||
</div>
|
||||
</main>
|
||||
|
||||
Reference in New Issue
Block a user