From 85fb3900dca70e19ad7b1f6a140835c2d45f818d Mon Sep 17 00:00:00 2001 From: Keita Akutsu Date: Tue, 26 Nov 2019 00:24:50 +0900 Subject: [PATCH 1/3] ja-trans: Translate concepts/scheduling/scheduler-perf-tuning/ into Japanese (#17119) --- .../scheduling/scheduler-perf-tuning.md | 74 +++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 content/ja/docs/concepts/scheduling/scheduler-perf-tuning.md diff --git a/content/ja/docs/concepts/scheduling/scheduler-perf-tuning.md b/content/ja/docs/concepts/scheduling/scheduler-perf-tuning.md new file mode 100644 index 0000000000000..3925fee5bd061 --- /dev/null +++ b/content/ja/docs/concepts/scheduling/scheduler-perf-tuning.md @@ -0,0 +1,74 @@ +--- +title: スケジューラーのパフォーマンスチューニング +content_template: templates/concept +weight: 70 +--- + +{{% capture overview %}} + +{{< feature-state for_k8s_version="1.14" state="beta" >}} + +[kube-scheduler](/docs/concepts/scheduling/kube-scheduler/#kube-scheduler)はKubernetesのデフォルトのスケジューラーです。クラスター内のNode上にPodを割り当てる責務があります。 + +クラスター内に存在するNodeで、Podのスケジューリング要求を満たすものはPodに対して_割り当て可能_ なNodeと呼ばれます。スケジューラーはPodに対する割り当て可能なNodeをみつけ、それらの割り当て可能なNodeにスコアをつけます。その中から最も高いスコアのNodeを選択し、Podに割り当てるためのいくつかの関数を実行します。スケジューラーは_Binding_ と呼ばれる処理中において、APIサーバーに対して割り当てが決まったNodeの情報を通知します。 + +このページでは、大規模のKubernetesクラスターにおけるパフォーマンス最適化のためのチューニングについて説明します。 + +{{% /capture %}} + +{{% capture body %}} + +## スコア付けするNodeの割合 + +Kubernetes 1.12以前では、Kube-schedulerがクラスター内の全てのNodeに対して割り当て可能かをチェックし、実際に割り当て可能なNodeのスコア付けをしていました。Kubernetes 1.12では新機能を追加し、ある数の割り当て可能なNodeが見つかった時点で、割り当て可能なNodeの探索を止めれるようになりました。これにより大規模なクラスターにおけるスケジューラーのパフォーマンスが向上しました。その数はクラスターのサイズの割合(%)として指定されます。この割合は`percentageOfNodesToScore`というオプションの設定項目によって指定可能です。この値の範囲は1から100までです。100より大きい値は100%として扱われます。0を指定したときは、この設定オプションを指定しないものとして扱われます。Kubernetes 1.14では、この値が指定されていないときは、スコア付けするNodeの割合をクラスターのサイズに基づいて決定するための機構があります。この機構では100Nodeのクラスターに対しては50%の割合とするような線形な式を使用します。5000Nodeのクラスターに対しては10%となります。自動で算出される割合の最低値は5%となります。言い換えると、クラスターの規模がどれだけ大きくても、ユーザーがこの値を5未満に設定しない限りスケジューラーは少なくても5%のクラスター内のNodeをスコア付けすることになります。 + +`percentageOfNodesToScore`の値を50%に設定する例は下記のとおりです。 + +```yaml +apiVersion: kubescheduler.config.k8s.io/v1alpha1 +kind: KubeSchedulerConfiguration +algorithmSource: + provider: DefaultProvider + +... + +percentageOfNodesToScore: 50 +``` + +{{< note >}} +割り当て可能なNodeが50未満のクラスターにおいては、割り当て可能なNodeの探索を止めるほどNodeが多くないため、スケジューラーは全てのNodeをチェックします。 +{{< /note >}} + +**この機能を無効にするためには**、`percentageOfNodesToScore`を100に設定してください。 + + +### percentageOfNodesToScoreのチューニング + +`percentageOfNodesToScore`は1から100の間の範囲である必要があり、デフォルト値はクラスターのサイズに基づいて計算されます。また、クラスターのサイズの最小値は50Nodeとハードコードされています。これは数百のNodeを持つようなクラスターにおいて、この値を50より低い値に変更してもスケジューラーが検出する割り当て可能なNodeの数に大きな影響を与えないことを意味します。このオプションは意図的なものです。その理由としては小規模のクラスターにおいて、パフォーマンスを著しく改善する可能性が低いためです。1000Nodeを超える大規模なクラスターでこの値を低く設定すると、パフォーマンスが著しく改善される可能性があります。 + +この値を設定する際に考慮するべき重要な注意事項として、割り当て可能Nodeのチェック対象のNodeが少ないと、一部のNodeはPodの割り当てのためにスコアリングされなくなります。結果として、高いスコアをつけられる可能性のあるNodeがスコアリングフェーズに渡されることがありません。これにより、Podの配置が理想的なものでなくなります。したがって、この値をかなり低い割合に設定すべきではありません。一般的な経験則として、この値を10未満に設定しないことです。スケジューラーのスループットがアプリケーションにとって致命的で、Nodeのスコアリングが重要でないときのみ、この値を低く設定するべきです。言いかえると、割り当て可能な限り、Podは任意のNode上で稼働させるのが好ましいです。 + +クラスターが数百のNodeを持つ場合やそれに満たない場合でも、この設定オプションのデフォルト値を低くするのを推奨しません。デフォルト値を低くしてもスケジューラーのパフォーマンスを大幅に改善することはありません。 + +### スケジューラーはどのようにNodeを探索するか + +このセクションでは、この機能の内部の詳細を理解したい人向けになります。 + +クラスター内の全てのNodeに対して平等にPodの割り当ての可能性を持たせるため、スケジューラーはラウンドロビン方式でNodeを探索します。複数のNodeの配列になっているイメージです。スケジューラーはその配列の先頭から探索を開始し、`percentageOfNodesToScore`によって指定された数のNodeを検出するまで、割り当て可能かどうかをチェックしていきます。次のPodでは、スケジューラーは前のPodの割り当て処理でチェックしたところから探索を再開します。 + +Nodeが複数のゾーンに存在するとき、スケジューラーは様々なゾーンのNodeを探索して、異なるゾーンのNodeが割り当て可能かどうかのチェック対象になるようにします。例えば2つのゾーンに6つのNodeがある場合を考えます。 + +``` +Zone 1: Node 1, Node 2, Node 3, Node 4 +Zone 2: Node 5, Node 6 +``` + +スケジューラーは、下記の順番でNodeの割り当て可能性を評価します。 + +``` +Node 1, Node 5, Node 2, Node 6, Node 3, Node 4 +``` + +全てのNodeのチェックを終えたら、1番目のNodeに戻ってチェックをします。 + +{{% /capture %}} From 87d6b4a925023c7297565e980f3cfc3bc9a6b6e2 Mon Sep 17 00:00:00 2001 From: Keita Akutsu Date: Fri, 20 Dec 2019 02:10:36 +0900 Subject: [PATCH 2/3] ja-trans: Improve Japanese translation in concepts/scheduling/scheduler-perf-tuning/ (#17119) --- content/ja/docs/concepts/scheduling/scheduler-perf-tuning.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/scheduling/scheduler-perf-tuning.md b/content/ja/docs/concepts/scheduling/scheduler-perf-tuning.md index 3925fee5bd061..e0252a224a7cf 100644 --- a/content/ja/docs/concepts/scheduling/scheduler-perf-tuning.md +++ b/content/ja/docs/concepts/scheduling/scheduler-perf-tuning.md @@ -44,11 +44,11 @@ percentageOfNodesToScore: 50 ### percentageOfNodesToScoreのチューニング -`percentageOfNodesToScore`は1から100の間の範囲である必要があり、デフォルト値はクラスターのサイズに基づいて計算されます。また、クラスターのサイズの最小値は50Nodeとハードコードされています。これは数百のNodeを持つようなクラスターにおいて、この値を50より低い値に変更してもスケジューラーが検出する割り当て可能なNodeの数に大きな影響を与えないことを意味します。このオプションは意図的なものです。その理由としては小規模のクラスターにおいて、パフォーマンスを著しく改善する可能性が低いためです。1000Nodeを超える大規模なクラスターでこの値を低く設定すると、パフォーマンスが著しく改善される可能性があります。 +`percentageOfNodesToScore`は1から100の間の範囲である必要があり、デフォルト値はクラスターのサイズに基づいて計算されます。また、クラスターのサイズの最小値は50ノードとハードコードされています。これは数百のノードを持つようなクラスターにおいてこの値を50より低い値に変更しても、スケジューラーが検出する割り当て可能なノードの数に大きな影響を与えないことを意味します。このオプションは意図的なものです。その理由としては、小規模のクラスターにおいてパフォーマンスを著しく改善する可能性が低いためです。1000ノードを超える大規模なクラスターでこの値を低く設定すると、パフォーマンスが著しく改善される可能性があります。 この値を設定する際に考慮するべき重要な注意事項として、割り当て可能Nodeのチェック対象のNodeが少ないと、一部のNodeはPodの割り当てのためにスコアリングされなくなります。結果として、高いスコアをつけられる可能性のあるNodeがスコアリングフェーズに渡されることがありません。これにより、Podの配置が理想的なものでなくなります。したがって、この値をかなり低い割合に設定すべきではありません。一般的な経験則として、この値を10未満に設定しないことです。スケジューラーのスループットがアプリケーションにとって致命的で、Nodeのスコアリングが重要でないときのみ、この値を低く設定するべきです。言いかえると、割り当て可能な限り、Podは任意のNode上で稼働させるのが好ましいです。 -クラスターが数百のNodeを持つ場合やそれに満たない場合でも、この設定オプションのデフォルト値を低くするのを推奨しません。デフォルト値を低くしてもスケジューラーのパフォーマンスを大幅に改善することはありません。 +クラスターが数百のノードを持つ場合やそれに満たない場合でも、この設定オプションのデフォルト値を低くするのを推奨しません。デフォルト値を低くしてもスケジューラーのパフォーマンスを大幅に改善することはありません。 ### スケジューラーはどのようにNodeを探索するか From 14be309770d0d594ba52575f4e8e20526437f815 Mon Sep 17 00:00:00 2001 From: Keita Akutsu Date: Sat, 21 Dec 2019 05:32:24 +0900 Subject: [PATCH 3/3] ja-trans: Improve Japanese translation in concepts/scheduling/scheduler-perf-tuning/ (#17119) --- .../scheduling/scheduler-perf-tuning.md | 22 +++++++++---------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/content/ja/docs/concepts/scheduling/scheduler-perf-tuning.md b/content/ja/docs/concepts/scheduling/scheduler-perf-tuning.md index e0252a224a7cf..8843138e73243 100644 --- a/content/ja/docs/concepts/scheduling/scheduler-perf-tuning.md +++ b/content/ja/docs/concepts/scheduling/scheduler-perf-tuning.md @@ -8,9 +8,9 @@ weight: 70 {{< feature-state for_k8s_version="1.14" state="beta" >}} -[kube-scheduler](/docs/concepts/scheduling/kube-scheduler/#kube-scheduler)はKubernetesのデフォルトのスケジューラーです。クラスター内のNode上にPodを割り当てる責務があります。 +[kube-scheduler](/docs/concepts/scheduling/kube-scheduler/#kube-scheduler)はKubernetesのデフォルトのスケジューラーです。クラスター内のノード上にPodを割り当てる責務があります。 -クラスター内に存在するNodeで、Podのスケジューリング要求を満たすものはPodに対して_割り当て可能_ なNodeと呼ばれます。スケジューラーはPodに対する割り当て可能なNodeをみつけ、それらの割り当て可能なNodeにスコアをつけます。その中から最も高いスコアのNodeを選択し、Podに割り当てるためのいくつかの関数を実行します。スケジューラーは_Binding_ と呼ばれる処理中において、APIサーバーに対して割り当てが決まったNodeの情報を通知します。 +クラスター内に存在するノードで、Podのスケジューリング要求を満たすものはPodに対して_割り当て可能_ なノードと呼ばれます。スケジューラーはPodに対する割り当て可能なノードをみつけ、それらの割り当て可能なノードにスコアをつけます。その中から最も高いスコアのノードを選択し、Podに割り当てるためのいくつかの関数を実行します。スケジューラーは_Binding_ と呼ばれる処理中において、APIサーバーに対して割り当てが決まったノードの情報を通知します。 このページでは、大規模のKubernetesクラスターにおけるパフォーマンス最適化のためのチューニングについて説明します。 @@ -18,9 +18,9 @@ weight: 70 {{% capture body %}} -## スコア付けするNodeの割合 +## スコア付けするノードの割合 -Kubernetes 1.12以前では、Kube-schedulerがクラスター内の全てのNodeに対して割り当て可能かをチェックし、実際に割り当て可能なNodeのスコア付けをしていました。Kubernetes 1.12では新機能を追加し、ある数の割り当て可能なNodeが見つかった時点で、割り当て可能なNodeの探索を止めれるようになりました。これにより大規模なクラスターにおけるスケジューラーのパフォーマンスが向上しました。その数はクラスターのサイズの割合(%)として指定されます。この割合は`percentageOfNodesToScore`というオプションの設定項目によって指定可能です。この値の範囲は1から100までです。100より大きい値は100%として扱われます。0を指定したときは、この設定オプションを指定しないものとして扱われます。Kubernetes 1.14では、この値が指定されていないときは、スコア付けするNodeの割合をクラスターのサイズに基づいて決定するための機構があります。この機構では100Nodeのクラスターに対しては50%の割合とするような線形な式を使用します。5000Nodeのクラスターに対しては10%となります。自動で算出される割合の最低値は5%となります。言い換えると、クラスターの規模がどれだけ大きくても、ユーザーがこの値を5未満に設定しない限りスケジューラーは少なくても5%のクラスター内のNodeをスコア付けすることになります。 +Kubernetes 1.12以前では、Kube-schedulerがクラスター内の全てのノードに対して割り当て可能かをチェックし、実際に割り当て可能なノードのスコア付けをしていました。Kubernetes 1.12では新機能を追加し、ある数の割り当て可能なノードが見つかった時点で、割り当て可能なノードの探索を止めれるようになりました。これにより大規模なクラスターにおけるスケジューラーのパフォーマンスが向上しました。その数はクラスターのサイズの割合(%)として指定されます。この割合は`percentageOfNodesToScore`というオプションの設定項目によって指定可能です。この値の範囲は1から100までです。100より大きい値は100%として扱われます。0を指定したときは、この設定オプションを指定しないものとして扱われます。Kubernetes 1.14では、この値が指定されていないときは、スコア付けするノードの割合をクラスターのサイズに基づいて決定するための機構があります。この機構では100ノードのクラスターに対しては50%の割合とするような線形な式を使用します。5000ノードのクラスターに対しては10%となります。自動で算出される割合の最低値は5%となります。言い換えると、クラスターの規模がどれだけ大きくても、ユーザーがこの値を5未満に設定しない限りスケジューラーは少なくても5%のクラスター内のノードをスコア付けすることになります。 `percentageOfNodesToScore`の値を50%に設定する例は下記のとおりです。 @@ -36,7 +36,7 @@ percentageOfNodesToScore: 50 ``` {{< note >}} -割り当て可能なNodeが50未満のクラスターにおいては、割り当て可能なNodeの探索を止めるほどNodeが多くないため、スケジューラーは全てのNodeをチェックします。 +割り当て可能なノードが50未満のクラスターにおいては、割り当て可能なノードの探索を止めるほどノードが多くないため、スケジューラーは全てのノードをチェックします。 {{< /note >}} **この機能を無効にするためには**、`percentageOfNodesToScore`を100に設定してください。 @@ -46,29 +46,29 @@ percentageOfNodesToScore: 50 `percentageOfNodesToScore`は1から100の間の範囲である必要があり、デフォルト値はクラスターのサイズに基づいて計算されます。また、クラスターのサイズの最小値は50ノードとハードコードされています。これは数百のノードを持つようなクラスターにおいてこの値を50より低い値に変更しても、スケジューラーが検出する割り当て可能なノードの数に大きな影響を与えないことを意味します。このオプションは意図的なものです。その理由としては、小規模のクラスターにおいてパフォーマンスを著しく改善する可能性が低いためです。1000ノードを超える大規模なクラスターでこの値を低く設定すると、パフォーマンスが著しく改善される可能性があります。 -この値を設定する際に考慮するべき重要な注意事項として、割り当て可能Nodeのチェック対象のNodeが少ないと、一部のNodeはPodの割り当てのためにスコアリングされなくなります。結果として、高いスコアをつけられる可能性のあるNodeがスコアリングフェーズに渡されることがありません。これにより、Podの配置が理想的なものでなくなります。したがって、この値をかなり低い割合に設定すべきではありません。一般的な経験則として、この値を10未満に設定しないことです。スケジューラーのスループットがアプリケーションにとって致命的で、Nodeのスコアリングが重要でないときのみ、この値を低く設定するべきです。言いかえると、割り当て可能な限り、Podは任意のNode上で稼働させるのが好ましいです。 +この値を設定する際に考慮するべき重要な注意事項として、割り当て可能ノードのチェック対象のノードが少ないと、一部のノードはPodの割り当てのためにスコアリングされなくなります。結果として、高いスコアをつけられる可能性のあるノードがスコアリングフェーズに渡されることがありません。これにより、Podの配置が理想的なものでなくなります。したがって、この値をかなり低い割合に設定すべきではありません。一般的な経験則として、この値を10未満に設定しないことです。スケジューラーのスループットがアプリケーションにとって致命的で、ノードのスコアリングが重要でないときのみ、この値を低く設定するべきです。言いかえると、割り当て可能な限り、Podは任意のノード上で稼働させるのが好ましいです。 クラスターが数百のノードを持つ場合やそれに満たない場合でも、この設定オプションのデフォルト値を低くするのを推奨しません。デフォルト値を低くしてもスケジューラーのパフォーマンスを大幅に改善することはありません。 -### スケジューラーはどのようにNodeを探索するか +### スケジューラーはどのようにノードを探索するか このセクションでは、この機能の内部の詳細を理解したい人向けになります。 -クラスター内の全てのNodeに対して平等にPodの割り当ての可能性を持たせるため、スケジューラーはラウンドロビン方式でNodeを探索します。複数のNodeの配列になっているイメージです。スケジューラーはその配列の先頭から探索を開始し、`percentageOfNodesToScore`によって指定された数のNodeを検出するまで、割り当て可能かどうかをチェックしていきます。次のPodでは、スケジューラーは前のPodの割り当て処理でチェックしたところから探索を再開します。 +クラスター内の全てのノードに対して平等にPodの割り当ての可能性を持たせるため、スケジューラーはラウンドロビン方式でノードを探索します。複数のノードの配列になっているイメージです。スケジューラーはその配列の先頭から探索を開始し、`percentageOfNodesToScore`によって指定された数のノードを検出するまで、割り当て可能かどうかをチェックしていきます。次のPodでは、スケジューラーは前のPodの割り当て処理でチェックしたところから探索を再開します。 -Nodeが複数のゾーンに存在するとき、スケジューラーは様々なゾーンのNodeを探索して、異なるゾーンのNodeが割り当て可能かどうかのチェック対象になるようにします。例えば2つのゾーンに6つのNodeがある場合を考えます。 +ノードが複数のゾーンに存在するとき、スケジューラーは様々なゾーンのノードを探索して、異なるゾーンのノードが割り当て可能かどうかのチェック対象になるようにします。例えば2つのゾーンに6つのノードがある場合を考えます。 ``` Zone 1: Node 1, Node 2, Node 3, Node 4 Zone 2: Node 5, Node 6 ``` -スケジューラーは、下記の順番でNodeの割り当て可能性を評価します。 +スケジューラーは、下記の順番でノードの割り当て可能性を評価します。 ``` Node 1, Node 5, Node 2, Node 6, Node 3, Node 4 ``` -全てのNodeのチェックを終えたら、1番目のNodeに戻ってチェックをします。 +全てのノードのチェックを終えたら、1番目のノードに戻ってチェックをします。 {{% /capture %}}