最近のお仕事の話をしたい。
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
おおよそ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受験したときはまったく範囲ではなかったと思う。重要な概念だと思うので試験範囲に含めてよいと思うけどなぁ。