Kubernetes基盤⇔VMware基盤 計算リソース管理方式比較 早見表

#本記事執筆の背景

Kubernetes基盤を用いたシステム運用を本格化するにあたっての見逃すことが出来ない一つのトピックとして、計算リソース管理を挙げることが出来ます（**なお、本記事の以降の記述においては、「リソース」という用語はKubernetes製品におけるAPIリソースではなく、CPU資源やメモリ資源などの計算リソースを指すものとします**）。その背景としては、以下に示す3つのポイントを挙げることが出来ます。

* 柔軟性/迅速性に優れるKubernetes基盤を活用することにより実現する、動的なリソース最適化（例:オートスケール）に対する関係者の期待が大きい。
* 「DevOps」の文脈に基づきKubernetes基盤を運用する場合には、基盤上で稼働するワークロードは（その消費リソースも含めて）必然的に動的な性質を持たざるを得ない。
* Kubernetes基盤上で稼働するコンテナの個数が著しく膨大になることが予想されるため、「数の暴力」に対応するための自律的なリソース管理のための実装を整える必要が生じる。

一方で、Kubernetes製品の初学者（典型的には、過去にVMware基盤[^1]の実装・運用を担当していたシステム基盤のスペシャリスト）にとって、上述した背景を踏まえた上での動的なリソース管理はなかなか馴染みが無いものであったりします。

上述したような状況を踏まえた上で、本記事では、過去にVMware基盤の実装・運用を担当していたシステム基盤のスペシャリストを読者として想定した上で、VMware基盤とKuberentes基盤との類似点/相違点を**4つの早見表**として示すことにより、Kuberenetes基盤でのリソース管理の概観を明らかにします。

#本記事での記述内容についての留意事項

本記事の記述内容は、原則として、以下の製品バージョンに準拠しています。
* Kubernetes製品 v1.14
* VMware vSphere製品 v6.7

また、正確を期すために、可能な範囲で根拠となるべき出典を参照するよう対応させていただいておりますが、実機動作やソースコード内容への検証といったレベルでの裏付けは取れていないため、その旨をご了承願います。

#リソース管理 実装比較 早見表
リソース管理に関わる基本的な概念項目のそれぞれを対象として、Kubernetes基盤におけるリソース管理実装とVMware基盤における実装との間での相違を以下の早見表に示します。

|リソース管理の概念  |VMware基盤  |Kubernetes基盤  |
|---|---|---|
|管理対象とし得るリソース種別|CPUサイクル、メモリ容量、GPU処理能力、ネットワークI/O（NIOC）、ストレージI/O（SIOC）|CPUサイクル、メモリ容量、短期的ストレージ容量[^2]、GPU処理能力...etc.[^3]|
|リソースの予約|[予約](https://docs.vmware.com/jp/VMware-vSphere/6.7/com.vmware.vsphere.resmgmt.doc/GUID-8B88D3D8-E9D9-4C05-A065-B3DE1FFFB401.html)  |[requests](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#resource-requests-and-limits-of-pod-and-container) |
|リソースの上限|[制限](https://docs.vmware.com/jp/VMware-vSphere/6.7/com.vmware.vsphere.resmgmt.doc/GUID-117972E3-F5D3-4641-9EAC-F9DD2B0761C3.html)|[limits](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#resource-requests-and-limits-of-pod-and-container)|
|リソースの割り当て比|[シェア](https://docs.vmware.com/jp/VMware-vSphere/6.7/com.vmware.vsphere.resmgmt.doc/GUID-C0D2EFAE-1FE4-4867-AC3F-3E70D9A9ED59.html)  |[requests](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#resource-requests-and-limits-of-pod-and-container)[^4]|
|CPUコアの静的割り当て|[CPUアフィニティ](https://docs.vmware.com/jp/VMware-vSphere/6.7/com.vmware.vsphere.resmgmt.doc/GUID-5FCC0AAA-9D58-4EDF-9A5F-8628F1C8B830.html)|（対応する実装なし）[^5]|
|GPUリソース管理|vDGA、vSGA、Shared Pass-Through Graphics[^6]  |[Kubernetes Device Plug-in拡張実装](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)[^7]によるGPUリソース管理の有効化|
|ストレージI/O管理|[vSphere Storage I/O Control（SIOC）](https://docs.vmware.com/jp/VMware-vSphere/6.7/com.vmware.vsphere.resmgmt.doc/GUID-7686FEC3-1FAC-4DA7-B698-B808C44E5E96.html)|（対応する実装なし）[^8]|
|ネットワークI/O管理|[vSphere Network I/O Control](https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.networking.doc/GUID-ADEA0213-C969-43E4-B1F4-66D4A916EBDF.html)|（対応する実装なし）[^8]|
|リソース割り当て運用の利用者への委任|[リソースプール](https://docs.vmware.com/jp/VMware-vSphere/6.7/com.vmware.vsphere.resmgmt.doc/GUID-60077B40-66FF-4625-934A-641703ED7601.html)を用いた委任|[Resource Quota](https://kubernetes.io/docs/concepts/policy/resource-quotas/)を用いた委任**（詳細比較は後続の早見表で）**|
|コンピュートインスタンスの配置最適化|[DRS](https://docs.vmware.com/jp/VMware-vSphere/6.7/com.vmware.vsphere.resmgmt.doc/GUID-8ACF3502-5314-469F-8CC9-4A9BD5925BC2.html)による配置最適化|[kube-scheduler](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-scheduling/scheduler.md)による配置最適化**（詳細比較は後続の早見表で）**|
|基盤リソース逼迫状況におけるクラスタ内でのリソース配分の最適化|[DRS](https://docs.vmware.com/jp/VMware-vSphere/6.7/com.vmware.vsphere.resmgmt.doc/GUID-8ACF3502-5314-469F-8CC9-4A9BD5925BC2.html)による仮想マシンの動的再配置を通じた、リソース配分の最適化|[Eviction](https://kubernetes.io/docs/tasks/administer-cluster/out-of-resource/#eviction-policy)、および[Preemption](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/)を用いた、実行優先度が低いコンテナの強制終了、および、実行優先度が高いコンテナへのリソース割り当て**（詳細比較は後続の早見表で）**|
|コンピュートインスタンスの自律的なスケールアウト/スケールアップ|（対応する実装なし）|[Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/)機能を用いたコンテナの自律的なスケールアウト、および、[Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler)機能を用いたコンテナの自律的なスケールアップ[^9]|
|システム基盤の自律的なスケールアウト/スケールアップ|（対応する実装なし）|[Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler)機能を用いたノードの自律的なスケールアウト[^10]|

#利用者へのリソース割り当て運用の委任 動作比較 早見表
「リソース管理 実装比較」の早見表で示した通り、Kubernetes基盤においては、コンテナへのリソース割り当てを利用者に委任する運用を[Resource Quota](https://kubernetes.io/docs/concepts/policy/resource-quotas/)実装により支援します。この、利用者へのリソース割り当て運用の委任を対象として、以下の早見表にKubernetes基盤とVMware基盤との間での相違を示します。

|比較の観点  |VMware基盤  |Kubernetes基盤  |
|---|---|---|
|利用者への委任単位|[リソースプール](https://docs.vmware.com/jp/VMware-vSphere/6.7/com.vmware.vsphere.resmgmt.doc/GUID-60077B40-66FF-4625-934A-641703ED7601.html)|[namespace](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/)|
|委任に際して統制の対象と出来るリソース種別|CPUサイクル、メモリ容量|CPUサイクル、メモリ容量、永続ストレージ容量（他、多数）[^11]|
|コンピュートインスタンス1個あたりのリソース割り当ての制限[^12]|不可能|可能（「LimitRange」機能[^13]により実現する）|
|「リソースプール」の階層化|可能|不可能|

#コンピュートインスタンスの配置最適化 動作比較 早見表
「リソース管理 実装比較」の早見表で示した通り、Kubernetes基盤においては[kube-scheduler](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-scheduling/scheduler.md)実装によりノード上へのコンテナの配置が最適化されます。これは、[DRS](https://docs.vmware.com/jp/VMware-vSphere/6.7/com.vmware.vsphere.resmgmt.doc/GUID-8ACF3502-5314-469F-8CC9-4A9BD5925BC2.html)を用いることによりESXiホストへの仮想マシンの配置を最適化するVMware基盤での運用と類似しています。そうしたコンピュートインスタンス（コンテナ、仮想マシン）配置の自律的な最適化を対象として、以下の早見表にKubernetes基盤とVMware基盤との間での相違を示します。

|比較の観点  |VMware基盤  |Kubernetes基盤  |
|---|---|---|
|動的配置機能の既定での有効/無効|無効[^14]|有効|
|配置最適化の過程におけるノード負荷状況への配慮|あり|なし[^15]|
|ノードを指定する形でのコンピュートインスタンスの配置制御[^16]|[仮想マシンとホスト間のアフィニティルール](https://docs.vmware.com/jp/VMware-vSphere/6.7/com.vmware.vsphere.resmgmt.doc/GUID-2FB90EF5-7733-4095-8B66-F10D6C57B820.html)により実現する。|[nodeSelector](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#nodeselector)実装、[nodeAffinity](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)実装、もしくは[Taints and Tolerations](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/)実装により実現する。|
|コンピュートインスタンス間での配置制御[^17]|[仮想マシン間のアフィニティルール](https://docs.vmware.com/jp/VMware-vSphere/6.7/com.vmware.vsphere.resmgmt.doc/GUID-94FCC204-115A-4918-9533-BFC588338ECB.html)により実現する |[Inter-Pod Affinity](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)実装により実現する|
|ノード負荷平準化を目的としたコンピュートインスタンスの再配置|vMotionによる仮想マシン移行|なし[^19]|

#基盤リソース逼迫状況における動作比較 早見表
「リソース管理 実装比較」の早見表で示した通り、Kubernetes基盤では、基盤が提供するリソースが逼迫した際に、実行優先度が低いコンテナを強制終了することにより、優先度が高いコンテナの稼働のために必要なリソースを確保するための実装が提供されています。そのような基盤リソース逼迫時における動作を対象として、以下の早見表にKubernetes基盤とVMware基盤との間での相違を示します。

|比較の観点  |VMware基盤  |Kubernetes基盤  |
|---|---|---|
|リソース逼迫時の起動制限|[アドミッションコントロール](https://docs.vmware.com/jp/VMware-vSphere/6.7/com.vmware.vsphere.resmgmt.doc/GUID-25AAD7FD-5579-4F7E-AB3A-60CF8D982A06.html)により、余剰リソースが不足している状態での仮想マシンの起動が制限される。  |[アドミッションコントロール相当のリソース管理実装](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#how-pods-with-resource-requests-are-scheduled)により、余剰リソースが不足している状態でのコンテナの起動が制限される。|
|ノードにおいてリソースが逼迫した際のリソース再配分動作|[透過的メモリ共有](https://docs.vmware.com/jp/VMware-vSphere/6.7/com.vmware.vsphere.resmgmt.doc/GUID-F9111E35-E197-46EC-8350-77827A5A2DEC.html)や[メモリバルーニング](https://docs.vmware.com/jp/VMware-vSphere/6.7/com.vmware.vsphere.resmgmt.doc/GUID-85BDEAD3-C889-46AC-BC01-D4B39C638E49.html)などを用いた、メモリリソースの節約、および再配分が行われる。リソース逼迫を理由として仮想マシンが強制されることはない。|優先度（[QoS Class](https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/#qos-classes)）が低いコンテナを[Eviction Policy](https://kubernetes.io/docs/tasks/administer-cluster/out-of-resource/#eviction-policy)に基づき強制終了することにより、強制終了されたコンテナが保持していたリソースを回収すると共に、より優先度が高いコンテナにリソースを再配分する。|
|クラスタにおいてリソースが逼迫した際のリソース再配分動作|[DRS](https://docs.vmware.com/jp/VMware-vSphere/6.7/com.vmware.vsphere.resmgmt.doc/GUID-0B9D99DC-71B3-4693-86EF-E0F037F8F016.html)実装を用いてノードへの仮想マシン配置を動的に最適化することによりリソース逼迫の解消を試みる。リソース逼迫を理由として仮想マシンが強制終了されることはない。|[Preemption](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/)実装を用いてクラスタ内での優先度（[Priority Class](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/)）が低いコンテナを強制終了することにより、強制終了されたコンテナが保持していたリソースを回収すると共に、より優先度が高いコンテナにリソースを再配分する。|

なお、本記事において繰り返し用いてきた「優先度」という用語に対応するKubernetes基盤における属性/設定には以下に示す2種類が存在するため、互いに混同しないよう注意が必要です[^18]。

* [QoS Class](https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/#qos-classes)
    * リソース逼迫をノード単位で解消するための、[Eviction](https://kubernetes.io/docs/tasks/administer-cluster/out-of-resource/#eviction-policy)運用のために用いられる。
    * （非常に端的に要約すると）必要十分な分量のリソースをコンテナに対して「予約」（[requests](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#resource-requests-and-limits-of-pod-and-container) ）することを通じて、当該のコンテナが属するPodのQoS Classを高めることが出来る。
* [Priority Class](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/)
    * リソース逼迫をクラスタ単位で解消するための、[Preemption](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/)実装を機能させるために用いられる。
    * Priority ClassはPodに対して明示的に指定しなければならない。

#Kubernetes基盤におけるリソース管理のポイント（VMware基盤の構築・運用経験者に向けて）

本記事で提示した4つの早見表から得られる洞察を、VMware基盤の構築・運用経験者に向けたKubernetes基盤におけるリソース管理のポイントとして、以下に要約します（なお、Kubernetes基盤とVMware基盤との間での差異に相当するポイントは**太字**で記述します）。

1. リソース管理の中核となるCPUサイクル、およびメモリ容量のコンテナへの割り当てに際しては、「予約」と「上限」という、VMware基盤の場合と同様の概念を用いることが出来る。
1. **Kubernetes基盤はI/Oリソース制御の手段を（現時点では）欠いているため、高I/Oのワークロードの配置にあたっては考慮が必要である。**
1. **Kubernetes製品においては、自律的なスケールアウト運用、スケールアップ運用を実現するための機能拡張が積極的に行われている。**
1. 基盤利用者にコンピュートインスタンス（コンテナや仮想マシン）へのリソース割り当てを委任する運用は、Kubernetes基盤の場合でもVMware基盤の場合とほぼ同様の感覚で実現可能である。
1. **Kubernetes基盤では、VMware基盤で言う「DRSによる配置の完全自動化」相当の自律的なコンテナ配置が「既定で」行われるため、自律的なコンテナ配置を制御するためのシステム設計（例:Inter-Pod Affinity設計）が必須となる。**
1. **リソース逼迫への対処として、Kubernetes基盤では、実行優先度（QoS Class/Priority Class）が低いコンテナを強制終了することによるリソース回収が志向される傾向があるため、システム可用性の観点での注意が必要。**

上記のポイント「1.」～「6.」のうち、Kubernetes基盤とVMware基盤との間での差異が特に際立つポイントは、ポイント「3.」、ポイント「5.」、およびポイント「6.」となります。そのため、VMware基盤（もしくは、その類似したハイパーバイザー基盤）の実装・運用の経験者がKubernetes基盤の本番運用に従事するにあたっては、以下に示す3つの実装概念の習得に意識して取り組む必要が生じるでしょう。

* 自律的なスケールアウト/スケールアップ運用（まずは、[Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/)への対応）
* [kube-scheduler](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-scheduling/scheduler.md)実装によるノード配置の最適化
* [Eviction Policy](https://kubernetes.io/docs/tasks/administer-cluster/out-of-resource/#eviction-policy)、および[Preemption](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/)実装による優先度が低いコンテナからのリソース回収

特に、**リソース配分の自律的な最適化を目的としたコンテナの強制終了**、というKubernetes基盤に特徴的な実装が、「基盤リソース利用の効率性」と「コンテナ稼働の可用性/安定性」との間での無視出来ないトレードオフ関係をもたらすことには注意が必要でしょう。

#おすすめ書籍
短時間で体系的な知識を獲得する場合には、書籍を参照することも有効であると考えます。一方で、本記事の執筆者の手元にある何冊かの書籍を眺める限り、リソース管理について取り上げていない、もしくは十分なページを割いていないケースが散見されます。そのため、リソース管理に関して、まとまった記述が為されている（本記事の執筆者の手元にある）おすすめ書籍を以下に紹介します。

* [Kubernetes完全ガイド (impress top gear)](https://www.amazon.co.jp/Kubernetes%E5%AE%8C%E5%85%A8%E3%82%AC%E3%82%A4%E3%83%89-impress-top-gear-%E9%9D%92%E5%B1%B1/dp/4295004804)
    * 書籍自体の内容については、以下の記事で紹介されています。
        * [書評「Kubernetes完全ガイド」Kubernetesを学ぶ全ての人にオススメしたい ｜ DevelopersIO](https://dev.classmethod.jp/etc/kubernetes-perfect-guide/)
* [Kubernetes in Action](https://www.oreilly.com/library/view/kubernetes-in-action/9781617293726/)
    * 洋書、かつ、そこそこのお値段がする書籍ではありますが、O'Reillyが参加する電子書籍読み放題サービスであるSafari Book Onlineよりアクセス出来るため、会員の方はどうぞ。
    * 書籍自体の内容については、以下のブログ記事で紹介されています。
        * [Kubernetes in Actionの個人的なまとめ - 世界中の羊をかき集めて](http://shepherdmaster.hateblo.jp/entry/2018/03/20/214909)

#本記事での解説内容に関係するQiita記事の一覧
本記事での解説内容に関係するQiita記事の一覧を以下に列挙します[^20]。

##Kubernetes基盤でのリソースの予約/上限設定（requests/limits）
* [KubernetesのResource RequestsとResource Limitsについて - Qiita](https://qiita.com/sheepland/items/eb0e4c65aaae70ec4e2f)
* [【第四弾】Kubernetesベストプラクティス：Requests & Limits - Qiita](https://qiita.com/jackchuka/items/b82c545a674975e62c04)

##Kubernetes環境でのGPUリソース管理実装
* [Kubernetes on NVIDIA GPUsとは - Qiita](https://qiita.com/tmatsu/items/0bc9c166a7a89d7f1024)
* [KubernetesからGPUを使ってTensorflowを動かす](https://qiita.com/cvusk/items/5a6f57876fdcff7710d2)
* [Initializersを使ってK8s + NVIDIA device pluginでの意図しないGPUの割当を防止してみる - Qiita](https://qiita.com/tmatsu/items/d8a392862e1090f12073)
* [Kubernetes on NVIDIA GPUsをEC2上に構築してみる - Qiita](https://qiita.com/str416yb/items/e331a360315c42a99cee)

##Kubernetes環境での自律的なスケールアウト/スケールアップ運用
* [KubernetesのPodとNodeのAuto Scalingについて - Qiita](https://qiita.com/sheepland/items/37ea0b77df9a4b4c9d80)
* [Kuberentes の水平オートスケール - Qiita](https://qiita.com/shmurata/items/8ebaf74028365fc950c9)
* [KubernetesでDatadog + Horizontal Pod Autoscalerをやってみた - Qiita](https://qiita.com/knqyf263/items/e82f86e11c998d903a2b)
* [GKE + k8s オートスケールの設定方法 - Qiita](https://qiita.com/zaru/items/176bedfe477707f89aff)
* [Kubernetes の垂直オートスケール - Qiita](https://qiita.com/shmurata/items/197b5b722ac7e9dedb90)
* [GKEがVertical Pod Autoscalerに対応したらしいので調査した - Qiita](https://qiita.com/soiya1919/items/2f084cb68a65655a32f5)
* [Kuberentes クラスタのオートスケール - Qiita](https://qiita.com/shmurata/items/f75ff02a8096e8cfd6cf)
* [GKEでPodとNodeをAutoscaling する - Qiita](https://qiita.com/k-hal/items/5f060fdbafa3d29b3499)

##Kubernetes基盤でのリソース割り当て運用の委任
* [KubernetesのResourceQuotaの動作確認 - Qiita](https://qiita.com/sotoiwa/items/aa32d641185d724cd26a)

##Kubernetes基盤でのノードへのコンテナ配置
* [Kubernetes: スケジューラの動作 - Qiita](https://qiita.com/tkusumi/items/58fdadbe4053812cb44e)
* [kube-schedulerのソースコードを読みながらPodがNodeにBindされるまでを理解する - Qiita](https://qiita.com/everpeace/items/601dc613a0f424fb5619)
* [KubernetesのNode Affinity, Inter-Pod Affinityについて - Qiita](https://qiita.com/sheepland/items/ed12b3dc4a8f1df7c4ec)
* [KubernetesのTaintsとTolerationsについて - Qiita](https://qiita.com/sheepland/items/8fedae15e157c102757f)
* [Kubernetes: Kubernetes Descheduler とは - Qiita](https://qiita.com/tkusumi/items/7c5b2b958a7e4beaf5ee)

[^1]: 本記事では「VMware vSphere製品を用いて構成されるシステム基盤」を指して「VMware基盤」と呼称します（表現の正確性という観点からは「vSphere基盤」と呼称する方が適切ではありますが、分かり易さを重視しました）。
[^2]: Kubernetes v1.14でのFeature StateはBetaとなります（[Local ephemeral storage](https://qiita.com/drafts/6f92c91d7eba6b3de7bd/edit)）
[^3]: 管理対象とし得るリソース種別をPlug-inにより拡張する製品思想となっています（cf. [Extended resources](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)）。また、管理対象とし得るリソース種別を将来に向けて拡張するためのプランが存在します（cf.[The Kubernetes resource model](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/resources.md)）。
[^4]: Kubernetes基盤においては、CPUリソースの逼迫が生じた際に（VMware基盤における「シェア」を用いた運用のように）「requests]値の比をもって各コンテナへの余剰CPUリソースの割り当て比を決定します（cf. [Resource Quality of Service in Kubernetes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/resource-qos.md)）。なお、メモリ容量については類似した実装が提供されていないように見受けられます。
[^5]: 例えば、docker runコマンドにおける[--cpuset-cpus](https://docs.docker.com/engine/reference/run/#runtime-constraints-on-resources)制約を用いることにより、アフィニティ同様の実装を無理やり行うことが出来るかも知れませんが、未検証です。
[^6]: 各実装の概要が、[GRAPHICS ACCELERATION FOR VIEW VIRTUAL DESKTOPS IN HORIZON 7](https://techzone.vmware.com/sites/default/files/resource/graphics_acceleration_for_view_virtual_desktops_in_horizon_7.pdf)文書にまとめられています（VMware Horizon View製品向けのドキュメントですが...）。
[^7]: 具体的な実装例として、「[https://github.com/NVIDIA/k8s-device-plugin](https://github.com/NVIDIA/k8s-device-plugin)」や「[AMD GPU device plugin for Kubernetes](https://github.com/RadeonOpenCompute/k8s-device-plugin)」が挙げられます（cf. [Schedule GPUs - Kubernetes](https://kubernetes.io/docs/tasks/manage-gpus/scheduling-gpus/)）。
[^8]: ネットワークI/OやストレージI/Oを対象としたリソース管理が「Future resource types」とされているようです（cf. [The Kubernetes resource model](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/resources.md)）。
[^9]: [Vertical Pod Autoscaler機能](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler)は、本記事執筆時点においては未だベータ版相当であるという認識です。
[^10]: [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler)機能の使用のためには、機能に対応するクラウド基盤上にKubernetesクラスタを配置する必要があります。
[^11]: 具体的な一覧については、[製品文書](https://kubernetes.io/docs/concepts/policy/resource-quotas/)を参照願います。
[^12]: （表現が分り辛いのですが）リソース割り当てを委任された利用者が、「あるコンピュートインスタンス（コンテナや仮想マシン）」に割り当てることが出来るリソースの上限（や下限）を制限することを指します。
[^13]: 機能の具体的な内容については、製品文書（[CPU向け設定](https://kubernetes.io/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)、[メモリ向け設定](https://kubernetes.io/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)）を参照願います。
[^14]: vSphere基盤のセットアップ直後ではDRSクラスタ自体が存在しないことを「既定状態における無効化」として表現しています。
[^15]: Git文書「[Scheduler Algorithm in Kubernetes](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-scheduling/scheduler_algorithm.md)」の記述内容、および製品ソースコード「[least_requested.go](https://github.com/kubernetes/kubernetes/blob/b359b6bfe7e49ae7bbb9d21552d2a06bc55f8bc2/pkg/scheduler/algorithm/priorities/least_requested.go)」に基づく、本記事執筆者による認識を記述しています。
[^16]: 具体的な運用例として、ノードの可用性レベルに基づくコンテナ配置先の制御が挙げられます（例:重要な業務をサポートするコンテナを可用性が高いノード上に配置する）。
[^17]: 具体的な運用例として、互いに密に連携するコンテナを性能向上を目的として同一のノードに集中して配置することや、並列稼働するコンテナを可用性確保を目的として異なるコンテナに分散して配置することが挙げられます。
[^18]: 基盤リソースの逼迫に起因するコンテナの強制終了⇒再生成が繰り返された結果としてノード負荷が平準化されるケースは生じえます。しかしながら、それはあくまで副次的な事象であるため、「コンテナ配置の事後にノード負荷を自律的に平準化するための実装」をKubernetes基盤が備えているとは判断出来ない、というのが本記事の筆者の意見です。その上で、[kube-scheduler](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-scheduling/scheduler.md)がコンテナの自律的な配置に際して、ノード負荷状況（例:ノードに相当する各DockerホストのCPU使用率）への配慮を行わないことと合わせて考えると、コンテナの生成/廃棄が活発でない環境においては、クラスタを構成するノード間でリソース利用状況が偏る懸念があると認識しています。その一方で、ここで記述したようなKubernetes基盤の弱点を補うような機能拡張もプランされている模様です（cf. [Descheduler for Kubernetes](https://github.com/kubernetes-incubator/descheduler)）。
[^19]: Kubernetes製品ドキュメント上でも、利用者による混同を避けるための解説が行われています（cf. [Interactions of Pod priority and QoS](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/#interactions-of-pod-priority-and-qos)）。
[^20]: 本記事の執筆者が簡単に検索した結果を列挙したリストであるため、一覧としての網羅性が担保されたものではありません。