カテゴリー
サイト構築

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

Gke

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

前回までのGKE

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

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

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

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

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

  1. PodのCPU使用率が上がる
  2. Kubernetesのオートスケール機構によりPodのレプリカが作成され複数のPodができる
  3. ノードの負荷が上がるとGCEのオートスケール機能で新たなインスタンスが立ち上がる
  4. 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のオートスケールについては以下に書きました。

お名前.com 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が作成されたときに使用されますよ。

これで通常運用できるようになったかな

 これで、GKEでWordPressがまともに動くようになりました。まぁ、まだセッションが共有されていないっぽいとか問題はありますが、いったんはこれで運用できるようになったかな。

 
 

この記事を書いた人: A-tak

A-tak.com(えいたっく どっとこむ)の管理人。
Apple野郎なおっさんでしたが、ちょっと最近のAppleには飽き気味。
A-tak.comは2002年2月から運営(前身のサイトは1999年3月から)。今年で18年目!

Twitter
Mastodon
Facebook

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA


このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください