From 07dabc1b063a88d18313f2df186bc597150ed871 Mon Sep 17 00:00:00 2001 From: akitok Date: Sat, 25 Jul 2020 01:20:20 +0900 Subject: [PATCH] fix manage-resources-containers.md --- .../manage-resources-containers.md | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/content/ja/docs/concepts/configuration/manage-resources-containers.md b/content/ja/docs/concepts/configuration/manage-resources-containers.md index eb9df8d289..a502842474 100644 --- a/content/ja/docs/concepts/configuration/manage-resources-containers.md +++ b/content/ja/docs/concepts/configuration/manage-resources-containers.md @@ -22,7 +22,7 @@ Pod内のコンテナのリソース_要求_を指定すると、スケジュー Podが動作しているNodeに利用可能なリソースが十分にある場合、そのリソースの`要求`が指定するよりも多くのリソースをコンテナが使用することが許可されます ただし、コンテナはそのリソースの`制限`を超えて使用することはできません。 -たとえば、コンテナに256 MiBの `メモリー`要求を設定し、そのコンテナが8GiBのメモリーを持つNodeにスケジュールされたPod内に存在し、他のPodが存在しない場合、コンテナはより多くのRAMを使用しようとする可能性があります。 +たとえば、コンテナに256MiBの`メモリー`要求を設定し、そのコンテナが8GiBのメモリーを持つNodeにスケジュールされたPod内に存在し、他のPodが存在しない場合、コンテナはより多くのRAMを使用しようとする可能性があります。 そのコンテナに4GiBの`メモリー`制限を設定すると、kubelet(および{{< glossary_tooltip text="コンテナランタイム" term_id="container-runtime" >}}) が制限を適用します。ランタイムは、コンテナーが設定済みのリソース制限を超えて使用するのを防ぎます。例えば、コンテナ内のプロセスが、許容量を超えるメモリを消費しようとすると、システムカーネルは、メモリ不足(OOM)エラーで、割り当てを試みたプロセスを終了します。 @@ -42,7 +42,7 @@ Huge PageはLinux固有の機能であり、Nodeのカーネルはデフォル {{< note >}} `hugepages- *`リソースをオーバーコミットすることはできません。 -これは `memory`や`cpu`リソースとは異なります。 +これは`memory`や`cpu`リソースとは異なります。 {{< /note >}} CPUとメモリーは、まとめて*コンピュートリソース*または単に*リソース*と呼ばれます。 @@ -74,7 +74,7 @@ Kuberenetesにおける1つのCPUは、クラウドプロバイダーの**1 vCPU 要求を少数で指定することもできます。 `spec.containers[].resources.requests.cpu`が`0.5`のコンテナは、1CPUを要求するコンテナの半分のCPUが保証されます。 `0.1`という表現は`100m`という表現と同等であり、`100ミリCPU`と読み替えることができます。 -`100ミリコア`と言う人もいますが、これは同じことを意味すると理解されています。 +`100ミリコア`という表現も、同じことを意味しています。 `0.1`のような小数点のある要求はAPIによって`100m`に変換され、`1m`より細かい精度は許可されません。 このため、`100m`の形式が推奨されます。 @@ -94,8 +94,7 @@ E、P、T、G、M、Kのいずれかのサフィックスを使用して、メ 例を見てみましょう。 次のPodには2つのコンテナがあります。 -各コンテナには、0.25cpuおよび64MiB(226バイト)のメモリー要求があります。 -各コンテナには、0.5cpuおよび128MiBのメモリー制限があります。 +各コンテナには、0.25cpuおよび64MiB(226バイト)のメモリー要求と、0.5cpuおよび128MiBのメモリー制限があります Podには0.5cpuと128MiBのメモリー要求があり、1cpuと256MiBのメモリ制限があると言えます。 ```yaml @@ -231,7 +230,7 @@ kubeletは、ローカルストレージの使用量を測定できます。 別の構成を使用している場合、kubeletはローカルのエフェメラルストレージにリソース制限を適用しません。 {{< note >}} -kubeletは、 `tmpfs`のemptyDirボリュームをローカルのエフェメラルストレージとしてではなく、コンテナメモリーとして追跡します。 +kubeletは、`tmpfs`のemptyDirボリュームをローカルのエフェメラルストレージとしてではなく、コンテナメモリーとして追跡します。 {{< /note >}} ### ローカルのエフェメラルストレージの要求と制限設定 @@ -293,7 +292,7 @@ Podを作成すると、KubernetesスケジューラーはPodを実行するNode kubeletがローカルのエフェメラルストレージをリソースとして管理している場合、kubeletはストレージの使用量を測定します -- _tmpfs_ `emptyDir`ボリュームを除く`emptyDir`ボリューム +- _tmpfs_`emptyDir`ボリュームを除く`emptyDir`ボリューム - Nodeレベルのログを保持するディレクトリ - 書き込み可能なコンテナレイヤー @@ -332,7 +331,7 @@ kubeletは、`emptyDir`ボリューム、コンテナログディレクトリ、 プロジェクトクォータは、ファイルシステム上のストレージ使用量を管理するためのオペレーティングシステムレベルの機能です。 Kubernetesでは、プロジェクトクォータを有効にしてストレージの使用状況を監視することができます。 -ノード上の `emptyDir` ボリュームをバックアップしているファイルシステムがプロジェクトクォータをサポートしていることを確認してください。 +ノード上の`emptyDir`ボリュームをバックアップしているファイルシステムがプロジェクトクォータをサポートしていることを確認してください。 例えば、XFSやext4fsはプロジェクトクォータを提供しています。 {{< note >}} @@ -369,7 +368,7 @@ Kubernetesが使用しないようにする必要があります。 ## 拡張リソース -拡張リソースは `kubernetes.io` ドメインの外で完全に修飾されたリソース名です。 +拡張リソースは`kubernetes.io`ドメインの外で完全に修飾されたリソース名です。 これにより、クラスタオペレータはKubernetesに組み込まれていないリソースをアドバタイズし、ユーザはそれを利用することができるようになります。 拡張リソースを使用するためには、2つのステップが必要です。 @@ -387,7 +386,7 @@ Nodeレベルの拡張リソースはNodeに関連付けられています。 ##### その他のリソース 新しいNodeレベルの拡張リソースをアドバタイズするには、クラスタオペレータはAPIサーバに`PATCH`HTTPリクエストを送信し、クラスタ内のNodeの`status.capacity`に利用可能な量を指定します。 -この操作の後、ノードの `status.capacity` には新しいリソースが含まれます。 +この操作の後、ノードの`status.capacity`には新しいリソースが含まれます。 `status.allocatable`フィールドは、kubeletによって非同期的に新しいリソースで自動的に更新されます。 スケジューラはPodの適合性を評価する際にNodeの`status.allocatable`値を使用するため、Nodeの容量に新しいリソースを追加してから、そのNodeでリソースのスケジューリングを要求する最初のPodが現れるまでには、短い遅延が生じる可能性があることに注意してください。