**このページの改善にご協力ください** このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。 # コンテナネットワークのオブザーバビリティを使用して Kubernetes ワークロードのトラフィックをモニタリングする Amazon EKS は、コンテナネットワーク環境に関するより深いインサイトを提供する拡張ネットワークのオブザーバビリティ機能を提供します。これらの機能は、AWS における Kubernetes ネットワーク環境をよりよく理解し、モニタリングし、トラブルシューティングするのに役立ちます。強化されたコンテナネットワークのオブザーバビリティでは、クラスタートラフィック、AZ 間フロー、AWS サービス全体にわたって、事前の異常検出をより効果的に行うために、ネットワーク関連のきめ細かなメトリクスを活用できます。これらのメトリクスを使用して、システムパフォーマンスを測定し、任意のオブザーバビリティスタックで基盤となるメトリクスを視覚化できます。 さらに、Amazon EKS は、より迅速な根本原因分析のために、正確なトラブルシューティングを加速および強化するネットワークモニタリングの視覚化を AWS コンソールで提供するようになりました。これらの視覚化機能を活用することで、再送信や再送信タイムアウトを引き起こしているトップトーカーやネットワークフローを特定し、インシデント中の死角を排除することもできます。 これらの機能は、[Amazon CloudWatch Network Flow Monitor](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-NetworkFlowMonitor.html) によって有効化されています。 ## ユースケース ### ネットワークパフォーマンスを測定して異常を検出する いくつかのチームは、システムのパフォーマンスを測定し、システムメトリクスを視覚化し、特定のしきい値を超えた場合にアラームを受け取れるオブザーバビリティスタックを標準化しています。EKS のコンテナネットワークのオブザーバビリティは、スクレイピング可能な主要なシステムメトリクスを公開することで、ポッドおよびワーカーノードレベルでシステムのネットワークパフォーマンスのオブザーバビリティを拡張し、これと整合します。 ### コンソールの視覚化を活用してより正確なトラブルシューティングを行う モニタリングシステムからアラームが発生した場合は、問題が発生したクラスターとワークロードに焦点を絞り込む必要があります。これを支援するために、EKS コンソールの視覚化を活用すると、クラスターレベルで調査範囲を絞り込み、再送信、再送信タイムアウト、転送データ量の原因となっているネットワークフローの特定を高速化できます。 ### Amazon EKS 環境でトップトーカーを追跡する 多くのチームは、プラットフォームの基盤として EKS を実行し、EKS をアプリケーション環境におけるネットワークアクティビティの中心にしています。この機能のネットワークモニタリング機能を使用すると、クラスター内、AZ 間、さらに AWS 内の外部宛先 (DynamoDB と S3) や AWS クラウド外 (インターネットまたはオンプレミス) へのトラフィックのうち、(データ量で測定した場合に) 最も多くのトラフィックを発生させているワークロードを追跡できます。さらに、再送信、再送信タイムアウト、および転送データ量に基づいて、これらの各フローのパフォーマンスをモニタリングできます。 ## 機能 1. パフォーマンスメトリクス - この機能を使用すると、EKS クラスター内で実行されている Network Flow Monitor (NFM) エージェントから、ポッドとワーカーノードのネットワーク関連のシステムメトリクスを直接スクレイピングできます。 1. サービスマップ - この機能では、クラスター内のワークロード間の相互通信を動的に視覚化し、通信しているポッド間のネットワークフローに関連する主要なメトリクス (再送信 - RT、再送信タイムアウト - RTO、転送データ量 - DT) を迅速に把握できます。 1. フローテーブル - このテーブルでは、AWS サービスビュー、クラスタービュー、外部ビューの 3 つの異なる観点から、クラスター内の Kubernetes ワークロード全体におけるトップトーカーをモニタリングできます。ビューごとに、送信元ポッドとその送信先の間における再送信、再送信タイムアウト、転送データ量を確認できます。 + AWS サービスビュー: AWS サービス (DynamoDB および S3) へのトップトーカーを表示します + クラスタービュー: クラスター内のトップトーカーを表示します (東西方向) + 外部ビュー: AWS 外のクラスター外宛先へのトップトーカーを表示します ## はじめに 開始するには、新規または既存のクラスターの EKS コンソールでコンテナネットワークオブザーバビリティを有効にします。これにより、Network Flow Monitor (NFM) の依存関係 ([スコープ](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_CreateScope.html)と[モニター](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_CreateMonitor.html)リソース) の作成が自動化されます。さらに、[Network Flow Monitor Agent アドオン](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-NetworkFlowMonitor-agents-kubernetes-eks.html)をインストールする必要があります。または、` AWS CLI`、[EKS API](https://docs.aws.amazon.com/eks/latest/APIReference/API_Operations_Amazon_Elastic_Kubernetes_Service.html) (アドオン用)、[NFM API](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-NetworkFlowMonitor-API-operations.html)、あるいは Infrastructure as Code ([Terraform](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/networkflowmonitor_monitor) など) を使用して、これらの依存関係をインストールすることもできます。これらの依存関係を設定したら、NFM エージェントからポッドとワーカーノードのネットワークパフォーマンスメトリクスをスクレイピングするように、任意のモニタリングツールを設定できます。ワークロードのネットワークアクティビティとパフォーマンスを視覚化するには、クラスターのオブザーバビリティダッシュボードの [ネットワーク] タブから EKS コンソールに移動します。 EKS で Network Flow Monitor を使用すると、既存のオブザーバビリティワークフローとテクノロジースタックを維持しながら、EKS 環境のネットワークレイヤーの理解と最適化をさらに促進する一連の追加機能を活用できます。詳細については、[こちらの Network Flow Monitor の料金](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-NetworkFlowMonitor.pricing.html)を参照してください。 ## 前提条件と重要な注意事項 1. 上記のように、EKS コンソールからコンテナネットワークオブザーバビリティを有効にすると、基盤となる NFM リソースの依存関係 (スコープとモニター) が自動的に作成され、NFM 用 EKS アドオンのインストールプロセスが案内されます。 1. Terraform などの Infrastructure as Code (IaC) を使用してこの機能を有効にする場合は、NFM スコープ、NFM モニター、NFM 用 EKS アドオンの依存関係を IaC で定義する必要があります。さらに、[Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html) または[サービスアカウントの IAM ロール (IRSA)](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) を使用して、[関連するアクセス許可](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchNetworkFlowMonitorAgentPublishPolicy.html)を EKS アドオンに付与する必要があります。 1. NFM エージェントの EKS アドオンでは、最小バージョン 1.1.0 を実行している必要があります。 1. Network Flow Monitor リソースをサポートするには、[Terraform AWS Provider](https://github.com/hashicorp/terraform-provider-aws) の v6.21.0 以降を使用する必要があります。 ### 必要な IAM 許可 #### NFM エージェント用 EKS アドオン `CloudWatchNetworkFlowMonitorAgentPublishPolicy` の [AWS 管理ポリシー](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchNetworkFlowMonitorAgentPublishPolicy.html)は、Pod Identity で使用できます。このポリシーには、NFM エージェントがテレメトリレポート (メトリクス) を Network Flow Monitor エンドポイントに送信するためのアクセス許可が含まれています。 ``` { "Version" : "2012-10-17", "Statement" : [ { "Effect" : "Allow", "Action" : [ "networkflowmonitor:Publish" ], "Resource" : "*" } ] } ``` #### EKS コンソールでのコンテナネットワークのオブザーバビリティ 機能を有効にし、コンソールでサービスマップとフローテーブルを視覚化するには、次のアクセス許可が必要です。 ``` { "Version" : "2012-10-17", "Statement" : [ { "Effect": "Allow", "Action": [ "networkflowmonitor:ListScopes", "networkflowmonitor:ListMonitors", "networkflowmonitor:GetScope", "networkflowmonitor:GetMonitor", "networkflowmonitor:CreateScope", "networkflowmonitor:CreateMonitor", "networkflowmonitor:TagResource", "networkflowmonitor:StartQueryMonitorTopContributors", "networkflowmonitor:StopQueryMonitorTopContributors", "networkflowmonitor:GetQueryStatusMonitorTopContributors", "networkflowmonitor:GetQueryResultsMonitorTopContributors" ], "Resource": "*" } ] } ``` ## AWS CLI、EKS API、NFM API の使用 ``` #!/bin/bash # Script to create required Network Flow Monitor resources set -e CLUSTER_NAME="my-eks-cluster" CLUSTER_ARN="arn:aws:eks:{Region}:{Account}:cluster/{ClusterName}" REGION="us-west-2" AGENT_NAMESPACE="amazon-network-flow-monitor" echo "Creating Network Flow Monitor resources..." # Check if Network Flow Monitor agent is running in the cluster echo "Checking for Network Flow Monitor agent in cluster..." if kubectl get pods -n "$AGENT_NAMESPACE" --no-headers 2>/dev/null | grep -q "Running"; then echo "Network Flow Monitor agent exists and is running in the cluster" else echo "Network Flow Monitor agent not found. Installing as EKS addon..." aws eks create-addon \ --cluster-name "$CLUSTER_NAME" \ --addon-name "$AGENT_NAMESPACE" \ --region "$REGION" echo "Network Flow Monitor addon installation initiated" fi # Get Account ID ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) echo "Cluster ARN: $CLUSTER_ARN" echo "Account ID: $ACCOUNT_ID" # Check for existing scope echo "Checking for existing Network Flow Monitor Scope..." EXISTING_SCOPE=$(aws networkflowmonitor list-scopes --region $REGION --query 'scopes[0].scopeArn' --output text 2>/dev/null || echo "None") if [ "$EXISTING_SCOPE" != "None" ] && [ "$EXISTING_SCOPE" != "null" ]; then echo "Using existing scope: $EXISTING_SCOPE" SCOPE_ARN=$EXISTING_SCOPE else echo "Creating new Network Flow Monitor Scope..." SCOPE_RESPONSE=$(aws networkflowmonitor create-scope \ --targets "[{\"targetIdentifier\":{\"targetId\":{\"accountId\":\"${ACCOUNT_ID}\"},\"targetType\":\"ACCOUNT\"},\"region\":\"${REGION}\"}]" \ --region $REGION \ --output json) SCOPE_ARN=$(echo $SCOPE_RESPONSE | jq -r '.scopeArn') echo "Scope created: $SCOPE_ARN" fi # Create Network Flow Monitor with EKS Cluster as local resource echo "Creating Network Flow Monitor..." MONITOR_RESPONSE=$(aws networkflowmonitor create-monitor \ --monitor-name "${CLUSTER_NAME}-monitor" \ --local-resources "type=AWS::EKS::Cluster,identifier=${CLUSTER_ARN}" \ --scope-arn "$SCOPE_ARN" \ --region $REGION \ --output json) MONITOR_ARN=$(echo $MONITOR_RESPONSE | jq -r '.monitorArn') echo "Monitor created: $MONITOR_ARN" echo "Network Flow Monitor setup complete!" echo "Monitor ARN: $MONITOR_ARN" echo "Scope ARN: $SCOPE_ARN" echo "Local Resource: AWS::EKS::Cluster (${CLUSTER_ARN})" ``` ## Infrastructure as Code (IaC) の使用 ### Terraform Terraform を使用して AWS クラウドインフラストラクチャを管理している場合は、次のリソース設定を含めることで、クラスターのコンテナネットワークオブザーバビリティを有効にできます。 #### NFM スコープ ``` data "aws_caller_identity" "current" {} resource "aws_networkflowmonitor_scope" "example" { target { region = "us-east-1" target_identifier { target_type = "ACCOUNT" target_id { account_id = data.aws_caller_identity.current.account_id } } } tags = { Name = "example" } } ``` #### NFM モニター ``` resource "aws_networkflowmonitor_monitor" "example" { monitor_name = "eks-cluster-name-monitor" scope_arn = aws_networkflowmonitor_scope.example.scope_arn local_resource { type = "AWS::EKS::Cluster" identifier = aws_eks_cluster.example.arn } remote_resource { type = "AWS::Region" identifier = "us-east-1" # this must be the same region that the cluster is in } tags = { Name = "example" } } ``` #### NFM 用 EKS アドオン ``` resource "aws_eks_addon" "example" { cluster_name = aws_eks_cluster.example.name addon_name = "aws-network-flow-monitoring-agent" } ``` ## 動作の仕組み ### パフォーマンスメトリクス #### システムメトリクス (Prometheus や Grafana などの) サードパーティ (3P) ツールを使用して EKS 環境を監視している場合、サポートされているシステムメトリクスを Network Flow Monitor エージェントから直接スクレイピングできます。これらのメトリクスをモニタリングスタックに送信することで、ポッドおよびワーカーノードレベルでシステムのネットワークパフォーマンスの測定を拡張できます。使用可能なメトリクスは、サポートされているシステムメトリクスの表に一覧表示されています。 ![\[システムメトリクスのスクレイピングの図\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/nfm-eks-metrics-workflow.png) これらのメトリクスを有効にするには、インストールプロセス中に、設定変数を使用して次の環境変数を上書きします (https://aws.amazon.com/blogs/containers/amazon-eks-add-ons-advanced-configuration/ を参照)。 ``` OPEN_METRICS: Enable or disable open metrics. Disabled if not supplied Type: String Values: [“on”, “off”] OPEN_METRICS_ADDRESS: Listening IP address for open metrics endpoint. Defaults to 127.0.0.1 if not supplied Type: String OPEN_METRICS_PORT: Listening port for open metrics endpoint. Defaults to 80 if not supplied Type: Integer Range: [0..65535] ``` #### フローレベルのメトリクス さらに、Network Flow Monitor は、再送信、再送信タイムアウト、転送データ量といったフローレベルのメトリクスと共にネットワークフローデータをキャプチャします。このデータは Network Flow Monitor によって処理され、EKS コンソールで視覚化され、クラスターの環境内のトラフィックと、これらのフローレベルのメトリクスに基づいてパフォーマンスが示されます。 以下の図は、両方のタイプのメトリクス (システムレベルとフローレベル) を活用して、運用インテリジェンスを高めるワークフローを示しています。 ![\[パフォーマンスメトリクスが異なるワークフローの図\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/nfm-eks-metrics-types-workflow.png) 1. プラットフォームチームは、モニタリングスタック内でシステムメトリクスを収集して視覚化できます。アラートを設定することで、NFM エージェントのシステムメトリクスを使用して、ポッドまたはワーカーノードに影響を与えるネットワークの異常や問題を検出できます。 1. 次のステップとして、プラットフォームチームは EKS コンソールのネイティブな視覚化を活用し、フローの表現とそれに関連するメトリクスに基づいて、調査範囲をさらに絞り込み、トラブルシューティングを高速化できます。 重要な注意点: NFM エージェントからのシステムメトリクスのスクレイピングと、NFM エージェントがフローレベルのメトリクスを NFM バックエンドにプッシュするプロセスは、互いに独立したプロセスです。 ##### サポートされているシステムメトリクス 重要な注意点: システムメトリクスは [OpenMetrics](https://openmetrics.io/) 形式でエクスポートされます。 | メトリクス名 | タイプ | ディメンション | 説明 | | --- | --- | --- | --- | | ingress\$1flow | ゲージ | instance\$1id、iface、ポッド、名前空間、ノード | Ingress TCP フローカウント (TcpPassiveOpens) | | egress\$1flow | ゲージ | instance\$1id、iface、ポッド、名前空間、ノード | Egress TCP フローカウント (TcpActiveOpens) | | ingress\$1packets | ゲージ | instance\$1id、iface、ポッド、名前空間、ノード | 受信パケット数 (デルタ) | | egress\$1packets | ゲージ | instance\$1id、iface、ポッド、名前空間、ノード | 送信パケット数 (デルタ) | | ingress\$1bytes | ゲージ | instance\$1id、iface、ポッド、名前空間、ノード | 入力バイト数 (デルタ) | | egress\$1bytes | ゲージ | instance\$1id、iface、ポッド、名前空間、ノード | 出力バイト数 (デルタ) | | bw\$1in\$1allowance\$1exceeded | ゲージ | instance\$1id、eni、ノード | インバウンド帯域幅の制限によりキューに入れられた/ドロップされたパケット | | bw\$1out\$1allowance\$1exceeded | ゲージ | instance\$1id、eni、ノード | アウトバウンド帯域幅の制限によりキューに入れられた/ドロップされたパケット | | pps\$1allowance\$1exceeded | ゲージ | instance\$1id、eni、ノード | 双方向 PPS 制限によりキューに入れられた/ドロップされたパケット | | conntrack\$1allowance\$1exceeded | ゲージ | instance\$1id、eni、ノード | 接続追跡制限によりドロップされたパケット | | linklocal\$1allowance\$1exceeded | ゲージ | instance\$1id、eni、ノード | ローカルプロキシサービスの PPS 制限によりドロップされたパケット | ##### サポートされているフローレベルのメトリクス | メトリクス名 | 型 | 説明 | | --- | --- | --- | | TCP 再送信 | Counter | 送信中に失われた、または破損したパケットを送信者が再送信した回数。 | | TCP 再送信タイムアウト | Counter | 送信中にパケットが失われたかどうかを判断するために、送信者が待機期間を開始した回数。 | | 転送データ量 (バイト) | Counter | 特定のフローの送信元と送信先の間で転送されるデータの量。 | ### サービスマップとフローテーブル ![\[NFM と EKS の連携方法の図\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/nfm-eks-workflow.png) 1. Network Flow Monitor エージェントは、インストールされると、すべてのワーカーノードで DaemonSet として実行され、30 秒ごとに、(転送データ量に基づいて) 上位 500 件のネットワークフローを収集します。 1. これらのネットワークフローは、AZ 内、AZ 間、EC2 → S3, EC2 → DynamoDB (DDB)、未分類のカテゴリに分類されます。各フローには、再送信、再送信タイムアウト、転送データ量 (バイト単位) の 3 つのメトリクスが関連付けられています。 + AZ 内 - 同じ AZ 内のポッド間のネットワークフロー + AZ 間 - 異なる AZ 間のポッド間のネットワークフロー + EC2 → S3 - ポッドから S3 へのネットワークフロー + EC2 → DDB - ポッドから DDB へのネットワークフロー + 未分類 - ポッドからインターネットまたはオンプレミスへのネットワークフロー 1. Network Flow Monitor Top Contributors API からのネットワークフローは、EKS コンソールで次のエクスペリエンスを強化するために使用されます。 + サービスマップ: クラスター内のネットワークフロー (AZ 内および AZ 間) の視覚化。 + フローテーブル: クラスター内のネットワークフロー (AZ 内および AZ 間)、ポッドから AWS サービス (EC2 → S3 および EC2 → DDB) へのフロー、ポッドから外部宛先 (未分類) へのフローの表形式表示。 Top Contributors API からプルされたネットワークフローは、1 時間の時間範囲に限定されており、各カテゴリにつき最大 500 件のフローを含めることができます。サービスマップでは、1 時間の時間範囲において、AZ 内および AZ 間のフローカテゴリから最大 1000 件のフローを取得して表示できます。フローテーブルでは、2 時間の時間範囲において、6 つのネットワークフローカテゴリすべてから最大 3000 件のネットワークフローを取得して表示できます。 #### 例: サービスマップ *デプロイビュー* ![\[デプロイビューでの e コマースアプリを使用したサービスマップの図\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/ecommerce-deployment.png) *ポッドビュー* ![\[ポッドビューでの e コマースアプリを使用したサービスマップの図\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/ecommerce-pod.png) *デプロイビュー* ![\[デプロイビューでのフォトギャラリーアプリを使用したサービスマップの図\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/photo-gallery-deployment.png) *ポッドビュー* ![\[ポッドビューでのフォトギャラリーアプリを使用したサービスマップの図\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/photo-gallery-pod.png) #### 例: フローテーブル *AWS サービスビュー* ![\[フローテーブルビューの図\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/aws-service-view.png) *クラスタービュー* ![\[クラスタービューでのフローテーブルの図\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/cluster-view.png) ## 考慮事項と制限事項 + EKS のコンテナネットワークオブザーバビリティは、[Network Flow Monitor がサポートされている](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-NetworkFlowMonitor-Regions.html)リージョンでのみ使用できます。 + サポートされているシステムメトリクスは OpenMetrics 形式で、Network Flow Monitor (NFM) エージェントから直接スクレイピングできます。 + [Terraform](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/networkflowmonitor_monitor) などの Infrastructure as Code (IaC) を使用して EKS でコンテナネットワークオブザーバビリティを有効にするには、NFM スコープ、NFM モニター、NFM エージェントなどの依存関係を設定で定義して作成しておく必要があります。 + Network Flow Monitor は、1 分あたり最大約 500 万件のフローをサポートします。これは、Network Flow Monitor エージェントがインストールされた約 5,000 台の EC2 インスタンス (EKS ワーカーノード) に相当します。5,000 台を超えるインスタンスにエージェントをインストールすると、追加の容量が利用可能になるまで、モニタリングパフォーマンスに影響する可能性があります。 + NFM エージェントの EKS アドオンでは、最小バージョン 1.1.0 を実行している必要があります。 + Network Flow Monitor リソースをサポートするには、[Terraform AWS Provider](https://github.com/hashicorp/terraform-provider-aws) の v6.21.0 以降を使用する必要があります。 + ネットワークフローにポッドメタデータを付加するには、ポッドはホストのネットワーク名前空間ではなく、独自の独立したネットワーク名前空間で実行されている必要があります。