GCP kubernetes with Ingress

はじめに
以前記事のおさらい
1. 環境構成図
2. 実施した内容の概要：
今回の目標
GCPリソースの用意
manifestの修正
確認
1. 不足点
最後に

はじめに

今回の記事は、以前書いた「GKEとcloudSQLでWordPressを構築してみた」の続編となります。
0 から構築する方法を知りたい方は、以前の記事もご一読いただければと思います。

今回の環境は前回構築したGCPリソースをそのまま使用する予定です。

この記事では、セッション維持(L7ロードバランサー機能)するために、Loadbalancerではなく、Ingressを使用する時の設定や注意事項を書いていきます。
初めてIngressを触る方には、色々参考になれるところ(自分はハマった)がきっとあると思いますので、心を落ち着いて読んでいただければと思います。

また、本記事はGCP(Google Cloud Platform)を使用することを前提としていますので、GCP特有の設定内容もあることにご了承ください。

以前記事のおさらい

Kubernetesの知識があって、以前の記事を読む時間のない方もいるかと思いますので、ここで簡単に以前記事の内容のおさらいをします。

環境構成図

下記構成のWordPressを構築するものとなります。

実施した内容の概要：

GCPリソースの準備
- GKE(kubernetesクラスタ)の作成
- cloudSQL(MySQL)の作成
- Global IPの作成
WordPressのDBとユーザの作成
manifestでKubernetesのリソースを作成
- secret
- loadbalancer
- deployment

今回の目標

LoadbalancerをIngressに入れ替わって、GCPのロードバランサーの「セッションアフィニティ」の設定(セッション維持)をCookieで維持するように設定する。

では、始めていきましょう。

GCPリソースの用意

Ingressはグローバルタイプの静的IPしか使えないので、以前Loadbalancer用に作成したリージョンタイプのはもう使えません。

以下のコマンドで新規作成する必要があります。

# リソース名を'k8s-ingress-ip'とする
gcloud compute addresses create k8s-ingress-ip --global

manifestの修正

Ingressの設定はkind: BackendConfigというGKE専用のKubernetesリソースが必要です。
参考資料
 参考資料

また、LoadbalancerをIngressに変更するために、NodePortの作成や、Podのヘルスチェックの仕組みを入れる必要がありますので、諸々修正が必要です。

以下でそれぞれ修正後のmanifestsをコメント付きでお見せします。

secret

secretはWordPress設定用なので、今回の改修とは関係ありません。そのまま使用できます。

BackendConfig

kind: BackendConfig：GCPのIngressの設定をするためのkubernetesのリソース。またこのリソースはNodePortで読み込みます。

# APIから見て、GCP専用であることがわかります。
apiVersion: cloud.google.com/v1beta1
kind: BackendConfig
metadata:
  name: wp-backend-config
spec:
  sessionAffinity:
    affinityType: "GENERATED_COOKIE"  # COOKIEでセッション維持するように設定
    affinityCookieTtlSec: 180  # COOKIEの有効期限(秒)

汎用例参考

deployment

Podにヘルスチェックを入れるため、Deploymentの内容も修正が必要です。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: wp-deployment
  labels:
    app: wordpress
spec:
  replicas: 2
  selector:
    matchLabels:
      app: wordpress
  template:
    metadata:
      labels:
        app: wordpress
    spec:
      containers:
      - name: wp-container
        image: wordpress:latest
        ports:
        - containerPort: 80
        readinessProbe:  # readinessProbeヘルスチェックを追加
        # 今回はpostStartで作成した/test.phpを使ってヘルスチェックにしている。元々用意するものを使うのがお勧め
          httpGet:
            port: 80
            path: /test.php
          initialDelaySeconds: 30
          timeoutSeconds: 15
          successThreshold: 1
          failureThreshold: 5
          periodSeconds: 3
        lifecycle:
          postStart:
            exec:
              command: ["/bin/sh", "-c", "echo $(hostname) > /var/www/html/test.php"]
        envFrom:
        - secretRef:
            name: wp-db-env

今回はpostStartで作成した/test.phpを使ってヘルスチェックにしているが、お勧めしません。なぜなら、ヘルスチェック時にファイルが存在しないかもしれませんからです。今回はヘルスチェックのタイムアウト時間を緩めるることで、何とか動くようにできました。

IngressとIngressのためのService(NodePort)

IngressとNodePortを作成します。

apiVersion: v1
kind: Service
metadata:
  name: wp-nodeport
  namespace: default
  # BackendConfigの設定を読み込む。spec.portsにnameを付けた場合、port番号の代わりに、nameも使える
  annotations:
    beta.cloud.google.com/backend-config: '{"ports": {"8080":"wp-backend-config"}}'
spec:
  ports:
  - port: 8080
    protocol: TCP
    targetPort: 80
  selector:
    app: wordpress
  type: NodePort
---
# GCPの静的IPを指定するには、apiバージョンを`extensions/v1beta1`にする必要がある
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: wp-ingress
  annotations:
    # GCPのグローバルIPのリソース名を指定する。※静的IPは事前に用意する必要がある
    kubernetes.io/ingress.global-static-ip-name: k8s-ingress-ip
spec:
  rules:
    - http:
        paths:
        - path: /*
          backend:
            serviceName: wp-nodeport
            servicePort: 8080

※Ingress作成から使得るようになるまで、10分ほどかかります。

確認

以下のコマンドで、構成を確認できます。

Ingressの確認

# ingress及びIPの確認
kubectl describe ingress wp-ingress

その他の設定の確認

セッション維持(セッションアフィニティ)、ヘルスチェックの設定はGCP管理コンソールで確認できます。

GCPの管理コンソール > Kubernetes Engine > ServicesとIngress

不足点

~~現在の構成では、サーバのIPでアクセスすると、Ingressはサーバの/にリクエストを出すので、リダイレクトが効かないぽいです。~~
~~<IP>/wp-login.phpで直接ログインページにアクセスする必要があります。これはよろしくない構成です。対処は必要です。~~

2020/06/29更新：

~~色々調査して、結局ローカルのブラウザのせいで、8080ポート(以前のキャッシュ)へアクセスしようとして、ダメだったことがわかりました。~~
~~これは解決として、セッション維持の確認をしたところ、cookieでのセッション維持はされませんでした。さらなる調査が必要です。~~

HTTP Cookie アフィニティは、HTTP_COOKIE フラグで指定された HTTP Cookie に基づいて、NEG 内のバックエンド VM またはエンドポイントにリクエストをルーティングします。クライアントが Cookie を指定しない場合、プロキシは Cookie を生成し、Set-Cookie ヘッダーでクライアントに返します。

上記の内容によると、クライアントPodやコンテナではなく、バックエンドVMまたはエンドポイントらしいです。
完全に勘違いしてしまいました。。。
Podへのセッション維持はまた他の方法を探すしかないです。