Translate concepts/services-networking/service-topology into Japanese.

Author: shuuji3

content/ja/docs/concepts/services-networking/service-topology.md

@@ -1,13 +1,9 @@
 ---
-reviewers:
-- johnbelamaric
-- imroc
-title: Service Topology
+title: Serviceトポロジー
 feature:
-  title: Service Topology
+  title: Serviceトポロジー
   description: >
-    Routing of service traffic based upon cluster topology.
-
+    Serviceのトラフィックをクラスタートポロジーに基づいてルーティングします。
 content_type: concept
 weight: 10
 ---
@@ -17,96 +13,47 @@ weight: 10
 
 {{< feature-state for_k8s_version="v1.17" state="alpha" >}}
 
-_Service Topology_ enables a service to route traffic based upon the Node
-topology of the cluster. For example, a service can specify that traffic be
-preferentially routed to endpoints that are on the same Node as the client, or
-in the same availability zone.
-
-
+*Serviceトポロジー*を利用すると、Serviceのトラフィックをクラスターのノードトポロジーに基づいてルーティングできるようになります。たとえば、あるServiceのトラフィックに対して、できるだけ同じノードや同じアベイラビリティゾーン上にあるエンドポイントを優先してルーティングするように指定できます。
 
 <!-- body -->
 
-## Introduction
-
-By default, traffic sent to a `ClusterIP` or `NodePort` Service may be routed to
-any backend address for the Service. Since Kubernetes 1.7 it has been possible
-to route "external" traffic to the Pods running on the Node that received the
-traffic, but this is not supported for `ClusterIP` Services, and more complex
-topologies &mdash; such as routing zonally &mdash; have not been possible. The
-_Service Topology_ feature resolves this by allowing the Service creator to
-define a policy for routing traffic based upon the Node labels for the
-originating and destination Nodes.
-
-By using Node label matching between the source and destination, the operator
-may designate groups of Nodes that are "closer" and "farther" from one another,
-using whatever metric makes sense for that operator's requirements. For many
-operators in public clouds, for example, there is a preference to keep service
-traffic within the same zone, because interzonal traffic has a cost associated
-with it, while intrazonal traffic does not. Other common needs include being able
-to route traffic to a local Pod managed by a DaemonSet, or keeping traffic to
-Nodes connected to the same top-of-rack switch for the lowest latency.
-
+## はじめに
 
-## Using Service Topology
+デフォルトでは、`ClusterIP`や`NodePort`Serviceに送信されたトラフィックは、Serviceに対応する任意のバックエンドのアドレスにルーティングされる可能性があります。しかし、Kubernetes 1.7以降では、「外部の」トラフィックをそのトラフィックを受信したノード上のPodにルーティングすることが可能になりました。しかし、この機能は`ClusterIP`Serviceでは対応しておらず、ゾーン内ルーティングなどのより複雑なトポロジーは実現不可能でした。*Serviceトポロジー*の機能を利用すれば、Serviceの作者が送信元ノードと送信先ノードのNodeのラベルに基づいてトラフィックをルーティングするためのポリシーを定義できるようになるため、この問題を解決できます。
 
-If your cluster has Service Topology enabled, you can control Service traffic
-routing by specifying the `topologyKeys` field on the Service spec. This field
-is a preference-order list of Node labels which will be used to sort endpoints
-when accessing this Service. Traffic will be directed to a Node whose value for
-the first label matches the originating Node's value for that label. If there is
-no backend for the Service on a matching Node, then the second label will be
-considered, and so forth, until no labels remain.
+送信元と送信先の間のNodeラベルのマッチングを使用することにより、オペレーターは、そのオペレーターの要件に適したメトリクスを使用して、お互いに「より近い」または「より遠い」ノードのグループを指定できます。たとえば、パブリッククラウド上のさまざまなオペレーターでは、Serviceのトラフィックを同一ゾーン内に留めようとする傾向があります。パブリッククラウドでは、ゾーンをまたぐトラフィックでは関連するコストがかかる一方、ゾーン内のトラフィックにはコストがかからない場合があるからです。その他のニーズとしては、DaemonSetが管理するローカルのPodにトラフィックをルーティングできるようにしたり、レイテンシーを低く抑えるために同じラック上のスイッチに接続されたノードにトラフィックを限定したいというものがあります。
 
-If no match is found, the traffic will be rejected, just as if there were no
-backends for the Service at all. That is, endpoints are chosen based on the first
-topology key with available backends. If this field is specified and all entries
-have no backends that match the topology of the client, the service has no
-backends for that client and connections should fail. The special value `"*"` may
-be used to mean "any topology". This catch-all value, if used, only makes sense
-as the last value in the list.
+## Serviceトポロジーを利用する
 
-If `topologyKeys` is not specified or empty, no topology constraints will be applied.
+クラスターのServiceトポロジーが有効になっていれば、Serviceのspecに`topologyKeys`フィールドを指定することで、Serviceのトラフィックのルーティングを制御できます。このフィールドは、Nodeラベルの優先順位リストで、このServiceにアクセスするときにエンドポイントをソートするために使われます。Traffic will be directed to a Node whose value for the first label matches the originating Node's value for that label.一致したノード上にServiceに対応するバックエンドが存在しなかった場合は、2つ目のラベルについて検討が行われ、同様に、残っているラベルが順番に検討されまます。
 
-Consider a cluster with Nodes that are labeled with their hostname, zone name,
-and region name. Then you can set the `topologyKeys` values of a service to direct
-traffic as follows.
+一致するキーが1つも見つからなかった場合、トラフィックは、Serviceに対応するバックエンドが存在しなかったかのように拒否されます。言い換えると、エンドポイントは、利用可能なバックエンドが存在する最初のトポロジーキーに基づいて選択されます。このフィールドが指定され、すべてのエントリーでクライアントのトポロジーに一致するバックエンドが存在しない場合、そのクライアントに対するバックエンドが存在しないものとしてコネクションが失敗します。「任意のトポロジー」を意味する特別な値`"*"`を指定することもできます。任意の値にマッチするこの値に意味があるのは、リストの最後の値として使った場合だけです。
 
-* Only to endpoints on the same node, failing if no endpoint exists on the node:
-  `["kubernetes.io/hostname"]`.
-* Preferentially to endpoints on the same node, falling back to endpoints in the
-  same zone, followed by the same region, and failing otherwise: `["kubernetes.io/hostname",
-  "topology.kubernetes.io/zone", "topology.kubernetes.io/region"]`.
-  This may be useful, for example, in cases where data locality is critical.
-* Preferentially to the same zone, but fallback on any available endpoint if
-  none are available within this zone:
-  `["topology.kubernetes.io/zone", "*"]`.
+`topologyKeys`が未指定または空の場合、トポロジーの制約は適用されません。
 
+ホスト名、ゾーン名、リージョン名のラベルが付いたノードを持つクラスターについて考えてみましょう。このとき、Serviceの`topologyKeys`の値を設定することで、トラフィックの向きを以下のように制御できます。
 
+* トラフィックを同じノード上のエンドポイントのみに向け、同じノード上にエンドポイントが1つも存在しない場合には失敗するようにする: `["kubernetes.io/hostname"]`。
+* 同一ノード上のエンドポイントを優先し、失敗した場合には同一ゾーン上のエンドポイント、同一リージョンゾーンのエンドポイントへとフォールバックし、それ以外の場合には失敗する: `["kubernetes.io/hostname", "topology.kubernetes.io/zone", "topology.kubernetes.io/region"]`。これは、たとえばデータのローカリティが非常に重要である場合などに役に立ちます。
+* 同一ゾーンを優先しますが、ゾーン内に利用可能なノードが存在しない場合は、利用可能な任意のエンドポイントにフォールバックする: `["topology.kubernetes.io/zone", "*"]`。
 
-## Constraints
+## 制約
 
-* Service topology is not compatible with `externalTrafficPolicy=Local`, and
-  therefore a Service cannot use both of these features. It is possible to use
-  both features in the same cluster on different Services, just not on the same
-  Service.
+* Serviceトポロジーは`externalTrafficPolicy=Local`と互換性がないため、Serviceは2つの機能を同時に利用できません。2つの機能を同じクラスター上の異なるServiceでそれぞれ利用することは可能ですが、同一のService上では利用できません。
 
-* Valid topology keys are currently limited to `kubernetes.io/hostname`,
-  `topology.kubernetes.io/zone`, and `topology.kubernetes.io/region`, but will
-  be generalized to other node labels in the future.
+* 有効なトポロジーキーは、現在は`kubernetes.io/hostname`、`topology.kubernetes.io/zone`、および`topology.kubernetes.io/region`に限定されています。しかし、将来は一般化され、他のノードラベルも使用できるようになる予定です。
 
-* Topology keys must be valid label keys and at most 16 keys may be specified.
+* トポロジーキーは有効なラベルのキーでなければならず、最大で16個のキーまで指定できます。
 
-* The catch-all value, `"*"`, must be the last value in the topology keys, if
-  it is used.
+* すべての値をキャッチする`"*"`を使用する場合は、トポロジーキーの最後の値として指定しなければなりません。
 
+## 例
 
-## Examples
+以下では、Serviceトポロジーの機能を利用したよくある例を紹介します。
 
-The following are common examples of using the Service Topology feature.
+### ノードローカルのエンドポイントだけを使用する
 
-### Only Node Local Endpoints
-
-A Service that only routes to node local endpoints. If no endpoints exist on the node, traffic is dropped:
+ノードローカルのエンドポイントのみにルーティングするServiceの例です。もし同一ノード上にエンドポイントが存在しない場合、トラフィックは損失します。
 
 ```yaml
 apiVersion: v1
@@ -124,9 +71,9 @@ spec:
     - "kubernetes.io/hostname"
 ```
 
-### Prefer Node Local Endpoints
+### ノードローカルのエンドポイントを優先して使用する
 
-A Service that prefers node local Endpoints but falls back to cluster wide endpoints if node local endpoints do not exist:
+ノードローカルのエンドポイントを優先して使用しますが、ノードローカルのエンドポイントが存在しない場合にはクラスター全体のエンドポイントにフォールバックするServiceの例です。
 
 ```yaml
 apiVersion: v1
@@ -146,10 +93,9 @@ spec:
 ```
 
 
-### Only Zonal or Regional Endpoints
-
-A Service that prefers zonal then regional endpoints. If no endpoints exist in either, traffic is dropped.
+### 同一ゾーンや同一リージョンのエンドポイントだけを使用する
 
+同一リージョンのエンドポイントより同一ゾーンのエンドポイントを優先するServiceの例です。もしいずれのエンドポイントも存在しない場合、トラフィックは損失します。
 
 ```yaml
 apiVersion: v1
@@ -168,9 +114,9 @@ spec:
     - "topology.kubernetes.io/region"
 ```
 
-### Prefer Node Local, Zonal, then Regional Endpoints
+### ノードローカル、同一ゾーン、同一リーションのエンドポイントを優先して使用する
 
-A Service that prefers node local, zonal, then regional endpoints but falls back to cluster wide endpoints.
+ノードローカル、同一ゾーン、同一リージョンのエンドポイントを順番に優先し、クラスター全体のエンドポイントにフォールバックするServiceの例です。
 
 ```yaml
 apiVersion: v1
@@ -191,13 +137,9 @@ spec:
     - "*"
 ```
 
-
-
-
 ## {{% heading "whatsnext" %}}
 
-
-* Read about [enabling Service Topology](/docs/tasks/administer-cluster/enabling-service-topology)
-* Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)
+* [Serviceトポトジーを有効にする](/docs/tasks/administer-cluster/enabling-service-topology)を読む。
+* [アプリケーションをServiceと接続する](/ja/docs/concepts/services-networking/connect-applications-service/)を読む。