ダウンタイムなくIngressからGatewayに移行してみる

はじめに

アプリチームのkuribo-です。

今回はCertificate Managerの検証の続きです。
GKEでもCertificate Managerを使ってみようと検証してみました。
（あくまで当初の目的はGKEでもCertificate Managerを使いたいだったのですが、調べていくうちに話が大きくなりました…）

GKEでCertificate Managerを使うため調査

GKEでCertificate Managerを使うため調査しました。
今までGKEではIngressを使っていたのですが、IngressはCertificate Managerに対応していません。
そのためIngressに代わるものを探す必要がありました。
調べていくと、GatewayAPIを使うことでCertificate Managerを利用できることがわかりました。

ですので、IngressからGatewayAPIに移行する方法の調査しました。

調査した時に参考にしたIssue。
https://github.com/kubernetes/ingress-gce/issues/1692

IngressからGatewayへ移行する

Google公式がIngressからGatewayへの移行について記載しています。
https://cloud.google.com/kubernetes-engine/docs/concepts/gateway-api?hl=ja#ingress_and_gateway

ただこれだけではあまりよくわかりません。
とりあえずIngressとGatewayを並行稼働させることだけはわかります。
それが可能なのか？など実際に試してみました。

ただ、ここで1点注意点です。
GatewayAPIではまだCloud CDNのサポートがされていないようですので、Cloud CDNを使っている場合はご注意ください。

実際に試してみた

NodeでGatewayAPIが使えるように有効化する

以下ドキュメントのコマンドを実行することでGatewayAPIが有効化されます。
https://cloud.google.com/kubernetes-engine/docs/how-to/deploying-gateways?hl=ja#enable-gateway

terraformの場合は以下の部分を追記することでGatewayAPIが有効化されます。

resource "google_container_cluster" "cluster" {
  gateway_api_config {
    channel = "CHANNEL_STANDARD"
  }
}

Manifestを作成する

Gatewayを使う場合、今までのIngressを置き換えることになります。
ただ、frontendConfigやbackendConfigも使えなくなるので、それぞれ置き換えます。
尚、GatewayClassのManifestも本来必要になるようですが、GCP側で用意してくれているので作成する必要はありません。

gateway.yml

apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: hoge-gateway
  annotations:
    networking.gke.io/certmap: cert-map
spec:
  gatewayClassName: gke-l7-global-external-managed
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    allowedRoutes:
      kinds:
      - kind: HTTPRoute
  addresses:
  - type: NamedAddress
    value: hoge-ip

http-route.yml

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: hoge-route
spec:
  parentRefs:
  - kind: Gateway
    name: hoge-gateway
  hostnames:
  - "hoge.example.com"
  rules:
  - matches:
    - path:
        value: /
    backendRefs:
    - name: hoge-service
      port: 80

frontendConfigやbackendConfigなどを作成していた場合、
GCPBackendPolicyやHealthCheckPolicyを作成してください。

反映と切り替え

上記のManifestを反映することで、LBのtarget-https-proxyおよび、forwarding-rule部分が作成されます。（新しいIPがLBに追加されます）
これで旧LBと新LBが並行稼働している状態になるので、この状態でDNSのAレコード（あればAAAAレコードも）を新LBの方に切り替えることで無停止による切り替えが完了します。

DNSで切り替えることになりますので、事前にTTLは短くしておいて切り戻しがしやすいようにしておいてください。

つまづきポイント

GatewayAPIの情報が結構少ない。そのため、GatewayとIngressの比較をしようとしてもGateway側の仕様があまりわからない。
調べた結果、GatewayとIngressで主に以下の部分に差異がありました。

• GatewayはCloud CDNに対応していない
  • https://cloud.google.com/kubernetes-engine/docs/how-to/gatewayclass-capabilities?hl=ja#:~:text=Armor%20%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%20%E3%83%9D%E3%83%AA%E3%82%B7%E3%83%BC-,Cloud%20CDN,-%E3%82%B5%E3%83%9D%E3%83%BC%E3%83%88%E3%81%95%E3%82%8C
• Cloud Armorは2023年4月10日に機能追加された。
  • https://cloud.google.com/kubernetes-engine/docs/how-to/configure-gateway-resources?hl=ja#configure_cloud_armor
• logging, IAP, カスタムレスポンスヘッダーは対応している。
  • https://cloud.google.com/kubernetes-engine/docs/how-to/configure-gateway-resources?hl=ja#configure_http_access_logging
  • https://cloud.google.com/kubernetes-engine/docs/how-to/configure-gateway-resources?hl=ja#configure_iap
  • https://cloud.google.com/kubernetes-engine/docs/how-to/gatewayclass-capagbilities?hl=ja#:~:text=responseHeaderModifier.add

まとめ

現在Ingressの機能よりGatewayのほうが若干機能が足りないところもありますが、
今後Gatewayにしか更新しないみたいな方針っぽいものを見たので遅かれ早かれ移行していく必要があります。
今後もうちょっとGoogleの移行手順のドキュメントが充実すると良いです。

おわりに

意外と結構大変な検証になりました。
Ingressとその他のManifestから移行する時の、移行後のManifestの書き方などもうちょっとドキュメントが欲しいな。

---

GI Cloud は事業の拡大に向けて一緒に夢を追う仲間を募集しています

当社は「クラウドで日本のIT業界を変革し、世の中をもっとハッピーに」をミッションに掲げ、Google Cloudに特化した技術者集団として、お客様にコンサルティングからシステム開発、運用・保守まで一気通貫でサービスを提供しています。

まだ小規模な事業体ですが、スタートアップならではの活気と成長性に加えて、大手総合商社である伊藤忠グループの一員としてやりがいのある案件にもどんどんチャレンジできる環境が整っています。成長意欲の高い仲間と共にスキルを磨きながら、クラウドの力で世の中をもっとハッピーにしたい。そんな我々の想いに共感できる方のエントリーをお待ちしています。

採用ページ