shibatch's journey

日々考えていることをつらつら書くだけです

マルチクラウドのKubernetesでVPAを導入した(メモ)

最近のお仕事の話をしたい。

GoogleKubernetesEngine(GKE)とOpenStack上のプライベートクラウド環境に垂直Podスケーリング(VPA)を入れました。

VPAはPodでのCPU / Memoryリソースでどのくらいリクエストするのが良いのかを測定してくれたり、自動的に調整してくれる機能ですね。

これがGKEとOpenStackでちょっと導入方法が違ったのがおもしろかったので書き留めです。(リソースの設定ファイルの内容は同じものでOK。)

なお、ふんわりした知識で導入しているので詳細は誤っているところもあるかもしれません:bow:

GKEでVPAをenableにする

ドキュメントが公開されているのでこの通りやればOK。 GKEだとgcloudコマンドでONにする、もしくはコンソール上からONにします。 (コントロールプレーンの再起動が走ります)

gcloud container clusters update <cluster name> --enable-vertical-pod-autoscaling

f:id:shibatch:20220321175002p:plain
コンソール

おおよそ5分くらいでVPAがONになりました。

gcloud container clusters describe <cluster name>
<snip>
verticalPodAutoscaling:
  enabled: true

GKEはコントロールプレーンにPodを配置しており、get pod のようなコマンドで確認は(自分の知る限り)できませんでした。

プライベートクラウド上のKubernetesクラスタでVPAをenableにする

こちらも手順は公開されているのでこの通りやればよいです。 AWS EKSでも手順が公開されてますがほぼ同様の手順でした。

リポジトリを取得して以下のコマンドを投入するだけ。これでpodが展開されてvpaが起動します。

./hack/vpa-up.sh

以下のエラーがでたのですが

ERROR: Failed to create CA certificate for self-signing. If the error is "unknown option -addext", update your openssl version or deploy VPA from the vpa-release-0.8 branch.
deployment.apps/vpa-admission-controller created

これはドキュメント内に対処方法が書いてあって、実行している端末のOpenSSHのバージョンを上げればよいです。 私はMacなのですがMacは純正のOpenSSHでないので純正のものをインストールして再度実行したらVPAが入りました。

shibatch@aa vertical-pod-autoscaler % k get pod -n kube-system | grep vpa
vpa-admission-controller-58cf99779c-bdwsv   1/1     Running     0          63m
vpa-recommender-678f4f6d4b-ttlp2            1/1     Running     0          63m
vpa-updater-64ddd67787-4bw7g                1/1     Running     0          63m

VPAをONにする

ここからは環境による差異はありあません。VPAのリソースをapplyします。リソース内で取得したいpodがあるdeploymentを指定します。

shibatch@aa  % cat vpa.yaml
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: hoge-vpa
  namespace: default
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: fuga
  updatePolicy:
    updateMode: "Off"
shibatch@aa  % k apply -f vpa.yaml
verticalpodautoscaler.autoscaling.k8s.io/hoge-vpa created

ここで updateMode: "Off"としています。つまりRecuestの推奨値は出すけれども自動でスケーリングするような動作はしない設定です。 VPAを導入する場合はまずはこの状態から初めて十分に検証できたら他のモードに移行することがベストプラクティスとされています。

しばらくすると取得されだします。

shibatch@PMAC952S production % k get vpa hoge-vpa
NAME        MODE   CPU    MEM          PROVIDED   AGE
hoge-vpa   Off    920m   9616998332   True       3m33s

describe vpa するとコンテナごとのRecuestを出してくれますね!

shibatch@PMAC952S ~ % k describe vpa hoge-vpa
Name:         hoge-vpa
Namespace:    default
<snip>
Status:
  Conditions:
    Last Transition Time:  2022-03-11T08:50:53Z
    Status:                False
    Type:                  LowConfidence
    Last Transition Time:  2022-03-11T08:50:53Z
    Status:                True
    Type:                  RecommendationProvided
  Recommendation:
    Container Recommendations:
      Container Name:  front
      Lower Bound:
        Cpu:     1m
        Memory:  9437184
      Target:
        Cpu:     2m
        Memory:  11534336
      Uncapped Target:
        Cpu:     2m
        Memory:  11534336
      Upper Bound:
        Cpu:           2m
        Memory:        12582912
      Container Name:  api
      Lower Bound:
        Cpu:     355m
        Memory:  6951010304
      Target:
        Cpu:     900m
        Memory:  8825864192
      Uncapped Target:
        Cpu:     900m
        Memory:  8825864192
      Upper Bound:
        Cpu:     1155m
        Memory:  9171894272
Events:          <none>

基本的にTarget の項目を参考にすればよさそう

HPA と VPAの組み合わせ

VPAと違うアプローチのスケーリングの概念として、水平ポッドスケーリング(HPA)があります。 こちらはリソースの使用状況をみてPodを増減する、横方向へのスケーリングですね。

これらは組み合わせて使うことは推奨されていないようです。 なんとなく理由はわかりますね。HPAでPodが増減すると使われるリソースが増減するので適切な設定値にならない恐れがあるんだと思います。 ただ、前述したupdateMode: "Off" の設定だとOK。私はHPAも活用しているのでこのモードで動かして、リソースの推奨値がでたらRecuestを変更する形にします。 これでもあてずっぽで設定するようなRecuestより幾分無駄がないはずです。


こんな感じで手探りしつつVPAを導入しました〜 最近やっとKubernetes触ってて楽しいと思えるようになってきた。いいことだ。

このHPA / VPAのスケーリングの概念ってとっても大事だと思うんだけどCKA受験したときはまったく範囲ではなかったと思う。重要な概念だと思うので試験範囲に含めてよいと思うけどなぁ。