この記事はGoogle Cloud Platform Advent Calender 2015の12月5日分の記事です
皆さんこんばんは。
Google Container Engine(GKE)使ってますか！？
と、いろいろなところで聞いていますが全く手が上がりません。
しかし、使いはじめると必ず「あれ？GKEとHTTP LB連携ってどうやって使うんだ？」という疑問が出てくることでしょう。今回はその先取りです。
というわけで、今回はGKEでHTTP Load Balancer(HTTP LB)を使う方法についてステップバイステップで解説していきたいと思います。
ただし、ここらへんはバージョンアップがとても早いので、常に最新の文章を見るようにしてください。
そもそも[GKE|HTTP LB]って？
GKEは、簡単に言ってしまえば、マネージドなKubernetesを提供するGoogle Cloud Platform(GCP)のサービス群の1つのことです。今回はKubernetesについての解説はしません。（それだけで5記事ぐらい書けそう）
HTTP LBは、GCPで提供されているロードバランサーのサービスの1つです。GCPにはNetwork Load BalancerとHTTP Load Balancerがあります。Network LBはL4, HTTP LBはL7で動いています。
HTTP LBはとても強力な機能をいくつか持っており、それらに関してはここらへんが詳しいです。
GKEでHTTP LBを使いたいと思うモチベーション
私の場合、そのモチベーションは2つほどありました。
HTTPS、HTTP/2対応
HTTP LBには、HTTPSをHTTPになおして下流に流したり、HTTP/2をHTTP/1.1になおして下流に流したりという機能があり、しかも特別に設定することといえば証明書ぐらいです。特にHTTP/2は、これだけでは本当の意味で対応したとは言いがたいですが、やる価値はあるでしょう。
Content-based Load Balancingを使いたい
GCPではUrlMapと呼ばれるリソースを設定すると、どのパスでアクセスされたら、どのBackend Serviceを利用するか、ということが設定できます。
例えば、http://example.com/api/*アクセスしたら、APIを提供しているバックエンド、http://example.com/admin/*だったら内部用のバックエンド、それ以外(http://example.com/*)だったらフロントエンド用のバックエンド、といった具合です。
この要領で、このURLだったらこのpodにアクセスする、というようにLBを使いたくなります。特に、Microserviceな感じでサービスを作成する場合、かなり便利です。
GKEとHTTP LBを連携させてみる
前提条件
今回は、3つのGCEインスタンスでクラスタを組み、podはReplication Controllerで作成・管理する想定です。
今回使用するReplication ControllerとServiceを設定するファイルはこのような感じです。
apiVersion: v1
kind: ReplicationController
metadata:
name: frontend
labels:
name: frontend
spec:
replicas: 3
selector:
name: frontend
template:
metadata:
labels:
name: frontend
spec:
containers:
- name: frontend
image: asia.gcr.io/project/frontend
ports:
- containerPort: 80
protocol: TCP
apiVersion: v1
kind: Service
metadata:
name: frontend
labels:
name: frontend
spec:
ports:
port: 8000
targetPort 80
protocol: TCP
nodePort: 30062
type: NodePort
selector:
name: frontend
そして、作成するクラスタ名やどこのゾーンに作るかなどは環境変数に入れておきます。
$ export CLUSTER_NAME="kuma-project"
$ export ZONE="asia-east1-a"
また、gcloudなどは予め使えるようにしておきましょう。
ここを読めば詳細がわかりますが、LinuxやMacだと、基本的には
$ curl https://sdk.cloud.google.com | bash
でセットアップが終わるかと思います。
1: クラスタを作成する
$ gcloud container clusters create $CLUSTER_NAME --zone $ZONE
2: Replication ControllerとServiceを作成する
$ kubectl create -f frontend-replication-controller.yml
$ kubectl create -f frontend-service.yml
ちゃんとそれぞれ作成されたか確認して見ましょう。
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
frontend-xxxxx 1/1 Running 0 1m
frontend-yyyyy 1/1 Running 0 1m
frontend-zzzzz 1/1 Running 0 1m
$ kubectl get services
NAME CLUSTER_IP EXTERNAL_IP PORT(S) SELECTOR AGE
frontend 10.xx.xx.xx nodes 8000/TCP name=frontend 1m
kubernetes 10.xx.xx.xx <none> 443/TCP <none> 3m
3: HTTP healthcheckを作成する
HTTP LB用に、今回作ったpodsのhealthcheckの設定を作成します
$ gcloud compute http-health-checks create http-basic-check-30062 --port 30062
ポートはfrontend-service.ymlでしているnodeportである30062を指定します。
3.5:クラスターのtagとグループ名を確認する
クラスタが組まれたら、そのクラスタには特有のtagと、自動的にインスタンスグループが作成されています。それらの名前を調べて環境変数に入れておきましょう。GUIでも見れますが、コマンドでも簡単にできます。
$ export TAG=$(basename `gcloud container clusters describe ${CLUSTER_NAME} --zone ${ZONE} | grep gke | awk '{print $2}'` | sed -e s/group/node/)
$ export GROUP_NAME=$(basename `gcloud container clusters describe $CLUSTER_NAME --zone $ZONE | grep gke | awk '{print $2}'`)
4: ファイアーウォールのルールを作成する
LBがアクセスできるようにファイアーウォールのルールを作成しましょう
$ gcloud compute firewall-rules create frontend-pods-30062 --source-ranges 130.211.0.0/22 --allow=tcp:30062 --target-tags $TAG
5: インスタンスグループにNamed Port追加する
$ gcloud compute instance-groups managed set-named-ports $GROUP_NAME --named-ports http:30062 --zone $ZONE
6: インスタンスグループをバックエンドサービスとしてLB
に登録する
gcloud compute backend-services create web-map-backend-service --protocol HTTP --port-name http --http-health-check http-basic-check-30062
今回、frontendはHTTPSの対応はしていないのでプロトコルはHTTPを選択します。また、ヘルスチェックを行う設定は、3で作ったものを指定します。
7: 登録したバックエンドサービスを使用可能にする
gcloud compute backend-services add-backend web-map-backend-service --balancing-mode UTILIZATION --max-utilization 0.8 --capacity-scaler 1 --instance-group $GROUP_NAME --zone $ZONE
8: UrlMapを作成する
$ gcloud compute url-maps create web-map --default-service web-map-backend-service
今回はバックエンドサービスはこれしか登録しないため、上記のようになりますが、バックエンドサービスが複数ある場合は適所登録してください。
9: LBのプロキシを作成する
$ gcloud compute target-http-proxies create http-lb-proxy --url-map web-map
10: 作成したプロキシに対してフォワードルールを作成する
$ gcloud compute forwarding-rules create http-content-rule --global --target-http-proxy http-lb-proxy --port-range 80
まとめ
いかがだったでしょうか。おそらく、HTTP LB、GKEとの組み合わせになるため、それぞれを多少使ってみないとイメージがつかないかもしれませんが、これらを組み合わせることで、特にMicroserviceな構成のサービスは格段に作りやすく、管理・運用・拡張性が高いものになるかと思います。
もしかしたら、手順5からはGUI（マネジメントコンソール）で行ったほうがイメージが付くかもしれません。要望があれば、そちらの方も作成したいかと思います。