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] 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)