Automated translation updates

  - Updated translations for: ja
  - Generated from commit: 2af0a49
  - Workflow run: 24564210637

Author: github-actions[bot]

website/i18n/ja/docusaurus-plugin-content-docs/current/automation/controlplanes/kro/provision-resources.md

@@ -1,10 +1,10 @@
 ---
 title: "kroによるリソースの作成"
 sidebar_position: 5
-tmdTranslationSourceHash: b9394e7175a82507b6f33e051b9ffbe3
+tmdTranslationSourceHash: 352f766cfce2da86190272b1db3df91b
 ---
 
-kroをインストールしたので、WebApplication ResourceGraphDefinitionsを使用して**Carts**コンポーネントをデプロイします。まず、再利用可能なWebApplication APIを定義するResourceGraphDefinitionテンプレートを確認しましょう：
+kroをインストールしたので、kro WebApplication ResourceGraphDefinitionsを使用して**Carts**コンポーネントをデプロイします。まず、再利用可能なWebApplication APIを定義するResourceGraphDefinitionテンプレートを確認しましょう：
 
 <details>
   <summary>RGDマニフェストの全容を表示</summary>
@@ -26,7 +26,7 @@ kroをインストールしたので、WebApplication ResourceGraphDefinitions
 ::yaml{file="manifests/modules/automation/controlplanes/kro/rgds/webapp-rgd.yaml" zoomPath="spec.schema.spec" zoomBefore="0"}
 
 :::info
-スキーマがどのようにデフォルト値と型定義を使用して、Kubernetesの複雑さを隠し、開発者に優しいAPIを作成しているかに注目してください。
+スキーマがどのようにデフォルト値と型定義を使用して、基礎となるKubernetesの複雑さを隠し、開発者に優しいAPIを作成しているかに注目してください。
 :::
 
 このWebApplication ResourceGraphDefinitionを使用して、インメモリデータベースを使用する**Carts**コンポーネントのインスタンスを作成します。まず、既存のcartsデプロイメントをクリーンアップしましょう：
@@ -44,7 +44,7 @@ deployment.apps "carts-dynamodb" deleted
 次に、WebApplication APIを登録するためにResourceGraphDefinitionを適用します：
 
 ```bash wait=10
-$ kubectl apply -f ~/environment/eks-workshop/modules/automation/controlplanes/kro/rgds/webapp-rgd.yaml
+$ cat ~/environment/eks-workshop/modules/automation/controlplanes/kro/rgds/webapp-rgd.yaml | envsubst | kubectl apply -f -
 resourcegraphdefinition.kro.run/web-application created
 ```
 

website/i18n/ja/docusaurus-plugin-content-docs/current/automation/gitops/argocd/access_argocd.md

@@ -2,7 +2,7 @@
 title: "Argo CDのインストール"
 sidebar_position: 10
 weight: 10
-tmdTranslationSourceHash: d56c4f4c50af1ff2a7b63644e2d44aeb
+tmdTranslationSourceHash: a732381699805dc3451f19017ace3eef
 ---
 
 まずはクラスターにArgo CDをインストールしましょう：
@@ -12,6 +12,7 @@ $ helm repo add argo-cd https://argoproj.github.io/argo-helm
 $ helm upgrade --install argocd argo-cd/argo-cd --version "${ARGOCD_CHART_VERSION}" \
   --namespace "argocd" --create-namespace \
   --values ~/environment/eks-workshop/modules/automation/gitops/argocd/values.yaml \
+  --set "server.service.annotations.service\\.beta\\.kubernetes\\.io/load-balancer-source-ranges"="$INBOUND_CIDRS" \
   --wait
 NAME: argocd
 LAST DEPLOYED: [...]

website/i18n/ja/docusaurus-plugin-content-docs/current/automation/gitops/argocd/gitea.md

@@ -1,7 +1,7 @@
 ---
 title: "Gitea のセットアップ"
 sidebar_position: 5
-tmdTranslationSourceHash: 65f16f55be12d2b448d3eac30d9a4841
+tmdTranslationSourceHash: 0cca9646f30f651e0ad39dd069a3bd31
 ---
 
 GitHub や GitLab の代わりに、迅速で簡単な代替手段として [Gitea](https://gitea.com) を使用します。Gitea は軽量な自己ホスト型 Git サービスで、ユーザーフレンドリーなウェブインターフェースを提供し、独自の Git リポジトリを迅速にセットアップおよび管理することができます。これは、Argo CD で探索する GitOps ワークフローに不可欠な Kubernetes マニフェストの保存とバージョン管理のための信頼できるソースとして機能します。
@@ -13,6 +13,8 @@ $ helm upgrade --install gitea oci://docker.gitea.com/charts/gitea \
   --version "$GITEA_CHART_VERSION" \
   --namespace gitea --create-namespace \
   --values ~/environment/eks-workshop/modules/automation/gitops/argocd/gitea/values.yaml \
+  --set "service.http.annotations.service\\.beta\\.kubernetes\\.io/load-balancer-source-ranges"="$INBOUND_CIDRS" \
+  --set "service.ssh.annotations.service\\.beta\\.kubernetes\\.io/load-balancer-source-ranges"="$INBOUND_CIDRS" \
   --set "gitea.admin.password=${GITEA_PASSWORD}" \
   --wait
 ```

website/i18n/ja/docusaurus-plugin-content-docs/current/automation/gitops/flux/gitea.md

@@ -1,7 +1,7 @@
 ---
 title: "Gitea のセットアップ"
 sidebar_position: 5
-tmdTranslationSourceHash: 81a4c85f3ba8bb568bde3044b3cdfecc
+tmdTranslationSourceHash: 3cb2d3f98584b410d0712934d5902c5d
 ---
 
 GitHubやGitLabの代わりとして、迅速かつ簡単な方法として[Gitea](https://gitea.com)を使用します。Giteaは軽量な自己ホスト型Gitサービスで、ユーザーフレンドリーなウェブインターフェースを提供し、独自のGitリポジトリを迅速に設定および管理することができます。これは、Fluxで探索するGitOpsワークフローに不可欠なKubernetesマニフェストを保存およびバージョン管理するための信頼できるソースとして機能します。
@@ -13,6 +13,8 @@ $ helm upgrade --install gitea oci://docker.gitea.com/charts/gitea \
   --version "$GITEA_CHART_VERSION" \
   --namespace gitea --create-namespace \
   --values ~/environment/eks-workshop/modules/automation/gitops/flux/gitea/values.yaml \
+  --set "service.http.annotations.service\\.beta\\.kubernetes\\.io/load-balancer-source-ranges"="$INBOUND_CIDRS" \
+  --set "service.ssh.annotations.service\\.beta\\.kubernetes\\.io/load-balancer-source-ranges"="$INBOUND_CIDRS" \
   --set "gitea.admin.password=${GITEA_PASSWORD}" \
   --wait
 ```
@@ -54,3 +56,4 @@ $ git config --global user.name "Your Name"
 $ git config --global init.defaultBranch main
 $ git config --global core.sshCommand 'ssh -i ~/.ssh/gitops_ssh.pem'
 ```
+

website/i18n/ja/docusaurus-plugin-content-docs/current/fundamentals/exposing/ingress/adding-ingress.md

@@ -1,21 +1,21 @@
 ---
 title: "Ingressの作成"
 sidebar_position: 20
-tmdTranslationSourceHash: 55ba2d304b8961fd6c8455b49eb75f66
+tmdTranslationSourceHash: 75afb2bdcdabdcb4e4411b96e8001b6c
 ---
 
 以下の構成で Ingress リソースを作成しましょう：
 
 ::yaml{file="manifests/modules/exposing/ingress/creating-ingress/ingress.yaml" paths="kind,metadata.annotations,spec.rules.0"}
 
 1. `Ingress` の種類を使用
-2. アノテーションを使用して、作成される ALB の様々な動作（ターゲットポッドに対して実行するヘルスチェックなど）を設定できます
+2. アノテーションを使用して、作成される ALB の様々な動作（ターゲットポッドに対して実行するヘルスチェックなど）を設定できます。`inbound-cidrs` アノテーションは、特定の CIDR 範囲へのインバウンドトラフィックを制限します
 3. rules セクションは、ALB がトラフィックをどのようにルーティングすべきかを表現するために使用されます。この例では、パスが `/` から始まる全ての HTTP リクエストを、ポート 80 で `ui` という名前の Kubernetes サービスにルーティングしています
 
 この設定を適用しましょう：
 
 ```bash timeout=180 hook=add-ingress hookTimeout=430
-$ kubectl apply -k ~/environment/eks-workshop/modules/exposing/ingress/creating-ingress
+$ kubectl kustomize ~/environment/eks-workshop/modules/exposing/ingress/creating-ingress | envsubst | kubectl apply -f -
 ```
 
 作成された Ingress オブジェクトを確認しましょう：
@@ -26,7 +26,7 @@ NAME   CLASS   HOSTS   ADDRESS                                            PORTS
 ui     alb     *       k8s-ui-ui-1268651632.us-west-2.elb.amazonaws.com   80      15s
 ```
 
-ALB はターゲットをプロビジョニングして登録するのに数分かかりますので、この Ingress 用にプロビジョニングされた ALB をより詳しく見てみましょう：
+ALB はターゲットをプロビジョニングして登録するのに数分かかりますので、この Ingress 用にプロビジョニングされた ALB の設定を詳しく見てみましょう：
 
 ```bash
 $ aws elbv2 describe-load-balancers --query 'LoadBalancers[?contains(LoadBalancerName, `k8s-ui-ui`) == `true`]'
@@ -97,7 +97,7 @@ $ aws elbv2 describe-target-health --target-group-arn $TARGET_GROUP_ARN
 }
 ```
 
-Ingress オブジェクトで IP モードを指定したので、ターゲットは `ui` ポッドの IP アドレスとトラフィックを提供するポートを使用して登録されます。
+Ingress オブジェクトで IP モードを指定したので、ターゲットは `ui` Pod の IP アドレスとトラフィックを提供するポートを使用して登録されます。
 
 次のリンクをクリックすると、コンソールで ALB とそのターゲットグループを確認することもできます：
 

website/i18n/ja/docusaurus-plugin-content-docs/current/fundamentals/exposing/ingress/external-dns.md

@@ -1,14 +1,14 @@
 ---
 title: "External DNS"
 sidebar_position: 30
-tmdTranslationSourceHash: b7f399a9ad32bbe99ece1082753fcd42
+tmdTranslationSourceHash: 9f9eabb2ce6f39f3e5e9524956100e15
 ---
 
 [ExternalDNS](https://github.com/kubernetes-sigs/external-dns)はKubernetesコントローラーで、クラスターのサービスとイングレス用のDNSレコードを自動的に管理します。KubernetesリソースとAWS Route 53などのDNSプロバイダーとの間の橋渡しとして機能し、DNSレコードがクラスターの状態と同期されるようにします。ロードバランサーにDNSエントリを使用することで、自動生成されたホスト名の代わりに人間が読みやすく、覚えやすいアドレスを提供し、組織のブランディングに合わせたドメイン名でサービスを簡単にアクセスおよび認識できるようにします。
 
-このラボでは、ExternalDNSとAWS Route 53を使用して、KubernetesのイングレスリソースのDNS管理を自動化します。
+このラボでは、ExternalDNSとAWS Route 53を使用して、KubernetesのIngressリソースのDNS管理を自動化します。
 
-まず、環境変数として提供されているIAMロールARNとHelmチャートバージョンを使用して、HelmでExternalDNSをインストールしましょう：
+まず、環境変数として提供されているIAM roleのARNとHelmチャートバージョンを使用して、HelmでExternalDNSをインストールしましょう：
 
 ```bash
 $ helm repo add external-dns https://kubernetes-sigs.github.io/external-dns/
@@ -33,20 +33,20 @@ NAME                                READY   STATUS    RESTARTS   AGE
 external-dns-5bdb4478b-fl48s        1/1     Running   0          2m
 ```
 
-次に、DNS設定を追加して以前のイングレスリソースを更新しましょう：
+次に、DNS設定を追加して以前のIngressリソースを更新しましょう：
 
 ::yaml{file="manifests/modules/exposing/ingress/external-dns/ingress.yaml" paths="metadata.annotations,spec.rules.0.host"}
 
-1. `external-dns.alpha.kubernetes.io/hostname`アノテーションは、ExternalDNSにイングレス用に作成および管理するDNS名を指定し、アプリのホスト名とロードバランサーのマッピングを自動化します。
-2. `spec.rules.host`は、イングレスが待ち受けるドメイン名を定義し、ExternalDNSはこれを使って関連するロードバランサーの一致するDNSレコードを作成します。
+1. `external-dns.alpha.kubernetes.io/hostname`アノテーションは、ExternalDNSにIngress用に作成および管理するDNS名を指定し、アプリのホスト名とロードバランサーのマッピングを自動化します。
+2. `spec.rules.host`は、Ingressが待ち受けるドメイン名を定義し、ExternalDNSはこれを使って関連するロードバランサーの一致するDNSレコードを作成します。
 
 この設定を適用しましょう：
 
 ```bash
-$ kubectl apply -k ~/environment/eks-workshop/modules/exposing/ingress/external-dns
+$ kubectl kustomize ~/environment/eks-workshop/modules/exposing/ingress/external-dns | envsubst | kubectl apply -f -
 ```
 
-ホスト名を使用して作成されたイングレスオブジェクトを確認しましょう：
+ホスト名を使用して作成されたIngressオブジェクトを確認しましょう：
 
 ```bash wait=120
 $ kubectl get ingress ui   -n ui
@@ -89,3 +89,4 @@ Set-Cookie: SESSIONID=c3f13e02-4ff3-40ba-866e-c777f7450997
 
 {"status":"UP"}
 ```
+

website/i18n/ja/docusaurus-plugin-content-docs/current/fundamentals/exposing/ingress/multiple-ingress.md

@@ -1,7 +1,7 @@
 ---
 title: "複数のIngressパターン"
 sidebar_position: 30
-tmdTranslationSourceHash: 2e75c3dcc5a0600975e14bd41effa2a4
+tmdTranslationSourceHash: d8bc8cb629e5535cec646d8b0d73ad9e
 ---
 
 同じEKSクラスター内で複数のIngressオブジェクトを活用することは一般的です。例えば、複数の異なるワークロードを公開するためなどです。デフォルトでは、各IngressはそれぞれALBの作成につながりますが、IngressGroup機能を活用することで複数のIngressリソースをグループ化できます。コントローラーはIngressGroup内のすべてのIngressのルールを自動的に統合し、1つのALBでそれらをサポートします。さらに、Ingressで定義されたほとんどのアノテーションは、そのIngressによって定義されたパスにのみ適用されます。
@@ -25,7 +25,7 @@ tmdTranslationSourceHash: 2e75c3dcc5a0600975e14bd41effa2a4
 これらのマニフェストをクラスターに適用します：
 
 ```bash wait=60
-$ kubectl apply -k ~/environment/eks-workshop/modules/exposing/ingress/multiple-ingress
+$ kubectl kustomize ~/environment/eks-workshop/modules/exposing/ingress/multiple-ingress | envsubst | kubectl apply -f -
 ```
 
 これで、`-multi`で終わる2つの追加のIngressオブジェクトがクラスターに作成されます：
@@ -54,7 +54,7 @@ $ aws elbv2 describe-rules --listener-arn $LISTENER_ARN
 - それ以外はuiサービスのターゲットグループに送信されます
 - デフォルトのバックアップとして、漏れたリクエストのために404があります
 
-AWS consoleで新しいALB設定も確認できます：
+AWSコンソールで新しいALB設定も確認できます：
 
 <ConsoleButton url="https://console.aws.amazon.com/ec2/home#LoadBalancers:tag:ingress.k8s.aws/stack=retail-app-group;sort=loadBalancerName" service="ec2" label="EC2コンソールを開く"/>
 

website/i18n/ja/docusaurus-plugin-content-docs/current/fundamentals/exposing/loadbalancer/adding-lb.md

@@ -1,21 +1,22 @@
 ---
 title: "ロードバランサーの作成"
 sidebar_position: 20
-tmdTranslationSourceHash: 10d2bea65be51068244e993bee3c0d60
+tmdTranslationSourceHash: e841c90e78e7e9a022ea9cda90de035c
 ---
 
 以下の設定でロードバランサーをプロビジョニングする追加のServiceを作成しましょう：
 
-::yaml{file="manifests/modules/exposing/load-balancer/nlb/nlb.yaml" paths="spec.type,spec.ports,spec.selector"}
+::yaml{file="manifests/modules/exposing/load-balancer/nlb/nlb.yaml" paths="metadata.annotations,spec.type,spec.ports,spec.selector"}
 
-1. この`Service`はネットワークロードバランサーを作成します
-2. NLBはポート80でリッスンし、`ui` Podsのポート8080に接続を転送します
-3. ここでは、ポッド上のラベルを使用して、このサービスのターゲットに追加するポッドを指定します
+1. AnnotationsはAWS Load Balancer Controllerがインターネット向けNLBをプロビジョニングするように設定します。`load-balancer-source-ranges`アノテーションはインバウンドトラフィックを特定のCIDR範囲に制限します
+2. この`Service`はネットワークロードバランサーを作成します
+3. NLBはポート80でリッスンし、`ui` Podsのポート8080に接続を転送します
+4. ここでは、ポッド上のラベルを使用して、このサービスのターゲットに追加するポッドを指定します
 
 この設定を適用します：
 
 ```bash timeout=180 hook=add-lb hookTimeout=430
-$ kubectl apply -k ~/environment/eks-workshop/modules/exposing/load-balancer/nlb
+$ kubectl kustomize ~/environment/eks-workshop/modules/exposing/load-balancer/nlb | envsubst | kubectl apply -f -
 ```
 
 `ui`アプリケーションのService リソースを再度確認してみましょう：

website/i18n/ja/docusaurus-plugin-content-docs/current/networking/eks-hybrid-nodes/routing-traffic.md

@@ -3,7 +3,7 @@ title: "ハイブリッドノードへのトラフィックのルーティング
 sidebar_position: 10
 sidebar_custom_props: { "module": false }
 weight: 25 # used by test framework
-tmdTranslationSourceHash: 6788556a7a4a9439c02c3c9fc4d89018
+tmdTranslationSourceHash: f15efea2d89072d3a7d2cabdd1b301dc
 ---
 
 これで、ハイブリッドノードインスタンスがクラスターに接続されたので、
@@ -20,7 +20,7 @@ tmdTranslationSourceHash: 6788556a7a4a9439c02c3c9fc4d89018
 ワークロードをデプロイしましょう：
 
 ```bash
-$ kubectl apply -k ~/environment/eks-workshop/modules/networking/eks-hybrid-nodes/kustomize
+$ kubectl kustomize ~/environment/eks-workshop/modules/networking/eks-hybrid-nodes/kustomize | envsubst | kubectl apply -f -
 namespace/nginx-remote created
 service/nginx created
 deployment.apps/nginx created
@@ -49,7 +49,7 @@ $ aws elbv2 describe-load-balancers --query 'LoadBalancers[?contains(LoadBalance
 
 :::
 
-ALBがアクティブになったら、IngressのAssociatedの`Address`を確認してALBのURLを取得できます：
+ALBがアクティブになったら、Ingressに関連付けられた`Address`を確認してALBのURLを取得できます：
 
 ```bash
 $ export ADDRESS=$(kubectl get ingress -n nginx-remote nginx -o jsonpath="{.status.loadBalancer.ingress[*].hostname}{'\n'}") && echo $ADDRESS
@@ -83,3 +83,4 @@ EKSハイブリッドノードでさらに多くのユースケースを探索
 ```bash timeout=300 wait=30
 $ kubectl delete -k ~/environment/eks-workshop/modules/networking/eks-hybrid-nodes/kustomize --ignore-not-found=true
 ```
+

website/i18n/ja/docusaurus-plugin-content-docs/current/networking/vpc-lattice/configuring-routes.md

@@ -1,15 +1,15 @@
 ---
 title: "ルートの設定"
 sidebar_position: 30
-tmdTranslationSourceHash: 2a099daa7d22fd6797d5afed142a0f8d
+tmdTranslationSourceHash: 607942b50a09a9268c77b8b43a71019f
 ---
 
 このセクションでは、ブルー/グリーンデプロイメントやカナリアスタイルのデプロイメントのための重み付けルーティングを使用した、高度なトラフィック管理にAmazon VPC Latticeを使用する方法を示します。
 
 配送オプションに「Lattice」というプレフィックスを追加した`checkout`マイクロサービスの修正版をデプロイしましょう。Kustomizeを使用して、この新しいバージョンを新しい名前空間（`checkoutv2`）にデプロイします。
 
 ```bash
-$ kubectl apply -k ~/environment/eks-workshop/modules/networking/vpc-lattice/abtesting/
+$ kubectl kustomize ~/environment/eks-workshop/modules/networking/vpc-lattice/abtesting/ | envsubst | kubectl apply -f -
 $ kubectl rollout status deployment/checkout -n checkoutv2
 ```