diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/automation/controlplanes/kro/cloud-dynamodb.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/automation/controlplanes/kro/cloud-dynamodb.md index b55e6972d..33eda9b4a 100644 --- a/website/i18n/ja/docusaurus-plugin-content-docs/current/automation/controlplanes/kro/cloud-dynamodb.md +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/automation/controlplanes/kro/cloud-dynamodb.md @@ -1,7 +1,7 @@ --- title: "クラウドリソースのプロビジョニング" sidebar_position: 6 -tmdTranslationSourceHash: 14aa0a06a6577684447440694dfb8ddd +tmdTranslationSourceHash: f478f189f68179b54c1919d629ea6ec3 --- このセクションでは、カートが使用しているインメモリデータベースをDynamoDBに置き換えます。WebApplicationのベーステンプレートを拡張してWebApplicationDynamoDB ResourceGraphDefinitionを構成することで実現します。 @@ -132,7 +132,7 @@ http://k8s-ui-ui-a9797f0f61.elb.us-west-2.amazonaws.com ロードバランサーがプロビジョニングを完了したことを確認するには、次のコマンドを実行できます： ```bash timeout=610 -curl --head -X GET --retry 30 --retry-all-errors --retry-delay 15 --connect-timeout 30 --max-time 60 \ +$ curl --head -X GET --retry 30 --retry-all-errors --retry-delay 15 --connect-timeout 30 --max-time 60 \ -k $(kubectl get ingress -n ui ui -o jsonpath="{.status.loadBalancer.ingress[*].hostname}") ``` diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/navigating-labs.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/navigating-labs.md index 77031ba93..c7eccc8a4 100644 --- a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/navigating-labs.md +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/navigating-labs.md @@ -1,7 +1,7 @@ --- title: ラボのナビゲーション sidebar_position: 30 -tmdTranslationSourceHash: '19c60d21bd5821a49af31787350fabab' +tmdTranslationSourceHash: 'c7e58b83cd9dad8d1b1ebf524ecb56c6' --- import Tabs from '@theme/Tabs'; @@ -22,7 +22,7 @@ import TabItem from '@theme/TabItem'; **AWS イベントに参加している場合**は、Workshop Studio のスタートページの下部にある *Event Outputs* セクションから IDE を開きます。 -Event Outputs copy/paste +Event Outputs copy/paste **自分のアカウントで実行している場合**は、CloudFormation スタックの Outputs タブで `IdeUrl` を見つけてください。詳細は[セットアップガイド](/docs/fastpaths/setup/your-account)を参照してください。 @@ -35,24 +35,24 @@ import TabItem from '@theme/TabItem'; ## ヒント ### コピー/ペースト権限 -ブラウザによっては、Code Server ターミナルへのコンテンツのコピー/ペーストの方法が異なる場合があります。 +ブラウザによっては、VS Code Terminal へのコンテンツのコピー/ペーストの方法が異なる場合があります。 ターミナルでコンテンツを最初にペーストしようとすると、次のようなブラウザのポップアップが表示されます: - Chrome copy/paste + Chrome copy/paste **Allow** ボタンをクリックして、この機能を有効にします。これ以降、コピー/ペーストは簡単になります。このワークショップでは、可能であれば Google Chrome の使用をお勧めします。 ターミナルでコンテンツをペーストしようとするたびに、マウスポインタの隣に次のスクリーンショットに示すような小さなボタンが表示されます。コピーしたコンテンツを実際にペーストするには、それをクリックする必要があります。 - Firefox/Safari copy/paste + Firefox/Safari copy/paste さらに、エディタウィンドウの右下隅に次のポップアップボックスが表示される場合がありますが、これは閉じて無視してかまいません。 - Firefox/Safari copy/paste + Firefox/Safari copy/paste diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/setup/your-account/index.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/setup/your-account/index.md index 35ceebc89..90c42ebdb 100644 --- a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/setup/your-account/index.md +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/setup/your-account/index.md @@ -1,7 +1,7 @@ --- title: あなたのAWSアカウントで sidebar_position: 30 -tmdTranslationSourceHash: '816ae7a5604c47cc743c1eddcfcdadec' +tmdTranslationSourceHash: 'a9ac429d98a155726091877652b40b3a' --- import Tabs from '@theme/Tabs'; @@ -33,37 +33,36 @@ import TabItem from '@theme/TabItem'; 画面の下部までスクロールして、IAM通知を承認してください： -acknowledge IAM +acknowledge IAM 次に、**Create stack**ボタンをクリックします： -Create Stack +Create Stack CloudFormationスタックのデプロイには約5分かかります。完了したら、**Outputs**タブから続行に必要な情報を取得できます： -cloudformation outputs +cloudformation outputs `IdeUrl`出力には、IDEにアクセスするためにブラウザに入力するURLが含まれています。`IdePasswordSecret`には、IDE用に生成されたパスワードを含むAWS Secrets Managerシークレットへのリンクが含まれています。 パスワードを取得するには、`IdePasswordSecret`URLを開き、**Retrieve**ボタンをクリックします： -secretsmanager retrieve +secretsmanager retrieve その後、パスワードをコピーできるようになります： -password in Secrets Manager +password in Secrets Manager 提供されたIDE URLを開くと、パスワードの入力を求められます： -IDE password prompt +IDE password prompt パスワードを送信すると、最初のIDE画面が表示されます： -IDE initial screen +IDE initial screen 次のステップは、ラボ演習を実行するためのEKSクラスターを作成することです。以下のガイドのいずれかに従って、これらのラボの要件を満たすクラスターをプロビジョニングしてください： - **(推奨)** [eksctl](./using-eksctl.md) - (近日公開予定！) [Terraform](./using-terraform.md)、興味がありますか？ [GitHubリポジトリ](https://github.com/aws-samples/eks-workshop-v2/issues)でお知らせください - (近日公開予定！) CDK - diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fundamentals/exposing/gateway-api/canary.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fundamentals/exposing/gateway-api/canary.md new file mode 100644 index 000000000..507655010 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fundamentals/exposing/gateway-api/canary.md @@ -0,0 +1,142 @@ +--- +title: "カナリアデプロイメント" +sidebar_position: 30 +tmdTranslationSourceHash: '9d9e00ea1be46189ef41abc4586cd177' +--- + +Gateway API は、重み付けトラフィック分割をネイティブにサポートしており、追加のツールや Service Mesh インフラストラクチャなしでカナリアデプロイメントを可能にします。このセクションでは、UI アプリケーションの新しいバージョンをデプロイし、HTTPRoute の重み付けを使用して、元のバージョンから新しいバージョンへトラフィックを段階的に移行します。 + +従来の Kubernetes Ingress では、重み付けトラフィック分割はネイティブにサポートされていません。これを実現するには、Istio や App Mesh のような Service Mesh が必要になります。Gateway API は、`backendRefs` の weight フィールドを通じて、これを第一級の機能として提供します。 + +## 新しい UI バージョンのデプロイ + +まず、UI アプリケーションの第 2 バージョン（`ui-v2`）をデプロイします。これはオレンジ色のテーマを使用しており、元の青色のテーマと視覚的に区別できます。 + +::yaml{file="manifests/modules/exposing/gateway-api/canary/deployment-ui-v2.yaml" paths="metadata.name,spec.template.spec.containers.0.env"} + +主な違いは `RETAIL_UI_THEME=orange` 環境変数で、これにより視覚的に異なるオレンジ色のテーマの UI が生成されます。 + +また、新しい Pod にトラフィックをルーティングするための Service も必要です。 + +::yaml{file="manifests/modules/exposing/gateway-api/canary/service-ui-v2.yaml" paths="metadata.name,spec.selector"} + +両方のリソースを適用します。 + +```bash +$ kubectl apply -f ~/environment/eks-workshop/modules/exposing/gateway-api/canary/deployment-ui-v2.yaml +$ kubectl apply -f ~/environment/eks-workshop/modules/exposing/gateway-api/canary/service-ui-v2.yaml +``` + +新しい Pod が準備完了になるまで待ちます。 + +```bash timeout=120 +$ kubectl wait --for=condition=Ready pods -l app.kubernetes.io/version=v2 -n ui --timeout=120s +``` + +## 90/10 カナリアルートの適用 + +次に、既存の `ui-route` HTTPRoute を、元の UI に 90%、ui-v2 に 10% のトラフィックを送信する重み付けバージョンに置き換えます。 + +::yaml{file="manifests/modules/exposing/gateway-api/canary/httproute-ui-canary.yaml" paths="spec.rules.0.backendRefs"} + +`backendRefs` フィールドに、明示的な `weight` 値を持つ 2 つのエントリが含まれていることに注目してください。Gateway コントローラーは、これらの重み付けに基づいてトラフィックを比例的に分散します。 + +カナリア HTTPRoute を適用します。 + +```bash hook=canary hookTimeout=180 +$ kubectl apply -f ~/environment/eks-workshop/modules/exposing/gateway-api/canary/httproute-ui-canary.yaml +``` + +## トラフィック分割のテスト + +Gateway に複数のリクエストを送信し、分散を観察します。約 10% のレスポンスがオレンジ色のテーマの ui-v2 から返されるはずです。 + +```bash timeout=60 +$ export GATEWAY_URL=$(kubectl get gateway retail-store-gateway -n ui -o jsonpath='{.status.addresses[0].value}') +$ for i in $(seq 1 20); do curl -s $GATEWAY_URL | grep "theme" ; done +href="/assets/css/theme-default.css"theme: { +href="/assets/css/theme-default.css"theme: { +href="/assets/css/theme-default.css"theme: { +href="/assets/css/theme-default.css"theme: { +href="/assets/css/theme-default.css"theme: { +href="/assets/css/theme-orange.css"theme: { +href="/assets/css/theme-default.css"theme: { +href="/assets/css/theme-default.css"theme: { +href="/assets/css/theme-default.css"theme: { +href="/assets/css/theme-default.css"theme: { +href="/assets/css/theme-default.css"theme: { +href="/assets/css/theme-default.css"theme: { +href="/assets/css/theme-default.css"theme: { +href="/assets/css/theme-orange.css"theme: { +href="/assets/css/theme-default.css"theme: { +href="/assets/css/theme-orange.css"theme: { +href="/assets/css/theme-default.css"theme: { +href="/assets/css/theme-default.css"theme: { +href="/assets/css/theme-default.css"theme: { +href="/assets/css/theme-orange.css"theme: { +``` + +ほとんどのレスポンスが `theme-default` を返し、20 回のリクエストのうち約 1〜2 回が `theme-orange` を返すことが確認でき、90/10 のトラフィック分割が機能していることがわかります。 + +## 50/50 へのトラフィック増加 + +新しいバージョンが正しく動作していることを確認したら、カナリアの重み付けを 50% に増やします。 + +::yaml{file="manifests/modules/exposing/gateway-api/canary/httproute-canary-50-50.yaml" paths="spec.rules.0.backendRefs"} + +```bash +$ kubectl apply -f ~/environment/eks-workshop/modules/exposing/gateway-api/canary/httproute-canary-50-50.yaml +``` + +再度テストして、均等な分割を確認します。 + +```bash timeout=60 +$ for i in $(seq 1 20); do curl -s $GATEWAY_URL | grep "theme" ; done +``` + +レスポンスの約半分がオレンジ色のテーマを返すことが確認できるはずです。 + +## ロールアウトの完了 + +新しいバージョンに満足したら、重み付けを 0/100 に設定して、すべてのトラフィックを ui-v2 に移行します。 + +::yaml{file="manifests/modules/exposing/gateway-api/canary/httproute-canary-0-100.yaml" paths="spec.rules.0.backendRefs"} + +```bash +$ kubectl apply -f ~/environment/eks-workshop/modules/exposing/gateway-api/canary/httproute-canary-0-100.yaml +``` + +すべてのトラフィックが新しいバージョンに移行したことを確認します。 + +```bash timeout=60 +$ for i in $(seq 1 20); do curl -s $GATEWAY_URL | grep "theme" ; done +``` + +すべてのレスポンスがオレンジ色のテーマを返し、ui-v2 への完全な切り替えが確認できるはずです。 + + + + + +## まとめ + +このセクションでは、Gateway API のネイティブな重み付けトラフィック分割を使用して、段階的なカナリアデプロイメントを実行しました。 + +1. 視覚的に区別できる新しいバージョンの UI をデプロイ +2. リスクを最小限に抑えるために 90/10 の分割で開始 +3. 新しいバージョンを検証した後、50/50 に増加 +4. 0/100 の分割でロールアウトを完了 + +### Gateway API と Ingress の比較 + +| 機能 | Gateway API | Kubernetes Ingress | +|---|---|---| +| 重み付けトラフィック分割 | `backendRefs` の重み付けによりネイティブサポート | ネイティブにサポートされていない | +| カナリアデプロイメント | 組み込み済み、追加ツール不要 | Service Mesh またはアノテーションが必要 | +| クロスネームスペースルーティング | `parentRefs` によりネイティブサポート | IngressGroup などの回避策が必要 | +| ロール指向モデル | GatewayClass → Gateway → HTTPRoute | 単一の Ingress リソース | +| ルートごとの複数バックエンド | 重み付けとフィルターによりネイティブサポート | パスごとに単一のバックエンドに制限 | +| 段階的ロールアウト | 宣言的な重み付け更新 | 外部コントローラーが必要 | + +Gateway API のネイティブなトラフィック分割により、カナリアデプロイメントが簡潔かつ宣言的になり、従来の Ingress で必要とされる追加の Service Mesh インフラストラクチャやカスタムアノテーションが不要になります。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fundamentals/exposing/gateway-api/exposing-ui.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fundamentals/exposing/gateway-api/exposing-ui.md new file mode 100644 index 000000000..f399f83e4 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fundamentals/exposing/gateway-api/exposing-ui.md @@ -0,0 +1,101 @@ +--- +title: "UI の公開" +sidebar_position: 10 +tmdTranslationSourceHash: 1efb3668b1217f800a23c87a73944820 +--- + +このセクションでは、UI アプリケーションを Application Load Balancer 経由で公開するために必要な Gateway API リソースを作成します。 + +## GatewayClass の作成 + +GatewayClass は、どのコントローラーが Gateway リソースの管理を担当するかを定義します。AWS Load Balancer Controller を使用する GatewayClass を作成します: + +::yaml{file="manifests/modules/exposing/gateway-api/exposing-ui/gatewayclass.yaml" paths="spec.controllerName"} + +これにより、`aws-alb` クラスを参照する Gateway は AWS Load Balancer Controller によって処理されることを Kubernetes に指示します。 + +GatewayClass を適用します: + +```bash +$ kubectl apply -f ~/environment/eks-workshop/modules/exposing/gateway-api/exposing-ui/gatewayclass.yaml +``` + +## Load Balancer の設定 + +LBC v3.x で Gateway API を使用する場合、Load Balancer の設定はアノテーションではなく `LoadBalancerConfiguration` CRD を通じて行われます。このリソースは ALB のスキームを定義します: + +::yaml{file="manifests/modules/exposing/gateway-api/exposing-ui/loadbalancerconfig.yaml" paths="spec.scheme"} + +`scheme: internet-facing` により、ALB がインターネットから公開アクセス可能になります。 + +LoadBalancerConfiguration を適用します: + +```bash +$ export SOURCE_RANGES=$(echo $INBOUND_CIDRS | jq -R 'split(",")') +$ cat ~/environment/eks-workshop/modules/exposing/gateway-api/exposing-ui/loadbalancerconfig.yaml | envsubst | kubectl apply -f - +``` + +## Gateway の作成 + +Gateway リソースは実際の Load Balancer インフラストラクチャをプロビジョニングします。これは GatewayClass と LoadBalancerConfiguration を参照します: + +::yaml{file="manifests/modules/exposing/gateway-api/exposing-ui/gateway.yaml" paths="spec.gatewayClassName,spec.infrastructure,spec.listeners"} + +重要なポイント: + +1. `gatewayClassName: aws-alb` は、この Gateway を作成した GatewayClass にリンクします +2. `infrastructure.parametersRef` は ALB 設定用の LoadBalancerConfiguration を参照します +3. リスナーはポート 80 で HTTP トラフィックを受け入れます + +Gateway を適用します: + +```bash timeout=600 +$ kubectl apply -f ~/environment/eks-workshop/modules/exposing/gateway-api/exposing-ui/gateway.yaml +$ kubectl wait --for=condition=Programmed gateway/retail-store-gateway -n ui --timeout=600s +``` + +## HTTPRoute の作成 + +HTTPRoute は、Gateway に到着したトラフィックをバックエンドサービスにどのようにルーティングするかを定義します。パスプレフィックス `/` を持つすべてのトラフィックを UI サービスにルーティングします: + +::yaml{file="manifests/modules/exposing/gateway-api/exposing-ui/httproute-ui.yaml" paths="spec.parentRefs,spec.rules"} + +1. `parentRefs` はこのルートを Gateway にリンクします +2. ルールは `/` で始まるすべてのパスに一致し、トラフィックをポート 80 の `ui` サービスに転送します + +HTTPRoute を適用します: + +```bash hook=exposing-ui hookTimeout=430 +$ kubectl apply -f ~/environment/eks-workshop/modules/exposing/gateway-api/exposing-ui/httproute-ui.yaml +``` + +## リソースの検証 + +すべてのリソースが正常に作成されたことを確認します: + +```bash +$ kubectl get gatewayclass +NAME CONTROLLER ACCEPTED AGE +aws-alb gateway.k8s.aws/alb True 2m +$ kubectl get gateway -n ui +NAME CLASS ADDRESS PROGRAMMED AGE +retail-store-gateway aws-alb k8s-ui-retailst-xxxxxxxxxx.us-west-2.elb.amazonaws.com True 2m +$ kubectl get httproute -n ui +NAME HOSTNAMES AGE +ui-route 2m +``` + +Gateway ALB 経由で UI にアクセスします: + +```bash +$ export GATEWAY_URL=$(kubectl get gateway retail-store-gateway -n ui -o jsonpath='{.status.addresses[0].value}') +$ echo "http://${GATEWAY_URL}" +http://k8s-ui-retailst-xxxxxxxxxx.us-west-2.elb.amazonaws.com +``` + +Gateway でプロビジョニングされた ALB を通じて、ブラウザで retail store の UI にアクセスできるようになりました。 + + + + + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fundamentals/exposing/gateway-api/index.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fundamentals/exposing/gateway-api/index.md new file mode 100644 index 000000000..2c4fded75 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fundamentals/exposing/gateway-api/index.md @@ -0,0 +1,41 @@ +--- +title: "Gateway API" +sidebar_position: 50 +sidebar_custom_props: { "module": true } +description: "Amazon Elastic Kubernetes Service で Gateway API を使用して Kubernetes サービスへのトラフィックを公開およびルーティングします。" +tmdTranslationSourceHash: '338809b8f6eb03de5933e964f77ac9a0' +--- + +::required-time + +:::tip 始める前に +このセクションに向けて環境を準備します: + +```bash timeout=300 wait=30 +$ prepare-environment exposing/gateway-api +``` + +これにより、ラボ環境に以下の変更が加えられます: + +- Gateway API CRD (Custom Resource Definition) のインストール +- AWS Load Balancer Controller Gateway API CRD のインストール +- AWS Load Balancer Controller 用の IAM role の作成 + +これらの変更を適用する Terraform は[こちら](https://github.com/VAR::MANIFESTS_OWNER/VAR::MANIFESTS_REPOSITORY/tree/VAR::MANIFESTS_REF/manifests/modules/exposing/gateway-api/.workshop/terraform)で確認できます。 + +::: + +[Gateway API](https://gateway-api.sigs.k8s.io/) は Kubernetes Ingress API の後継であり、クラスタへのトラフィックルーティングを管理するためのより表現力豊かで拡張可能なモデルを提供します。インフラストラクチャとルーティングの関心事を単一のリソースに結合する Ingress とは異なり、Gateway API は責任を分離するロール指向の設計を使用します: + +- **GatewayClass** — コントローラを定義します（インフラストラクチャプロバイダーが管理） +- **Gateway** — ロードバランサーインフラストラクチャをプロビジョニングします（クラスタオペレーターが管理） +- **HTTPRoute** — バックエンドサービスへのルーティングルールを定義します（アプリケーション開発者が管理） + +この分離により、異なるチームが独立して自分たちのリソースを管理でき、セキュリティと運用の明確性が向上します。 + +このモジュールでは、AWS Load Balancer Controller で Gateway API を使用して、サンプルアプリケーションへのトラフィックを公開およびルーティングする方法を探ります。以下の 3 つの主要なシナリオを取り上げます: + +1. **UI の公開** — GatewayClass、Gateway、HTTPRoute を作成して ALB をプロビジョニングし、UI サービスへのトラフィックをルーティングします +2. **パスベースルーティング** — Catalog API 用の 2 番目の HTTPRoute を追加し、複数のサービスが単一の Gateway（および ALB）をクロス namespace ルーティングで共有する方法を示します +3. **Canary Deployment** — 重み付けされたトラフィック分割を使用して、UI のあるバージョンから別のバージョンへ段階的にトラフィックをシフトします + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fundamentals/exposing/gateway-api/introduction.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fundamentals/exposing/gateway-api/introduction.md new file mode 100644 index 000000000..f1e873ac5 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fundamentals/exposing/gateway-api/introduction.md @@ -0,0 +1,67 @@ +--- +title: "コントローラーのデプロイ" +sidebar_position: 5 +tmdTranslationSourceHash: 'b2fbccdac6c96dae84b89bf2c3a59a3f' +--- + +以下の手順に従って、Gateway API サポートを有効にした AWS Load Balancer Controller をデプロイします。 + +`prepare-environment` ステップでは、すでに Gateway API の CRD がインストールされ、必要な IAM role が作成されています。ここでは、Helm を使用して AWS Load Balancer Controller をインストールします。 + +Gateway API サポートを有効にして AWS Load Balancer Controller をインストールします： + +```bash wait=30 +$ helm repo add eks-charts https://aws.github.io/eks-charts +$ helm upgrade --install aws-load-balancer-controller eks-charts/aws-load-balancer-controller \ + --version "${LBC_CHART_VERSION}" \ + --namespace "kube-system" \ + --set "clusterName=${EKS_CLUSTER_NAME}" \ + --set "serviceAccount.name=aws-load-balancer-controller-sa" \ + --set "serviceAccount.annotations.eks\\.amazonaws\\.com/role-arn"="$LBC_ROLE_ARN" \ + --set "defaultTargetType=ip" \ + --wait +Release "aws-load-balancer-controller" does not exist. Installing it now. +NAME: aws-load-balancer-controller +LAST DEPLOYED: [...] +NAMESPACE: kube-system +STATUS: deployed +REVISION: 1 +TEST SUITE: None +NOTES: +AWS Load Balancer controller installed! +``` + +コントローラーは Deployment として実行されます： + +```bash +$ kubectl get deployment -n kube-system aws-load-balancer-controller +NAME READY UP-TO-DATE AVAILABLE AGE +aws-load-balancer-controller 2/2 2 2 30s +``` + +クラスターで Gateway API の CRD が利用可能であることを確認します： + +```bash +$ kubectl get crds | grep gateway +gatewayclasses.gateway.networking.k8s.io [...] +gateways.gateway.networking.k8s.io [...] +httproutes.gateway.networking.k8s.io [...] +referencegrants.gateway.networking.k8s.io [...] +``` + +現在、クラスターには Gateway リソースはありません： + +```bash expectError=true +$ kubectl get gateway -A +No resources found +``` + +HTTPRoute リソースもありません： + +```bash expectError=true +$ kubectl get httproute -A +No resources found +``` + +コントローラーがデプロイされたので、Gateway API リソースを作成して Application Load Balancer 経由でアプリケーションを公開する準備が整いました。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fundamentals/exposing/gateway-api/path-based-routing.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fundamentals/exposing/gateway-api/path-based-routing.md new file mode 100644 index 000000000..bef9e36d9 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fundamentals/exposing/gateway-api/path-based-routing.md @@ -0,0 +1,99 @@ +--- +title: "パスベースルーティング" +sidebar_position: 20 +tmdTranslationSourceHash: '3ec3358cbfbf9332df120c0bae8b49e2' +--- + +Gateway API の主要な利点の1つは、単一の Gateway から複数の名前空間にまたがる複数のバックエンドサービスにトラフィックをルーティングできることです。このセクションでは、`/catalog` リクエストを Catalog API に転送する2つ目の HTTPRoute を追加し、既存の UI ルートは引き続き他のすべてのトラフィックを処理します。 + +## 現在の状態 + +現時点では、`ui` 名前空間に単一の HTTPRoute（`ui-route`）があり、パスプレフィックス `/` を持つすべてのトラフィックを UI サービスにルーティングしています： + +```bash +$ kubectl get httproute -n ui +NAME HOSTNAMES AGE +ui-route 5m +``` + +Gateway ALB へのすべてのリクエストは、パスに関係なく現在 UI アプリケーションに到達します。 + +## Catalog HTTPRoute の追加 + +`catalog` 名前空間に新しい HTTPRoute を作成し、パスプレフィックス `/catalog` を持つリクエストを Catalog サービスにルーティングします： + +::yaml{file="manifests/modules/exposing/gateway-api/path-based-routing/httproute-catalog.yaml" paths="metadata.namespace,spec.parentRefs,spec.rules"} + +重要なポイント： + +1. HTTPRoute は `catalog` 名前空間に作成され、ルーティング先のサービスと同じ場所に配置されます +2. `parentRefs` フィールドは `ui` 名前空間の Gateway `retail-store-gateway` を参照します — これが名前空間をまたぐルーティングです +3. ルールはパスプレフィックス `/catalog` を持つリクエストをマッチし、それらを `catalog` サービスのポート 80 に転送します + +Catalog HTTPRoute を適用します： + +```bash +$ kubectl apply -f ~/environment/eks-workshop/modules/exposing/gateway-api/path-based-routing/httproute-catalog.yaml +``` + +## Catalog ヘルスチェックの設定 + +catalog サービスは、デフォルトのルートパス `/` ではなく `/health` でヘルスエンドポイントを公開します。ALB にヘルスチェック場所を伝えるために `TargetGroupConfiguration` が必要です： + +::yaml{file="manifests/modules/exposing/gateway-api/path-based-routing/targetgroupconfig-catalog.yaml" paths="spec.targetReference,spec.defaultConfiguration.healthCheckConfig"} + +1. `targetReference` は catalog Service を識別します +2. `healthCheckPath: /health` は ALB に `/` の代わりに `/health` をチェックするよう指示します + +TargetGroupConfiguration を適用します： + +```bash hook=path-routing hookTimeout=180 +$ kubectl apply -f ~/environment/eks-workshop/modules/exposing/gateway-api/path-based-routing/targetgroupconfig-catalog.yaml +``` + +## 両方のルートを検証 + +両方の HTTPRoute が Gateway にアタッチされていることを確認します： + +```bash +$ kubectl get httproute -A +NAMESPACE NAME HOSTNAMES AGE +ui ui-route 5m +catalog catalog-route 30s +``` + +`/catalog` パスが Catalog API の JSON を返すことをテストします： + +```bash timeout=60 +$ export GATEWAY_URL=$(kubectl get gateway retail-store-gateway -n ui -o jsonpath='{.status.addresses[0].value}') +$ curl -s $GATEWAY_URL/catalog/products | jq . +``` + +Catalog サービスから製品データを含む JSON レスポンスが返されます。 + +ルートパス `/` がまだ UI を返すことを確認します： + +```bash +$ curl --head -X GET -s $GATEWAY_URL +HTTP/1.1 200 OK +Content-Type: text/html +Content-Length: 19973 +Connection: keep-alive +Content-Language: en-US +``` + +`Content-Type: text/html` レスポンスは UI サービスが `/` で応答していることを確認し、Catalog API は `/catalog` でアクセス可能になりました — 両方とも同じ Gateway ALB を通じて提供されています。 + +## 名前空間をまたぐルーティング + +このパターンは、Gateway API の従来の Ingress に対する主要な利点の1つを示しています。Ingress では、ルーティングルールとロードバランサー設定が単一のリソースに密結合されており、名前空間をまたいで ALB を共有するには IngressGroup アノテーションのような回避策が必要です。 + +Gateway API では、アーキテクチャが役割指向です： + +- **クラスター運用者**は1つの名前空間で Gateway（ロードバランサーインフラストラクチャ）を管理します +- **アプリケーションチーム**は自分の名前空間で HTTPRoute を作成し、`parentRefs` を介して共有 Gateway を参照します + +Catalog チームは、Gateway が存在する `ui` 名前空間へのアクセスを必要とせずに、`catalog` 名前空間で独立してルーティングルールを管理できます。Gateway コントローラーは、Gateway がリスナー設定を通じて許可していれば、アタッチメントを自動的に処理します。 + +この関心事の分離により、Gateway API は、異なるチームが異なるサービスを所有しながら共通のインフラストラクチャを共有するマルチチームクラスターに自然に適合します。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/helm/index.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/helm/index.md index 07852aec7..1e6c81f5a 100644 --- a/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/helm/index.md +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/helm/index.md @@ -2,7 +2,7 @@ title: Helm sidebar_custom_props: { "module": true } sidebar_position: 80 -tmdTranslationSourceHash: 9225a9fafd70ac2c086e8584ce39a4ac +tmdTranslationSourceHash: 94c98ab9ffe2f7ba7aa7d283813df7d2 --- ::required-time @@ -16,21 +16,21 @@ $ prepare-environment introduction/helm ::: -このワークショップでは主にKustomizeと対話しますが、EKSクラスターに特定のパッケージをインストールするためにHelmを使用する状況があります。このラボでは、Helmの簡単な紹介を行い、事前にパッケージ化されたアプリケーションをインストールする方法を示します。 +このワークショップでは主にKustomizeを使用しますが、EKSクラスターに特定のパッケージをインストールするためにHelmを使用する状況があります。このラボでは、Helmの簡単な紹介を行い、事前にパッケージ化されたアプリケーションをインストールする方法を示します。 :::info -このラボでは、独自のワークロード用のHelmチャートの作成については説明しません。このトピックの詳細については、[ガイド](https://helm.sh/docs/chart_template_guide/)を参照してください。 +このラボでは、独自のワークロード用のHelmチャートの作成については説明しません。このトピックの詳細については、こちらの[ガイド](https://helm.sh/docs/chart_template_guide/)を参照してください。 ::: -[Helm](https://helm.sh)はKubernetes用のパッケージマネージャーであり、Kubernetesアプリケーションの定義、インストール、アップグレードを支援します。Helmはチャートと呼ばれるパッケージングフォーマットを使用し、アプリケーションの実行に必要なすべてのKubernetesリソース定義が含まれています。Helmを使用することで、Kubernetesクラスター上でのアプリケーションのデプロイと管理が簡素化されます。 +[Helm](https://helm.sh)はKubernetes用のパッケージマネージャーであり、Kubernetesアプリケーションの定義、インストール、アップグレードを支援します。チャートと呼ばれるパッケージ形式を使用し、アプリケーションを実行するために必要なすべてのKubernetesリソース定義が含まれています。HelmはKubernetesクラスター上でのアプリケーションのデプロイと管理を簡素化します。 ## Helm CLI -`helm` CLIツールは通常、Kubernetesクラスターと組み合わせて使用され、アプリケーションのデプロイとライフサイクルを管理します。これにより、Kubernetes上でのアプリケーションデプロイの一貫性と再現性のあるパッケージ化、インストール、管理が容易になり、異なる環境間でのアプリケーションデプロイの自動化と標準化が容易になります。 +`helm` CLIツールは通常、Kubernetesクラスターと組み合わせて使用され、アプリケーションのデプロイとライフサイクルを管理します。Kubernetes上でのアプリケーションのパッケージ化、インストール、管理に一貫性のある再現可能な方法を提供し、さまざまな環境でのアプリケーションデプロイの自動化と標準化を容易にします。 -CLIはすでに私たちのIDEにインストールされています： +CLIはすでにIDEにインストールされています： ```bash $ helm version @@ -38,7 +38,7 @@ $ helm version ## Helmチャートのインストール -サンプルアプリケーションのUIコンポーネントをKustomizeマニフェストではなく、Helmチャートを使用してインストールしてみましょう。Helmパッケージマネージャーを使用してチャートをインストールすると、そのチャートに対して新しい**リリース**が作成されます。各リリースはHelmによって追跡され、他のリリースとは独立してアップグレード、ロールバック、またはアンインストールすることができます。 +Kustomizeマニフェストではなく、Helmチャートを使用してサンプルアプリケーションのUIコンポーネントをインストールしてみましょう。Helmパッケージマネージャーを使用してチャートをインストールすると、そのチャートの新しい**リリース**が作成されます。各リリースはHelmによって追跡され、他のリリースとは独立してアップグレード、ロールバック、またはアンインストールできます。 まず既存のUIアプリケーションを削除しましょう： @@ -46,7 +46,7 @@ $ helm version $ kubectl delete namespace ui ``` -次にチャートをインストールできます： +次にチャートをインストールします： ```bash hook=install $ helm install ui \ @@ -56,13 +56,13 @@ $ helm install ui \ --wait ``` -このコマンドを次のように分解できます： +このコマンドは次のように分解できます： -- Helmにチャートのインストールを指示する`install`サブコマンドを使用 +- `install`サブコマンドを使用してHelmにチャートのインストールを指示 - リリースに`ui`という名前を付ける - 特定のバージョンで[ECR Public](https://gallery.ecr.aws/aws-containers/retail-store-sample-ui-chart)にホストされているチャートを使用 -- チャートを`ui`名前空間にインストール -- リリース内のPodが準備完了状態になるのを待機 +- `ui`名前空間にチャートをインストール +- リリース内のPodが準備完了状態になるまで待機 チャートがインストールされたら、EKSクラスター内のリリースを一覧表示できます： @@ -72,7 +72,7 @@ NAME NAMESPACE REVISION UPDATED STATUS C ui ui 1 2024-06-11 03:58:39.862100855 +0000 UTC deployed retail-store-sample-ui-chart-X.X.X ``` -また、指定した名前空間で実行されているアプリケーションを確認できます： +また、指定した名前空間で実行されているアプリケーションも確認できます： ```bash $ kubectl get pod -n ui @@ -82,12 +82,12 @@ ui-55fbd7f494-zplwx 1/1 Running 0 119s ## チャートオプションの設定 -上記の例では、チャートを[デフォルト設定](https://github.com/aws-containers/retail-store-sample-app/blob/v1.2.1/src/ui/chart/values.yaml)でインストールしました。多くの場合、コンポーネントの動作を変更するためにインストール時にチャートに設定**値**を提供する必要があります。 +上記の例では、[デフォルト設定](https://github.com/aws-containers/retail-store-sample-app/blob/v1.2.1/src/ui/chart/values.yaml)でチャートをインストールしました。多くの場合、コンポーネントの動作を変更するために、インストール時にチャートに設定**値**を提供する必要があります。 インストール時にチャートに値を提供する一般的な方法は2つあります： 1. YAMLファイルを作成し、`-f`または`--values`フラグを使用してHelmに渡す -2. `--set`フラグに続けて`key=value`ペアを使用して値を渡す +2. `--set`フラグの後に`key=value`ペアを指定して値を渡す これらの方法を組み合わせてUIリリースを更新してみましょう。次の`values.yaml`ファイルを使用します： @@ -95,11 +95,11 @@ ui-55fbd7f494-zplwx 1/1 Running 0 119s manifests/modules/introduction/helm/values.yaml ``` -これにより、Podにいくつかのカスタムkubernetes注釈が追加され、UIテーマが上書きされます。 +これにより、Podにいくつかのカスタム Kubernetes アノテーションが追加され、UIテーマもオーバーライドされます。 :::tip[どの値を使用すればよいかわからない場合] -多くのHelmチャートはレプリカ数やPod注釈などの一般的な側面を設定するための比較的一貫した値を持っていますが、各Helmチャートには独自の一意の設定セットがあります。特定のチャートをインストールおよび設定する際は、そのドキュメントで利用可能な設定値を確認する必要があります。 +多くのHelmチャートは、レプリカやPodアノテーションなどの一般的な側面を設定するための比較的一貫した値を持っていますが、各Helmチャートには独自の設定セットがあります。特定のチャートをインストールおよび設定する際は、そのドキュメントで利用可能な設定値を確認する必要があります。 ::: @@ -144,7 +144,7 @@ ui-55fbd7f494-gkr2j 1/1 Running 0 30s ui-55fbd7f494-zplwx 1/1 Running 0 5m ``` -現在3つのレプリカが実行されていることがわかります。また、Deploymentを調査することで注釈が適用されたことを確認できます： +現在3つのレプリカが実行されていることが確認できます。また、Deploymentを調査することでアノテーションが適用されたことを確認できます： ```bash $ kubectl get -o yaml deployment ui -n ui | yq '.spec.template.metadata.annotations' @@ -154,139 +154,10 @@ my-annotation: my-value ## リリースの削除 -同様にCLIを使用してリリースをアンインストールすることもできます： +同様に、CLIを使用してリリースをアンインストールできます： ```bash $ helm uninstall ui --namespace ui --wait ``` -これにより、そのリリース用にチャートによって作成されたすべてのリソースがEKSクラスターから削除されます。 - -## Helmを使用したアプリケーションのデプロイ - -それでは、Helmを使用してリテールストアアプリケーションをデプロイする方法を見てみましょう。ワークショップでは主にKustomizeを使用しますが、多くのサードパーティアプリケーションがHelmチャートとして配布されているため、Helmを理解することは価値があります。 - -### Catalogサービス用のシンプルなチャートの作成 - -Helmでアプリケーションをパッケージ化してデプロイする方法を理解するために、catalogサービス用の基本的なHelmチャートを作成してみましょう： - -```bash -$ helm create retail-catalog -``` - -これにより、基本的なチャート構造が作成されます。作成されたものを見てみましょう： - -```bash -$ ls -la retail-catalog/ -total 8 -drwxr-xr-x 4 user user 128 Nov 15 10:30 . -drwxr-xr-x 3 user user 96 Nov 15 10:30 .. --rw-r--r-- 1 user user 1141 Nov 15 10:30 Chart.yaml -drwxr-xr-x 2 user user 64 Nov 15 10:30 charts -drwxr-xr-x 3 user user 96 Nov 15 10:30 templates --rw-r--r-- 1 user user 1862 Nov 15 10:30 values.yaml -``` - -### チャートのカスタマイズ - -catalogサービスをデプロイするためにデフォルトの値を変更しましょう。`values.yaml`ファイルを更新します： - -```bash -$ cat > retail-catalog/values.yaml <