legacyシステムからGoogle Cloudへの道のり
GYAOのtsです。
我々のチームは、オールパブリッククラウドで、Microservice Architectureを採用した次期バックエンドを設計中です。

経緯

　
前回の投稿ではいろいろあって若干表現を変えました。

　
　
　
さて、前回の投稿でkube-uiとAuto scaleについて触れたのだが、どうやら現在(2017/3/17)はkubernetes-dashboardと名前が変わっているらしい。
改めてkubernetes-dashboardとAuto scaleについてまとめてみることにする。

kubernetes-dashboard

まずはdashboard、前回の投稿でnginxが入ったpodを4つにスケールアウトしたが、その続きから。

まず、dashboardの表示方法だが、私の知っている方法は2通りある。

kubectl proxyを使用してローカルマシン上でproxyをたてて表示。
GKEのkubernetes masterに直アクセスで表示。

まずは１のパターンから。
GKEのコンソールで「クラスタに接続」をクリックすると何をすればいいかすべてが表示される。

kubectlがローカルマシンに入っていないといけないが、インストールは上記画面のkubectlのリンクから辿れる。

書いてあるとおりに打ってproxyを立ち上げたら http://localhost:8001/ui にアクセスして完了。

2のパターン。

GKEのコンソールでエンドポイントを確認する。（下図の赤枠）

https://[エンドポイント]/ui

にアクセス。basic認証がかかっているので、GKEコンソールの「認証情報を表示」(上図の赤枠内)で表示されるuser、passwordを入力。

アクセス完了。各種情報の閲覧はもとより、yamlのuploadまでできる。

Auto scale

続いてチーム内でも関心の高いAuto scaleだが、せっかく上述でdashboardを立ち上げたので、podのスケール状況をみながら進めていくことにする。

まずは現在のpodの状況

kubectl scale rc nginx --replicas=4

で4podsにスケールアウトしたが、しばらく時間が経過したのでもとに戻っている。

それではAuto scale設定。
今回はわかりやすいようにpodの消費するcpuが1%を超えたらスケールアウトするように設定する。
クラウドシェルで以下のように設定。

kubectl autoscale rc nginx --min=2 --max=10  --cpu-percent=1

pod数2〜10でスケールアウトするように設定。

実際に負荷をかけてみる今回はApache Benchを使ってローカルのマシンからnginxのwelcomeページに負荷をかけてみる。

ab -n 3000 -c 2000 http://[serviceのip]/

すると

podが2個ふえた。

当然だが、しばらくアクセスしないとまたもとに戻る。まぁ便利。

所感

StatefulSetsの件（前回の投稿参照）はあるが、例えばプレ層とAPIをコンテナ化して、１つのpodにまとめると相当運用楽でしょうね。もともとそういう使い方を想定しているでしょうし。loggingはCloudLoggingでまとめられるし、それをBigQueryにもワンタッチでexportできる。痒いところに手が届いてますね。自分たちでこういったインフラを作る意味を全く感じさせません。我々のチームも有効に利用して大きな成果を上げていこうと思います。