Kubernetes Gateway APIとEnvoy Gateway

Kubernetes Ingress APIは、その基盤をなすものですが、高度なトラフィック管理ポリシー、ロールベースのアクセス制御、プロトコルを意識したルーティングを表現する上で、本質的な限界を抱えています。これらの制約により、ベンダー固有のアノテーションやカスタムリソース定義（CRD）が必要となることが多く、設定が断片化し、ポータビリティが低下していました。Kubernetes Gateway APIは、より表現力豊かで、拡張性が高く、ロール指向のトラフィック管理アプローチを提供することで、戦略的な後継として登場しました。

このガイドでは、Ingress-NGINXからKubernetes Gateway APIへのアーキテクチャの移行について、特にEnvoy Gatewayを活用することに焦点を当てて詳しく説明します。Gateway APIのコアリソース、高度なトラフィックルーティングパターン、グローバルレートリミットの実装、cert-managerによるTLS終端の自動化、そしてゼロダウンタイム移行戦略の概要について解説します。

Audio Briefing• Voice: Google Cloud ja-JP-Neural2-B

0:00 / 0:00

Kubernetes Gateway APIを理解する

Gateway APIは、Ingress APIの欠点を解消するために設計された、イングレストラフィック管理のための構造化された階層モデルを導入しています。これにより、インフラプロバイダー、クラスターオペレーター、アプリケーション開発者といった異なるペルソナ間で関心を分離します。

コアリソース

Gateway APIは、いくつかの主要なリソースを定義しています。

GatewayClass:
- 永続ボリュームのStorageClassと同様に、Gatewayのクラスを定義します。
- このクラスのGatewayのプロビジョニングと管理を担当するコントローラーを指定します（例：envoy-gateway）。
- インフラプロバイダーによって管理されます。
yaml
```
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: eg-standard
spec:
  controllerName: gateway.envoyproxy.io/gatewayclass-controller
  description: Envoy Gateway managed by Envoy Gateway project.
```

Gateway:

クラスターへのトラフィックの論理的なエントリーポイントを表します。
実際のロードバランサーまたはプロキシ（例：EnvoyプロキシのデプロイメントとLoadBalancerサービス）をプロビジョニングします。
リスナー（ポート、プロトコル、ホスト名）を指定し、GatewayClassを参照します。
クラスターオペレーターによって管理されます。

yaml

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: eg-gateway
  namespace: envoy-gateway-system
spec:
  gatewayClassName: eg-standard
  listeners:
    - name: http
      protocol: HTTP
      port: 80
      allowedRoutes:
        namespaces:
          from: All
    - name: https
      protocol: HTTPS
      port: 443
      tls:
        mode: Terminate
        certificateRefs:
          - kind: Secret
            name: example-com-tls
      allowedRoutes:
        namespaces:
          from: All

HTTPRoute:
- GatewayからバックエンドサービスへのHTTP/HTTPSトラフィックのルーティングルールを定義します。
- ホスト、パス、ヘッダー、クエリパラメータのマッチングをサポートします。
- 重み付けされたトラフィック分割、リダイレクト、リライトなどの高度な機能を有効にします。
- アプリケーション開発者によって管理されます。
yaml
```
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: example-httproute
  namespace: default
spec:
  parentRefs:
    - name: eg-gateway
      namespace: envoy-gateway-system
  hostnames:
    - "example.com"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      backendRefs:
        - name: my-service
          port: 8080
```

GRPCRoute:

gRPCトラフィックに特化したルートで、gRPCサービス名とメソッド名によるマッチングを可能にします。
アプリケーション開発者によって管理されます。

yaml

apiVersion: gateway.networking.k8s.io/v1
kind: GRPCRoute
metadata:
  name: example-grpcroute
  namespace: default
spec:
  parentRefs:
    - name: eg-gateway
      namespace: envoy-gateway-system
  hostnames:
    - "grpc.example.com"
  rules:
    - matches:
        - method:
            service: "com.example.MyService"
            method: "MyMethod"
      backendRefs:
        - name: my-grpc-service
          port: 50051

TLSRoute:
- SNI（Server Name Indication）に基づいてTLSトラフィックをバックエンドサービスにルーティングします。
- 通常、パススルーTLSや、バックエンドサービスがTLS終端を処理する場合に使用されます。
- アプリケーション開発者によって管理されます。
yaml
```
apiVersion: gateway.networking.k8s.io/v1
kind: TLSRoute
metadata:
  name: example-tlsroute
  namespace: default
spec:
  parentRefs:
    - name: eg-gateway
      namespace: envoy-gateway-system
  hostnames:
    - "secure.example.com"
  rules:
    - backendRefs:
        - name: my-secure-service
          port: 8443
```

アーキテクチャ上の利点

ロールベースの分離: インフラ、クラスター、アプリケーションチームの責任を明確に定義します。
拡張性: Policy CRDを使用して、ポリシー（例：レート制限、認証）を様々なレベル（Gateway、Route、Service）でアタッチできます。
プロトコル認識: IngressのHTTPのみの制限を超え、HTTP、HTTPS、gRPC、TCP/UDPをネイティブにサポートします。
ポータビリティ: 標準化されたAPIにより、ベンダーロックインを軽減し、実装間の移行を簡素化します。

Envoy Gatewayの紹介

Envoy Gatewayは、Gateway APIの実装としてEnvoyプロキシをプロビジョニングおよび管理するために設計された公式のEnvoyプロジェクトです。これはコントロールプレーンとして機能し、Gateway APIリソースをEnvoyの動的設定（xDS API）に変換します。

なぜEnvoy Gatewayなのか？

パフォーマンス: 高性能、低レイテンシー、堅牢な機能セットで知られるEnvoy Proxyを基盤としています。
拡張性: Envoyのフィルターチェーンアーキテクチャを活用し、高度なトラフィック操作を実現します。
成熟したエコシステム: Envoy Proxyプロジェクトの豊富な機能とコミュニティサポートの恩恵を受けます。
高度な機能: 重み付けされたロードバランシング、サーキットブレーキング、グローバルレート制限、高度な可観測性などをすぐに利用できます。
公式サポート: 公式のEnvoyプロジェクトであるため、Envoyのロードマップとベストプラクティスとの整合性が保証されます。

比較: Ingress-NGINX vs. Envoy Gateway

| 機能 / メトリック | Ingress-NGINX | Envoy Gateway (Gateway APIを使用) | トレードオフ

What about Ingress-NGINX?

This guide focuses on migrating from Ingress-NGINX to the Gateway API. While the Gateway API is a general-purpose API, Envoy Gateway is a specific implementation that leverages the power of Envoy Proxy.

Prerequisites

Before we dive into the migration, ensure you have the following:

A Kubernetes cluster (version 1.24 or higher).
kubectl configured to access your cluster.
Helm (version 3.x) installed.
Basic understanding of Kubernetes concepts (Pods, Services, Deployments, Ingress).
Familiarity with Ingress-NGINX configurations.

Installation of Envoy Gateway

First, let's install Envoy Gateway into your Kubernetes cluster. We'll use Helm for this.

Add the Envoy Gateway Helm repository:

bash

helm repo add envoygateway https://envoyproxy.github.io/envoy-gateway/
helm repo update

Install Envoy Gateway:

bash

helm install envoy-gateway envoygateway/envoy-gateway --version 1.0.0 -n envoy-gateway --create-namespace

Verify the installation:

bash

kubectl get pods -n envoy-gateway

You should see pods for envoy-gateway and envoy-gateway-bootstrap running.

Deploying a Sample Application

To demonstrate traffic management, let's deploy a simple "Hello World" application.

bash

kubectl create deployment hello-world --image=gcr.io/google-samples/hello-app:1.0
kubectl expose deployment hello-world --port=80 --target-port=8080

Verify the application is running:

bash

kubectl get pods -l app=hello-world
kubectl get svc hello-world

Migrating Ingress-NGINX to Gateway API

Now, let's walk through the migration process. We'll start with a basic Ingress-NGINX configuration and translate it to Gateway API resources.

Step 1: Basic HTTP Routing

Consider a simple Ingress-NGINX configuration that routes traffic for example.com to our hello-world service:

yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello-world-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: hello-world
            port:
              number: 80

To achieve the same with Gateway API, we need a GatewayClass, a Gateway, and an HTTPRoute.

First, let's define our GatewayClass. Envoy Gateway automatically creates a default GatewayClass named eg upon installation. We'll use that.

Next, create a Gateway resource. This will provision an external load balancer for our traffic.

yaml

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
spec:
  gatewayClassName: eg
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    hostname: "example.com"

Apply this Gateway:

bash

kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
spec:
  gatewayClassName: eg
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    hostname: "example.com"
EOF

Wait for the Gateway to be provisioned and get its address:

bash

kubectl get gateway example-gateway

You should see an external IP address or hostname assigned to the Gateway. Make a note of it.

Now, let's create an HTTPRoute to route traffic from example.com to our hello-world service.

yaml

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: hello-world-route
spec:
  parentRefs:
  - name: example-gateway
  hostnames:
  - "example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: hello-world
      port: 80

Apply this HTTPRoute:

bash

kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: hello-world-route
spec:
  parentRefs:
  - name: example-gateway
  hostnames:
  - "example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: hello-world
      port: 80
EOF

Test the routing. You'll need to update your /etc/hosts file (or equivalent) to point example.com to the Gateway's external IP address.

bash

curl -H "Host: example.com" http://<GATEWAY_EXTERNAL_IP>

You should receive the "Hello World" response.

Step 2: TLS Termination with `cert-manager`

Ingress-NGINX typically handles TLS termination using secrets containing certificates. With Gateway API, we can automate this using cert-manager.

First, ensure cert-manager is installed in your cluster. If not, you can install it via Helm:

bash

helm repo add jetstack https://charts.jetstack.io
helm repo update
helm install cert-manager jetstack/cert-manager --namespace cert-manager --create-namespace --version v1.13.2 --set installCRDs=true

Next, we'll create a ClusterIssuer (or Issuer) resource for cert-manager. For this example, we'll use a self-signed issuer for simplicity. In a production environment, you would use a Let's Encrypt issuer.

yaml

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: selfsigned-issuer
spec:
  selfSigned: {}

Apply the ClusterIssuer:

bash

kubectl apply -f - <<EOF
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: selfsigned-issuer
spec:
  selfSigned: {}
EOF

Now, modify our Gateway to listen on HTTPS and reference a Certificate resource that cert-manager will manage.

yaml

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
spec:
  gatewayClassName: eg
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    hostname: "example.com"
    # Redirect HTTP to HTTPS
    # This is an Envoy Gateway specific extension
    # For general Gateway API, you'd use an HTTPRoute for redirection
    # filters:
    # - type: RequestRedirect
    #   requestRedirect:
    #     scheme: https
    #     statusCode: 301
  - name: https
    protocol: HTTPS
    port: 443
    hostname: "example.com"
    tls:
      mode: Terminate
      certificateRefs:
      - kind: Secret
        name: example-com-tls

Apply the updated Gateway:

bash

kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
spec:
  gatewayClassName: eg
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    hostname: "example.com"
  - name: https
    protocol: HTTPS
    port: 443
    hostname: "example.com"
    tls:
      mode: Terminate
      certificateRefs:
      - kind: Secret
        name: example-com-tls
EOF

Next, create a Certificate resource that tells cert-manager to issue a certificate for example.com using our selfsigned-issuer and store it in a secret named example-com-tls.

yaml

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: example-com
spec:
  secretName: example-com-tls
  dnsNames:
  - example.com
  issuerRef:
    name: selfsigned-issuer
    kind: ClusterIssuer

Apply the Certificate:

bash

kubectl apply -f - <<EOF
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: example-com
spec:
  secretName: example-com-tls
  dnsNames:
  - example.com
  issuerRef:
    name: selfsigned-issuer
    kind: ClusterIssuer
EOF

Wait for cert-manager to issue the certificate. You can check the status:

bash

kubectl get certificate example-com
kubectl get secret example-com-tls

Once the secret example-com-tls is ready, test HTTPS access:

bash

curl -k -H "Host: example.com" https://<GATEWAY_EXTERNAL_IP>

The -k flag is used to bypass self-signed certificate warnings. In a production setup with a trusted issuer, you wouldn't need it.

Step 3: Advanced Traffic Routing (Weighted Split)

Ingress-NGINX supports weighted traffic splitting through annotations or by defining multiple backends with weights. Gateway API provides native support for this.

Let's deploy a second version of our hello-world application:

bash

kubectl create deployment hello-world-v2 --image=gcr.io/google-samples/hello-app:2.0
kubectl expose deployment hello-world-v2 --port=80 --target-port=8080

Now, modify our HTTPRoute to split traffic 80/20 between hello-world (v1) and hello-world-v2.

yaml

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: hello-world-route
spec:
  parentRefs:
  - name: example-gateway
  hostnames:
  - "example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: hello-world
      port: 80
      weight: 80
    - name: hello-world-v2
      port: 80
      weight: 20

Apply the updated HTTPRoute:

bash

kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: hello-world-route
spec:
  parentRefs:
  - name: example-gateway
  hostnames:
  - "example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: hello-world
      port: 80
      weight: 80
    - name: hello-world-v2
      port: 80
      weight: 20
EOF

Test the weighted split by sending multiple requests:

bash

for i in $(seq 1 10); do curl -k -H "Host: example.com" https://<GATEWAY_EXTERNAL_IP>; done

You should see a mix of "Hello, world!" and "Hello, world! Version: 2.0.0" responses, roughly in an 80/20 ratio.

Step 4: Global Rate Limiting

Ingress-NGINX offers rate limiting through annotations. Envoy Gateway, leveraging Envoy Proxy, provides robust and flexible rate limiting capabilities. We'll implement a global rate limit using an EnvoyGatewayRateLimit resource (an Envoy Gateway specific CRD).

First, ensure the RateLimit API is enabled in your Envoy Gateway configuration. By default, it should be.

Next, define a RateLimit resource. This example limits requests to 5 per minute per client IP.

yaml

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: RateLimit
metadata:
  name: global-rate-limit
spec:
  # Apply this rate limit to all HTTPRoutes attached to example-gateway
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: example-gateway
  rules:
  - clientSelectors:
    - ip: {} # Apply to all client IPs
    limit:
      requests: 5
      unit: Minute

Apply the RateLimit:

bash

kubectl apply -f - <<EOF
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: RateLimit
metadata:
  name: global-rate-limit
spec:
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: example-gateway
  rules:
  - clientSelectors:
    - ip: {}
    limit:
      requests: 5
      unit: Minute
EOF

Test the rate limit by sending more than 5 requests within a minute:

bash

for i in $(seq 1 10); do curl -k -H "Host: example.com" https://<GATEWAY_EXTERNAL_IP>; sleep 5; done

After the 5th request, subsequent requests within the minute should receive a 429 Too Many Requests response.

Zero-Downtime Migration Strategy

Migrating from Ingress-NGINX to Gateway API with zero downtime involves a careful, phased approach.

Deploy Envoy Gateway alongside Ingress-NGINX: Install Envoy Gateway and configure its Gateway resources to listen on different ports or hostnames initially, or use a separate external IP. Do NOT point your production DNS to the Envoy Gateway yet.
Translate Ingress rules to Gateway API: Systematically convert your Ingress-NGINX configurations (Ingress resources, ConfigMaps, Secrets, annotations) into equivalent Gateway API resources (GatewayClass, Gateway, HTTPRoute, TLSRoute, GRPCRoute, TCPRoute, UDPRoute, RateLimit, etc.).
Test thoroughly: Before any traffic cutover, extensively test the Envoy Gateway setup in a staging environment. Ensure all routing rules, TLS termination, and advanced policies work as expected.
Gradual DNS Cutover:
- Phase 1 (Canary): Update a small percentage of your DNS traffic (e.g., 5-10%) to point to the Envoy Gateway's external IP. Monitor metrics, logs, and error rates closely for any anomalies.
- Phase 2 (Incremental): If Phase 1 is stable, gradually increase the percentage of traffic directed to Envoy Gateway (e.g., 25%, 50%, 75%). Continue monitoring.
- Phase 3 (Full Cutover): Once confident, update 100% of your DNS traffic to point to the Envoy Gateway.
Rollback Plan: Always have a clear rollback plan. If any issues arise during the cutover, be prepared to revert DNS changes to point back to Ingress-NGINX.
Decommission Ingress-NGINX: After a successful and stable migration, you can safely remove Ingress-NGINX from your cluster.

Conclusion

The Kubernetes Gateway API, implemented by Envoy Gateway, offers a powerful and flexible evolution for managing ingress traffic in Kubernetes. By adopting a role-oriented design, native support for advanced routing, and extensibility through policies, it addresses many limitations of the traditional Ingress API. This guide provided a practical walkthrough for migrating common Ingress-NGINX patterns to Envoy Gateway, including basic HTTP routing, automated TLS termination with cert-manager, weighted traffic splitting, and global rate limiting, along with a strategy for zero-downtime migration. Embracing the Gateway API positions your Kubernetes infrastructure for more robust, scalable, and maintainable traffic management.

Next, you might want to explore:

Custom Filters: Leverage Envoy's extensive filter capabilities for even more advanced traffic manipulation.
Authentication/Authorization: Integrate with external identity providers for fine-grained access control.
Observability: Dive deeper into Envoy's rich metrics, logging, and distributed tracing capabilities.

Feel free to share your thoughts and experiences in the comments below!


## Installation and Initial Setup

This section outlines the deployment of Envoy Gateway and the initial configuration of Gateway API resources.

### Prerequisites

*   A running Kubernetes cluster (v1.24+).
*   `kubectl` configured to connect to your cluster.
*   `helm` (v3.x+) installed.

### Installing Envoy Gateway

Envoy Gateway is typically installed via Helm.

```bash
# 1. Envoy Gateway Helmリポジトリを追加する
helm repo add envoy-gateway https://envoyproxy.github.io/gateway/
helm repo update

# 2. Envoy Gateway用の名前空間を作成する
kubectl create namespace envoy-gateway-system

# 3. Envoy Gatewayをインストールする
helm install envoy-gateway envoy-gateway/envoy-gateway -n envoy-gateway-system --version v0.0.0 # 最新の安定バージョンに置き換えてください

Verify the installation:

bash

kubectl get pods -n envoy-gateway-system
# 期待される出力 (例):
# NAME                                        READY   STATUS    RESTARTS   AGE
# envoy-gateway-7b8c7d4f5-abcde               1/1     Running   0          2m
# envoy-gateway-bootstrap-7b8c7d4f5-abcde     1/1     Running   0          2m
# eg-gateway-proxy-7b8c7d4f5-abcde            1/1     Running   0          2m

kubectl get gatewayclass
# 期待される出力:
# NAME         CONTROLLER                         ACCEPTED   AGE
# eg-standard  gateway.envoyproxy.io/gatewayclass-controller   True       2m

Deploying a Basic Gateway

After installation, the eg-standard GatewayClass is available. Now, deploy a Gateway resource that will provision an external LoadBalancer.

yaml

# gateway.yaml
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: eg-public-gateway
  namespace: envoy-gateway-system # ゲートウェイは通常、コントローラの名前空間にデプロイされます
spec:
  gatewayClassName: eg-standard
  listeners:
    - name: http
      protocol: HTTP
      port: 80
      allowedRoutes:
        namespaces:
          from: All # どの名前空間からのHTTPRouteもアタッチを許可する
    - name: https
      protocol: HTTPS
      port: 443
      tls:
        mode: Terminate
        certificateRefs:
          - kind: Secret
            name: default-tls-cert # このシークレットは後でcert-managerで作成されます
      allowedRoutes:
        namespaces:
          from: All # どの名前空間からのHTTPRouteもアタッチを許可する

Apply the Gateway:

bash

kubectl apply -f gateway.yaml

Monitor the Gateway status until an external IP/hostname is assigned:

bash

kubectl get gateway eg-public-gateway -n envoy-gateway-system -w
# 期待される出力 (例):
# NAME              CLASS         ADDRESS         READY   HTTP    HTTPS   AGE
# eg-public-gateway eg-standard   <pending>       False   80      443     10s
# ...
# eg-public-gateway eg-standard   192.0.2.123     True    80      443     2m

Note the ADDRESS assigned to your Gateway. This is the external IP/hostname you will point your DNS records to.

Core Routing Concepts with Envoy Gateway

This section demonstrates how to configure various routing patterns using Gateway API resources.

6.1. HTTPRoute

HTTPRoute is the primary resource for routing HTTP/HTTPS traffic.

Basic Path-Based Routing

Route requests to /api/v1 to my-api-service and /web to my-web-service.

yaml

# services.yaml (バックエンドサービスの例)
apiVersion: v1
kind: Service
metadata:
  name: my-api-service
spec:
  selector:
    app: my-api
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-api-deployment
spec:
  selector:
    matchLabels:
      app: my-api
  template:
    metadata:
      labels:
        app: my-api
    spec:
      containers:
        - name: api
          image: nginxdemos/hello:latest # プレースホルダーイメージ
          ports:
            - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: my-web-service
spec:
  selector:
    app: my-web
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-web-deployment
spec:
  selector:
    matchLabels:
      app: my-web
  template:
    metadata:
      labels:
        app: my-web
    spec:
      containers:
        - name: web
          image: nginxdemos/hello:latest # プレースホルダーイメージ
          ports:
            - containerPort: 8080

yaml

# httproute-path.yaml
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: path-routing-example
  namespace: default
spec:
  parentRefs:
    - name: eg-public-gateway
      namespace: envoy-gateway-system
  hostnames:
    - "app.example.com"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api/v1
      backendRefs:
        - name: my-api-service
          port: 80
    - matches:
        - path:
            type: PathPrefix
            value: /web
      backendRefs:
        - name: my-web-service
          port: 80

Apply these manifests:

bash

kubectl apply -f services.yaml
kubectl apply -f httproute-path.yaml

Requests to http://app.example.com/api/v1/users will go to my-api-service, and http://app.example.com/web/index.html to my-web-service.

Header-Based Routing

Route traffic based on the presence or value of an HTTP header. This is useful for A/B testing or routing internal tools.

yaml

# httproute-header.yaml
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: header-routing-example
  namespace: default
spec:
  parentRefs:
    - name: eg-public-gateway
      namespace: envoy-gateway-system
  hostnames:
    - "app.example.com"
  rules:
    - matches:
        - headers:
            - name: X-Internal-User
              value: "true"
          path:
            type: PathPrefix
            value: /admin
      backendRefs:
        - name: my-admin-service # このサービスが存在すると仮定
          port: 80
    - matches:
        - path:
            type: PathPrefix
            value: /admin
      backendRefs:
        - name: my-public-service # このサービスが存在すると仮定
          port: 80

In this example, requests to app.example.com/admin with X-Internal-User: true header will go to my-admin-service, otherwise to my-public-service.

6.2. GRPCRoute

GRPCRoute enables routing based on gRPC service and method names.

yaml

# grpc-service.yaml (gRPCバックエンドの例)
apiVersion: v1
kind: Service
metadata:
  name: my-grpc-service
spec:
  selector:
    app: my-grpc-app
  ports:
    - protocol: TCP
      port: 50051
      targetPort: 50051
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-grpc-deployment
spec:
  selector:
    matchLabels:
      app: my-grpc-app
  template:
    metadata:
      labels:
        app: my-grpc-app
    spec:
      containers:
        - name: grpc-server
          image: grpc/go-grpc-example-server:latest # プレースホルダーgRPCサーバー
          ports:
            - containerPort: 50051

yaml

# grpcroute.yaml
apiVersion: gateway.networking.k8s.io/v1
kind: GRPCRoute
metadata:
  name: grpc-routing-example
  namespace: default
spec:
  parentRefs:
    - name: eg-public-gateway
      namespace: envoy-gateway-system
  hostnames:
    - "grpc.example.com"
  rules:
    - matches:
        - method:
            service: "helloworld.Greeter" # gRPCサービス名
            method: "SayHello" # gRPCメソッド名
            type: Exact
      backendRefs:
        - name: my-grpc-service
          port: 50051
    - matches:
        - method:
            service: "helloworld.Greeter"
            type: Exact # Greeterサービス下の任意のメソッドに一致
      backendRefs:
        - name: my-grpc-service
          port: 50051

Apply these manifests:

bash

kubectl apply -f grpc-service.yaml
kubectl apply -f grpcroute.yaml

6.3. TLSRoute

TLSRoute is used for SNI-based routing, typically for TLS passthrough where the backend service handles TLS termination.

yaml

# tls-service.yaml (TLSバックエンドの例)
apiVersion: v1
kind: Service
metadata:
  name: my-secure-service
spec:
  selector:
    app: my-secure-app
  ports:
    - protocol: TCP
      port: 8443
      targetPort: 8443
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-secure-deployment
spec:
  selector:
    matchLabels:
      app: my-secure-app
  template:
    metadata:
      labels:
        app: my-secure-app
    spec:
      containers:
        - name: secure-app
          image: nginxdemos/hello:latest # プレースホルダー、TLS対応アプリであるべき
          ports:
            - containerPort: 8443

yaml

# tlsroute.yaml
apiVersion: gateway.networking.k8s.io/v1
kind: TLSRoute
metadata:
  name: tls-routing-example
  namespace: default
spec:
  parentRefs:
    - name: eg-public-gateway
      namespace: envoy-gateway-system
      sectionName: https # HTTPSリスナーにアタッチ
  hostnames:
    - "secure.example.com"
  rules:
    - backendRefs:
        - name: my-secure-service
          port: 8443

Apply these manifests:

bash

kubectl apply -f tls-service.yaml
kubectl apply -f tlsroute.yaml

Kubernetes Gateway APIとEnvoy Gateway: Ingress-NGINXから最新のトラフィックルーティングへ

Kubernetes Gateway APIを理解する

コアリソース

アーキテクチャ上の利点

Envoy Gatewayの紹介

なぜEnvoy Gatewayなのか？

比較: Ingress-NGINX vs. Envoy Gateway

What about Ingress-NGINX?

Prerequisites

Installation of Envoy Gateway

Deploying a Sample Application

Migrating Ingress-NGINX to Gateway API

Step 1: Basic HTTP Routing

Step 2: TLS Termination with `cert-manager`

Step 3: Advanced Traffic Routing (Weighted Split)

Step 4: Global Rate Limiting

Zero-Downtime Migration Strategy

Conclusion

Deploying a Basic Gateway

Core Routing Concepts with Envoy Gateway

6.1. HTTPRoute

Basic Path-Based Routing

Header-Based Routing

6.2. GRPCRoute

6.3. TLSRoute

Stay Updated

Free In-Browser Developer Tools

Kubernetes Gateway API本番環境での利用: Ingress-NginxからEnvoyへの移行

KubernetesにおけるeBPFとCilium: 高スループットルーティング、ネットワークポリシー、Hubble可観測性

CiliumとCalico (eBPF利用): Kubernetesネットワークスループット、セキュリティ、サービスメッシュ

Kubernetes Gateway APIを理解する

コアリソース

アーキテクチャ上の利点

Envoy Gatewayの紹介

なぜEnvoy Gatewayなのか？

比較: Ingress-NGINX vs. Envoy Gateway

What about Ingress-NGINX?

Prerequisites

Installation of Envoy Gateway

Deploying a Sample Application

Migrating Ingress-NGINX to Gateway API

Step 1: Basic HTTP Routing

Step 2: TLS Termination with cert-manager

Step 3: Advanced Traffic Routing (Weighted Split)

Step 4: Global Rate Limiting

Zero-Downtime Migration Strategy

Conclusion

Deploying a Basic Gateway

Core Routing Concepts with Envoy Gateway

6.1. HTTPRoute

Basic Path-Based Routing

Header-Based Routing

6.2. GRPCRoute

6.3. TLSRoute

Stay Updated

Free In-Browser Developer Tools

Related Articles

Kubernetes Gateway API本番環境での利用: Ingress-NginxからEnvoyへの移行

KubernetesにおけるeBPFとCilium: 高スループットルーティング、ネットワークポリシー、Hubble可観測性

CiliumとCalico (eBPF利用): Kubernetesネットワークスループット、セキュリティ、サービスメッシュ

Step 2: TLS Termination with `cert-manager`