Skip to content

Commit 7bd2037

Browse files
Okabe-JunyaOkabe-Junya
committed
chore(ja): unify scheduler katakana notation
1 parent 73f7fa8 commit 7bd2037

6 files changed

Lines changed: 11 additions & 11 deletions

File tree

‎content/ja/docs/concepts/configuration/manage-resources-containers.md‎

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -13,7 +13,7 @@ feature:
1313
{{< glossary_tooltip term_id="pod" >}}を指定する際に、{{< glossary_tooltip text="コンテナ" term_id="container" >}}が必要とする各リソースの量をオプションで指定することができます。
1414
指定する最も一般的なリソースはCPUとメモリ(RAM)ですが、他にもあります。
1515

16-
Pod内のコンテナのリソース*requests*を指定すると、スケジューラはこの情報を使用して、どのNodeにPodを配置するかを決定します。コンテナにリソースの*limits*を指定すると、kubeletはその制限を適用し、実行中のコンテナが設定した制限を超えてリソースを使用することができないようにします。また、kubeletは、少なくともそのシステムリソースのうち、*requests* の量を、そのコンテナが使用するために特別に確保します。
16+
Pod内のコンテナのリソース*requests*を指定すると、スケジューラーはこの情報を使用して、どのNodeにPodを配置するかを決定します。コンテナにリソースの*limits*を指定すると、kubeletはその制限を適用し、実行中のコンテナが設定した制限を超えてリソースを使用することができないようにします。また、kubeletは、少なくともそのシステムリソースのうち、*requests* の量を、そのコンテナが使用するために特別に確保します。
1717

1818
<!-- body -->
1919

@@ -396,7 +396,7 @@ Nodeレベルの拡張リソースはNodeに関連付けられています。
396396
新しいNodeレベルの拡張リソースをアドバタイズするには、クラスターオペレーターはAPIサーバに`PATCH`HTTPリクエストを送信し、クラスター内のNodeの`status.capacity`に利用可能な量を指定します。
397397
この操作の後、ノードの`status.capacity`には新しいリソースが含まれます。
398398
`status.allocatable`フィールドは、kubeletによって非同期的に新しいリソースで自動的に更新されます。
399-
スケジューラはPodの適合性を評価する際にNodeの`status.allocatable`値を使用するため、Nodeの容量に新しいリソースを追加してから、そのNodeでリソースのスケジューリングを要求する最初のPodが現れるまでには、短い遅延が生じる可能性があることに注意してください。
399+
スケジューラーはPodの適合性を評価する際にNodeの`status.allocatable`値を使用するため、Nodeの容量に新しいリソースを追加してから、そのNodeでリソースのスケジューリングを要求する最初のPodが現れるまでには、短い遅延が生じる可能性があることに注意してください。
400400

401401
**例:**
402402

@@ -427,7 +427,7 @@ JSON-Patchの操作パス値は、JSON-Pointerとして解釈されます。
427427
次のスケジューラーポリシーの構成は、クラスターレベルの拡張リソース"example.com/foo"がスケジューラー拡張機能によって処理されることを示しています。
428428

429429
- スケジューラーは、Podが"example.com/foo"を要求した場合にのみ、Podをスケジューラー拡張機能に送信します。
430-
- `ignoredByScheduler`フィールドは、スケジューラがその`PodFitsResources`述語で"example.com/foo"リソースをチェックしないことを指定します。
430+
- `ignoredByScheduler`フィールドは、スケジューラーがその`PodFitsResources`述語で"example.com/foo"リソースをチェックしないことを指定します。
431431

432432
```json
433433
{

‎content/ja/docs/concepts/extend-kubernetes/_index.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -149,7 +149,7 @@ Kubernetesはいくつかのビルトイン認証方式と、それらが要件
149149

150150
これはかなりの大きな作業で、ほとんど全てのKubernetesユーザーはスケジューラーを変更する必要はありません。
151151

152-
スケジューラは[Webhook](https://github.com/kubernetes/community/blob/main/contributors/design-proposals/scheduling/scheduler_extender.md)もサポートしており、Webhookバックエンド(スケジューラー拡張)を通じてPodを配置するために選択されたノードをフィルタリング、優先度付けすることが可能です。
152+
スケジューラーは[Webhook](https://github.com/kubernetes/community/blob/main/contributors/design-proposals/scheduling/scheduler_extender.md)もサポートしており、Webhookバックエンド(スケジューラー拡張)を通じてPodを配置するために選択されたノードをフィルタリング、優先度付けすることが可能です。
153153

154154

155155

‎content/ja/docs/concepts/extend-kubernetes/extend-cluster.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -150,7 +150,7 @@ Kubernetesはいくつかのビルトイン認証方式と、それらが要件
150150

151151
これはかなりの大きな作業で、ほとんど全てのKubernetesユーザーはスケジューラーを変更する必要はありません。
152152

153-
スケジューラは[Webhook](https://github.com/kubernetes/community/blob/main/contributors/design-proposals/scheduling/scheduler_extender.md)もサポートしており、Webhookバックエンド(スケジューラーエクステンション)を通じてPodを配置するために選択されたノードをフィルタリング、優先度付けすることが可能です。
153+
スケジューラーは[Webhook](https://github.com/kubernetes/community/blob/main/contributors/design-proposals/scheduling/scheduler_extender.md)もサポートしており、Webhookバックエンド(スケジューラーエクステンション)を通じてPodを配置するために選択されたノードをフィルタリング、優先度付けすることが可能です。
154154

155155

156156

‎content/ja/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md‎

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -83,20 +83,20 @@ percentageOfNodesToScore: 50
8383
また、クラスターのサイズの最小値は100ノードとハードコードされています。
8484

8585
{{< note >}}
86-
割り当て可能なノードが100以下のクラスターでは、スケジューラの検索を早期に停止するのに十分な割り当て可能なノードがないため、スケジューラはすべてのノードをチェックします。
86+
割り当て可能なノードが100以下のクラスターでは、スケジューラーの検索を早期に停止するのに十分な割り当て可能なノードがないため、スケジューラーはすべてのノードをチェックします。
8787

8888
小規模クラスターでは、`percentageOfNodesToScore`に低い値を設定したとしても、同様の理由で変更による影響は全くないか、ほとんどありません。
8989

9090
クラスターのノード数が数百以下の場合は、この設定オプションをデフォルト値のままにします。
91-
変更してもスケジューラの性能を大幅に改善する可能性はほとんどありません。
91+
変更してもスケジューラーの性能を大幅に改善する可能性はほとんどありません。
9292
{{< /note >}}
9393

9494
この値を設定する際に考慮するべき重要な注意事項として、割り当て可能ノードのチェック対象のノードが少ないと、一部のノードはPodの割り当てのためにスコアリングされなくなります。
9595
結果として、高いスコアをつけられる可能性のあるノードがスコアリングフェーズに渡されることがありません。
9696
これにより、Podの配置が理想的なものでなくなります。
9797

9898
kube-schedulerが頻繁に不適切なPodの配置を行わないよう、`percentageOfNodesToScore`をかなり低い値を設定することは避けるべきです。
99-
スケジューラのスループットがアプリケーションにとって致命的で、ノードのスコアリングが重要でない場合を除いて、10%未満に設定することは避けてください。
99+
スケジューラーのスループットがアプリケーションにとって致命的で、ノードのスコアリングが重要でない場合を除いて、10%未満に設定することは避けてください。
100100
言いかえると、割り当て可能な限り、Podは任意のノード上で稼働させるのが好ましいです。
101101

102102
## スケジューラーはどのようにノードを探索するか {#how-the-scheduler-iterates-over-nodes}

‎content/ja/docs/concepts/storage/storage-classes.md‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -129,7 +129,7 @@ PersistentVolumeは、Podのスケジュール制約によって指定された
129129
[CSIボリューム](/ja/docs/concepts/storage/volumes/#csi)も動的プロビジョニングと事前作成されたPVでサポートされていますが、サポートされているトポロジーキーと例を確認するには、特定のCSIドライバーのドキュメントを参照する必要があります。
130130

131131
{{< note >}}
132-
`WaitForFirstConsumer`の使用を選択した場合は、Pod仕様で`nodeName`を使用してノードアフィニティを指定しないでください。この場合にnodeNameを使用すると、スケジューラはバイパスされ、PVCは保留状態のままになります。
132+
`WaitForFirstConsumer`の使用を選択した場合は、Pod仕様で`nodeName`を使用してノードアフィニティを指定しないでください。この場合にnodeNameを使用すると、スケジューラーはバイパスされ、PVCは保留状態のままになります。
133133

134134
代わりに、以下に示すように、この場合はホスト名にノードセレクターを使用できます。
135135
{{< /note >}}
@@ -535,4 +535,4 @@ volumeBindingMode: WaitForFirstConsumer
535535

536536
ローカルボリュームは現在、動的プロビジョニングをサポートしていませんが、Podのスケジューリングまでボリュームバインドを遅らせるには、引き続きStorageClassを作成する必要があります。これは、`WaitForFirstConsumer`ボリュームバインディングモードによって指定されます。
537537

538-
ボリュームバインディングを遅延させると、PersistentVolumeClaimに適切なPersistentVolumeを選択するときに、スケジューラはPodのスケジューリング制約をすべて考慮することができます。
538+
ボリュームバインディングを遅延させると、PersistentVolumeClaimに適切なPersistentVolumeを選択するときに、スケジューラーはPodのスケジューリング制約をすべて考慮することができます。

‎content/ja/docs/concepts/storage/volumes.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -610,7 +610,7 @@ spec:
610610
```
611611

612612
ローカルボリュームを使用する場合は、PersistentVolume `nodeAffinity`を設定する必要があります。
613-
KubernetesのスケジューラはPersistentVolume `nodeAffinity`を使用して、これらのPodを正しいノードにスケジューリングします。
613+
KubernetesのスケジューラーはPersistentVolume `nodeAffinity`を使用して、これらのPodを正しいノードにスケジューリングします。
614614

615615
PersistentVolume `volumeMode`を(デフォルト値の「Filesystem」ではなく)「Block」に設定して、ローカルボリュームをrawブロックデバイスとして公開できます。
616616

0 commit comments

Comments
 (0)