KubernetesのHPAとService — 増えても入れ替わっても、窓口は1つ
Kubernetesは、宣言した数のPodを動かし続ける現場監督でした。では、アクセスが急に増えたら? 新しいバージョンに入れ替えるときは? このページでは、Podの数が変わっても、中身が入れ替わっても、利用者からは何も変わらずに見える仕組みを見ていきます。
主役は2つです。負荷を見てPodの数を自動で増減させる HPAと、入れ替わり続けるPodの前に立つ変わらない窓口 Service。まず図1で、アクセス数のスライダーを動かしてみてください。
HPAがやっているのは、1行の割り算
HPA(Horizontal Pod Autoscaler)は、15秒ごとにPodのCPU使用率を集めて、図1の下に出ている1行の式を計算しているだけです。
必要なPod数 = 今のPod数 × (今の平均CPU ÷ 目標CPU)。3台で平均90%なら、目標50%に下げるには 3 × 90 ÷ 50 = 5.4 で、切り上げて6台。台数を増やせば1台あたりの負担が減る、という当たり前の比例計算です。
ただし、新しいPodは起動してすぐには仕事ができません。「⚡ 急にアクセスが殺到」を押すと、Podが増えるまでの数十秒は応答が遅くなるのが分かります。HPAは後追いなので、一瞬で跳ね上がる負荷には最低台数(minReplicas)を多めにしておく、といった備えを組み合わせます。
逆に、アクセスが減ってもすぐには減らしません。減らした直後にまた増えると、起動待ちの間に遅くなってしまうからです。標準では5分間の最大値を見て、それより下がってから減らします。
Service — 入れ替わるPodの前に立つ、変わらない窓口
図1でPodが増えたり減ったりしても、Serviceの住所 10.96.0.10 は一度も変わりませんでした。Podは作り直されるたびにIPアドレスが変わるので、利用者が直接Podを指していたら困ります。そこでServiceが「いま受付できるPodの一覧(エンドポイント)」を持ち、届いたリクエストをそこへ振り分けます。
この一覧に載るのは、準備完了(Ready)と判定されたPodだけです。判定には readinessProbe(準備できたかの定期確認)を使います。これが効いてくるのが、新しいバージョンへの入れ替え、ローリングアップデートです。図2で1手ずつ進めてください。
- HPA
- Horizontal Pod Autoscaler。CPU使用率などを見て、Podの数を自動で増減させる仕組み。
- 目標CPU
- HPAに「平均でこのくらいにしておいて」と渡す値。余裕を残すため50〜70%にすることが多い。
- Service
- 入れ替わるPodの前に置く、変わらない名前とIPアドレス。届いたリクエストをPodへ振り分ける。
- エンドポイント
- Serviceがいま振り分けてよいPodの一覧。Ready のPodだけが載る。
- readinessProbe
- 「リクエストを受けられる状態か」を定期的に確かめる設定。通るまで一覧に載らない。
- maxSurge
- ローリングアップデート中に、宣言した数より何台まで多く動かしてよいか。図2では1。
まとめ
HPAは「今の台数 × 今のCPU ÷ 目標CPU」で必要な台数を計算し、増やすのはすぐ、減らすのは様子を見てから行います。Serviceは変わらない住所を持ち、準備できたPodだけを一覧に載せて振り分けます。Podが増えても入れ替わっても利用者に何も見えないのは、数を合わせる係と、窓口の係が分かれているからです。