Open8

k8s gateway api

kkk777kkk777

Gateway

https://gateway-api.sigs.k8s.io/concepts/api-overview/#gateway
Gateway リソースの 挙動を定義する load balancer config が必要?

Route

https://gateway-api.sigs.k8s.io/concepts/api-overview/#tlsroute
tlsroute のイメージが湧かないので後で深掘り

https://gateway-api.sigs.k8s.io/concepts/api-overview/#tcproute-and-udproute
異なるバックエンドに流すには必ずポート番号を変える必要あり
TLS終端も可能だし、暗号化したまま流すことも可能

HTTPRoute/TCPRoute は Gateway > backend 間で再暗号化が可能。現在は標準化されているわけではないが、個別で設定を提供することが可能


Gateway と Route の紐付けはこの辺が参考になる
https://gateway-api.sigs.k8s.io/concepts/api-overview/#how-it-works

kkk777kkk777

以下のように設定することで Gateway に紐づけることのできる Route の Namespace を複数設定できるが、env: stg などのラベルで運用する場合は、Namespace に ラベルを付与できるユーザによって自由に変更が可能になっている側面を持つことに留意する

namespaces:
  from: Selector
  selector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: In
      values:
      - foo
      - bar
kkk777kkk777

https://gateway-api.sigs.k8s.io/concepts/versioning/#release-channels

Standard Channel の機能を使うのが丸そう。
Experimental Channel は破壊的変更が起きうる。

gateway api では、k8s の versioning では alpha > v1 のサイクル
ReferenceGrant だけ例外的に v1beta1

以下のように crd の annotation に種別が確認できる

gateway.networking.k8s.io/bundle-version: v0.4.0
gateway.networking.k8s.io/channel: standard|experimental

最新の k8s マイナーバージョンから、5バージョンを対応

kkk777kkk777

Gateway

Gateway.spec.Addresses で gateway に付与する IP などを指定できる。
ingress の Ingress.Spec.loadBalancerIP みたいなもの

GatewayClass

GatewayClass.spec.controller は versioning で管理するのが推奨

example.net/gateway/v1   // Use version 1
example.net/gateway/v2.1 // Use version 2.1
example.net/gateway      // Use the default version

GatewayClass.spec.parametersRef で controller に指定させる変数とかを定義できる。
オススメは 設定項目を CRD で定義することだが、 configMap を使うことも可能。

# GatewayClass for Gateways that define Internet-facing applications.
kind: GatewayClass
metadata:
  name: internet
spec:
  controllerName: "example.net/gateway-controller"
  parametersRef:
    group: example.net/v1alpha1
    kind: Config
    name: internet-gateway-config
---
apiVersion: example.net/v1alpha1
kind: Config
metadata:
  name: internet-gateway-config
spec:
  ip-address-pool: internet-vips

HTTPRoute

gateway リソースの紐付けで、name を使って紐付けるか port 番号で紐づける方法がある

spec:
  parentRefs:
  - name: acme-lb
    sectionName: foo
spec:
  parentRefs:
  - name: acme-lb
    port: 8080

port 番号で紐づけることで、複数の listener を一度に紐づけることが利点であるが、
port 番号を変更することができなくなるので、変わることの予定ない port でのみ利用するのが良さそう

spec.rules.matches で条件を絞ることができる、1つでも満たせばOK の形式
未指定の場合は、"/" の prefix となり、全てを許可する

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
...
spec:
  rules:
  - matches:
    - path:
        value: "/foo"
      headers:
      - name: "version"
        value: "2"
    - path:
        value: "/v2/foo"

spec.rules.filters で、 header の追加などの処理を挟むことができる。
spec.rules.timeouts で、timeout を設定できる。(アルファ)

  • request : gateway がリクエストを受けてから、レスポンスを返すまで
  • backendRequest : gateway からバックエンドにリクエストを投げてからレスポンスが返ってくるまで

GRPCRoute

HTTPRoute と GRPCRoute のホスト名はコンフリクトに留意する必要がある。
従って、gRPC と HTTPS の両方で通信したい場合、ホスト名を分ける必要がある。
ホスト名を分けない場合、HTTPRoute で両方の通信を設定する必要がある。

kkk777kkk777

redirect filter と rewrite filter は同時に使えない
https://gateway-api.sigs.k8s.io/guides/http-redirect-rewrite/#http-path-redirects-and-rewrites

weight はパーセントではなく、すべての総和が母数となる
https://gateway-api.sigs.k8s.io/guides/traffic-splitting/

filter で RequestMirror を使えば、単一の svc という制約があるが、リクエストをミラーリングして送れる。そのレスポンスはクライアントに返らないので、 blue green リリースなどで有用そう
https://gateway-api.sigs.k8s.io/guides/http-request-mirroring/