From f5fac359bb64637abdb68443c5ff0e9c3b05df3c Mon Sep 17 00:00:00 2001 From: Kobayashi Daisuke Date: Tue, 18 Jan 2022 15:35:10 +0900 Subject: [PATCH 01/10] translate topology-aware-hints into Japanese --- .../topology-aware-hints.md | 105 ++++++++++++++++++ 1 file changed, 105 insertions(+) create mode 100644 content/ja/docs/concepts/services-networking/topology-aware-hints.md diff --git a/content/ja/docs/concepts/services-networking/topology-aware-hints.md b/content/ja/docs/concepts/services-networking/topology-aware-hints.md new file mode 100644 index 0000000000..e56d7bf73d --- /dev/null +++ b/content/ja/docs/concepts/services-networking/topology-aware-hints.md @@ -0,0 +1,105 @@ +--- +reviewers: +- robscott +title: Topology Aware Hints +content_type: concept +weight: 45 +--- + + + + +{{< feature-state for_k8s_version="v1.23" state="beta" >}} + +*Topology Aware Hints*は、クライアントがendpointをどのように使用するかについての提案を含めることにより、トポロジーを考慮したルーティングを可能にします。このアプローチでは、EndpointSliceおよび/またはEndpointオブジェクトの消費者が、これらのネットワークエンドポイントへのトラフィックを、それが発生した場所の近くにルーティングできるように、メタデータを追加します。 + +たとえば、ローカリティ内でトラフィックをルーティングすることで、コストを削減したり、ネットワークパフォーマンスを向上させたりできます。 + + + +## 動機 + +Kubernetesクラスタは、マルチゾーン環境で展開されることが多くなっています。 +トポロジー・アウェア・ヒント_は、トラフィックを発信元のゾーン内に留めておくのに役立つメカニズムを提供します。このコンセプトは、一般に「Topology Aware Routing」と呼ばれています。endpointSliceコントローラは{{< glossary_tooltip term_id="Service" >}のendpointを計算する際に、各endpointのトポロジー（地域とゾーン）を考慮し、ゾーンに割り当てるためのヒントフィールドに値を入力します。 +EndpointSliceコントローラは、各endpointのトポロジー（地域とゾーン）を考慮し、ゾーンに割り当てるためのヒントフィールドに入力します。 +{{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}のようなクラスタコンポーネントは、次にこれらのヒントを消費し、それらを使用してトラフィックがルーティングされる方法に影響を与えることが可能です。(トポロジー的に近いendpointを優先する)。 + + +## Topology Aware Hintを使う + +`service.kubernetes.io/topology-aware-hints`アノテーションを`auto`に設定すると、サービスに対してTopology Aware Hintを有効にすることができます。これは、EndpointSliceコントローラーが安全と判断した場合に、トポロジーヒントを設定するように指示します。 +重要なのは、これはヒントが常に設定されることを保証するものではないことです。 + +## 使い方 {#implementation} + +この機能を有効にする機能は、EndpointSliceコントローラーとkube-proxyの2つのコンポーネントに分かれています。このセクションでは、各コンポーネントがこの機能をどのように実装しているか、高レベルの概要を説明します。 + +### EndpointSliceコントローラー {#implementation-control-plane} + +この機能が有効な場合、EndpointSliceコントローラーはEndpointSliceにヒントを設定する役割を担います。 +コントローラーは、各ゾーンに比例した量のendpointを割り当てます。 +この割合は、そのゾーンで実行されているノードの[割り当て可能な](/ja/docs/task/administer-cluster/reserve-compute-resources/#node-allocatable)CPUコアを基に決定されます。 + +たとえば、あるゾーンに2つのCPUコアがあり、別のゾーンに1つのCPUコアしかない場合、コントローラは2つのCPUコアを持つゾーンに2倍のendpointを割り当てます。 + +次の例は、ヒントが入力されたときのEndpointSliceの外観を示しています。 + +```yaml +apiVersion: discovery.k8s.io/v1 +kind: EndpointSlice +metadata: + name: example-hints + labels: + kubernetes.io/service-name: example-svc +addressType: IPv4 +ports: + - name: http + protocol: TCP + port: 80 +endpoints: + - addresses: + - "10.1.2.3" + conditions: + ready: true + hostname: pod-1 + zone: zone-a + hints: + forZones: + - name: "zone-a" +``` + +### kube-proxy {#implementation-kube-proxy} + +kube-proxyは、EndpointSliceコントローラーによって設定されたヒントに基づいて、ルーティング先のendpointをフィルター処理します。ほとんどの場合、これは、kube-proxyが同じゾーン内のendpointにトラフィックをルーティングできることを意味します。コントローラーが別のゾーンからendpointを割り当てて、ゾーン間でendpointがより均等に分散されるようにする場合があります。これにより、一部のトラフィックが他のゾーンにルーティングされます。 + +## セーフガード + +各ノードのKubernetesコントロールプレーンとkube-proxyは、Topology Aware Hintを使用する前に、いくつかのセーフガードルールを適用します。これらがチェックアウトされない場合、kube-proxyは、ゾーンに関係なく、クラスター内のどこからでもendpointを選択します。 + +1. **endpointの数が不十分です：** クラスター内のゾーンよりもendpointが少ない場合、コントローラーはヒントを割り当てません。 + +2. **バランスの取れた割り当てを実現できません：** 場合によっては、ゾーン間でendpointのバランスの取れた割り当てを実現できないことがあります。たとえば、ゾーンaがゾーンbの2倍の大きさであるが、endpointが2つしかない場合、ゾーンaに割り当てられたendpointはゾーンbの2倍のトラフィックを受信する可能性があります。この「予想される過負荷」値が各ゾーンの許容しきい値を下回ることができない場合、コントローラーはヒントを割り当てません。重要なことに、これはリアルタイムのフィードバックに基づいていません。それでも、個々のendpointが過負荷になる可能性があります。 + +3. **1つ以上のノードの情報が不十分です：**ノードに`topology.kubernetes.io/zone`ラベルがないか、割り当て可能なCPUの値を報告していない場合、コントロールプレーンはtopology-aware endpoint hintsを設定しないため、kube-proxyはendpointをゾーンでフィルタリングしません。 + +4. **1つ以上のendpointにゾーンヒントが存在しません：** これが発生すると、kube-proxyはTopology Aware Hintsから、またはTopology Aware Hintsへの移行が進行中であると見なします。この状態のサービスに対してendpointをフィルタリングすることは危険であるため、kube-proxyはすべてのendpointを使用するようにフォールバックします。 + +5. **ゾーンはヒントで表されません：** kube-proxyが、実行中のゾーンをターゲットとするヒントを持つendpointを少なくとも1つ見つけることができない場合、すべてのゾーンのendpointを使用することになります。これは、既存のクラスターに新しいゾーンを追加するときに発生する可能性が最も高くなります。 + +## Constraints + +* サービスで`externalTrafficPolicy`または`internalTrafficPolicy`が`Local`に設定されている場合、Topology Aware Hintは使用されません。同じServiceではなく、異なるServiceの同じクラスターで両方の機能を使用することができます。 + +* このアプローチは、ゾーンのサブセットから発信されるトラフィックの割合が高いサービスではうまく機能しません。代わりに、これは、着信トラフィックが各ゾーンのノードの容量にほぼ比例することを前提としています。 + +* EndpointSliceコントローラーは、各ゾーンの比率を計算するときに、準備ができていないノードを無視します。ノードの大部分の準備ができていない場合、これは意図しない結果をもたらす可能性があります。 + +* EndpointSliceコントローラーは、各ゾーンの比率を計算するデプロイ時に{{< glossary_tooltip + text="tolerations" term_id="toleration" >}}を考慮しません。サービスをバックアップするPodがクラスタ内のノードのサブセットに制限されている場合、これは考慮されません。 + +* これは、オートスケーリングと相性が悪いかもしれません。例えば、多くのトラフィックが1つのゾーンから発信されている場合、そのゾーンに割り当てられたendpointのみがそのトラフィックを処理することになります。その結果、{{< glossary_tooltip + text="Horizontal Pod Autoscaler" term_id="horizontal-pod-autoscaler" >}}がこのイベントを拾えなくなったり、新しく追加されたPodが別のゾーンで開始されたりする可能性があります。 + +## {{% heading "whatsnext" %}} + +* [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を読む。 From d2ad1640c3a5ad540bb6ef858dc64be51bfdbe52 Mon Sep 17 00:00:00 2001 From: Kobayashi Daisuke Date: Tue, 18 Jan 2022 15:40:34 +0900 Subject: [PATCH 02/10] fix build error --- .../docs/concepts/services-networking/topology-aware-hints.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/services-networking/topology-aware-hints.md b/content/ja/docs/concepts/services-networking/topology-aware-hints.md index e56d7bf73d..f69bf04b64 100644 --- a/content/ja/docs/concepts/services-networking/topology-aware-hints.md +++ b/content/ja/docs/concepts/services-networking/topology-aware-hints.md @@ -20,7 +20,7 @@ weight: 45 ## 動機 Kubernetesクラスタは、マルチゾーン環境で展開されることが多くなっています。 -トポロジー・アウェア・ヒント_は、トラフィックを発信元のゾーン内に留めておくのに役立つメカニズムを提供します。このコンセプトは、一般に「Topology Aware Routing」と呼ばれています。endpointSliceコントローラは{{< glossary_tooltip term_id="Service" >}のendpointを計算する際に、各endpointのトポロジー（地域とゾーン）を考慮し、ゾーンに割り当てるためのヒントフィールドに値を入力します。 +トポロジー・アウェア・ヒント_は、トラフィックを発信元のゾーン内に留めておくのに役立つメカニズムを提供します。このコンセプトは、一般に「Topology Aware Routing」と呼ばれています。endpointSliceコントローラは{{< glossary_tooltip term_id="Service" >}}のendpointを計算する際に、各endpointのトポロジー（地域とゾーン）を考慮し、ゾーンに割り当てるためのヒントフィールドに値を入力します。 EndpointSliceコントローラは、各endpointのトポロジー（地域とゾーン）を考慮し、ゾーンに割り当てるためのヒントフィールドに入力します。 {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}のようなクラスタコンポーネントは、次にこれらのヒントを消費し、それらを使用してトラフィックがルーティングされる方法に影響を与えることが可能です。(トポロジー的に近いendpointを優先する)。 From 027b08ca2202531c4d4255ab876c9928292408b4 Mon Sep 17 00:00:00 2001 From: Kobayashi Daisuke Date: Tue, 18 Jan 2022 16:07:37 +0900 Subject: [PATCH 03/10] fix some mistakes --- .../services-networking/topology-aware-hints.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/topology-aware-hints.md b/content/ja/docs/concepts/services-networking/topology-aware-hints.md index f69bf04b64..d988388c90 100644 --- a/content/ja/docs/concepts/services-networking/topology-aware-hints.md +++ b/content/ja/docs/concepts/services-networking/topology-aware-hints.md @@ -1,7 +1,7 @@ --- reviewers: - robscott -title: Topology Aware Hints +title: Topology Aware Hint content_type: concept weight: 45 --- @@ -11,7 +11,7 @@ weight: 45 {{< feature-state for_k8s_version="v1.23" state="beta" >}} -*Topology Aware Hints*は、クライアントがendpointをどのように使用するかについての提案を含めることにより、トポロジーを考慮したルーティングを可能にします。このアプローチでは、EndpointSliceおよび/またはEndpointオブジェクトの消費者が、これらのネットワークエンドポイントへのトラフィックを、それが発生した場所の近くにルーティングできるように、メタデータを追加します。 +*Topology Aware Hint*は、クライアントがendpointをどのように使用するかについての提案を含めることにより、トポロジーを考慮したルーティングを可能にします。このアプローチでは、EndpointSliceおよび/またはEndpointオブジェクトの消費者が、これらのネットワークエンドポイントへのトラフィックを、それが発生した場所の近くにルーティングできるように、メタデータを追加します。 たとえば、ローカリティ内でトラフィックをルーティングすることで、コストを削減したり、ネットワークパフォーマンスを向上させたりできます。 @@ -20,9 +20,9 @@ weight: 45 ## 動機 Kubernetesクラスタは、マルチゾーン環境で展開されることが多くなっています。 -トポロジー・アウェア・ヒント_は、トラフィックを発信元のゾーン内に留めておくのに役立つメカニズムを提供します。このコンセプトは、一般に「Topology Aware Routing」と呼ばれています。endpointSliceコントローラは{{< glossary_tooltip term_id="Service" >}}のendpointを計算する際に、各endpointのトポロジー（地域とゾーン）を考慮し、ゾーンに割り当てるためのヒントフィールドに値を入力します。 +*Topology Aware Hint*は、トラフィックを発信元のゾーン内に留めておくのに役立つメカニズムを提供します。このコンセプトは、一般に「Topology Aware Routing」と呼ばれています。endpointSliceコントローラは{{< glossary_tooltip term_id="Service" >}}のendpointを計算する際に、各endpointのトポロジー（地域とゾーン）を考慮し、ゾーンに割り当てるためのヒントフィールドに値を入力します。 EndpointSliceコントローラは、各endpointのトポロジー（地域とゾーン）を考慮し、ゾーンに割り当てるためのヒントフィールドに入力します。 -{{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}のようなクラスタコンポーネントは、次にこれらのヒントを消費し、それらを使用してトラフィックがルーティングされる方法に影響を与えることが可能です。(トポロジー的に近いendpointを優先する)。 +{{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}のようなクラスタコンポーネントは、次にこれらのヒントを消費し、それらを使用してトラフィックがルーティングされる方法に影響を与えることが可能です(トポロジー的に近いendpointを優先します)。 ## Topology Aware Hintを使う @@ -80,9 +80,9 @@ kube-proxyは、EndpointSliceコントローラーによって設定されたヒ 2. **バランスの取れた割り当てを実現できません：** 場合によっては、ゾーン間でendpointのバランスの取れた割り当てを実現できないことがあります。たとえば、ゾーンaがゾーンbの2倍の大きさであるが、endpointが2つしかない場合、ゾーンaに割り当てられたendpointはゾーンbの2倍のトラフィックを受信する可能性があります。この「予想される過負荷」値が各ゾーンの許容しきい値を下回ることができない場合、コントローラーはヒントを割り当てません。重要なことに、これはリアルタイムのフィードバックに基づいていません。それでも、個々のendpointが過負荷になる可能性があります。 -3. **1つ以上のノードの情報が不十分です：**ノードに`topology.kubernetes.io/zone`ラベルがないか、割り当て可能なCPUの値を報告していない場合、コントロールプレーンはtopology-aware endpoint hintsを設定しないため、kube-proxyはendpointをゾーンでフィルタリングしません。 +3. **1つ以上のノードの情報が不十分です：** ノードに`topology.kubernetes.io/zone`ラベルがないか、割り当て可能なCPUの値を報告していない場合、コントロールプレーンはtopology-aware endpoint hintsを設定しないため、kube-proxyはendpointをゾーンでフィルタリングしません。 -4. **1つ以上のendpointにゾーンヒントが存在しません：** これが発生すると、kube-proxyはTopology Aware Hintsから、またはTopology Aware Hintsへの移行が進行中であると見なします。この状態のサービスに対してendpointをフィルタリングすることは危険であるため、kube-proxyはすべてのendpointを使用するようにフォールバックします。 +4. **1つ以上のendpointにゾーンヒントが存在しません：** これが発生すると、kube-proxyはTopology Aware Hintから、またはTopology Aware Hintへの移行が進行中であると見なします。この状態のサービスに対してendpointをフィルタリングすることは危険であるため、kube-proxyはすべてのendpointを使用するようにフォールバックします。 5. **ゾーンはヒントで表されません：** kube-proxyが、実行中のゾーンをターゲットとするヒントを持つendpointを少なくとも1つ見つけることができない場合、すべてのゾーンのendpointを使用することになります。これは、既存のクラスターに新しいゾーンを追加するときに発生する可能性が最も高くなります。 From d48800b7632030e4ca719f7efa8e75dfc0e708ed Mon Sep 17 00:00:00 2001 From: Kobayashi Daisuke Date: Wed, 19 Jan 2022 17:21:35 +0900 Subject: [PATCH 04/10] =?UTF-8?q?address=20reviews=20(change=20"=E3=83=BC"?= =?UTF-8?q?,=20"=EF=BC=9A")?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../topology-aware-hints.md | 26 +++++++++---------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/topology-aware-hints.md b/content/ja/docs/concepts/services-networking/topology-aware-hints.md index d988388c90..70b710de91 100644 --- a/content/ja/docs/concepts/services-networking/topology-aware-hints.md +++ b/content/ja/docs/concepts/services-networking/topology-aware-hints.md @@ -1,7 +1,5 @@ --- -reviewers: -- robscott -title: Topology Aware Hint +title: トポロジーを意識したヒント content_type: concept weight: 45 --- @@ -19,10 +17,10 @@ weight: 45 ## 動機 -Kubernetesクラスタは、マルチゾーン環境で展開されることが多くなっています。 -*Topology Aware Hint*は、トラフィックを発信元のゾーン内に留めておくのに役立つメカニズムを提供します。このコンセプトは、一般に「Topology Aware Routing」と呼ばれています。endpointSliceコントローラは{{< glossary_tooltip term_id="Service" >}}のendpointを計算する際に、各endpointのトポロジー（地域とゾーン）を考慮し、ゾーンに割り当てるためのヒントフィールドに値を入力します。 -EndpointSliceコントローラは、各endpointのトポロジー（地域とゾーン）を考慮し、ゾーンに割り当てるためのヒントフィールドに入力します。 -{{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}のようなクラスタコンポーネントは、次にこれらのヒントを消費し、それらを使用してトラフィックがルーティングされる方法に影響を与えることが可能です(トポロジー的に近いendpointを優先します)。 +Kubernetesクラスターは、マルチゾーン環境で展開されることが多くなっています。 +*Topology Aware Hint*は、トラフィックを発信元のゾーン内に留めておくのに役立つメカニズムを提供します。このコンセプトは、一般に「Topology Aware Routing」と呼ばれています。endpointSliceコントローラーは{{< glossary_tooltip term_id="Service" >}}のendpointを計算する際に、各endpointのトポロジー（地域とゾーン）を考慮し、ゾーンに割り当てるためのヒントフィールドに値を入力します。 +EndpointSliceコントローラーは、各endpointのトポロジー（地域とゾーン）を考慮し、ゾーンに割り当てるためのヒントフィールドに入力します。 +{{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}のようなクラスターコンポーネントは、次にこれらのヒントを消費し、それらを使用してトラフィックがルーティングされる方法に影響を与えることが可能です(トポロジー的に近いendpointを優先します)。 ## Topology Aware Hintを使う @@ -40,7 +38,7 @@ EndpointSliceコントローラは、各endpointのトポロジー（地域と コントローラーは、各ゾーンに比例した量のendpointを割り当てます。 この割合は、そのゾーンで実行されているノードの[割り当て可能な](/ja/docs/task/administer-cluster/reserve-compute-resources/#node-allocatable)CPUコアを基に決定されます。 -たとえば、あるゾーンに2つのCPUコアがあり、別のゾーンに1つのCPUコアしかない場合、コントローラは2つのCPUコアを持つゾーンに2倍のendpointを割り当てます。 +たとえば、あるゾーンに2つのCPUコアがあり、別のゾーンに1つのCPUコアしかない場合、コントローラーは2つのCPUコアを持つゾーンに2倍のendpointを割り当てます。 次の例は、ヒントが入力されたときのEndpointSliceの外観を示しています。 @@ -76,15 +74,15 @@ kube-proxyは、EndpointSliceコントローラーによって設定されたヒ 各ノードのKubernetesコントロールプレーンとkube-proxyは、Topology Aware Hintを使用する前に、いくつかのセーフガードルールを適用します。これらがチェックアウトされない場合、kube-proxyは、ゾーンに関係なく、クラスター内のどこからでもendpointを選択します。 -1. **endpointの数が不十分です：** クラスター内のゾーンよりもendpointが少ない場合、コントローラーはヒントを割り当てません。 +1. **endpointの数が不十分です:** クラスター内のゾーンよりもendpointが少ない場合、コントローラーはヒントを割り当てません。 -2. **バランスの取れた割り当てを実現できません：** 場合によっては、ゾーン間でendpointのバランスの取れた割り当てを実現できないことがあります。たとえば、ゾーンaがゾーンbの2倍の大きさであるが、endpointが2つしかない場合、ゾーンaに割り当てられたendpointはゾーンbの2倍のトラフィックを受信する可能性があります。この「予想される過負荷」値が各ゾーンの許容しきい値を下回ることができない場合、コントローラーはヒントを割り当てません。重要なことに、これはリアルタイムのフィードバックに基づいていません。それでも、個々のendpointが過負荷になる可能性があります。 +2. **バランスの取れた割り当てを実現できません:** 場合によっては、ゾーン間でendpointのバランスの取れた割り当てを実現できないことがあります。たとえば、ゾーンaがゾーンbの2倍の大きさであるが、endpointが2つしかない場合、ゾーンaに割り当てられたendpointはゾーンbの2倍のトラフィックを受信する可能性があります。この「予想される過負荷」値が各ゾーンの許容しきい値を下回ることができない場合、コントローラーはヒントを割り当てません。重要なことに、これはリアルタイムのフィードバックに基づいていません。それでも、個々のendpointが過負荷になる可能性があります。 -3. **1つ以上のノードの情報が不十分です：** ノードに`topology.kubernetes.io/zone`ラベルがないか、割り当て可能なCPUの値を報告していない場合、コントロールプレーンはtopology-aware endpoint hintsを設定しないため、kube-proxyはendpointをゾーンでフィルタリングしません。 +3. **1つ以上のノードの情報が不十分です:** ノードに`topology.kubernetes.io/zone`ラベルがないか、割り当て可能なCPUの値を報告していない場合、コントロールプレーンはtopology-aware endpoint hintsを設定しないため、kube-proxyはendpointをゾーンでフィルタリングしません。 -4. **1つ以上のendpointにゾーンヒントが存在しません：** これが発生すると、kube-proxyはTopology Aware Hintから、またはTopology Aware Hintへの移行が進行中であると見なします。この状態のサービスに対してendpointをフィルタリングすることは危険であるため、kube-proxyはすべてのendpointを使用するようにフォールバックします。 +4. **1つ以上のendpointにゾーンヒントが存在しません:** これが発生すると、kube-proxyはTopology Aware Hintから、またはTopology Aware Hintへの移行が進行中であると見なします。この状態のサービスに対してendpointをフィルタリングすることは危険であるため、kube-proxyはすべてのendpointを使用するようにフォールバックします。 -5. **ゾーンはヒントで表されません：** kube-proxyが、実行中のゾーンをターゲットとするヒントを持つendpointを少なくとも1つ見つけることができない場合、すべてのゾーンのendpointを使用することになります。これは、既存のクラスターに新しいゾーンを追加するときに発生する可能性が最も高くなります。 +5. **ゾーンはヒントで表されません:** kube-proxyが、実行中のゾーンをターゲットとするヒントを持つendpointを少なくとも1つ見つけることができない場合、すべてのゾーンのendpointを使用することになります。これは、既存のクラスターに新しいゾーンを追加するときに発生する可能性が最も高くなります。 ## Constraints @@ -95,7 +93,7 @@ kube-proxyは、EndpointSliceコントローラーによって設定されたヒ * EndpointSliceコントローラーは、各ゾーンの比率を計算するときに、準備ができていないノードを無視します。ノードの大部分の準備ができていない場合、これは意図しない結果をもたらす可能性があります。 * EndpointSliceコントローラーは、各ゾーンの比率を計算するデプロイ時に{{< glossary_tooltip - text="tolerations" term_id="toleration" >}}を考慮しません。サービスをバックアップするPodがクラスタ内のノードのサブセットに制限されている場合、これは考慮されません。 + text="tolerations" term_id="toleration" >}}を考慮しません。サービスをバックアップするPodがクラスター内のノードのサブセットに制限されている場合、これは考慮されません。 * これは、オートスケーリングと相性が悪いかもしれません。例えば、多くのトラフィックが1つのゾーンから発信されている場合、そのゾーンに割り当てられたendpointのみがそのトラフィックを処理することになります。その結果、{{< glossary_tooltip text="Horizontal Pod Autoscaler" term_id="horizontal-pod-autoscaler" >}}がこのイベントを拾えなくなったり、新しく追加されたPodが別のゾーンで開始されたりする可能性があります。 From ffa586acf4fb8b6368eafc975e331bdcea0bd81e Mon Sep 17 00:00:00 2001 From: Kobayashi Daisuke Date: Wed, 19 Jan 2022 18:03:14 +0900 Subject: [PATCH 05/10] Corresponds to review comments about comma. --- .../services-networking/topology-aware-hints.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/topology-aware-hints.md b/content/ja/docs/concepts/services-networking/topology-aware-hints.md index 70b710de91..cefba8b322 100644 --- a/content/ja/docs/concepts/services-networking/topology-aware-hints.md +++ b/content/ja/docs/concepts/services-networking/topology-aware-hints.md @@ -18,14 +18,14 @@ weight: 45 ## 動機 Kubernetesクラスターは、マルチゾーン環境で展開されることが多くなっています。 -*Topology Aware Hint*は、トラフィックを発信元のゾーン内に留めておくのに役立つメカニズムを提供します。このコンセプトは、一般に「Topology Aware Routing」と呼ばれています。endpointSliceコントローラーは{{< glossary_tooltip term_id="Service" >}}のendpointを計算する際に、各endpointのトポロジー（地域とゾーン）を考慮し、ゾーンに割り当てるためのヒントフィールドに値を入力します。 +*Topology Aware Hint*は、トラフィックを発信元のゾーン内に留めておくのに役立つメカニズムを提供します。このコンセプトは、一般に「Topology Aware Routing」と呼ばれています。EndpointSliceコントローラーは{{< glossary_tooltip term_id="Service" >}}のendpointを計算する際に、各endpointのトポロジー（地域とゾーン）を考慮し、ゾーンに割り当てるためのヒントフィールドに値を入力します。 EndpointSliceコントローラーは、各endpointのトポロジー（地域とゾーン）を考慮し、ゾーンに割り当てるためのヒントフィールドに入力します。 {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}のようなクラスターコンポーネントは、次にこれらのヒントを消費し、それらを使用してトラフィックがルーティングされる方法に影響を与えることが可能です(トポロジー的に近いendpointを優先します)。 ## Topology Aware Hintを使う -`service.kubernetes.io/topology-aware-hints`アノテーションを`auto`に設定すると、サービスに対してTopology Aware Hintを有効にすることができます。これは、EndpointSliceコントローラーが安全と判断した場合に、トポロジーヒントを設定するように指示します。 +`service.kubernetes.io/topology-aware-hints`アノテーションを`auto`に設定すると、サービスに対してTopology Aware Hintを有効にすることができます。これはEndpointSliceコントローラーが安全と判断した場合に、トポロジーヒントを設定するように指示します。 重要なのは、これはヒントが常に設定されることを保証するものではないことです。 ## 使い方 {#implementation} @@ -40,7 +40,7 @@ EndpointSliceコントローラーは、各endpointのトポロジー（地域 たとえば、あるゾーンに2つのCPUコアがあり、別のゾーンに1つのCPUコアしかない場合、コントローラーは2つのCPUコアを持つゾーンに2倍のendpointを割り当てます。 -次の例は、ヒントが入力されたときのEndpointSliceの外観を示しています。 +次の例は、ヒントが入力されたときのEndpointSliceの様子を示しています。 ```yaml apiVersion: discovery.k8s.io/v1 @@ -68,7 +68,7 @@ endpoints: ### kube-proxy {#implementation-kube-proxy} -kube-proxyは、EndpointSliceコントローラーによって設定されたヒントに基づいて、ルーティング先のendpointをフィルター処理します。ほとんどの場合、これは、kube-proxyが同じゾーン内のendpointにトラフィックをルーティングできることを意味します。コントローラーが別のゾーンからendpointを割り当てて、ゾーン間でendpointがより均等に分散されるようにする場合があります。これにより、一部のトラフィックが他のゾーンにルーティングされます。 +kube-proxyは、EndpointSliceコントローラーによって設定されたヒントに基づいて、ルーティング先のendpointをフィルター処理します。ほとんどの場合、これはkube-proxyが同じゾーン内のendpointにトラフィックをルーティングできることを意味します。コントローラーが別のゾーンからendpointを割り当てて、ゾーン間でendpointがより均等に分散されるようにする場合があります。これにより、一部のトラフィックが他のゾーンにルーティングされます。 ## セーフガード @@ -82,20 +82,20 @@ kube-proxyは、EndpointSliceコントローラーによって設定されたヒ 4. **1つ以上のendpointにゾーンヒントが存在しません:** これが発生すると、kube-proxyはTopology Aware Hintから、またはTopology Aware Hintへの移行が進行中であると見なします。この状態のサービスに対してendpointをフィルタリングすることは危険であるため、kube-proxyはすべてのendpointを使用するようにフォールバックします。 -5. **ゾーンはヒントで表されません:** kube-proxyが、実行中のゾーンをターゲットとするヒントを持つendpointを少なくとも1つ見つけることができない場合、すべてのゾーンのendpointを使用することになります。これは、既存のクラスターに新しいゾーンを追加するときに発生する可能性が最も高くなります。 +5. **ゾーンはヒントで表されません:** kube-proxyが、実行中のゾーンをターゲットとするヒントを持つendpointを少なくとも1つ見つけることができない場合、すべてのゾーンのendpointを使用することになります。これは既存のクラスターに新しいゾーンを追加するときに発生する可能性が最も高くなります。 -## Constraints +## 制約事項 * サービスで`externalTrafficPolicy`または`internalTrafficPolicy`が`Local`に設定されている場合、Topology Aware Hintは使用されません。同じServiceではなく、異なるServiceの同じクラスターで両方の機能を使用することができます。 -* このアプローチは、ゾーンのサブセットから発信されるトラフィックの割合が高いサービスではうまく機能しません。代わりに、これは、着信トラフィックが各ゾーンのノードの容量にほぼ比例することを前提としています。 +* このアプローチは、ゾーンのサブセットから発信されるトラフィックの割合が高いサービスではうまく機能しません。代わりに、これは着信トラフィックが各ゾーンのノードの容量にほぼ比例することを前提としています。 * EndpointSliceコントローラーは、各ゾーンの比率を計算するときに、準備ができていないノードを無視します。ノードの大部分の準備ができていない場合、これは意図しない結果をもたらす可能性があります。 * EndpointSliceコントローラーは、各ゾーンの比率を計算するデプロイ時に{{< glossary_tooltip text="tolerations" term_id="toleration" >}}を考慮しません。サービスをバックアップするPodがクラスター内のノードのサブセットに制限されている場合、これは考慮されません。 -* これは、オートスケーリングと相性が悪いかもしれません。例えば、多くのトラフィックが1つのゾーンから発信されている場合、そのゾーンに割り当てられたendpointのみがそのトラフィックを処理することになります。その結果、{{< glossary_tooltip +* これはオートスケーリングと相性が悪いかもしれません。例えば、多くのトラフィックが1つのゾーンから発信されている場合、そのゾーンに割り当てられたendpointのみがそのトラフィックを処理することになります。その結果、{{< glossary_tooltip text="Horizontal Pod Autoscaler" term_id="horizontal-pod-autoscaler" >}}がこのイベントを拾えなくなったり、新しく追加されたPodが別のゾーンで開始されたりする可能性があります。 ## {{% heading "whatsnext" %}} From 849a28d4aaf4bf2a31f256ac832b3689c4ff7a8b Mon Sep 17 00:00:00 2001 From: Kobayashi Daisuke Date: Tue, 1 Feb 2022 11:51:29 +0900 Subject: [PATCH 06/10] Update content/ja/docs/concepts/services-networking/topology-aware-hints.md Co-authored-by: nasa9084 --- .../docs/concepts/services-networking/topology-aware-hints.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/services-networking/topology-aware-hints.md b/content/ja/docs/concepts/services-networking/topology-aware-hints.md index cefba8b322..f6361fe447 100644 --- a/content/ja/docs/concepts/services-networking/topology-aware-hints.md +++ b/content/ja/docs/concepts/services-networking/topology-aware-hints.md @@ -82,7 +82,7 @@ kube-proxyは、EndpointSliceコントローラーによって設定されたヒ 4. **1つ以上のendpointにゾーンヒントが存在しません:** これが発生すると、kube-proxyはTopology Aware Hintから、またはTopology Aware Hintへの移行が進行中であると見なします。この状態のサービスに対してendpointをフィルタリングすることは危険であるため、kube-proxyはすべてのendpointを使用するようにフォールバックします。 -5. **ゾーンはヒントで表されません:** kube-proxyが、実行中のゾーンをターゲットとするヒントを持つendpointを少なくとも1つ見つけることができない場合、すべてのゾーンのendpointを使用することになります。これは既存のクラスターに新しいゾーンを追加するときに発生する可能性が最も高くなります。 +5. **ゾーンはヒントで表されません:** kube-proxyが、実行中のゾーンをターゲットとするヒントを持つendpointを1つも見つけることができない場合、すべてのゾーンのendpointを使用することになります。これは既存のクラスターに新しいゾーンを追加するときに発生する可能性が最も高くなります。 ## 制約事項 From 01abcb22e055ea2e0a4d1b181b6fad4bb0e3e33c Mon Sep 17 00:00:00 2001 From: Kobayashi Daisuke Date: Tue, 1 Feb 2022 11:55:19 +0900 Subject: [PATCH 07/10] fix some points commented --- .../services-networking/topology-aware-hints.md | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/topology-aware-hints.md b/content/ja/docs/concepts/services-networking/topology-aware-hints.md index f6361fe447..c0131d42cd 100644 --- a/content/ja/docs/concepts/services-networking/topology-aware-hints.md +++ b/content/ja/docs/concepts/services-networking/topology-aware-hints.md @@ -11,15 +11,15 @@ weight: 45 *Topology Aware Hint*は、クライアントがendpointをどのように使用するかについての提案を含めることにより、トポロジーを考慮したルーティングを可能にします。このアプローチでは、EndpointSliceおよび/またはEndpointオブジェクトの消費者が、これらのネットワークエンドポイントへのトラフィックを、それが発生した場所の近くにルーティングできるように、メタデータを追加します。 -たとえば、ローカリティ内でトラフィックをルーティングすることで、コストを削減したり、ネットワークパフォーマンスを向上させたりできます。 +たとえば、局所的にトラフィックをルーティングすることで、コストを削減したり、ネットワークパフォーマンスを向上させたりできます。 ## 動機 Kubernetesクラスターは、マルチゾーン環境で展開されることが多くなっています。 -*Topology Aware Hint*は、トラフィックを発信元のゾーン内に留めておくのに役立つメカニズムを提供します。このコンセプトは、一般に「Topology Aware Routing」と呼ばれています。EndpointSliceコントローラーは{{< glossary_tooltip term_id="Service" >}}のendpointを計算する際に、各endpointのトポロジー（地域とゾーン）を考慮し、ゾーンに割り当てるためのヒントフィールドに値を入力します。 -EndpointSliceコントローラーは、各endpointのトポロジー（地域とゾーン）を考慮し、ゾーンに割り当てるためのヒントフィールドに入力します。 +*Topology Aware Hint*は、トラフィックを発信元のゾーン内に留めておくのに役立つメカニズムを提供します。このコンセプトは、一般に「Topology Aware Routing」と呼ばれています。EndpointSliceコントローラーは{{< glossary_tooltip term_id="Service" >}}のendpointを計算する際に、各endpointのトポロジー(地域とゾーン)を考慮し、ゾーンに割り当てるためのヒントフィールドに値を入力します。 +EndpointSliceコントローラーは、各endpointのトポロジー(地域とゾーン)を考慮し、ゾーンに割り当てるためのヒントフィールドに入力します。 {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}のようなクラスターコンポーネントは、次にこれらのヒントを消費し、それらを使用してトラフィックがルーティングされる方法に影響を与えることが可能です(トポロジー的に近いendpointを優先します)。 @@ -86,17 +86,15 @@ kube-proxyは、EndpointSliceコントローラーによって設定されたヒ ## 制約事項 -* サービスで`externalTrafficPolicy`または`internalTrafficPolicy`が`Local`に設定されている場合、Topology Aware Hintは使用されません。同じServiceではなく、異なるServiceの同じクラスターで両方の機能を使用することができます。 +* Serviceで`externalTrafficPolicy`または`internalTrafficPolicy`が`Local`に設定されている場合、Topology Aware Hintは使用されません。同じServiceではなく、異なるServiceの同じクラスターで両方の機能を使用することができます。 * このアプローチは、ゾーンのサブセットから発信されるトラフィックの割合が高いサービスではうまく機能しません。代わりに、これは着信トラフィックが各ゾーンのノードの容量にほぼ比例することを前提としています。 * EndpointSliceコントローラーは、各ゾーンの比率を計算するときに、準備ができていないノードを無視します。ノードの大部分の準備ができていない場合、これは意図しない結果をもたらす可能性があります。 -* EndpointSliceコントローラーは、各ゾーンの比率を計算するデプロイ時に{{< glossary_tooltip - text="tolerations" term_id="toleration" >}}を考慮しません。サービスをバックアップするPodがクラスター内のノードのサブセットに制限されている場合、これは考慮されません。 +* EndpointSliceコントローラーは、各ゾーンの比率を計算するデプロイ時に{{< glossary_tooltip text="tolerations" term_id="toleration" >}}を考慮しません。サービスをバックアップするPodがクラスター内のノードのサブセットに制限されている場合、これは考慮されません。 -* これはオートスケーリングと相性が悪いかもしれません。例えば、多くのトラフィックが1つのゾーンから発信されている場合、そのゾーンに割り当てられたendpointのみがそのトラフィックを処理することになります。その結果、{{< glossary_tooltip - text="Horizontal Pod Autoscaler" term_id="horizontal-pod-autoscaler" >}}がこのイベントを拾えなくなったり、新しく追加されたPodが別のゾーンで開始されたりする可能性があります。 +* これはオートスケーリングと相性が悪いかもしれません。例えば、多くのトラフィックが1つのゾーンから発信されている場合、そのゾーンに割り当てられたendpointのみがそのトラフィックを処理することになります。その結果、{{< glossary_tooltip text="Horizontal Pod Autoscaler" term_id="horizontal-pod-autoscaler" >}}がこのイベントを拾えなくなったり、新しく追加されたPodが別のゾーンで開始されたりする可能性があります。 ## {{% heading "whatsnext" %}} From 9e65cf1ba862d85db78ed76d9ac1d653447bcfa4 Mon Sep 17 00:00:00 2001 From: Kobayashi Daisuke Date: Tue, 1 Feb 2022 12:06:30 +0900 Subject: [PATCH 08/10] update --- .../docs/concepts/services-networking/topology-aware-hints.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/services-networking/topology-aware-hints.md b/content/ja/docs/concepts/services-networking/topology-aware-hints.md index c0131d42cd..b119dad348 100644 --- a/content/ja/docs/concepts/services-networking/topology-aware-hints.md +++ b/content/ja/docs/concepts/services-networking/topology-aware-hints.md @@ -92,7 +92,7 @@ kube-proxyは、EndpointSliceコントローラーによって設定されたヒ * EndpointSliceコントローラーは、各ゾーンの比率を計算するときに、準備ができていないノードを無視します。ノードの大部分の準備ができていない場合、これは意図しない結果をもたらす可能性があります。 -* EndpointSliceコントローラーは、各ゾーンの比率を計算するデプロイ時に{{< glossary_tooltip text="tolerations" term_id="toleration" >}}を考慮しません。サービスをバックアップするPodがクラスター内のノードのサブセットに制限されている場合、これは考慮されません。 +* EndpointSliceコントローラーは、各ゾーンの比率を計算するデプロイ時に{{< glossary_tooltip text="toleration" term_id="toleration" >}}を考慮しません。サービスをバックアップするPodがクラスター内のノードのサブセットに制限されている場合、これは考慮されません。 * これはオートスケーリングと相性が悪いかもしれません。例えば、多くのトラフィックが1つのゾーンから発信されている場合、そのゾーンに割り当てられたendpointのみがそのトラフィックを処理することになります。その結果、{{< glossary_tooltip text="Horizontal Pod Autoscaler" term_id="horizontal-pod-autoscaler" >}}がこのイベントを拾えなくなったり、新しく追加されたPodが別のゾーンで開始されたりする可能性があります。 From a86a5c6511e30bc25d0c8db5aa08209a9131c155 Mon Sep 17 00:00:00 2001 From: Kobayashi Daisuke Date: Fri, 1 Apr 2022 14:36:48 +0900 Subject: [PATCH 09/10] Update content/ja/docs/concepts/services-networking/topology-aware-hints.md Co-authored-by: nasa9084 --- .../docs/concepts/services-networking/topology-aware-hints.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/services-networking/topology-aware-hints.md b/content/ja/docs/concepts/services-networking/topology-aware-hints.md index b119dad348..ca41ef1367 100644 --- a/content/ja/docs/concepts/services-networking/topology-aware-hints.md +++ b/content/ja/docs/concepts/services-networking/topology-aware-hints.md @@ -18,7 +18,7 @@ weight: 45 ## 動機 Kubernetesクラスターは、マルチゾーン環境で展開されることが多くなっています。 -*Topology Aware Hint*は、トラフィックを発信元のゾーン内に留めておくのに役立つメカニズムを提供します。このコンセプトは、一般に「Topology Aware Routing」と呼ばれています。EndpointSliceコントローラーは{{< glossary_tooltip term_id="Service" >}}のendpointを計算する際に、各endpointのトポロジー(地域とゾーン)を考慮し、ゾーンに割り当てるためのヒントフィールドに値を入力します。 +*Topology Aware Hint*は、トラフィックを発信元のゾーン内に留めておくのに役立つメカニズムを提供します。このコンセプトは、一般に「Topology Aware Routing」と呼ばれています。EndpointSliceコントローラーは{{< glossary_tooltip term_id="Service" >}}のendpointを計算する際に、各endpointのトポロジー(リージョンとゾーン)を考慮し、ゾーンに割り当てるためのヒントフィールドに値を入力します。 EndpointSliceコントローラーは、各endpointのトポロジー(地域とゾーン)を考慮し、ゾーンに割り当てるためのヒントフィールドに入力します。 {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}のようなクラスターコンポーネントは、次にこれらのヒントを消費し、それらを使用してトラフィックがルーティングされる方法に影響を与えることが可能です(トポロジー的に近いendpointを優先します)。 From 020a6aa13ae2c20088a15ae6e66c7b6d0f717834 Mon Sep 17 00:00:00 2001 From: Kobayashi Daisuke Date: Fri, 1 Apr 2022 14:36:55 +0900 Subject: [PATCH 10/10] Update content/ja/docs/concepts/services-networking/topology-aware-hints.md Co-authored-by: nasa9084 --- .../docs/concepts/services-networking/topology-aware-hints.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/services-networking/topology-aware-hints.md b/content/ja/docs/concepts/services-networking/topology-aware-hints.md index ca41ef1367..ed26561f40 100644 --- a/content/ja/docs/concepts/services-networking/topology-aware-hints.md +++ b/content/ja/docs/concepts/services-networking/topology-aware-hints.md @@ -19,7 +19,7 @@ weight: 45 Kubernetesクラスターは、マルチゾーン環境で展開されることが多くなっています。 *Topology Aware Hint*は、トラフィックを発信元のゾーン内に留めておくのに役立つメカニズムを提供します。このコンセプトは、一般に「Topology Aware Routing」と呼ばれています。EndpointSliceコントローラーは{{< glossary_tooltip term_id="Service" >}}のendpointを計算する際に、各endpointのトポロジー(リージョンとゾーン)を考慮し、ゾーンに割り当てるためのヒントフィールドに値を入力します。 -EndpointSliceコントローラーは、各endpointのトポロジー(地域とゾーン)を考慮し、ゾーンに割り当てるためのヒントフィールドに入力します。 +EndpointSliceコントローラーは、各endpointのトポロジー(リージョンとゾーン)を考慮し、ゾーンに割り当てるためのヒントフィールドに入力します。 {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}のようなクラスターコンポーネントは、次にこれらのヒントを消費し、それらを使用してトラフィックがルーティングされる方法に影響を与えることが可能です(トポロジー的に近いendpointを優先します)。