Google Container Engineに移行したその5 オートスケール

Gke

　Google Container Engineでオートスケールの設定をしてみます。

1 前回までのGKE
2 GKEのオートスケールの動き
3 ポッドの設定
4 Kubernetesのオートスケール設定
5 インスタンスグループの設定
6 Podのリソースに制限を入れている理由
7 これで通常運用できるようになったかな

前回までのGKE

　前回はGoogle Container Engine(GKE)でnginx + PHP-FPMでWordPressのコンテナを作成しました。

Google Container Engineに移行したその4 | A-tak-dot-com

　今回は、負荷が上がってきたときに自動でポッドを追加し、さらにノード(VM)も増やしていく設定を行います。

GKEのオートスケールの動き

　以下のような動きになる。

PodのCPU使用率が上がる
Kubernetesのオートスケール機構によりPodのレプリカが作成され複数のPodができる
ノードの負荷が上がるとGCEのオートスケール機能で新たなインスタンスが立ち上がる
Kubernetesが新たなインスタンスにもPodを作りはじめる

というような感じ。

ポッドの設定

　前回の記事のPodを作成するyamlファイルを少し変更しています。containersのところだけ抜きだします。すべての設定は前回の記事参照してください。

Google Container Engineに移行したその4 | A-tak-dot-com

[yaml]
containers:
–
name: "nginx"
image: "asia.gcr.io/my-project99/nginx:v21"
resources:
limits:
cpu: 100m
requests:
cpu: 100m
ports:
–
containerPort: 80
volumeMounts:
– name: www
mountPath: "/var/contents"
–
name: "php-fpm"
image: "asia.gcr.io/my-project99/php-fpm:v3"
resources:
limits:
cpu: 300m
requests:
cpu: 100m
ports:
–
containerPort: 9000
volumeMounts:
– name: www
mountPath: "/var/contents"
[/yaml]

　追加したのは「resources:」です。その中で「limit」と「requests」を指定しています。

　limitsはコンテナが最大どれだけそのノードのリソースを使えるかを指定するものです。「cpu: 300m」となっているのは最大30%のCPUを使用するという指定になります。1000mで100%ということになりますね。

　requestsはPodを立ち上げる時に初期で必要なリソースです。「cpu:100m」だとCPU使用率の空きが最低でも10%はないと、そのノードでPodが立ち上がらなくなります。既にCPU使用率95%とかになっていると、他に空いているノードがあれば、そこでPodが起動します。

イマイチこのあたりがよくわからなかったのですが、こちらの記事がだいぶ参考になりました。

Kubernetesのポッドが起動しない原因と対策 – Qiita

　これらの制限を入れていないとPodはノードのリソースをすべてフルに使います。それでもいいんですが、効率よく負荷分散するには設定しておくべきかなと思います。理由は一通りこの後の説明した後に書きますね。

　lmitにどの程度のリソースを割り振るかは試行錯誤ですね。私はg1-smallのインスタンスを使っていますが、とりあえず上記の設定で問題なく動いています。

　設定した内容は、以下のコマンドで確認できます。

[bash]
kubectl describe nodes [インスタンス名]
[/bash]

結果の中に以下のような行があってここで設定が確認できます。

[bash]
Namespace Name CPU Requests CPU Limits
default web-rc-06-2r1ml 200m (20%) 400m (40%)
[/bash]

NameのところにPodの名前が出ています。先ほどのPodにはコンテナが二つあってそれぞれRequestsは100mずつなので、合計した200mが表示されています。本当はメモリの制限値も出ているのですが、省略しています。

Kubernetesのオートスケール設定

　以下のコマンドでオートスケールの設定が出来ます。

[bash]
kubectl autoscale rc [レプリケーションコントローラーの名前] –min=1 –max=10 –cpu-percent=80
[/bash]

　この設定だとPodのCPU使用率が80%を超えたら新たなPodが立ち上がり、最大10個のPodが作成されます。

インスタンスグループの設定

　ノードの負荷が上がると新しいインスタンスが立ち上がると書きましたが、この部分はGoogle Compute Engine(GCE)のインスタンスグループの機能を使って実現します。

　GCEのオートスケールについては以下に書きました。

お名前．ｃｏｍ VPSからGoogle Compute Engineにサーバー移行したその3 | A-tak-dot-com

　ただ、今回は「インスタンステンプレート」や「インスタンスグループ」はGKEでクラスタを作成したときに自動で作成されています。Google Developer Consoleでインスタンスグループを開くと、「gke-xxxxx」というようなモノがあるはずです。

　このインスタンスグループを編集して、「自動スケーリング」を「オン」にして「インスタンスの最大数」を指定すれば、ノードのオートスケールの設定は完了です。

　ちなみに「自動修復」の「ヘルスチェック」は「しない」のままにしておかないといけないようです。「する」にするとなぜかヘルスチェックに失敗して自動修復が走り始めノードが再起動を繰り返して全滅します😅

　そもそもKubernetesのServiceが生きているノードに通信を送るように制御してくれるので、インスタンスグループでヘルスチェックを設定する必要はなさそうです。

　これでGKEでオートスケールが動作するようになります。

Podのリソースに制限を入れている理由

　冒頭のPodのリソース制限を入れた方が負荷分散が適切に動作すると書きましたが、理由を表す図を書いてみました。

うまく負荷分散

　左がPodのリソース制限をかけない場合です。

　こうすると、たとえインスタンスグループの機能により新たなノードが立ち上がったとしても、Podは今のノードのリソースを使い切るまで新たなノードにPodを作成しません。最初のノードで頑張り続けるんですね。頑張って処理できてるならいいや、という考えもありますが、新たにノードが立ち上がっているのにもかかわらず、なかなかそのノードが使われない状態というのは、もったいない気がしますね。

　右がPodのリソース制限を加えた場合です。

　この場合、ノードのリソースをある程度消費した段階(=Podに設定した値に近づくと)で新たなPodが起動します。このとき新たなノードが立ち上がっていれば、そちらにPodが配置されます。最初の例よりもいい感じに各ノードに負荷が分散することが期待できます。図ではノードの半分のリソースを余らせているように見えますが、もちろんもっと負荷が上がれば残りの分のリソースも別のPodが作成されたときに使用されますよ。