Kekeの日記

エンジニア、読書なんでも

KubernetesのResource Request、LimitとHorizontal Pod Autoscalerについて

f:id:bobchan1915:20181001203926p:plain

動機

KubernetesでPod間通信をしたときに、レスポンスタイムがスパイクするような現象に遭遇しました。

アプリケーション側のコードには問題がなさそうで、Kubernetes上でホストしていてCPUなどリソースが怪しいのではないかという予測しています。

今回はResourceに関わる二つの設定項目RequestLimitについて調査します。

また、同時にHorizonatal Pod Autoscalerも調べました。

目次

Resource

Request

Podをデプロイ時に必要なリソース(CPU or メモリ)を指定することができる仕組みです。

注意点

  • PodはResource Requestした以上のリソースを使うことができる。
  • Podのデプロイ時にはNodeの総Pod Resource Requestをみて、デプロイできるかできないか決める
新PodのResource Request < NodeにあるPodの総Resource Request

ならばデプロイされる。このためNodeのリソースが100%使われていても総Resource Requestに空きがあればデプロイされる

Limits

Podが使うリソースの上限を設けられる仕組みである

注意点

  • Nodeのリソースに空きがあっても使うことはできない。
  • Resource Requestが指定されていないとResouce Request = Resource Limitである。
  • Nodeのリソース以上に配分することができる。

リソースの指定方法

CPU

CPUは1000m=1vCPUである。

またmをつけなければ1 = 1vCPUという計算になる。

メモリ

Mi, Kなどいろんな単位があるので、そちらを参照してください。

リソースが越えると......

ランタイム中にリソースが越えると以下のようなことが起きる。

CPU

CPUの場合は処理に時間がかかってしまうが、何も起きずREADYのままである。

しかし、私たちのパソコンが重い作業をするとカタカタするように、処理速度(Process Time)に大きく影響する。

メモリ

メモリが不足するとOut of Memory(OOM)としてプロセスをKissして、コンテナが消滅します。

STATUSCrashLoopBackOffになり、Exponential backoffアルゴリズムにしたがって、再起動のサイクルは遅くなる。

Horizontal Pod Autoscaler(HPA)

概要

リソースの使用量によってPodの数を自動的に変更する仕組みです。

仕組み

デフォルトでは30秒に一回、メトリクスを取得します。

以下のフラグで変更することができます。

--horizontal-pod-autoscaler-sync-period

複数のメトリクスでHPA

autoscaling/v2beta2を使うことによって複数のメトリクスを使うことができます。

設定方法

name: hogeのように`Deploymentに名前で指定する。

scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: hoge
metrics:
  - type: Resource
    resource:
      name: cpu
      target:
           type: Utilization
           targetAverageUtilization: 50

typeの種類

以下のような種類があります。

type 内容
Resource CPU/メモリのリソース
Object Kubernetesオブジェクトのリソース
Pods Podのメトリクス
External Kubernetes外のメトリクス

CPU以外のリソースはPrometheusなどの他のメトリクスサーバーと連携するため、別途設定をしないといけない。

デバックする

以下のコマンドでクラスタに設定されてあるHorizontal Pod Autoscalerを見ることができます。

kubectl get hpa

NAME      REFERENCE           TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
hoge    Deployment/hoge   0%/50%    1         5         1          5h

ベストプラクティス

Nodeをアプリケーションから保護する

以下の項目より、あらかじめシステム様にCPUを保護するとアプリケーションに全CPUソースを取られることがなくなる。

--kube-reserved="cpu=100m,memory=100Mi,ephemeral-storage=1Gi"
--system-reserved="cpu=100m,memory=100Mi,ephemeral-storage=1Gi"

LimitsRangeを活用する

LimitRangeを活用するとNamespaceごとにCPU/メモリのリソースの最小値、最大値、デフォルトの値などを設定することができます。

これはPodを作成するときに有効化するので、既存のデプロイされたものには適用されませんので注意してください。

まとめ

リソースをチェックすると以下のようになっていました。

f:id:bobchan1915:20181001203819p:plain

これだとNodeは動作速度が遅くなるし、大変です。

改善できるところを見つけて、どんどんやっていこうと思います。