Amazon CloudWatch Observability EKS アドオンまたは Helm チャートを使用して CloudWatch エージェントをインストールする - Amazon CloudWatch

Amazon CloudWatch Observability EKS アドオンまたは Helm チャートを使用して CloudWatch エージェントをインストールする

Amazon CloudWatch Observability EKS アドオンまたは Amazon CloudWatch Observability Helm チャートを使用して、Amazon EKS クラスターに CloudWatch エージェントと Fluent Bit エージェントをインストールできます。また、Helm チャートを使用して、Amazon EKS でホストされていない Kubernetes クラスターに CloudWatch エージェントと Fluent Bit エージェントをインストールすることもできます。

Amazon EKS クラスターでこのいずれかの方法を使用すると、デフォルトで Amazon EKS と CloudWatch Application Signals の両方の Container Insights がオブザーバビリティが強化されたうえで有効になります。どちらの機能を使用しても、クラスターからインフラストラクチャメトリクス、アプリケーションパフォーマンステレメトリ、コンテナログを容易に収集できます。

Amazon EKS 向けにオブザーバビリティが強化された Container Insights では、観察結果ごと Container Insights メトリクスに課金されます。保存されたメトリクスまたは取り込まれたログごとには課金されません。Application Signals の場合、アプリケーションへのインバウンドリクエスト、アプリケーションからのアウトバウンドリクエスト、設定された各サービスレベル目標 (SLO) に基づいて、請求が行われます。インバウンドリクエストを受信するたびにアプリケーションシグナルが 1 つ生成され、アウトバウンドリクエストが発生するたびにアプリケーションシグナルが 1 つ生成されます。各 SLO は、測定間隔ごとにアプリケーションシグナルを 2 つ作成します。CloudWatch の料金の詳細については、「Amazon CloudWatch の料金」をご覧ください。

どちらの方法を使用しても、Amazon EKS クラスターの Linux と Windows の両方のワーカーノードで Container Insights を有効にできます。Windows で Container Insights を有効にするには、Amazon EKS アドオンのバージョン 1.5.0 以降を使用するか、Helm チャートを使用する必要があります。現在、Amazon EKS クラスターの Windows では、Application Signals はサポートされていません。

Amazon CloudWatch Observability EKS アドオンは、Kubernetes バージョン 1.23 以降で Amazon EKS クラスターを実行している場合にサポートされます。

また、このアドオンまたは Helm チャートをインストールするときは、IAM アクセス許可を付与して、CloudWatch エージェントが CloudWatch にメトリクス、ログ、トレースを送信できるようにする必要があります。次の 2 通りの方法があります。

  • ワーカーノードの IAM ロールにポリシーをアタッチします。このオプションは、テレメトリを CloudWatch に送信するアクセス許可をワーカーノードに付与します。

  • エージェントポッドでサービスアカウントの IAM ロールを使用し、このロールにポリシーをアタッチします。これは Amazon EKS クラスターでのみ機能します。このオプションでは、CloudWatch は適切なエージェントポッドにのみアクセスできます。

オプション 1: EKS Pod Identity を使用してインストールする

バージョン 3.1.0 以降のアドオンを使用している場合は、EKS Pod Identity を使用して、必要なアクセス許可をアドオンに付与できます。EKS Pod Identity は、推奨オプションであり、最小特権、認証情報のローテーション、監査可能性などなどの利点を提供します。さらに、EKS Pod Identity を使用すると、クラスター作成自体の一部として EKS アドオンをインストールできます。

この方法を使用するには、まず EKS Pod Identity の関連付けの手順に従って IAM ロールを作成し、EKS Pod Identity エージェントを設定します。

Amazon CloudWatch Observability EKS アドオンをインストールします。アドオンをインストールするには、AWS CLI、Amazon EKS コンソール、AWS CloudFormation または Terraform を使用できます。

AWS CLI
AWS CLI を使用して Amazon CloudWatch Observability EKS アドオンをインストールするには

次のコマンドを入力します。my-cluster-name をクラスター名に置き換え、111122223333 をアカウント ID に置き換えます。my-role を EKS Pod Identity の関連付けステップで作成した IAM ロールに置き換えます。

aws iam attach-role-policy \ --role-name my-role \ --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy aws eks create-addon \ --addon-name amazon-cloudwatch-observability \ --cluster-name my-cluster-name \ --pod-identity-associations serviceAccount=cloudwatch-agent,roleArn=arn:aws:iam::111122223333:role/my-role
Amazon EKS console
Amazon EKS コンソールを使用して Amazon CloudWatch Observability EKS アドオンを追加するには
  1. Ahttps://console.aws.amazon.com/eks/home#/clusters で Amazon EKS コンソールを開きます。

  2. 左のナビゲーションペインで [クラスター] を選択してください。

  3. Amazon CloudWatch Observability EKS アドオンを設定するクラスターの名前を選択します。

  4. [アドオン] タブを選択してください。

  5. [その他のアドオンを入手] を選択してください。

  6. [アドオンを選択] ページで、次の操作を行います。

    1. [Amazon EKS アドオン] セクションで、[Amazon CloudWatch Observability] チェックボックスを選択します。

    2. [次へ] を選択します。

  7. [選択したアドオンセッティングの設定] ページで、次の操作を行います。

    1. 使用する [バージョン] を選択します。

    2. [アドオンアクセス] では、[EKS Pod Identity] を選択します。

    3. IAM ロールが設定されていない場合は、[推奨ロールを作成] を選択し、ステップ 3 の [名前、確認、および作成] になるまで [次へ] を選択します。必要に応じてロール名を変更することができます。それ以外の場合は、[ロールの作成] を選択し、アドオンページに戻り、作成した IAM ロールを選択します。

    4. (オプション) [オプションの構成設定] を展開できます。[コンフリクト解決方法] で [上書きする] を選択すると、既存のアドオンでの 1 つ以上の設定が、Amazon EKS アドオンの設定で上書きされます。このオプションが有効でない状態で既存の設定との競合が発生する場合は、オペレーションが失敗します。表示されたエラーメッセージを使用して、競合をトラブルシューティングできます。このオプションを選択する前に、自分で管理する必要のある設定が、Amazon EKS アドオンにより管理されていないことを確認してください。

    5. [次へ] を選択します。

  8. [確認と追加] ページで、[作成] を選択します。アドオンのインストールが完了した後、インストールしたアドオンが表示されます。

AWS CloudFormation
AWS CloudFormation を使用して Amazon CloudWatch Observability EKS アドオンをインストールするには
  1. まず、次の AWS CLI コマンドを実行して、必要な IAM ポリシーを IAM ロールにアタッチします。my-role を EKS Pod Identity の関連付けステップで作成したロールに置き換えます。

    aws iam attach-role-policy \ --role-name my-role \ --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
  2. 次に、以下のリソースを作成します。my-cluster-name をクラスターの名前に置き換え、111122223333 をアカウント ID に置き換え、my-role を EKS Pod Identity の関連付けステップで作成した IAM ロールに置き換えます。詳細については、「AWS::EKS::Addon」を参照してください。

    { "Resources": { "EKSAddOn": { "Type": "AWS::EKS::Addon", "Properties": { "AddonName": "amazon-cloudwatch-observability", "ClusterName": "my-cluster-name", "PodIdentityAssociations": [ { "ServiceAccount": "cloudwatch-agent", "RoleArn": "arn:aws:iam::111122223333:role/my-role" } ] } } } }
Terraform
Terraform を使用して Amazon CloudWatch Observability EKS アドオンをインストールするには
  1. 以下を使用します。my-cluster-name をクラスターの名前、111122223333 をアカウント ID、my-service-account-role を EKS Pod Identity 関連付け手順で作成した IAM ロールに置き換えます。

    詳細については、Terraform ドキュメントの「Resource: aws_eks_addon」を参照してください。

  2. resource "aws_iam_role_policy_attachment" "CloudWatchAgentServerPolicy" { policy_arn = "arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy" role = "my-role" } resource "aws_eks_addon" "example" { cluster_name = "my-cluster-name" addon_name = "amazon-cloudwatch-observability" pod_identity_associations { roleArn = "arn:aws:iam::111122223333:role/my-role" serviceAccount = "cloudwatch-agent" } }

オプション 2: ワーカーノードで IAM のアクセス許可を使用してインストールする

この方法を使用するには、まず次のコマンドを入力して IAM ポリシー CloudWatchAgentServerPolicy をワーカーノードにアタッチします。このコマンドでは、my-worker-node-role を Kubernetes ワーカーノードが使用する IAM ロールに置き換えます。

aws iam attach-role-policy \ --role-name my-worker-node-role \ --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy

Amazon CloudWatch Observability EKS アドオンをインストールします。アドオンをインストールするには、AWS CLI、コンソール、AWS CloudFormation または Terraform を使用できます。

AWS CLI
AWS CLI を使用して Amazon CloudWatch Observability EKS アドオンをインストールするには

次のコマンドを入力します。my-cluster-name を自分のクラスター名に置き換えます。

aws eks create-addon --addon-name amazon-cloudwatch-observability --cluster-name my-cluster-name
Amazon EKS console
Amazon EKS コンソールを使用して Amazon CloudWatch Observability EKS アドオンを追加するには
  1. Ahttps://console.aws.amazon.com/eks/home#/clusters で Amazon EKS コンソールを開きます。

  2. 左のナビゲーションペインで [クラスター] を選択してください。

  3. Amazon CloudWatch Observability EKS アドオンを設定するクラスターの名前を選択します。

  4. [アドオン] タブを選択してください。

  5. [その他のアドオンを入手] を選択してください。

  6. [アドオンを選択] ページで、次の操作を行います。

    1. [Amazon EKS アドオン] セクションで、[Amazon CloudWatch Observability] チェックボックスを選択します。

    2. [次へ] を選択します。

  7. [選択したアドオンセッティングの設定] ページで、次の操作を行います。

    1. 使用する [バージョン] を選択します。

    2. (オプション) [オプションの構成設定] を展開できます。[コンフリクト解決方法] で [上書きする] を選択すると、既存のアドオンでの 1 つ以上の設定が、Amazon EKS アドオンの設定で上書きされます。このオプションが有効でない状態で既存の設定との競合が発生する場合は、オペレーションが失敗します。表示されたエラーメッセージを使用して、競合をトラブルシューティングできます。このオプションを選択する前に、自分で管理する必要のある設定が、Amazon EKS アドオンにより管理されていないことを確認してください。

    3. [次へ] を選択します。

  8. [確認と追加] ページで、[作成] を選択します。アドオンのインストールが完了した後、インストールしたアドオンが表示されます。

AWS CloudFormation
AWS CloudFormation を使用して Amazon CloudWatch Observability EKS アドオンをインストールするには

my-cluster-name を自分のクラスター名に置き換えます。詳細については、「AWS::EKS::Addon」を参照してください。

{ "Resources": { "EKSAddOn": { "Type": "AWS::EKS::Addon", "Properties": { "AddonName": "amazon-cloudwatch-observability", "ClusterName": "my-cluster-name" } } } }
Helm chart
amazon-cloudwatch-observability Helm チャートを使用するには
  1. このチャートを使用するには、Helm をインストールしておく必要があります。Helm のインストールの詳細については、「Helm ドキュメント」を参照してください。

  2. Helm をインストールしたら、次のコマンドを入力します。my-cluster-name をクラスターの名前に置き換え、my-cluster-region をクラスターが実行されるリージョンに置き換えます。

    helm repo add aws-observability https://aws-observability.github.io/helm-charts helm repo update aws-observability helm install --wait --create-namespace --namespace amazon-cloudwatch amazon-cloudwatch-observability aws-observability/amazon-cloudwatch-observability --set clusterName=my-cluster-name --set region=my-cluster-region
Terraform
Terraform を使用して Amazon CloudWatch Observability EKS アドオンをインストールするには

my-cluster-name を自分のクラスター名に置き換えます。詳細については、「Resource: aws_eks_addon」を参照してください。

resource "aws_eks_addon" "example" { addon_name = "amazon-cloudwatch-observability" cluster_name = "my-cluster-name" }

オプション 3: IAM サービスアカウントロールを使用してインストールする (アドオンを使用する場合のみ)

この方法は、Amazon CloudWatch Observability EKS アドオンを使用している場合にのみ有効です。この方法を使用する前に、次の前提条件を確認してください。

  • Container Insights がサポートされているいずれかの AWS リージョン に、ノードがアタッチされ機能している Amazon EKS クラスターがある。サポートされているリージョンのリストについては、「Container Insights」を参照してください。

  • クラスターに kubectl がインストールされ、設定されている。詳細については、Amazon EKS ユーザーガイドの「kubectl のインストール」を参照してください。

  • eksctl がインストールされている。詳細については、「Amazon EKS ユーザーガイド」の「Installing or updating eksctl」を参照してください。

AWS CLI
AWS CLI を使用して IAM サービスアカウントロールを使用して Amazon CloudWatch Observability EKS アドオンをインストールするには
  1. クラスターに OpenID Connect (OIDC) プロバイダーがない場合、次のコマンドを入力して作成します。詳細については、「Amazon EKS ユーザーガイド」の「Configuring a Kubernetes service account to assume an IAM role」を参照してください。

    eksctl utils associate-iam-oidc-provider --cluster my-cluster-name --approve
  2. 次のコマンドを入力してポリシー CloudWatchAgentServerPolicy がアタッチされた IAM ロールを作成し、OIDC を使用してそのロールを引き受けるようにエージェントのサービスアカウントを設定します。my-cluster-name をクラスターの名前、my-service-account-role をサービスアカウントを関連付けるロールの名前に置き換えます。ロールがまだ存在しない場合は、eksctl によって作成されます。

    eksctl create iamserviceaccount \ --name cloudwatch-agent \ --namespace amazon-cloudwatch --cluster my-cluster-name \ --role-name my-service-account-role \ --attach-policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy \ --role-only \ --approve
  3. 次のコマンドを入力して、アドオンをインストールします。my-cluster-name をクラスターの名前、111122223333 をアカウント ID、my-service-account-role を前の手順で作成したIAM ロールに置き換えます。

    aws eks create-addon --addon-name amazon-cloudwatch-observability --cluster-name my-cluster-name --service-account-role-arn arn:aws:iam::111122223333:role/my-service-account-role
Amazon EKS console
コンソール上で、IAM サービスアカウントロールを使用して Amazon CloudWatch Observability EKS アドオンをインストールするには
  1. Ahttps://console.aws.amazon.com/eks/home#/clusters で Amazon EKS コンソールを開きます。

  2. 左のナビゲーションペインで [クラスター] を選択してください。

  3. Amazon CloudWatch Observability EKS アドオンを設定するクラスターの名前を選択します。

  4. [アドオン] タブを選択してください。

  5. [その他のアドオンを入手] を選択してください。

  6. [アドオンを選択] ページで、次の操作を行います。

    1. [Amazon EKS アドオン] セクションで、[Amazon CloudWatch Observability] チェックボックスを選択します。

    2. [次へ] を選択します。

  7. [選択したアドオンセッティングの設定] ページで、次の操作を行います。

    1. 使用する [バージョン] を選択します。

    2. アドオンアクセスの場合は、[サービスアカウントの IAM ロール (IRSA)] を選択します。

    3. アドオンアクセスボックスで IAM ロールを選択します。

    4. (オプション) [オプションの構成設定] を展開できます。[コンフリクト解決方法] で [上書きする] を選択すると、既存のアドオンでの 1 つ以上の設定が、Amazon EKS アドオンの設定で上書きされます。このオプションが有効でない状態で既存の設定との競合が発生する場合は、オペレーションが失敗します。表示されたエラーメッセージを使用して、競合をトラブルシューティングできます。このオプションを選択する前に、自分で管理する必要のある設定が、Amazon EKS アドオンにより管理されていないことを確認してください。

    5. [次へ] を選択します。

  8. [確認と追加] ページで、[作成] を選択します。アドオンのインストールが完了した後、インストールしたアドオンが表示されます。

Amazon EKS Hybrid Nodes の考慮事項

Container Insights はノードレベルのメトリクスの EC2 インスタンスメタデータサービス (IMDS) における可用性に依存するため、ノードレベルのメトリクスはハイブリッドノードでは利用できません。クラスター、ワークロード、Pod、コンテナレベルのメトリクスはハイブリッドノードで利用できます。

前のセクションの手順に従ってアドオンをインストールしたら、エージェントがハイブリッドノードで正常に実行できるように、アドオンマニフェストを更新する必要があります。クラスターの amazoncloudwatchagents リソースを編集し、RUN_WITH_IRSA 環境変数を追加して次のものと一致させます。

kubectl edit amazoncloudwatchagents -n amazon-cloudwatch cloudwatch-agent
apiVersion: v1
       items:
       - apiVersion: cloudwatch.aws.amazon.com/v1alpha1
         kind: AmazonCloudWatchAgent
         metadata:
           ...
           name: cloudwatch-agent
           namespace: amazon-cloudwatch
           ...
         spec:
           ...
           env:
           - name: RUN_WITH_IRSA # <-- Add this
             value: "True" # <-- Add this
           - name: K8S_NODE_NAME
             valueFrom:
               fieldRef:
                 fieldPath: spec.nodeName
                 ...
       

(オプション) その他の設定

コンテナログの収集をオプトアウトする

デフォルトでは、アドオンは Fluent Bit を使用してすべてのポッドからコンテナログを収集し、そのログを CloudWatch Logs に送信します。収集されるログについての詳細は、「Fluent Bit の設定」を参照してください。

注記

アドオンも Helm チャートも、クラスター内の既存の Fluentd リソースや Fluent Bit リソースを管理しません。アドオンや Helm チャートをインストールする前に、既存の Fluentd や Fluent Bit リソースを削除できます。あるいは、既存のセットアップを維持し、アドオンや Helm チャートから Fluent Bit もインストールされないようにするには、このセクションの指示に従ってこうしたインストールを無効にできます。

Amazon CloudWatch Observability EKS アドオンを使用している場合に、コンテナログの収集をオプトアウトするには、アドオンの作成時または更新時に次のオプションを渡します。

--configuration-values '{ "containerLogs": { "enabled": false } }'

Helm チャートを使用している場合に、コンテナログの収集をオプトアウトするには、アドオンの作成時または更新時に次のオプションを渡します。

--set containerLogs.enabled=false

カスタム Fluent Bit 設定を使用する

Amazon CloudWatch Observability EKS アドオンのバージョン 1.7.0 以降では、アドオンや Helm チャートを作成または更新するときに Fluent Bit 設定を変更できます。こうしてカスタマイズした Fluent Bit 設定は、アドオンでは詳細設定の containerLogs ルートレベルセクションで指定し、Helm チャートでは値のオーバーライドで指定します。このセクションでは、カスタマイズした Fluent Bit 設定を config セクション (Linux の場合) または configWindows セクション (Windows の場合) で指定します。config は、さらに次のサブセクションに分かれています。

  • serviceSERVICE 設定を表すセクションであり、Fluent Bit エンジンのグローバルな動作を定義します。

  • customParsers - グローバルな PARSER を表すセクションであり、これを含めると非構造化ログエントリを取得して、ログの処理とその後のフィルタリングが容易になるように構造化できます。

  • extraFiles - Fluent Bit conf ファイルを追加で含めることができるセクションです。デフォルトでは、次の 3 つの conf ファイルが含まれています。

    • application-log.conf – クラスターから CloudWatch Logs 内のロググループ /aws/containerinsights/my-cluster-name/application にアプリケーションログを送信するための conf ファイル。

    • dataplane-log.conf – CRI ログ、kubelet ログ、kube-proxy ログ、Amazon VPC CNI ログなど、クラスターのデータプレーンコンポーネントに対応するログを CloudWatch Logs のロググループ /aws/containerinsights/my-cluster-name/dataplane に送信するための conf ファイル。

    • host-log.conf – Linux 上の /var/log/dmesg/var/log/messages/var/log/secure と、Windows 上の System winlogs から CloudWatch のロググループ /aws/containerinsights/my-cluster-name/host にログを送信するための conf ファイル。

注記

サブセクション内のフィールドを 1 つだけ変更する場合でも、上記の個々のセクションをすべて設定してください。デフォルトで有効になっている機能を無効にすることがないように、下記に示したデフォルト設定をベースラインとして使用し、そのうえで適宜変更を加えることをお勧めします。Amazon EKS アドオンの詳細設定を変更するときや、Helm チャートの値のオーバーライドを指定するときには、以下の YAML 設定を使用できます。

クラスターの config セクションを確認するには、GitHub の aws-observability / helm-charts を参照し、インストールするアドオンまたは Helm チャートのバージョンに対応するリリースを見つけます。次に、/charts/amazon-cloudwatch-observability/values.yaml に移動して、fluentBit セクション内の containerLogsconfig セクション (Linux の場合) および configWindows セクション (Windows の場合) を探します。

例えば、バージョン 1.7.0 のデフォルトの Fluent Bit 設定は、ここで確認できます。

config を、Amazon EKS アドオンの詳細設定を使用して指定する場合や、Helm インストールの値のオーバーライドとして指定する場合は、YAML として指定することをお勧めします。YAML が次の構造に準拠していることを確認してください。

containerLogs: fluentBit: config: service: | ... customParsers: | ... extraFiles: application-log.conf: | ... dataplane-log.conf: | ... host-log.conf: | ...

次の例では、config はフラッシュ間隔のグローバル設定を 45 秒に変更します。Flush フィールドへの変更はこれだけですが、サービスサブセクション全体に対する SERVICE 定義を指定する必要があります。この例では、他のサブセクションにオーバーライドを指定しなかったため、そのサブセクションではデフォルトが使用されます。

containerLogs: fluentBit: config: service: | [SERVICE] Flush 45 Grace 30 Log_Level error Daemon off Parsers_File parsers.conf storage.path /var/fluent-bit/state/flb-storage/ storage.sync normal storage.checksum off storage.backlog.mem_limit 5M

次の設定例には、追加で Fluent ビット conf ファイルが含まれています。この例では、extraFiles の下にカスタム my-service.conf を追加しており、3 つのデフォルトの extraFiles に加えて、このファイルが含まれます。

containerLogs: fluentBit: config: extraFiles: my-service.conf: | [INPUT] Name tail Tag myservice.* Path /var/log/containers/*myservice*.log DB /var/fluent-bit/state/flb_myservice.db Mem_Buf_Limit 5MB Skip_Long_Lines On Ignore_Older 1d Refresh_Interval 10 [OUTPUT] Name cloudwatch_logs Match myservice.* region ${AWS_REGION} log_group_name /aws/containerinsights/${CLUSTER_NAME}/myservice log_stream_prefix ${HOST_NAME}- auto_create_group true

次の例では、既存の conf ファイルを extraFiles から完全に削除しています。空の文字列で上書きすることで、application-log.conf 全体が除外されます。extraFiles から application-log.conf を省いてもデフォルトの使用を示唆するだけであり、この例で示そうとしているのはそういうことではありません。同じことが、以前にカスタマイズして extraFiles に追加した conf ファイルを削除するといった場合にも言えます。

containerLogs: fluentBit: config: extraFiles: application-log.conf: ""

インストールされたポッドワークロードの Kubernetes 許容範囲を管理する

Amazon CloudWatch Observability EKS アドオンのバージョン 1.7.0 以降、アドオンと Helm チャートはアドオンまたは Helm チャートがインストールするポッドワークロード上ですべてのテイントを許容するようにデフォルトで Kubernetes の許容範囲を設定します。これにより、CloudWatch エージェントや Fluent Bit などのデーモンセットは、デフォルトでクラスター内のすべてのノードでポッドをスケジュールできるようになります。許容範囲とテイントの詳細については、Kubernetes ドキュメントの「Taints and Tolerations」を参照してください。

アドオンまたは Helm チャートによってデフォルトで設定される許容範囲は次のとおりです。

tolerations: - operator: Exists

アドオンの詳細設定を使用するときや、値のオーバーライドで Helm チャートをインストールまたはアップグレードするときに、tolerations フィールドをルートレベルで設定することで、デフォルトの許容範囲を上書きできます。例えば、次のようになります。

tolerations: - key: "key1" operator: "Exists" effect: "NoSchedule"

許容範囲を完全に省略するには、次のような設定を使用できます。

tolerations: []

許容範囲に加えた変更は、アドオンまたは Helm チャートがインストールするすべてのポッドワークロードに適用されます。

高速コンピューティングメトリクスの収集をオプトアウトする

オブザーバビリティが強化された Container Insights は、デフォルトでは高速化コンピューティングのモニタリングのためにメトリクスを収集します。NVIDIA GPU メトリクス、AWS Trainium と AWS Inferentia の AWS Neuron メトリクス、AWS Elastic Fabric Adapter (EFA) メトリクスなどです。

Amazon EKS ワークロードの NVIDIA GPU メトリクスは、デフォルトではバージョン v1.3.0-eksbuild.1 の EKS アドオンまたは Helm チャート、およびバージョン 1.300034.0 の CloudWatch エージェントから収集されます。収集されたメトリクスと前提条件のリストについては、「NVIDIA GPU メトリクス」を参照してください。

AWS Trainium および AWS Inferentia アクセラレーターの AWS Neuron メトリクスは、バージョン v1.5.0-eksbuild.1 の EKS アドオンまたは Helm チャート、およびバージョン 1.300036.0 の CloudWatch エージェントから収集されます。収集されたメトリクスと前提条件のリストについては、「AWS Trainium と AWS Inferentia の AWS Neuron メトリクス 」を参照してください。

Amazon EKS クラスター上の Linux ノードの AWS Elastic Fabric Adapter (EFA) メトリクスは、デフォルトではバージョン v1.5.2-eksbuild.1 の EKS アドオンまたは Helm チャート、およびバージョン 1.300037.0 の CloudWatch エージェントから収集されます。収集されたメトリクスと前提条件のリストについては、「AWS Elastic Fabric Adapter (EFA) メトリクス 」を参照してください。

CloudWatch エージェント設定ファイルの accelerated_compute_metrics フィールドを false に設定することで、これらのメトリクスの収集をオプトアウトできます。このフィールドは、CloudWatch 設定ファイルの metrics_collected セクションの kubernetes セクションで利用できます。以下は、オプトアウトの設定の例です。カスタム CloudWatch エージェント設定の使用方法の詳細については、次のセクション「カスタム CloudWatch エージェント設定を使用する」を参照してください。

{ "logs": { "metrics_collected": { "kubernetes": { "enhanced_container_insights": true, "accelerated_compute_metrics": false } } } }

カスタム CloudWatch エージェント設定を使用する

CloudWatch エージェントを使用して他のメトリクスやログやトレースを収集するには、Container Insights と CloudWatch Application Signals を有効にしたままカスタム設定を指定します。そのためには、EKS アドオンや Helm チャートを作成または更新するときに使用できる詳細設定を開き、エージェントキーの下にある設定キー内に CloudWatch エージェント設定ファイルを埋め込みます。次に、デフォルトのまま他に設定を行わない場合のエージェント設定を示します。

重要

他に構成設定を行って設定をカスタマイズした場合は、そのカスタム設定がエージェントで使用されるデフォルト設定よりも優先されます。オブザーバビリティが強化された Container Insights や CloudWatch Application Signals など、デフォルトで有効になっている機能を意図せず無効にしないように注意してください。エージェント設定をカスタマイズしなければならない場合は、以下のデフォルト設定をベースラインとして使用し、適宜必要な変更を加えることをお勧めします。

  • Amazon CloudWatch Observability EKS アドオンを使用する場合

    --configuration-values '{ "agent": { "config": { "logs": { "metrics_collected": { "application_signals": {}, "kubernetes": { "enhanced_container_insights": true } } }, "traces": { "traces_collected": { "application_signals": {} } } } }'
  • Helm チャートを使用する場合

    --set agent.config='{ "logs": { "metrics_collected": { "application_signals": {}, "kubernetes": { "enhanced_container_insights": true } } }, "traces": { "traces_collected": { "application_signals": {} } } }'

次の例は、Windows 上の CloudWatch エージェントのデフォルトエージェント設定を示しています。Windows 上の CloudWatch エージェントは、カスタム設定をサポートしていません。

{ "logs": { "metrics_collected": { "kubernetes": { "enhanced_container_insights": true }, } } }

アドミッションウェブフック TLS 証明書の管理

Amazon CloudWatch Observability EKS アドオンと Helm チャートは、Kubernetes アドミッションウェブフックを利用して、AmazonCloudWatchAgent および Instrumentation カスタムリソース (CR) リクエストのほか、オプションで CloudWatch Application Signals が有効になっている場合にはクラスター上の Kubernetes ポッドリクエストも、検証したうえで必要な変更を加えます。Kubernetes の場合、安全な通信を確保するためには、API サーバーからの信頼が設定された TLS 証明書がウェブフックに必要です。

デフォルトでは、Amazon CloudWatch Observability EKS アドオンと Helm チャートは、API サーバーとウェブフックサーバー間の通信を保護するために、自己署名 CA とこの CA の署名入りの TLS 証明書を自動生成します。この自動生成された証明書の有効期限はデフォルトで 10 年で、有効期限は自動更新されません。また、このアドオンや Helm チャートがアップグレードされるか再インストールされるたびに、CA バンドルと証明書が再生成されるため、有効期限がリセットされます。自動生成された証明書のデフォルトの有効期限を変更する場合は、アドオンを作成または更新するときに以下のように追加の設定を行います。expiry-in-days を目的の有効期限 (日) に置き換えてください。

  • これを Amazon CloudWatch Observability EKS アドオンに使用する

    --configuration-values '{ "admissionWebhooks": { "autoGenerateCert": { "expiryDays": expiry-in-days } } }'
  • これを Helm チャートに使用する

    --set admissionWebhooks.autoGenerateCert.expiryDays=expiry-in-days

安全性の高い多機能な証明機関を利用できるように、cert-manager がオプトインでサポートされています。Kubernetes で TLS 証明書を管理するのに広く採用されているソリューションであり、証明書を取得、更新、管理、使用するプロセスを簡素化できます。これにより、証明書が有効で最新の状態であることが保証されます。有効期限前の設定しておいた時刻になると、証明書が更新されます。また、AWS Certificate Manager プライベート認証機関などサポートされているさまざまな発行元から簡単に証明書を発行できます。

クラスターで TLS 証明書を管理する場合のベストプラクティスを確認すること、および本番環境では cert-manager を選択することをお勧めします。アドミッションウェブフック TLS 証明書を管理できるように cert-manager を有効にすることにした場合は、Amazon CloudWatch Observability EKS アドオンや Helm チャートをインストールする前に、Amazon EKS クラスターに cert-manager をプリインストールしておく必要があることに注意してください。使用可能なインストールオプションの詳細については、cert-manager のドキュメントを参照してください。インストールを終えたら、cert-manager を使用して、アドミッションウェブフック TLS 証明書を管理することもできます。その場合は、追加で以下の設定を行います。

  • Amazon CloudWatch Observability EKS アドオンを使用している場合

    --configuration-values '{ "admissionWebhooks": { "certManager": { "enabled": true } } }'
  • Helm チャートを使用している場合

    --set admissionWebhooks.certManager.enabled=true
--configuration-values '{ "admissionWebhooks": { "certManager": { "enabled": true } } }'

詳細設定では、ここで説明するように、デフォルトで自己署名発行者が使用されます。

Amazon EBS ボリューム ID を収集する

パフォーマンスログで Amazon EBS ボリューム ID を収集する場合は、ワーカーノードまたはサービスアカウントにアタッチされた IAM ロールに別のポリシーを追加する必要があります。以下をインラインポリシーとして追加します。詳細については、「Adding and Removing IAM Identity Permissions」を参照してください。

{ "Version": "2012-10-17", "Statement": [ { "Action": [ "ec2:DescribeVolumes" ], "Resource": "*", "Effect": "Allow" } ] }

Amazon CloudWatch Observability EKS アドオンや Helm チャートのトラブルシューティング

以下の情報を参考にして、Amazon CloudWatch Observability EKS アドオンや Helm チャートに関する問題のトラブルシューティングを行います。

Amazon CloudWatch Observability EKS アドオンや Helm チャートの更新と削除

Amazon CloudWatch Observability EKS アドオンを更新または削除する手順については、「Amazon EKS アドオンの管理」を参照してください。アドオン名には amazon-cloudwatch-observability を使用してください。

クラスター内の Helm チャートを削除するには、次のコマンドを入力します。

helm delete amazon-cloudwatch-observability -n amazon-cloudwatch --wait

Amazon CloudWatch Observability EKS アドオンや Helm チャートで使用される CloudWatch エージェントのバージョンを確認する

Amazon CloudWatch Observability EKS アドオンと Helm チャートは、使用中の CloudWatch エージェントのバージョンなど、クラスター上の CloudWatch エージェントデーモンセットの動作を制御する AmazonCloudWatchAgent のカスタムリソースをインストールします。以下のコマンドを入力して、クラスターにインストールされている AmazonCloudWatchAgent カスタムリソースがすべて記載されたリストを取得できます。

kubectl get amazoncloudwatchagent -A

このコマンドの出力を調べれば、CloudWatch エージェントのバージョンを確認できるはずです。このほか、amazoncloudwatchagent リソースを記述するか、クラスターで動作しているいずれかの cloudwatch-agent-* ポッドを記述して、使用中のイメージを調べることもできます。

アドオンや Helm チャートの管理時の ConfigurationConflict の処理

Amazon CloudWatch Observability EKS アドオンや Helm チャートのインストールまたは更新時に、既存のリソースによって生じたエラーが見られたとします。これはおそらく、CloudWatch エージェントとその関連コンポーネント (ServiceAccount、ClusterRole、ClusterRoleBinding など) がクラスターにインストールされていることが原因と考えられます。

アドオンによって表示されるエラーには、Conflicts found when trying to apply. Will not continue due to resolve conflicts mode などがあります。

Helm チャートによって表示されるエラーは、Error: INSTALLATION FAILED: Unable to continue with install and invalid ownership metadata. のようになります。

このアドオンや Helm チャートによって CloudWatch エージェントとその関連コンポーネントがインストールされるときに内容の変更が検出されると、デフォルトではインストールまたは更新が失敗します。これによって、クラスター上にあるリソースの状態が上書きされることを防いでいます。

Amazon CloudWatch Observability EKS アドオンへのオンボード時にこのエラーが発生した場合は、クラスターにインストール済みの CloudWatch エージェントセットアップを削除した後に EKS アドオンや Helm チャートをインストールすると良いでしょう。カスタムエージェント設定など、元の CloudWatch エージェントセットアップへのカスタマイズを必ずバックアップし、アドオンや Helm チャートを次回インストールまたは更新するときにそれらのカスタマイズを適用してください。Container Insights へのオンボーディングを目的に CloudWatch エージェントをインストール済みである場合は、「Container Insights の CloudWatch エージェントと Fluent Bit の削除」で詳細を確認してください。

その他に、アドオンでサポートされている設定オプションで OVERWRITE を指定して競合を解決することも可能です。このオプションを使用すると、クラスター上の競合を上書きしてアドオンのインストールまたは更新を継続できます。Amazon EKS コンソールを使用する場合、アドオンの作成または更新時に [オプションの構成設定] を選択すると、[競合の解決方法] が表示されます。AWS CLI を使用する場合は、コマンドに --resolve-conflicts OVERWRITE を指定することで、アドオンを作成または更新できます。

Java Management Extensions (JMX) メトリクスの収集

CloudWatch エージェントは、Amazon EKS で Java Management Extensions (JMX) メトリクスの収集をサポートしています。これにより、Amazon EKS クラスターで実行されている Java アプリケーションから追加のメトリクスを収集し、パフォーマンス、メモリ使用量、トラフィック、その他の重要なメトリクスに関するインサイトを得ることができます。詳細については、「Java Management Extensions (JMX) メトリクスの収集」を参照してください。

Kueue メトリクスの有効化

CloudWatch Observability EKS アドオンのバージョン v2.4.0-eksbuild.1 以降、Container Insights for Amazon EKS は Amazon EKS クラスターから Kueue メトリクスの収集をサポートします。これらのメトリクスの詳細については、「Kueue メトリクス 」を参照してください。

Amazon SageMaker AI Hyperpod Task Governance EKS アドオンを使用している場合、[前提条件] セクションの手順をスキップし、「設定フラグの有効化」の手順にのみに従います。

前提条件

Amazon EKS クラスターに Kueue をインストールする前に、マニフェストファイルで次の更新を行います。

  1. Kueue のオプションのクラスターキューリソースメトリクスを有効にします。これを行うには、kueue-system ConfigMap でインラインの controller_manager_config.yaml を変更します。metrics セクションで、enableClusterQueueResources: true 行を追加またはコメント解除します。

    apiVersion: v1 data: controller_manager_config.yaml: | apiVersion: config.kueue.x-k8s.io/v1beta1 kind: Configuration health: healthProbeBindAddress: :8081 metrics: bindAddress: :8080 enableClusterQueueResources: true <-- ADD/UNCOMMENT THIS LINE
  2. デフォルトでは、すべての k8s サービスはクラスター全体で利用できます。Kueue は、メトリクスを公開するためのサービス kueue-controller-manager-metrics-service を作成します。メトリクスの観測値の重複を防止するには、このサービスを変更し、同じノードからメトリクスサービスにのみアクセス権を許可します。これを行うには、kueue-controller-manager-metrics-service 定義に internalTrafficPolicy: Local 行を追加します。

    apiVersion: v1 kind: Service metadata: labels: ... name: kueue-controller-manager-metrics-service namespace: kueue-system spec: ports: - name: https port: 8443 protocol: TCP targetPort: https internalTrafficPolicy: Local <-- ADD THIS LINE selector: control-plane: controller-manager
  3. 最後に、kueue-controller-manager ポッドによって kube-rbac-proxy コンテナが作成されます。現在、このコンテナには高レベルのログ記録の詳細度があり、メトリクススクレイパーが kueue-controller-manager-metrics-service にアクセスすると、クラスターのベアラートークンがそのコンテナによってログ記録される原因になります。このログ記録の詳細を減らすことをお勧めします。Kueue によって配布されるマニフェストのデフォルト値は 10 です。0 に変更することをお勧めします。

    apiVersion: apps/v1 kind: Deployment metadata: labels: ... name: kueue-controller-manager namespace: kueue-system spec: ... template: ... spec: containers: ... - args: - --secure-listen-address=0.0.0.0:8443 - --upstream=http://127.0.0.1:8080/ - --logtostderr=true - --v=0 <-- CHANGE v=10 TO v=0 image: gcr.io/kubebuilder/kube-rbac-proxy:v0.8.0 name: kube-rbac-proxy ...

設定フラグの有効化

Kueue メトリクスを有効にするには、アドオンの追加設定で kueue_container_insights を有効にする必要があります。これを行うには、AWS CLI を使用して EKS Observability アドオンを設定するか、Amazon EKS コンソールを使用します。

次のいずれかの方法で EKS Observability アドオンを正常にインストールできたら、HyperPod コンソールの [ダッシュボード] タブで Amazon EKS クラスターメトリクスを表示できます。

AWS CLI
AWS CLI を使用して Kueue メトリクスを有効にする方法
  • 次の AWS CLI コマンドを入力してアドオンをインストールします。

    aws eks create-addon --cluster-name cluster-name --addon-name amazon-cloudwatch-observability --configuration-values "configuration_json_file"

    次の例は、設定値を持つ JSON ファイルです。

    { "agent": { "config": { "logs": { "metrics_collected": { "kubernetes": { "kueue_container_insights": true, "enhanced_container_insights": true }, "application_signals": { } } }, "traces": { "traces_collected": { "application_signals": { } } } }, }, }
Amazon EKS console
Amazon EKS コンソールを使用して Kueue メトリクスを有効にする方法
  1. Ahttps://console.aws.amazon.com/eks/home#/clusters で Amazon EKS コンソールを開きます。

  2. クラスターの名前を選択します。

  3. [アドオン] を選択します。

  4. リストで [Amazon CloudWatch Observability] アドオンを見つけてインストールします。これを行うとき、[オプションの設定] を選択して次の JSON 設定値を含めます。

    { "agent": { "config": { "logs": { "metrics_collected": { "kubernetes": { "kueue_container_insights": true, "enhanced_container_insights": true }, "application_signals": { } } }, "traces": { "traces_collected": { "application_signals": { } } } }, }, }

OpenTelemetry コレクター設定ファイルの追加

CloudWatch エージェントは、独自の設定ファイルとともに、補足的な OpenTelemetry コレクター設定ファイルをサポートします。この機能を使用すると、CloudWatch エージェント設定を通じて CloudWatch Application Signals や Container Insights などの CloudWatch エージェント機能が使用できます。また、単一のエージェントで既存の OpenTelemetry コレクター設定を取り込むこともできます。

CloudWatch エージェントによって自動的に作成されたパイプラインとのマージ競合を防ぐには、OpenTelemetry コレクター設定の各コンポーネントおよびパイプラインにカスタムサフィックスを追加することをお勧めします。これにより、競合やマージ競合を防ぐことができます。

  • Amazon CloudWatch Observability EKS アドオンを使用している場合

    --configuration-values file://values.yaml

    or

    --configuration-values ' agent: otelConfig: receivers: otlp/custom-suffix: protocols: http: {} exporters: awscloudwatchlogs/custom-suffix: log_group_name: "test-group" log_stream_name: "test-stream" service: pipelines: logs/custom-suffix: receivers: [otlp/custom-suffix] exporters: [awscloudwatchlogs/custom-suffix] '
  • Helm チャートを使用している場合

    --set agent.otelConfig=' receivers: otlp/custom-suffix: protocols: http: {} exporters: awscloudwatchlogs/custom-suffix: log_group_name: "test-group" log_stream_name: "test-stream" service: pipelines: logs/custom-suffix: receivers: [otlp/custom-suffix] exporters: [awscloudwatchlogs/custom-suffix] '