Ingressの作成
次にIngressを作成します。Ingressにより、Webアプリケーションが外部に公開されるようになります。
このIngressでは先ほど作成したServiceを指定します。
Static-IPを予約
Ingressを作成する前に固定IPアドレスを予約しましょう。IngressはIPを指定しないで作成すると毎回ランダムなIPが振られてしまいます。これではIPにドメインを振っていた場合等で都合が悪いです。そのため静的なIPを予約して、それをIngressのIPとして使う設定にしましょう。
gcloudのコマンドでIPを予約
gcloudコマンドで固定IPアドレスを予約します。Google Cloud Platformの固定IPアドレスには2つのタイプがありますが、今回予約するIPのタイプはグローバルを指定します。
$ gcloud compute addresses create test-ip --global
Created [https://www.googleapis.com/compute/v1/projects/{my-project}/global/addresses/test-ip].
このコマンドが完了したら、実際に固定IPアドレスが予約されたかを確認します。予約しただけなので、STATUSはRESERVEDになってるはずです。
$ gcloud compute addresses list --global NAME REGION ADDRESS STATUS test-ip xx.xxx.xxx.xxx RESERVED
Ingressの作成
それでは次にIngressを作成します。このIngressでは先ほど予約した固定IPアドレスを指定します。
エディタを開いて、リスト2をコピー＆ペーストしてingress-my-api.yamlというファイル名で保存してください。
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: test-ingress
annotations:
kubernetes.io/ingress.global-static-ip-name: "test-ip" # 先ほど、予約したstatic-ipを指定
spec:
backend:
serviceName: service-my-api # 前の手順で作成したServiceの名前を指定
servicePort: 80
このYAMLでは「metadata > annotations > kubernetes.io/ingress.global-static-ip-name」で予約したStatic-ipを指定して、IngressのIPに対してアクセスした場合にSericeのservice-my-apiに振り分けるように、「spec > backend > serviceName & servicePort」を指定しています。
それでは、kubectl createコマンドでIngressを作成してみましょう。
$ kubectl create -f ingress-my-api.yaml ingress "test-ingress" created
コマンドが正常終了したら、次にgetとdescribeコマンドでIngressの状態を確認してみましょう。
Ingressの作成には数分ほどかかるので、createコマンドを実行した直後であれば、以下の通りADDRESSに何も表示されていない結果が得られます。
kubectl get ing NAME HOSTS ADDRESS PORTS AGE test-ingress dev.app.io 80 25s
Ingressの作成が完了していれば、以下と同様の結果が得られるはずです。
$ kubectl get ing
NAME HOSTS ADDRESS PORTS AGE
test-ingress dev.app.io {予約したStatic-IP} 80 4m
この結果が得られない場合は、Ingressの作成がまだ途中なので作成完了まで数分ほど待ちましょう。
getコマンドでIngressのADDRESSが表示されたら、次はdescribeコマンドを実行しましょう。
kubectl describe ing/test-ingress
Name: test-ingress
Namespace: default
Address: {予約したStatic-IP}
Default backend: default-http-backend:80 (10.48.1.4:8080)
Rules:
Host Path Backends
---- ---- --------
* * service-my-api:80 (10.48.0.5:80,10.48.2.7:80)
Annotations:
backends: {"k8s-be-31708--c599329eddb5878a":"HEALTHY","k8s-be-32765--c599329eddb5878a":"HEALTHY"}
forwarding-rule: k8s-fw-default-test-ingress--c599329eddb5878a
target-proxy: k8s-tp-default-test-ingress--c599329eddb5878a
url-map: k8s-um-default-test-ingress--c599329eddb5878a
Events:
FirstSeen LastSeen Count From SubObjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
14m 14m 1 loadbalancer-controller Normal ADD default/test-ingress
12m 12m 1 loadbalancer-controller Normal CREATE ip: {予約したStatic-IP}
12m 36s 7 loadbalancer-controller Normal Service no user specified default backend, using system default
Ingressが正常に作成されていれば、Ruleの部分にservice-my-api:80が確認できると思います。
Ingressではヘルスチェックとして、Serviceを経由してPodのルートディレクトリ（http://ServiceのIP:port/）に対してgetリクエストを投げてHTTPステータスコード200が返ってくるかを確認するようになっています。
describeの結果内の「Annotations > backends」で{"k8s-be-31708--c599329eddb5878a":"HEALTHY","k8s-be-32765--c599329eddb5878a":"HEALTHY"}と表示されているのが、ヘルスチェックの結果です。HEALTHYと表示されていれば、ヘルスチェックをパスしたということになります。
次に、Deploymentのログを確認してみましょう。ヘルスチェックのアクセス履歴がlogコマンドで得られるはずです。
$ kubectl log deploy/my-api W0718 08:49:26.645167 81531 cmd.go:392] log is DEPRECATED and will be removed in a future version. Use logs instead. Found 2 pods, using pod/my-api-1799588982-s5msj 10.146.0.5 - - [17/Jul/2017:23:48:49 +0000] "GET / HTTP/1.1" 200 612 "-" "GoogleHC/1.0" "-" 10.48.0.1 - - [17/Jul/2017:23:48:50 +0000] "GET / HTTP/1.1" 200 612 "-" "GoogleHC/1.0" "-" 10.48.0.1 - - [17/Jul/2017:23:48:50 +0000] "GET / HTTP/1.1" 200 612 "-" "GoogleHC/1.0" "-" 10.48.0.1 - - [17/Jul/2017:23:48:51 +0000] "GET / HTTP/1.1" 200 612 "-" "GoogleHC/1.0" "-"
GoogleHC/1.0がIngressのヘルスチェックのユーザーエージェントで、Serviceを経由してPodのルートディレクトリ（http://ServiceのIP:port/）に対してGETリクエストを投げていることが確認できます。その時のレスポンスで200を返しているため、ヘルスチェックを問題なくパスしたことになっています。
最後にcurlコマンドを手元のマシンから実行して、先ほど予約した固定IPアドレスからデプロイしたPodにアクセスできるかを確認しましょう。
$ curl {予約した固定IPアドレス}
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
...中略...
<p><em>Thank you for using nginx.</em></p>
</body>
</html>
このように、nginxのhtmlがレスポンスとして返ってきたことが確認できると思います。これで、Podを外部に公開することができました。
最後に
以上でServiceとIngressを使いWebアプリケーションを外部に公開することができました。次回はBlue-Green Deployment相当の機能と、アプリケーションのバージョンごとにURLを生成する機能を追加する方法について紹介します。
