whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix manage-resources-containers.md

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