このページの改善にご協力ください

このユーザーガイドに貢献するには、すべてのページの右側のペインにある「GitHub でこのページを編集する」リンクを選択してください。

コンテナネットワークのオブザーバビリティを使用して Kubernetes ワークロードのトラフィックをモニタリングする

Amazon EKS は、コンテナネットワーク環境に関するより深いインサイトを提供する拡張ネットワークのオブザーバビリティ機能を提供します。これらの機能は、AWS における Kubernetes ネットワーク環境をよりよく理解し、モニタリングし、トラブルシューティングするのに役立ちます。強化されたコンテナネットワークのオブザーバビリティでは、クラスタートラフィック、AZ 間フロー、AWS サービス全体にわたって、事前の異常検出をより効果的に行うために、ネットワーク関連のきめ細かなメトリクスを活用できます。これらのメトリクスを使用して、システムパフォーマンスを測定し、任意のオブザーバビリティスタックで基盤となるメトリクスを視覚化できます。

さらに、Amazon EKS は、より迅速な根本原因分析のために、正確なトラブルシューティングを加速および強化するネットワークモニタリングの視覚化を AWS コンソールで提供するようになりました。これらの視覚化機能を活用することで、再送信や再送信タイムアウトを引き起こしているトップトーカーやネットワークフローを特定し、インシデント中の死角を排除することもできます。

これらの機能は、Amazon CloudWatch Network Flow Monitor によって有効化されています。

ユースケース

ネットワークパフォーマンスを測定して異常を検出する

いくつかのチームは、システムのパフォーマンスを測定し、システムメトリクスを視覚化し、特定のしきい値を超えた場合にアラームを受け取れるオブザーバビリティスタックを標準化しています。EKS のコンテナネットワークのオブザーバビリティは、スクレイピング可能な主要なシステムメトリクスを公開することで、ポッドおよびワーカーノードレベルでシステムのネットワークパフォーマンスのオブザーバビリティを拡張し、これと整合します。

コンソールの視覚化を活用してより正確なトラブルシューティングを行う

モニタリングシステムからアラームが発生した場合は、問題が発生したクラスターとワークロードに焦点を絞り込む必要があります。これを支援するために、EKS コンソールの視覚化を活用すると、クラスターレベルで調査範囲を絞り込み、再送信、再送信タイムアウト、転送データ量の原因となっているネットワークフローの特定を高速化できます。

Amazon EKS 環境でトップトーカーを追跡する

多くのチームは、プラットフォームの基盤として EKS を実行し、EKS をアプリケーション環境におけるネットワークアクティビティの中心にしています。この機能のネットワークモニタリング機能を使用すると、クラスター内、AZ 間、さらに AWS 内の外部宛先 (DynamoDB と S3) や AWS クラウド外 (インターネットまたはオンプレミス) へのトラフィックのうち、(データ量で測定した場合に) 最も多くのトラフィックを発生させているワークロードを追跡できます。さらに、再送信、再送信タイムアウト、および転送データ量に基づいて、これらの各フローのパフォーマンスをモニタリングできます。

機能

はじめに

開始するには、新規または既存のクラスターの EKS コンソールでコンテナネットワークオブザーバビリティを有効にします。これにより、Network Flow Monitor (NFM) の依存関係 (スコープとモニターリソース) の作成が自動化されます。さらに、Network Flow Monitor Agent アドオンをインストールする必要があります。または、 AWS CLI、EKS API (アドオン用)、NFM API、あるいは Infrastructure as Code (Terraform など) を使用して、これらの依存関係をインストールすることもできます。これらの依存関係を設定したら、NFM エージェントからポッドとワーカーノードのネットワークパフォーマンスメトリクスをスクレイピングするように、任意のモニタリングツールを設定できます。ワークロードのネットワークアクティビティとパフォーマンスを視覚化するには、クラスターのオブザーバビリティダッシュボードの [ネットワーク] タブから EKS コンソールに移動します。

EKS で Network Flow Monitor を使用すると、既存のオブザーバビリティワークフローとテクノロジースタックを維持しながら、EKS 環境のネットワークレイヤーの理解と最適化をさらに促進する一連の追加機能を活用できます。詳細については、こちらの Network Flow Monitor の料金を参照してください。

前提条件と重要な注意事項

必要な IAM 許可

NFM エージェント用 EKS アドオン

CloudWatchNetworkFlowMonitorAgentPublishPolicy の AWS 管理ポリシーは、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 エージェントから直接スクレイピングできます。これらのメトリクスをモニタリングスタックに送信することで、ポッドおよびワーカーノードレベルでシステムのネットワークパフォーマンスの測定を拡張できます。使用可能なメトリクスは、サポートされているシステムメトリクスの表に一覧表示されています。

これらのメトリクスを有効にするには、インストールプロセス中に、設定変数を使用して次の環境変数を上書きします (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 コンソールで視覚化され、クラスターの環境内のトラフィックと、これらのフローレベルのメトリクスに基づいてパフォーマンスが示されます。

以下の図は、両方のタイプのメトリクス (システムレベルとフローレベル) を活用して、運用インテリジェンスを高めるワークフローを示しています。

重要な注意点: NFM エージェントからのシステムメトリクスのスクレイピングと、NFM エージェントがフローレベルのメトリクスを NFM バックエンドにプッシュするプロセスは、互いに独立したプロセスです。

サポートされているシステムメトリクス

重要な注意点: システムメトリクスは OpenMetrics 形式でエクスポートされます。

サポートされているフローレベルのメトリクス

サービスマップとフローテーブル

Top Contributors API からプルされたネットワークフローは、1 時間の時間範囲に限定されており、各カテゴリにつき最大 500 件のフローを含めることができます。サービスマップでは、1 時間の時間範囲において、AZ 内および AZ 間のフローカテゴリから最大 1000 件のフローを取得して表示できます。フローテーブルでは、2 時間の時間範囲において、6 つのネットワークフローカテゴリすべてから最大 3000 件のネットワークフローを取得して表示できます。

例: サービスマップ

デプロイビュー

ポッドビュー

デプロイビュー

ポッドビュー

例: フローテーブル

AWS サービスビュー

クラスタービュー

考慮事項と制限