From 072d6a07c483bc7e18697337019f0a19852dc2bf Mon Sep 17 00:00:00 2001 From: 196Ikuchil <196thinline@gmail.com> Date: Sat, 26 Feb 2022 20:47:01 +0900 Subject: [PATCH 1/3] docs:translate concepts/scheduling-eviction/pod-overhead/ --- .../scheduling-eviction/pod-overhead.md | 160 ++++++++++++++++++ 1 file changed, 160 insertions(+) create mode 100644 content/ja/docs/concepts/scheduling-eviction/pod-overhead.md diff --git a/content/ja/docs/concepts/scheduling-eviction/pod-overhead.md b/content/ja/docs/concepts/scheduling-eviction/pod-overhead.md new file mode 100644 index 0000000000..89a7d4fdeb --- /dev/null +++ b/content/ja/docs/concepts/scheduling-eviction/pod-overhead.md @@ -0,0 +1,160 @@ +--- +title: Podのオーバーヘッド +content_type: concept +weight: 30 +--- + + + +{{< feature-state for_k8s_version="v1.18" state="beta" >}} + + +PodをNode上で実行する時に、Pod自身は大量のシステムリソースを消費します。これらのリソースは、Pod内のコンテナ(群)を実行するために必要なリソースとして追加されます。Podのオーバーヘッドは、コンテナの要求と制限に加えて、Podのインフラストラクチャで消費されるリソースを計算するための機能です。 + + + + + + +Kubernetesでは、Podの[RuntimeClass](/docs/concepts/containers/runtime-class/)に関連するオーバーヘッドに応じて、[アドミッション](/ja/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks)時にPodのオーバーヘッドが設定されます。 + +Podのオーバーヘッドを有効にした場合、Podのスケジューリング時にコンテナのリソース要求の合計に加えて、オーバーヘッドも考慮されます。同様に、Kubeletは、Podのcgroupのサイズ決定時およびPodの退役の順位付け時に、Podのオーバーヘッドを含めます。 + +## Podのオーバーヘッドの有効化　{#set-up} + +クラスター全体で`PodOverhead`の[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)が有効になっていること（1.18時点ではデフォルトでオンになっています）と、`overhead`フィールドを定義する`RuntimeClass`が利用されていることを確認する必要があります。 + +## 使用例 + +Podのオーバーヘッド機能を使用するためには、`overhead`フィールドが定義されたRuntimeClassが必要です。例として、仮想マシンとゲストOSにPodあたり約120MiBを使用する仮想化コンテナーランタイムで、次のようなRuntimeClassを定義できます。 + +```yaml +--- +kind: RuntimeClass +apiVersion: node.k8s.io/v1 +metadata: + name: kata-fc +handler: kata-fc +overhead: + podFixed: + memory: "120Mi" + cpu: "250m" +``` + +`kata-fc`RuntimeClassハンドラーを指定して作成されたワークロードは、リソースクォータの計算や、Nodeのスケジューリング、およびPodのcgroupのサイズ決定にメモリーとCPUのオーバーヘッドが考慮されます。 + +次のtest-podのワークロードの例を実行するとします。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-pod +spec: + runtimeClassName: kata-fc + containers: + - name: busybox-ctr + image: busybox + stdin: true + tty: true + resources: + limits: + cpu: 500m + memory: 100Mi + - name: nginx-ctr + image: nginx + resources: + limits: + cpu: 1500m + memory: 100Mi +``` + +アドミッション時、RuntimeClass[アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/)は、RuntimeClass内に記述された`オーバーヘッド`を含むようにワークロードのPodSpecを更新します。もし既にPodSpec内にこのフィールドが定義済みの場合、そのPodは拒否されます。この例では、RuntimeClassの名前しか指定されていないので、アドミッションコントローラーは`オーバーヘッド`を含むようにPodを変更します。 + +RuntimeClassのアドミッションコントローラーの後、更新されたPodSpecを確認できます。 + +```bash +kubectl get pod test-pod -o jsonpath='{.spec.overhead}' +``` + +出力は次の通りです: +``` +map[cpu:250m memory:120Mi] +``` +ResourceQuotaが定義されている場合、コンテナー要求の合計と`オーバーヘッド`フィールドがカウントされます。 + +kube-schedulerが新しいPodを実行すべきNodeを決定する際、スケジューラーはそのPodの`オーバーヘッド`と、そのPodに対するコンテナー要求の合計を考慮します。この例だと、スケジューラーは、要求とオーバーヘッドを追加し、2.25CPUと320MiBのメモリを持つNodeを探します。 + +PodがNodeにスケジュールされると、そのNodeのkubeletはPodのために新しい{{< glossary_tooltip text="cgroup" term_id="cgroup" >}}を生成します。基盤となるコンテナーランタイムがコンテナーを作成するのは、このPod内です。 + +リソースにコンテナごとの制限が定義されている場合(制限が定義されているGuaranteed QoSまたはBustrable QoS)、kubeletはそのリソース(CPUはcpu.cfs_quota_us、メモリはmemory.limit_in_bytes)に関連するPodのcgroupの上限を設定します。この上限は、コンテナーの制限とPodSpecで定義された`オーバーヘッド`の合計に基づきます。 + +CPUについては、PodがGuaranteedまたはBurstable QoSの場合、kubeletはコンテナーの要求の合計とPodSpecに定義された`オーバーヘッド`に基づいて`cpu.share`を設定します。 + +次の例より、ワークロードに対するコンテナーの要求を確認できます。 +```bash +kubectl get pod test-pod -o jsonpath='{.spec.containers[*].resources.limits}' +``` + +コンテナーの要求の合計は、CPUは2000m、メモリーは200MiBです。 +``` +map[cpu: 500m memory:100Mi] map[cpu:1500m memory:100Mi] +``` + +Nodeで観測される値と比較してみましょう。 +```bash +kubectl describe node | grep test-pod -B2 +``` + +出力では、2250mのCPUと320MiBのメモリーが要求されており、Podのオーバーヘッドが含まれていることが分かります。 +``` + Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits AGE + --------- ---- ------------ ---------- --------------- ------------- --- + default test-pod 2250m (56%) 2250m (56%) 320Mi (1%) 320Mi (1%) 36m +``` + +## Podのcgroupの制限を確認 + +ワークロードで実行中のNode上にある、Podのメモリーのcgroupを確認します。次に示す例では、CRI互換のコンテナーランタイムのCLIを提供するNodeで[`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md)を使用しています。これはPodのオーバーヘッドの動作を示すための高度な例であり、ユーザーがNode上で直接cgroupsを確認する必要はありません。 + +まず、特定のNodeで、Podの識別子を決定します。 + +```bash +# PodがスケジュールされているNodeで実行 +POD_ID="$(sudo crictl pods --name test-pod -q)" +``` + +ここから、Podのcgroupのパスが決定します。 +```bash +# PodがスケジュールされているNodeで実行 +sudo crictl inspectp -o=json $POD_ID | grep cgroupsPath +``` + +結果のcgroupパスにはPodの`ポーズ中`コンテナーも含まれます。Podレベルのcgroupは１つ上のディレクトリです。 +``` + "cgroupsPath": "/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/7ccf55aee35dd16aca4189c952d83487297f3cd760f1bbf09620e206e7d0c27a" +``` + +今回のケースでは、Podのcgroupパスは、`kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2`となります。メモリーのPodレベルのcgroupの設定を確認しましょう。 +```bash +# PodがスケジュールされているNodeで実行 +# また、Podに割り当てられたcgroupと同じ名前に変更 + cat /sys/fs/cgroup/memory/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/memory.limit_in_bytes +``` + +予想通り320MiBです。 +``` +335544320 +``` + +### Observability + +Podのオーバヘッドが利用されているタイミングを特定し、定義されたオーバーヘッドで実行されているワークロードの安定性を観察するため、[kube-state-metrics](https://github.com/kubernetes/kube-state-metrics)には`kube_pod_overhead`というメトリクスが用意されています。この機能はv1.9のkube-state-metricsでは利用できませんが、次のリリースで期待されています。それまでは、kube-state-metricsをソースからビルドする必要があります。 + + + +## {{% heading "whatsnext" %}} + + +* [RuntimeClass](/ja/docs/concepts/containers/runtime-class/) +* [Podのオーバーヘッドの設計](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead) From b602aac06ff3219548d14076da77686defea6b32 Mon Sep 17 00:00:00 2001 From: 196Ikuchil <196thinline@gmail.com> Date: Wed, 16 Mar 2022 18:15:52 +0900 Subject: [PATCH 2/3] =?UTF-8?q?fix:replace=20=E3=82=B3=E3=83=B3=E3=83=86?= =?UTF-8?q?=E3=83=8A=E3=83=BC=20to=20=E3=82=B3=E3=83=B3=E3=83=86=E3=83=8A?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../scheduling-eviction/pod-overhead.md | 20 +++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/content/ja/docs/concepts/scheduling-eviction/pod-overhead.md b/content/ja/docs/concepts/scheduling-eviction/pod-overhead.md index 89a7d4fdeb..6fa3853204 100644 --- a/content/ja/docs/concepts/scheduling-eviction/pod-overhead.md +++ b/content/ja/docs/concepts/scheduling-eviction/pod-overhead.md @@ -26,7 +26,7 @@ Podのオーバーヘッドを有効にした場合、Podのスケジューリ ## 使用例 -Podのオーバーヘッド機能を使用するためには、`overhead`フィールドが定義されたRuntimeClassが必要です。例として、仮想マシンとゲストOSにPodあたり約120MiBを使用する仮想化コンテナーランタイムで、次のようなRuntimeClassを定義できます。 +Podのオーバーヘッド機能を使用するためには、`overhead`フィールドが定義されたRuntimeClassが必要です。例として、仮想マシンとゲストOSにPodあたり約120MiBを使用する仮想化コンテナランタイムで、次のようなRuntimeClassを定義できます。 ```yaml --- @@ -81,22 +81,22 @@ kubectl get pod test-pod -o jsonpath='{.spec.overhead}' ``` map[cpu:250m memory:120Mi] ``` -ResourceQuotaが定義されている場合、コンテナー要求の合計と`オーバーヘッド`フィールドがカウントされます。 +ResourceQuotaが定義されている場合、コンテナ要求の合計と`オーバーヘッド`フィールドがカウントされます。 -kube-schedulerが新しいPodを実行すべきNodeを決定する際、スケジューラーはそのPodの`オーバーヘッド`と、そのPodに対するコンテナー要求の合計を考慮します。この例だと、スケジューラーは、要求とオーバーヘッドを追加し、2.25CPUと320MiBのメモリを持つNodeを探します。 +kube-schedulerが新しいPodを実行すべきNodeを決定する際、スケジューラーはそのPodの`オーバーヘッド`と、そのPodに対するコンテナ要求の合計を考慮します。この例だと、スケジューラーは、要求とオーバーヘッドを追加し、2.25CPUと320MiBのメモリを持つNodeを探します。 -PodがNodeにスケジュールされると、そのNodeのkubeletはPodのために新しい{{< glossary_tooltip text="cgroup" term_id="cgroup" >}}を生成します。基盤となるコンテナーランタイムがコンテナーを作成するのは、このPod内です。 +PodがNodeにスケジュールされると、そのNodeのkubeletはPodのために新しい{{< glossary_tooltip text="cgroup" term_id="cgroup" >}}を生成します。基盤となるコンテナランタイムがコンテナを作成するのは、このPod内です。 -リソースにコンテナごとの制限が定義されている場合(制限が定義されているGuaranteed QoSまたはBustrable QoS)、kubeletはそのリソース(CPUはcpu.cfs_quota_us、メモリはmemory.limit_in_bytes)に関連するPodのcgroupの上限を設定します。この上限は、コンテナーの制限とPodSpecで定義された`オーバーヘッド`の合計に基づきます。 +リソースにコンテナごとの制限が定義されている場合(制限が定義されているGuaranteed QoSまたはBustrable QoS)、kubeletはそのリソース(CPUはcpu.cfs_quota_us、メモリはmemory.limit_in_bytes)に関連するPodのcgroupの上限を設定します。この上限は、コンテナの制限とPodSpecで定義された`オーバーヘッド`の合計に基づきます。 -CPUについては、PodがGuaranteedまたはBurstable QoSの場合、kubeletはコンテナーの要求の合計とPodSpecに定義された`オーバーヘッド`に基づいて`cpu.share`を設定します。 +CPUについては、PodがGuaranteedまたはBurstable QoSの場合、kubeletはコンテナの要求の合計とPodSpecに定義された`オーバーヘッド`に基づいて`cpu.share`を設定します。 -次の例より、ワークロードに対するコンテナーの要求を確認できます。 +次の例より、ワークロードに対するコンテナの要求を確認できます。 ```bash kubectl get pod test-pod -o jsonpath='{.spec.containers[*].resources.limits}' ``` -コンテナーの要求の合計は、CPUは2000m、メモリーは200MiBです。 +コンテナの要求の合計は、CPUは2000m、メモリーは200MiBです。 ``` map[cpu: 500m memory:100Mi] map[cpu:1500m memory:100Mi] ``` @@ -115,7 +115,7 @@ kubectl describe node | grep test-pod -B2 ## Podのcgroupの制限を確認 -ワークロードで実行中のNode上にある、Podのメモリーのcgroupを確認します。次に示す例では、CRI互換のコンテナーランタイムのCLIを提供するNodeで[`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md)を使用しています。これはPodのオーバーヘッドの動作を示すための高度な例であり、ユーザーがNode上で直接cgroupsを確認する必要はありません。 +ワークロードで実行中のNode上にある、Podのメモリーのcgroupを確認します。次に示す例では、CRI互換のコンテナランタイムのCLIを提供するNodeで[`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md)を使用しています。これはPodのオーバーヘッドの動作を示すための高度な例であり、ユーザーがNode上で直接cgroupsを確認する必要はありません。 まず、特定のNodeで、Podの識別子を決定します。 @@ -130,7 +130,7 @@ POD_ID="$(sudo crictl pods --name test-pod -q)" sudo crictl inspectp -o=json $POD_ID | grep cgroupsPath ``` -結果のcgroupパスにはPodの`ポーズ中`コンテナーも含まれます。Podレベルのcgroupは１つ上のディレクトリです。 +結果のcgroupパスにはPodの`ポーズ中`コンテナも含まれます。Podレベルのcgroupは１つ上のディレクトリです。 ``` "cgroupsPath": "/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/7ccf55aee35dd16aca4189c952d83487297f3cd760f1bbf09620e206e7d0c27a" ``` From 30de7d917409a17f2ee0e969ba4ea40286254f3c Mon Sep 17 00:00:00 2001 From: 196Ikuchil <196thinline@gmail.com> Date: Wed, 16 Mar 2022 18:20:45 +0900 Subject: [PATCH 3/3] =?UTF-8?q?fix:replace=20=E3=81=9F=E3=82=81=20to=20?= =?UTF-8?q?=E3=81=AE=E3=81=A7?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- content/ja/docs/concepts/scheduling-eviction/pod-overhead.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/scheduling-eviction/pod-overhead.md b/content/ja/docs/concepts/scheduling-eviction/pod-overhead.md index 6fa3853204..f88da29e8f 100644 --- a/content/ja/docs/concepts/scheduling-eviction/pod-overhead.md +++ b/content/ja/docs/concepts/scheduling-eviction/pod-overhead.md @@ -69,7 +69,7 @@ spec: memory: 100Mi ``` -アドミッション時、RuntimeClass[アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/)は、RuntimeClass内に記述された`オーバーヘッド`を含むようにワークロードのPodSpecを更新します。もし既にPodSpec内にこのフィールドが定義済みの場合、そのPodは拒否されます。この例では、RuntimeClassの名前しか指定されていないので、アドミッションコントローラーは`オーバーヘッド`を含むようにPodを変更します。 +アドミッション時、RuntimeClass[アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/)は、RuntimeClass内に記述された`オーバーヘッド`を含むようにワークロードのPodSpecを更新します。もし既にPodSpec内にこのフィールドが定義済みの場合、そのPodは拒否されます。この例では、RuntimeClassの名前しか指定されていないため、アドミッションコントローラーは`オーバーヘッド`を含むようにPodを変更します。 RuntimeClassのアドミッションコントローラーの後、更新されたPodSpecを確認できます。