このページでは、GKE クラスタに Gateway をデプロイするときに Google Kubernetes Engine(GKE)が作成するロードバランサの構成方法について説明します。
Gateway をデプロイすると、GatewayClass の構成により、GKE が作成するロードバランサが決まります。このマネージド ロードバランサには、ポリシーで変更可能なデフォルトの設定があらかじめ構成されています。
Gateway、Service、ServiceImport にポリシーを接続して、インフラストラクチャやアプリケーションの要件に合わせて Gateway リソースをカスタマイズできます。ポリシーを適用または変更した後、Gateway リソース、Route リソース、または Service リソースの削除や再作成を行う必要はありません。ポリシーは Gateway コントローラによって処理され、基盤となるロードバランサ リソースが(新しい)ポリシーに従って(再)構成されます。
始める前に
始める前に、次の作業が完了していることを確認してください。
- Google Kubernetes Engine API を有効にする。 Google Kubernetes Engine API の有効化
- このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。すでに gcloud CLI をインストールしている場合は、
gcloud components update
を実行して最新のバージョンを取得する。
GKE Gateway Controller の要件
- Standard の場合は GKE バージョン 1.24 以降。
- Autopilot の場合は GKE バージョン 1.26 以降。
- Google Cloud CLI バージョン 407.0.0 以降。
- Gateway API は、VPC ネイティブ クラスタでのみサポートされます。
- 内部 GatewayClass を使用している場合は、プロキシ専用サブネットを有効にする必要があります。
- クラスタで
HttpLoadBalancing
アドオンが有効になっている必要があります。 - Istio を使用している場合は、Istio を次のいずれかのバージョンにアップグレードする必要があります。
- 1.15.2 以降
- 1.14.5 以降
- 1.13.9 以降
- 共有 VPC を使用している場合は、ホスト プロジェクトで、サービス プロジェクトの GKE サービス アカウントに
Compute Network User
ロールを割り当てる必要があります。
制限事項
GKE Gateway Controller の制限事項に加えて、Gateway リソースに適用されるポリシーには、次の制限事項が適用されます。
GCPGatewayPolicy
リソースは、gateway.networking.k8s.io
Gateway
にのみ接続できます。GCPGatewayPolicy
リソースは、ターゲットのGateway
と同じ Namespace に存在している必要があります。単一クラスタ Gateway を使用する場合、
GCPBackendPolicy
とHealthCheckPolicy
リソースはService
リソースを参照する必要があります。
- マルチクラスタ Gateway を使用する場合、
GCPBackendPolicy
リソースとHealthCheckPolicy
リソースはServiceImport
リソースを参照する必要があります。
1 つの Service に接続できる
GCPGatewayPolicy
は常に 1 つのみです。2 つのGCPGatewayPolicy
ポリシーが作成され、同じService
またはServiceImport
をターゲットにしている場合、最も古いポリシーが優先され、2 番目のポリシーは接続できません。GKE Gateway では、階層型ポリシーはサポートされていません。
HealthCheckPolicy
リソースとGCPBackendPolicy
リソースは、ターゲットのService
リソースまたはServiceImport
リソースと同じ Namespace に存在する必要があります。GCPBackendPolicy
リソースとHealthCheckPolicy
リソースは、1 つのバックエンド サービスのみを参照できる構造になっています。
リージョン内部 Gateway のグローバル アクセスを構成する
このセクションでは、バージョン 1.24 以降を実行している GKE クラスタで使用可能な機能について説明します。
内部 Gateway でグローバル アクセスを有効にするには、Gateway リソースにポリシーを接続します。
次の GCPGatewayPolicy
マニフェストは、グローバル アクセス用にリージョン内部 Gateway を有効にします。
apiVersion: networking.gke.io/v1
kind: GCPGatewayPolicy
metadata:
name: my-gateway-policy
namespace: default
spec:
default:
allowGlobalAccess: true
targetRef:
group: gateway.networking.k8s.io
kind: Gateway
name: my-gateway
SSL ポリシーを構成してクライアントとロードバランサ間のトラフィックを保護する
このセクションでは、バージョン 1.24 以降を実行している GKE クラスタで使用可能な機能について説明します。
クライアントからロードバランサへのトラフィックを保護するには、ポリシーの名前を GCPGatewayPolicy
に追加して SSL ポリシーを構成します。デフォルトでは、Gateway に SSL ポリシーが定義も接続もされていません。
GCPGatewayPolicy
でポリシーを参照する前に、SSL ポリシーを作成してください。
次の GCPGatewayPolicy
マニフェストでは、gke-gateway-ssl-policy
という名前のセキュリティ ポリシーを指定しています。
apiVersion: networking.gke.io/v1
kind: GCPGatewayPolicy
metadata:
name: my-gateway-policy
namespace: team1
spec:
default:
sslPolicy: gke-gateway-ssl-policy
targetRef:
group: gateway.networking.k8s.io
kind: Gateway
name: my-gateway
ヘルスチェックを構成する
このセクションでは、バージョン 1.24 以降を実行している GKE クラスタで使用可能な機能について説明します。
HealthCheckPolicy
を使用して、ロードバランサのヘルスチェック設定を制御できます。ヘルスチェックの各タイプ(http
、https
、grpc
、http2
)には、定義可能なパラメータがあります。Google Cloud は、GKE Service のバックエンド サービスごとに一意のヘルスチェックを作成します。
次の HealthCheckPolicy
マニフェストは、ヘルスチェック ポリシーの構成時に使用可能なすべてのフィールドを示します。
サービス
apiVersion: networking.gke.io/v1
kind: HealthCheckPolicy
metadata:
name: lb-healthcheck
namespace: lb-service-namespace
spec:
default:
checkIntervalSec: INTERVAL
timeoutSec: TIMEOUT
healthyThreshold: HEALTHY_THRESHOLD
unhealthyThreshold: UNHEALTHY_THRESHOLD
logConfig:
enabled: ENABLED
config:
type: PROTOCOL
httpHealthCheck:
portSpecification: PORT_SPECIFICATION
port: PORT
portName: PORT_NAME
host: HOST
requestPath: REQUEST_PATH
response: RESPONSE
proxyHeader: PROXY_HEADER
httpsHealthCheck:
portSpecification: PORT_SPECIFICATION
port: PORT
portName: PORT_NAME
host: HOST
requestPath: REQUEST_PATH
response: RESPONSE
proxyHeader: PROXY_HEADER
grpcHealthCheck:
grpcServiceName: GRPC_SERVICE_NAME
portSpecification: PORT_SPECIFICATION
port: PORT
portName: PORT_NAME
http2HealthCheck:
portSpecification: PORT_SPECIFICATION
port: PORT
portName: PORT_NAME
host: HOST
requestPath: REQUEST_PATH
response: RESPONSE
proxyHeader: PROXY_HEADER
targetRef:
group: ""
kind: Service
name: lb-service
マルチクラスタ サービス
apiVersion: networking.gke.io/v1
kind: HealthCheckPolicy
metadata:
name: lb-healthcheck
namespace: lb-service-namespace
spec:
default:
checkIntervalSec: INTERVAL
timeoutSec: TIMEOUT
healthyThreshold: HEALTHY_THRESHOLD
unhealthyThreshold: UNHEALTHY_THRESHOLD
logConfig:
enabled: ENABLED
config:
type: PROTOCOL
httpHealthCheck:
portSpecification: PORT_SPECIFICATION
port: PORT
portName: PORT_NAME
host: HOST
requestPath: REQUEST_PATH
response: RESPONSE
proxyHeader: PROXY_HEADER
httpsHealthCheck:
portSpecification: PORT_SPECIFICATION
port: PORT
portName: PORT_NAME
host: HOST
requestPath: REQUEST_PATH
response: RESPONSE
proxyHeader: PROXY_HEADER
grpcHealthCheck:
grpcServiceName: GRPC_SERVICE_NAME
portSpecification: PORT_SPECIFICATION
port: PORT
portName: PORT_NAME
http2HealthCheck:
portSpecification: PORT_SPECIFICATION
port: PORT
portName: PORT_NAME
host: HOST
requestPath: REQUEST_PATH
response: RESPONSE
proxyHeader: PROXY_HEADER
targetRef:
group: net.gke.io
kind: ServiceImport
name: lb-service
次のように置き換えます。
INTERVAL
: 各ヘルスチェック プローバーのチェック間隔を秒単位で指定します。これは、プローバーのチェックを開始してから次のチェックを開始するまでの時間です。このパラメータを省略すると、Google Cloud のデフォルト(5 秒)が使用されます。詳細については、複数の Probe と頻度をご覧ください。TIMEOUT
は、Google Cloud が Probe に対するレスポンスを待つ時間を指定します。TIMEOUT
の値はINTERVAL
以下にする必要があります。単位は秒です。各プローブでは、プローブ タイムアウトの前に HTTP 200(OK)レスポンス コードを配信する必要があります。HEALTHY_THRESHOLD
とUNHEALTHY_THRESHOLD
: 正常から異常、または異常から正常に健全性を変更するために、少なくとも 1 つのプローバーについて、プローブの成功または失敗の連続回数を示します。これらのパラメータのいずれかを省略した場合、Google Cloud ではデフォルト値の 2 が使用されます。PROTOCOL
: ヘルスチェックの Probe システムで使用されるプロトコルを指定します。詳細については、HTTP、HTTPS、HTTP/2 での成功基準と gRPC での成功基準をご覧ください。このパラメータは必須です。ENABLED
: ロギングを有効にするかどうかを指定します。PORT_SPECIFICATION
: ヘルスチェックで固定ポート(USE_FIXED_PORT
)、名前付きポート(USE_NAMED_PORT
)、サービスポート(USE_SERVING_PORT
)のいずれを使用するかを指定します。指定しない場合、ヘルスチェックはport
フィールドとportName
フィールドで指定された動作に従います。port
もportName
も指定されていない場合、このフィールドはデフォルトのUSE_SERVING_PORT
になります。PORT
: HealthCheckPolicy では、ポート番号を使用したロードバランサのヘルスチェック ポートの指定のみがサポートされています。このパラメータを省略した場合、Google Cloud ではデフォルトの 80 が使用されます。ロードバランサは、Pod の IP アドレスにプローブを直接送信するため、containerPort
が Service のtargetPort
で参照される場合でも、サービスを提供する Pod のcontainerPort
と一致するポートを選択する必要があります。Service のtargetPort
で参照されるcontainerPorts
に限定されません。PORT_NAME
: InstanceGroup.NamedPort.name で定義されているポート名を指定します。port
とportName
の両方が定義されている場合、Google Cloud はまずport
値を考慮します。HOST
: ヘルスチェック リクエストのホストヘッダーの値。この値はホスト名の RFC 1123 定義を使用します。ただし、数値の IP アドレスは使用できません。指定しないか空のままにした場合、この値はデフォルトでヘルスチェックの IP アドレスになります。REQUEST_PATH
: ヘルスチェック リクエストのリクエストパスを指定します。指定しないか空のままにした場合、/
がデフォルトになります。RESPONSE
: レスポンス データの先頭と照合するバイトを指定します。指定しないか空のままにした場合、GKE はすべてのレスポンスを正常と解釈します。レスポンス データには ASCII のみを使用できます。PROXY_HEADER
: プロキシ ヘッダーのタイプを指定します。NONE
またはPROXY_V1
を使用できます。デフォルトはNONE
です。GRPC_SERVICE_NAME
: gRPC サービスの名前(省略可)。すべてのサービスを指定する場合は、このフィールドを省略します。
HealthCheckPolicy フィールドの詳細については、healthChecks
リファレンスをご覧ください。
Google Cloud Armor バックエンド セキュリティ ポリシーを構成してバックエンド サービスを保護する
このセクションでは、バージョン 1.24 以降を実行している GKE クラスタで使用可能な機能について説明します。
バックエンド サービスを保護するため、セキュリティ ポリシーの名前を GCPBackendPolicy
に追加し、Google Cloud Armor バックエンド セキュリティ ポリシーを構成します。デフォルトでは、Gateway に Google Cloud Armor バックエンド セキュリティ ポリシーは定義されません。また接続もされません。
GCPBackendPolicy
でポリシーを参照する前に、Google Cloud Armor バックエンド セキュリティ ポリシーを作成してください。
次の GCPBackendPolicy
マニフェストでは、example-security-policy
という名前のバックエンド セキュリティ ポリシーを指定しています。
サービス
apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
name: my-backend-policy
namespace: lb-service-namespace
spec:
default:
securityPolicy: example-security-policy
targetRef:
group: ""
kind: Service
name: lb-service
マルチクラスタ サービス
apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
name: my-backend-policy
namespace: lb-service-namespace
spec:
default:
securityPolicy: example-security-policy
targetRef:
group: net.gke.io
kind: ServiceImport
name: lb-service
IAP を構成する
このセクションでは、バージョン 1.24 以降を実行している GKE クラスタで使用可能な機能について説明します。
Identity-Aware Proxy(IAP)は、HTTPRoute に関連付けられたバックエンド サービスにアクセス制御ポリシーを適用します。この適用により、適切な Identity and Access Management(IAM)ロールが割り当てられた認証済みユーザーまたはアプリケーションのみが、これらのバックエンド サービスにアクセスできます。
デフォルトでは、バックエンド サービスに適用される IAP がないため、GCPBackendPolicy
で明示的に IAP を構成する必要があります。
Gateway で IAP を構成するには、次の操作を行います。
GKE の IAP を有効にする
BackendConfig
は Ingress デプロイの場合にのみ有効のため、バックエンドの構成(BackendConfig の構成)をしないでください。IAP のシークレットを作成します。
Google Cloud コンソールで、[認証情報] ページに移動します。
クライアントの名前をクリックして、OAuth クライアント ファイルをダウンロードします。
OAuth クライアント ファイルから、OAuth シークレットをクリップボードにコピーします。
iap-secret.txt
というファイルを作成します。次のコマンドを使用して、OAuth シークレットを
iap-secret.txt
ファイルに貼り付けます。echo -n CLIENT_SECRET > iap-secret.txt kubectl create secret generic SECRET_NAME --from-file=key=iap-secret.txt
シークレットを参照する IAP ポリシーを指定するには:
次の
GCPBackendPolicy
マニフェストを作成し、SECRET_NAME
とCLIENT_ID
をそれぞれ置き換えます。マニフェストをbackend-policy.yaml
として保存します。サービス
apiVersion: networking.gke.io/v1 kind: GCPBackendPolicy metadata: name: backend-policy spec: default: iap: enabled: true oauth2ClientSecret: name: SECRET_NAME clientID: CLIENT_ID targetRef: group: "" kind: Service name: lb-service
マルチクラスタ サービス
apiVersion: networking.gke.io/v1 kind: GCPBackendPolicy metadata: name: backend-policy spec: default: iap: enabled: true oauth2ClientSecret: name: SECRET_NAME clientID: CLIENT_ID targetRef: group: net.gke.io kind: ServiceImport name: lb-service
backend-policy.yaml
マニフェストを適用します。kubectl apply -f backend-policy.yaml
構成を確認します
IAP で
GCPBackendPolicy
を作成したら、ポリシーが適用されたことを確認します。kubectl get gcpbackendpolicy
出力は次のようになります。
NAME AGE backend-policy 45m
詳細を確認するには、describe コマンドを使用します。
kubectl describe gcpbackendpolicy
出力は次のようになります。
Name: backend-policy Namespace: default Labels: <none> Annotations: <none> API Version: networking.gke.io/v1 Kind: GCPBackendPolicy Metadata: Creation Timestamp: 2023-05-27T06:45:32Z Generation: 2 Resource Version: 19780077 UID: f4f60a3b-4bb2-4e12-8748-d3b310d9c8e5 Spec: Default: Iap: Client ID: 441323991697-luotsrnpboij65ebfr13hlcpm5a4heke.apps.googleusercontent.com Enabled: true oauth2ClientSecret: Name: my-iap-secret Target Ref: Group: Kind: Service Name: lb-service Status: Conditions: Last Transition Time: 2023-05-27T06:48:25Z Message: Reason: Attached Status: True Type: Attached Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ADD 46m sc-gateway-controller default/backend-policy Normal SYNC 44s (x15 over 43m) sc-gateway-controller Application of GCPGatewayPolicy "default/backend-policy" was a success
バックエンド サービスのタイムアウトを構成する
このセクションでは、バージョン 1.24 以降を実行している GKE クラスタで使用可能な機能について説明します。
次の GCPBackendPolicy
マニフェストでは、バックエンド サービスのタイムアウト期間を 40 秒に設定しています。デフォルトの timeoutSec
フィールドは 30 秒です。
サービス
apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
name: my-backend-policy
namespace: lb-service-namespace
spec:
default:
timeoutSec: 40
targetRef:
group: ""
kind: Service
name: lb-service
マルチクラスタ サービス
apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
name: my-backend-policy
namespace: lb-service-namespace
spec:
default:
timeoutSec: 40
targetRef:
group: net.gke.io
kind: ServiceImport
name: lb-service
セッション アフィニティを構成する
このセクションでは、バージョン 1.24 以降を実行している GKE クラスタで使用可能な機能について説明します。
セッション アフィニティは、次の基準に基づいて構成できます。
- クライアント IP アドレス
- 生成した Cookie
Service にセッション アフィニティを構成すると、Gateway の localityLbPolicy
設定が MAGLEV
に設定されます。
GCPBackendPolicy
からセッション アフィニティの構成を削除すると、Gateway は localityLbPolicy
の設定をデフォルト値の ROUND_ROBIN
に戻します。この値は、通知なしで GKE マネージド バックエンド サービス(ロードバランサに接続されている)に設定され、gcloud CLI コマンド、UI、Terraform の出力には反映されません。
次の GCPBackendPolicy
マニフェストでは、クライアント IP アドレスに基づいてセッション アフィニティを指定しています。
サービス
apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
name: my-backend-policy
namespace: lb-service-namespace
spec:
default:
sessionAffinity:
type: CLIENT_IP
targetRef:
group: ""
kind: Service
name: lb-service
マルチクラスタ サービス
apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
name: my-backend-policy
namespace: lb-service-namespace
spec:
default:
sessionAffinity:
type: CLIENT_IP
targetRef:
group: net.gke.io
kind: ServiceImport
name: lb-service
次の GCPBackendPolicy
マニフェストは、生成された Cookie に基づいてセッション アフィニティを指定し、Cookie の TTL を 50 秒に構成しています。
サービス
apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
name: my-backend-policy
namespace: lb-service-namespace
spec:
default:
sessionAffinity:
type: GENERATED_COOKIE
cookieTtlSec: 50
targetRef:
group: ""
kind: Service
name: lb-service
マルチクラスタ サービス
apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
name: my-backend-policy
namespace: lb-service-namespace
spec:
default:
sessionAffinity:
type: GENERATED_COOKIE
cookieTtlSec: 50
targetRef:
group: net.gke.io
kind: ServiceImport
name: lb-service
sessionAffinity.type
に対して、CLIENT_IP
、CLIENT_IP_PROTO
、CLIENT_IP_PORT_PROTO
、GENERATED_COOKIE
、HEADER_FIELD
、HTTP_COOKIE
、NONE
のオプションを使用できます。
コネクション ドレインのタイムアウトを構成する
このセクションでは、バージョン 1.24 以降を実行している GKE クラスタで使用可能な機能について説明します。
コネクション ドレインのタイムアウトは、GCPBackendPolicy
を使用して構成できます。コネクション ドレインのタイムアウトは、接続がドレインするまで待機する時間(秒)です。タイムアウト時間は 0~3,600 秒に設定できます。デフォルト値は 0 で、この場合、コネクション ドレインも無効になります。
次の GCPBackendPolicy
マニフェストは、コネクション ドレインのタイムアウトを 60 秒に指定します。
サービス
apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
name: my-backend-policy
namespace: lb-service-namespace
spec:
default:
connectionDraining:
drainingTimeoutSec: 60
targetRef:
group: ""
kind: Service
name: lb-service
マルチクラスタ サービス
apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
name: my-backend-policy
namespace: lb-service-namespace
spec:
default:
connectionDraining:
drainingTimeoutSec: 60
targetRef:
group: net.gke.io
kind: ServiceImport
name: lb-service
指定されたタイムアウト期間の間、GKE は削除されたバックエンドに対する既存のリクエストが完了するまで待機します。ロードバランサは、削除されたバックエンドに新しいリクエストを送信しません。タイムアウト時間に達すると、GKE はバックエンドへの残りの接続をすべて閉じます。
HTTP アクセス ロギング
このセクションでは、バージョン 1.24 以降を実行している GKE クラスタで使用可能な機能について説明します。
デフォルトでの設定:
- Gateway コントローラは、クライアントからのすべての HTTP リクエストを Cloud Logging に記録します。
- サンプリング レートは 1,000,000 であるため、すべてのリクエストがログに記録されます。
GCPBackendPolicy
を使用して Gateway のアクセス ロギングを無効にするには、次の 3 つの方法があります。
GCPBackendPolicy
にlogging
セクションを追加しないでおくlogging.enabled
をfalse
に設定するlogging.enabled
をtrue
に、logging.sampleRate
を0
に設定する
アクセス ロギングのサンプリング レートを構成することもできます。
次の GCPBackendPolicy
マニフェストでは、アクセス ロギングのデフォルトのサンプルレートが変更され、指定された Service リソースに対する HTTP リクエストの 50% に設定されます。
サービス
apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
name: my-backend-policy
namespace: lb-service-namespace
spec:
default:
logging:
enabled: true
sampleRate: 500000
targetRef:
group: ""
kind: Service
name: lb-service
マルチクラスタ サービス
apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
name: my-backend-policy
namespace: lb-service-namespace
spec:
default:
logging:
enabled: true
sampleRate: 500000
targetRef:
group: net.gke.io
kind: ServiceImport
name: lb-service
このマニフェストには次のフィールドがあります。
enable: true
: アクセス ロギングを明示的に有効にします。ログは Logging で参照できます。sampleRate: 500000
: パケットの 50% がログに記録されるように指定します。0~1,000,000 の値を使用できます。GKE はこの値を 1,000,000 で割って [0,1] の範囲の浮動小数点値に変換します。このフィールドは、enable
がtrue
に設定されている場合にのみ機能します。sampleRate
は省略可能なフィールドですが、構成する場合はenable: true
も設定する必要があります。enable
がtrue
に設定され、sampleRate
が指定されていない場合、GKE はenable
をfalse
に設定します。
トラブルシューティング
同じ Service
に複数の GCPBackendPolicy
が接続されている
症状:
GCPBackendPolicy
を Service
または ServiceImport
に接続すると、次のステータスの状態が発生することがあります。
status:
conditions:
- lastTransitionTime: "2023-09-26T20:18:03Z"
message: conflicted with GCPBackendPolicy "[POLICY_NAME]" of higher precedence, hence not applied
reason: Conflicted
status: "False"
type: Attached
理由:
このステータス状態は、すでに GCPBackendPolicy
が接続されている Service
または ServiceImport
に 2 つ目の GCPBackendPolicy
を接続しようとしていることを示します。
GKE Gateway では、同じ Service
や ServiceImport
に複数の GCPBackendPolicy
を接続できません。詳細については、制限事項をご覧ください。
回避策:
すべてのカスタム構成を含む GCPBackendPolicy
を 1 つ構成し、Service
または ServiceImport
に接続します。
次のステップ
- Gateway コントローラの詳細を確認する。
- リソースから Gateway を参照する方法を学習する。