diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/automation/controlplanes/kro/provision-resources.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/automation/controlplanes/kro/provision-resources.md index 8013ef0297..14c59df438 100644 --- a/website/i18n/ja/docusaurus-plugin-content-docs/current/automation/controlplanes/kro/provision-resources.md +++ b/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テンプレートを確認しましょう：
RGDマニフェストの全容を表示 @@ -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 ``` diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/automation/gitops/argocd/access_argocd.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/automation/gitops/argocd/access_argocd.md index 0a9af7a182..d22e6faf73 100644 --- a/website/i18n/ja/docusaurus-plugin-content-docs/current/automation/gitops/argocd/access_argocd.md +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/automation/gitops/argocd/access_argocd.md @@ -2,16 +2,18 @@ title: "Argo CDのインストール" sidebar_position: 10 weight: 10 -tmdTranslationSourceHash: d56c4f4c50af1ff2a7b63644e2d44aeb +tmdTranslationSourceHash: f21fde74f48eca3eff8ecc25c4231f6e --- まずはクラスターにArgo CDをインストールしましょう： ```bash $ helm repo add argo-cd https://argoproj.github.io/argo-helm +$ ESCAPED_CIDRS="${INBOUND_CIDRS//,/\\,}" $ 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=$ESCAPED_CIDRS" \ --wait NAME: argocd LAST DEPLOYED: [...] diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/automation/gitops/argocd/gitea.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/automation/gitops/argocd/gitea.md index e751537842..3e5e9001c4 100644 --- a/website/i18n/ja/docusaurus-plugin-content-docs/current/automation/gitops/argocd/gitea.md +++ b/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: 9a72a1093c545cbb52c730a79ad8fee9 --- GitHub や GitLab の代わりに、迅速で簡単な代替手段として [Gitea](https://gitea.com) を使用します。Gitea は軽量な自己ホスト型 Git サービスで、ユーザーフレンドリーなウェブインターフェースを提供し、独自の Git リポジトリを迅速にセットアップおよび管理することができます。これは、Argo CD で探索する GitOps ワークフローに不可欠な Kubernetes マニフェストの保存とバージョン管理のための信頼できるソースとして機能します。 @@ -9,10 +9,13 @@ GitHub や GitLab の代わりに、迅速で簡単な代替手段として [Git Helm を使用して Gitea を EKS クラスターにインストールしましょう： ```bash +$ ESCAPED_CIDRS="${INBOUND_CIDRS//,/\\,}" $ 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=$ESCAPED_CIDRS" \ + --set "service.ssh.annotations.service\\.beta\\.kubernetes\\.io/load-balancer-source-ranges=$ESCAPED_CIDRS" \ --set "gitea.admin.password=${GITEA_PASSWORD}" \ --wait ``` diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/automation/gitops/flux/gitea.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/automation/gitops/flux/gitea.md index 1f3350a7da..5404f74324 100644 --- a/website/i18n/ja/docusaurus-plugin-content-docs/current/automation/gitops/flux/gitea.md +++ b/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: 523a68005935e08654a02d63632128f0 --- GitHubやGitLabの代わりとして、迅速かつ簡単な方法として[Gitea](https://gitea.com)を使用します。Giteaは軽量な自己ホスト型Gitサービスで、ユーザーフレンドリーなウェブインターフェースを提供し、独自のGitリポジトリを迅速に設定および管理することができます。これは、Fluxで探索するGitOpsワークフローに不可欠なKubernetesマニフェストを保存およびバージョン管理するための信頼できるソースとして機能します。 @@ -9,10 +9,13 @@ GitHubやGitLabの代わりとして、迅速かつ簡単な方法として[Gite Helmを使用してEKSクラスターにGiteaをインストールしましょう： ```bash +$ ESCAPED_CIDRS="${INBOUND_CIDRS//,/\\,}" $ 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=$ESCAPED_CIDRS" \ + --set "service.ssh.annotations.service\\.beta\\.kubernetes\\.io/load-balancer-source-ranges=$ESCAPED_CIDRS" \ --set "gitea.admin.password=${GITEA_PASSWORD}" \ --wait ``` @@ -54,3 +57,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' ``` + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/automation/platform-engineering-on-eks/index.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/automation/platform-engineering-on-eks/index.md new file mode 100644 index 0000000000..9984c40918 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/automation/platform-engineering-on-eks/index.md @@ -0,0 +1,13 @@ +--- +title: "Platform Engineering on EKS" +sidebar_custom_props: { "explore": "https://catalog.workshops.aws/platform-engineering-on-eks/en-US" } +sidebar_position: 90 +tmdTranslationSourceHash: 'f7246371bf12c113a910ff6e18dc0b28' +--- + +開発チームは、一貫性のないツールや複雑なプロビジョニングプロセスに悩まされることがよくあります。Cloud Native Computing Foundation (CNCF) では、プラットフォームを「プラットフォームのユーザーのニーズに応じて定義され、提示される統合された機能の集合体」と定義しています。つまり、アプリケーションが必要とするサービスやツールを統合し、Web ポータル、テンプレート、API を通じてシンプルな体験を提供する統一レイヤーです。 + +Platform Engineering on EKS は、開発者のセルフサービスを中核とした内部開発者プラットフォーム (IDP) の構築方法を示すハンズオンワークショップです。Backstage を使用した統合開発者ポータルのセットアップ、ACK と KRO を使用した AWS リソースの標準化された infrastructure-as-code プロビジョニング、そして Amazon EKS 上での namespace-as-a-service ワークフロー、policy-as-code、GitOps の実用的なパターンを探求します。 + + + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/amazon-eks-pod-identity/index.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/amazon-eks-pod-identity/index.md new file mode 100644 index 0000000000..0fcc73f059 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/amazon-eks-pod-identity/index.md @@ -0,0 +1,19 @@ +--- +title: "ワークロードからAWS APIへの安全なアクセス" +sidebar_position: 50 +description: "EKS Pod Identityを使用して、Amazon Elastic Kubernetes Serviceで実行されているアプリケーションのAWS認証情報を管理します。" +tmdTranslationSourceHash: '77eb8e7949428f93ddc8daaf7676b48e' +--- + +:::tip 事前にセットアップされている内容 +Amazon EKS Auto Modeクラスターには以下が含まれています： + +- cartsサービス用のAmazon DynamoDBテーブル +- cartsワークロードがDynamoDBにアクセスするために設定されたIAMロール + +::: + +Pod内のコンテナで実行されるアプリケーションは、サポートされているAWS SDKまたはAWS CLIを使用して、AWS Identity and Access Management（IAM）権限を使ってAWSサービスにAPIリクエストを行うことができます。例えば、アプリケーションはS3バケットにファイルをアップロードしたり、DynamoDBテーブルにクエリを実行したりする必要がある場合があります。そのためには、AWS APIリクエストにAWS認証情報で署名する必要があります。[EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html)は、Amazon EC2インスタンスプロファイルがインスタンスに認証情報を提供するのと同様に、アプリケーションの認証情報を管理する機能を提供します。AWS認証情報を作成してコンテナに配布したり、Amazon EC2インスタンスのロールを使用する代わりに、IAMロールをKubernetes Service Accountに関連付けて、Podがそれを使用するように設定できます。サポートされているSDKバージョンの正確なリストについては、EKSドキュメントを[こちら](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-minimum-sdk.html)で確認してください。 + +このモジュールでは、サンプルアプリケーションのコンポーネントの1つを再設定してAWS APIを活用し、適切な権限を提供します。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/amazon-eks-pod-identity/introduction.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/amazon-eks-pod-identity/introduction.md new file mode 100644 index 0000000000..ac21c000ac --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/amazon-eks-pod-identity/introduction.md @@ -0,0 +1,27 @@ +--- +title: "はじめに" +sidebar_position: 31 +tmdTranslationSourceHash: '30a2bf69cd7c96a2fc73a4005d5069f1' +--- + +アーキテクチャの `carts` コンポーネントは、ストレージバックエンドとして Amazon DynamoDB を使用しています。これは、Amazon EKS との非リレーショナルデータベース統合でよく見られるユースケースです。現在、carts API は、EKS クラスタ内のコンテナとして実行されている [Amazon DynamoDB の軽量版](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DynamoDBLocal.html) と共にデプロイされています。 + +次のコマンドを実行すると、これを確認できます： + +```bash wait=30 +$ kubectl -n carts get pod +NAME READY STATUS RESTARTS AGE +carts-5d7fc9d8f-xm4hs 1/1 Running 0 14m +carts-dynamodb-698674dcc6-hw2bg 1/1 Running 0 14m +``` + +上記の出力では、Pod `carts-dynamodb-698674dcc6-hw2bg` が軽量版 DynamoDB サービスです。環境変数を確認することで、`carts` アプリケーションがこれを使用していることを検証できます： + +```bash timeout=180 +$ kubectl wait --for=condition=Ready pods -l app.kubernetes.io/component=service -n carts --timeout=120s +$ kubectl -n carts exec deployment/carts -- env | grep RETAIL_CART_PERSISTENCE_DYNAMODB_ENDPOINT +RETAIL_CART_PERSISTENCE_DYNAMODB_ENDPOINT=http://carts-dynamodb:8000 +``` + +このアプローチはテストには便利ですが、フルマネージドの Amazon DynamoDB サービスが提供するスケールと信頼性を最大限に活用するために、アプリケーションを移行したいと考えています。次のセクションでは、Amazon DynamoDB を使用するようにアプリケーションを再構成し、EKS Pod Identity を実装して AWS サービスへの安全なアクセスを提供します。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/amazon-eks-pod-identity/understanding.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/amazon-eks-pod-identity/understanding.md new file mode 100644 index 0000000000..46c08749d7 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/amazon-eks-pod-identity/understanding.md @@ -0,0 +1,20 @@ +--- +title: "Pod IAMの理解" +sidebar_position: 33 +tmdTranslationSourceHash: '34ff18988cc9f932ada0b0e51dc7e163' +--- + +問題の最初の確認場所は、`carts`サービスのログです： + +```bash hook=pod-logs timeout=480 +$ LATEST_POD=$(kubectl get pods -n carts -l app.kubernetes.io/component=service --sort-by=.metadata.creationTimestamp -o jsonpath='{.items[-1:].metadata.name}') +sleep 60 +kubectl logs -n carts -p $LATEST_POD +[...] +software.amazon.awssdk.core.exception.SdkClientException: Unable to load credentials from any of the providers in the chain AwsCredentialsProviderChain(credentialsProviders=[SystemPropertyCredentialsProvider(), EnvironmentVariableCredentialsProvider(), WebIdentityTokenCredentialsProvider(), ProfileCredentialsProvider(profileName=default, profileFile=ProfileFile(sections=[])), ContainerCredentialsProvider(), InstanceProfileCredentialsProvider()]) : [SystemPropertyCredentialsProvider(): Unable to load credentials from system settings. Access key must be specified either via environment variable (AWS_ACCESS_KEY_ID) or system property (aws.accessKeyId)., EnvironmentVariableCredentialsProvider(): Unable to load credentials from system settings. Access key must be specified either via environment variable (AWS_ACCESS_KEY_ID) or system property (aws.accessKeyId)., WebIdentityTokenCredentialsProvider(): Either the environment variable AWS_WEB_IDENTITY_TOKEN_FILE or the javaproperty aws.webIdentityTokenFile must be set., ProfileCredentialsProvider(profileName=default, profileFile=ProfileFile(sections=[])): Profile file contained no credentials for profile 'default': ProfileFile(sections=[]), ContainerCredentialsProvider(): Cannot fetch credentials from container - neither AWS_CONTAINER_CREDENTIALS_FULL_URI or AWS_CONTAINER_CREDENTIALS_RELATIVE_URI environment variables are set., InstanceProfileCredentialsProvider(): Failed to load credentials from IMDS.] +``` + +アプリケーションはエラーを生成しており、PodがDynamoDBにアクセスするためのAWS認証情報を読み込めないことを示しています。これは、EKS Pod IdentityによってIAM roleやpolicyがPodにリンクされていない場合、アプリケーションがAWS API呼び出しを行うための認証情報を取得できないためです。 + +一つのアプローチとして、ノードのIAM roleの権限を拡張することが考えられますが、これではそれらのインスタンス上で実行されているすべてのPodがDynamoDBテーブルにアクセスできるようになってしまいます。これは最小権限の原則に違反し、セキュリティのベストプラクティスではありません。代わりに、EKS Pod Identityを使用して、`carts`アプリケーションが必要とする特定の権限をPodレベルで提供し、きめ細かいアクセス制御を確保します。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/amazon-eks-pod-identity/use-pod-identity.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/amazon-eks-pod-identity/use-pod-identity.md new file mode 100644 index 0000000000..ad05ef9244 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/amazon-eks-pod-identity/use-pod-identity.md @@ -0,0 +1,108 @@ +--- +title: "EKS Pod Identityの使用" +sidebar_position: 34 +hide_table_of_contents: true +tmdTranslationSourceHash: 'c2ccba1ccd0c6f8192e1325cbaff51bc' +--- + +Amazon EKS Auto Modeでは、EKS Pod Identity Agentがすでに含まれており、AWSによってコントロールプレーンで管理されています。既存のPod Identityアソシエーションを確認することで、Pod Identityが利用可能であることを確認できます： + +```bash +$ aws eks list-pod-identity-associations --cluster-name $EKS_CLUSTER_AUTO_NAME --namespace carts +{ + "associations": [] +} +``` + +`carts`サービスがDynamoDBテーブルへの読み書きに必要な権限を提供するIAM roleは、Auto Modeクラスターのセットアップ時に作成されました。以下のようにポリシーを表示できます： + +```bash +$ aws iam get-policy-version \ + --version-id v1 --policy-arn \ + --query 'PolicyVersion.Document' \ + arn:aws:iam::${AWS_ACCOUNT_ID}:policy/${EKS_CLUSTER_AUTO_NAME}-carts-dynamo | jq . +{ + "Statement": [ + { + "Action": "dynamodb:*", + "Effect": "Allow", + "Resource": [ + "arn:aws:dynamodb:us-west-2:267912352941:table/eks-workshop-auto-carts", + "arn:aws:dynamodb:us-west-2:267912352941:table/eks-workshop-auto-carts/index/*" + ], + "Sid": "AllAPIActionsOnCart" + } + ], + "Version": "2012-10-17" +} +``` + +また、このroleには適切な信頼関係が設定されており、EKS Service PrincipalがPod Identityのためにこのroleをassumeできるようになっています。以下のコマンドで確認できます： + +```bash +$ aws iam get-role \ + --query 'Role.AssumeRolePolicyDocument' \ + --role-name ${EKS_CLUSTER_AUTO_NAME}-carts-dynamo | jq . +{ + "Version": "2012-10-17", + "Statement": [ + { + "Effect": "Allow", + "Principal": { + "Service": "pods.eks.amazonaws.com" + }, + "Action": [ + "sts:AssumeRole", + "sts:TagSession" + ] + } + ] +} +``` + +次に、Amazon EKS Pod Identity機能を使用して、Deploymentによって使用されるKubernetes Service AccountとAWS IAM roleを関連付けます。アソシエーションを作成するには、以下のコマンドを実行します： + +```bash wait=30 +$ aws eks create-pod-identity-association --cluster-name ${EKS_CLUSTER_AUTO_NAME} \ + --role-arn arn:aws:iam::${AWS_ACCOUNT_ID}:role/${EKS_CLUSTER_AUTO_NAME}-carts-dynamo \ + --namespace carts --service-account carts | jq . +{ + "association": { + "clusterName": "eks-workshop-auto", + "namespace": "carts", + "serviceAccount": "carts", + "roleArn": "arn:aws:iam::267912352941:role/eks-workshop-auto-carts-dynamo", + "associationArn": "arn:aws:eks:us-west-2:267912352941:podidentityassociation/eks-workshop-auto/a-yg5uoymvtfgdg5tcj", + "associationId": "a-yg5uoymvtfgdg5tcj", + "tags": {}, + "createdAt": "2025-10-11T01:13:27.763000+00:00", + "modifiedAt": "2025-10-11T01:13:27.763000+00:00", + "disableSessionTags": false + } +} +``` + +残りは、`carts` Deploymentが`carts` Service Accountを使用していることを確認することです： + +```bash +$ kubectl -n carts describe deployment carts | grep 'Service Account' + Service Account: carts +``` + +Service Accountが確認できたので、`carts` Podをリサイクルしましょう： + +```bash hook=enable-pod-identity hookTimeout=430 +$ kubectl -n carts rollout restart deployment/carts +deployment.apps/carts restarted +``` + +Podのステータスを確認して、正常にロールアウトされたかを確認しましょう： + +```bash timeout=360 +$ kubectl -n carts rollout status deployment/carts --timeout=300s +Waiting for deployment "carts" rollout to finish: 1 old replicas are pending termination... +deployment "carts" successfully rolled out +``` + +それでは、次のセクションで、cartsアプリケーションで発生していたDynamoDB権限の問題が解決されたかどうかを確認しましょう。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/amazon-eks-pod-identity/using-dynamo.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/amazon-eks-pod-identity/using-dynamo.md new file mode 100644 index 0000000000..d6d7e46323 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/amazon-eks-pod-identity/using-dynamo.md @@ -0,0 +1,79 @@ +--- +title: "Amazon DynamoDB の使用" +sidebar_position: 32 +tmdTranslationSourceHash: '8a2dad5af76103e706512f44167f1dda' +--- + +このプロセスの最初のステップは、既に作成されている DynamoDB テーブルを使用するように carts サービスを再設定することです。アプリケーションは ConfigMap からほとんどの設定を読み込みます。それを見てみましょう: + +```bash +$ kubectl -n carts get -o yaml cm carts | yq +apiVersion: v1 +data: + AWS_ACCESS_KEY_ID: key + AWS_SECRET_ACCESS_KEY: secret + RETAIL_CART_PERSISTENCE_DYNAMODB_CREATE_TABLE: "true" + RETAIL_CART_PERSISTENCE_DYNAMODB_ENDPOINT: http://carts-dynamodb:8000 + RETAIL_CART_PERSISTENCE_DYNAMODB_TABLE_NAME: Items + RETAIL_CART_PERSISTENCE_PROVIDER: dynamodb +kind: ConfigMap +metadata: + name: carts + namespace: carts +``` + +以下の kustomization は、DynamoDB エンドポイント設定を削除して ConfigMap を上書きします。これにより、SDK はテスト用 Pod の代わりに実際の DynamoDB サービスを使用するようになります。また、既に作成されている DynamoDB テーブル名も設定しました。テーブル名は環境変数 `RETAIL_CART_PERSISTENCE_DYNAMODB_TABLE_NAME` から取得されます。 + +```kustomization +modules/security/eks-pod-identity/dynamo/kustomization.yaml +ConfigMap/carts +``` + +DynamoDB テーブル名を設定して、Kustomize を実行し、実際の DynamoDB サービスを使用するようにしましょう: + +```bash +$ export CARTS_DYNAMODB_TABLENAME=${EKS_CLUSTER_AUTO_NAME}-carts && echo $CARTS_DYNAMODB_TABLENAME +eks-workshop-auto-carts +$ kubectl kustomize ~/environment/eks-workshop/modules/security/eks-pod-identity/dynamo \ + | envsubst | kubectl apply -f- +``` + +これにより、ConfigMap が新しい値で上書きされます: + +```bash +$ kubectl -n carts get cm carts -o yaml | yq +apiVersion: v1 +data: + AWS_REGION: us-west-2 + RETAIL_CART_PERSISTENCE_DYNAMODB_TABLE_NAME: eks-workshop-auto-carts + RETAIL_CART_PERSISTENCE_PROVIDER: dynamodb +kind: ConfigMap +metadata: + labels: + app: carts + name: carts + namespace: carts +``` + +次に、新しい ConfigMap の内容を反映させるために、すべての carts Pod を再起動する必要があります: + +```bash expectError=true hook=enable-dynamo +$ kubectl rollout restart -n carts deployment/carts +deployment.apps/carts restarted +$ kubectl rollout status -n carts deployment/carts --timeout=20s +Waiting for deployment "carts" rollout to finish: 1 old replicas are pending termination... +error: timed out waiting for the condition +``` + +変更が正常にデプロイされなかったようです。Pod を確認することでこれを確認できます: + +```bash +$ kubectl -n carts get pod +NAME READY STATUS RESTARTS AGE +carts-5d486d7cf7-8qxf9 1/1 Running 0 5m49s +carts-df76875ff-7jkhr 0/1 CrashLoopBackOff 3 (36s ago) 2m2s +carts-dynamodb-698674dcc6-hw2bg 1/1 Running 0 20m +``` + +何が問題なのでしょうか？ + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/amazon-eks-pod-identity/verifying-dynamo.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/amazon-eks-pod-identity/verifying-dynamo.md new file mode 100644 index 0000000000..855750c759 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/amazon-eks-pod-identity/verifying-dynamo.md @@ -0,0 +1,41 @@ +--- +title: "DynamoDB アクセスの検証" +sidebar_position: 35 +tmdTranslationSourceHash: 8c2ac2956c8fb49e1b1d9d6e9b884b1b +--- + +これで、`carts` Service Account が認可された IAM ロールに関連付けられたため、`carts` Pod は DynamoDB テーブルにアクセスする権限を持つようになりました。ウェブストアに再度アクセスし、ショッピングカートに移動してください。 + +```bash +$ ALB_HOSTNAME=$(kubectl get ingress ui-auto -n ui -o yaml | yq .status.loadBalancer.ingress[0].hostname) +$ echo "http://$ALB_HOSTNAME" +http://k8s-ui-ui-a9797f0f61.elb.us-west-2.amazonaws.com +``` + +`carts` Pod は DynamoDB サービスに到達でき、ショッピングカートにアクセスできるようになりました！ + +![Cart](/img/sample-app-screens/shopping-cart.webp) + +:::caution +アプリケーションの読み込み時にエラーが表示される場合は、[前のセクション](./use-pod-identity.md)の最後で `carts` Pod を再起動したことを確認してください。 +::: + +AWS IAM ロールが Service Account に関連付けられた後、その Service Account を使用して新しく作成された Pod は、[EKS Pod Identity webhook](https://github.com/aws/amazon-eks-pod-identity-webhook) によってインターセプトされます。この webhook は Amazon EKS クラスターの control plane で実行され、AWS によって完全に管理されています。新しい `carts` Pod を詳しく見て、新しい環境変数を確認しましょう: + +```bash +$ kubectl -n carts exec deployment/carts -- env | grep AWS +AWS_STS_REGIONAL_ENDPOINTS=regional +AWS_DEFAULT_REGION=us-west-2 +AWS_REGION=us-west-2 +AWS_CONTAINER_CREDENTIALS_FULL_URI=http://169.254.170.23/v1/credentials +AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE=/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token +``` + +これらの環境変数について注目すべき点: + +- `AWS_DEFAULT_REGION` - リージョンは EKS クラスターと同じものに自動的に設定されます +- `AWS_STS_REGIONAL_ENDPOINTS` - `us-east-1` のグローバルエンドポイントに過度の負荷をかけないように、リージョナル STS エンドポイントが設定されます +- `AWS_CONTAINER_CREDENTIALS_FULL_URI` - この変数は、[HTTP credential provider](https://docs.aws.amazon.com/sdkref/latest/guide/feature-container-credentials.html) を使用して認証情報を取得する方法を AWS SDK に伝えます。つまり、EKS Pod Identity は `AWS_ACCESS_KEY_ID`/`AWS_SECRET_ACCESS_KEY` ペアのような認証情報を注入する必要がなく、代わりに SDK は EKS Pod Identity メカニズムを介して一時的な認証情報を取得できます。この機能の詳細については、[AWS ドキュメント](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html)をご覧ください。 + +アプリケーションで Pod Identity の設定が正常に完了しました。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/ebs/deployment-with-ebs.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/ebs/deployment-with-ebs.md new file mode 100644 index 0000000000..5637ae65bd --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/ebs/deployment-with-ebs.md @@ -0,0 +1,196 @@ +--- +title: 永続的な EBS ボリュームの使用 +sidebar_position: 20 +tmdTranslationSourceHash: 9fe30f4fb4bd054c70c10fb30958babd +--- + +それでは、catalog MySQL データベースを更新して、永続的な EBS ストレージを使用するようにしましょう。EKS Auto Mode では、EBS CSI Driver がすでにインストールされ、AWS によって管理されています。 + +## StorageClass の作成 + +StorageClass は、EKS Auto Mode が EBS ボリュームをプロビジョニングする方法を定義します。EKS Auto Mode には EBS CSI Driver が含まれていますが、ストレージ機能を使用するには、`ebs.csi.eks.amazonaws.com` を参照する StorageClass を作成する必要があります。 + +::yaml{file="manifests/modules/fastpaths/developers/ebs/storageclass.yaml" paths="provisioner,parameters.type"} + +1. `provisioner: ebs.csi.eks.amazonaws.com` - EKS Auto Mode の組み込み EBS CSI Driver を使用します +2. `type: gp3` - EBS ボリュームタイプを指定します + +StorageClass を適用します: + +```bash +$ kubectl apply -f ~/environment/eks-workshop/modules/fastpaths/developers/ebs/storageclass.yaml +``` + +## catalog MySQL データベースの更新 + +`volumeClaimTemplates` を含む多くの StatefulSet フィールドは変更できないため、新しいストレージ構成で catalog サービスを削除して再作成する必要があります。 + +まず、現在の catalog MySQL StatefulSet を削除します: + +```bash wait=10 +$ kubectl delete -n catalog statefulset catalog-mysql +``` + +次に、永続的ストレージを有効にして再作成します。更新された StatefulSet には `volumeClaimTemplates` セクションが含まれています: + +::yaml{file="manifests/modules/fastpaths/developers/ebs/statefulset-mysql.yaml" paths="spec.volumeClaimTemplates.0.spec.storageClassName,spec.volumeClaimTemplates.0.spec.accessModes,spec.volumeClaimTemplates.0.spec.resources"} + +1. `accessModes` は ReadWriteOnce を指定し、ボリュームが単一のノードによってマウントされることを許可します +2. `storageClassName` は動的プロビジョニングのために ebs-sc StorageClass を指定します +3. 30GB の EBS ボリュームをリクエストしています + +構成を適用し、catalog Pod を再起動してデータベースの初期化を確実にします: + +```bash timeout=180 +$ kubectl apply -k ~/environment/eks-workshop/modules/fastpaths/developers/ebs +$ kubectl rollout restart deployment/catalog -n catalog # DB 構造をプッシュするために catalog を強制的に再起動 +``` + +## PersistentVolumeClaim の確認 + +再作成された catalog MySQL StatefulSet には、関連する PersistentVolumeClaim があります。 + +```bash +$ kubectl describe statefulset -n catalog catalog-mysql +Name: catalog-mysql +Namespace: catalog +... + Containers: + mysql: + Image: public.ecr.aws/docker/library/mysql:8.0 + Port: 3306/TCP + Mounts: + /var/lib/mysql from data (rw) +Volume Claims: + Name: data + StorageClass: + Labels: + Annotations: + Capacity: 30Gi + Access Modes: [ReadWriteOnce] +``` + +作成された Persistent Volume Claim (PVC) を確認します: + +```bash +$ kubectl get pvc -n catalog +NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE +data-catalog-mysql-0 Bound pvc-abc123... 30Gi RWO ebs-sc 2m +``` + +PVC の詳細を調査します: + +```bash +$ kubectl describe pvc -n catalog data-catalog-mysql-0 +Name: data-catalog-mysql-0 +Namespace: catalog +StorageClass: ebs-sc +Status: Bound +Volume: pvc-abc123... +Annotations: pv.kubernetes.io/bind-completed: yes + pv.kubernetes.io/bound-by-controller: yes + volume.beta.kubernetes.io/storage-provisioner: ebs.csi.aws.com +Capacity: 30Gi +Access Modes: RWO +VolumeMode: Filesystem +Used By: catalog-mysql-0 +``` + +PVC は Persistent Volume (PV) にバインドされ、**ebs.csi.aws.com** を使用して 30Gi の容量でプロビジョニングされています。 + +## PersistentVolume (PV) の調査 + +```bash +$ kubectl describe pv $(kubectl get pvc -n catalog data-catalog-mysql-0 -o jsonpath="{.spec.volumeName}") +Name: pvc-abc123... +Annotations: pv.kubernetes.io/provisioned-by: ebs.csi.aws.com +StorageClass: ebs-sc +Status: Bound +Claim: catalog/data-catalog-mysql-0 +Reclaim Policy: Delete +Access Modes: RWO +VolumeMode: Filesystem +Capacity: 30Gi +Node Affinity: + Required Terms: + Term 0: topology.kubernetes.io/zone in [us-west-2a] +Source: + Type: CSI (a Container Storage Interface (CSI) volume source) + Driver: ebs.csi.aws.com + FSType: ext4 + VolumeHandle: vol-0abc123... + ReadOnly: false +``` + +**VolumeHandle** は Amazon EBS Volume ID を参照します。**Node Affinity** は、Pod が EBS ボリュームと同じ Availability Zone にスケジュールされることを保証します。 + +## EBS ボリュームの確認 + +EBS Volume ID を取得します: + +```bash +$ MYSQL_PV_NAME=$(kubectl get pvc -n catalog data-catalog-mysql-0 -o jsonpath="{.spec.volumeName}") +$ MYSQL_EBS_VOL_ID=$(kubectl get pv $MYSQL_PV_NAME -o jsonpath="{.spec.csi.volumeHandle}") +$ echo "EBS Volume ID: $MYSQL_EBS_VOL_ID" +``` + +EBS ボリュームの詳細を表示します: + +```bash +$ aws ec2 describe-volumes --volume-ids $MYSQL_EBS_VOL_ID | jq . +``` + +このボリュームは暗号化が有効になっている gp3 ストレージを使用しています。 + +## データの永続性のテスト + +Pod の再起動後もデータが永続化されることを確認しましょう。まず、Pod の準備ができるまで待ちます: + +```bash timeout=420 +$ kubectl wait --for=condition=Ready -n catalog pod/catalog-mysql-0 --timeout=360s +``` + +MySQL データディレクトリにテストファイルを作成します: + +```bash +$ kubectl exec -n catalog catalog-mysql-0 -- bash -c "echo 123 > /var/lib/mysql/test.txt" +``` + +テストファイルが作成されたことを確認します: + +```bash +$ kubectl exec -n catalog catalog-mysql-0 -- ls -larth /var/lib/mysql/ | grep -i test +-rw-r--r--. 1 root root 4 Oct 11 00:39 test.txt +``` + +次に、障害をシミュレートするために Pod を削除します: + +```bash +$ kubectl delete pod -n catalog catalog-mysql-0 +``` + +StatefulSet コントローラーが自動的に Pod を再作成するのを待ちます: + +```bash +$ kubectl wait --for=condition=Ready -n catalog pod/catalog-mysql-0 --timeout=120s +``` + +Pod の再起動後もテストファイルが存在することを確認します: + +```bash +$ kubectl exec -n catalog catalog-mysql-0 -- cat /var/lib/mysql/test.txt +123 +``` + +成功です！テストファイルは Pod の再起動後も永続化されました。これは、データが Pod のエフェメラルストレージではなく、EBS ボリュームに保存されているためです。Amazon EBS がデータを保存し、AWS のアベイラビリティーゾーン内で安全かつ利用可能な状態を維持しています。 + +## まとめ + +このセクションでは、以下を実施しました: + +- catalog MySQL データベースを更新して、永続的な EBS ストレージを使用するようにしました +- EBS ボリュームが正しく作成されたことを確認しました +- Pod の再起動後もデータが永続化されることをテストしました + +EKS Auto Mode では、EBS CSI Driver が事前にインストールされ、管理されているため、ステートフルなワークロードの永続的なブロックストレージを簡単にプロビジョニングできます。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/ebs/existing-architecture.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/ebs/existing-architecture.md new file mode 100644 index 0000000000..fd501da1ea --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/ebs/existing-architecture.md @@ -0,0 +1,35 @@ +--- +title: 現在のストレージ構成 +sidebar_position: 10 +tmdTranslationSourceHash: 1150974f534eebd6354989f4c6fe4eac +--- + +catalog MySQL データベースが現在どのようにデータを保存しているかを確認しましょう。catalog サービスはバックエンドデータベースとして MySQL を使用しており、その現在のストレージ構成を確認します。 + +まず、catalog MySQL データベースの StatefulSet を見てみましょう: + +```bash +$ kubectl describe statefulset -n catalog catalog-mysql +Name: catalog-mysql +Namespace: catalog +[...] + Containers: + mysql: + Image: public.ecr.aws/docker/library/mysql:8.0 + Port: 3306/TCP + Mounts: + /var/lib/mysql from data (rw) + Volumes: + data: + Type: EmptyDir (a temporary directory that shares a pod's lifetime) +[...] +``` + +StatefulSet は現在、Pod のライフタイムの間だけ存在する [EmptyDir volume](https://kubernetes.io/docs/concepts/storage/volumes/#emptydir) を使用しています。これは次のことを意味します: + +- Pod が終了すると、すべてのデータベースデータが永久に失われます +- データベースは各 Pod の再起動時に新しい状態で開始されます +- Pod のライフサイクルイベント全体でデータの永続性がありません + +これは本番環境のデータベースには適していません。次のセクションでは、Amazon EBS を使用して永続ストレージを構成し、データベースデータが Pod の再起動や障害を乗り越えて存続するようにします。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/ebs/index.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/ebs/index.md new file mode 100644 index 0000000000..f77b672511 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/ebs/index.md @@ -0,0 +1,23 @@ +--- +title: EBSを使用したワークロードストレージの追加 +sidebar_position: 40 +description: "Amazon Elastic Block Storeを使用したAmazon Elastic Kubernetes Service上のワークロード向けの永続的なブロックストレージ。" +tmdTranslationSourceHash: 7320f317c9f0a3a5c148c680491d7102 +--- + +:::tip セットアップ済みの内容 +Amazon EKS Auto Modeクラスターには**Amazon EBS CSI Driver**が含まれており、永続的なブロックストレージボリュームの動的プロビジョニングが可能です。 +::: + +[Amazon Elastic Block Store](https://docs.aws.amazon.com/ebs/latest/userguide/what-is-ebs.html) (Amazon EBS) は、Amazon EC2およびAmazon EKSで使用するための永続的なブロックストレージボリュームを提供します。EBSボリュームは高可用性で信頼性の高いストレージであり、同じアベイラビリティーゾーン内で実行中のインスタンスにアタッチできます。 + +Amazon EKS Auto Modeでは、EBS CSI Driverが事前にインストールされ、AWSによって管理されているため、手動でのインストールや設定は不要です。 + +このラボでは、以下を実施します： + +- EBSによる永続的なブロックストレージについて学習する +- catalog MySQLデータベースを永続的なEBSボリュームを使用するように設定する +- Pod再起動後のデータ永続性を検証する + +この実践的な体験を通じて、永続的なストレージソリューションのためにEKS Auto ModeでAmazon EBSを効果的に使用する方法を学びます。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/index.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/index.md new file mode 100644 index 0000000000..54ad5d928a --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/index.md @@ -0,0 +1,33 @@ +--- +title: "開発者必須" +sidebar_position: 50 +sidebar_custom_props: { "module": true } +tmdTranslationSourceHash: "572b4034ea5aef74687a2baf8b252b67" +--- + +# 開発者必須 + +::required-time + +:::tip 始める前に +このファストパスは、専用の Amazon EKS Auto Mode クラスターを使用します。Amazon EKS Auto Mode は、クラスター自体を超えて Kubernetes クラスターの AWS 管理を拡張し、コンピューティングオートスケーリング、ネットワーキング、ロードバランシング、DNS、ブロックストレージなど、ワークロードのスムーズな運用を可能にするインフラストラクチャを管理します。 + +このラボ用の環境を準備します: + +```bash timeout=600 +$ prepare-environment fastpaths/developer +``` +::: + +EKS ワークショップ開発者必須へようこそ！これは、ワークロードをデプロイする際に最も一般的に必要とされる Amazon EKS の機能を学ぶために、開発者向けに最適化されたラボのコレクションです。 + +この学習パスでは、以下を学びます: + +- EKS でのコンテナ化されたアプリケーションのデプロイと管理 +- Amazon EBS を使用した永続ストレージの操作 +- ワークロードのオートスケーリングの実装 +- ロードバランサーと Ingress によるアプリケーションの公開 +- EKS Pod Identity を使用した DynamoDB などの AWS サービスの利用 + +それでは始めましょう！ + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/ingress/adding-ingress.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/ingress/adding-ingress.md new file mode 100644 index 0000000000..ce4f4e8eef --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/ingress/adding-ingress.md @@ -0,0 +1,153 @@ +--- +title: "Ingress の作成" +sidebar_position: 20 +tmdTranslationSourceHash: '7853bafb8c4cf75d9cae7be70165679f' +--- + +:::info AWS Load Balancer Controller +AWS Load Balancer Controller は Amazon EKS Auto Mode に含まれており、コントロールプレーンで実行されます。Ingress リソースを作成すると、自動的に AWS ロードバランサーがプロビジョニングされます。 +::: + +現在、クラスターには Ingress リソースが存在しません。これは次のコマンドで確認できます: + +```bash expectError=true +$ kubectl get ingress -n ui +No resources found in ui namespace. +``` + +まず、IngressClass と IngressClassParams を設定する必要があります: + +::yaml{file="manifests/modules/fastpaths/developers/ingress/adding-ingress/ingressclass.yaml" paths="0.spec.controller,0.spec.parameters,1.spec"} + +1. `controller` フィールドは、Auto Mode ALB 機能をターゲットにするために `eks.amazonaws.com/alb` に設定する必要があります +2. `parameters` セクションは、`apiGroup: eks.amazonaws.com` を持つ IngressClassParams リソースを参照します +3. IngressClassParams は、ロードバランサーのスキームやターゲットタイプなど、AWS 固有の設定を定義します + +この IngressClass を使用して、Ingress を設定します: + +::yaml{file="manifests/modules/fastpaths/developers/ingress/adding-ingress/ingress.yaml" paths="kind,spec.ingressClassName,spec.rules"} + +1. `Ingress` kind を使用します +2. `ingressClassName` は Auto Mode IngressClass を参照します +3. rules セクションは、パスが `/` で始まるすべての HTTP リクエストを、ポート 80 の `ui` という Kubernetes Service にルーティングします + +:::info +EKS Auto Mode では、アノテーションによる ALB 設定はサポートされていません。設定は IngressClassParams で行う必要があります。 +::: + +それでは、これらの設定を適用しましょう: + +```bash timeout=180 hook=add-ingress hookTimeout=660 +$ kubectl kustomize ~/environment/eks-workshop/modules/fastpaths/developers/ingress/adding-ingress | envsubst | kubectl apply -f - +``` + +作成された Ingress オブジェクトを確認しましょう: + +```bash +$ kubectl get ingress ui-auto -n ui +NAME CLASS HOSTS ADDRESS PORTS AGE +ui-auto eks-auto-alb * k8s-ui-uiauto-6cd0ef095e-78768930.us-west-2.elb.amazonaws.com 80 5s +``` + +ALB のプロビジョニングとターゲットの登録には数分かかるため、この Ingress 用にプロビジョニングされた ALB がどのように設定されているかを詳しく見てみましょう: + +```bash +$ aws elbv2 describe-load-balancers --query 'LoadBalancers[?contains(LoadBalancerName, `k8s-ui-uiauto`) == `true`]' +[ + { + "LoadBalancerArn": "arn:aws:elasticloadbalancing:us-west-2:1234567890:loadbalancer/app/k8s-ui-uiauto-cb8129ddff/f62a7bc03db28e7c", + "DNSName": "k8s-ui-ui-cb8129ddff-1888909706.us-west-2.elb.amazonaws.com", + "CanonicalHostedZoneId": "Z1H1FL5HABSF5", + "CreatedTime": "2022-09-30T03:40:00.950000+00:00", + "LoadBalancerName": "k8s-ui-ui-cb8129ddff", + "Scheme": "internet-facing", + "VpcId": "vpc-0851f873025a2ece5", + "State": { + "Code": "active" + }, + "Type": "application", + "AvailabilityZones": [ + { + "ZoneName": "us-west-2b", + "SubnetId": "subnet-00415f527bbbd999b", + "LoadBalancerAddresses": [] + }, + { + "ZoneName": "us-west-2a", + "SubnetId": "subnet-0264d4b9985bd8691", + "LoadBalancerAddresses": [] + }, + { + "ZoneName": "us-west-2c", + "SubnetId": "subnet-05cda6deed7f3da65", + "LoadBalancerAddresses": [] + } + ], + "SecurityGroups": [ + "sg-0f8e704ee37512eb2", + "sg-02af06ec605ef8777" + ], + "IpAddressType": "ipv4" + } +] +``` + +これから何がわかるでしょうか？ + +- ALB はパブリックインターネット経由でアクセス可能です +- VPC 内のパブリックサブネットを使用しています + +コントローラーによって作成されたターゲットグループ内のターゲットを確認します: + +```bash +$ ALB_ARN=$(aws elbv2 describe-load-balancers --query 'LoadBalancers[?contains(LoadBalancerName, `k8s-ui-uiauto`) == `true`].LoadBalancerArn' | jq -r '.[0]') +$ TARGET_GROUP_ARN=$(aws elbv2 describe-target-groups --load-balancer-arn $ALB_ARN | jq -r '.TargetGroups[0].TargetGroupArn') +$ aws elbv2 describe-target-health --target-group-arn $TARGET_GROUP_ARN +{ + "TargetHealthDescriptions": [ + { + "Target": { + "Id": "10.42.180.183", + "Port": 8080, + "AvailabilityZone": "us-west-2c" + }, + "HealthCheckPort": "8080", + "TargetHealth": { + "State": "healthy" + } + } + ] +} +``` + +Ingress オブジェクトで IP モードの使用を指定したため、ターゲットは `ui` Pod の IP アドレスとトラフィックを提供するポートを使用して登録されます。 + +このリンクをクリックして、コンソールで ALB とそのターゲットグループを確認することもできます: + + + +:::caution +このボタンを使用してコンソールを開く際に問題が発生した場合は、AWS コンソールのアクティブなセッションがない可能性があります。この問題を解決するには、ワークショップのホームページに移動し、左側のナビゲーションメニューの `AWS account access` セクションにある `Open AWS console` というリンクをクリックしてください。 +::: + +Ingress リソースから URL を取得します: + +```bash +$ ADDRESS=$(kubectl get ingress -n ui ui-auto -o jsonpath="{.status.loadBalancer.ingress[*].hostname}") +$ echo "http://${ADDRESS}" +http://k8s-ui-uiauto-cb8129ddff-1888909706.us-west-2.elb.amazonaws.com +``` + +ロードバランサーのプロビジョニングが完了するまで待つには、次のコマンドを実行します: + +```bash timeout=600 +$ 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-auto -o jsonpath="{.status.loadBalancer.ingress[*].hostname}") +``` + +そして、Web ブラウザでアクセスしてください。Web ストアの UI が表示され、ユーザーとしてサイト内を移動できるようになります。 + + + + + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/ingress/index.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/ingress/index.md new file mode 100644 index 0000000000..ef155278bf --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/ingress/index.md @@ -0,0 +1,18 @@ +--- +title: "Ingress でワークロードを公開する" +chapter: true +sidebar_position: 20 +description: "Amazon Elastic Kubernetes Service の Ingress API を使用して、HTTP および HTTPS ルートを外部に公開します。" +tmdTranslationSourceHash: "2a7c7a0a3e458f2a3b85abd264fa6c6a" +--- + +:::tip 事前にセットアップされているもの +Amazon EKS Auto Mode クラスターには、Kubernetes Ingress リソース用の AWS Elastic Load Balancer を管理する **AWS Load Balancer Controller** が含まれています。 +::: + +現在、ウェブストアアプリケーションは外部に公開されていないため、ユーザーがアクセスする方法がありません。ウェブストアワークロードには多くのマイクロサービスがありますが、エンドユーザーが利用できる必要があるのは `ui` アプリケーションのみです。これは、`ui` アプリケーションが内部の Kubernetes ネットワークを使用して、他のバックエンドサービスへのすべての通信を実行するためです。 + +Kubernetes Ingress は、クラスター内で実行されている Kubernetes サービスへの外部または内部の HTTP(S) アクセスを管理できる API リソースです。Amazon Elastic Load Balancing Application Load Balancer (ALB) は、リージョン内の複数のターゲット（Amazon EC2 インスタンスなど）にわたってアプリケーション層（レイヤー 7）で受信トラフィックを負荷分散する人気の AWS サービスです。ALB は、ホストまたはパスベースのルーティング、TLS（Transport Layer Security）終端、WebSockets、HTTP/2、AWS WAF（Web Application Firewall）統合、統合アクセスログ、ヘルスチェックなど、多くの機能をサポートしています。 + +このラボ演習では、Kubernetes Ingress モデルで ALB を使用して、サンプルアプリケーションを公開します。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/keda/configure-keda.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/keda/configure-keda.md new file mode 100644 index 0000000000..1c48246b57 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/keda/configure-keda.md @@ -0,0 +1,32 @@ +--- +title: "KEDAの設定" +sidebar_position: 10 +tmdTranslationSourceHash: 'c96cb78211f58bb444430338982960a3' +--- + +KEDAをインストールすると、いくつかのカスタムリソースが作成されます。これらのリソースの1つである`ScaledObject`を使用すると、外部イベントソースをDeploymentまたはStatefulSetにマッピングしてスケーリングすることができます。このラボでは、`ui` Deploymentをターゲットとし、CloudWatchの`RequestCountPerTarget`メトリクスに基づいてこのワークロードをスケーリングする`ScaledObject`を作成します。 + +::yaml{file="manifests/modules/autoscaling/workloads/keda/scaledobject/scaledobject.yaml" paths="spec.scaleTargetRef,spec.minReplicaCount,spec.maxReplicaCount,spec.triggers"} + +1. これはKEDAがスケーリングするリソースです。`name`はターゲットとするDeploymentの名前で、`ScaledObject`はDeploymentと同じNamespaceに存在する必要があります +2. KEDAがDeploymentをスケーリングする際の最小レプリカ数 +3. KEDAがDeploymentをスケーリングする際の最大レプリカ数 +4. `expression`は[CloudWatch Metrics Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-insights-querylanguage.html)構文を使用してターゲットメトリクスを選択します。`targetMetricValue`を超えると、KEDAはワークロードをスケールアウトして増加した負荷に対応します。この例では、`RequestCountPerTarget`が100を超えると、KEDAはDeploymentをスケーリングします。 + +AWS CloudWatch scalerの詳細については、[こちら](https://keda.sh/docs/scalers/aws-cloudwatch/)をご覧ください。 + +まず、ラボの前提条件の一部として作成されたApplication Load Balancer (ALB)とTarget Groupに関する情報を収集する必要があります。 + +```bash +$ export ALB_ARN=$(aws elbv2 describe-load-balancers --query 'LoadBalancers[?contains(LoadBalancerName, `k8s-ui-uiauto-`) == `true`]' | jq -r .[0].LoadBalancerArn) +$ export ALB_ID=$(aws elbv2 describe-load-balancers --query 'LoadBalancers[?contains(LoadBalancerName, `k8s-ui-uiauto-`) == `true`]' | jq -r .[0].LoadBalancerArn | awk -F "loadbalancer/" '{print $2}') +$ export TARGETGROUP_ID=$(aws elbv2 describe-target-groups --load-balancer-arn $ALB_ARN | jq -r '.TargetGroups[0].TargetGroupArn' | awk -F ":" '{print $6}') +``` + +これらの値を使用して、`ScaledObject`の設定を更新し、クラスターにリソースを作成できます。 + +```bash +$ kubectl kustomize ~/environment/eks-workshop/modules/autoscaling/workloads/keda/scaledobject \ + | envsubst | kubectl apply -f- +``` + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/keda/index.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/keda/index.md new file mode 100644 index 0000000000..c4d5adb157 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/keda/index.md @@ -0,0 +1,21 @@ +--- +title: "アプリケーションのオートスケーリング" +chapter: true +sidebar_position: 80 +description: "KEDAを使用してAmazon Elastic Kubernetes Service上のワークロードを自動的にスケールする" +tmdTranslationSourceHash: 'd769f5905db18fbbe1dcf4ebd3b78bf5' +--- + +:::tip 事前に設定されている内容 +Amazon EKS Auto Modeクラスターが作成された後、KEDA Operator用のIAMロールが設定されています +::: + +オートスケーリングは、ワークロードを監視し、安定した予測可能なパフォーマンスを維持しながら、コストを最適化するために容量を自動的に調整します。Kubernetesを使用する場合、自動的にスケールするために使用できる主な関連メカニズムは2つあります： + +- **コンピュート：** Podがスケールされると、Kubernetesクラスター内の基盤となるコンピュートも、Podを実行するために使用されるワーカーノードの数またはサイズを調整することで適応する必要があります。 +- **Pod：** Podはkubernetesクラスター内でワークロードを実行するために使用されるため、ワークロードのスケーリングは主に、特定のアプリケーションへの負荷の変化などのシナリオに応じて、Podを水平または垂直にスケールすることによって行われます。 + +このラボでは、[Kubernetes Event-Driven Autoscaler (KEDA)](https://keda.sh/)を使用してdeployment内のPodをスケールする方法を見ていきます。この目的のために使用できる別のオプションとして、Horizontal Pod Autoscaler (HPA)があり、平均CPU使用率に基づいてPodを水平にスケールするために使用できます。しかし、ワークロードは外部イベントやメトリクスに基づいてスケールする必要がある場合があります。そのため、KEDAは、Amazon SQSのキューの長さやCloudWatchの他のメトリクスなど、さまざまなイベントソースからのイベントに基づいてワークロードをスケールする機能を提供します。KEDAは、さまざまなメトリクスシステム、データベース、メッセージングシステムなどに対応する60以上の[scaler](https://keda.sh/docs/scalers/)をサポートしています。 + +KEDAは、Helmチャートを使用してKubernetesクラスターにデプロイできる軽量のワークロードです。KEDAは、Horizontal Pod AutoscalerのようなKubernetesの標準コンポーネントと連携して、DeploymentまたはStatefulSetをスケールします。KEDAを使用すると、これらのさまざまなイベントソースでスケールしたいワークロードを選択的に選択できます。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/keda/install-keda.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/keda/install-keda.md new file mode 100644 index 0000000000..2ed9651ca4 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/keda/install-keda.md @@ -0,0 +1,58 @@ +--- +title: "KEDAのインストール" +sidebar_position: 5 +tmdTranslationSourceHash: '5f7ef8141f2a607cd661c7d3cc86726a' +--- + +まず、Helmを使用してKEDAをインストールしましょう。Auto Modeクラスターのセットアップ時に、CloudWatch内のメトリックデータにアクセスするための権限を持つIAMロールが作成されました。 + +Amazon EKS Auto Modeでは、IRSAの代わりにEKS Pod Identityを使用します。Pod Identity関連付けを作成しましょう： + +```bash wait=10 +$ export KEDA_ROLE_ARN=arn:aws:iam::${AWS_ACCOUNT_ID}:role/${EKS_CLUSTER_AUTO_NAME}-keda +$ aws eks create-pod-identity-association --cluster-name ${EKS_CLUSTER_AUTO_NAME} \ + --role-arn ${KEDA_ROLE_ARN} \ + --namespace keda --service-account keda-operator | jq . +``` + +次にKEDAをインストールします： + +```bash timeout=300 +$ export KEDA_CHART_VERSION=$(grep -oP 'default\s*=\s*"\K[^"]+' ~/environment/eks-workshop/modules/autoscaling/workloads/keda/.workshop/terraform/vars.tf | tail -1) +$ helm repo add kedacore https://kedacore.github.io/charts +$ helm upgrade --install keda kedacore/keda \ + --version "${KEDA_CHART_VERSION}" \ + --namespace keda \ + --create-namespace \ + --wait +Release "keda" does not exist. Installing it now. +NAME: keda +LAST DEPLOYED: [...] +NAMESPACE: kube-system +STATUS: deployed +REVISION: 1 +TEST SUITE: None +NOTES: +[...] +``` + +Helmインストール後、KEDAはkedaネームスペース内に複数のDeploymentとして実行されます： + +```bash +$ kubectl rollout restart deployment/keda-operator -n keda +$ kubectl rollout status deployment/keda-operator -n keda --timeout=120s +$ kubectl get deployment -n keda +NAME READY UP-TO-DATE AVAILABLE AGE +keda-admission-webhooks 1/1 1 1 105s +keda-operator 1/1 1 1 105s +keda-operator-metrics-apiserver 1/1 1 1 105s +``` + +各KEDAのDeploymentは異なる重要な役割を果たします： + +1. Agent (keda-operator) - ワークロードのスケーリングを制御します +2. Metrics (keda-operator-metrics-server) - Kubernetesメトリックサーバーとして機能し、外部メトリックへのアクセスを提供します +3. Admission Webhooks (keda-admission-webhooks) - 設定ミスを防ぐためにリソース設定を検証します（例：同じワークロードをターゲットとする複数のScaledObject） + +これで、ワークロードをスケーリングするためのKEDAの設定に進むことができます。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/keda/test-keda.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/keda/test-keda.md new file mode 100644 index 0000000000..be1795de79 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/keda/test-keda.md @@ -0,0 +1,64 @@ +--- +title: "負荷の生成" +sidebar_position: 20 +tmdTranslationSourceHash: 'd1bf6954cff0fd4986118348039d7617' +--- + +設定したKEDA `ScaledObject`に応答してKEDAがDeploymentをスケールする様子を観察するには、アプリケーションに負荷を生成する必要があります。[hey](https://github.com/rakyll/hey)を使用してワークロードのホームページを呼び出すことで負荷を生成します。 + +以下のコマンドは、次の設定で負荷ジェネレーターを実行します: + +- 3つのワーカーが同時に実行 +- それぞれが1秒あたり5クエリを送信 +- 最大10分間実行 + +```bash hook=keda-pod-scaleout hookTimeout=660 wait=300 +$ export ALB_HOSTNAME=$(kubectl get ingress ui-auto -n ui -o yaml | yq .status.loadBalancer.ingress[0].hostname) +$ kubectl run load-generator \ + --image=williamyeh/hey:latest \ + --restart=Never -- -c 3 -q 5 -z 10m http://$ALB_HOSTNAME/home +``` + +`ScaledObject`に基づいて、KEDAはHPAリソースを作成し、HPAがワークロードをスケールするために必要なメトリクスを提供します。アプリケーションにリクエストが到達している状態で、HPAリソースを監視して進行状況を確認できます: + +```bash test=false +$ kubectl get hpa keda-hpa-ui-hpa -n ui --watch +NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE +keda-hpa-ui-hpa Deployment/ui 7/100 (avg) 1 10 1 7m58s +keda-hpa-ui-hpa Deployment/ui 778/100 (avg) 1 10 1 8m33s +keda-hpa-ui-hpa Deployment/ui 194500m/100 (avg) 1 10 4 8m48s +keda-hpa-ui-hpa Deployment/ui 97250m/100 (avg) 1 10 8 9m3s +keda-hpa-ui-hpa Deployment/ui 625m/100 (avg) 1 10 8 9m18s +keda-hpa-ui-hpa Deployment/ui 91500m/100 (avg) 1 10 8 9m33s +keda-hpa-ui-hpa Deployment/ui 92125m/100 (avg) 1 10 8 9m48s +keda-hpa-ui-hpa Deployment/ui 750m/100 (avg) 1 10 8 10m +keda-hpa-ui-hpa Deployment/ui 102625m/100 (avg) 1 10 8 10m +keda-hpa-ui-hpa Deployment/ui 113625m/100 (avg) 1 10 8 11m +keda-hpa-ui-hpa Deployment/ui 90900m/100 (avg) 1 10 10 11m +keda-hpa-ui-hpa Deployment/ui 91500m/100 (avg) 1 10 10 12m +``` + +オートスケーリングの動作に満足したら、`Ctrl+C`でwatchを終了し、次のように負荷ジェネレーターを停止できます: + +```bash +$ kubectl delete pod load-generator --ignore-not-found +``` + +負荷ジェネレーターが終了すると、HPAは設定に基づいて最小レプリカ数までゆっくりと減らしていくことに注目してください。 + +CloudWatchコンソールで負荷テストの結果を確認することもできます: + + + +お使いのアカウントでこのグラフを再現するには、CloudWatchメトリクスコンソールから、2つのメトリクスを追加し、それに応じてグラフを設定する必要があります: + +1. **Metrics**の下で、クラスターと同じリージョンにいることを確認します。 +1. **ApplicationELB > Per AppELB Metrics, per TG Metrics**の下で、`RequestCount`と`RequestCountPerTarget`を選択します。 +1. **Graphed Metrics (2)**タブをクリックし、各メトリクスに対して以下を実行します: + 1. **Statistic**を`Average`から`Sum`に変更します。 + 1. **Period**を`5 minutes`から`1 minute`に変更します。 + +結果から、最初はすべての負荷が単一のPodで処理されていましたが、KEDAがワークロードをスケールし始めると、リクエストはロードバランサーのターゲットグループで有効なターゲットになった追加のPodに分散されることがわかります。負荷ジェネレーターPodを10分間実行させた場合、このような結果が表示されます。 + +![Insights](/img/keda/keda-cloudwatch.png) + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/pod-logging/fluent-bit-cloudwatch.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/pod-logging/fluent-bit-cloudwatch.md new file mode 100644 index 0000000000..0e38400583 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/pod-logging/fluent-bit-cloudwatch.md @@ -0,0 +1,72 @@ +--- +title: "CloudWatch でのログの確認" +sidebar_position: 40 +pagination_next: fastpaths/explore/index +tmdTranslationSourceHash: 'afbf0c15420bd6ef0df8e46d32ec8c2c' +--- + +このラボ演習では、各ノードにデプロイされた Fluent Bit エージェントによって Amazon CloudWatch Logs に転送された Kubernetes Pod のログを確認する方法を見ていきます。デプロイされたアプリケーションコンポーネントは `stdout` にログを書き込み、それらは各ノードの `/var/log/containers/*.log` パスに保存されます。 + +まず、Fluent Bit を有効にして以降に新しいログが書き込まれるように、`ui` コンポーネントの Pod をリサイクルしましょう。 + +```bash timeout=180 +$ kubectl delete pod -n ui --all +$ kubectl rollout status deployment/ui \ + -n ui --timeout 120s +deployment "ui" successfully rolled out +``` + +その間に、Fluent Bit DaemonSet のログを確認すると、`ui` コンポーネント用の既存のロググループの下に新しいログストリームが作成されているのが確認できます。 + +```bash hook=pods-log +$ kubectl logs daemonset.apps/aws-for-fluent-bit -n amazon-cloudwatch +... +[2025/04/15 12:40:10] [ info] [filter:kubernetes:kubernetes.0] token updated +[2025/04/15 12:40:10] [ info] [input:tail:tail.0] inotify_fs_add(): inode=16895961 watch_fd=12 name=/var/log/containers/ui-8564fc5cfb-qb7td_ui_ui-4ace14944409ee785708c9031b4c2243bfa065ffe0cd320e219131aa33541a1e.log +[2025/04/15 12:40:11] [ info] [output:cloudwatch_logs:cloudwatch_logs.0] Creating log stream ui-8564fc5cfb-qb7td.ui in log group /aws/eks/fluentbit-cloudwatch/workload/ui +[2025/04/15 12:40:11] [ info] [output:cloudwatch_logs:cloudwatch_logs.0] Created log stream ui-8564fc5cfb-qb7td.ui + +``` + +次に、`ui` コンポーネントが `kubectl logs` を直接使用してログを作成していることを確認できます: + +```bash +$ kubectl logs -n ui deployment/ui +Picked up JAVA_TOOL_OPTIONS: -javaagent:/opt/aws-opentelemetry-agent.jar +OpenJDK 64-Bit Server VM warning: Sharing is only supported for boot loader classes because bootstrap classpath has been appended +[otel.javaagent 2023-07-03 23:39:18:499 +0000] [main] INFO io.opentelemetry.javaagent.tooling.VersionLogger - opentelemetry-javaagent - version: 1.24.0-aws + + . ____ _ __ _ _ + /\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \ +( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \ + \\/ ___)| |_)| | | | | || (_| | ) ) ) ) + ' |____| .__|_| |_|_| |_\__, | / / / / + =========|_|==============|___/=/_/_/_/ + :: Spring Boot :: (v3.0.6) + +2023-07-03T23:39:20.472Z INFO 1 --- [ main] c.a.s.u.UiApplication : Starting UiApplication v0.0.1-SNAPSHOT using Java 17.0.7 with PID 1 (/app/app.jar started by appuser in /app) +2023-07-03T23:39:20.488Z INFO 1 --- [ main] c.a.s.u.UiApplication : No active profile set, falling back to 1 default profile: "default" +2023-07-03T23:39:24.985Z WARN 1 --- [ main] o.s.b.a.e.EndpointId : Endpoint ID 'fail-cart' contains invalid characters, please migrate to a valid format. +2023-07-03T23:39:25.132Z INFO 1 --- [ main] o.s.b.a.e.w.EndpointLinksResolver : Exposing 15 endpoint(s) beneath base path '/actuator' +2023-07-03T23:39:25.567Z INFO 1 --- [ main] o.s.b.w.e.n.NettyWebServer : Netty started on port 8080 +2023-07-03T23:39:25.599Z INFO 1 --- [ main] c.a.s.u.UiApplication : Started UiApplication in 5.877 seconds (process running for 7.361) +``` + +CloudWatch Logs コンソールを開いて、これらのログが表示されているかを確認します: + + + +**fluentbit-cloudwatch** でフィルタリングして、Fluent Bit によって作成されたロググループを見つけます: + +![CloudWatch Log Group](/img/fastpaths/developer/pod-logging/log-group.webp) + +`/eks-workshop-auto/worker-fluentbit-logs-*` を選択してログストリームを表示します。各ログストリームは個別の Pod に対応しています: + +![CloudWatch Log Stream](/img/fastpaths/developer/pod-logging/log-streams.webp) + +ログエントリの 1 つを展開すると、完全な JSON ペイロードを確認できます: + +![Pod logs](/img/fastpaths/developer/pod-logging/logs.webp) + +これで、開発者向けの EKS ワークショップのファーストパスは終了です。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/pod-logging/fluentbit-setup.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/pod-logging/fluentbit-setup.md new file mode 100644 index 0000000000..67e79479ac --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/pod-logging/fluentbit-setup.md @@ -0,0 +1,120 @@ +--- +title: "Fluent Bit の使用" +sidebar_position: 30 +tmdTranslationSourceHash: 'cf5dd128b67e44605330033bcd0b49b9' +--- + +このラボでは、EKS Auto Mode クラスターで [Fluent Bit](https://fluentbit.io/) ロギングエージェントを DaemonSet として設定します。 + +Fluent Bit は、さまざまなソースからデータとログを収集し、フィルターで強化して、CloudWatch、Kinesis Data Firehose、Kinesis Data Streams、Amazon OpenSearch Service などの複数の宛先に送信できる軽量なログプロセッサーおよびフォワーダーです。 + +AWS は、CloudWatch Logs と Kinesis Data Firehose の両方のプラグインを備えた Fluent Bit イメージを提供しています。[AWS for Fluent Bit](https://github.com/aws/aws-for-fluent-bit) イメージは [Amazon ECR Public Gallery](https://gallery.ecr.aws/aws-observability/aws-for-fluent-bit) で利用できます。 + +Fluent Bit は、さまざまな宛先にログを送信するために使用できます。ただし、このラボでは、コンテナログを CloudWatch に送信するためにどのように活用されるかを見ていきます。 + +![Fluent-bit Architecture](/img/fastpaths/developer/pod-logging/fluentbit-architecture.png) + +次のセクションでは、Fluent Bit エージェントがコンテナ / Pod のログを CloudWatch Logs に送信するために DaemonSet として既に実行されていることを検証する方法を見ていきます。[コンテナから CloudWatch Logs にログを送信するために Fluent Bit をデプロイする方法](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-setup-logs-FluentBit.html#Container-Insights-FluentBit-troubleshoot)の詳細をご覧ください。 + +まず、次のコマンドを入力して、Fluent Bit 用に作成されたリソースを検証できます。各ノードには 1 つの Pod が必要です： + +```bash hook=get-all +$ kubectl get all -n amazon-cloudwatch -l app.kubernetes.io/name=aws-for-fluent-bit +NAME READY STATUS RESTARTS AGE +pod/aws-for-fluent-bit-jg4jr 1/1 Running 0 94s +pod/aws-for-fluent-bit-lvp9f 1/1 Running 0 95s +pod/aws-for-fluent-bit-q959s 1/1 Running 0 94s + +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +service/aws-for-fluent-bit ClusterIP 172.16.41.165 2020/TCP 96s + +NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE +daemonset.apps/aws-for-fluent-bit 3 3 3 3 3 96s +``` + +`aws-for-fluent-bit` の ConfigMap は、各ノードからディレクトリ `/var/log/containers/*.log` 内のファイルの内容を CloudWatch ロググループ `/eks-workshop/worker-fluentbit-logs` にストリーミングするように設定されています。 + +```bash hook=desc-cm +$ kubectl describe configmap -n amazon-cloudwatch -l app.kubernetes.io/name=aws-for-fluent-bit +Name: aws-for-fluent-bit +Namespace: kube-system +Labels: app.kubernetes.io/instance=aws-for-fluent-bit + app.kubernetes.io/managed-by=Helm + app.kubernetes.io/name=aws-for-fluent-bit + app.kubernetes.io/version=2.31.12.20231011 + helm.sh/chart=aws-for-fluent-bit-0.1.32 +Annotations: meta.helm.sh/release-name: aws-for-fluent-bit + meta.helm.sh/release-namespace: kube-system + +Data +==== +fluent-bit.conf: +---- +[SERVICE] + HTTP_Server On + HTTP_Listen 0.0.0.0 + HTTP_PORT 2020 + Health_Check On + HC_Errors_Count 5 + HC_Retry_Failure_Count 5 + HC_Period 5 + + Parsers_File /fluent-bit/parsers/parsers.conf +[INPUT] + Name tail + Tag kube.* + Path /var/log/containers/*.log + DB /var/log/flb_kube.db + multiline.parser docker, cri + Mem_Buf_Limit 5MB + Skip_Long_Lines On + Refresh_Interval 10 +[FILTER] + Name kubernetes + Match kube.* + Kube_URL https://kubernetes.default.svc.cluster.local:443 + Merge_Log On + Merge_Log_Key data + Keep_Log On + K8S-Logging.Parser On + K8S-Logging.Exclude On + Buffer_Size 32k +[OUTPUT] + Name cloudwatch_logs + Match * + region us-west-2 + log_group_name /aws/eks/eks-workshop/aws-fluentbit-logs-20250415195811907400000002 + log_stream_prefix fluentbit- +... +``` + +`kubectl logs` コマンドを使用して Fluent Bit Pod のログを確認します。ここで、サービス用に新しい CloudWatch Log グループとストリームが作成されていることが確認できます。 + +```bash hook=pods-log +$ kubectl logs daemonset.apps/aws-for-fluent-bit -n amazon-cloudwatch + +Found 3 pods, using pod/aws-for-fluent-bit-4mnbw +AWS for Fluent Bit Container Image Version 2.28.4 +Fluent Bit v1.9.9 +* Copyright (C) 2015-2022 The Fluent Bit Authors +* Fluent Bit is a CNCF sub-project under the umbrella of Fluentd +* https://fluentbit.io + +[2025/04/14 16:15:40] [ info] [fluent bit] version=1.9.9, commit=5fcfe330e5, pid=1 +[2025/04/14 16:15:40] [ info] [storage] version=1.3.0, type=memory-only, sync=normal, checksum=disabled, max_chunks_up=128 +[2025/04/14 16:15:40] [ info] [cmetrics] version=0.3.7 +... +[2025/04/14 16:15:40] [ info] [filter:kubernetes:kubernetes.0] connectivity OK +[2025/04/14 16:15:40] [ info] [sp] stream processor started +[2025/04/14 16:15:40] [ info] [output:cloudwatch_logs:cloudwatch_logs.0] worker #0 started +... +[2025/04/14 16:16:01] [ info] [output:cloudwatch_logs:cloudwatch_logs.0] Creating log stream ui-8564fc5cfb-54llk.ui in log group /aws/eks/fluentbit-cloudwatch/workload/ui +[2025/04/14 16:16:01] [ info] [output:cloudwatch_logs:cloudwatch_logs.0] Log Group /aws/eks/fluentbit-cloudwatch/workload/ui not found. Will attempt to create it. +[2025/04/14 16:16:01] [ info] [output:cloudwatch_logs:cloudwatch_logs.0] Creating log group /aws/eks/fluentbit-cloudwatch/workload/ui +[2025/04/14 16:16:01] [ info] [output:cloudwatch_logs:cloudwatch_logs.0] Created log group /aws/eks/fluentbit-cloudwatch/workload/ui +[2025/04/14 16:16:01] [ info] [output:cloudwatch_logs:cloudwatch_logs.0] Creating log stream ui-8564fc5cfb-54llk.ui in log group /aws/eks/fluentbit-cloudwatch/workload/ui +[2025/04/14 16:16:01] [ info] [output:cloudwatch_logs:cloudwatch_logs.0] Created log stream ui-8564fc5cfb-54llk.ui +``` + +次のラボでは、これらのログを CloudWatch で検証します。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/pod-logging/index.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/pod-logging/index.md new file mode 100644 index 0000000000..7f6a2f0dc3 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/developer/pod-logging/index.md @@ -0,0 +1,21 @@ +--- +title: "ワークロードログへのアクセス" +sidebar_position: 90 +description: "Amazon Elastic Kubernetes Service 上で実行されている Pod からワークロードログをキャプチャします。" +tmdTranslationSourceHash: 'da925ddc830e75594e43b7f6ebb12cf5' +--- + +:::tip セットアップされているもの +Amazon EKS Auto Mode クラスターは Fluent Bit ログ収集エージェントで構成されています。 +::: + +モダンアプリケーションのアーキテクチャのゴールドスタンダードを提供する [Twelve-Factor App マニフェスト](https://12factor.net/)によると、コンテナ化されたアプリケーションは[ログを stdout と stderr に出力する](https://12factor.net/logs)べきです。これは Kubernetes でもベストプラクティスと考えられています。 + +アプリケーションログは、開発者がアプリケーションの動作をデバッグする必要があるときの最良の友です。しかし、Kubernetes はすぐに使えるログの収集と保存のネイティブソリューションを提供していません。コンテナランタイムが JSON 形式でログをローカルファイルシステムに保存するように設定するだけです。Docker などのコンテナランタイムは、コンテナの `stdout` と `stderr` ストリームをロギングドライバーにリダイレクトします。Kubernetes では、コンテナログはノード上の `/var/log/pods/*.log` に書き込まれます。これらのログは `kubectl logs myapp` コマンドを使用してアクセスできます。ここで `myapp` はクラスター内で実行されている Pod または Deployment です。しかし、この方法でログにアクセスすることは、本番環境ではスケーラブルではありません。そのためには、Fluent Bit のようなクラスター全体のログコレクターシステムが必要です。このシステムは、ノード上のこれらのログファイルを tail して、CloudWatch のようなログ保持および検索システムにログを送信できます。これらのログコレクターシステムは通常、ワーカーノード上で DaemonSet として実行されます。 + +このラボでは、ログエージェントである Fluent Bit を設定して、EKS のノードからアプリケーションログを収集し、CloudWatch Logs に送信する方法を示します。 + +:::info +CDK Observability Accelerator を使用している場合は、[AWS for Fluent Bit Addon](https://aws-quickstart.github.io/cdk-eks-blueprints/addons/aws-for-fluent-bit/) をご確認ください。AWS for FluentBit アドオンは、CloudWatch、Amazon Kinesis、AWS OpenSearch などの複数の AWS 送信先にログを転送するように構成できます。 +::: + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/explore/index.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/explore/index.md new file mode 100644 index 0000000000..28b6ee0033 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/explore/index.md @@ -0,0 +1,15 @@ +--- +title: "探索" +sidebar_position: 80 +pagination_prev: null +tmdTranslationSourceHash: 'c66660641d7c0a875c6bce7029ab955d' +--- + +おめでとうございます。ラーニングパスが完了しました！アプリケーションを通じてフィードバックをお寄せいただくことをお忘れなく！ + +まだ時間がある場合は、[モジュラーワークショップモジュール](/docs/introduction)で追加のコンテンツを探索してみてはいかがでしょうか？これらはネットワーキング、セキュリティ、可観測性など、より深いトピックをカバーしています。各モジュールの開始時に `prepare-environment` コマンドを実行することをお忘れなく。 + +import HomepageModuleLink from "@site/src/components/HomepageModuleLink"; + + + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/getting-started/about.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/getting-started/about.md new file mode 100644 index 0000000000..8c32d9af36 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/getting-started/about.md @@ -0,0 +1,60 @@ +--- +title: アプリケーションアーキテクチャ +sidebar_position: 10 +tmdTranslationSourceHash: '17e4cc9815c4309693f27a2a653bb847' +--- + +このワークショップのほとんどのラボでは、共通のサンプルアプリケーションを使用して、演習中に作業できる実際のコンテナコンポーネントを提供します。サンプルアプリケーションは、顧客がカタログを閲覧し、カートにアイテムを追加し、チェックアウトプロセスを通じて注文を完了できるシンプルなウェブストアアプリケーションをモデル化しています。 + + + + + +このアプリケーションには、いくつかのコンポーネントと依存関係があります： + + + +| コンポーネント | 説明 | +| --------- | ----------- | +| UI | フロントエンドのユーザーインターフェースを提供し、他のさまざまなサービスへのAPIコールを集約します。 | +| Catalog | 商品リストと詳細のAPIです | +| Cart | 顧客のショッピングカートのAPIです | +| Checkout | チェックアウトプロセスを調整するAPIです | +| Orders | 顧客の注文を受け取り処理するAPIです | + +最初は、ロードバランサーやマネージドデータベースなどのAWSサービスを使用せず、Amazon EKSクラスター内で自己完結する方法でアプリケーションをデプロイします。ラボを進めるうちに、EKSのさまざまな機能を活用して、小売店舗のためにより広範なAWSサービスと機能を活用していきます。 + +サンプルアプリケーションの完全なソースコードは[GitHub](https://github.com/aws-containers/retail-store-sample-app)で確認できます。 + +## コンテナイメージ + +各コンポーネントはコンテナイメージとしてパッケージ化され、Amazon ECR Publicに公開されています： + +| コンポーネント | ECR Publicリポジトリ | Dockerfile | +| --------- | --------------------- | ---------- | +| UI | [Repository](https://gallery.ecr.aws/aws-containers/retail-store-sample-ui) | [Dockerfile](https://github.com/aws-containers/retail-store-sample-app/blob/v1.2.1/src/ui/Dockerfile) | +| Catalog | [Repository](https://gallery.ecr.aws/aws-containers/retail-store-sample-catalog) | [Dockerfile](https://github.com/aws-containers/retail-store-sample-app/blob/v1.2.1/src/catalog/Dockerfile) | +| Cart | [Repository](https://gallery.ecr.aws/aws-containers/retail-store-sample-cart) | [Dockerfile](https://github.com/aws-containers/retail-store-sample-app/blob/v1.2.1/src/cart/Dockerfile) | +| Checkout | [Repository](https://gallery.ecr.aws/aws-containers/retail-store-sample-checkout) | [Dockerfile](https://github.com/aws-containers/retail-store-sample-app/blob/v1.2.1/src/checkout/Dockerfile) | +| Orders | [Repository](https://gallery.ecr.aws/aws-containers/retail-store-sample-orders) | [Dockerfile](https://github.com/aws-containers/retail-store-sample-app/blob/v1.2.1/src/orders/Dockerfile) | + +## Kubernetesアーキテクチャ + +**catalog**コンポーネントがKubernetesリソースにどのようにマッピングされるかを見てみましょう： + + + +この図では、考慮すべき点がいくつかあります： + +- catalog APIを提供するアプリケーションは[Pod](https://kubernetes.io/docs/concepts/workloads/pods/)として実行されます。これはKubernetesで最も小さなデプロイ可能な単位です。アプリケーションPodは、前のセクションで概説したコンテナイメージを実行します。 +- catalogコンポーネントに対して実行されるPodは、[Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)によって作成され、catalog Podの1つ以上の「レプリカ」を管理して、水平方向にスケールできるようにします。 +- [Service](https://kubernetes.io/docs/concepts/services-networking/service/)は、Podのセットとして実行されているアプリケーションを公開する抽象的な方法であり、これによりcatalog APIがKubernetesクラスター内の他のコンポーネントから呼び出されることを可能にします。各ServiceにはそれぞれのDNSエントリが与えられます。 +- このワークショップの開始時には、Kubernetesクラスター内で[StatefulSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/)として実行されるMySQLデータベースがあります。これはステートフルなワークロードを管理するために設計されています。 +- これらのKubernetesコンストラクトはすべて、専用のcatalog Namespaceにグループ化されています。各アプリケーションコンポーネントには独自のNamespaceがあります。 + +マイクロサービスアーキテクチャの各コンポーネントは、概念的にcatalogと似ており、Deploymentsを使用してアプリケーションワークロードPodを管理し、Servicesを使用してそれらのPodにトラフィックをルーティングします。アーキテクチャの広範なビューを拡張すると、システム全体でトラフィックがどのようにルーティングされるかを考えることができます： + + + +**ui**コンポーネントは、たとえばユーザーのブラウザからHTTPリクエストを受け取ります。次に、アーキテクチャ内の他のAPIコンポーネントにHTTPリクエストを行ってそのリクエストを満たし、ユーザーにレスポンスを返します。各ダウンストリームコンポーネントは、独自のデータストアまたは他のインフラストラクチャを持つことができます。Namespaceは各マイクロサービスのリソースの論理的なグループ化であり、ソフトな分離境界としても機能し、Kubernetes RBACとNetwork Policiesを使用して効果的にコントロールを実装するために使用できます。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/getting-started/finish.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/getting-started/finish.md new file mode 100644 index 0000000000..81d2fabc7a --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/getting-started/finish.md @@ -0,0 +1,114 @@ +--- +title: その他のコンポーネント +sidebar_position: 50 +pagination_next: null +tmdTranslationSourceHash: 50d648c69e8d1ee1c8a365c24b4097c3 +--- + +このラボ演習では、Kustomizeの力を活用してサンプルアプリケーションの残りの部分を効率的にデプロイします。次のkustomizationファイルは、他のkustomizationを参照して複数のコンポーネントを一緒にデプロイする方法を示しています： + +```file +manifests/base-application/kustomization.yaml +``` + +:::tip +Catalog APIがこのkustomizationに含まれていることに注目してください。既にデプロイしたのではないでしょうか？ + +KubernetesはDeclareativeなメカニズムを使用しているため、Catalog APIのマニフェストを再度適用でき、すべてのリソースが既に作成されているためKubernetesはアクションを実行しないことを期待できます。 +::: + +このkustomizationをクラスターに適用して、残りのコンポーネントをデプロイします： + +```bash wait=10 +$ kubectl apply -k ~/environment/eks-workshop/base-application +``` + +:::info +追加のワークロードをデプロイすると、EKS Auto Modeは新しいPodを収容するために必要に応じて追加のコンピュートインスタンスを自動的にプロビジョニングします。 +::: + +EKS Auto Modeがワークロード用にノードをプロビジョニングする様子を確認してください。EKS Auto Modeがアプリケーション用にgeneral-purposeノードプールに2つ目のノードをプロビジョニングする様子が表示されます。また、Podを移動する容量があるため、systemノードも統合されます。 + +```bash timeout=180 test=false +$ kubectl get nodes --watch +... +NAME STATUS ROLES AGE VERSION +i-082b0e8be0994671a NotReady 1s v1.33.4-eks-e386d34 +... +i-082b0e8be0994671a Ready 2s v1.33.4-eks-e386d34 +``` + +前のコマンドを実行するタイミングによっては、`NotReady`または`Ready`ステータスのノードが表示される場合があります。ただし、いずれの場合でも、最も新しいAgeを持つ新しいノードが表示されるはずです。ノードが表示されたら、`Ctrl+C`を押してウォッチを停止してください。Podは実行中になります： + +Kubernetesはさまざまな目的でラベルを使用します。たとえば、ノードにはNodePoolを示すラベルがあり、次のコマンドで確認できます： +```bash +$ kubectl get nodes -o json | jq -c '.items[] | {name: .metadata.name, nodepool: .metadata.labels."karpenter.sh/nodepool"}' +{"name":"i-082b0e8be0994671a","nodepool":"general-purpose"} +{"name":"i-0af75b7f0f828f36c","nodepool":"general-purpose"} +``` + + +これが完了したら、`kubectl wait`を使用して、続行する前にすべてのコンポーネントが起動していることを確認できます： + +```bash timeout=200 +$ kubectl wait --for=condition=Ready --timeout=180s pods \ + -l app.kubernetes.io/created-by=eks-workshop -A +``` + +これで、各アプリケーションコンポーネント用のNamespaceが作成されます： + +```bash +$ kubectl get namespaces -l app.kubernetes.io/created-by=eks-workshop +NAME STATUS AGE +carts Active 62s +catalog Active 7m17s +checkout Active 62s +orders Active 62s +other Active 62s +ui Active 62s +``` + +コンポーネント用に作成されたすべてのリソースも確認できます： + +```bash +$ kubectl get all -l app.kubernetes.io/created-by=eks-workshop -A +NAMESPACE NAME READY STATUS RESTARTS AGE +carts pod/carts-68d496fff8-h2w84 1/1 Running 1 (75s ago) 89s +carts pod/carts-dynamodb-995f7768c-s6wv2 1/1 Running 0 89s +catalog pod/catalog-5fdcc8c65-rrcbh 1/1 Running 3 (68s ago) 89s +catalog pod/catalog-mysql-0 1/1 Running 0 88s +checkout pod/checkout-5b885fb57c-8bkf2 1/1 Running 0 89s +checkout pod/checkout-redis-69cb79ff4d-vxjlh 1/1 Running 0 89s +orders pod/orders-74f89d6dbd-pw58j 1/1 Running 0 88s +orders pod/orders-postgresql-0 1/1 Running 0 88s +ui pod/ui-5989474687-tqps9 1/1 Running 0 88s + +NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +carts service/carts ClusterIP 172.20.64.186 80/TCP 89s +carts service/carts-dynamodb ClusterIP 172.20.187.59 8000/TCP 89s +catalog service/catalog ClusterIP 172.20.242.75 80/TCP 89s +catalog service/catalog-mysql ClusterIP 172.20.4.209 3306/TCP 89s +... +``` + +サンプルアプリケーションがデプロイされ、このワークショップの残りのラボで使用する基盤を提供する準備が整いました！ + +## 次のステップ + +サンプルアプリケーションをデプロイしたので、学習の旅を定義するために2つのオプションのいずれかを選択してください。 + + + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/getting-started/first.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/getting-started/first.md new file mode 100644 index 0000000000..c99c6837df --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/getting-started/first.md @@ -0,0 +1,148 @@ +--- +title: 最初のコンポーネントのデプロイ +sidebar_position: 40 +tmdTranslationSourceHash: '0dbec28f9d8a26b4d0a8e6cd338727a4' +--- + +サンプルアプリケーションは、Kustomize で簡単に適用できるように構成された Kubernetes マニフェストのセットで構成されています。Kustomize はオープンソースのツールであり、`kubectl` CLI のネイティブ機能としても提供されています。このワークショップでは、Kustomize を使用して Kubernetes マニフェストに変更を適用し、YAML を手動で編集することなくマニフェストファイルの変更を理解しやすくします。このワークショップのさまざまなモジュールを進めていく中で、Kustomize を使用してオーバーレイとパッチを段階的に適用していきます。 + +サンプルアプリケーションと、このワークショップのモジュールの YAML マニフェストを参照する最も簡単な方法は、IDE のファイルブラウザを使用することです。 + +![IDE files](/img/fastpaths/getting-started/ide-initial.webp) + +`eks-workshop` を展開し、次に `base-application` の項目を展開すると、サンプルアプリケーションの初期状態を構成するマニフェストを参照できます。 + +![IDE files base](/img/fastpaths/getting-started/ide-base.webp) + +この構造は、**サンプルアプリケーション**セクションで概説された各アプリケーションコンポーネントのディレクトリで構成されています。 + +`modules` ディレクトリには、後続のラボ演習全体でクラスタに適用するマニフェストのセットが含まれています。 + +![IDE files modules](/img/fastpaths/getting-started/ide-modules.webp) + +何かを行う前に、EKS クラスタの現在の Namespace を確認しましょう。 + +```bash +$ kubectl get namespaces +NAME STATUS AGE +default Active 30h +kube-node-lease Active 30h +kube-public Active 30h +kube-system Active 30h +``` + +リストされているすべてのエントリは、システムコンポーネントの Namespace です。[Kubernetes labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) を使用して、作成した Namespace のみにフィルタリングします。 + +```bash +$ kubectl get namespaces -l app.kubernetes.io/created-by=eks-workshop +No resources found +``` + +最初に行うことは、catalog コンポーネントを単独でデプロイすることです。このコンポーネントのマニフェストは `~/environment/eks-workshop/base-application/catalog` にあります。 + +```bash +$ ls ~/environment/eks-workshop/base-application/catalog +configMap.yaml +deployment.yaml +kustomization.yaml +namespace.yaml +secrets.yaml +service-mysql.yaml +service.yaml +serviceAccount.yaml +statefulset-mysql.yaml +``` + +これらのマニフェストには、catalog API の望ましい状態を表現する Deployment が含まれています。 + +::yaml{file="manifests/base-application/catalog/deployment.yaml" paths="spec.replicas,spec.template.metadata.labels,spec.template.spec.containers.0.image,spec.template.spec.containers.0.ports,spec.template.spec.containers.0.livenessProbe,spec.template.spec.containers.0.resources"} + +1. 単一のレプリカを実行します +2. 他のリソースが参照できるように、Pod にラベルを適用します +3. `public.ecr.aws/aws-containers/retail-store-sample-catalog` コンテナイメージを使用します +4. `http` という名前のポート 8080 でコンテナを公開します +5. `/health` パスに対して [probes/healthchecks](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/) を実行します +6. Kubernetes スケジューラが十分な利用可能リソースを持つノードに配置できるように、特定の量の CPU とメモリを[リクエスト](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/)します + +マニフェストには、他のコンポーネントが catalog API にアクセスするために使用する Service も含まれています。 + +::yaml{file="manifests/base-application/catalog/service.yaml" paths="spec.ports,spec.selector"} + +1. ポート 80 で自身を公開し、Deployment によって公開される `http` ポートをターゲットにします。これはポート 8080 に変換されます +2. 上記の Deployment で表現したものと一致するラベルを使用して catalog Pod を選択します + +catalog コンポーネントを作成しましょう。 + +```bash +$ kubectl apply -k ~/environment/eks-workshop/base-application/catalog +namespace/catalog created +serviceaccount/catalog created +configmap/catalog created +secret/catalog-db created +service/catalog created +service/catalog-mysql created +deployment.apps/catalog created +statefulset.apps/catalog-mysql created +``` + +:::info EKS Auto Mode のコンピュートプロビジョニング +Amazon EKS Auto Mode にワークロードをデプロイすると、クラスタは Pod を実行するための EC2 インスタンスを自動的にプロビジョニングします。このプロセスをリアルタイムで観察してみましょう。 +::: + + + +```bash +$ kubectl get pod -n catalog +NAME READY STATUS RESTARTS AGE +catalog-5fdcc8c65-jkg9f 1/1 Running 2 (87s ago) 2m6s +catalog-mysql-0 1/1 Running 0 2m5s +``` + + + +Pod がまだ準備できていない場合は、[kubectl wait](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#wait) を使用して準備ができるまで待つことができます。 + +```bash timeout=200 +$ kubectl wait --for=condition=Ready pods --all -n catalog --timeout=180s +``` + +Pod が実行されているので、[ログを確認](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#logs)できます。例えば catalog API の場合は次のようになります。 + +:::tip +[kubectl logs の出力を「フォロー」する](https://kubernetes.io/docs/reference/kubectl/cheatsheet/)には、コマンドに '-f' オプションを使用します。（出力のフォローを停止するには CTRL-C を使用します） +::: + +```bash +$ kubectl logs -n catalog deployment/catalog +``` + +Kubernetes では、catalog Pod の数を水平方向に簡単にスケーリングすることもできます。 + +```bash +$ kubectl scale -n catalog --replicas 3 deployment/catalog +deployment.apps/catalog scaled +$ kubectl wait --for=condition=Ready pods --all -n catalog --timeout=180s +``` + +:::info Auto Mode の自動スケーリング +EKS Auto Mode は、ワークロードの需要に合わせてコンピュート容量を自動的にスケーリングします。現在のノードが処理できる以上のレプリカにスケーリングすると、Auto Mode は追加のノードを自動的にプロビジョニングします。クラスタは Pod のリソース要件に基づいて、ノードの配置と容量を継続的に最適化します。 +::: + +適用したマニフェストは、クラスタ内の他のコンポーネントが接続するために使用できる、アプリケーションと MySQL Pod のそれぞれの Service も作成します。 + +```bash +$ kubectl get svc -n catalog +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +catalog ClusterIP 172.20.83.84 80/TCP 2m48s +catalog-mysql ClusterIP 172.20.181.252 3306/TCP 2m48s +``` + +これらの Service はクラスタの内部にあるため、インターネットや VPC からアクセスすることはできません。ただし、[exec](https://kubernetes.io/docs/tasks/debug/debug-application/get-shell-running-container/) を使用して EKS クラスタ内の既存の Pod にアクセスし、catalog API が動作していることを確認できます。 + +```bash timeout=180 +$ kubectl -n catalog exec -i \ + deployment/catalog -- curl catalog.catalog.svc/catalog/products | jq . +``` + +製品情報を含む JSON ペイロードが返されるはずです。おめでとうございます。Kubernetes と EKS を使用して最初のマイクロサービスをデプロイしました！ + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/getting-started/index.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/getting-started/index.md new file mode 100644 index 0000000000..e863c654e3 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/getting-started/index.md @@ -0,0 +1,22 @@ +--- +title: はじめに +sidebar_position: 40 +description: "EKS にサンプル小売アプリケーションをデプロイします。" +sidebar_custom_props: { "module": true } +tmdTranslationSourceHash: 'c4b4ab1218ac34dbc4752330a705553a' +--- + +:::tip 始める前に +この Fast Path では、専用の Amazon EKS Auto Mode クラスターを使用します。Amazon EKS Auto Mode は、クラスター自体を超えて Kubernetes クラスターの AWS 管理を拡張し、コンピュートのオートスケーリング、ネットワーキング、ロードバランシング、DNS、ブロックストレージなど、ワークロードのスムーズな運用を可能にするインフラストラクチャを管理します。 + +このラボ用に環境を準備します: + +```bash +$ prepare-environment fastpaths/getting-started +``` +::: + +EKS ワークショップの最初のハンズオンラボへようこそ。この演習の目標は、今後の多くのラボ演習で使用するサンプルアプリケーションに慣れ、そうすることで EKS へのワークロードのデプロイに関連するいくつかの基本的な概念に触れることです。アプリケーションのアーキテクチャを探索し、EKS クラスターにコンポーネントをデプロイします。 + +ラボ環境の EKS クラスターに最初のワークロードをデプロイして、探索してみましょう！ + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/index.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/index.md new file mode 100644 index 0000000000..c0cccecaf9 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/index.md @@ -0,0 +1,23 @@ +--- +title: "はじめに" +sidebar_position: 10 +tmdTranslationSourceHash: '2f75776010aa8dbf0f9a590034be7034' +--- + +# Amazon EKS Auto Mode で学ぶ + +迅速に Amazon EKS を実践できる、効率化されたロールベースの学習体験です。すべての EKS 機能を網羅する包括的なワークショップとは異なり、Auto Mode パスは開発者やオペレーターなどの特定のロールに最も重要な機能に焦点を当てています。 + +## あなたの学習パスを選択 + +![Fast Path オプション](/img/fastpaths/fast-path-options.png) + +以下の手順に従って開始してください: + +1. **[セットアップ](/docs/fastpaths/setup)** 環境を準備します — AWS イベントに参加している場合でも、自分のアカウントで実行している場合でも、セットアップガイドに従って IDE とクラスターを準備してください。 +2. [ラボのナビゲーション](/docs/fastpaths/navigating-labs) モジュールを使用して、ラボでの指示の進め方を学びます。 +3. あなたのロールと興味に基づいて、EKS 開発者または EKS オペレーターのパスを選択してさらに学習を進めてください。 + +Amazon EKS Auto Mode を活用したこれらのパスは、インフラストラクチャのセットアップと管理を最小限に抑え、EKS のコアコンセプトの学習とワークロードのデプロイに集中できるようにします。ワークショップ、イベント、またはすぐに実践的な体験を得たい場合のセルフペース学習に最適です。 + +それでは環境をセットアップしましょう！ 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 new file mode 100644 index 0000000000..77031ba93a --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/navigating-labs.md @@ -0,0 +1,103 @@ +--- +title: ラボのナビゲーション +sidebar_position: 30 +tmdTranslationSourceHash: '19c60d21bd5821a49af31787350fabab' +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +このウェブサイトと提供されるコンテンツの操作方法を確認しましょう。 + +## 構造 + +このワークショップのコンテンツは以下で構成されています: + +1. 個別のラボ演習 +2. ラボに関連する概念を説明するサポートコンテンツ + +ラボ演習は、どのモジュールも独立した演習として実行できるように設計されています。ラボ演習は左側のサイドバーに表示され、`LAB`アイコンで示されます。 + +## IDE を開く + +**AWS イベントに参加している場合**は、Workshop Studio のスタートページの下部にある *Event Outputs* セクションから IDE を開きます。 + +Event Outputs copy/paste + +**自分のアカウントで実行している場合**は、CloudFormation スタックの Outputs タブで `IdeUrl` を見つけてください。詳細は[セットアップガイド](/docs/fastpaths/setup/your-account)を参照してください。 + +## ラボの開始 + +:::caution +各ラボには「始める前に」セクションがあり、最初に実行する必要がある `prepare-environment` コマンドが含まれています。必ずそのページから開始してください。ラボの途中から始めると、予期しない動作が発生します。 +::: + +## ヒント + +### コピー/ペースト権限 +ブラウザによっては、Code Server ターミナルへのコンテンツのコピー/ペーストの方法が異なる場合があります。 + + + + ターミナルでコンテンツを最初にペーストしようとすると、次のようなブラウザのポップアップが表示されます: + + Chrome copy/paste + + **Allow** ボタンをクリックして、この機能を有効にします。これ以降、コピー/ペーストは簡単になります。このワークショップでは、可能であれば Google Chrome の使用をお勧めします。 + + + ターミナルでコンテンツをペーストしようとするたびに、マウスポインタの隣に次のスクリーンショットに示すような小さなボタンが表示されます。コピーしたコンテンツを実際にペーストするには、それをクリックする必要があります。 + + Firefox/Safari copy/paste + + さらに、エディタウィンドウの右下隅に次のポップアップボックスが表示される場合がありますが、これは閉じて無視してかまいません。 + + Firefox/Safari copy/paste + + + +### ターミナルコマンド + +このワークショップでのほとんどの操作は、手動で入力するか IDE ターミナルにコピー/ペーストするターミナルコマンドで行います。ターミナルコマンドは次のように表示されます: + +```bash test=false +$ echo "This is an example command" +``` + +`echo "This is an example command"` の上にマウスを置き、クリックしてそのコマンドをクリップボードにコピーします。 + +次のように、サンプル出力を含むコマンドも表示されます: + +```bash test=false +$ date +Fri Aug 30 12:25:58 MDT 2024 +``` + +「クリックしてコピー」機能を使用すると、コマンドのみがコピーされ、サンプル出力は無視されます。 + +コンテンツで使用されるもう1つのパターンは、1つのターミナルに複数のコマンドを表示することです: + +```bash test=false +$ echo "This is an example command" +This is an example command +$ date +Fri Aug 30 12:26:58 MDT 2024 +``` + +この場合、各コマンドを個別にコピーするか、ターミナルウィンドウの右上隅にあるクリップボードアイコンを使用してすべてのコマンドをコピーできます。試してみてください! + +### Kustomize の使用 + +[Kustomize](https://kustomize.io/) を使用すると、宣言的な「kustomization」ファイルを使用して Kubernetes マニフェストファイルを管理できます。これにより、Kubernetes リソースの「ベース」マニフェストを表現し、構成、カスタマイズ、多くのリソース全体で横断的な変更を簡単に行う機能が提供されます。 + +このワークショップでは、Kustomize に関連する次の2種類のコマンドが表示されます。 + +1. `kubectl kustomize some-deployment.yaml` - このコマンドは、Kustomize 設定を使用して yaml のカスタマイズされたバージョンを**生成**します。リソースはデプロイされません。 + +1. `kubectl apply -k some-deployment.yaml` - このコマンドは、Kustomize 設定を使用して yaml のカスタマイズされたバージョンを直接**適用**し、リソースをデプロイします。 + +Kustomize の詳細については、https://kustomize.io/ を参照してください。 + +## 次のステップ + +このワークショップの形式に慣れたら、[Getting Started](/docs/fastpaths/getting-started) に進んでください。 diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/amazon-eks-pod-identity/index.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/amazon-eks-pod-identity/index.md new file mode 100644 index 0000000000..9e3863c1e8 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/amazon-eks-pod-identity/index.md @@ -0,0 +1,19 @@ +--- +title: "ワークロードからAWS APIへの安全なアクセス" +sidebar_position: 60 +description: "EKS Pod Identityを使用して、Amazon Elastic Kubernetes Service上で実行されているアプリケーションのAWS認証情報を管理します。" +tmdTranslationSourceHash: '77cff549fe1a20bbfaf0bb39b74c9e8a' +--- + +:::tip セットアップ済みの内容 +Amazon EKS Auto Modeクラスターには以下が含まれています： + +- cartsサービス用のAmazon DynamoDBテーブル +- cartsワークロードがDynamoDBにアクセスするために設定されたIAMロール + +::: + +Pod内のコンテナのアプリケーションは、サポートされているAWS SDKまたはAWS CLIを使用して、AWS Identity and Access Management（IAM）権限を使ってAWSサービスへのAPIリクエストを行うことができます。たとえば、アプリケーションがS3バケットにファイルをアップロードしたり、DynamoDBテーブルをクエリしたりする必要がある場合、AWS APIリクエストにAWS認証情報で署名する必要があります。[EKS Pod Identities](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html)は、Amazon EC2インスタンスプロファイルがインスタンスに認証情報を提供する方法と同様に、アプリケーションの認証情報を管理する機能を提供します。AWS認証情報を作成してコンテナに配布したり、Amazon EC2インスタンスのロールを使用したりする代わりに、IAMロールをKubernetes Service Accountに関連付けて、Podがそれを使用するように設定できます。サポートされているSDKバージョンの正確なリストについては、EKSドキュメントを[こちら](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-minimum-sdk.html)で確認してください。 + +このモジュールでは、サンプルアプリケーションのコンポーネントの1つを再設定してAWS APIを活用し、適切な権限を提供します。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/amazon-eks-pod-identity/introduction.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/amazon-eks-pod-identity/introduction.md new file mode 100644 index 0000000000..7343bb9887 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/amazon-eks-pod-identity/introduction.md @@ -0,0 +1,27 @@ +--- +title: "はじめに" +sidebar_position: 31 +tmdTranslationSourceHash: '30a2bf69cd7c96a2fc73a4005d5069f1' +--- + +アーキテクチャの`carts`コンポーネントは、Amazon DynamoDBをストレージバックエンドとして使用しています。これは、Amazon EKSとの非リレーショナルデータベース統合でよく見られるユースケースです。現在、carts APIは、EKSクラスター内のコンテナとして実行されている[Amazon DynamoDBの軽量版](https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/DynamoDBLocal.html)でデプロイされています。 + +次のコマンドを実行すると、これを確認できます: + +```bash wait=30 +$ kubectl -n carts get pod +NAME READY STATUS RESTARTS AGE +carts-5d7fc9d8f-xm4hs 1/1 Running 0 14m +carts-dynamodb-698674dcc6-hw2bg 1/1 Running 0 14m +``` + +上記の出力では、Pod `carts-dynamodb-698674dcc6-hw2bg`が軽量DynamoDBサービスです。`carts`アプリケーションがこれを使用していることは、環境変数を確認することで検証できます: + +```bash timeout=180 +$ kubectl wait --for=condition=Ready pods -l app.kubernetes.io/component=service -n carts --timeout=120s +$ kubectl -n carts exec deployment/carts -- env | grep RETAIL_CART_PERSISTENCE_DYNAMODB_ENDPOINT +RETAIL_CART_PERSISTENCE_DYNAMODB_ENDPOINT=http://carts-dynamodb:8000 +``` + +このアプローチはテストには便利ですが、フルマネージドなAmazon DynamoDBサービスを使用するようにアプリケーションを移行し、スケールと信頼性の利点を最大限に活用したいと考えています。以下のセクションでは、Amazon DynamoDBを使用するようにアプリケーションを再構成し、EKS Pod IdentityでAWSサービスへの安全なアクセスを実装します。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/amazon-eks-pod-identity/understanding.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/amazon-eks-pod-identity/understanding.md new file mode 100644 index 0000000000..a73e497684 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/amazon-eks-pod-identity/understanding.md @@ -0,0 +1,20 @@ +--- +title: "Pod IAM の理解" +sidebar_position: 33 +tmdTranslationSourceHash: '34ff18988cc9f932ada0b0e51dc7e163' +--- + +問題の最初の調査先は `carts` サービスのログです： + +```bash hook=pod-logs timeout=480 +$ LATEST_POD=$(kubectl get pods -n carts -l app.kubernetes.io/component=service --sort-by=.metadata.creationTimestamp -o jsonpath='{.items[-1:].metadata.name}') +sleep 60 +kubectl logs -n carts -p $LATEST_POD +[...] +software.amazon.awssdk.core.exception.SdkClientException: Unable to load credentials from any of the providers in the chain AwsCredentialsProviderChain(credentialsProviders=[SystemPropertyCredentialsProvider(), EnvironmentVariableCredentialsProvider(), WebIdentityTokenCredentialsProvider(), ProfileCredentialsProvider(profileName=default, profileFile=ProfileFile(sections=[])), ContainerCredentialsProvider(), InstanceProfileCredentialsProvider()]) : [SystemPropertyCredentialsProvider(): Unable to load credentials from system settings. Access key must be specified either via environment variable (AWS_ACCESS_KEY_ID) or system property (aws.accessKeyId)., EnvironmentVariableCredentialsProvider(): Unable to load credentials from system settings. Access key must be specified either via environment variable (AWS_ACCESS_KEY_ID) or system property (aws.accessKeyId)., WebIdentityTokenCredentialsProvider(): Either the environment variable AWS_WEB_IDENTITY_TOKEN_FILE or the javaproperty aws.webIdentityTokenFile must be set., ProfileCredentialsProvider(profileName=default, profileFile=ProfileFile(sections=[])): Profile file contained no credentials for profile 'default': ProfileFile(sections=[]), ContainerCredentialsProvider(): Cannot fetch credentials from container - neither AWS_CONTAINER_CREDENTIALS_FULL_URI or AWS_CONTAINER_CREDENTIALS_RELATIVE_URI environment variables are set., InstanceProfileCredentialsProvider(): Failed to load credentials from IMDS.] +``` + +アプリケーションがエラーを生成しており、Pod が DynamoDB にアクセスするための AWS 認証情報を読み込めないことを示しています。これは、EKS Pod Identity を介して IAM ロールやポリシーが Pod にリンクされていない場合、デフォルトでアプリケーションが AWS API 呼び出しを行うための認証情報を取得できないために発生しています。 + +1つのアプローチは、ノード IAM ロールの IAM 権限を拡張することですが、これではそれらのインスタンスで実行されている任意の Pod が DynamoDB テーブルにアクセスできるようになってしまいます。これは最小権限の原則に違反し、セキュリティのベストプラクティスではありません。代わりに、EKS Pod Identity を使用して、`carts` アプリケーションが必要とする特定の権限を Pod レベルで提供し、きめ細かいアクセス制御を確保します。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/amazon-eks-pod-identity/use-pod-identity.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/amazon-eks-pod-identity/use-pod-identity.md new file mode 100644 index 0000000000..8bb4b49b7b --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/amazon-eks-pod-identity/use-pod-identity.md @@ -0,0 +1,103 @@ +--- +title: "EKS Pod Identity の使用" +sidebar_position: 34 +hide_table_of_contents: true +tmdTranslationSourceHash: '2b0a7dd5bfdf5b8f031c0ed19f8e3f74' +--- + +Amazon EKS Auto Mode では、EKS Pod Identity Agent がすでに含まれており、AWS によってコントロールプレーンで管理されています。既存の Pod Identity アソシエーションを確認することで、Pod Identity が利用可能であることを確認できます。 + +```bash +$ aws eks list-pod-identity-associations --cluster-name $EKS_CLUSTER_AUTO_NAME --namespace carts +{ + "associations": [] +} +``` + +`carts` サービスが DynamoDB テーブルに読み書きするために必要な権限を提供する IAM role が、Auto Mode クラスターのセットアップ時に作成されています。以下のようにポリシーを表示できます。 + +```bash +$ aws iam get-policy-version \ + --version-id v1 --policy-arn \ + --query 'PolicyVersion.Document' \ + arn:aws:iam::${AWS_ACCOUNT_ID}:policy/${EKS_CLUSTER_AUTO_NAME}-carts-dynamo | jq . +{ + "Statement": [ + { + "Action": "dynamodb:*", + "Effect": "Allow", + "Resource": [ + "arn:aws:dynamodb:us-west-2:267912352941:table/eks-workshop-auto-carts", + "arn:aws:dynamodb:us-west-2:267912352941:table/eks-workshop-auto-carts/index/*" + ], + "Sid": "AllAPIActionsOnCart" + } + ], + "Version": "2012-10-17" +} +``` + +この role には、EKS サービスプリンシパルが Pod Identity のためにこの role を引き受けることを許可する、適切な信頼関係も設定されています。以下のコマンドで表示できます。 + +```bash +$ aws iam get-role \ + --query 'Role.AssumeRolePolicyDocument' \ + --role-name ${EKS_CLUSTER_AUTO_NAME}-carts-dynamo | jq . +{ + "Version": "2012-10-17", + "Statement": [ + { + "Effect": "Allow", + "Principal": { + "Service": "pods.eks.amazonaws.com" + }, + "Action": [ + "sts:AssumeRole", + "sts:TagSession" + ] + } + ] +} +``` + +次に、Amazon EKS Pod Identity 機能を使用して、デプロイメントで使用される Kubernetes Service Account に AWS IAM role を関連付けます。アソシエーションを作成するには、以下のコマンドを実行します。 + +```bash wait=30 +$ aws eks create-pod-identity-association --cluster-name ${EKS_CLUSTER_AUTO_NAME} \ + --role-arn arn:aws:iam::${AWS_ACCOUNT_ID}:role/${EKS_CLUSTER_AUTO_NAME}-carts-dynamo \ + --namespace carts --service-account carts | jq . +{ + "association": { + "clusterName": "eks-workshop-auto", + "namespace": "carts", + "serviceAccount": "carts", + "roleArn": "arn:aws:iam::267912352941:role/eks-workshop-auto-carts-dynamo", + "associationArn": "arn:aws:eks:us-west-2:267912352941:podidentityassociation/eks-workshop-auto/a-yg5uoymvtfgdg5tcj", + "associationId": "a-yg5uoymvtfgdg5tcj", + "tags": {}, + "createdAt": "2025-10-11T01:13:27.763000+00:00", + "modifiedAt": "2025-10-11T01:13:27.763000+00:00", + "disableSessionTags": false + } +} +``` + +残りの作業は、`carts` Deployment が `carts` Service Account を使用していることを確認することです。 + +```bash +$ kubectl -n carts describe deployment carts | grep 'Service Account' + Service Account: carts +``` + +Service Account が確認できたので、`carts` Pod をリサイクルしましょう。 + +```bash hook=enable-pod-identity hookTimeout=430 timeout=360 +$ kubectl -n carts rollout restart deployment/carts +deployment.apps/carts restarted +$ kubectl -n carts rollout status deployment/carts --timeout=300s +Waiting for deployment "carts" rollout to finish: 1 old replicas are pending termination... +deployment "carts" successfully rolled out +``` + +それでは、次のセクションで、carts アプリケーションで発生していた DynamoDB の権限の問題が解決されたかどうかを確認しましょう。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/amazon-eks-pod-identity/using-dynamo.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/amazon-eks-pod-identity/using-dynamo.md new file mode 100644 index 0000000000..63fbe937c5 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/amazon-eks-pod-identity/using-dynamo.md @@ -0,0 +1,79 @@ +--- +title: "Amazon DynamoDB の使用" +sidebar_position: 32 +tmdTranslationSourceHash: '8a2dad5af76103e706512f44167f1dda' +--- + +このプロセスの最初のステップは、既に作成されている DynamoDB テーブルを使用するように carts サービスを再設定することです。アプリケーションはほとんどの設定を ConfigMap から読み込みます。それを見てみましょう： + +```bash +$ kubectl -n carts get -o yaml cm carts | yq +apiVersion: v1 +data: + AWS_ACCESS_KEY_ID: key + AWS_SECRET_ACCESS_KEY: secret + RETAIL_CART_PERSISTENCE_DYNAMODB_CREATE_TABLE: "true" + RETAIL_CART_PERSISTENCE_DYNAMODB_ENDPOINT: http://carts-dynamodb:8000 + RETAIL_CART_PERSISTENCE_DYNAMODB_TABLE_NAME: Items + RETAIL_CART_PERSISTENCE_PROVIDER: dynamodb +kind: ConfigMap +metadata: + name: carts + namespace: carts +``` + +次の kustomization は ConfigMap を上書きして、DynamoDB エンドポイントの設定を削除します。これにより、SDK はテスト用の Pod の代わりに実際の DynamoDB サービスを使用するように指示されます。また、既に作成されている DynamoDB テーブル名も設定しました。テーブル名は環境変数 `RETAIL_CART_PERSISTENCE_DYNAMODB_TABLE_NAME` から取得されています。 + +```kustomization +modules/security/eks-pod-identity/dynamo/kustomization.yaml +ConfigMap/carts +``` + +DynamoDB テーブル名を設定し、Kustomize を実行して実際の DynamoDB サービスを使用しましょう： + +```bash +$ export CARTS_DYNAMODB_TABLENAME=${EKS_CLUSTER_AUTO_NAME}-carts && echo $CARTS_DYNAMODB_TABLENAME +eks-workshop-auto-carts +$ kubectl kustomize ~/environment/eks-workshop/modules/security/eks-pod-identity/dynamo \ + | envsubst | kubectl apply -f- +``` + +これにより、ConfigMap が新しい値で上書きされます： + +```bash +$ kubectl -n carts get cm carts -o yaml | yq +apiVersion: v1 +data: + AWS_REGION: us-west-2 + RETAIL_CART_PERSISTENCE_DYNAMODB_TABLE_NAME: eks-workshop-auto-carts + RETAIL_CART_PERSISTENCE_PROVIDER: dynamodb +kind: ConfigMap +metadata: + labels: + app: carts + name: carts + namespace: carts +``` + +次に、新しい ConfigMap の内容を取得するために、すべての carts Pod を再起動する必要があります： + +```bash expectError=true hook=enable-dynamo +$ kubectl rollout restart -n carts deployment/carts +deployment.apps/carts restarted +$ kubectl rollout status -n carts deployment/carts --timeout=20s +Waiting for deployment "carts" rollout to finish: 1 old replicas are pending termination... +error: timed out waiting for the condition +``` + +変更が適切にデプロイされなかったようです。Pod を確認することでこれを確認できます： + +```bash +$ kubectl -n carts get pod +NAME READY STATUS RESTARTS AGE +carts-5d486d7cf7-8qxf9 1/1 Running 0 5m49s +carts-df76875ff-7jkhr 0/1 CrashLoopBackOff 3 (36s ago) 2m2s +carts-dynamodb-698674dcc6-hw2bg 1/1 Running 0 20m +``` + +何が問題だったのでしょうか？ + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/amazon-eks-pod-identity/verifying-dynamo.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/amazon-eks-pod-identity/verifying-dynamo.md new file mode 100644 index 0000000000..5829fce191 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/amazon-eks-pod-identity/verifying-dynamo.md @@ -0,0 +1,38 @@ +--- +title: "DynamoDB アクセスの検証" +sidebar_position: 35 +pagination_next: fastpaths/explore/index +tmdTranslationSourceHash: '71af52af1703fd93ecb5a1774ce76077' +--- + +これで、`carts` Service Account が認可された IAM ロールに関連付けられたため、`carts` Pod は DynamoDB テーブルへのアクセス許可を持つようになりました。もう一度ウェブストアにアクセスして、ショッピングカートに移動してください。 + +```bash +$ LB_HOSTNAME=$(kubectl get svc ui-nlb-auto -n ui -o yaml | yq .status.loadBalancer.ingress[0].hostname) +$ echo "http://$LB_HOSTNAME" +http://k8s-ui-uinlbaut-a9797f0f61.elb.us-west-2.amazonaws.com +``` + +`carts` Pod は DynamoDB サービスに到達でき、ショッピングカートにアクセスできるようになりました！ + +![Cart](/img/sample-app-screens/shopping-cart.webp) + +AWS IAM ロールが Service Account に関連付けられると、その Service Account を使用して新しく作成される Pod は、[EKS Pod Identity webhook](https://github.com/aws/amazon-eks-pod-identity-webhook) によって傍受されます。この webhook は Amazon EKS クラスターのコントロールプレーンで実行され、AWS によって完全に管理されています。新しい `carts` Pod を詳しく見て、新しい環境変数を確認してください。 + +```bash +$ kubectl -n carts exec deployment/carts -- env | grep AWS +AWS_STS_REGIONAL_ENDPOINTS=regional +AWS_DEFAULT_REGION=us-west-2 +AWS_REGION=us-west-2 +AWS_CONTAINER_CREDENTIALS_FULL_URI=http://169.254.170.23/v1/credentials +AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE=/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token +``` + +これらの環境変数について注目すべき点： + +- `AWS_DEFAULT_REGION` - リージョンは自動的に EKS クラスターと同じに設定されます +- `AWS_STS_REGIONAL_ENDPOINTS` - リージョナル STS エンドポイントが設定され、`us-east-1` のグローバルエンドポイントへの負荷を避けます +- `AWS_CONTAINER_CREDENTIALS_FULL_URI` - この変数は、[HTTP 認証情報プロバイダー](https://docs.aws.amazon.com/sdkref/latest/guide/feature-container-credentials.html)を使用して認証情報を取得する方法を AWS SDK に指示します。つまり、EKS Pod Identity は `AWS_ACCESS_KEY_ID`/`AWS_SECRET_ACCESS_KEY` ペアのような形式で認証情報を挿入する必要がなく、代わりに SDK は EKS Pod Identity メカニズムを介して一時的な認証情報を取得できます。この機能の詳細については、[AWS ドキュメント](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html)をご覧ください。 + +アプリケーションで Pod Identity を正常に設定しました。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/index.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/index.md new file mode 100644 index 0000000000..82abda45d2 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/index.md @@ -0,0 +1,31 @@ +--- +title: "Operator Essentials" +sidebar_position: 60 +sidebar_custom_props: { "module": true } +tmdTranslationSourceHash: '9b2d0b60ba5cabc544ba2dab1c87470d' +--- + +# Operator Essentials + +::required-time + +:::tip 始める前に +このファストパスでは、専用の Amazon EKS Auto Mode クラスターを使用します。Amazon EKS Auto Mode は、クラスター自体を超えて Kubernetes クラスターの AWS 管理を拡張し、コンピュートのオートスケーリング、ネットワーキング、ロードバランシング、DNS、ブロックストレージなど、ワークロードのスムーズな運用を可能にするインフラストラクチャを管理します。 + +このラボ用の環境を準備します： + +```bash timeout=600 +$ prepare-environment fastpaths/operator +``` +::: + +EKS Workshop Operator Essentials へようこそ！これは、EKS クラスターを運用する際に最も一般的に必要とされる Amazon EKS の機能をオペレーターが学習するために最適化された一連のラボです。 + +この一連の演習を通じて、以下を学習します： + +- Karpenter によるクラスターオートスケーリングの設定 +- Pod 間トラフィックを保護するためのネットワークポリシーの実装 +- EKS におけるシークレットの操作 +- EKS Pod Identity を使用した DynamoDB などの AWS サービスの利用 + +さあ、始めましょう！ diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/karpenter/consolidation.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/karpenter/consolidation.md new file mode 100644 index 0000000000..5dd23970e6 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/karpenter/consolidation.md @@ -0,0 +1,119 @@ +--- +title: "ディスラプション (統合)" +sidebar_position: 50 +tmdTranslationSourceHash: '917a7d9fa2b5eba8c737d35dfecde14b' +--- + +Karpenter は、ディスラプションの対象となるノードを自動的に検出し、必要に応じて代替ノードを起動します。これは3つの異なる理由で発生する可能性があります: + +- **有効期限**: デフォルトでは、Karpenter は 720時間（30日）後にインスタンスを自動的に期限切れにし、再利用を強制してノードを最新の状態に保ちます。 +- **ドリフト**: Karpenter は設定の変更（`NodePool` や `NodeClass` など）を検出し、必要な変更を適用します +- **統合**: コストを効率的に運用するための重要な機能として、Karpenter はクラスターのコンピュートを継続的に最適化します。例えば、ワークロードが使用率の低いコンピュートインスタンスで実行されている場合、より少ないインスタンスに統合します。 + +ディスラプションは、`NodePool` の `disruption` ブロックを通じて設定されます。以下は、Auto Mode が設定した `general-purpose` NodePool 設定ポリシーの一部です。 + +```json + disruption: + budgets: + - nodes: 10% + consolidateAfter: 30s + consolidationPolicy: WhenEmptyOrUnderutilized +``` + +1. `budget` はカスタム値に設定されており、ワークロードへの悪影響を最小限に抑えるため、同時にディスラプションされるノードの割合を指定します。 +2. `consolidateAfter` は統合プロセスを開始する前の待機時間を指定します。 +3. `WhenEmptyOrUnderutilized` ポリシーにより、Karpenter はノードが空または使用率が低い場合にノードを置き換えることができます。 + +次のコマンドを使用して NodePool 設定を確認し、ディスラプション設定を確認できます。 + +```bash +$ kubectl get nodepools general-purpose -o yaml | yq .spec.disruption +``` + +`consolidationPolicy` の値 `WhenEmptyOrUnderutilized` は、`consolidateAfter`（ここでは30秒）後にパッキングを最適化するためにノードを統合し、一度に10%のノードの置き換えを許可する予算を持ちます。他の値も可能で、例えば `consolidationPolicy` は `WhenEmpty` に設定することもでき、これはワークロード Pod を含まないノードのみにディスラプションを制限します。ディスラプションの詳細については、[Karpenter ドキュメント](https://karpenter.sh/docs/concepts/disruption/#consolidation)をご覧ください。 + +インフラストラクチャのスケールアウトは、コスト効率的にコンピュートインフラストラクチャを運用するための方程式の片面に過ぎません。例えば、使用率の低いコンピュートインスタンスで実行されているワークロードをより少ないインスタンスにコンパクトにするなど、継続的に最適化できる必要もあります。これにより、コンピュート上でワークロードを実行する全体的な効率が向上し、オーバーヘッドが減少し、コストが削減されます。 + +`disruption` が `consolidationPolicy: WhenEmptyOrUnderutilized` に設定されている場合の自動統合のトリガー方法を見ていきましょう: + +1. `inflate` ワークロードを5から12レプリカにスケールし、Karpenter に追加容量をプロビジョニングさせる +2. ワークロードを5レプリカに戻してスケールダウンする +3. Karpenter がコンピュートを統合するのを観察する + +`inflate` ワークロードを再度スケールして、より多くのリソースを消費させます: + +```bash timeout=240 +$ kubectl scale -n other deployment/inflate --replicas 12 +$ kubectl rollout status -n other deployment/inflate --timeout=180s +``` + +これにより、このデプロイメントの合計メモリ要求が約12Giに変更されます。各ノードの kubelet 用に予約されている約600Miを考慮すると、これは `m5.large` タイプの2つのインスタンスに収まります: + +```bash +$ kubectl get nodes -L beta.kubernetes.io/instance-type -L kubernetes.io/arch -L kubernetes.io/os --sort-by=.metadata.creationTimestamp +NAME STATUS ROLES AGE VERSION INSTANCE-TYPE ARCH OS +i-07fd006840ed07309 Ready 20h v1.33.4-eks-e386d34 c6a.large amd64 linux +i-0e209b70f1d2dfae0 Ready 17h v1.33.4-eks-e386d34 c6a.large amd64 linux +i-0a78dba9f62f5e0e4 Ready 90m v1.33.4-eks-e386d34 m5a.large amd64 linux +i-076a7c45e5f8e5f11 Ready 7m12s v1.33.4-eks-e386d34 m5a.large amd64 linux +``` + +次に、レプリカ数を5に戻してスケールダウンします: + +```bash wait=90 +$ kubectl scale -n other deployment/inflate --replicas 5 +``` + +Karpenter イベントを確認して、デプロイメントのスケールに応じて Karpenter がどのようなアクションを取ったかを把握できます。次のコマンドを実行する前に約5〜10秒待ちます: + +```bash hook=grep +$ kubectl events | grep -i 'disruption' + +3m39s Normal DisruptionBlocked nodeclaim/general-purpose-5c74h Node is nominated for a pending pod +3m42s Normal DisruptionLaunching nodeclaim/general-purpose-l6dpl Launching NodeClaim: Underutilized +3m42s Normal DisruptionWaitingReadiness nodeclaim/general-purpose-l6dpl Waiting on readiness to continue disruption +3m39s Normal DisruptionBlocked nodeclaim/general-purpose-l6dpl Nodeclaim does not have an associated node +18m Normal DisruptionBlocked nodeclaim/general-purpose-m6gjm Nodeclaim does not have an associated node +4m38s Normal DisruptionBlocked nodeclaim/general-purpose-m6gjm Node is nominated for a pending pod +3m20s Normal DisruptionTerminating nodeclaim/general-purpose-m6gjm Disrupting NodeClaim: Underutilized +2m29s Normal DisruptionBlocked nodeclaim/general-purpose-m6gjm Node is deleting or marked for deletion +4m38s Normal DisruptionTerminating nodeclaim/general-purpose-nhtc7 Disrupting NodeClaim: Underutilized +4m28s Normal DisruptionBlocked nodeclaim/general-purpose-nhtc7 Node is deleting or marked for deletion +4m38s Normal DisruptionBlocked node/i-076a7c45e5f8e5f11 Node is nominated for a pending pod +3m20s Normal DisruptionTerminating node/i-076a7c45e5f8e5f11 Disrupting Node: Underutilized +2m29s Normal DisruptionBlocked node/i-076a7c45e5f8e5f11 Node is deleting or marked for deletion +3m39s Normal DisruptionBlocked node/i-0a78dba9f62f5e0e4 Node is nominated for a pending pod +3m19s Normal DisruptionBlocked node/i-0e1f072dc32194cc7 Node is nominated for a pending pod +4m38s Normal DisruptionTerminating node/i-0e209b70f1d2dfae0 Disrupting Node: Underutilized +4m28s Normal DisruptionBlocked node/i-0e209b70f1d2dfae0 Node is deleting or marked for deletion +``` + +出力には、Karpenter が特定のノードを識別して cordon、drain、そして終了させる様子が表示されます: + +これにより、Kubernetes スケジューラーはそれらのノード上の Pod を残りの容量に配置し、クラスター内のノード数が減少したことが確認できます。 + +```bash +$ kubectl get nodes -L beta.kubernetes.io/instance-type -L kubernetes.io/arch -L kubernetes.io/os --sort-by=.metadata.creationTimestamp + +NAME STATUS ROLES AGE VERSION INSTANCE-TYPE ARCH OS +i-07fd006840ed07309 Ready 21h v1.33.4-eks-e386d34 c6a.large amd64 linux +i-0a78dba9f62f5e0e4 Ready 104m v1.33.4-eks-e386d34 m5a.large amd64 linux +i-0e1f072dc32194cc7 Ready 6m4s v1.33.4-eks-e386d34 c6a.large amd64 linux +``` + +Karpenter は、ワークロードの変更に応じてノードをより安価なバリアントに置き換えられる場合、さらに統合することもできます。これは、`inflate` デプロイメントのレプリカを1にスケールダウンすることで実証できます。合計メモリ要求は約1Giになります: + +```bash wait=60 +$ kubectl scale -n other deployment/inflate --replicas 1 +``` + +Karpenter ログを確認して、コントローラーがどのようなアクションを取ったかを確認できます: + +```bash test=false +$ kubectl events | grep -i 'disruption' +``` + +出力には、Karpenter が使用率の低いノードを削除して NodePool 内のワークロードを統合する様子が表示されます。 + +これで EKS Auto Mode のオートスケーリング機能の紹介は終わりです。Auto Mode が提供するデフォルトの NodePool と NodeClass 設定を使用しましたが、特定のニーズに合わせてクラスター内にカスタムの NodePool と NodeClass リソースを設定することもできます。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/karpenter/index.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/karpenter/index.md new file mode 100644 index 0000000000..b0f69d0880 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/karpenter/index.md @@ -0,0 +1,29 @@ +--- +title: "EKS Auto Mode によるオートスケーリング" +sidebar_position: 20 +description: "EKS Auto Mode で Amazon Elastic Kubernetes Service の自動的なコンピュート管理を実現します。" +tmdTranslationSourceHash: "1f33ea5e2868f81be011bb2e7762c98b" +--- + +:::tip セットアップ済みの内容 +Amazon EKS Auto Mode クラスターには、**Karpenter** によって提供される完全マネージド型オートスケーリング機能が含まれており、すぐに使えるコンピュートスケーリングが有効になっています。 +::: + +このラボでは、EKS Auto Mode がクラスターに自動コンピュートスケーリングを提供する仕組みを探ります。Auto Mode には、運用負荷を最小限に抑える包括的なマネージド機能スイートの一部として、完全マネージド型の [Karpenter](https://github.com/aws/karpenter) 機能が含まれています。オートスケーリング機能は、スケジュール不可能な Pod の集約リソース要求を観察し、スケジューリングレイテンシを最小限に抑えるためにノードを起動および終了する決定を行うことで、アプリケーションのニーズに合わせた適切なコンピュートリソースを数分ではなく数秒で提供するように設計されています。 + + + +EKS Auto Mode のオートスケーリングは以下のように機能します： + +- Kubernetes スケジューラーがスケジュール不可能とマークした Pod を監視 +- Pod が要求するスケジューリング制約（リソース要求、ノードセレクタ、アフィニティ、Toleration、Pod Topology Spread Constraints）を評価 +- Pod の要件を満たすノードをプロビジョニング +- 新しいノードで実行するように Pod をスケジューリング +- ノードが不要になったときにノードを削除 + +:::info +EKS Auto Mode では、Karpenter は AWS によって完全に管理され、クラスター外で実行されます。セルフマネージド Karpenter とは異なり、Karpenter Pod をデプロイ、スケール、またはアップグレードする必要はありません。すべての運用面は AWS によって処理され、NodePool と NodeClass の設定に対する制御は保持されます。 +::: + +Auto Mode が完全マネージド型オートスケーリングを提供するため、ワークロードのためにノードがプロビジョニングされる方法を制御する NodePool の設定に直接移ることができます。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/karpenter/node-provisioning.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/karpenter/node-provisioning.md new file mode 100644 index 0000000000..2760072d86 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/karpenter/node-provisioning.md @@ -0,0 +1,117 @@ +--- +title: "自動ノードプロビジョニング" +sidebar_position: 40 +tmdTranslationSourceHash: 'f72bb599bbdb8974b106cac05c633d86' +--- + +まず、スケジュールできない Pod のニーズに応じて、Karpenter が適切なサイズの EC2 インスタンスを動的にプロビジョニングする方法を確認します。これにより、EKS クラスター内の未使用のコンピュートリソースを削減できます。 + +前のセクションで確認した NodePool は、Karpenter が使用できる特定のインスタンスファミリーを指定していました。それらは以下の通りです。 + +| インスタンスファミリー | 世代 | OS | アーキテクチャ | +| ----------------- | ---------- | ------ | ------------ | +| `c`, `m`, `r` | >4 | Linux | amd64 | + +この広範な設定により、Karpenter は要件に基づいて適切なサイズのインスタンスを選択するための幅広い選択肢を持つことができます。 + +いくつかの Pod を作成して、Auto Mode の Karpenter ベースのオートスケーリングがどのように適応するか見てみましょう。現在、Karpenter によって管理されているノードが 2 つあるはずです: + +```bash +$ kubectl get node -l karpenter.sh/nodepool=general-purpose + +NAME STATUS ROLES AGE VERSION +i-07fd006840ed07309 Ready 17h v1.33.4-eks-e386d34 +i-0e209b70f1d2dfae0 Ready 14h v1.33.4-eks-e386d34 +``` + +Karpenter にスケールアウトをトリガーさせるために、以下の Deployment を使用します: + +::yaml{file="manifests/modules/autoscaling/compute/karpenter/automode/scale/deployment.yaml" paths="spec.replicas,spec.template.spec.containers.0.image,spec.template.spec.containers.0.resources"} + +1. 初期状態では 0 レプリカを実行するように指定されており、後でスケールアップします +3. シンプルな `pause` コンテナイメージを使用します +4. 各 Pod に `1Gi` のメモリをリクエストします + +:::info pause コンテナとは？ +この例では、以下のイメージを使用していることに気付くでしょう: + +`public.ecr.aws/eks-distro/kubernetes/pause` + +これは実際のリソースを消費せず、すぐに起動する小さなコンテナで、スケーリングシナリオのデモンストレーションに最適です。この特定のラボの多くの例でこれを使用します。 +::: + +この Deployment を適用します: + +```bash +$ kubectl apply -k ~/environment/eks-workshop/modules/autoscaling/compute/karpenter/automode/scale +deployment.apps/inflate created +``` + +それでは、Karpenter が最適化された決定を行っていることを実証するために、意図的にこの Deployment をスケールしてみましょう。1Gi のメモリをリクエストしているので、Deployment を 5 レプリカにスケールすると、合計 5Gi のメモリがリクエストされることになります。 + +進める前に、上記の表から Karpenter がどのインスタンスをプロビジョニングすると思いますか？どのインスタンスタイプをプロビジョニングしてほしいですか？ + +Deployment をスケールします: + +```bash +$ kubectl scale -n other deployment/inflate --replicas 5 +``` + +この操作は 1 つ以上の新しい EC2 インスタンスを作成するため、時間がかかります。`kubectl` を使用して完了するまで待つことができます: + +```bash timeout=200 +$ kubectl rollout status -n other deployment/inflate --timeout=180s +``` + +それでは、Karpenter が実行したアクションをイベントをリストして確認しましょう。イベントがリストされるまで 5-10 秒待ちます。 + +```bash wait=10 +$ kubectl events | grep -i 'NodeClaim' +``` + +新しいノードが起動されていることを示す出力が表示されるはずです。 + +``` +2m55s Normal Launched nodeclaim/general-purpose-5c74h Status condition transitioned, Type: Launched, Status: Unknown -> True, Reason: Launched +2m52s Normal DisruptionBlocked nodeclaim/general-purpose-5c74h Nodeclaim does not have an associated node +2m39s Normal Registered nodeclaim/general-purpose-5c74h Status condition transitioned, Type: Registered, Status: Unknown -> True, Reason: Registered +2m36s Normal Initialized nodeclaim/general-purpose-5c74h Status condition transitioned, Type: Initialized, Status: Unknown -> True, Reason: Initialized +2m36s Normal Ready nodeclaim/general-purpose-5c74h Status condition transitioned, Type: Ready, Status: Unknown -> True, Reason: Ready +12m Normal Unconsolidatable nodeclaim/general-purpose-nhtc7 Can't replace with a cheaper node +``` + +Karpenter は、スケジュールされる予定のすべての Pod を収容できる十分な大きさで、同時にコストが低い最も適切なインスタンスタイプを見つけます。 + +:::info +最も安いインスタンスタイプ以外が選択される場合もあります。例えば、作業しているリージョンでその最も安いインスタンスタイプに残りの容量がない場合などです。 +::: + +クラスター内の利用可能なノードを再度リストしてみましょう。 + +```bash +$ kubectl get nodes \ + -L beta.kubernetes.io/instance-type \ + -L kubernetes.io/arch \ + -L kubernetes.io/os \ + --sort-by=.metadata.creationTimestamp + +NAME STATUS ROLES AGE VERSION INSTANCE-TYPE ARCH OS +i-07fd006840ed07309 Ready 20h v1.33.4-eks-e386d34 c6a.large amd64 linux +i-0e209b70f1d2dfae0 Ready 17h v1.33.4-eks-e386d34 c6a.large amd64 linux +i-0a78dba9f62f5e0e4 Ready 60m v1.33.4-eks-e386d34 m5a.large amd64 linux +``` + +プールに追加された最後のノードが、このページの前半で示した `NodePool` 設定テーブルに従っていることがわかります。 + +Karpenter は NodeClaim と呼ばれる Kubernetes ネイティブオブジェクトを通じてノードを追跡します。これはオブジェクトなので、設定も確認できます: + +```bash +$ kubectl get nodeclaims.karpenter.sh -o wide +NAME TYPE CAPACITY ZONE NODE READY AGE IMAGEID ID NODEPOOL NODECLASS DRIFTED +general-purpose-dh59z m5a.large on-demand us-west-2b i-0d3ed392f96f22793 True 5m58s ami-00e71b7a43dd16dec aws:///us-west-2b/i-0d3ed392f96f22793 general-purpose default +general-purpose-mw4sf c6a.large on-demand us-west-2a i-0078b61779fc13053 True 30h ami-00e71b7a43dd16dec aws:///us-west-2a/i-0078b61779fc13053 general-purpose default +general-purpose-wp7wg c6a.large on-demand us-west-2c i-0c1ceaeeb6ed1bfb6 True 8m5s ami-00e71b7a43dd16dec aws:///us-west-2c/i-0c1ceaeeb6ed1bfb6 general-purpose default +``` + +この簡単な例は、EKS Auto Mode の Karpenter ベースのオートスケーリングが、コンピュート容量を必要とするワークロードのリソース要件に基づいて、適切なインスタンスタイプを動的に選択できることを示しています。これは、Cluster Autoscaler のようなノードプールを中心としたモデルとは根本的に異なります。ノードプールでは、単一のノードグループ内のインスタンスタイプは一貫した CPU とメモリの特性を持つ必要があります。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/karpenter/setup-provisioner.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/karpenter/setup-provisioner.md new file mode 100644 index 0000000000..b55e3e89b4 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/karpenter/setup-provisioner.md @@ -0,0 +1,115 @@ +--- +title: "Karpenter 設定の確認" +sidebar_position: 30 +tmdTranslationSourceHash: 71e7d00dc015ad2a1c4b15a4580cf76d +--- + +EKS Auto Mode は、すぐに使える機能として完全マネージド型の Karpenter を提供します。Karpenter の設定は `NodePool` CRD (Custom Resource Definition) の形式で提供されます。単一の Karpenter `NodePool` は、さまざまな Pod 形状を処理できます。Karpenter は、ラベルやアフィニティなどの Pod 属性に基づいてスケジューリングとプロビジョニングの決定を行います。クラスターには複数の `NodePool` を持つことができますが、当面は Auto Mode がデフォルトで設定する NodePool を使用します。 + +Karpenter の主な目的の 1 つは、容量管理を簡素化することです。他の自動スケーリングソリューションに精通している場合、Karpenter が **グループレス自動スケーリング** と呼ばれる異なるアプローチを採用していることに気づいたかもしれません。他のソリューションでは、従来 **ノードグループ** という概念を制御要素として使用し、提供される容量の特性（つまり：オンデマンド、EC2 Spot、GPU ノードなど）を定義し、クラスター内のグループの望ましいスケールを制御していました。AWS では、ノードグループの実装は [Auto Scaling グループ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroup.html) と一致します。Karpenter を使用すると、異なるコンピューティングニーズを持つ複数のタイプのアプリケーションを管理する際に生じる複雑さを回避できます。 + +まず、Karpenter が使用する既存のリソースを確認することから始めましょう。まず、一般的な容量要件を定義するデフォルトの `NodePool` を確認します： + +```bash +$ kubectl get nodepools general-purpose -o yaml + +apiVersion: karpenter.sh/v1 +kind: NodePool +metadata: + annotations: + karpenter.sh/nodepool-hash: "4012513481623584108" + karpenter.sh/nodepool-hash-version: v3 + generation: 1 + labels: + app.kubernetes.io/managed-by: eks + name: general-purpose + resourceVersion: "57384" +spec: + disruption: + budgets: + - nodes: 10% + consolidateAfter: 30s + consolidationPolicy: WhenEmptyOrUnderutilized + template: + metadata: {} + spec: + expireAfter: 336h + nodeClassRef: + group: eks.amazonaws.com + kind: NodeClass + name: default + requirements: + - key: karpenter.sh/capacity-type + operator: In + values: + - on-demand + - key: eks.amazonaws.com/instance-category + operator: In + values: + - c + - m + - r + - key: eks.amazonaws.com/instance-generation + operator: Gt + values: + - "4" + - key: kubernetes.io/arch + operator: In + values: + - amd64 + - key: kubernetes.io/os + operator: In + values: + - linux + terminationGracePeriod: 24h0m0s +``` + +このデフォルトの `NodePool` リソースに加えて、ワークロードに対する異なる分離要件やインフラストラクチャ要件を指定するために、カスタム `NodePool` リソースを作成することもできます。以下は、そのための主な考慮事項です。 + +1. `NodePool` は、すべての新しいノードを Kubernetes ラベル `type: karpenter` で起動するように設定されており、これにより、デモンストレーション目的で Pod を Karpenter ノードに特定してターゲットできるようになります。 +2. [NodePool CRD](https://karpenter.sh/docs/concepts/nodepools/) は、インスタンスタイプやゾーンなどのノードプロパティの定義をサポートしています。この設定では、`karpenter.sh/capacity-type` を設定して、最初は Karpenter をオンデマンドインスタンスのプロビジョニングに制限し、`node.kubernetes.io/instance-type` を設定して特定のインスタンスタイプのサブセットに制限しています。他にどのようなプロパティが [利用可能かはこちら](https://karpenter.sh/docs/concepts/scheduling/#selecting-nodes) で確認できます。ワークショップ中にさらにいくつか取り組みます。 +3. `NodePool` は、それが管理する CPU とメモリの量に制限を定義できます。この制限に達すると、Karpenter はその特定の `NodePool` に関連する追加容量をプロビジョニングせず、総コンピューティングに上限を提供します。 + +`NodePool` に加えて、Karpenter にはもう 1 つ重要なリソース、`NodeClass` があります。前の `NodePool` 設定の `nodeClassRef` の下で参照されている `NodeClass` を確認できます。この `NodeClass` も EKS Auto Mode によって事前にプロビジョニングされています。以下がその設定です。 + +```bash +$ kubectl get nodeclass default -o yaml + +apiVersion: eks.amazonaws.com/v1 +kind: NodeClass +metadata: + annotations: + eks.amazonaws.com/nodeclass-hash: "495408067366721138" + eks.amazonaws.com/nodeclass-hash-version: v2 + finalizers: + - eks.amazonaws.com/termination + generation: 1 + labels: + app.kubernetes.io/managed-by: eks + name: default + resourceVersion: "304263" +spec: + ephemeralStorage: + iops: 3000 + size: 80Gi + throughput: 125 + networkPolicy: DefaultAllow + networkPolicyEventLogs: Disabled + role: eks-workshop-auto-auto-node + securityGroupSelectorTerms: + - id: sg-0c70efd097a74a4cf + snatPolicy: Random + subnetSelectorTerms: + - id: subnet-096bfe6623a87be3f + - id: subnet-09e84ab4eee5d16bb + - id: subnet-02a87ab5b226b952d +``` + +1. `role` 属性は、Karpenter によってプロビジョニングされる EC2 インスタンスに適用される IAM role を割り当てます +2. `subnetSelectorTerms` は、Karpenter が EC2 インスタンスを起動するサブネットを検索するために使用できます。 +3. `securityGroupSelectorTerms` は、EC2 インスタンスにアタッチされるセキュリティグループに対して同じ機能を実現します。 + +これらのリソースがすべて EKS Auto Mode によって管理されているため、Karpenter はクラスターの容量のプロビジョニングを開始するために必要な基本要件を満たしています。 + +実際に動作を確認するために、ハンズオンを行いましょう。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/network-policies/egress.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/network-policies/egress.md new file mode 100644 index 0000000000..d5d5f239b5 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/network-policies/egress.md @@ -0,0 +1,93 @@ +--- +title: "Egressコントロールの実装" +sidebar_position: 70 +tmdTranslationSourceHash: 'c3b515d0268ac59bde0627c5900ac0d1' +--- + + + +上記のアーキテクチャ図に示されているように、'ui'コンポーネントはフロントフェイシングアプリです。そこで、'ui'コンポーネントのネットワークコントロールの実装を開始するために、'ui'namespaceからのすべてのegressトラフィックをブロックするネットワークポリシーを定義します。 + +::yaml{file="manifests/modules/networking/network-policies/apply-network-policies/default-deny.yaml" paths="spec.podSelector,spec.policyTypes"} + +1. 空のセレクタ`{}`はすべてのPodにマッチします +2. `Egress`ポリシータイプはPodからのアウトバウンドトラフィックを制御します + +> **注意** : ネットワークポリシーにはnamespaceが指定されていません。これは、クラスター内の任意のnamespaceに適用できる汎用ポリシーであるためです。 + +```bash wait=45 +$ kubectl apply -n ui -f ~/environment/eks-workshop/modules/networking/network-policies/apply-network-policies/default-deny.yaml +``` + +それでは、'ui'コンポーネントから'catalog'コンポーネントにアクセスしてみましょう。 + +```bash expectError=true +$ kubectl exec deployment/ui -n ui -- curl http://catalog.catalog/health --connect-timeout 5 + % Total % Received % Xferd Average Speed Time Time Time Current + Dload Upload Total Spent Left Speed + 0 0 0 0 0 0 0 0 --:--:-- 0:00:03 --:--:-- 0 +curl: (28) Resolving timed out after 5000 milliseconds +command terminated with exit code 28 +``` + +curlコマンドの実行時に、以下の文が表示されるはずです。これは、'ui'コンポーネントが'catalog'コンポーネントと直接通信できなくなったことを示しています。 + +```text +curl: (28) Resolving timed out after 5000 milliseconds +``` + +上記のポリシーを実装すると、'ui'コンポーネントは'catalog'サービスやその他のサービスコンポーネントへのアクセスが必要であるため、サンプルアプリケーションが正しく機能しなくなります。'ui'コンポーネントに対して効果的なegressポリシーを定義するには、コンポーネントのネットワーク依存関係を理解する必要があります。 + +'ui'サービスが正常に機能するには、以下の3つのegressネットワーク接続が必要です。 + +1. 'catalog'、'orders'などの他のすべてのサービスと通信できる機能 +2. `kube-system`などのクラスターシステムnamespace内のクラスター全体の共通ツールにアクセスできる機能 +3. DNS名を解決するためにkube-dnsサービスにアクセスできる機能。EKS Auto Modeクラスターの場合、このIPは`172.20.0.10/32`です。以下の構成でこの接続が有効になります。 + +以下のネットワークポリシーは、上記の要件を念頭に置いて設計されています。 + +::yaml{file="manifests/modules/fastpaths/operators/network-policies/allow-ui-egress.yaml" paths="spec.egress.0.to.0,spec.egress.0.to.1,spec.egress.0.to.2"} + +1. 最初のegressルールは、内部サービスのドメイン名解決のためにDNSサーバーへのegressトラフィックを許可することに焦点を当てています。 +2. 最初のegressルールは、'catalog'、'orders'などのすべての`service`コンポーネントへのegressトラフィック（データベースコンポーネントへのアクセスは提供しない）を許可することに焦点を当てており、`namespaceSelector`と組み合わせることで、Podラベルが`app.kubernetes.io/component: service`と一致する限り、任意のnamespaceへのegressトラフィックを許可します。 +3. 2番目のegressルールは、`kube-system` namespace内のすべてのコンポーネントへのegressトラフィックを許可することに焦点を当てており、これによりシステムnamespace内のコンポーネントとの他の重要な通信が可能になります。 + +この追加ポリシーを適用しましょう: + +```bash wait=45 +$ kubectl apply -f ~/environment/eks-workshop/modules/fastpaths/operators/network-policies/allow-ui-egress.yaml +``` + +それでは、'catalog'サービスに接続できるかどうかをテストしてみましょう: + +```bash +$ kubectl exec deployment/ui -n ui -- curl -s http://catalog.catalog/health | yq +OK +``` + +出力からわかるように、'catalog'サービスには接続できますが、`app.kubernetes.io/component: service`ラベルがないため、データベースには接続できません: + +```bash expectError=true +$ kubectl exec deployment/ui -n ui -- curl -v telnet://catalog-mysql.catalog:3306 --connect-timeout 5 + % Total % Received % Xferd Average Speed Time Time Time Current + Dload Upload Total Spent Left Speed + 0 0 0 0 0 0 0 0 --:--:-- 0:00:05 --:--:-- 0 +* Failed to connect to catalog-mysql.catalog port 3306 after 5000 ms: Timeout was reached +* Closing connection 0 +curl: (28) Failed to connect to catalog-mysql.catalog port 3306 after 5000 ms: Timeout was reached +command terminated with exit code 28 +``` + +同様に、'order'サービスなどの他のサービスに接続できるかどうかをテストできます。接続できるはずです。ただし、インターネットや他のサードパーティサービスへの呼び出しはブロックされるはずです。 + +```bash expectError=true +$ kubectl exec deployment/ui -n ui -- curl -v www.google.com --connect-timeout 5 + Trying XXX.XXX.XXX.XXX:80... +* Trying [XXXX:XXXX:XXXX:XXXX::XXXX]:80... +* Immediate connect fail for XXXX:XXXX:XXXX:XXXX::XXXX: Network is unreachable +curl: (28) Failed to connect to www.google.com port 80 after 5001 ms: Timeout was reached +command terminated with exit code 28 +``` + +これで'ui'コンポーネントに対する効果的なegressポリシーを定義したので、catalogサービスとデータベースコンポーネントに焦点を当て、'catalog' namespaceへのトラフィックを制御するネットワークポリシーを実装しましょう。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/network-policies/index.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/network-policies/index.md new file mode 100644 index 0000000000..0c4890935b --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/network-policies/index.md @@ -0,0 +1,28 @@ +--- +title: "安全なPod間通信の有効化" +sidebar_position: 30 +description: "ネットワークポリシーを使用してAmazon Elastic Kubernetes ServiceのPod間のネットワークトラフィックを制限します。" +tmdTranslationSourceHash: '9cc9d0ab7041602715d2c4a43bd989e4' +--- + +デフォルトでは、KubernetesはすべてのPodが制限なく自由に通信できるようになっています。Kubernetesのネットワークポリシーを使用すると、Pod間、Namespace間、およびIPブロック（CIDR範囲）間のトラフィックフローに関するルールを定義および適用できます。これらは仮想ファイアウォールとして機能し、Podラベル、Namespace、IPアドレス、ポートなどのさまざまな基準に基づいて、ingress（受信）およびegress（送信）のネットワークトラフィックルールを指定することで、クラスターをセグメント化して保護できます。 + +以下は、いくつかの主要な要素の説明を含むネットワークポリシーの例です： + +::yaml{file="manifests/modules/networking/network-policies/apply-network-policies/example-network-policy.yaml" paths="metadata,spec.podSelector,spec.policyTypes,spec.ingress,spec.egress" title="example-network-policy.yaml"} + +1. 他のKubernetesオブジェクトと同様に、`metadata`を使用すると、指定されたネットワークポリシーの名前とNamespaceを指定できます +2. `spec.podSelector`を使用すると、指定されたネットワークポリシーが適用されるNamespace内の特定のPodをラベルに基づいて選択できます。仕様で空のPodセレクターまたはmatchLabelsが指定されている場合、ポリシーはNamespace内のすべてのPodに適用されます。 +3. `spec.policyTypes`は、選択されたPodに対してポリシーがingressトラフィック、egressトラフィック、またはその両方に適用されるかを指定します。このフィールドを指定しない場合、デフォルトの動作では、ネットワークポリシーがegressセクションを持たない限り、ingressトラフィックのみにネットワークポリシーが適用されます。egressセクションがある場合、ネットワークポリシーはingressとegressの両方のトラフィックに適用されます。 +4. `ingress`を使用すると、どのPod（`podSelector`）、Namespace（`namespaceSelector`）、またはCIDR範囲（`ipBlock`）からのトラフィックが選択されたPodへ許可されるか、およびどのポートまたはポート範囲を使用できるかを指定するingressルールを設定できます。ポートまたはポート範囲が指定されていない場合、任意のポートを通信に使用できます。 +5. `egress`を使用すると、選択されたPodからどのPod（`podSelector`）、Namespace（`namespaceSelector`）、またはCIDR範囲（`ipBlock`）へのトラフィックが許可されるか、およびどのポートまたはポート範囲を使用できるかを指定するegressルールを設定できます。ポートまたはポート範囲が指定されていない場合、任意のポートを通信に使用できます。 + +Kubernetesネットワークポリシーで許可または制限される機能の詳細については、[Kubernetesドキュメント](https://kubernetes.io/docs/concepts/services-networking/network-policies/)を参照してください。 + +ネットワークポリシーに加えて、Amazon VPC CNIのIPv4モードには「Security Groups for Pods」と呼ばれる強力な機能があります。この機能により、Amazon EC2セキュリティグループを使用して、ノードにデプロイされたPodへの、およびPodからのインバウンドおよびアウトバウンドネットワークトラフィックを管理する包括的なルールを定義できます。Security Groups for Podsとネットワークポリシーの間には機能の重複がありますが、いくつかの重要な違いがあります。 + +- セキュリティグループはCIDR範囲へのingressおよびegressトラフィックの制御を可能にしますが、ネットワークポリシーはPod、Namespace、およびCIDR範囲へのingressおよびegressトラフィックの制御を可能にします。 +- セキュリティグループは他のセキュリティグループからのingressおよびegressトラフィックの制御を可能にしますが、これはネットワークポリシーでは利用できません。 + +Amazon EKSでは、Pod間のネットワーク通信を制限し、攻撃対象領域を減らし、潜在的な脆弱性を最小限に抑えるために、セキュリティグループと併せてネットワークポリシーを使用することを強く推奨しています。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/network-policies/ingress.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/network-policies/ingress.md new file mode 100644 index 0000000000..80dc6e261a --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/network-policies/ingress.md @@ -0,0 +1,144 @@ +--- +title: "Ingress コントロールの実装" +sidebar_position: 80 +tmdTranslationSourceHash: 'b4ba9980ff48dda0f8bd740131f20534' +--- + + + +アーキテクチャ図に示されているように、'catalog' namespace は 'ui' namespace からのみトラフィックを受信し、他の namespace からは受信しません。また、'catalog' データベースコンポーネントは、'catalog' サービスコンポーネントからのみトラフィックを受信できます。 + +上記のネットワークルールを、'catalog' namespace へのトラフィックを制御する Ingress ネットワークポリシーを使用して実装していきます。 + +ポリシーを適用する前は、'catalog' サービスは 'ui' コンポーネントからアクセスできます： + +```bash timeout=180 +$ kubectl exec deployment/ui -n ui -- curl -v catalog.catalog/health --connect-timeout 5 + Trying XXX.XXX.XXX.XXX:80... +* Connected to catalog.catalog (XXX.XXX.XXX.XXX) port 80 (#0) +> GET /health HTTP/1.1 +> Host: catalog.catalog +> User-Agent: curl/7.88.1 +> Accept: */* +> +< HTTP/1.1 200 OK +... +``` + +'orders' コンポーネントからもアクセスできます： + +```bash +$ kubectl exec deployment/orders -n orders -- curl -v catalog.catalog/health --connect-timeout 5 + Trying XXX.XXX.XXX.XXX:80... +* Connected to catalog.catalog (XXX.XXX.XXX.XXX) port 80 (#0) +> GET /health HTTP/1.1 +> Host: catalog.catalog +> User-Agent: curl/7.88.1 +> Accept: */* +> +< HTTP/1.1 200 OK +... +``` + +次に、'catalog' サービスコンポーネントへのトラフィックを 'ui' コンポーネントからのみ許可するネットワークポリシーを定義します： + +::yaml{file="manifests/modules/networking/network-policies/apply-network-policies/allow-catalog-ingress-webservice.yaml" paths="spec.podSelector,spec.ingress.0.from.0"} + +1. `podSelector` はラベル `app.kubernetes.io/name: catalog` と `app.kubernetes.io/component: service` を持つ Pod をターゲットにします +2. この `ingress.from` 設定は、`kubernetes.io/metadata.name: ui` で識別される `ui` namespace で実行され、ラベル `app.kubernetes.io/name: ui` を持つ Pod からの受信接続のみを許可します + +ポリシーを適用しましょう： + +```bash wait=45 +$ kubectl apply -f ~/environment/eks-workshop/modules/networking/network-policies/apply-network-policies/allow-catalog-ingress-webservice.yaml +``` + +次に、'ui' から 'catalog' コンポーネントに引き続きアクセスできることを確認してポリシーを検証します： + +```bash +$ kubectl exec deployment/ui -n ui -- curl -v catalog.catalog/health --connect-timeout 5 + Trying XXX.XXX.XXX.XXX:80... +* Connected to catalog.catalog (XXX.XXX.XXX.XXX) port 80 (#0) +> GET /health HTTP/1.1 +> Host: catalog.catalog +> User-Agent: curl/7.88.1 +> Accept: */* +> +< HTTP/1.1 200 OK +... +``` + +しかし、'orders' コンポーネントからはアクセスできません： + +```bash expectError=true +$ kubectl exec deployment/orders -n orders -- curl -v catalog.catalog/health --connect-timeout 5 +* Trying XXX.XXX.XXX.XXX:80... +* ipv4 connect timeout after 4999ms, move on! +* Failed to connect to catalog.catalog port 80 after 5001 ms: Timeout was reached +* Closing connection 0 +curl: (28) Failed to connect to catalog.catalog port 80 after 5001 ms: Timeout was reached +... +``` + +上記の出力からわかるように、'ui' コンポーネントのみが 'catalog' サービスコンポーネントと通信でき、'orders' サービスコンポーネントは通信できません。 + +しかし、これでは 'catalog' データベースコンポーネントがまだ開いたままなので、'catalog' サービスコンポーネントのみが 'catalog' データベースコンポーネントと通信できるようにするネットワークポリシーを実装しましょう。 + +::yaml{file="manifests/modules/networking/network-policies/apply-network-policies/allow-catalog-ingress-db.yaml" paths="spec.podSelector,spec.ingress.0.from.0"} + +1. `podSelector` はラベル `app.kubernetes.io/name: catalog` と `app.kubernetes.io/component: mysql` を持つ Pod をターゲットにします +2. `ingress.from` はラベル `app.kubernetes.io/name: catalog` と `app.kubernetes.io/component: service` を持つ Pod からの受信接続のみを許可します + +ポリシーを適用しましょう： + +```bash wait=45 +$ kubectl apply -f ~/environment/eks-workshop/modules/networking/network-policies/apply-network-policies/allow-catalog-ingress-db.yaml +``` + +'orders' コンポーネントから 'catalog' データベースに接続できないことを確認してネットワークポリシーを検証しましょう： + +```bash expectError=true +$ kubectl exec deployment/orders -n orders -- curl -v catalog-mysql.catalog:3306 --connect-timeout 5 +* Trying XXX.XXX.XXX.XXX:3306... +* ipv4 connect timeout after 4999ms, move on! +* Failed to connect to catalog-mysql.catalog port 3306 after 5001 ms: Timeout was reached +* Closing connection 0 +curl: (28) Failed to connect to catalog-mysql.catalog port 3306 after 5001 ms: Timeout was reached +command terminated with exit code 28 +... +``` + +重要な点として、ネットワークポリシーは IP アドレスに依存していないことに注意してください。'catalog' Pod を再起動して、引き続き接続できることを確認できます： + +```bash timeout=180 +$ kubectl rollout restart deployment/catalog -n catalog +$ kubectl rollout status deployment/catalog -n catalog --timeout=2m +``` + +次に、'catalog' Pod から 'catalog-mysql' データベースに接続できるか確認しましょう。 + +```bash +$ kubectl exec deployment/catalog -n catalog -- curl -v catalog-mysql.catalog:3306 --connect-timeout 5 --http0.9 + % Total % Received % Xferd Average Speed Time Time Time Current + Dload Upload Total Spent Left Speed + 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Host catalog-mysql.catalog:3306 was resolved. +* IPv6: (none) +* IPv4: 172.20.233.240 +* Trying 172.20.233.240:3306... +* Connected to catalog-mysql.catalog (172.20.233.240) port 3306 +* using HTTP/1.x +> GET / HTTP/1.1 +> Host: catalog-mysql.catalog:3306 +> User-Agent: curl/8.11.1 +> Accept: */* +> +* Request completely sent off +{ [5 bytes data] +100 115 0 115 0 0 20901 0 --:--:-- --:--:-- --:--:-- 23000 +* shutting down connection #0 +``` + +上記の出力からわかるように、'catalog' サービスコンポーネントのみが 'catalog' データベースコンポーネントと通信できます。 + +これで 'catalog' namespace に対する効果的な Ingress ポリシーを実装できたので、同じロジックをサンプルアプリケーションの他の namespace やコンポーネントに拡張することで、サンプルアプリケーションの攻撃対象領域を大幅に削減し、ネットワークセキュリティを向上させることができます。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/network-policies/setup.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/network-policies/setup.md new file mode 100644 index 0000000000..869d30e1a5 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/network-policies/setup.md @@ -0,0 +1,46 @@ +--- +title: "ラボのセットアップ" +sidebar_position: 60 +tmdTranslationSourceHash: '9eba6c5d1669ba133f53bbc555f31bb3' +--- + +このラボでは、ラボクラスターにデプロイされたサンプルアプリケーションのネットワークポリシーを実装します。サンプルアプリケーションのコンポーネントアーキテクチャを以下に示します。 + + + +サンプルアプリケーションの各コンポーネントは、独自の namespace に実装されています。例えば、**'ui'** コンポーネントは **'ui'** namespace にデプロイされ、**'catalog'** Web サービスと **'catalog'** MySQL データベースは **'catalog'** namespace にデプロイされています。 + +現在、定義されたネットワークポリシーはなく、サンプルアプリケーション内のどのコンポーネントも他のコンポーネントや外部サービスと通信できます。例えば、'catalog' コンポーネントは 'checkout' コンポーネントと直接通信できます。以下のコマンドを使用してこれを検証できます。 + +```bash +$ kubectl exec deployment/catalog -n catalog -- curl -s http://checkout.checkout/health | jq +{ + "status": "ok", + "info": { + "chaos": { + "status": "up" + } + }, + "error": {}, + "details": { + "chaos": { + "status": "up" + } + } +} +``` + +EKS Auto Mode クラスターでネットワークポリシーを有効にするために必要な構成変更を行いましょう。そのために、クラスターにネットワーキングを提供する VPC container network interface (CNI) の ConfigMap を作成します。 + +::yaml{file="manifests/modules/fastpaths/operators/network-policies/vpc-cni-policies.yaml" paths="data.enable-network-policy-controller"} + +1. これにより、vpc-cni プラグインでネットワークポリシーコントローラが有効になります + +この構成を適用します。 + +```bash timeout=180 +$ kubectl apply -f ~/environment/eks-workshop/modules/fastpaths/operators/network-policies/vpc-cni-policies.yaml +``` + +それでは、サンプルアプリケーションのネットワークトラフィックフローをより適切に制御できるように、いくつかのネットワークルールを実装しましょう。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/secrets-manager/ascp.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/secrets-manager/ascp.md new file mode 100644 index 0000000000..e882d5c3d7 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/secrets-manager/ascp.md @@ -0,0 +1,49 @@ +--- +title: "AWS Secrets and Configuration Provider (ASCP)" +sidebar_position: 422 +tmdTranslationSourceHash: 'caf6dfb26db7a75b14bca637027c5da2' +--- + +このワークショップでは、AWS Secrets and Configuration Provider (ASCP) を EKS クラスターに事前設定しています。 + +アドオンが正しくデプロイされたことを検証しましょう。 + +まず、Secret Store CSI driver の `DaemonSet` とその `Pod` を確認します： + +```bash +$ kubectl -n kube-system get daemonsets,pods -l app=secrets-store-csi-driver +NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE +daemonset.apps/csi-secrets-store-secrets-store-csi-driver 3 3 3 3 3 kubernetes.io/os=linux 3m57s + +NAME READY STATUS RESTARTS AGE +pod/csi-secrets-store-secrets-store-csi-driver-bzddm 3/3 Running 0 3m57s +``` + +次に、CSI Secrets Store Provider for AWS driver の `DaemonSet` とその `Pod` を確認します： + +```bash +$ kubectl -n kube-system get daemonset,pods -l "app=secrets-store-csi-driver-provider-aws" +NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE +daemonset.apps/secrets-store-csi-driver-provider-aws 3 3 3 3 3 kubernetes.io/os=linux 2m3s + +NAME READY STATUS RESTARTS AGE +pod/secrets-store-csi-driver-provider-aws-4jf8f 1/1 Running 0 2m2s +``` + +CSI driver を介して AWS Secrets Manager に保存されたシークレットへのアクセスを提供するには、`SecretProviderClass` が必要です。これは、AWS Secrets Manager の情報と一致するドライバー設定とパラメータを提供する namespace スコープの Custom Resource Definition (CRD) です。 + +::yaml{file="manifests/modules/security/secrets-manager/secret-provider-class.yaml" paths="spec.provider,spec.parameters.objects,spec.secretObjects.0"} + +1. `provider: aws` は AWS Secrets Store CSI driver を指定します +2. `parameters.objects` は、`$SECRET_NAME` という名前の AWS `secretsmanager` ソースシークレットを定義し、[jmesPath](https://jmespath.org/) を使用して特定の `username` と `password` フィールドを抽出し、Kubernetes で使用するための名前付きエイリアスに変換します +3. `secretObjects` は、抽出された `username` と `password` フィールドをシークレットキーにマッピングする `catalog-secret` という名前の標準 `Opaque` Kubernetes Secret を作成します + +このリソースを作成しましょう： + +```bash +$ cat ~/environment/eks-workshop/modules/security/secrets-manager/secret-provider-class.yaml \ + | envsubst | kubectl apply -f - +``` + +Secret Store CSI Driver は、Kubernetes と AWS Secrets Manager などの外部シークレットプロバイダーの間の仲介役として機能します。SecretProviderClass で設定すると、シークレットを Pod ボリュームのファイルとしてマウントし、同期された Kubernetes Secret オブジェクトを作成することができ、アプリケーションがこれらのシークレットを使用する方法に柔軟性を提供します。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/secrets-manager/create-secret.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/secrets-manager/create-secret.md new file mode 100644 index 0000000000..3807e7f1e3 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/secrets-manager/create-secret.md @@ -0,0 +1,43 @@ +--- +title: "AWS Secrets Manager にシークレットを保存する" +sidebar_position: 421 +tmdTranslationSourceHash: '89fe2ca98f6ed6cf386c25c15672fc9c' +--- + +まず、AWS CLI を使用して AWS Secrets Manager にシークレットを作成しましょう。ユーザー名とパスワードの値を含む JSON エンコードされた認証情報を持つシークレットを作成します。 + +```bash +$ export SECRET_SUFFIX=$(openssl rand -hex 4) +$ export SECRET_NAME="$EKS_CLUSTER_AUTO_NAME-catalog-secret-${SECRET_SUFFIX}" +$ aws secretsmanager create-secret --name "$SECRET_NAME" \ + --secret-string '{"username":"catalog", "password":"dYmNfWV4uEvTzoFu"}' --region $AWS_REGION | jq +{ + "ARN": "arn:aws:secretsmanager:us-west-2:1234567890:secret:eks-workshop-catalog-secret-WDD8yS", + "Name": "eks-workshop-catalog-secret-WDD8yS", + "VersionId": "7e0b352d-6666-4444-aaaa-cec1f1d2df1b" +} +``` + +:::note +アカウント内の既存のシークレットと競合しないように、`openssl` を使用してシークレット名に一意のサフィックスを生成しています。 +::: + +シークレットが正常に作成されたことを、[AWS Secrets Manager Console](https://console.aws.amazon.com/secretsmanager/listsecrets) または AWS CLI のいずれかで確認できます。CLI を使用してシークレットのメタデータを確認してみましょう。 + +```bash +$ aws secretsmanager describe-secret --secret-id "$SECRET_NAME" | jq +{ + "ARN": "arn:aws:secretsmanager:us-west-2:1234567890:secret:eks-workshop-catalog-secret-WDD8yS", + "Name": "eks-workshop-catalog-secret-WDD8yS", + "LastChangedDate": "2023-10-10T20:44:51.882000+00:00", + "VersionIdsToStages": { + "94d1fe43-87f5-42fb-bf28-f6b090f0ca44": [ + "AWSCURRENT" + ] + }, + "CreatedDate": "2023-10-10T20:44:51.439000+00:00" +} +``` + +AWS Secrets Manager にシークレットを正常に作成できたので、次のセクションで Kubernetes アプリケーションで使用します。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/secrets-manager/external-secrets.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/secrets-manager/external-secrets.md new file mode 100644 index 0000000000..8a0b46e691 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/secrets-manager/external-secrets.md @@ -0,0 +1,137 @@ +--- +title: "External Secrets Operator" +sidebar_position: 424 +tmdTranslationSourceHash: '1de17192c2e07a824ef9d3b122a721db' +--- + +次に、External Secrets Operator を使用して AWS Secrets Manager と統合する方法を見ていきましょう。これは既に EKS クラスターにインストールされています: + +```bash wait=30 +$ kubectl -n external-secrets get pods +NAME READY STATUS RESTARTS AGE +external-secrets-6d95d66dc8-5trlv 1/1 Running 0 7m +external-secrets-cert-controller-774dff987b-krnp7 1/1 Running 0 7m +external-secrets-webhook-6565844f8f-jxst8 1/1 Running 0 7m +$ kubectl -n external-secrets get sa +NAME SECRETS AGE +default 0 7m +external-secrets-sa 0 7m +``` + +Operator は `external-secrets-sa` という名前の ServiceAccount を使用しており、これは [EKS Pod Identities](../amazon-eks-pod-identity/) を介して IAM role に関連付けられ、シークレットを取得するために AWS Secrets Manager へのアクセスを提供します: + +`ClusterSecretStore` リソースを作成する必要があります - これは、任意の namespace の ExternalSecrets から参照できるクラスター全体の SecretStore です。この `ClusterSecretStore` を作成するために使用するファイルを見てみましょう: + +::yaml{file="manifests/modules/fastpaths/operators/external-secrets/cluster-secret-store.yaml" paths="spec.provider.aws.service,spec.provider.aws.region"} + +1. シークレットソースとして AWS Secrets Manager を使用するために `service: SecretsManager` を設定 +2. `$AWS_REGION` 環境変数を使用して、シークレットが保存されている AWS リージョンを指定 + +:::note +EKS Pod Identites を使用する場合、ServiceAccount `external-secrets-sa` を AWS Secrets Manager 権限を持つ IAM role にリンクする Pod Identity Association を介して認証するため、ここで auth セクションは不要です +::: + +このファイルを使用して ClusterSecretStore リソースを作成しましょう。 + +```bash timeout=300 +$ kubectl wait --for=condition=available deployment/external-secrets-webhook -n external-secrets --timeout=240s +$ cat ~/environment/eks-workshop/modules/fastpaths/operators/external-secrets/cluster-secret-store.yaml \ + | envsubst | kubectl apply -f - +``` + +次に、AWS Secrets Manager から取得するデータと、それを Kubernetes Secret に変換する方法を定義する `ExternalSecret` を作成します。その後、これらの認証情報を使用するように `catalog` Deployment を更新します: + +```kustomization +modules/security/secrets-manager/external-secrets/kustomization.yaml +Deployment/catalog +ExternalSecret/catalog-external-secret +``` + +```bash timeout=180 +$ kubectl kustomize ~/environment/eks-workshop/modules/security/secrets-manager/external-secrets/ \ + | envsubst | kubectl apply -f- +$ kubectl rollout status -n catalog deployment/catalog --timeout=120s +``` + +新しい `ExternalSecret` リソースを見てみましょう: + +```bash +$ kubectl -n catalog get externalsecrets.external-secrets.io +NAME STORE REFRESH INTERVAL STATUS READY +catalog-external-secret cluster-secret-store 1h SecretSynced True +``` + +`SecretSynced` ステータスは、AWS Secrets Manager からの同期が成功したことを示しています。リソースの仕様を見てみましょう: + +```bash +$ kubectl -n catalog get externalsecrets.external-secrets.io catalog-external-secret -o yaml | yq '.spec' +dataFrom: + - extract: + conversionStrategy: Default + decodingStrategy: None + key: eks-workshop-catalog-secret-WDD8yS +refreshInterval: 1h +secretStoreRef: + kind: ClusterSecretStore + name: cluster-secret-store +target: + creationPolicy: Owner + deletionPolicy: Retain +``` + +この設定は、`key` パラメータを介して AWS Secrets Manager のシークレットと、先ほど作成した `ClusterSecretStore` を参照しています。1 時間の `refreshInterval` は、シークレット値が同期される頻度を決定します。 + +ExternalSecret を作成すると、対応する Kubernetes secret が自動的に作成されます: + +```bash +$ kubectl -n catalog get secrets +NAME TYPE DATA AGE +catalog-db Opaque 2 21h +catalog-external-secret Opaque 2 1m +catalog-secret Opaque 2 5h40m +``` + +このシークレットは External Secrets Operator によって所有されています: + +```bash +$ kubectl -n catalog get secret catalog-external-secret -o yaml | yq '.metadata.ownerReferences' +- apiVersion: external-secrets.io/v1beta1 + blockOwnerDeletion: true + controller: true + kind: ExternalSecret + name: catalog-external-secret + uid: b8710001-366c-44c2-8e8d-462d85b1b8d7 +``` + +`catalog` Pod が新しいシークレット値を使用していることを確認できます: + +```bash +$ kubectl -n catalog get pods +NAME READY STATUS RESTARTS AGE +catalog-777c4d5dc8-lmf6v 1/1 Running 0 1m +catalog-mysql-0 1/1 Running 0 24h +$ kubectl -n catalog get deployment catalog -o yaml | yq '.spec.template.spec.containers[] | .env' +- name: RETAIL_CATALOG_PERSISTENCE_USER + valueFrom: + secretKeyRef: + key: username + name: catalog-external-secret +- name: RETAIL_CATALOG_PERSISTENCE_PASSWORD + valueFrom: + secretKeyRef: + key: password + name: catalog-external-secret +``` + +### まとめ + +AWS Secrets Manager のシークレットを管理するための **AWS Secrets and Configuration Provider (ASCP)** と **External Secrets Operator (ESO)** の間に、単一の「ベスト」な選択肢はありません。 + +各ツールには明確な利点があります: + +- **ASCP** は、環境変数としての露出を避けて、AWS Secrets Manager からシークレットを volume として直接マウントできますが、これには volume 管理が必要です。 + +- **ESO** は Kubernetes Secrets のライフサイクル管理を簡素化し、クラスター全体の SecretStore 機能を提供しますが、volume マウントをサポートしていません。 + +特定のユースケースが意思決定を主導すべきであり、両方のツールを使用することで、シークレット管理において最大限の柔軟性とセキュリティを提供できます。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/secrets-manager/index.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/secrets-manager/index.md new file mode 100644 index 0000000000..7d71d59011 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/secrets-manager/index.md @@ -0,0 +1,25 @@ +--- +title: "AWS Secrets Managerでシークレットを管理する" +sidebar_position: 40 +description: "Amazon Elastic Kubernetes Service上で実行されるアプリケーションに、AWS Secrets Managerを使用して認証情報などの機密設定を提供します。" +tmdTranslationSourceHash: '0f47d16061fcc1c6fcd6acb283a09b15' +--- + +:::tip セットアップ済みの内容 +Amazon EKS Auto Modeクラスターには、以下のコンポーネントが設定されています。 + +- Kubernetes Secrets Store CSI Driver +- AWS Secrets and Configuration Provider +- External Secrets Operator +::: + +[AWS Secrets Manager](https://aws.amazon.com/secrets-manager/)は、認証情報、APIキー、証明書などの機密データを簡単にローテーション、管理、取得できるサービスです。[Kubernetes Secrets Store CSI Driver](https://secrets-store-csi-driver.sigs.k8s.io/)と[AWS Secrets and Configuration Provider (ASCP)](https://github.com/aws/secrets-store-csi-driver-provider-aws)を使用することで、Secrets Managerに保存されたシークレットをKubernetes Podのボリュームとしてマウントできます。 + +ASCPにより、Amazon EKS上で実行されるワークロードは、IAMロールとポリシーを使用したきめ細かなアクセス制御を通じて、Secrets Managerに保存されたシークレットにアクセスできます。Podがシークレットへのアクセスをリクエストすると、ASCPはPodのIDを取得し、それをIAMロールと交換し、そのロールを引き受けてから、そのロールに許可されたシークレットのみをSecrets Managerから取得します。 + +AWS Secrets ManagerをKubernetesと統合する別のアプローチとして、[External Secrets](https://external-secrets.io/)があります。このオペレーターは、AWS Secrets ManagerからKubernetes Secretsへシークレットを同期し、抽象化レイヤーを通じてライフサイクル全体を管理します。Secrets ManagerからKubernetes Secretsへ値を自動的に注入します。 + +どちらのアプローチも、Secrets Managerを通じた自動シークレットローテーションをサポートしています。External Secretsを使用する場合は、更新をポーリングするリフレッシュ間隔を設定でき、Secrets Store CSI Driverはローテーションレコンサイラー機能を提供して、Podが常に最新のシークレット値を持つことを保証します。 + +以下のセクションでは、AWS Secrets ManagerとASCP、およびExternal Secretsの両方を使用してシークレットを管理する実践的な例を探ります。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/secrets-manager/mounting-secrets.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/secrets-manager/mounting-secrets.md new file mode 100644 index 0000000000..bf4d021e40 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/operator/secrets-manager/mounting-secrets.md @@ -0,0 +1,132 @@ +--- +title: "Kubernetes Pod に AWS Secrets Manager のシークレットをマウントする" +sidebar_position: 423 +tmdTranslationSourceHash: '900774bf902b907197a8ccbf7ae6e588' +--- + +AWS Secrets Manager に保存されたシークレットを Kubernetes Secret と同期したので、それを Pod の中にマウントしてみましょう。まず、`catalog` Deployment と `catalog` Namespace の既存の Secret を確認しましょう。 + +現在、`catalog` Deployment は環境変数を介して `catalog-db` Secret からデータベース認証情報にアクセスしています: + +- `RETAIL_CATALOG_PERSISTENCE_USER` +- `RETAIL_CATALOG_PERSISTENCE_PASSWORD` + +これは、`envFrom` で Secret を参照することによって行われます: + +```bash +$ kubectl -n catalog get deployment catalog -o yaml | yq '.spec.template.spec.containers[] | .envFrom' + +- configMapRef: + name: catalog +- secretRef: + name: catalog-db +``` + +`catalog` Deployment には現在、`/tmp` にマウントされた `emptyDir` 以外に追加の `volumes` や `volumeMounts` はありません: + +```bash +$ kubectl -n catalog get deployment catalog -o yaml | yq '.spec.template.spec.volumes' +- emptyDir: + medium: Memory + name: tmp-volume +$ kubectl -n catalog get deployment catalog -o yaml | yq '.spec.template.spec.containers[] | .volumeMounts' +- mountPath: /tmp + name: tmp-volume +``` + +`catalog` Deployment を変更して、AWS Secrets Manager に保存されたシークレットを認証情報のソースとして使用するようにしましょう: + +```kustomization +modules/security/secrets-manager/mounting-secrets/kustomization.yaml +Deployment/catalog +``` + +以前検証した SecretProviderClass を使用して、CSI ドライバーで AWS Secrets Manager のシークレットを Pod 内の `/etc/catalog-secret` mountPath にマウントします。これにより、AWS Secrets Manager は保存されたシークレットの内容を Amazon EKS と同期し、Pod 内で環境変数として使用できる Kubernetes Secret を作成します。 + +```bash timeout=180 +$ kubectl kustomize ~/environment/eks-workshop/modules/security/secrets-manager/mounting-secrets/ \ + | envsubst | kubectl apply -f- +$ kubectl rollout status -n catalog deployment/catalog --timeout=120s +``` + +`catalog` Namespace で行われた変更を確認しましょう。 + +Deployment に新しい `volume` と対応する `volumeMount` が追加され、CSI Secret Store Driver を使用して `/etc/catalog-secret` にマウントされています: + +```bash +$ kubectl -n catalog get deployment catalog -o yaml | yq '.spec.template.spec.volumes' +- csi: + driver: secrets-store.csi.k8s.io + readOnly: true + volumeAttributes: + secretProviderClass: catalog-spc + name: catalog-secret +- emptyDir: + medium: Memory + name: tmp-volume +$ kubectl -n catalog get deployment catalog -o yaml | yq '.spec.template.spec.containers[] | .volumeMounts' +- mountPath: /etc/catalog-secret + name: catalog-secret + readOnly: true +- mountPath: /tmp + name: tmp-volume +``` + +マウントされた Secret は、Pod のコンテナファイルシステム内のファイルとして機密情報にアクセスする安全な方法を提供します。このアプローチは、シークレット値を環境変数として公開しないことや、ソース Secret が変更されたときに自動的に更新されることなど、いくつかの利点があります。 + +Pod 内のマウントされた Secret の内容を確認しましょう: + +```bash +$ kubectl -n catalog exec deployment/catalog -- ls /etc/catalog-secret/ +eks-workshop-auto-catalog-secret-WDD8yS +password +username +$ kubectl -n catalog exec deployment/catalog -- cat /etc/catalog-secret/${SECRET_NAME} | jq +{"username":"catalog", "password":"dYmNfWV4uEvTzoFu"} +$ kubectl -n catalog exec deployment/catalog -- cat /etc/catalog-secret/username | yq +catalog +$ kubectl -n catalog exec deployment/catalog -- cat /etc/catalog-secret/password | yq +dYmNfWV4uEvTzoFu +``` + +:::info +CSI ドライバーを使用して AWS Secrets Manager からシークレットをマウントする場合、mountPath に 3 つのファイルが作成されます: + +1. AWS シークレットの名前を持つファイルで、完全な JSON 値が含まれます +2. SecretProviderClass で定義された jmesPath 式を介して抽出された各キーの個別のファイル + +::: + +環境変数は、CSI Secret Store ドライバーを介して SecretProviderClass によって自動的に作成された新しい `catalog-secret` から取得されるようになりました: + +```bash +$ kubectl -n catalog get deployment catalog -o yaml | yq '.spec.template.spec.containers[] | .env' +- name: RETAIL_CATALOG_PERSISTENCE_USER + valueFrom: + secretKeyRef: + key: username + name: catalog-secret +- name: RETAIL_CATALOG_PERSISTENCE_PASSWORD + valueFrom: + secretKeyRef: + key: password + name: catalog-secret +$ kubectl -n catalog get secrets +NAME TYPE DATA AGE +catalog-db Opaque 2 15h +catalog-secret Opaque 2 43s +``` + +実行中の Pod で環境変数が正しく設定されていることを確認できます: + +```bash +$ kubectl -n catalog exec -ti deployment/catalog -- env | grep PERSISTENCE +RETAIL_CATALOG_PERSISTENCE_ENDPOINT=catalog-mysql:3306 +RETAIL_CATALOG_PERSISTENCE_PASSWORD=dYmNfWV4uEvTzoFu +RETAIL_CATALOG_PERSISTENCE_PROVIDER=mysql +RETAIL_CATALOG_PERSISTENCE_DB_NAME=catalog +RETAIL_CATALOG_PERSISTENCE_USER=catalog +``` + +これで、シークレット管理のベストプラクティスであるシークレットローテーションを活用できる、AWS Secrets Manager と完全に統合された Kubernetes Secret ができました。AWS Secrets Manager でシークレットがローテーションまたは更新されたときは、Deployment の新しいバージョンをロールアウトすることで、CSI Secret Store ドライバーが Kubernetes Secret の内容を更新された値と同期できるようになります。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/setup/aws-event.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/setup/aws-event.md new file mode 100644 index 0000000000..1fac0d9414 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/setup/aws-event.md @@ -0,0 +1,46 @@ +--- +title: AWSイベントでの利用 +sidebar_position: 20 +tmdTranslationSourceHash: 04b12c0c4959e1262ffab9241608712d +--- + +このワークショップに参加することで、ラボ資料を完了するために使用するAWSアカウントが提供されます。[https://catalog.workshops.aws/](https://catalog.workshops.aws/)にアクセスしてポータルに接続します。**Get Started**をクリックします。 + +![Workshop Studio Home](/docs/introduction/setup/workshop-studio-home.webp) + +サインインするよう求められます。**Email One-Time Password(OTP)**のオプションを選択します。 + +![Workshop Studio Sign in](/docs/introduction/setup/ws-studio-login.webp) + +メールアドレスを入力し、**Send passcode**を押します。これにより、ワンタイムパスコードが受信トレイに送信されます。メールが届いたら、パスコードを入力してログインします。 + +インストラクターから、これらの演習を開始する前に**イベントアクセスコード**が提供されているはずです。提供されたコードをテキストボックスに入力し、**Next**をクリックします。 + +![Event Code](/docs/introduction/setup/event-code.webp) + +利用規約を読んで同意し、**Join event**をクリックして続行します。 + +![Review and Join](/docs/introduction/setup/review-and-join.webp) + +個人用ダッシュボードが表示されます。**Open AWS Console**ボタンを選択して、AWSアカウントコンソールに移動します。 + +![Open Console](/docs/introduction/setup/openconsole.webp) + +次に、個人用ダッシュボードページに戻り、**Event Outputs**セクションまでスクロールダウンします。**IdeUrl**フィールドからURLをコピーし、新しいブラウザタブで開きます。 + +![Cloud9 Link](/docs/introduction/setup/workshop-studio-06.png) + +パスワードの入力を求められます。 + +![IDE Password](/docs/introduction/setup/visual-studio-01.png) + +出力から**IdePassword**フィールドの値を入力すると、web IDEが読み込まれます。 + +![Code-server login screen](/docs/introduction/setup/vscode-splash.webp) + +**Get started**を押して、ワークショップのスプラッシュページにアクセスします。 + +![Get Started](/docs/introduction/setup/workshop-event-page.webp) + +これで、[ラボのナビゲーションセクション](/docs/fastpaths/navigating-labs)に進むことができます。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/setup/index.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/setup/index.md new file mode 100644 index 0000000000..380e3cdc2b --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/setup/index.md @@ -0,0 +1,19 @@ +--- +title: セットアップ +sidebar_position: 20 +tmdTranslationSourceHash: '533c0316e871767a7636fe216f13f19d' +--- + +このセクションでは、ワークショップのラボを実行するための環境のセットアップ方法について説明します。 + +ワークショップ環境にアクセスするには、2つのオプションがあります： + +1. [AWS イベントでの参加](./aws-event.md) - AWS 主催のワークショップイベントに参加する場合 +2. [独自のアカウントでの実行](./your-account/index.md) - 個人の AWS アカウントでワークショップを実行する場合 + +:::info +各オプションには、ワークショップの演習を完了するために必要なリソースとツールへのアクセス方法の詳細な手順が記載されています。 +::: + +ご自身の状況に最も適したオプションを選択して、環境のセットアップを進めてください。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/setup/your-account/cleanup.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/setup/your-account/cleanup.md new file mode 100644 index 0000000000..2dcf6ee193 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/setup/your-account/cleanup.md @@ -0,0 +1,29 @@ +--- +title: クリーンアップ +sidebar_position: 90 +tmdTranslationSourceHash: 'b50eea77a7ff66e51772b8b1062a1d97' +--- + +:::caution + +先に進む前に、ラボ用 EKS クラスターのプロビジョニングに使用したメカニズムに応じて、それぞれのクリーンアップ手順を実行していることを確認してください： + +- [eksctl](./using-eksctl.md) +- [Terraform](./using-terraform.md) + +::: + +このセクションでは、ラボの実行に使用した IDE のクリーンアップ方法について説明します。 + +まず、CloudFormation スタックをデプロイしたリージョンで CloudShell を開きます： + + + +次に、以下のコマンドを実行して CloudFormation スタックを削除します： + +```bash test=false +$ aws cloudformation delete-stack --stack-name eks-workshop-ide +``` + +スタックが削除されると、IDE に関連するすべてのリソースが AWS アカウントから削除され、今後の課金が防止されます。 + 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 new file mode 100644 index 0000000000..35ceebc89d --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/setup/your-account/index.md @@ -0,0 +1,69 @@ +--- +title: あなたのAWSアカウントで +sidebar_position: 30 +tmdTranslationSourceHash: '816ae7a5604c47cc743c1eddcfcdadec' +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +:::danger 警告 +このワークショップ環境をあなたのAWSアカウントにプロビジョニングすると、リソースが作成され、**それらに関連するコストが発生します**。クリーンアップセクションでは、それらを削除してさらなる課金を防ぐ方法を説明します。 +::: + +このセクションでは、あなた自身のAWSアカウントでラボを実行するための環境をセットアップする方法について説明します。 + +最初のステップは、提供されているCloudFormationテンプレートを使用してIDEを作成することです。以下のAWS CloudFormationクイック作成リンクを使用して、適切なAWSリージョンで目的のテンプレートを起動してください。 + +| リージョン | リンク | +| ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `us-west-2` | [起動](https://us-west-2.console.aws.amazon.com/cloudformation/home#/stacks/quickcreate?templateUrl=https://ws-assets-prod-iad-r-pdx-f3b3f9f1a7d6a3d0.s3.us-west-2.amazonaws.com/39146514-f6d5-41cb-86ef-359f9d2f7265/eks-workshop-vscode-cfn.yaml&stackName=eks-workshop-ide¶m_RepositoryRef=VAR::MANIFESTS_REF) | +| `eu-west-1` | [起動](https://eu-west-1.console.aws.amazon.com/cloudformation/home#/stacks/quickcreate?templateUrl=https://ws-assets-prod-iad-r-dub-85e3be25bd827406.s3.eu-west-1.amazonaws.com/39146514-f6d5-41cb-86ef-359f9d2f7265/eks-workshop-vscode-cfn.yaml&stackName=eks-workshop-ide¶m_RepositoryRef=VAR::MANIFESTS_REF) | +| `ap-southeast-1` | [起動](https://ap-southeast-1.console.aws.amazon.com/cloudformation/home#/stacks/quickcreate?templateUrl=https://ws-assets-prod-iad-r-sin-694a125e41645312.s3.ap-southeast-1.amazonaws.com/39146514-f6d5-41cb-86ef-359f9d2f7265/eks-workshop-vscode-cfn.yaml&stackName=eks-workshop-ide¶m_RepositoryRef=VAR::MANIFESTS_REF) | + +これらの手順は上記のAWSリージョンでテストされており、他のリージョンでは変更なしに動作することは保証されていません。 + +:::warning + +ワークショップ資料の性質上、IDE EC2インスタンスはあなたのアカウントで広範なIAM権限を必要とします。例えば、IAM roleの作成などです。続行する前に、CloudFormationテンプレートでIDEインスタンスに提供されるIAM権限を確認してください。 + +私たちはIAM権限の最適化に継続的に取り組んでいます。改善のご提案がある場合は、[GitHub issue](https://github.com/aws-samples/eks-workshop-v2/issues)を作成してください。 + +::: + +画面の下部までスクロールして、IAM通知を承認してください： + +acknowledge IAM + +次に、**Create stack**ボタンをクリックします： + +Create Stack + +CloudFormationスタックのデプロイには約5分かかります。完了したら、**Outputs**タブから続行に必要な情報を取得できます： + +cloudformation outputs + +`IdeUrl`出力には、IDEにアクセスするためにブラウザに入力するURLが含まれています。`IdePasswordSecret`には、IDE用に生成されたパスワードを含むAWS Secrets Managerシークレットへのリンクが含まれています。 + +パスワードを取得するには、`IdePasswordSecret`URLを開き、**Retrieve**ボタンをクリックします： + +secretsmanager retrieve + +その後、パスワードをコピーできるようになります： + +password in Secrets Manager + +提供されたIDE URLを開くと、パスワードの入力を求められます： + +IDE password prompt + +パスワードを送信すると、最初のIDE画面が表示されます： + +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/fastpaths/setup/your-account/using-eksctl.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/setup/your-account/using-eksctl.md new file mode 100644 index 0000000000..86c4ca94dd --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/setup/your-account/using-eksctl.md @@ -0,0 +1,62 @@ +--- +title: eksctl を使用する +sidebar_position: 20 +pagination_next: fastpaths/navigating-labs +tmdTranslationSourceHash: '35b6089a346b6ed8dbdd09ac89809ae2' +--- + +このセクションでは、[eksctl ツール](https://eksctl.io/)を使用してラボ演習用のクラスターを構築する方法を説明します。これは最も簡単に始められる方法であり、ほとんどの学習者に推奨されます。 + +`eksctl` ユーティリティは、IDE 環境にプリインストールされているため、すぐにクラスターを作成できます。以下は、クラスターの構築に使用される設定です： + +::yaml{file="manifests/../cluster/eksctl/cluster-auto.yaml" paths="availabilityZones,metadata.name,autoModeConfig.nodePools" title="cluster.yaml"} + +1. 3つのアベイラビリティーゾーンにまたがる VPC を作成 +2. デフォルトで `eks-workshop-auto` という名前の EKS クラスターを作成 +3. EKS Auto Mode の組み込み NodePool を有効化 + + +以下のように設定ファイルを適用します： + +```bash +$ export EKS_CLUSTER_AUTO_NAME=eks-workshop-auto +$ curl -fsSL https://raw.githubusercontent.com/VAR::MANIFESTS_OWNER/VAR::MANIFESTS_REPOSITORY/VAR::MANIFESTS_REF/cluster/eksctl/cluster-auto.yaml | \ +envsubst | eksctl create cluster -f - +``` + +このプロセスは完了まで約 20 分かかります。 + +## 次のステップ + +クラスターの準備ができたら、「ラボのナビゲーション」セクションに進んで開始してください。 + +import Link from '@docusaurus/Link'; + +ラボのナビゲーションに進む → + +

+ +--- + +## クリーンアップ（ワークショップ全体の終了後） + +:::tip +以下は、EKS クラスターの使用が終了した後にリソースをクリーンアップする方法を示しています。これらの手順を完了すると、AWS アカウントへのさらなる課金を防ぐことができます。 +::: + +IDE 環境を削除する前に、前の手順で設定したクラスターをクリーンアップします。 + +まず、`delete-environment` を使用して、サンプルアプリケーションと残っているラボインフラストラクチャが削除されることを確認します： + +```bash +$ delete-environment +``` + +次に、`eksctl` でクラスターを削除します： + +```bash +$ eksctl delete cluster $EKS_CLUSTER_AUTO_NAME --wait +``` + +これで、IDE の[クリーンアップ](./cleanup.md)に進むことができます。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/setup/your-account/using-terraform.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/setup/your-account/using-terraform.md new file mode 100644 index 0000000000..a284a6ad79 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fastpaths/setup/your-account/using-terraform.md @@ -0,0 +1,11 @@ +--- +title: Terraformの使用 +sidebar_position: 30 +pagination_next: null +pagination_prev: null +tmdTranslationSourceHash: '5005866ee077e0e72a95ed7b550ef038' +--- + +:::danger +Terraformを使用したEKS Auto Modeクラスターの作成は現在サポートされていません。興味がある場合は、[GitHubリポジトリ](https://github.com/aws-samples/eks-workshop-v2/issues)にお知らせください。 +::: diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fundamentals/exposing/ingress/adding-ingress.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fundamentals/exposing/ingress/adding-ingress.md index 7dd0640039..4da683ca26 100644 --- a/website/i18n/ja/docusaurus-plugin-content-docs/current/fundamentals/exposing/ingress/adding-ingress.md +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fundamentals/exposing/ingress/adding-ingress.md @@ -1,7 +1,7 @@ --- title: "Ingressの作成" sidebar_position: 20 -tmdTranslationSourceHash: 55ba2d304b8961fd6c8455b49eb75f66 +tmdTranslationSourceHash: 75afb2bdcdabdcb4e4411b96e8001b6c --- 以下の構成で Ingress リソースを作成しましょう： @@ -9,13 +9,13 @@ tmdTranslationSourceHash: 55ba2d304b8961fd6c8455b49eb75f66 ::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 とそのターゲットグループを確認することもできます： diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fundamentals/exposing/ingress/external-dns.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fundamentals/exposing/ingress/external-dns.md index 4143f3ad94..0396e82190 100644 --- a/website/i18n/ja/docusaurus-plugin-content-docs/current/fundamentals/exposing/ingress/external-dns.md +++ b/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: 019f0b1b461fa8b8569fd792821c987d --- -[ExternalDNS](https://github.com/kubernetes-sigs/external-dns)はKubernetesコントローラーで、クラスターのサービスとイングレス用のDNSレコードを自動的に管理します。KubernetesリソースとAWS Route 53などのDNSプロバイダーとの間の橋渡しとして機能し、DNSレコードがクラスターの状態と同期されるようにします。ロードバランサーにDNSエントリを使用することで、自動生成されたホスト名の代わりに人間が読みやすく、覚えやすいアドレスを提供し、組織のブランディングに合わせたドメイン名でサービスを簡単にアクセスおよび認識できるようにします。 +[ExternalDNS](https://github.com/kubernetes-sigs/external-dns)はKubernetesコントローラーで、クラスターのサービスとIngressの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/ @@ -25,7 +25,7 @@ $ helm upgrade --install external-dns external-dns/external-dns --version "${DNS --wait ``` -ExternalDNSポッドが実行されていることを確認しましょう： +ExternalDNS Podが実行されていることを確認します： ```bash $ kubectl -n external-dns get pods @@ -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 @@ -54,7 +54,7 @@ NAME CLASS HOSTS ADDRESS ui alb ui.retailstore.com k8s-ui-ui-1268651632.us-west-2.elb.amazonaws.com 80 4m15s ``` -DNSレコードの作成を確認します。ExternalDNSは`retailstore.com`のRoute 53プライベートホストゾーンにDNSレコードを自動的に作成します。 +DNSレコードの作成を確認します。ExternalDNSは`retailstore.com` Route 53プライベートホストゾーンにDNSレコードを自動的に作成します。 :::note @@ -74,10 +74,10 @@ Desired change: CREATE ui.retailstore.com A -Route 53のプライベートホストゾーンは、関連付けられたVPC（この場合はEKSクラスターVPC）からのみアクセス可能です。DNSエントリをテストするために、ポッド内から`curl`を使用します： +Route 53プライベートホストゾーンは関連付けられたVPC（この場合はEKSクラスターVPC）からのみアクセス可能です。DNSエントリをテストするために、Pod内から`curl`を使用します： ```bash hook=dns-curl -$ kubectl -n ui exec -it \ +$ kubectl -n ui exec \ deployment/ui -- bash -c "curl -i http://ui.retailstore.com/actuator/health/liveness; echo" HTTP/1.1 200 OK diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fundamentals/exposing/ingress/multiple-ingress.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fundamentals/exposing/ingress/multiple-ingress.md index c8dc24fb41..7178176514 100644 --- a/website/i18n/ja/docusaurus-plugin-content-docs/current/fundamentals/exposing/ingress/multiple-ingress.md +++ b/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設定も確認できます： diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fundamentals/exposing/loadbalancer/adding-lb.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fundamentals/exposing/loadbalancer/adding-lb.md index 48989c12e6..f9ea8ef37c 100644 --- a/website/i18n/ja/docusaurus-plugin-content-docs/current/fundamentals/exposing/loadbalancer/adding-lb.md +++ b/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 リソースを再度確認してみましょう： diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/fundamentals/exposing/loadbalancer/ip-mode.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/fundamentals/exposing/loadbalancer/ip-mode.md index 10200ea149..134bf0e32f 100644 --- a/website/i18n/ja/docusaurus-plugin-content-docs/current/fundamentals/exposing/loadbalancer/ip-mode.md +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/fundamentals/exposing/loadbalancer/ip-mode.md @@ -1,7 +1,7 @@ --- title: "IPモード" sidebar_position: 40 -tmdTranslationSourceHash: b67d43544731909d6e1dd70f0bdca966 +tmdTranslationSourceHash: acc5b1f3e6086643730da5f893525689 --- 前述のように、作成したNLBは「インスタンスモード」で動作しています。インスタンスターゲットモードはAWS EC2インスタンス上で実行されているPodをサポートしています。このモードでは、AWS NLBはインスタンスにトラフィックを送信し、個々のワーカーノード上の`kube-proxy`がKubernetesクラスター内の1つ以上のワーカーノードを介してPodにトラフィックを転送します。 @@ -44,7 +44,7 @@ Service/ui-nlb kustomizeでマニフェストを適用します： ```bash -$ kubectl apply -k ~/environment/eks-workshop/modules/exposing/load-balancer/ip-mode +$ kubectl kustomize ~/environment/eks-workshop/modules/exposing/load-balancer/ip-mode | envsubst | kubectl apply -f - ``` ロードバランサーの構成が更新されるまで数分かかります。以下のコマンドを実行して、アノテーションが更新されたことを確認します： diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/basics/configuration/configmaps/index.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/basics/configuration/configmaps/index.md new file mode 100644 index 0000000000..74fdb609cf --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/basics/configuration/configmaps/index.md @@ -0,0 +1,121 @@ +--- +title: ConfigMaps +sidebar_position: 10 +tmdTranslationSourceHash: '235f6b1872d5a004ae5c9639a5e6438f' +--- + +# ConfigMaps + +**ConfigMaps** を使用すると、設定アーティファクトをイメージコンテンツから分離して、コンテナ化されたアプリケーションをポータブルに保つことができます。ConfigMaps は機密情報ではないデータをキーと値のペアで保存し、Pod は環境変数、コマンドライン引数、または設定ファイルとして使用できます。 + +ConfigMaps の利点： +- **設定管理:** アプリケーション設定をコードとは別に保存 +- **環境の柔軟性:** 異なる環境で異なる設定を使用 +- **実行時の更新:** コンテナイメージを再ビルドせずに設定を更新 +- **ポータビリティ:** 異なる環境間でアプリケーションをポータブルに保つ + +このラボでは、リテールストアの UI コンポーネント用に ConfigMap を作成し、バックエンドサービスへの接続方法を学びます。 + +### ConfigMap の作成 + +リテールストアの UI コンポーネント用の ConfigMap を作成しましょう。UI はバックエンドサービスの場所を知る必要があります： + +::yaml{file="manifests/base-application/ui/configMap.yaml" paths="kind,metadata.name,data" title="ui-configmap.yaml"} + +1. `kind: ConfigMap`: 作成するリソースのタイプを Kubernetes に指示します +2. `metadata.name`: namespace 内でこの ConfigMap を一意に識別します +4. `data`: 設定データを含むキーと値のペア + +ConfigMap の設定を適用します： +```bash +$ kubectl apply -k ~/environment/eks-workshop/modules/introduction/basics/configmaps/ +``` + +### ConfigMap の確認 + +次に、作成した ConfigMap を確認してみましょう： + +```bash +$ kubectl get configmaps -n ui +NAME DATA AGE +kube-root-ca.crt 1 2m51s +ui 4 2m50s +``` + +ConfigMap の詳細情報を取得します： +```bash +$ kubectl describe configmap ui -n ui +Name: ui +Namespace: ui +Labels: +Annotations: + +Data +==== +RETAIL_UI_ENDPOINTS_CARTS: +---- +http://carts.carts.svc:80 + +RETAIL_UI_ENDPOINTS_CATALOG: +---- +http://catalog.catalog.svc:80 + +RETAIL_UI_ENDPOINTS_CHECKOUT: +---- +http://checkout.checkout.svc:80 + +RETAIL_UI_ENDPOINTS_ORDERS: +---- +http://orders.orders.svc:80 + + +BinaryData +==== + +Events: +``` + +これにより以下が表示されます： +- **Data セクション** - ConfigMap に保存されているキーと値のペア +- **Labels** - 整理のためのメタデータタグ +- **Annotations** - 追加のメタデータ + +### Pod での ConfigMaps の使用 + +次に、ConfigMap を使用する Pod を作成しましょう。UI Pod を更新して設定を使用します： + +::yaml{file="manifests/modules/introduction/basics/configmaps/ui-pod-with-config.yaml" paths="spec.containers.0.envFrom" title="ui-pod-with-config.yaml"} + +1. `envFrom.configMapRef`: ConfigMap のすべてのキーと値のペアを環境変数としてロードします + +更新された Pod 設定を適用します： +```bash hook=ready +$ kubectl apply -f ~/environment/eks-workshop/modules/introduction/basics/configmaps/ui-pod-with-config.yaml +``` + +### 設定のテスト + +Pod が設定にアクセスできることを確認しましょう： + +```bash +$ kubectl exec -n ui ui-pod -- env | grep RETAIL_UI_ENDPOINTS_CATALOG +RETAIL_UI_ENDPOINTS_CATALOG=http://catalog.catalog.svc:80 +``` + +すべての ConfigMap 環境変数を確認することもできます： +```bash +$ kubectl exec -n ui ui-pod -- env | grep RETAIL_UI +RETAIL_UI_ENDPOINTS_CATALOG=http://catalog.catalog.svc:80 +RETAIL_UI_ENDPOINTS_CARTS=http://carts.carts.svc:80 +RETAIL_UI_ENDPOINTS_ORDERS=http://orders.orders.svc:80 +RETAIL_UI_ENDPOINTS_CHECKOUT=http://checkout.checkout.svc:80 +``` + +## 覚えておくべき重要なポイント + +* ConfigMaps は機密情報ではない設定データを保存します +* コンテナイメージから設定を分離します +* 環境変数として使用したり、ファイルとしてマウントしたりできます +* 異なる環境で同じイメージを動作させることができます +* ConfigMap ごとに 1MB のサイズ制限があります + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/basics/configuration/index.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/basics/configuration/index.md new file mode 100644 index 0000000000..e5820f409d --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/basics/configuration/index.md @@ -0,0 +1,69 @@ +--- +title: 設定 +sidebar_position: 50 +tmdTranslationSourceHash: '311c4e7d585f8c2bea7829df6cc153f6' +--- + +# 設定 + +アプリケーションは、API エンドポイントのような環境固有の設定から、データベースパスワードのような機密性の高い認証情報まで、設定データを必要とすることがよくあります。Kubernetes は設定データを管理するための 2 つのコアリソースを提供しています。 + +**ConfigMap** - 機密性のない設定データ用 +**Secret** - パスワード、トークン、証明書などの機密情報用 + +最近のアプリケーションは複数の環境で実行され、動的にスケールすることが多くなっています。 + +Kubernetes の設定リソースは、以下のことを可能にすることで、これを簡単にします。 +- **設定をコードから分離する** — 同じコンテナをどこにでもデプロイできるようにする +- **環境固有の設定を使用する** アプリケーションイメージを変更せずに +- **実行時に設定を更新する** イメージを再起動または再構築せずに +- **セキュリティを強化する** 機密性の高い値へのアクセスを制限することで +- **移植性を向上させる** クラスターやクラウドプロバイダー間で + +## ConfigMap と Secret の比較 + +| カテゴリ | ConfigMap | Secret | +| ------------------ | ------------------------------------------ | --------------------------------------------- | +| **目的** | 機密性のない設定を保存 | 機密データを保存 | +| **例** | API エンドポイント、機能フラグ、設定ファイル | パスワード、トークン、証明書 | +| **データ形式** | プレーンテキスト | Base64 エンコード | +| **可視性** | アクセス権を持つすべてのユーザーが読み取り可能 | RBAC によりアクセスが制限される | +| **セキュリティレベル** | 低 | 高 | + +## それぞれをいつ使用するか + +**ConfigMap の使用場面:** +- アプリケーション設定と機能フラグ +- サービス URL と API エンドポイント +- 設定ファイル（`nginx.conf`、`application.yaml`） +- 環境固有のパラメータ + +**Secret の使用場面:** +- データベース認証情報 +- API キーとトークン +- TLS 証明書と秘密鍵 +- コンテナレジストリの認証情報 + +## 設定パターン + +ConfigMap と Secret はどちらも、複数の方法で Pod から利用できます。 + +- **環境変数:** 環境変数として設定を注入 +- **ボリュームマウント:** コンテナファイルシステム内のファイルとして設定をマウント +- **コマンドライン引数:** コンテナコマンドの引数として設定を渡す + +## 設定管理を探る + +両方のタイプの設定データを管理する方法を学びます。 + +- **[ConfigMap](./configmaps)** - 機密性のない設定データの保存と管理 +- **[Secret](./secrets)** - パスワードや証明書などの機密情報を安全に扱う + +## 覚えておくべき重要なポイント + +* ConfigMap は機密性のない設定データを扱う +* Secret は機密情報を安全に保存する +* どちらも設定をアプリケーションコードから切り離す +* データの機密性に基づいて適切なリソースを選択する +* どちらも複数の利用パターン（環境変数、ファイル、引数）をサポートする + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/basics/configuration/secrets/index.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/basics/configuration/secrets/index.md new file mode 100644 index 0000000000..e70e7bd459 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/basics/configuration/secrets/index.md @@ -0,0 +1,153 @@ +--- +title: Secrets +sidebar_position: 20 +tmdTranslationSourceHash: '498d7a129e762c2cad7b7143f65b4f62' +--- + +# Secrets + +**Secrets**は、パスワード、OAuthトークン、SSHキー、TLS証明書などの機密情報を保存および管理するために使用されます。これらは、Pod仕様やコンテナイメージに直接記述するよりも、機密データを安全に扱う方法を提供します。 + +Secretsは以下を提供します： +- **セキュリティ：** 機密データをアプリケーションコードとは別に保存 +- **アクセス制御：** どのPodとユーザーが機密情報にアクセスできるかを制御 +- **暗号化：** データはbase64エンコードされ、保存時に暗号化可能 +- **柔軟性：** 環境変数、ファイル、またはイメージプルのためにSecretsを使用 + +このラボでは、小売店のカタログサービス用のデータベース認証情報を作成し、Podがこの機密情報に安全にアクセスする方法を学習します。 + +### 最初のSecretの作成 + +小売店のカタログサービス用のSecretを作成しましょう。カタログはMySQLデータベースに接続するためにデータベース認証情報が必要です： + +::yaml{file="manifests/base-application/catalog/secrets.yaml" paths="kind,metadata.name,data" title="catalog-secret.yaml"} + +1. `kind: Secret`：作成するリソースのタイプをKubernetesに指示 +2. `metadata.name`：Namespace内でこのSecretを一意に識別する名前 +5. `data`：機密データを含むキーと値のペア（base64エンコード済み） + +Secret設定を適用します： +```bash +$ kubectl apply -k ~/environment/eks-workshop/modules/introduction/basics/secrets +``` + +### Secretの確認 + +それでは、作成したSecretを確認しましょう： + +```bash +$ kubectl get secrets -n catalog +NAME TYPE DATA AGE +catalog-db Opaque 2 30s +``` + +Secretの詳細情報を取得します： +```bash +$ kubectl describe secret -n catalog catalog-db +Name: catalog-db +Namespace: catalog +Labels: +Annotations: + +Type: Opaque + +Data +==== +RETAIL_CATALOG_PERSISTENCE_PASSWORD: 16 bytes +RETAIL_CATALOG_PERSISTENCE_USER: 7 bytes +``` + +これは以下を示しています： +- **Type** - Secretの種類（汎用的な使用にはOpaque） +- **Data** - キーと値のペアの数（値はセキュリティのため非表示） +- **Labels** - 整理のためのメタデータタグ + +セキュリティ上の理由から、実際の値は表示されないことに注意してください。base64エンコードされたデータを確認するには： +```bash +$ kubectl get secret catalog-db -n catalog -o yaml +apiVersion: v1 +data: + RETAIL_CATALOG_PERSISTENCE_PASSWORD: ZFltTmZXVjR1RXZUem9GdQ== + RETAIL_CATALOG_PERSISTENCE_USER: Y2F0YWxvZw== +kind: Secret +metadata: + annotations: + kubectl.kubernetes.io/last-applied-configuration: | + {"apiVersion":"v1","data":{"RETAIL_CATALOG_PERSISTENCE_PASSWORD":"ZFltTmZXVjR1RXZUem9GdQ==","RETAIL_CATALOG_PERSISTENCE_USER":"Y2F0YWxvZw=="},"kind":"Secret","metadata":{"annotations":{},"name":"catalog-db","namespace":"catalog"}} + creationTimestamp: "2025-10-05T17:52:34Z" + name: catalog-db + namespace: catalog + resourceVersion: "902820" + uid: 726e4fef-f82b-4a7e-a063-f72f18a941cd +type: Opaque +``` + +データがbase64エンコードされていることがわかります。値をデコードするには： +```bash +$ kubectl get secret catalog-db -n catalog -o jsonpath='{.data.RETAIL_CATALOG_PERSISTENCE_USER}' | base64 --decode +catalog +``` + +### PodでのSecretsの使用 + +それでは、Secretを使用するPodを作成しましょう。カタログPodを更新してデータベース認証情報を使用します： + +::yaml{file="manifests/modules/introduction/basics/secrets/catalog-pod-with-secret.yaml" paths="kind,metadata.name,spec.containers,spec.containers.0.envFrom" title="catalog-pod-with-secret.yaml"} + +ここでの主な違いは： +- `envFrom.configMapRef`：ConfigMapからすべてのキーと値のペアを環境変数として読み込み +- `envFrom.secretRef`：Secretからすべてのキーと値のペアを環境変数として読み込み +- このアプローチは、個々のキーをマッピングせずにすべてのSecretデータを自動的に利用可能にします + +更新したPod設定を適用します： +```bash +$ kubectl apply -f ~/environment/eks-workshop/modules/introduction/basics/secrets/catalog-pod-with-secret.yaml +``` + +### Secretアクセスのテスト + +それでは、PodがSecret値にアクセスできることを確認しましょう： + +```bash hook=ready +$ kubectl exec -n catalog catalog-pod -- env | grep RETAIL_CATALOG_PERSISTENCE_USER +RETAIL_CATALOG_PERSISTENCE_USER=catalog_user +``` + +カタログ関連のすべての環境変数も確認できます： +```bash +$ kubectl exec -n catalog catalog-pod -- env | grep RETAIL_CATALOG +RETAIL_CATALOG_PERSISTENCE_PROVIDER=mysql +RETAIL_CATALOG_PERSISTENCE_ENDPOINT=catalog-mysql:3306 +RETAIL_CATALOG_PERSISTENCE_DB_NAME=catalog +RETAIL_CATALOG_PERSISTENCE_USER=catalog_user +RETAIL_CATALOG_PERSISTENCE_PASSWORD=dYmNfWV4uEvTzoFu +``` + +:::warning +本番環境では、パスワードをログやコンソール出力に出力することは避けてください。これは教育目的でのみ示されています。 +::: + +## SecretsとConfigMapsの比較 + +| Secrets | ConfigMaps | +|---------|------------| +| 機密データ（パスワード、トークン） | 非機密データ | +| base64エンコード + 追加のセキュリティ | 保存用にbase64エンコード | +| kubectl出力では値が非表示 | プレーンテキストで表示 | +| 認証情報、証明書、キー | 設定ファイル、環境変数 | + +## 高度なSecretsの管理 + +Kubernetes Secretsは機密データの基本的なセキュリティを提供しますが、本番環境ではより高度なシークレット管理ソリューションが必要になることがよくあります。自動ローテーション、きめ細かいアクセス制御、外部シークレットストアとの統合などの強化されたセキュリティ機能については、以下を参照してください： + +**[AWS Secrets Manager統合](../../../../security/secrets-management/secrets-manager/)** - 自動ローテーションと集中管理を備えたエンタープライズグレードのシークレット管理のために、AWS Secrets ManagerをEKSクラスターと統合する方法を学びます。 + +## 覚えておくべき重要なポイント + +* Secretsは機密データをアプリケーションコードとは別に保存します +* 値はbase64エンコードされ、保存時に暗号化可能です +* Secret値はセキュリティのためkubectl describeの出力では非表示になります +* 環境変数として使用するか、ファイルとしてマウントできます +* 非機密の設定データにはConfigMapsを使用します +* 本番ワークロードの場合、AWS Secrets Managerのような高度なソリューションの使用を検討してください + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/basics/index.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/basics/index.md new file mode 100644 index 0000000000..93962006b8 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/basics/index.md @@ -0,0 +1,89 @@ +--- +title: Kubernetes の基礎 +sidebar_position: 60 +sidebar_custom_props: { "module": true } +description: "アーキテクチャ、Helm、Kustomize を含む Kubernetes の基本的な概念を学びます。" +tmdTranslationSourceHash: d1fe31f35d924b01aa73fcb5e1885218 +--- + +# Kubernetes の概念 + +ハンズオンラボに入る前に、**Kubernetes がどのように機能するか**、そして**このワークショップを通じて使用するツール**を理解することが重要です。このセクションでは、EKS 学習の基礎となるコアアーキテクチャ、主要コンポーネント、デプロイメントツールを紹介します。 + +:::tip 始める前に +このセクションの環境を準備します: + +```bash timeout=300 wait=10 +$ prepare-environment introduction/basics +``` + +::: + +## Kubernetes アーキテクチャ概要 + +Kubernetes は **コントロールプレーンとワーカーノードのアーキテクチャ**に従っており、**コントロールプレーン**がクラスターを管理し、**ワーカーノード**がワークロードを実行します。 + +![Kubernetes Cluster Architecture](https://kubernetes.io/images/docs/kubernetes-cluster-architecture.svg) +*図: 簡略化された Kubernetes クラスターアーキテクチャ* + +### コントロールプレーンコンポーネント + +コントロールプレーンはクラスターに関するグローバルな決定を行い、システムの望ましい状態を保証します。 + +- **API Server** — Kubernetes のフロントエンドとして機能し、ユーザーとコンポーネントに Kubernetes API を公開します。 +- **etcd** — すべてのクラスターデータを保持する高可用性のキーバリューストアです。 +- **Scheduler** — リソースの可用性と制約に基づいて、Pod をノードに割り当てます。 +- **Controller Manager** — クラスターの健全性を維持し、実際の状態と望ましい状態を調整するバックグラウンドプロセス（コントローラー）を実行します。 + +### ワーカーノードコンポーネント + +各ノードは Pod をホストし管理するために必要なコンポーネントを実行します。 + +- **kubelet** — コントロールプレーンと通信し、コンテナが期待どおりに実行されていることを確認します。 +- **Container Runtime** — コンテナを実行します（例: containerd、CRI-O）。 +- **kube-proxy** — ネットワークルールを維持し、Pod とサービス間の通信を管理します。 + +--- + +## Amazon EKS アーキテクチャ + +**Amazon Elastic Kubernetes Service (EKS)** は、クラスター運用を簡素化するマネージド Kubernetes サービスです。 +コントロールプレーンの管理、アップグレード、高可用性を担当するため、ワークロードに集中できます。 + +EKS では以下が可能です: +- 運用オーバーヘッドを削減して**アプリケーションをより迅速にデプロイ** +- 変化するワークロードに対応するために**シームレスにスケール** +- AWS IAM とマネージドアップデートを使用して**セキュリティを強化** +- **コンピューティングモデルを選択** — 従来の EC2 ノードまたは EKS Auto Mode によるサーバーレス + +### 責任共有モデル + +Amazon EKS では: +- **AWS がコントロールプレーンを管理** — API Server、etcd、Scheduler、コントローラーを含みます。 +- **お客様がワーカーノードを管理** — アプリケーションが実行される EC2、Fargate、またはハイブリッドオプション。 +- **AWS サービスがネイティブに統合** — ロードバランサー、IAM ロール、VPC ネットワーキング、ストレージを含みます。 + +![Amazon EKS Architecture](https://docs.aws.amazon.com/images/eks/latest/userguide/images/whatis.png) +*図: Amazon EKS アーキテクチャと AWS サービスとの統合* + +## 覚えておくべき重要なポイント + +Kubernetes アーキテクチャを理解することは、効果的なクラスター管理とトラブルシューティングに不可欠です: + +### コントロールプレーン vs ワーカーノード +- **コントロールプレーン**コンポーネント（API Server、etcd、Scheduler、Controller Manager）は、クラスター全体の決定と状態管理を処理します +- **ワーカーノード**（kubelet、Container Runtime、kube-proxy）は、アプリケーションの実行とネットワーキングに重点を置いています +- この分離により、スケーラブルで回復力のあるクラスター運用が可能になります + +### EKS の利点 +- **運用負荷の軽減** — AWS がコントロールプレーンの複雑性、パッチ適用、高可用性を管理します +- **ネイティブな AWS 統合** — VPC、IAM、Load Balancers、その他の AWS サービスとのシームレスな接続 +- **柔軟なコンピューティングオプション** — ワークロードのニーズに基づいて EC2、Fargate、または Auto Mode から選択 + +### 設計原則 +- **宣言的な設定** — 望ましい状態を定義し、Kubernetes コントローラーがそれを達成するために動作します +- **API 駆動** — すべてのインタラクションは一貫性と監査可能性のために Kubernetes API を経由します +- **拡張可能** — カスタムリソースとコントローラーにより Kubernetes の機能を拡張できます + +これらのアーキテクチャの概念は、アプリケーションのデプロイ、Helm と Kustomize による設定管理、高度なクラスター機能の実装を進めていく上で不可欠です。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/basics/namespaces/index.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/basics/namespaces/index.md new file mode 100644 index 0000000000..6a9ee8b379 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/basics/namespaces/index.md @@ -0,0 +1,127 @@ +--- +title: Namespace +sidebar_position: 10 +tmdTranslationSourceHash: 509512e7f57ecd083a4d8cd800de1620 +--- + +# Namespace + +**Namespace** は、単一の Kubernetes クラスター内でリソースを整理し分離する方法を提供します。物理的なクラスター内の仮想クラスターのように考えることができます。これにより、同じ基盤インフラストラクチャを共有しながら、異なるアプリケーション、環境、またはチームを分離できます。 + +Namespace は、コンピューター上のフォルダーのようなものと考えることができます。関連するファイル（リソース）を混在させることなくグループ化できます。 + +Namespace は以下を提供します: +- **整理:** 関連するリソースをグループ化（アプリケーションのすべてのコンポーネントなど） +- **分離:** 異なるアプリケーションやチーム間でのリソースの競合を防止 +- **リソース管理:** 特定のリソースグループにクォータと制限を適用 +- **アクセス制御:** Kubernetes のパーミッション（RBAC — Role-Based Access Control と呼ばれる）を使用して、誰がリソースにアクセスしたり変更したりできるかを決定 + +このセクションでは、小売店アプリケーションのさまざまなコンポーネントを使用して、Namespace がリソースをどのように整理するかを探ります。 + +### デフォルトの Namespace +すべての Kubernetes クラスターは、いくつかの組み込み Namespace から始まります。これらは、クラスターがプロビジョニングされたときに自動的に作成されます: + +- **default** - Namespace を指定しない場合にリソースが配置される場所 +- **kube-system** - DNS やネットワーキングなどのシステムコンポーネント +- **kube-public** - 公開読み取り可能なリソース +- **kube-node-lease** - Node のハートビート情報 + +```bash +$ kubectl get namespaces +NAME STATUS AGE +default Active 1h +kube-node-lease Active 1h +kube-public Active 1h +kube-system Active 1h +``` + +### 最初の Namespace の作成 +小売店の UI コンポーネント用の Namespace を作成しましょう: + +::yaml{file="manifests/base-application/ui/namespace.yaml" paths="kind,metadata.name,metadata.labels" title="namespace.yaml"} + +1. `kind: Namespace`: 作成するリソースのタイプを Kubernetes に伝えます。 +2. `metadata.name`: クラスター内でこの Namespace の一意の識別子。 +3. `metadata.labels`: リソースを整理し分類するキーと値のペア。 + +`kubectl` を使用して設定ファイルを適用します +```bash +$ kubectl apply -f ~/environment/eks-workshop/base-application/ui/namespace.yaml +``` + +`kubectl create` コマンドを使用して直接 Namespace を作成することもできます。`catalog` サービス用の Namespace を作成し、ラベルを追加しましょう（ラベルはオプションですが、整理に役立ちます）: + +```bash +$ kubectl create namespace catalog +$ kubectl label namespace catalog app.kubernetes.io/created-by=eks-workshop +``` + +両方の Namespace を確認しましょう: +```bash +$ kubectl get namespaces -l app.kubernetes.io/created-by=eks-workshop +``` + +`-l` フラグは「ラベルセレクター」を表し、ラベルに基づいてリソースをフィルタリングします。この場合、`app.kubernetes.io/created-by=eks-workshop` というラベルを持つ Namespace のみを表示しています。これは、クラスター内のすべての Namespace の中から、このワークショップで作成されたリソースを見つけるのに役立ちます。 + +Namespace を詳しく見る +```bash +$ kubectl describe namespace ui +Name: ui +Labels: app.kubernetes.io/created-by=eks-workshop + kubernetes.io/metadata.name=ui +Annotations: +Status: Active + +No resource quota. + +No LimitRange resource. +``` + +### Namespace の使用 +リソースを操作する際、Namespace は 2 つの方法で指定できます: + +**`-n` フラグを使用:** +```bash +$ kubectl get all -n ui +``` + +**`--namespace` フラグを使用:** +```bash +$ kubectl get all --namespace ui +``` + + +ヒント: `-A` フラグを使用して、すべての Namespace のリソースを表示することもできます: + +```bash +$ kubectl get pods -A +``` + +### このワークショップでの Namespace +このワークショップでは、Namespace はサンプル小売店アプリケーションを構成するさまざまなマイクロサービスを分離するのに役立ちます。 + +- `ui` - フロントエンドユーザーインターフェース +- `catalog` - 商品カタログサービス +- `carts` - ショッピングカートサービス +- `checkout` - 注文処理サービス +- `orders` - 注文管理サービス + +ラボ全体を通じて、次のようなコマンドが表示されます: +```bash +$ kubectl get pods -n ui +$ kubectl get secrets -n catalog +``` + +この整理により、以下が容易になります: +* どのコンポーネントがどのサービスに属しているかを確認 +* 特定のサービスに設定を適用 +* 特定のサービス内の問題をトラブルシューティング + +## 覚えておくべき重要なポイント +* Namespace はリソースを整理し分離します +* 名前は Namespace 内で一意である必要があります +* ほとんどのリソースは Namespace に属し、一部はクラスター全体に存在します +* 一部のリソース（Node や PersistentVolume など）は Namespace に属さず、クラスターレベルで存在します +* 指定しない場合は default Namespace が使用されます +* リソースクォータとアクセス制御を有効にします + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/basics/pods/index.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/basics/pods/index.md new file mode 100644 index 0000000000..c0169b9045 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/basics/pods/index.md @@ -0,0 +1,230 @@ +--- +title: Pod +sidebar_position: 20 +tmdTranslationSourceHash: c90463a70c1082cf45b0350bbca20a02 +--- + +# Pod + +**Pod**はKubernetesにおける最小のデプロイ可能な単位です。Podは、ストレージ、ネットワーク、および実行方法の設定を共有する1つ以上のコンテナを表します。 + +Podが提供するもの: +- **コンテナのグループ化:** 通常、Podは単一のコンテナを実行しますが、データを共有したりlocalhost経由で通信する必要がある密結合な複数のコンテナを含めることができます。 +- **共有ネットワーク:** Pod内のすべてのコンテナは同じIPアドレスを共有します +- **共有ストレージ:** コンテナはPod内でボリュームを共有できます +- **ライフサイクル管理:** Pod内のコンテナは一緒に生き、一緒に終了します +- **一時的な性質:** Podは作成、破棄、再作成が可能です + +このラボでは、シンプルなサンプルPodを作成し、そのプロパティを調べることでPodについて学習します。 + +### Podの作成 + +Podがどのように機能するかを理解するために、シンプルなPodを作成しましょう。このマニフェストは、小売ストアのUIコンテナを実行するシンプルなPodを定義しています。 + +::yaml{file="manifests/modules/introduction/basics/pods/ui-pod.yaml" paths="kind,metadata.name,metadata.namespace,spec.containers,spec.containers.0.name,spec.containers.0.image,spec.containers.0.ports,spec.containers.0.env,spec.containers.0.resources" title="ui-pod.yaml"} + +1. `kind: Pod`: 作成するリソースのタイプをKubernetesに指示します +2. `metadata.name`: Namespace内でこのPodを一意に識別する名前 +3. `metadata.namespace`: Podが属するNamespace（ui Namespace） +4. `spec.containers`: Pod内で実行するコンテナを定義する配列 +5. `spec.containers.0.name`: 最初のコンテナの名前（ui） +6. `spec.containers.0.image`: ECR PublicレジストリのコンテナImage +7. `spec.containers.0.ports`: コンテナが公開するネットワークポート +8. `spec.containers.0.env`: コンテナの環境変数 +9. `spec.containers.0.resources`: CPUとメモリの割り当て設定 + +Pod設定を適用します: +```bash +$ kubectl apply -f ~/environment/eks-workshop/modules/introduction/basics/pods/ui-pod.yaml +``` + +Kubernetesは`ui` Namespace内にPodを作成し、コンテナImageのプルを開始します。 + +Podの準備が完了するまで待ちます: +```bash +$ kubectl wait --for=condition=Ready --timeout=60s -n ui pod/ui-pod +``` + +### Podの調査 + +次に、作成したPodを確認しましょう: + +```bash +$ kubectl get pods -n ui +NAME READY STATUS RESTARTS AGE +ui-pod 1/1 Running 0 30s +``` + +Podの詳細情報を取得します: +```bash +$ kubectl describe pod -n ui ui-pod +Name: ui-pod +Namespace: ui +Priority: 0 +Service Account: default +Node: ip-10-42-144-0.us-west-2.compute.internal/10.42.144.0 +Start Time: Sun, 05 Oct 2025 19:28:02 +0000 +Labels: app.kubernetes.io/component=service + app.kubernetes.io/name=ui +Annotations: +Status: Running +IP: 10.42.146.177 +IPs: + IP: 10.42.146.177 +Containers: + ui: + Container ID: containerd://01709a8abac99ce46842dda128752a68e828a485ee47f2094549fc00f9d71953 + Image: public.ecr.aws/aws-containers/retail-store-sample-ui:1.2.1 + Image ID: public.ecr.aws/aws-containers/retail-store-sample-ui@sha256:63a531dd3716cf9f6a3c7b54d65c39ce4de43cb23a613ac2933f2cb38aff86d7 + Port: 8080/TCP + Host Port: 0/TCP + State: Running + Started: Sun, 05 Oct 2025 19:28:03 +0000 + Ready: True + Restart Count: 0 + Limits: + memory: 1536Mi + Requests: + cpu: 250m + memory: 1536Mi + Environment: + JAVA_OPTS: -XX:MaxRAMPercentage=75.0 -Djava.security.egd=file:/dev/urandom + Mounts: + /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-68xdw (ro) +Conditions: + Type Status + PodReadyToStartContainers True + Initialized True + Ready True + ContainersReady True + PodScheduled True +Volumes: + kube-api-access-68xdw: + Type: Projected (a volume that contains injected data from multiple sources) + TokenExpirationSeconds: 3607 + ConfigMapName: kube-root-ca.crt + Optional: false + DownwardAPI: true +QoS Class: Burstable +Node-Selectors: +Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s + node.kubernetes.io/unreachable:NoExecute op=Exists for 300s +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal Scheduled 10s default-scheduler Successfully assigned ui/ui-pod to ip-10-42-144-0.us-west-2.compute.internal + Normal Pulled 10s kubelet Container image "public.ecr.aws/aws-containers/retail-store-sample-ui:1.2.1" already present on machine + Normal Created 10s kubelet Created container: ui + Normal Started 10s kubelet Started container ui +``` + +これには以下が表示されます: +- **コンテナの仕様** - Image、ポート、環境変数 +- **リソース使用量** - CPUとメモリのリクエスト/制限 +- **イベント** - Pod作成中に発生したこと +- **ステータス** - 現在の状態とヘルス + +Podのログを表示します: +```bash +$ kubectl logs -n ui ui-pod +Picked up JAVA_TOOL_OPTIONS: + + . ____ _ __ _ _ + /\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \ +( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \ + \\/ ___)| |_)| | | | | || (_| | ) ) ) ) + ' |____| .__|_| |_|_| |_\__, | / / / / + =========|_|==============|___/=/_/_/_/ + + :: Spring Boot :: (v3.4.4) + +2025-10-05T19:28:06.600Z INFO 1 --- [ main] c.a.s.u.UiApplication : Starting UiApplication v0.0.1-SNAPSHOT using Java 21.0.7 with PID 1 (/app/app.jar started by appuser in /app) +2025-10-05T19:28:06.658Z INFO 1 --- [ main] c.a.s.u.UiApplication : The following 1 profile is active: "prod" +2025-10-05T19:28:10.268Z INFO 1 --- [ main] i.o.i.s.a.OpenTelemetryAutoConfiguration : OpenTelemetry Spring Boot starter has been disabled + +2025-10-05T19:28:11.712Z INFO 1 --- [ main] o.s.b.a.e.w.EndpointLinksResolver : Exposing 4 endpoints beneath base path '/actuator' +2025-10-05T19:28:14.045Z INFO 1 --- [ main] o.s.b.w.e.n.NettyWebServer : Netty started on port 8080 (http) +2025-10-05T19:28:14.075Z INFO 1 --- [ main] c.a.s.u.UiApplication : Started UiApplication in 8.505 seconds (process running for 10.444) +``` + +> UIコンテナが起動しているのが確認できます。 + +Pod内でコマンドを実行します: +```bash hook=ready +$ kubectl exec -n ui ui-pod -- curl -s localhost:8080/actuator/health +{"status":"UP","groups":["liveness","readiness"]} +``` +これによりアプリケーションのステータスが返されます。 + +### Podへのアクセス + +ポートフォワーディングを使用して、ローカルマシンからPodにアクセスできます: +```bash test=false +$ kubectl port-forward -n ui ui-pod 8080:8080 +``` + +:::info +ポートフォワーディングは、ローカルポートをPod内のポートに一時的に接続し、ラップトップから直接アプリケーションにアクセスできるようにします。 +::: + +Workshop IDEでは、転送されたすべてのポートを表示するポップアップが表示されます。クリックしてブラウザでアプリケーションURLを開きます。 + +または、別のターミナルを開いてテストします: +```bash test=false +$ curl localhost:8080 +``` + +ブラウザで、小売ストアアプリケーションのランディングページが表示されます。 + +`CTRL+C`を押して`port-forward`セッションを終了します。 + +### Podの削除 + +Podが不要になったら、`kubectl delete`コマンドを使用して削除できます。Podを削除する方法はいくつかあります: + +**方法1: 名前で削除** +```bash +$ kubectl delete pod -n ui ui-pod +pod "ui-pod" deleted +``` + +**方法2: マニフェストファイルを使用して削除** +`ui-pod`を再作成してマニフェストファイルを使用して削除しましょう。 +```bash +$ kubectl apply -f ~/environment/eks-workshop/modules/introduction/basics/pods/ui-pod.yaml +$ kubectl delete -f ~/environment/eks-workshop/modules/introduction/basics/pods/ui-pod.yaml +pod "ui-pod" deleted +``` + +削除後、Podが消えたことを確認します: +```bash +$ kubectl get pods -n ui +No resources found in ui namespace. +``` + +:::warning +Podを直接削除すると、完全に消えます。Pod内のデータ（永続ボリュームに保存されていない限り）は失われます。本番環境では、Podは通常、必要に応じて自動的に再作成するDeploymentなどのコントローラーによって管理されます。 +::: + +### Podのライフサイクル + +Podには、クラスター内の現在の状態を反映する明確に定義されたライフサイクルフェーズがあります。 +- **Pending** - Podがスケジュールされ、コンテナが起動中です +- **Running** - 少なくとも1つのコンテナが実行中です +- **Succeeded** - すべてのコンテナが正常に完了しました +- **Failed** - 少なくとも1つのコンテナが失敗しました +- **Unknown** - Podの状態を判別できません + +Kubernetesコントローラーは継続的にPodの状態を監視し、目的のアプリケーションヘルスを維持するために（失敗したコンテナの再起動やPodの再作成などの）アクションを実行します。 + +## 覚えておくべき重要なポイント + +* PodはKubernetesにおける最小のデプロイ可能な単位です +* 通常は1つのコンテナを含みますが、複数含むこともできます +* Pod内でネットワークとストレージを共有します +* Podは一時的なものです - 作成されたり削除されたりします +* 通常、Deploymentなどのより高レベルのコントローラーによって管理されます + +:::info +実際のシナリオでは、Podを直接作成することはほとんどありません。代わりに、Deployment、ReplicaSet、JobなどのAPIリソースを使用して管理します。 +::: diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/basics/services/index.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/basics/services/index.md new file mode 100644 index 0000000000..b896e30ec1 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/basics/services/index.md @@ -0,0 +1,239 @@ +--- +title: Service +sidebar_position: 40 +tmdTranslationSourceHash: 7e89c1c4a77a0ed93376ebbcda1863c1 +--- + +# Service + +**Service** は、Pod にアクセスするための安定したネットワークエンドポイントを提供します。Pod は一時的なもので頻繁に作成/削除される可能性があるため、Service は信頼性の高い通信のために一貫した DNS 名と IP アドレスを提供します。 + +#### Service が重要な理由: +Pod は作成と削除を繰り返すため、クライアントは Pod に直接接続することができません。Service は以下を実現します: +- **安定したネットワーキングの提供:** Pod が変更されても IP と DNS 名は同じままです。 +- **負荷分散の提供:** 正常な Pod 間でリクエストを自動的に分散します +- **サービスディスカバリの実現:** 他のコンポーネントは名前で Service に到達できます +- **Pod の抽象化の提供:** クライアントは個々の Pod の IP を知る必要がありません +- **自動更新の処理:** Pod が作成または削除されるとエンドポイントを調整します + +このラボでは、小売ストアの catalog コンポーネントの Service を作成し、Service が Pod 間の通信をどのように実現するかを探ります。 + +### Service タイプ + +Kubernetes は、さまざまなユースケースに対応する異なる Service タイプを提供します: + +| タイプ | 目的 | アクセス | +|------|---------|--------| +| **ClusterIP** | クラスター内部通信 | クラスターのみ | +| **NodePort** | ノードポート経由の外部アクセス | 外部 | +| **LoadBalancer** | クラウドロードバランサー経由の外部アクセス | 外部 | +| **ExternalName** | 外部 DNS 名へのマッピング | 外部 | + +:::info +**LoadBalancer Service** に関する専用のラボは、このワークショップの後半で利用できます。そこでは、クラウドロードバランサーを使用して Service を外部に公開する方法を学習します。 +::: + +### Service の作成 + +小売ストアの UI Service を見てみましょう: + +::yaml{file="manifests/base-application/ui/service.yaml" paths="kind,metadata.name,spec.type,spec.ports,spec.selector" title="service.yaml"} + +1. `kind: Service`: Service リソースを作成します +2. `metadata.name`: Service の名前 (ui) +3. `spec.type`: Service タイプ (内部アクセス用の ClusterIP) +4. `spec.ports`: Service から Pod へのポートマッピング +5. `spec.selector`: どの Pod がトラフィックを受信するかを選択します + +Service をデプロイします: +```bash hook=ready +$ kubectl apply -k ~/environment/eks-workshop/modules/introduction/basics/services/ +``` + +### Service が Pod に接続する方法 + +Service は特定の Pod を直接認識しているわけではありません。代わりに、**ラベルセレクター**を使用して、トラフィックを受信すべき Pod を動的に検索します。これにより、柔軟で疎結合な関係が構築されます。 + +**仕組みは次のとおりです:** + +1. **Pod はラベルを持っています** - Pod を説明するキーと値のペア +2. **Service はセレクターを持っています** - Pod ラベルに一致する基準 +3. **Kubernetes が自動的に接続します** - セレクターに一致する Pod がエンドポイントになります + +UI Service でこれを実際に見てみましょう: + +```bash +# Service セレクターを確認 +$ kubectl get service -n ui ui -o jsonpath='{.spec.selector}' | jq +{ + "app.kubernetes.io/component": "service", + "app.kubernetes.io/instance": "ui", + "app.kubernetes.io/name": "ui" +} +``` + +次に、一致するラベルを持つ Pod を確認します: +```bash +# 一致するラベルを持つ Pod を検索 +$ kubectl get pod -n ui -l app.kubernetes.io/component=service -o jsonpath='{.items[0].metadata.labels}{"\n"}' | jq +{ + "app.kubernetes.io/component": "service", + "app.kubernetes.io/created-by": "eks-workshop", + "app.kubernetes.io/instance": "ui", + "app.kubernetes.io/name": "ui", + "pod-template-hash": "5989474687" +} +``` + +UI Pod が Service セレクターに一致するラベルを持っていることがわかります。これが、Service がどの Pod にトラフィックを送信すべきかを知る方法です。 + +**この関係は動的です:** +- 一致するラベルを持つ新しい Pod が起動すると、自動的に Service のエンドポイントになります +- Pod が削除されると、自動的に Service から削除されます +- Pod のラベルを変更すると、Service に追加または削除できます + +このラベルベースのシステムは以下を意味します: +- **Service は任意のワークロードコントローラーと連携します** (Deployment、StatefulSet など) +- **Pod は複数の Service に属することができます** 異なるセレクターに一致する場合 +- **Service は自動的に適応します** Pod がスケールアップまたはダウンするにつれて + +### Service の確認 + +Service のステータスを確認します: +```bash +$ kubectl get service -n ui +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +ui ClusterIP 172.20.83.84 80/TCP 15m +``` + +Service のエンドポイント (実際の Pod IP) を表示します: +```bash +$ kubectl get endpoints -n ui ui +NAME ENDPOINTS AGE +ui 10.42.1.15:8080 15m +``` +> これは、どの Pod がトラフィックを受信するかを示しています + +詳細な Service 情報を取得します: +```bash +$ kubectl describe service -n ui ui +Name: ui +Namespace: ui +Labels: app.kubernetes.io/component=service + app.kubernetes.io/created-by=eks-workshop + app.kubernetes.io/instance=ui + app.kubernetes.io/name=ui +Annotations: +Selector: app.kubernetes.io/component=service,app.kubernetes.io/instance=ui,app.kubernetes.io/name=ui +Type: ClusterIP +IP Family Policy: SingleStack +IP Families: IPv4 +IP: 172.16.88.252 +IPs: 172.16.88.252 +Port: http 80/TCP +TargetPort: http/TCP +Endpoints: 10.42.129.33:8080 +Session Affinity: None +Internal Traffic Policy: Cluster +Events: +``` + +### サービスディスカバリ + +Service は、DNS 名を通じた自動的なサービスディスカバリを実現します: + +**完全な DNS 名の形式:** +``` +..svc.cluster.local +``` + +**小売ストアからの例:** +- `ui.ui.svc.cluster.local` +- `catalog.catalog.svc.cluster.local` +- `carts.carts.svc.cluster.local` + +**同じ Namespace 内での短縮名:** +``` +# ui Namespace の Pod から +curl http://ui:80 + +# 異なる Namespace からは、完全な名前を使用します +curl http://ui.ui.svc.cluster.local:80 +``` + +### Service 通信のテスト + +テスト用の Pod を作成して、サービスディスカバリと通信をテストしてみましょう: + +```bash +# ネットワークテスト用のテスト Pod を作成 +$ kubectl run test-pod --image=curlimages/curl --restart=Never -- sleep 3600 +$ kubectl wait --for=condition=ready pod/test-pod --timeout=60s +``` + +```bash +# クラスター内から DNS 解決をテスト +$ kubectl exec test-pod -- nslookup ui.ui.svc.cluster.local +Server: 172.16.0.10 +Address: 172.16.0.10:53 + + +Name: ui.ui.svc.cluster.local +Address: 172.16.88.252 +``` + +```bash +# HTTP 通信をテスト (Web ページを表示) +$ kubectl exec test-pod -- curl -s http://ui.ui.svc.cluster.local/actuator/info | jq +{ + "pod": { + "name": "ui-6db5f6bd84-cx4mg" + } +} +``` + +### 負荷分散 + +Service は、セレクターに一致するすべての正常な Pod 間でトラフィックを自動的に分散します: + +**UI Deployment をスケールして負荷分散を確認します:** +```bash hook=replicas +$ kubectl scale deployment -n ui ui --replicas=3 +``` + +**Service のエンドポイントがどのように更新されるかを確認します:** +```bash +$ kubectl get endpoints -n ui ui +NAME ENDPOINTS AGE +ui 10.42.117.212:8080,10.42.129.33:8080,10.42.174.4:8080 11m +``` + +複数の Pod IP がエンドポイントとしてリストされていることがわかります - Service は、一致するラベルを持つため、新しい Pod を自動的に検出しました。 + +**負荷分散をテストします:** +```bash +# 複数のリクエストを実行して負荷分散の動作を確認 (1行) +$ for i in $(seq 1 5); do printf "Request %d:" "$i"; kubectl exec test-pod -- curl -s http://ui.ui.svc.cluster.local/actuator/info; echo; sleep 1; done +Request 1:{"pod":{"name":"ui-6db5f6bd84-xgpf4"}} +Request 2:{"pod":{"name":"ui-6db5f6bd84-cx4mg"}} +Request 3:{"pod":{"name":"ui-6db5f6bd84-7bq8w"}} +Request 4:{"pod":{"name":"ui-6db5f6bd84-7bq8w"}} +Request 5:{"pod":{"name":"ui-6db5f6bd84-cx4mg"}} +``` + +異なる Pod のホスト名にリクエストが分散されていることがわかり、Service がすべての一致する Pod 間で負荷分散を行っていることを示しています。 + +```bash +# テスト Pod をクリーンアップ +$ kubectl delete pod test-pod +``` + +## 覚えておくべき重要なポイント + +* Service は一時的な Pod に対して安定したネットワークエンドポイントを提供します +* ClusterIP Service はクラスター内部の通信を実現します +* Service はラベルセレクターを使用してターゲット Pod を検索します +* DNS 名は次のパターンに従います: service.namespace.svc.cluster.local +* Service は正常な Pod 間でトラフィックを自動的に負荷分散します +* ポートフォワーディングを使用してローカルで Service をテストします + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/basics/workload-management/daemonsets.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/basics/workload-management/daemonsets.md new file mode 100644 index 0000000000..9b77d9c367 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/basics/workload-management/daemonsets.md @@ -0,0 +1,123 @@ +--- +title: DaemonSets +sidebar_position: 33 +tmdTranslationSourceHash: e602c82c9b66ec1e69017d2ce84be22a +--- + +# DaemonSets + +**DaemonSets** は、クラスター内の**すべてのノード**（または一部のノード）で Pod のコピーが実行されることを保証します。ロギング、監視、ネットワークエージェントなど、すべてのノードで動作する必要があるシステムレベルのサービスに最適です。 + +主な利点： +- **すべてのノードをカバー** - ノードごとに 1 つの Pod +- **ノードに合わせて自動的にスケール** - 新しいノードには Pod が追加され、削除されたノードからは Pod が削除される +- **システムサービスを実行** - ロギング、監視、ネットワーキングに最適 +- **特定のノードをターゲット** - セレクターまたはアフィニティを使用 +- **ホストリソースへのアクセス** - ログ、メトリクス、システムファイルなど + +## DaemonSets を使用する場合 +DaemonSets は、すべてのノードまたは一部のノードで実行する必要があるサービスに最適です： +- **ログコレクター** - Fluentd、Filebeat、Fluent Bit +- **監視エージェント** - Node Exporter、Datadog エージェント、New Relic +- **ネットワークプラグイン** - CNI プラグイン、ロードバランサーコントローラー +- **セキュリティエージェント** - アンチウイルススキャナー、コンプライアンスツール +- **ストレージデーモン** - 分散ストレージエージェント + +## DaemonSet のデプロイ + +すべてのノードで実行され、ホストファイルシステムからログを収集するシンプルなログコレクター DaemonSet を作成しましょう： + +::yaml{file="manifests/modules/introduction/basics/daemonsets/log-collector.yaml" paths="kind,metadata.name,spec.selector,spec.template.spec.containers.0.volumeMounts,spec.template.spec.volumes" title="log-collector.yaml"} + +1. `kind: DaemonSet`: DaemonSet コントローラーを作成 +2. `metadata.name`: DaemonSet の名前（`log-collector`） +3. `spec.selector`: DaemonSet が Pod を見つける方法（ラベルによる） +4. `spec.template.spec.containers.0.volumeMounts`: コンテナがノードファイルにアクセスする方法 +5. `spec.template.spec.volumes`: ノードログにアクセスするためのホストパス + +DaemonSet の主な特徴： +- `replicas` フィールドがない - Kubernetes は自動的にノードごとに 1 つの Pod を実行 +- ノードが追加または削除されると、Pod が自動的にスケール +- 必要に応じて、`hostPath` ボリュームを使用して Pod がノードファイルにアクセス可能 +- 通常はシステムサービス用に `kube-system` namespace にデプロイされますが、他の namespace でも実行可能 + +DaemonSet をデプロイします： +```bash +$ kubectl apply -f ~/environment/eks-workshop/modules/introduction/basics/daemonsets/log-collector.yaml +``` + +## DaemonSet の検査 + +DaemonSet のステータスを確認： +```bash +$ kubectl get daemonset -n kube-system +NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE AGE +log-collector 3 3 3 3 3 2m +``` +> 期待される Pod と現在の Pod を示す出力が表示されます： + +すべてのノードで Pod を確認： +```bash +$ kubectl get pods -n kube-system -l app=log-collector -o wide +NAME READY STATUS NODE AGE +log-collector-abc12 1/1 Running ip-10-42-1-1 2m +log-collector-def34 1/1 Running ip-10-42-2-1 2m +log-collector-ghi56 1/1 Running ip-10-42-3-1 2m +``` +> ノードごとに 1 つの Pod があることに注目してください + +## ノードの選択 + +nodeSelector を使用して特定のノードをターゲットにします： + +```yaml +spec: + template: + spec: + nodeSelector: + node-type: worker + containers: + - name: monitoring-agent + image: monitoring:latest +``` + +より複雑なルールには nodeAffinity を使用します： + +```yaml +spec: + template: + spec: + affinity: + nodeAffinity: + requiredDuringSchedulingIgnoredDuringExecution: + nodeSelectorTerms: + - matchExpressions: + - key: kubernetes.io/arch + operator: In + values: + - amd64 +``` +シンプルなラベルマッチには nodeSelector を、より複雑なスケジューリング要件には nodeAffinity を使用します。 + +## DaemonSets と他のコントローラーの比較 + +| コントローラー | 目的 | レプリカ数 | ノード配置 | ユースケース | +|------------|---------|---------------|----------------|----------| +| DaemonSet | ノードごとに 1 つの Pod | 自動 | すべてのノードまたは一部 | システムサービス | +| Deployment | 複数の交換可能な Pod | 設定可能 | 任意のノード | ステートレスアプリ | +| StatefulSet | 安定したアイデンティティを持つ Pod | 設定可能 | 任意のノード | ステートフルアプリ | + +:::info +DaemonSets は、すべてのノードまたは特定のノードセットで実行する必要があるサービスに最適です。 +::: + +## 覚えておくべき重要なポイント + +* DaemonSets は自動的にノードごとに 1 つの Pod を実行 +* ロギングや監視などのシステムレベルのサービスに最適 +* レプリカ数を指定する必要がない - 自動的に決定される +* hostPath ボリュームを通じてノードリソースにアクセス可能 +* ノードセレクターを使用して特定のノードをターゲット化 +* ノードが参加/離脱すると、Pod が自動的に追加/削除される +* すべてのノードで一貫したシステム機能を実現するのに最適 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/basics/workload-management/deployments.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/basics/workload-management/deployments.md new file mode 100644 index 0000000000..28f5dda2d4 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/basics/workload-management/deployments.md @@ -0,0 +1,121 @@ +--- +title: Deployment +sidebar_position: 31 +tmdTranslationSourceHash: af538f5b1df8835fc8714ea2de6b80a5 +--- + +# Deployment + +**Deployment**は、ステートレスアプリケーションを実行するための最も一般的なワークロードコントローラーです。Deploymentは、アプリケーションが常に希望する数のPodを実行することを保証し、作成、スケーリング、更新、復旧を自動的に処理します。 + +Podを手動で管理する代わりに、DeploymentによってKubernetesは以下を実行できます： +- **複数の同一Podを実行** - 信頼性と負荷分散のため +- **自動的にスケール** - レプリカ数を調整することで +- **失敗したPodを復旧** - 手動介入なしで +- **ローリング更新を実行** - ダウンタイムなしで +- **簡単にロールバック** - 問題があった場合、以前のバージョンに戻す + +### Deploymentの作成 + +Deploymentを使用して小売ストアのUIをデプロイしましょう： + +::yaml{file="manifests/base-application/ui/deployment.yaml" paths="kind,metadata.name,spec.replicas,spec.selector,spec.template" title="deployment.yaml"} + +1. `kind: Deployment`: Deploymentコントローラーを定義 +2. `metadata.name`: Deploymentの名前（ui） +3. `spec.replicas`: 希望するPod数（この例では1） +4. `spec.selector`: 管理されるPodを見つけるために使用されるラベル +5. `spec.template`: 各Podがどのように見えるべきかを定義するPodテンプレート + +Deploymentは、実際のPodが常にこのテンプレートと一致することを保証します。 + +Deploymentを適用します： +```bash +$ kubectl apply -k ~/environment/eks-workshop/base-application/ui +``` + +### Deploymentの確認 + +Deploymentのステータスを確認します： +```bash +$ kubectl get deployment -n ui +NAME READY UP-TO-DATE AVAILABLE AGE +ui 1/1 1 1 30s +``` + +Deploymentによって作成されたPodをリストします： +```bash +$ kubectl get pods -n ui +NAME READY STATUS RESTARTS AGE +ui-6d5bb7b9c8-xyz12 1/1 Running 0 30s +``` + +詳細情報を取得します： +```bash +$ kubectl describe deployment -n ui ui +``` + +### Deploymentのスケーリング + +5つのレプリカにスケールアップします： +```bash +$ kubectl scale deployment -n ui ui --replicas=5 +$ kubectl get pods -n ui +NAME READY STATUS RESTARTS AGE +ui-6d5bb7b9c8-abc12 1/1 Running 0 2m +ui-6d5bb7b9c8-def34 1/1 Running 0 12s +ui-6d5bb7b9c8-ghi56 1/1 Running 0 12s +ui-6d5bb7b9c8-arx97 1/1 Running 0 10s +ui-6d5bb7b9c8-uiv85 1/1 Running 0 10s +``` + +:::info +Kubernetesは、高可用性のためにこれらのPodを利用可能なワーカーノード全体に自動的に分散します。 +::: + +3つのレプリカにスケールダウンします： +```bash +$ kubectl scale deployment -n ui ui --replicas=3 +$ kubectl get pods -n ui +NAME READY STATUS RESTARTS AGE +ui-6d5bb7b9c8-abc12 1/1 Running 0 2m +ui-6d5bb7b9c8-def34 1/1 Running 0 12s +ui-6d5bb7b9c8-ghi56 1/1 Running 0 12s +``` + +### ローリング更新とロールバック +イメージバージョンを変更することでDeploymentを更新できます： +```bash +$ kubectl set image deployment/ui ui=public.ecr.aws/aws-containers/retail-store-sample-ui:v2 -n ui +$ kubectl get pods -n ui +NAME READY STATUS RESTARTS AGE +ui-5989474687-5gcbt 1/1 Running 0 13m +ui-5989474687-dhk6q 1/1 Running 0 14s +ui-5989474687-dw8x8 1/1 Running 0 14s +ui-7c65b44b7c-znm9c 0/1 ErrImagePull 0 7s +``` +> 新しいPodが作成されましたが、ステータスが`ErrImagePull`になっています。 + +それでは変更をロールバックしましょう： +```bash +$ kubectl rollout undo deployment/ui -n ui +$ kubectl get pods -n ui +NAME READY STATUS RESTARTS AGE +ui-5989474687-5gcbt 1/1 Running 0 13m +ui-5989474687-dhk6q 1/1 Running 0 14s +ui-5989474687-dw8x8 1/1 Running 0 14s +``` + +ローリング更新により、ダウンタイムなしでアプリケーションを段階的に更新でき、Kubernetesは新しいPodが希望する状態と一致することを保証します。 +無効なイメージなど問題が発生した場合は、以前の動作しているバージョンに安全にロールバックでき、アプリケーションの可用性を維持し、安定性を保つことができます。 + +これは、Deploymentがアプリケーションの更新を簡素化し、可用性を維持し、本番環境でのリスクを軽減する方法を示しています。 + +### 覚えておくべき重要なポイント + +* Deploymentは複数の同一Podを自動的に管理します +* 本番環境では、Podを直接作成する代わりにDeploymentを使用します +* スケーリングは、レプリカ数を変更するだけで簡単にできます +* Pod名にはDeployment名とランダムなサフィックスが含まれます +* Deploymentは、WebアプリやAPIなどのステートレスアプリケーションに最適です + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/basics/workload-management/index.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/basics/workload-management/index.md new file mode 100644 index 0000000000..85d67edc4f --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/basics/workload-management/index.md @@ -0,0 +1,117 @@ +--- +title: ワークロード管理 +sidebar_position: 30 +tmdTranslationSourceHash: 51ffa41aa96c321ca5f0831c38641a08 +--- + +# ワークロード管理 +個々の Pod を直接作成することもできますが、本番環境では Pod を手動で管理することはほとんどありません。代わりに、**ワークロードコントローラー**を使用します。これは、さまざまなアプリケーションパターンに応じて Pod を作成・管理する上位レベルの Kubernetes リソースです。 + +ワークロードコントローラーは、以下のような賢いマネージャーと考えてください： +- 定義したテンプレートに基づいて **Pod を作成** +- **Pod の健全性を監視**し、障害が発生したインスタンスを置き換え +- 需要に応じて**スケーリング**を処理 +- ローリングデプロイメントのような戦略で**更新を管理** +- さまざまなアプリケーションタイプに対して**特化した動作を提供** + +## ワークロードコントローラーの種類 +Kubernetes は、特定のユースケース向けに設計されたいくつかのワークロードコントローラーを提供しています： + +- **Deployment** は、ステートレスアプリケーション向けに複数の同一 Pod を管理します。スケーリング、ローリングアップデート、障害が発生した Pod の自動置換を処理します。任意の Pod が任意のリクエストを処理できる Web アプリケーションに最適です。 +- **ReplicaSet** は、指定された数の同一 Pod が常に実行されていることを保証します。ReplicaSet を直接作成することはほとんどありませんが、Deployment が Pod を管理するために内部で使用する構成要素です。 +- **StatefulSet** は、ステートフルアプリケーション向けに安定したアイデンティティと永続的ストレージを提供します。各 Pod は一意の名前（`mysql-0`、`mysql-1` など）と独自の Persistent Volume を取得します。データベースやクラスター化されたアプリケーションに不可欠です。 +- **DaemonSet** は、各ノード（または選択されたノード）で正確に 1 つの Pod が実行されることを保証します。ログコレクターや監視エージェントなど、クラスター内のあらゆる場所で実行する必要があるシステムレベルのサービスに最適です。 +- **Job** は、Pod が正常に完了するまで実行し、その後停止します。他のコントローラーとは異なり、完了した Pod を再起動しません。データ移行やバッチ処理などの一度きりのタスクに最適です。 +- **CronJob** は、使い慣れた cron 構文を使用してスケジュールに従って Job を作成します。バックアップ、レポート生成、クリーンアップ操作などの定期的なタスクに最適です。 + +## コントローラー階層の理解 + +これらのコントローラーがどのように関連しているかを理解することは役立ちます： + +**Deployment → ReplicaSet → Pod** + +Deployment を作成すると、以下のことが起こります： +1. **Deployment** が ReplicaSet を作成・管理 +2. **ReplicaSet** が実際の Pod を作成・管理 +3. **Pod** がアプリケーションコンテナを実行 + +この階層的なアプローチにより、強力な機能が実現されます： +- **ローリングアップデート**: Deployment は古い ReplicaSet を徐々にスケールダウンしながら新しい ReplicaSet を作成 +- **ロールバック**: Deployment は以前の ReplicaSet バージョンに戻すことが可能 +- **スケーリング**: レプリカ数の変更が ReplicaSet を通じて Pod に伝播 + +デバッグ時に ReplicaSet を見ることがよくありますが（`kubectl get rs` など）、通常は Deployment を通じて間接的に管理します。 + +### ワークロードコントローラーを使用する理由 + +**Pod を直接管理する場合：** +- 障害時の手動での Pod 置換 +- 組み込みのスケーリングメカニズムがない +- 複雑な更新手順 +- ロールバック機能がない +- 本番環境での管理が困難 + +**ワークロードコントローラーを使用する場合：** +- Pod の自動置換と自己修復 +- 単一のコマンドで簡単にスケーリング +- ダウンタイムなしのローリングアップデート +- 以前のバージョンへの簡単なロールバック +- 本番環境に対応した管理 + +| コントローラー | 目的 | 最適な用途 | +|------------|---------|----------| +| **Deployment** | ステートレスアプリケーション | Web アプリ、API、マイクロサービス | +| **ReplicaSet** | Pod レプリカの維持 | 通常は Deployment によって管理 | +| **StatefulSet** | ステートフルアプリケーション | データベース、メッセージキュー | +| **DaemonSet** | ノードレベルサービス | ロギングエージェント、監視 | +| **Job** | 完了まで実行するタスク | データ移行、バッチ処理 | +| **CronJob** | スケジュールされたタスク | バックアップ、レポート、クリーンアップ | + +### 適切なワークロードコントローラーの選択 + +適切なコントローラーを選択するために、以下の質問を自問してください： + +**どのようなタイプのアプリケーションを実行していますか？** + +- **Web アプリ、API、またはマイクロサービス？** → **Deployment** を使用 + - Pod は交換可能でステートレス + - 複数の同一コピーを実行可能 + - 例：小売ストアの UI、カタログサービス + +- **データベースまたはメッセージキュー？** → **StatefulSet** を使用 + - 永続的ストレージが必要 + - 安定したネットワークアイデンティティが必要 + - 例：MySQL データベース、Kafka クラスター + +- **すべてのノードで実行するシステムサービス？** → **DaemonSet** を使用 + - 監視、ロギング、またはネットワーキング + - ノードごとに自動的に 1 つの Pod + - 例：ログコレクター、ノード監視 + +- **一度きりのタスクまたはバッチジョブ？** → **Job** を使用 + - 完了まで実行 + - データベース移行、データ処理 + - 例：製品カタログのインポート + +- **定期的にスケジュールされたタスク？** → **CronJob** を使用 + - スケジュールに従って実行（cron のように） + - バックアップ、レポート、クリーンアップ + - 例：日次売上レポートの生成 + +## 覚えておくべき重要なポイント + +* さまざまなワークロードコントローラーが、異なるアプリケーションパターンに対応 +* Deployment は、同一のレプリカを持つことができるステートレスアプリケーション向け +* StatefulSet は、永続的なアイデンティティが必要なステートフルアプリケーション向け +* DaemonSet は、システムレベルサービスのためにすべてのノードで Pod を実行 +* Job はタスクを完了まで実行、CronJob はスケジュールに従って実行 +* アプリケーションの要件に基づいて適切なコントローラーを選択 + +## 各ワークロードタイプを探索 + +ワークロードコントローラーの概要を理解したところで、各タイプについてさらに深く掘り下げてみましょう： + +- **[Deployment](./deployments)** - 小売ストア UI のようなステートレスアプリケーションのデプロイと管理を学習 +- **[StatefulSet](./statefulsets)** - 永続的ストレージを持つデータベースのようなステートフルアプリケーションの実行方法を理解 +- **[DaemonSet](./daemonsets)** - すべてのノードで実行されるシステムレベルサービスを探索 +- **[Job & CronJob](./jobs)** - バッチ処理とスケジュールされたタスクをマスター diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/basics/workload-management/jobs.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/basics/workload-management/jobs.md new file mode 100644 index 0000000000..eefb30757b --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/basics/workload-management/jobs.md @@ -0,0 +1,406 @@ +--- +title: Jobs & CronJobs +sidebar_position: 34 +tmdTranslationSourceHash: d6e15ee9dd1af39ed725bcf68f498595 +--- + +# Jobs & CronJobs + +**Jobs**と**CronJobs**は、**有限または定期的なタスク**を実行するためのコントローラーです。Podを継続的に実行し続けるDeploymentやStatefulSetとは異なり、Jobsはタスクを完了まで実行し、CronJobsはスケジュールに従ってJobsを実行します。 + +主な利点: +- **完了まで実行** - Podはタスクを完了して停止します +- **失敗したタスクの再試行** - バックオフポリシーに基づいて自動的に再試行します +- **並列実行** - 複数のPodを同時に実行できます +- **スケジュールされたタスク** - CronJobsは特定の時刻にタスクを実行します +- **履歴の追跡** - 成功および失敗した完了を監視します + +## JobsとCronJobsを使用する場合 + +**Jobsを使用する場合:** +- データベースのマイグレーションとスキーマの更新 +- データ処理とETL操作 +- 1回限りのセットアップタスクと初期化 +- バックアップ操作とファイル処理 + +**CronJobsを使用する場合:** +- 定期的なバックアップ（毎日、毎週） +- クリーンアップタスクとログのローテーション +- レポート生成とデータの同期 +- 定期的なヘルスチェックと監視 + +## Jobのデプロイ + +データ処理Jobを作成しましょう: + +::yaml{file="manifests/modules/introduction/basics/jobs/data-processing-job.yaml" paths="kind,metadata.name,spec.completions,spec.backoffLimit,spec.template.spec.restartPolicy" title="data-processing-job.yaml"} + +1. `kind: Job`: Jobコントローラーを作成します +2. `metadata.name`: Jobの名前（data-processor） +3. `spec.completions`: 必要な成功完了数（1） +4. `spec.backoffLimit`: 最大再試行回数（3） +5. `spec.template.spec.restartPolicy`: Podは失敗時に再起動しません。Jobコントローラーが再試行を処理します + +Jobをデプロイします: +```bash +$ kubectl apply -f ~/environment/eks-workshop/modules/introduction/basics/jobs/data-processing-job.yaml +``` + +## Jobの検査 + +Jobのステータスを確認します: +```bash +$ kubectl get jobs -n catalog +NAME COMPLETIONS DURATION AGE +data-processor 1/1 15s 1m +``` + +JobのPodを表示します: +```bash +$ kubectl get pods -n catalog -l job-name=data-processor +NAME READY STATUS RESTARTS AGE +data-processor-h7mg7 0/1 Completed 0 25s +``` + +Jobが完了するのを待ちます: +```bash +$ kubectl wait --for=condition=complete --timeout=60s job/data-processor -n catalog +``` + +Jobのログを確認して処理出力を確認します: +```bash +$ kubectl logs -n catalog job/data-processor +Starting data processing job... +Processing catalog data files... +Processing file 1/5... +File 1 processed successfully +... +Data processing job completed successfully! +``` + +Jobの詳細情報を取得します: +```bash +$ kubectl describe job -n catalog data-processor +Name: data-processor +Namespace: catalog +Selector: batch.kubernetes.io/controller-uid=639c46e3-ee04-4914-8c97-516a14087c1d +Labels: app.kubernetes.io/created-by=eks-workshop + app.kubernetes.io/name=data-processor +Annotations: +Parallelism: 1 +Completions: 1 +Completion Mode: NonIndexed +Suspend: false +Backoff Limit: 3 +Start Time: Sun, 05 Oct 2025 18:51:01 +0000 +Completed At: Sun, 05 Oct 2025 18:51:14 +0000 +Duration: 13s +Pods Statuses: 0 Active (0 Ready) / 1 Succeeded / 0 Failed +Pod Template: + Labels: app=data-processor + batch.kubernetes.io/controller-uid=639c46e3-ee04-4914-8c97-516a14087c1d + batch.kubernetes.io/job-name=data-processor + controller-uid=639c46e3-ee04-4914-8c97-516a14087c1d + job-name=data-processor + Containers: + processor: + Image: busybox:1.36 + Port: + Host Port: + Command: + /bin/sh + -c + echo "Starting data processing job..." + echo "Processing catalog data files..." + + # Simulate processing multiple files + for i in $(seq 1 5); do + echo "Processing file $i/5..." + sleep 2 + echo "File $i processed successfully" + done + + echo "Generating summary report..." + cat > /tmp/processing-report.txt << EOF + Data Processing Report + ===================== + Job: data-processor + Date: $(date) + Files processed: 5 + Status: Completed successfully + EOF + + echo "Report generated:" + cat /tmp/processing-report.txt + echo "Data processing job completed successfully!" + + Limits: + cpu: 200m + memory: 256Mi + Requests: + cpu: 100m + memory: 128Mi + Environment: + Mounts: + Volumes: + Node-Selectors: + Tolerations: +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal SuccessfulCreate 60s job-controller Created pod: data-processor-h7mg7 + Normal Completed 47s job-controller Job completed +``` + +## CronJobのデプロイ + +1分ごとに実行されるクリーンアップCronJobを作成しましょう: + +::yaml{file="manifests/modules/introduction/basics/jobs/catalog-cleanup.yaml" paths="kind,metadata.name,spec.schedule,spec.jobTemplate" title="catalog-cleanup.yaml"} + +1. `kind: CronJob`: CronJobコントローラーを作成します +2. `metadata.name`: CronJobの名前（`catalog-cleanup`） +3. `spec.schedule`: cronスケジュール（`*/1 * * * *` = 1分ごと） +4. `spec.jobTemplate`: 作成されるJobsのテンプレート + +CronJobをデプロイします: +```bash +$ kubectl apply -f ~/environment/eks-workshop/modules/introduction/basics/jobs/catalog-cleanup.yaml +``` + +## CronJobsの管理 + +CronJobsを表示します: +```bash +$ kubectl get cronjobs -n catalog +NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE +catalog-cleanup */1 * * * * False 0 30s +``` + +最初は、CronJobがまだ実行されていないため、`LAST SCHEDULE`には``と表示されます。CronJobは1分ごとに実行されますが、すぐに動作を確認するために手動でトリガーしましょう: + +```bash +# CronJobを手動でトリガーしてすぐに動作を確認します +$ kubectl create job --from=cronjob/catalog-cleanup manual-cleanup -n catalog +``` + +次に、CronJobによって作成されたJobsを表示します: +```bash +$ kubectl get jobs -n catalog +NAME STATUS COMPLETIONS DURATION AGE +data-processor Complete 1/1 13s 17m +manual-cleanup Running 0/1 5s 5s +``` + +ログを確認する前に、JobのPodが実行中になるのを待ちます: +```bash +$ kubectl wait --for=jsonpath='{.status.phase}'=Running pod -l job-name=manual-cleanup -n catalog --timeout=60s +``` + +Job実行のログを確認します: +```bash +$ kubectl logs job/manual-cleanup -n catalog +Starting cleanup job at Mon Oct 5 17:30:00 UTC 2025 +Checking for temporary files... +Found 3 temporary files to clean up: + - /tmp/cache_file_1.tmp + - /tmp/cache_file_2.tmp + - /tmp/old_log.log +Cleaning up temporary files... +Temporary files removed successfully +Cleanup completed at Mon Oct 5 17:30:05 UTC 2025 +Next cleanup scheduled in 1 minute +``` + +CronJobが自動的に実行されるのを待ちます（または1分後に確認します）: +```bash +# CronJobが自動的に実行されたかどうかを確認します +$ kubectl get cronjobs -n catalog +NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE +catalog-cleanup */1 * * * * False 0 30s 2m +``` + +名前空間内のすべてのJobsを表示します（CronJobsによって作成されたものを含む）: +```bash +$ kubectl get jobs -n catalog +NAME STATUS COMPLETIONS DURATION AGE +catalog-cleanup-29328191 Complete 1/1 9s 114s +catalog-cleanup-29328192 Complete 1/1 9s 54s +data-processor Complete 1/1 13s 21m +manual-cleanup Complete 1/1 10s 56s +``` + +特定のCronJobによって作成されたJobsを確認するには、CronJob名で始まるJobsを探します: +```bash hook=cronjob-first-run +$ kubectl get jobs -n catalog | grep catalog-cleanup +catalog-cleanup-29328192 Complete 1/1 9s 74s +catalog-cleanup-29328193 Complete 1/1 8s 14s +``` + +Jobの所有者参照を確認して、どのCronJobがそれを作成したかを確認することもできます: +```bash +$ kubectl get job manual-cleanup -n catalog -o yaml | grep -A 5 ownerReferences + ownerReferences: + - apiVersion: batch/v1 + controller: true + kind: CronJob + name: catalog-cleanup + uid: 7f2deb86-a5c7-4703-ac5e-c5dd4893ff23 +``` + +手動Jobをクリーンアップします: +```bash +$ kubectl delete job manual-cleanup -n catalog +``` + +### CronJob実行の監視 + +CronJobのステータスと履歴を確認します: +```bash +$ kubectl describe cronjob catalog-cleanup -n catalog +Name: catalog-cleanup +Namespace: catalog +Labels: app.kubernetes.io/created-by=eks-workshop + app.kubernetes.io/name=catalog-cleanup +Annotations: +Schedule: */1 * * * * +Concurrency Policy: Allow +Suspend: False +Successful Job History Limit: 3 +Failed Job History Limit: 1 +Starting Deadline Seconds: +Selector: +Parallelism: +Completions: +Pod Template: + Labels: app=catalog-cleanup + Containers: + cleanup: + Image: busybox:1.36 + Port: + Host Port: + Command: + /bin/sh + -c + echo "Starting cleanup job at $(date)" + echo "Checking for temporary files..." + + # Simulate finding and cleaning up files + echo "Found 3 temporary files to clean up:" + echo " - /tmp/cache_file_1.tmp" + echo " - /tmp/cache_file_2.tmp" + echo " - /tmp/old_log.log" + + # Simulate cleanup process + sleep 3 + echo "Cleaning up temporary files..." + sleep 2 + echo "Temporary files removed successfully" + + echo "Cleanup completed at $(date)" + echo "Next cleanup scheduled in 1 minute" + + Limits: + cpu: 100m + memory: 128Mi + Requests: + cpu: 50m + memory: 64Mi + Environment: + Mounts: + Volumes: + Node-Selectors: + Tolerations: +Last Schedule Time: Sun, 05 Oct 2025 19:14:00 +0000 +Active Jobs: catalog-cleanup-29328194 +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal SuccessfulCreate 19m cronjob-controller Created job catalog-cleanup-29328175 + Normal SawCompletedJob 18m cronjob-controller Saw completed job: catalog-cleanup-29328175, condition: Complete + ... +``` + +これは以下を示しています: +- **Schedule**: Jobが実行される時刻 +- **Last Schedule Time**: 最後に実行された時刻 +- **Active**: 現在実行中のJobs +- **Events**: 最近のCronJobアクティビティ + +トラブルシューティングのために最近のイベントを表示します: +```bash +$ kubectl get events -n catalog --field-selector involvedObject.name=catalog-cleanup +LAST SEEN TYPE REASON OBJECT MESSAGE +20m Normal SuccessfulCreate cronjob/catalog-cleanup Created job catalog-cleanup-29328175 +20m Normal SawCompletedJob cronjob/catalog-cleanup Saw completed job: catalog-cleanup-29328175, condition: Complete +3m28s Warning UnexpectedJob cronjob/catalog-cleanup Saw a job that the controller did not create or forgot: manual-cleanup +18m Normal SuccessfulCreate cronjob/catalog-cleanup Created job catalog-cleanup-29328176 +18m Normal SuccessfulCreate cronjob/catalog-cleanup Created job catalog-cleanup-29328177 +18m Normal SawCompletedJob cronjob/catalog-cleanup Saw completed job: catalog-cleanup-29328176, condition: Complete +18m Normal SuccessfulDelete cronjob/catalog-cleanup Deleted job catalog-cleanup-29328175 +18m Normal SawCompletedJob cronjob/catalog-cleanup Saw completed job: catalog-cleanup-29328177, condition: Complete +17m Normal SuccessfulCreate cronjob/catalog-cleanup Created job catalog-cleanup-29328178 +17m Normal SuccessfulDelete cronjob/catalog-cleanup Deleted job catalog-cleanup-29328176 +17m Normal SawCompletedJob cronjob/catalog-cleanup Saw completed job: catalog-cleanup-29328178, condition: Complete +``` + +### CronJobsの一時停止と再開 + +CronJobを一時的に停止します: +```bash +$ kubectl patch cronjob catalog-cleanup -n catalog -p '{"spec":{"suspend":true}}' +$ kubectl get cronjobs -n catalog +NAME SCHEDULE TIMEZONE SUSPEND ACTIVE LAST SCHEDULE AGE +catalog-cleanup */1 * * * * UTC True 0 42s 24m +``` + +一時停止されたCronJobを再開します: +```bash +$ kubectl patch cronjob catalog-cleanup -n catalog -p '{"spec":{"suspend":false}}' +$ kubectl get cronjobs -n catalog +NAME SCHEDULE TIMEZONE SUSPEND ACTIVE LAST SCHEDULE AGE +catalog-cleanup */1 * * * * UTC False 1 16s 24m +``` + +## 一般的なcronスケジュール + +| スケジュール | 説明 | +|----------|-------------| +| `0 2 * * *` | 毎日午前2時 | +| `0 */6 * * *` | 6時間ごと | +| `0 0 * * 0` | 毎週日曜日の午前0時 | +| `*/15 * * * *` | 15分ごと | +| `0 9 * * 1-5` | 平日の午前9時 | + +## 並列Jobs + +複数のアイテムを同時に処理する場合: + +```yaml +spec: + completions: 10 # 合計10個のアイテムを処理 + parallelism: 3 # 一度に3つのPodを実行 +``` +- `completions` = 成功したPodの合計数 +- `parallelism` = 同時に実行されるPodの数 + +これにより、3つの並列Podを使用して10個の成功した完了が作成されます。 + +## Jobsと他のコントローラーの比較 +| コントローラー | 目的 | Podは継続的に実行されますか？ | 使用例 | +|------------|---------|---------------|----------------| +| Job | 1回限りのタスク | いいえ | バッチ処理、マイグレーション | +| CronJob | スケジュールされたJobs | いいえ | バックアップ、定期レポート | +| Deployment | 長時間実行されるステートレスアプリ | はい | Webアプリ、API | +| StatefulSet | ステートフルサービス | はい | データベース、キュー | + +## 覚えておくべき重要なポイント + +* Jobsはタスクが正常に完了するまでPodを実行します +* CronJobsはスケジュールに従って自動的にJobsを作成します +* Jobsには`restartPolicy: Never`を、CronJobsには`OnFailure`を使用します +* バックオフ制限を設定して再試行回数を制御します +* Jobsは複数のPodを並列で実行して処理を高速化できます +* 完了したJobsをクリーンアップしてリソースの蓄積を避けます +* JobsとCronJobsは、有限または定期的なバッチタスクに最適で、長時間実行されるサービスには適していません + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/basics/workload-management/statefulsets.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/basics/workload-management/statefulsets.md new file mode 100644 index 0000000000..07cbea2cb2 --- /dev/null +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/basics/workload-management/statefulsets.md @@ -0,0 +1,105 @@ +--- +title: StatefulSets +sidebar_position: 32 +tmdTranslationSourceHash: f48100b6a8a52903afd4f3c1754ac19f +--- + +# StatefulSets + +**StatefulSets**は、**安定したアイデンティティと永続ストレージ**を必要とするアプリケーションを管理します。Deploymentではポッドが交換可能であるのに対し、StatefulSet内の各ポッドは、そのライフサイクル全体を通じて**一意で予測可能なアイデンティティを保持**します。 + +ステートフルアプリケーションに対して、いくつかの重要な利点を提供します: +- **安定したアイデンティティの提供** - ポッドは予測可能な名前を取得します(mysql-0、mysql-1、mysql-2) +- **永続ストレージの有効化** - 各ポッドは独自の永続ボリュームを持つことができます +- **順序付けられた操作の保証** - ポッドは順次作成および削除されます +- **安定したネットワーキングの維持** - 各ポッドは同じネットワークアイデンティティを保持します +- **順序付きのローリングアップデートのサポート** - ポッドは一度に1つずつ更新されます + +## StatefulSetのデプロイ + +Catalogサービス用のMySQLデータベースをデプロイしましょう: + +以下のYAMLは、Catalogサービス用にMySQLを実行するStatefulSetを作成し、永続ストレージと予測可能なPod名を持ちます。 + +::yaml{file="manifests/base-application/catalog/statefulset-mysql.yaml" paths="kind,metadata.name,spec.serviceName,spec.replicas" title="statefulset.yaml"} + +1. `kind: StatefulSet`: StatefulSetコントローラーを作成します +2. `metadata.name`: StatefulSetの名前(catalog-mysql) +3. `spec.serviceName`: 安定したネットワークアイデンティティに必要(headless Serviceを作成します) +4. `spec.replicas`: 実行するポッドの数(この例では1) + +データベースをデプロイします: +```bash +$ kubectl apply -k ~/environment/eks-workshop/base-application/catalog/ +``` + +## StatefulSetの確認 + +StatefulSetのステータスを確認します: +```bash +$ kubectl get statefulset -n catalog +NAME READY AGE +catalog-mysql 1/1 2m +``` + +作成されたポッドを表示します: +```bash +$ kubectl get pods -n catalog +NAME READY STATUS RESTARTS AGE +catalog-mysql-0 1/1 Running 0 2m +``` +> 数字のサフィックスを持つ予測可能なポッド名に注目してください + +StatefulSetの詳細情報を取得します: +```bash +$ kubectl describe statefulset -n catalog catalog-mysql +``` + +サフィックス(`-0`、`-1`など)により、ストレージとネットワークの目的で各ポッドを個別に追跡できます。 + +## StatefulSetのスケーリング + +3つのレプリカにスケールアップします: +```bash +$ kubectl scale statefulset -n catalog catalog-mysql --replicas=3 +$ kubectl get pods -n catalog +NAME READY STATUS RESTARTS AGE +catalog-mysql-0 1/1 Running 0 5m +catalog-mysql-1 0/1 Pending 0 10s +catalog-mysql-1 1/1 Running 0 30s +catalog-mysql-2 0/1 Pending 0 5s +catalog-mysql-2 1/1 Running 0 25s +``` +ポッドが順番に1つずつ作成されるのがわかります + +スケールダウンします: +```bash +$ kubectl scale statefulset -n catalog catalog-mysql --replicas=1 +``` + +ポッドは逆順に削除されます(2、次に1、0を保持)、安定性を確保します。 + +Kubernetesはまた、スケールアップまたはスケールダウンした場合でも、**各ポッドが永続ボリュームを保持する**ことを保証します。 + +## StatefulSets vs Deployments +| 機能 | StatefulSet | Deployment | +| ----------------- | ----------------------------- | ----------------- | +| Pod名 | 安定(`mysql-0`、`mysql-1`) | ランダム | +| ストレージ | ポッドごとに永続 | 通常は一時的 | +| 作成/削除 | 順序付き | 任意の順序 | +| ネットワークアイデンティティ | 安定 | 動的 | +| ユースケース | データベース、メッセージキュー | ステートレスアプリ | + +:::info +StatefulSetは、永続的なアイデンティティ、安定したネットワーキング、順序付けられた操作を必要とするアプリケーションに最適です。 +::: + +## 覚えておくべきポイント + +* StatefulSetは各ポッドに安定した一意のアイデンティティを提供します +* データベース、メッセージキュー、クラスター化されたアプリケーションに最適です +* 各ポッドは再起動後も存続する独自の永続ストレージを持つことができます +* 操作は順序通りに行われます - 作成(0→1→2)と削除(2→1→0) +* ポッド名は予測可能で変更されません +* アプリケーションがアイデンティティ、安定性、永続性を必要とする場合は常にStatefulSetを使用してください。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/getting-started/finish.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/getting-started/finish.md index 4c26a4f364..1881331615 100644 --- a/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/getting-started/finish.md +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/getting-started/finish.md @@ -1,7 +1,7 @@ --- title: 他のコンポーネント sidebar_position: 50 -tmdTranslationSourceHash: 2b121f2c62f5ef803e4d6ed1ed186a8c +tmdTranslationSourceHash: d8055e22245e0308df100684cf82cb42 --- この実習では、Kustomizeのパワーを活用してサンプルアプリケーションの残りの部分を効率的にデプロイします。次のkustomizationファイルは、他のkustomizationを参照して複数のコンポーネントを一緒にデプロイする方法を示しています： @@ -29,7 +29,7 @@ $ kubectl wait --for=condition=Ready --timeout=180s pods \ -l app.kubernetes.io/created-by=eks-workshop -A ``` -これで、各アプリケーションコンポーネント用の名前空間ができました： +これで、各アプリケーションコンポーネント用のNamespaceができました： ```bash $ kubectl get namespaces -l app.kubernetes.io/created-by=eks-workshop @@ -53,7 +53,6 @@ catalog catalog 1/1 1 1 7m46s checkout checkout 1/1 1 1 90s checkout checkout-redis 1/1 1 1 90s orders orders 1/1 1 1 90s -orders orders-postgresql 1/1 1 1 90s ui ui 1/1 1 1 90s ``` diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/getting-started/index.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/getting-started/index.md index 12b079046d..33fe54adc5 100644 --- a/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/getting-started/index.md +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/getting-started/index.md @@ -1,26 +1,150 @@ --- title: はじめに -sidebar_position: 30 +sidebar_position: 50 sidebar_custom_props: { "module": true } description: "Amazon Elastic Kubernetes Serviceでワークロードを実行する基本を学びましょう。" -tmdTranslationSourceHash: 7cdfb6c9bfdda46e240ba735baaedb14 +tmdTranslationSourceHash: b1aa6cc2b0129e0dbca8a43899c93dd0 --- ::required-time -EKSワークショップの最初のハンズオンラボへようこそ。この演習の目的は、今後の多くのラボ演習で使用するサンプルアプリケーションに慣れ親しみ、その過程でEKSにワークロードをデプロイすることに関する基本的な概念に触れることです。アプリケーションのアーキテクチャを探索し、コンポーネントをEKSクラスターにデプロイします。 - -それでは、ラボ環境のEKSクラスターに最初のワークロードをデプロイして探索してみましょう！ +EKSワークショップの最初のハンズオンラボへようこそ。この演習の目的は、IDE環境に必要な設定を準備し、その構造を探索することです。 始める前に、IDE環境とEKSクラスターを準備するために次のコマンドを実行する必要があります： +:::tip このセクションのために環境を準備してください： + ```bash $ prepare-environment introduction/getting-started ``` +このコマンドは、EKS WorkshopのGitリポジトリをIDE環境にクローンします。 +::: + +
+prepare-environmentは何をするのですか？（クリックして展開） + +`prepare-environment`コマンドは、各ワークショップモジュールのラボ環境をセットアップする重要なツールです。バックグラウンドで次のことを実行します： + +- **リポジトリのセットアップ**：GitHubから最新のEKS Workshopコンテンツを`/eks-workshop/repository`にダウンロードし、Kubernetesマニフェストを`~/environment/eks-workshop`にリンクします +- **クラスターのリセットとクリーンアップ**：サンプルの小売アプリケーションを基本状態にリセットします。以前のラボからの残存リソースを削除し、EKS管理ノードグループを初期サイズ（3ノード）に復元します。 +- **ラボ固有のインフラストラクチャ**：Terraformを使用して必要な追加AWSリソースを作成し、必要なKubernetesマニフェストをデプロイし、環境変数を設定し、必要なアドオンやコンポーネントをインストールすることで、対象モジュールを使用可能な状態にします。 + +
+ +## ワークショップの構造 + +`prepare-environment`を実行した後、`~/environment/eks-workshop/`でワークショップ資料にアクセスできます。ワークショップは、任意の順序で完了できるモジュール式のセクションで構成されています。 + +## EKSクラスターの探索 + +環境の準備が整ったので、プロビジョニングされたEKSクラスターを探索しましょう。次のコマンドを実行して、クラスターに慣れてください： + +### クラスター情報 + +まず、クラスター接続を確認し、基本情報を取得しましょう： + +```bash +$ kubectl cluster-info +Kubernetes control plane is running at https://XXXXXXXXXXXXXXXXXXXXXXXXXX.gr7.us-west-2.eks.amazonaws.com +CoreDNS is running at https://XXXXXXXXXXXXXXXXXXXXXXXXXX.gr7.us-west-2.eks.amazonaws.com/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy + +To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. +``` + +クラスターバージョンを確認します +```bash +$ kubectl version +Client Version: v1.33.5 +Kustomize Version: v5.6.0 +Server Version: v1.33.5-eks-113cf36 +``` + +クラスター内のワーカーノードを確認します + +```bash +$ kubectl get nodes -o wide +NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME +ip-10-42-121-153.us-west-2.compute.internal Ready 26h v1.33.5-eks-113cf36 10.42.121.153 Amazon Linux 2023.9.20250929 6.12.46-66.121.amzn2023.x86_64 containerd://1.7.27 +ip-10-42-141-241.us-west-2.compute.internal Ready 26h v1.33.5-eks-113cf36 10.42.141.241 Amazon Linux 2023.9.20250929 6.12.46-66.121.amzn2023.x86_64 containerd://1.7.27 +ip-10-42-183-73.us-west-2.compute.internal Ready 26h v1.33.5-eks-113cf36 10.42.183.73 Amazon Linux 2023.9.20250929 6.12.46-66.121.amzn2023.x86_64 containerd://1.7.27 +``` + +これにより、ワーカーノード、そのKubernetesバージョン、内部/外部IP、および使用されているコンテナランタイムが表示されます。 + +### クラスターコンポーネントの探索 + +クラスターで実行されているシステムコンポーネントを見てみましょう： + +```bash +$ kubectl get pods -n kube-system +NAME READY STATUS RESTARTS AGE +aws-node-8cz4d 2/2 Running 0 26h +aws-node-jlg4q 2/2 Running 0 26h +aws-node-vdc56 2/2 Running 0 26h +coredns-7bf648ff5d-4fqv9 1/1 Running 0 26h +coredns-7bf648ff5d-bfwwf 1/1 Running 0 26h +kube-proxy-77ln2 1/1 Running 0 26h +kube-proxy-7bwbj 1/1 Running 0 26h +kube-proxy-jnhfx 1/1 Running 0 26h +metrics-server-7fb96f5556-2k4lh 1/1 Running 0 26h +metrics-server-7fb96f5556-mpj78 1/1 Running 0 26h +``` + +次のような重要なコンポーネントが表示されます： +- **CoreDNS** - クラスターにDNSサービスを提供します +- **AWS Load Balancer Controller** - サービス用のAWSロードバランサーを管理します +- **VPC CNI** - VPC内のPodネットワーキングを処理します +- **kube-proxy** - 各ノード上のネットワークルールを管理します + +## サンプルアプリケーションのデプロイ + +小売店アプリケーションをデプロイして、Kubernetesの動作を見てみましょう。`kubectl`に組み込まれているKustomizeを使用します： + +```bash wait=10 +$ kubectl apply -k ~/environment/eks-workshop/base-application +``` + +これが完了したら、`kubectl wait`を使用して、続行する前にすべてのコンポーネントが起動していることを確認できます： + +```bash timeout=200 +$ kubectl wait --for=condition=Ready --timeout=180s pods \ + -l app.kubernetes.io/created-by=eks-workshop -A +``` + +各アプリケーションコンポーネント用のNamespaceが作成されます： + +```bash +$ kubectl get namespaces -l app.kubernetes.io/created-by=eks-workshop +NAME STATUS AGE +carts Active 62s +catalog Active 7m17s +checkout Active 62s +orders Active 62s +other Active 62s +ui Active 62s +``` + +コンポーネント用に作成されたすべてのDeploymentも確認できます： + +```bash +$ kubectl get deployment -l app.kubernetes.io/created-by=eks-workshop -A +NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE +carts carts 1/1 1 1 90s +carts carts-dynamodb 1/1 1 1 90s +catalog catalog 1/1 1 1 7m46s +checkout checkout 1/1 1 1 90s +checkout checkout-redis 1/1 1 1 90s +orders orders 1/1 1 1 90s +orders orders-postgresql 1/1 1 1 90s +ui ui 1/1 1 1 90s +``` + +サンプルアプリケーションがデプロイされ、このワークショップの残りのラボで使用する基盤を提供する準備ができました！ -このコマンドは何をしているのでしょうか？このラボでは、必要なKubernetesマニフェストファイルがファイルシステム上に存在するように、EKS WorkshopのGitリポジトリをIDE環境にクローンしています。 +## 次は何をしますか？ -以降のラボでも同様にこのコマンドを実行しますが、その際には次の2つの重要な追加機能を実行します： +EKSクラスターの準備ができ、サンプルアプリケーションがデプロイされました！学習目標に基づいて、任意のワークショップモジュールに進むことができます。 -1. EKSクラスターを初期状態にリセットする -2. 次のラボ演習に必要な追加コンポーネントをクラスターにインストールする +:::tip +各モジュールは独立しており、必要なリソースをセットアップするための独自の`prepare-environment`コマンドが含まれています。任意の順序で完了できます！ +::: 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 3f5595a9f5..92a59ce6c1 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 @@ -1,8 +1,8 @@ --- title: Helm sidebar_custom_props: { "module": true } -sidebar_position: 50 -tmdTranslationSourceHash: 5f7ef990a504bc7200491f65c8407b7a +sidebar_position: 80 +tmdTranslationSourceHash: 2cfda63d9839d159ccdaecf95773c388 --- ::required-time @@ -162,4 +162,113 @@ $ helm uninstall ui --namespace ui --wait これにより、そのリリース用にチャートによって作成されたすべてのリソースがEKSクラスターから削除されます。 -Helmの仕組みを理解したので、[Fundamentalsモジュール](/docs/fundamentals)に進みましょう。 +## 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 << 'EOF' +replicaCount: 2 + +image: + repository: public.ecr.aws/aws-containers/retail-store-sample-catalog + tag: "0.4.0" + pullPolicy: IfNotPresent + +service: + type: ClusterIP + port: 80 + targetPort: 8080 + +resources: + requests: + cpu: 128m + memory: 512Mi + limits: + cpu: 256m + memory: 512Mi + +nameOverride: "catalog" +fullnameOverride: "catalog" +EOF +``` + +### チャートのインストール + +それでは、Helmチャートを使用してcatalogサービスをインストールしましょう： + +```bash +$ helm install catalog ./retail-catalog --namespace catalog --create-namespace +``` + +デプロイを確認します： + +```bash +$ helm list -n catalog +NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION +catalog catalog 1 2024-11-15 10:35:42.123456789 +0000 UTC deployed retail-catalog-0.1.0 1.16.0 +``` + +実行中のPodを確認します： + +```bash +$ kubectl get pods -n catalog +NAME READY STATUS RESTARTS AGE +catalog-7d4b8c9f8d-abc12 1/1 Running 0 2m +catalog-7d4b8c9f8d-def34 1/1 Running 0 2m +``` + +### リリースのアップグレード + +Helmの強みの1つはアプリケーションのアップグレード管理です。レプリカ数を更新してアプリケーションをスケールしてみましょう： + +```bash +$ helm upgrade catalog ./retail-catalog \ + --namespace catalog \ + --set replicaCount=3 +``` + +### ロールバック + +何か問題が発生した場合、Helmを使用すると簡単にロールバックできます： + +```bash +$ helm rollback catalog 1 -n catalog +``` + +### クリーンアップ + +Helmリリースを削除します： + +```bash +$ helm uninstall catalog -n catalog +``` + +この例は、Helmがアプリケーションのデプロイに高レベルの抽象化を提供し、アップグレード、ロールバック、構成管理のサポートが組み込まれていることを示しています。 + +Helmの仕組みを理解したので、宣言的な構成管理について学ぶために[Kustomize](../kustomize)に進むか、[Fundamentalsモジュール](/docs/fundamentals)に進むことができます。 diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/index.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/index.md index debf82aa11..4dcf9af7f7 100644 --- a/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/index.md +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/index.md @@ -2,14 +2,14 @@ title: はじめに sidebar_position: 10 weight: 5 -tmdTranslationSourceHash: 61b50d02213aefa1774e875922ded5f9 +tmdTranslationSourceHash: ead142ad2229882977fab2e1aeb46f7d --- **AWS Elastic Kubernetes Service (EKS) ワークショップ**へようこそ！ このワークショップでは、EKSが提供する様々な機能と、AWSが提供する幅広いサービスとの統合について学び、探索するための一連のハンズオンラボ演習をご案内します。ラボは以下のような複数の領域にわたってグループ化されています： -- **はじめに** - このワークショップの形式と構造について学ぶ +- **はじめに** - ワークショップの形式と構造について学び、EKSクラスターをプロビジョニングし、Kubernetesの基本とサンプルアプリケーションに慣れる - **基礎** - マネージドノードグループ、Fargate、アプリケーションの公開、ストレージの活用など、基本的なEKSの概念に慣れる - **自動スケーリング** - アプリケーションとクラスターを水平および垂直に自動的にスケールする方法を理解する - **可観測性** - モニタリングはワークロードを本番環境に移行する上で重要な要素 @@ -22,3 +22,4 @@ tmdTranslationSourceHash: 61b50d02213aefa1774e875922ded5f9 Amazon EKSの基本について学ぶには、この短い約10分の動画をご覧ください：
+ diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/kustomize/index.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/kustomize/index.md index 7fbff08fff..600371c9b1 100644 --- a/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/kustomize/index.md +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/kustomize/index.md @@ -1,8 +1,8 @@ --- title: Kustomize sidebar_custom_props: { "module": true } -sidebar_position: 40 -tmdTranslationSourceHash: 80ad63a289b3caa54d84f83fab6555e6 +sidebar_position: 70 +tmdTranslationSourceHash: 785ddb1ac12e1137a75c4433b9b12aa5 --- ::required-time @@ -18,13 +18,56 @@ $ prepare-environment [Kustomize](https://kustomize.io/)は、宣言的な「kustomization」ファイルを使用してKubernetesマニフェストファイルを管理することができます。これにより、Kubernetesリソースの「ベース」マニフェストを表現し、構成、カスタマイズ、そして多くのリソースにわたる横断的な変更を簡単に適用することが可能になります。 -例えば、以下の`checkout`デプロイメントのマニフェストファイルを見てみましょう： +## 小売ストアアプリケーションのデプロイ + +まず、Kustomizeを使用して完全な小売ストアアプリケーションをデプロイしましょう。アプリケーションは連携して動作する複数のマイクロサービスで構成されています： + +### ベースアプリケーションのデプロイ + +最初に、ベース設定を使用して小売ストアアプリケーション全体をデプロイしましょう： + +```bash +$ kubectl apply -k ~/environment/eks-workshop/base-application +``` + +この単一のコマンドで、すべてのマイクロサービスがデプロイされます。何が作成されたか見てみましょう： + +```bash +$ kubectl get pods -A -l app.kubernetes.io/created-by=eks-workshop +NAME READY STATUS RESTARTS AGE +cart-6d4f8c9b8d-xyz12 1/1 Running 0 2m +catalog-7b5c9d8e9f-abc34 1/1 Running 0 2m +checkout-8c6d0e1f2g-def56 1/1 Running 0 2m +orders-9d7e2f3g4h-ghi78 1/1 Running 0 2m +ui-0e8f3g4h5i-jkl90 1/1 Running 0 2m +``` + +### Kustomizationの構造を理解する + +ベースアプリケーションは、すべてのコンポーネントディレクトリを参照する`kustomization.yaml`ファイルを使用しています： + +```bash +$ cat ~/environment/eks-workshop/base-application/kustomization.yaml +``` + +各サービスには、Kubernetesマニフェストを含む独自のディレクトリがあります： + +```bash +$ ls ~/environment/eks-workshop/base-application/ +cart/ catalog/ checkout/ orders/ ui/ kustomization.yaml +``` + +### オーバーレイによるカスタマイズ + +それでは、カスタマイズを作成してKustomizeの力を見てみましょう。例えば、`checkout`サービスの`replicas`フィールドを1から3に更新して水平にスケールしてみましょう。 + +以下の`checkout` Deploymentのマニフェストファイルを見てみましょう： ```file manifests/base-application/checkout/deployment.yaml ``` -このファイルは前の[Getting Started](../getting-started)ラボですでに適用されていますが、Kustomizeを使用して`replicas`フィールドを更新することで、このコンポーネントを水平にスケールしたいとします。このYAMLファイルを手動で更新する代わりに、Kustomizeを使用して`spec/replicas`フィールドを1から3に更新します。 +このYAMLファイルを手動で更新する代わりに、Kustomizeを使用して`spec/replicas`フィールドを1から3に更新します。 そのためには、以下のkustomizationを適用します。 @@ -95,6 +138,47 @@ $ kubectl kustomize ~/environment/eks-workshop/base-application \ これは`envsubst`を使用して、Kubernetesマニフェストファイル内の環境変数プレースホルダーを、あなたの特定の環境に基づく実際の値に置き換えます。例えば、いくつかのマニフェストでは、EKSクラスター名を`$EKS_CLUSTER_NAME`で、またはAWSリージョンを`$AWS_REGION`で参照する必要があります。 -Kustomizeの仕組みを理解したので、[Helmモジュール](/docs/introduction/helm)に進むか、直接[基礎モジュール](/docs/fundamentals)に進むことができます。 +## 高度なKustomizeパターン + +### 環境固有の設定 + +Kustomizeは、異なる環境に対する異なる設定の管理に優れています。例えば： + +- **ベース**: すべての環境で共有される共通の設定 +- **開発オーバーレイ**: 低いリソース制限、デバッグロギングを有効化 +- **本番オーバーレイ**: 高いリソース制限、複数のレプリカ、モニタリングを有効化 + +### 横断的な変更 + +Kustomizeの強みの1つは、複数のリソースに対して変更を行えることです。例えば： + +- すべてのリソースにラベルを追加: `commonLabels` +- すべてのリソースにアノテーションを追加: `commonAnnotations` +- すべてのデプロイメントにリソース制限を設定 +- イメージプルポリシーを一貫して設定 + +### 個別サービスのデプロイ + +特定のkustomizationを使用して個別のサービスをデプロイすることもできます： + +```bash +# catalogサービスのみをデプロイ +$ kubectl apply -k ~/environment/eks-workshop/base-application/catalog + +# UIサービスのみをデプロイ +$ kubectl apply -k ~/environment/eks-workshop/base-application/ui +``` + +### 生成されたマニフェストの表示 + +変更を適用する前に、Kustomizeが生成する内容をプレビューできます： + +```bash +$ kubectl kustomize ~/environment/eks-workshop/base-application/catalog +``` + +これにより、クラスターに実際に適用することなく、どのKubernetesリソースが作成されるかを正確に確認できます。 + +Kustomizeの仕組みを理解したので、[Getting Started](/docs/introduction/getting-started)ハンズオンラボに進むか、直接[基礎モジュール](/docs/fundamentals)に進むことができます。 Kustomizeについて詳しく知るには、公式Kubernetesの[ドキュメント](https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/)を参照してください。 diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/navigating-labs.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/navigating-labs.md index 79789608f8..ea9b6a5226 100644 --- a/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/navigating-labs.md +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/introduction/navigating-labs.md @@ -1,7 +1,7 @@ --- title: ラボのナビゲーション -sidebar_position: 25 -tmdTranslationSourceHash: '3ef210656bc2a09d2ad75d89542ca72f' +sidebar_position: 30 +tmdTranslationSourceHash: 'ce60b02ae62eb9aa4bbd5a450bd5f448' --- import Tabs from '@theme/Tabs'; @@ -16,21 +16,62 @@ import TabItem from '@theme/TabItem'; 1. 個別のラボ演習 2. ラボに関連する概念を説明するサポートコンテンツ -ラボ演習は、任意のモジュールを独立した演習として実行できるように設計されています。ラボ演習は左側のサイドバーに表示され、ここに示すアイコンで指定されています： +ラボ演習は、任意のモジュールを独立した演習として実行できるように設計されています。ラボ演習は左側のサイドバーに表示され、`LAB` アイコンで指定されています。 -![Lab icon example](/docs/introduction/lab-icon.webp) +## IDE を開く -このモジュールには、画面の左側に表示される **Getting started** という名前の単一のラボが含まれています。 +まだ開いていない場合は、スタートページの下部にある *Event outputs* セクションから IDE を開くことができます。 + + ![Event Outputs copy/paste](/img/fastpaths/ide-open.png) + +## 環境の準備 + +`prepare-environment` ツールは、各セクションのラボ環境をセットアップおよび設定するのに役立ちます。次のように実行するだけです： + +``` +$ prepare-environment $MODULE_NAME +``` + +### 基本的な使用パターン +``` +$ prepare-environment $MODULE_NAME/$LAB +``` + +**例** +``` +# Getting started ラボの場合 +$ prepare-environment introduction/getting-started + +# Karpenter autoscaling の場合 +$ prepare-environment autoscaling/compute/karpenter + +# EBS を使用したストレージの場合 +$ prepare-environment fundamentals/storage/ebs + +# ネットワーキング security groups の場合 +$ prepare-environment networking/securitygroups-for-pods +``` :::caution -各ラボは、このバッジで示されるページから開始する必要があります。ラボの途中から開始すると、予測不可能な動作が発生します。 +各ラボは「BEFORE YOU START」バッジで示されたページから開始する必要があります。ラボの途中から開始すると、予測不可能な動作が発生します。 ::: +## クラスターのリセット（Modular Section のみ） + +誤ってクラスターやモジュールを機能しない方法で設定してしまった場合、EKS クラスターをできる限りリセットするメカニズムが提供されており、いつでも実行できます。`prepare-environment` コマンドを実行し、完了するまで待つだけです。これには、実行時のクラスターの状態に応じて数分かかる場合があります。 + +```bash +$ prepare-environment +``` + +## ヒント + +### コピー＆ペーストの許可 ブラウザによっては、VSCode ターミナルにコンテンツを初めてコピー＆ペーストすると、次のようなプロンプトが表示される場合があります： -![VSCode copy/paste](/docs/introduction/vscode-copy-paste.webp) +VSCode copy/paste -## ターミナルコマンド +### ターミナルコマンド このワークショップでのやり取りのほとんどは、ターミナルコマンドを使用して行われます。これらのコマンドは、手動で入力するか、IDE ターミナルにコピー＆ペーストできます。ターミナルコマンドは次のように表示されます： @@ -60,10 +101,7 @@ Fri Aug 30 12:26:58 MDT 2024 この場合、各コマンドを個別にコピーするか、ターミナルウィンドウの右上にあるクリップボードアイコンを使用してすべてのコマンドをコピーできます。試してみてください！ -## EKS クラスターのリセット - -誤ってクラスターを機能しない方法で設定してしまった場合、EKS クラスターをできる限りリセットするメカニズムが提供されており、いつでも実行できます。単に `prepare-environment` コマンドを実行し、完了するまで待つだけです。これには、実行時のクラスターの状態に応じて数分かかる場合があります。 - ## 次のステップ -このワークショップの形式に慣れたら、[Getting started](/docs/introduction/getting-started) ラボに進むか、上部のナビゲーションバーを使用してワークショップの任意のモジュールにスキップしてください。 +このワークショップの形式に慣れたら、[Application Overview](/docs/introduction/getting-started/about) に進んでサンプルアプリケーションについて学習し、その後 [Getting Started](/docs/introduction/getting-started) ラボに進むか、上部のナビゲーションバーを使用してワークショップの任意のモジュールにスキップしてください。 + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/networking/eks-hybrid-nodes/routing-traffic.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/networking/eks-hybrid-nodes/routing-traffic.md index dc8ea72fa9..e9e2d4bf3b 100644 --- a/website/i18n/ja/docusaurus-plugin-content-docs/current/networking/eks-hybrid-nodes/routing-traffic.md +++ b/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 ``` + diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/networking/vpc-lattice/configuring-routes.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/networking/vpc-lattice/configuring-routes.md index b7ba0584d8..33f5e3b1b9 100644 --- a/website/i18n/ja/docusaurus-plugin-content-docs/current/networking/vpc-lattice/configuring-routes.md +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/networking/vpc-lattice/configuring-routes.md @@ -1,7 +1,7 @@ --- title: "ルートの設定" sidebar_position: 30 -tmdTranslationSourceHash: 2a099daa7d22fd6797d5afed142a0f8d +tmdTranslationSourceHash: 607942b50a09a9268c77b8b43a71019f --- このセクションでは、ブルー/グリーンデプロイメントやカナリアスタイルのデプロイメントのための重み付けルーティングを使用した、高度なトラフィック管理にAmazon VPC Latticeを使用する方法を示します。 @@ -9,7 +9,7 @@ tmdTranslationSourceHash: 2a099daa7d22fd6797d5afed142a0f8d 配送オプションに「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 ``` diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/observability/container-insights/visualize-application-metrics-cloudwatch.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/observability/container-insights/visualize-application-metrics-cloudwatch.md index 29d919266c..d344e90352 100644 --- a/website/i18n/ja/docusaurus-plugin-content-docs/current/observability/container-insights/visualize-application-metrics-cloudwatch.md +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/observability/container-insights/visualize-application-metrics-cloudwatch.md @@ -1,9 +1,11 @@ --- title: "アプリケーションメトリクス" sidebar_position: 50 -tmdTranslationSourceHash: d0902eea5e06ee6c0776e4e666b31ea3 +tmdTranslationSourceHash: 3f49f73bcc8bf808480d0dc139810348 --- +import dashboard from '@site/static/docs/observability/container-insights/cw-dashboard.webp'; + このセクションでは、ワークロードによって公開されているメトリクスの洞察を得て、Amazon CloudWatch Insights Prometheusを使用してこれらのメトリクスを可視化する方法を見ていきます。これらのメトリクスの例としては以下のようなものがあります： - Javaヒープメトリクスやデータベース接続プールのステータスなどのシステムメトリクス @@ -63,7 +65,7 @@ nodejs_heap_size_total_bytes 48668672 ::yaml{file="manifests/modules/observability/container-insights/adot-deployment/opentelemetrycollector.yaml" zoomPath="spec.config.receivers.prometheus" zoomBefore="2"} -AWS Container Insights Receiverではなく、[Prometheusレシーバー](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/prometheusreceiver/README.md)を使用してEKSクラスター内のすべてのポッドをスクレイプします。 +AWS Container Insights Receiverではなく、[Prometheusレシーバー](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/prometheusreceiver/README.md)を使用してEKSクラスター内のすべてのPodをスクレイプします。 ::yaml{file="manifests/modules/observability/container-insights/adot-deployment/opentelemetrycollector.yaml" zoomPath="spec.config.processors"} diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/observability/kubecost/introduction.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/observability/kubecost/introduction.md index 8629d1d407..1c8212aedb 100644 --- a/website/i18n/ja/docusaurus-plugin-content-docs/current/observability/kubecost/introduction.md +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/observability/kubecost/introduction.md @@ -1,7 +1,7 @@ --- title: "はじめに" sidebar_position: 10 -tmdTranslationSourceHash: ae393634b2df08c97fb378b53a9b884c +tmdTranslationSourceHash: 8efcc70ec51cfc295110ffa098c8c902 --- 最初に行うことは、クラスターにKubecostをインストールすることです。ラボの準備の一環として、AWS Load Balancer ControllerとEBS CSIドライバーが事前にインストールされ、Kubecostにイングレスとストレージを提供します。 @@ -13,11 +13,13 @@ $ aws ecr-public get-login-password \ --region us-east-1 | helm registry login \ --username AWS \ --password-stdin public.ecr.aws +$ ESCAPED_CIDRS="${INBOUND_CIDRS//,/\\,}" $ helm upgrade --install kubecost oci://public.ecr.aws/kubecost/cost-analyzer \ --version "${KUBECOST_CHART_VERSION}" \ --namespace "kubecost" --create-namespace \ --values https://raw.githubusercontent.com/kubecost/cost-analyzer-helm-chart/v${KUBECOST_CHART_VERSION}/cost-analyzer/values-eks-cost-monitoring.yaml \ --values ~/environment/eks-workshop/modules/observability/kubecost/values.yaml \ + --set "service.annotations.service\\.beta\\.kubernetes\\.io/load-balancer-source-ranges"="$ESCAPED_CIDRS" \ --wait NAME: kubecost LAST DEPLOYED: Thu Jun 13 17:48:55 2024 diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/security/secrets-management/secrets-manager/external-secrets.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/security/secrets-management/secrets-manager/external-secrets.md index 1d183ddf8d..3a298d3ff7 100644 --- a/website/i18n/ja/docusaurus-plugin-content-docs/current/security/secrets-management/secrets-manager/external-secrets.md +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/security/secrets-management/secrets-manager/external-secrets.md @@ -1,7 +1,7 @@ --- title: "External Secrets Operator" sidebar_position: 424 -tmdTranslationSourceHash: a83e79135004db35c75e04bc4266b948 +tmdTranslationSourceHash: cd7bf6b9c2b6b39e75b441f72c42579b --- 次に、External Secrets operatorを使用したAWS Secrets Managerとの統合を探ってみましょう。これは既にEKSクラスタにインストールされています： @@ -18,7 +18,7 @@ default 0 7m external-secrets-sa 0 7m ``` -オペレーターは`external-secrets-sa`という名前のServiceAccountを使用しており、これは[IRSA](../../iam-roles-for-service-accounts/)を介してIAMロールに関連付けられ、AWS Secrets Managerへのアクセス権を提供しています： +オペレーターは`external-secrets-sa`という名前のServiceAccountを使用しており、これは[IRSA](../../iam-roles-for-service-accounts/)を介してIAMロールに関連付けられ、シークレットを取得するためのAWS Secrets Managerへのアクセス権を提供しています： ```bash $ kubectl -n external-secrets describe sa external-secrets-sa | grep Annotations @@ -31,7 +31,7 @@ Annotations: eks.amazonaws.com/role-arn: arn:aws:iam::1234567890:role/ek 1. シークレットソースとしてAWS Secrets Managerを使用するために`service: SecretsManager`を設定 2. シークレットが保存されているAWSリージョンを指定するために`$AWS_REGION`環境変数を使用 -3. `auth.jwt`はIRSAを使用して`external-secrets`名前空間の`external-secrets-sa`サービスアカウントで認証し、これはAWS Secrets Managerへのアクセス権を持つIAMロールにリンクされています +3. `auth.jwt`はIRSAを使用して`external-secrets`名前空間の`external-secrets-sa`サービスアカウント経由で認証し、これはAWS Secrets Managerの権限を持つIAMロールにリンクされています このファイルを使用してClusterSecretStoreリソースを作成しましょう。 @@ -40,7 +40,15 @@ $ cat ~/environment/eks-workshop/modules/security/secrets-manager/cluster-secret | envsubst | kubectl apply -f - ``` -次に、AWS Secrets Managerからどのデータを取得し、それをKubernetesシークレットにどのように変換するかを定義する`ExternalSecret`を作成します。その後、これらの認証情報を使用するように`catalog`デプロイメントを更新します： +次に、AWS Secrets Managerからどのデータを取得し、それをKubernetesシークレットにどのように変換するかを定義する`ExternalSecret`を作成します。 + +適用される`ExternalSecret`マニフェストを確認してみましょう： + +::yaml{file="manifests/modules/security/secrets-manager/external-secrets/external-secret.yaml"} + +これはExternal Secrets Operatorに対して、`ClusterSecretStore`から`$SECRET_NAME`で識別されるシークレットを取得し、1時間ごとに`catalog`名前空間に同期するように指示します。 + +また、これらの認証情報を使用するように`catalog` Deploymentを更新します： ```kustomization modules/security/secrets-manager/external-secrets/kustomization.yaml @@ -104,7 +112,7 @@ $ kubectl -n catalog get secret catalog-external-secret -o yaml | yq '.metadata. uid: b8710001-366c-44c2-8e8d-462d85b1b8d7 ``` -私たちの`catalog`ポッドが新しいシークレット値を使用していることを確認できます： +私たちの`catalog` Podが新しいシークレット値を使用していることを確認できます： ```bash $ kubectl -n catalog get pods @@ -126,7 +134,7 @@ $ kubectl -n catalog get deployment catalog -o yaml | yq '.spec.template.spec.co ### まとめ -**AWS Secrets and Configuration Provider（ASCP）**と**External Secrets Operator（ESO）**の間には、AWS Secrets Managerのシークレットを管理するための「最良」な選択肢はありません。 +AWS Secrets Managerのシークレットを管理するための、**AWS Secrets and Configuration Provider（ASCP）**と**External Secrets Operator（ESO）**の間には、単一の「最良」な選択肢はありません。 それぞれのツールには異なる利点があります： diff --git a/website/i18n/ja/docusaurus-plugin-content-docs/current/troubleshooting/alb/alb_fix_7.md b/website/i18n/ja/docusaurus-plugin-content-docs/current/troubleshooting/alb/alb_fix_7.md index 1e518478e3..983001f08c 100644 --- a/website/i18n/ja/docusaurus-plugin-content-docs/current/troubleshooting/alb/alb_fix_7.md +++ b/website/i18n/ja/docusaurus-plugin-content-docs/current/troubleshooting/alb/alb_fix_7.md @@ -1,22 +1,22 @@ --- -title: "サービスがエンドポイントを登録していない問題" +title: "Service が Endpoint を登録していない問題" sidebar_position: 32 -tmdTranslationSourceHash: fc331a5ef68d4afb716ae012b9f5dd05 +tmdTranslationSourceHash: 8d1dace21e05f19a16833e847fd153c0 --- -このセクションでは、Application Load Balancer (ALB) が Kubernetes サービスのエンドポイントを正しく登録しない理由についてトラブルシューティングを行います。ALB が正常に作成されたにもかかわらず、バックエンドサービスの設定に問題があるためアプリケーションにアクセスできません。 +このセクションでは、Application Load Balancer (ALB) が Kubernetes Service の Endpoint を正しく登録しない理由についてトラブルシューティングを行います。ALB が正常に作成されたにもかかわらず、バックエンド Service の設定に問題があるためアプリケーションにアクセスできません。 ### ステップ 1: エラーの確認 -ALB を通じてアプリケーションにアクセスすると、「Backend service does not exist（バックエンドサービスが存在しません）」というエラーが表示されます： +ALB を通じてアプリケーションにアクセスすると、「Backend service does not exist（バックエンド Service が存在しません）」というエラーが表示されます： ![ALb-Backend-DoesNotExist](/docs/troubleshooting/alb/alb-does-not-exist.webp) -イングレスは正常に作成されたため、これは Kubernetes イングレスとサービス間の通信に問題があることを示唆しています。 +Ingress は正常に作成されたため、これは Kubernetes Ingress と Service 間の通信に問題があることを示唆しています。 -### ステップ 2: サービス設定の確認 +### ステップ 2: Service 設定の確認 -サービス設定を調べてみましょう： +Service 設定を調べてみましょう： ```bash $ kubectl -n ui get service/ui -o yaml @@ -52,9 +52,9 @@ status: loadBalancer: {} ``` -### ステップ 3: イングレス設定の確認 +### ステップ 3: Ingress 設定の確認 -次にイングレス設定を確認します： +次に Ingress 設定を確認します： ```bash $ kubectl get ingress/ui -n ui -o yaml @@ -91,14 +91,14 @@ spec: ... ``` -イングレスが `service-ui` という名前のサービスを使用するように設定されていますが、実際のサービス名は `ui` であることに注目してください。 +Ingress が `service-ui` という名前の Service を使用するように設定されていますが、実際の Service 名は `ui` であることに注目してください。 -### ステップ 4: イングレス設定の修正 +### ステップ 4: Ingress 設定の修正 -イングレスを正しいサービス名を指すように更新しましょう： +Ingress を正しい Service 名を指すように更新しましょう： ```bash -$ kubectl apply -k ~/environment/eks-workshop/modules/troubleshooting/alb/creating-alb/fix_ingress +$ kubectl kustomize ~/environment/eks-workshop/modules/troubleshooting/alb/creating-alb/fix_ingress | envsubst | kubectl apply -f - ``` 修正後の設定は次のようになります： @@ -118,13 +118,13 @@ spec: number: 80 ``` -### ステップ 5: サービスエンドポイントの確認 +### ステップ 5: Service Endpoint の確認 -サービス名を修正した後も、まだ 503 エラーが表示されます： +Service 名を修正した後も、まだ 503 エラーが表示されます： ![ALb-503-ERROR](/docs/troubleshooting/alb/alb-503.webp) -これは、サービスのバックエンドエンドポイントに問題があることを示唆しています。エンドポイントを確認してみましょう： +これは、Service のバックエンド Endpoint に問題があることを示唆しています。Endpoint を確認してみましょう： ```bash $ kubectl -n ui get endpoints ui @@ -132,11 +132,11 @@ NAME ENDPOINTS AGE ui 13d ``` -エンドポイントが空であることは、サービスが Pod バックエンドを適切に選択していないことを示しています。 +Endpoint が空であることは、Service が Pod バックエンドを適切に選択していないことを示しています。 -### ステップ 6: サービスと Pod のラベルの比較 +### ステップ 6: Service と Pod のラベルの比較 -デプロイメントの Pod ラベルを調べてみましょう： +Deployment の Pod ラベルを調べてみましょう： ```bash $ kubectl -n ui get deploy/ui -o yaml @@ -183,7 +183,7 @@ spec: ``` -これをサービスセレクタと比較してみましょう： +これを Service セレクタと比較してみましょう： ```bash $ kubectl -n ui get svc ui -o yaml @@ -217,10 +217,10 @@ spec: ... ``` -サービスセレクタの `app.kubernetes.io/name: ui-app` が Pod ラベルの `app.kubernetes.io/name: ui` と一致していません。 +Service セレクタの `app.kubernetes.io/name: ui-app` が Pod ラベルの `app.kubernetes.io/name: ui` と一致していません。 :::tip -サービスセレクタを以下のように更新することができます： +Service セレクタを以下のように更新することができます： ```text kubectl edit service -n @@ -234,25 +234,25 @@ kubectl patch service -n --type='json' -p='[{"op": "r ::: -### ステップ 7: サービスセレクタの修正 +### ステップ 7: Service セレクタの修正 -サービスセレクタを Pod ラベルと一致するように更新しましょう： +Service セレクタを Pod ラベルと一致するように更新しましょう： ```bash timeout=960 hook=fix-7 hookTimeout=960 $ kubectl apply -k ~/environment/eks-workshop/modules/troubleshooting/alb/creating-alb/fix_ui ``` -修正を適用した後、ブラウザを更新してください。これでUI アプリケーションが表示されるはずです： +修正を適用した後、ブラウザを更新してください。これで UI アプリケーションが表示されるはずです： ![ALB-UI-APP](/docs/troubleshooting/alb/alb-working.webp) :::tip -サービスと Pod の接続をトラブルシューティングする際は： +Service と Pod の接続をトラブルシューティングする際は： -1. サービスセレクタが Pod ラベルと完全に一致することを常に確認する +1. Service セレクタが Pod ラベルと完全に一致することを常に確認する 2. `kubectl get endpoints` を使用して Pod の選択を確認する 3. ラベル名と値のタイプミスがないか確認する ::: -サービス設定の問題を修正し、ALB のトラブルシューティング演習を完了しました！お疲れ様でした。 +Service 設定の問題を修正し、ALB のトラブルシューティング演習を完了しました！お疲れ様でした。