fix manage-resources-containers.md
akitok
Akito Kobayashi
parent
5b4d09cd87
commit
07dabc1b06
|
|
@ -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(2<sup>26</sup>バイト)のメモリー要求があります。
|
||||
各コンテナには、0.5cpuおよび128MiBのメモリー制限があります。
|
||||
各コンテナには、0.25cpuおよび64MiB(2<sup>26</sup>バイト)のメモリー要求と、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が現れるまでには、短い遅延が生じる可能性があることに注意してください。
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue