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できる。痒いところに手が届いてますね。自分たちでこういったインフラを作る意味を全く感じさせません。我々のチームも有効に利用して大きな成果を上げていこうと思います。