結局requestsとlimitsはどう設定すればいいのか

Slide 1

Slide 1 text

結局requestsとlimitsはどう設定すればいいのか Kubernetes Novice Tokyo #16 2022/02/15

Slide 2

Slide 2 text

自己紹介 Saino - 某Web系企業にて昨年10月からSRE担当の新卒一年目 - WebメディアのKubernetes(GKE)運用が主な業務 - Kubernetes歴 = インフラ歴は4ヶ月 - 先月CKADを取得

Slide 3

Slide 3 text

- Podのリソース設定という基本的な内容を題材に、 - Kubernetes初学者である自分が難しさを感じた部分と - 設定する際に考慮すべきポイントについてお話しします。本日は...

Slide 4

Slide 4 text

1. そもそもrequestsとlimitsとは何か 2. requestsとlimitsの何が難しいのか 3. 結局requestsとlimitsはどう設定すればいいのか今日お話すること

Slide 5

Slide 5 text

そもそもrequestsとlimits とは何か Kubernetes Novice Tokyo #16

Slide 6

Slide 6 text

- どちらもPodに割り当てるリソース量を設定するパラメータ - Podのspec.containers[].resources以下でコンテナごとに設定。 - それぞれcpuとmemoryについて設定できる。 requestsとlimitsとは spec: … containers: … resources: requests: cpu: 50m memory: 300Mi limits: cpu: 200m memory: 500Mi

Slide 7

Slide 7 text

requestsとは - Podが使用できることを保証される最低のリソース量。 - Podはrequestしたリソース分の空きがあるNodeにスケジュールされる。 - どのnodeにもrequests分の空きがない場合、Podはスケジュールされず、 Pending状態になる。 spec: … containers: … resources: requests: cpu: 50m memory: 300Mi limits: cpu: 200m memory: 500Mi

Slide 8

Slide 8 text

limitsとは - Podが使用できる最大のリソース量(Nodeのリソースに空きがあれば)。 - limitsを超えてリソースを使うことはできない。 - memory.limitsを越えればOOM KilledされPodは強制終了する。 - cpu.limitsに達するとthrottleが発生する。 - 設定しなければrequests = limitsになる。 spec: … containers: … resources: requests: cpu: 50m memory: 300Mi limits: cpu: 200m memory: 500Mi

Slide 9

Slide 9 text

requestsとlimitsの何が難しいのか Kubernetes Novice Tokyo #16

Slide 10

Slide 10 text

1. 様々な要素を複合的に考慮して設定する必要がある。 2. 「ちょうど良い値」を設定しなければならない。 requestsとlimits設定の何が難しいのか

Slide 11

Slide 11 text

1. 様々な要素を複合的に考慮して設定する必要がある。

Slide 12

Slide 12 text

requests, limitsに関係する様々な要素 - リソース設定の際にはPod以外についても考慮しなければならない。例えば、、、 - オートスケールを実装する仕組みであるHPA, VPA (水平, 垂直オートスケーラ) は、「requestsの値に対する実際の使用率の比」を閾値に用いる。 - HPA, VPAを使う場合、requestsの意味合いが増える。 https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/

Slide 13

Slide 13 text

1. 様々な複合的要素を考慮する必要がある　環境で用いる様々なk8sリソースへの影響を考慮して設定しなければならない。 - HPAやVPA (水平, 垂直オートスケーラ) 　　→requestsの値を元にオートスケールの閾値を決定する。 - QoS (Podの優先度) 　　→requests < limitsであるほど低優先度のPodになる。 - ノードオートスケーラ(GKEなどマネージドk8sの実装) →どのノードにもrequests分の空きがない時、ノード自体が増える。

Slide 14

Slide 14 text

2. 「ちょうど良い値」を　設定しなければならない。

Slide 15

Slide 15 text

- そもそもリソース調整とは「小さすぎるとパフォーマンスに響くし、大きすぎてもコストがかさむ」という中で「ちょうど良い値」を選ぶもの。 - もちろんパフォーマンスを下げてはいけないので、たっぷりとリソースを確保しておきたいが、 - 実際には「ちょうど良い」リソース量を設定して、コストとパフォーマンスの両立を叶えたいところ。 2. 大きすぎず小さすぎない「ちょうど良い値」

Slide 16

Slide 16 text

結局requestsとlimitsはどう設定すればいいのか Kubernetes Novice Tokyo #16

Slide 17

Slide 17 text

1. 様々な要素を複合的に考慮して設定する必要がある。 2. 「ちょうど良い値」を設定しなければならない。 requestsとlimitsはどう設定すればいいのか

Slide 18

Slide 18 text

1. 様々な要素を複合的に考慮して設定する必要がある。 2. 「ちょうど良い値」を設定しなければならない。 requestsとlimitsはどう設定すればいいのか

Slide 19

Slide 19 text

1. 様々な要素を複合的に考慮して設定する必要がある。 2. 「ちょうど良い値」を設定しなければならない。 requestsとlimitsはどう設定すればいいのか 1. については学習と慣れで解決するのみ😇 自分の環境ではなにを考慮してrequests, limitsを設定する必要があるか把握すること。

Slide 20

Slide 20 text

1. 様々な要素を複合的に考慮して設定する必要がある。 2. 「ちょうど良い値」を設定しなければならない。 requestsとlimitsはどう設定すればいいのか

Slide 21

Slide 21 text

- 負荷試験...? テストシナリオを用意して負荷試験を行い、予め想定負荷に耐えられるよう適当な値を算出する → 負荷試験と実際のユーザの動きは異なるものの、一定有効。 - 実際のリソース使用量のメトリクスを見る。「足りないか、足りているか」は分かるが、いくつに設定すればいいか？をどう決めるか。経験や勘に頼りがち。 →唯一解を探すよりチームとしてノウハウが溜まっているかが大事。「ちょうど良い値」をどうやって知るか

Slide 22

Slide 22 text

1. 様々な要素を複合的に考慮して設定する必要がある。 2. 「ちょうど良い値」を設定しなければならない。 →スケールとともに「ちょうど良い値」も変わる。 requestsとlimitsはどう設定すればいいのか

Slide 23

Slide 23 text

- 一方で「ちょうどいい値」はスケールとともに変化するもの。 - 負荷が増大すれば「ちょうどいい値」も大きくなる。 - 実際弊社でもリリース当初は負荷試験で決めた値をrequests, limitsに設定していたが、サービスのスケールととも少しずつ足したり、試験時の想定ほど使わなかった分を減らしたりと、気がつけば手動で変更する運用になっていた。 →俗人的な運用に😇 「ちょうど良い値」をどうやって知るか

Slide 24

Slide 24 text

- 負荷増大のタイミング、規模が事前に分かっている場合決まった時刻に何かを公開する場合や、サービスがテレビの取材を受け放送時刻にアクセス増加が見込まれる場合など。 →想定負荷に応じて事前にリソースを増やしておくスケジュールドスケーリングで対応。スケールとともに変わる「ちょうど良い値」

Slide 25

Slide 25 text

- 負荷増大のタイミング、規模が事前に分からない場合。 ①長期的な負荷増加への対応(サービスのグロースなど) 　レイテンシの閾値でエラーバジェットを設定するなどし、チームで定期的なリソース使用量の振り返りや負荷試験の機会を設けることで俗人性を排除。 ②短期的な負荷増加への対応(いわゆるスパイク) 　VPA, HPAなど水平or垂直オートスケーリングで対応。　※それでもコンテナの起動より速い急激なスパイクには対応できない。スケールとともに変わる「ちょうど良い値」

Slide 26

Slide 26 text

HPA, VPAを用いる場合の「ちょうどいい値」 - HPA, VPAを使う場合も「ちょうどいい値」の意味が変わる。 - HPAを用いた場合、Pod数という意味では動的にリソースを調整する仕組みがあるものの、requests, limits自体は固定値のまま。 →まず単一のPodで理想的なパフォーマンスを出せるか？(Novice Tokyo#5) - VPAを用いた場合、動的にリソース量の書き換えをしてはくれるものの、HPAと併用できない。 →サービス特性に合わせた選択を。

Slide 27

Slide 27 text

最後に - requests, limitsだけでパフォーマンスの問題を解決するものでもない。 - K8s単位で言えばnodeSelectorやtopoloogySpreadConstraintsなどを利用し、処理に合わせた適切なノードを選択するスケジューリング制御も有効。 - アプリケーション側の実装やサービス特性まで広く視点を持つことが重要。

Slide 28

Slide 28 text

ご清聴ありがとうございました皆さんのベストプラクティスを是非コメントで教えてください！