Ingress のその先: Gateway API という選択
こんにちは。Enabling team の山本です。
Retail AI X では、Google Cloud 上でさまざまなサービスを稼働させており、日々、トライアルの店舗をご利用のお客様へ価値を提供しております。
この記事は、Enabling team の役割の 1 つである「Application stack の ecosystem に関する調査」の活動報告です。
Application stack
今回は、Ingress API(Ingress)の進化版である Gateway を調査します。
Kubernetes Gateway API(Gateway)
引用:Kubernetes Gateway API
ご存じのとおり、Ingress は、負荷分散・SSL 終端などの機能を提供します。
今回、Gateway が GA になったことで、弊社サービスへの導入に向けた調査を行います。
評価
弊社の採用基準としては、Technology Radar でいうところの
HOLD : 採用する場合は慎重に進める必要がある。
くらいの位置付けだと思います。
理由
Ingress でサポートされていた機能が現時点でサポートされていないためです。
具体的には、以下の機能を必要としています。
- Google Cloud Armor
- SSL ポリシー
- カスタム リクエストとレスポンス ヘッダー
Production への適用は、もう少し待つ必要があると思います。
今後の Update に期待です!
それでは、先々の導入準備として、 Ingress との違いを確認していきます。
はじめに
弊社のサービスは、 ほぼ全てで Ingress を採用してきました。
Ingress について、Infra と Application の関心ごとが混在することに不満を感じます。
具体的には、ドメイン・証明書と Path rule が同じ manifest に存在するところです。
そもそも、Stream-aligned team は、Production 環境全体に責任を持つため、Infra が、Application がと言う境界は無いはずですが。
構築
GKE Cluster の作成
gcloud beta container --project "gw-sandbox-service-a" clusters create "case1a" --zone "asia-northeast1-a" --no-enable-basic-auth --cluster-version "1.24.7-gke.900" --release-channel "regular" --machine-type "e2-medium" --image-type "COS_CONTAINERD" --disk-type "pd-balanced" --disk-size "100" --metadata disable-legacy-endpoints=true --scopes "https://www.googleapis.com/auth/devstorage.read_only","https://www.googleapis.com/auth/logging.write","https://www.googleapis.com/auth/monitoring","https://www.googleapis.com/auth/servicecontrol","https://www.googleapis.com/auth/service.management.readonly","https://www.googleapis.com/auth/trace.append" --max-pods-per-node "110" --num-nodes "1" --logging=SYSTEM,WORKLOAD --monitoring=SYSTEM --enable-ip-alias --network "projects/gw-sandbox-service-a/global/networks/default" --subnetwork "projects/gw-sandbox-service-a/regions/asia-northeast1/subnetworks/default" --no-enable-intra-node-visibility --default-max-pods-per-node "110" --no-enable-master-authorized-networks --addons HorizontalPodAutoscaling,HttpLoadBalancing,GcePersistentDiskCsiDriver --enable-autoupgrade --enable-autorepair --max-surge-upgrade 1 --max-unavailable-upgrade 0 --enable-shielded-nodes --node-locations "asia-northeast1-a" --gateway-api=standard
-
--gateway-api=standard
: Gateway を有効にするパラメータ
SSL 証明書の作成
IP Address の予約は不要です。
-
--domains
: 取得する FQDN
gcloud compute ssl-certificates create store-example-com \
--domains=gw-test.example.com \
--global
ゲートウェイと HTTPRoute を作成する
Gateway の作成時に、SSL 証明書で指定したドメインを設定します。
cat << EOF | kubectl apply -f -
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
name: external-http
spec:
gatewayClassName: gke-l7-gxlb
listeners:
- name: https
protocol: HTTPS
port: 443
tls:
mode: Terminate
options:
networking.gke.io/pre-shared-certs: store-example-com # SSL 証明書名
EOF
cat << EOF | kubectl apply -f -
kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
name: store-external
labels:
gateway: external-http
spec:
parentRefs:
- name: external-http
hostnames:
- "gw-test.example.com" # 取得する FQDN
rules:
- backendRefs:
- name: store-v1
port: 8080
EOF
IP Address を取得する
kubectl get gateway external-http -o=jsonpath="{.status.addresses[0].value}"
FQDN を登録します。
ステータスが ACTIVE
になるまで15分程度待ちます。
ゲートウェイの動作を確認する
yamamoto_daisuke@cloudshell:~ (gw-sandbox-service-a)$ curl https://gw-test.example.com -v
* Trying 34.120.89.76:443...
* Connected to gw-test.example.com (34.120.89.76) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=gw-test.example.com
* start date: Jan 6 11:11:22 2023 GMT
* expire date: Apr 6 11:56:31 2023 GMT
* subjectAltName: host "gw-test.example.com" matched cert's "gw-test.example.com"
* issuer: C=US; O=Google Trust Services LLC; CN=GTS CA 1D4
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x5651339d92c0)
> GET / HTTP/2
> Host: gw-test.example.com
> user-agent: curl/7.74.0
> accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 500
< date: Fri, 06 Jan 2023 23:04:10 GMT
< content-length: 14
< content-type: text/plain; charset=utf-8
< via: 1.1 google
< alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
<
response 500
* Connection #0 to host gw-test.example.com left intact
yamamoto_daisuke@cloudshell:~ (gw-sandbox-service-a)$
これで、Gateway の設定が完了しました。
Application を使用した動作確認は、公式を確認してください。
まとめ
Gateway
resource と HTTPRoute
resource が分かれていることで、SRE と Developer が役割分担を行うことができます。
Ingress の後継ということで違いを見てきましたが、問題となるような設定手順は存在しませんでした。
既存のサービスの Ingress の置き換えも問題なく進めることができると思います。
なお、今後、機能追加は、Gateway が中心になる予定ということです。
Stream-aligned team の Production への適用時のギャップを埋めるため、動向をウォッチしていきます。
Discussion