Envoy Gateway クイックスタート: 10 分で最初のリクエストを通す

この記事のゴールはシンプルです。思想はひとまず飛ばして、Envoy Gateway をまず動かします。 例の service にアクセスできれば、ドキュメントのトップページで止まっている人たちより、もう一歩先に進めています。

前提条件

少なくとも 1 つ、動作する Kubernetes cluster が必要です。たとえば:

• ローカル: kind, minikube, k3d
• クラウド: EKS, GKE, AKS
• 自宅 lab: K3s + MetalLB でも可

さらに必要なもの:

• kubectl
• helm
• LoadBalancer address を払い出せる cluster、または port-forward で試してもよい環境

⚠️ cluster が LoadBalancer をサポートしていない場合、公式ドキュメントは MetalLB との組み合わせを勧めています。外部 address がなくても終わりではありません。単に port-forward で検証するだけです。

Step 1: Envoy Gateway をインストールする

コントロールプレーンを入れます。

helm install eg oci://docker.io/envoyproxy/gateway-helm   --version v1.7.0   -n envoy-gateway-system   --create-namespace

起動完了を待ちます。

kubectl wait --timeout=5m -n envoy-gateway-system   deployment/envoy-gateway   --for=condition=Available

これが完了したら、Envoy Gateway controller は cluster 上で稼働しています。以後は Gateway API リソースを読み取り、対応する Envoy 設定を生成できます。

Step 2: 公式 Quickstart リソースを適用する

公式 repo には、次をまとめたサンプルが用意されています。

• GatewayClass
• Gateway
• HTTPRoute
• サンプル backend app

そのまま適用します。

kubectl apply -f   https://github.com/envoyproxy/gateway/releases/download/v1.7.0/quickstart.yaml   -n default

これは、公式チームがあなたのために完成済みのデモ一式を並べてくれているようなものです。まずは動かし、その後で分解して理解すれば十分です。

Step 3: トラフィックが流れていることを確認する

Option A: Cluster に LoadBalancer がある場合

Gateway の address を取得します。

export GATEWAY_HOST=$(kubectl get gateway/eg -o jsonpath='{.status.addresses[0].value}')

リクエストを送ります。

curl --verbose   --header "Host: www.example.com"   http://$GATEWAY_HOST/get

HTTP 200 が返れば、次を意味します。

• Gateway が有効な入口として動作している
• HTTPRoute が正常に attach されている
• backend service へ正しくルーティングされている

Option B: LoadBalancer がない場合は Port-Forward を使う

Envoy service を探します。

export ENVOY_SERVICE=$(kubectl get svc -n envoy-gateway-system   --selector=gateway.envoyproxy.io/owning-gateway-namespace=default,gateway.envoyproxy.io/owning-gateway-name=eg   -o jsonpath='{.items[0].metadata.name}')

ローカルの 8888 を Gateway の 80 へ forward します。

kubectl -n envoy-gateway-system port-forward service/${ENVOY_SERVICE} 8888:80

別の terminal で:

curl --verbose   --header "Host: www.example.com"   http://localhost:8888/get

これはローカル検証ルートです。少し裏口から入る感じはありますが、ルーティングが確認できるならそれで十分です。エンジニアリングはたまに「まず動かし、その後で美しくする」です。

うまく動かないときに最初に見る場所

ありがちな問題は Envoy Gateway 自体が壊れていることではなく、チェーンのどこかがつながっていないことです。

役立つコマンド:

kubectl get pods -n envoy-gateway-system
kubectl get gatewayclass
kubectl get gateway -A
kubectl get httproute -A
kubectl get svc,pod -n default

Gateway status を深く見るには:

kubectl get gateway/eg -o yaml

見るべきポイント:

• status.addresses
• Listener conditions
• route が accepted されたかどうか

さっき実際にやったこと

実行したコマンドは少ないですが、end-to-end の流れを一通り完了しています。

1. Envoy Gateway をインストールした
2. cluster にどの gateway controller を使うか伝える GatewayClass を作成した
3. 入口 port と protocol を宣言する Gateway を作成した
4. backend service へトラフィックを流す HTTPRoute を作成した
5. Envoy Gateway がその宣言を Envoy Proxy が実行できる設定へ変換した

これこそ Gateway API を使う価値です。書くのは Kubernetes リソースであって、proxy の設定ファイルを手で積み上げることではありません。

次の一歩

最初のリクエストが通ったので、次の記事では各リソースが実際に何をしているかを整理し、頭の中のモデルを作ります。 👉 コア概念