KubernetesのCPU／メモリ要求はContainerSpecのresourcesで指定できます。
resourcesの指定方法により、Guaranteed, Burstable, BestEffortのQoSクラスが指定されます。
リソースが逼迫してくると、BestErrort, Burstable, Guaranteedの順にkillされる挙動となります。
QoSクラスはkubectl describeコマンドでPodを確認すると表示されます。
BestEffortの指定方法
BestEffortは、resourcesを指定しない場合のQoSクラスです。
要求リソースが0になり、他のコンテナ配備に影響を与えない挙動になります。
高負荷時に停止しても問題ないコンテナを特定できていれば、BestEffort（リソース要求なし）を活用できます。
Guaranteedの指定方法
Guaranteedは、CPUとメモリにつきresources.requestsとresources.limitsの値を一致させて指定することで設定できます。
実務的には、以下のようにresources.limitsのみ指定する方法が明確でしょう。resources.requestsを省略するとlimitsと同じ指定になります。
spec:
containers:
- name: some-container
resources:
limits:
cpu: 100m
memory: 100Mi
cpuとmemoryは両方指定が必要で、マルチコンテナの場合には、全コンテナに指定が必要です。
当然ですがlimits.cpuはCPU割り当て時間をハードに制限するため、小さい値をセットすると性能劣化します。
一方で大きな値を指定するとデプロイ可能な他コンテナを制約するため、使いづらい面があります。
limits.memoryについてはその全てを排他的に確保するわけではないため、安全を考慮して多少大きい値を指定することになるでしょう。
Burstableの指定方法
Burstableクラスについては、ポイントはあまりありません。
resourcesの4つの指定方法のうち、一部を指定するとBurstableになります。
QoSの観点では、BestEffortよりも優先的に保護する意図で何かリソース要求しておく、という使い方になるでしょう。
たとえばlimits.cpuを指定しない場合、CPUに空きがあれば集中的に動作する挙動になります。
また、ガベージコレクタのある言語でメモリ要求が読めないコンテナもlimits.memoryを指定しづらいケースが多くあります。
Guaranteedのための要求値がうまく定まらないケースでは、BestEffortとBurstableの分類にとどめるのが現実的なのでしょう。
実利用しているリソースはkubectl top podコマンドで確認できます。ただし、ある時点の値でしかない点など注意が必要です。
