Unterstützung für die Verbesserung dieser Seite beitragen

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Um zu diesem Benutzerhandbuch beizutragen, wählen Sie den GitHub Link Diese Seite bearbeiten auf, der sich im rechten Bereich jeder Seite befindet.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Überwachen Sie den Kubernetes-Workload-Traffic mit Container Network Observability

Amazon EKS bietet erweiterte Funktionen zur Netzwerkbeobachtbarkeit, die tiefere Einblicke in Ihre Container-Netzwerkumgebung bieten. Diese Funktionen helfen Ihnen dabei, Ihre Kubernetes-Netzwerklandschaft in besser zu verstehen, zu überwachen und Fehler zu beheben. AWS Dank der verbesserten Beobachtbarkeit von Container-Netzwerken können Sie detaillierte, netzwerkbezogene Metriken für eine bessere proaktive Erkennung von Anomalien im Cluster-Traffic, AZ-übergreifenden Flows und Diensten nutzen. AWS Mithilfe dieser Metriken können Sie die Systemleistung messen und die zugrunde liegenden Metriken mithilfe Ihres bevorzugten Observability-Stacks visualisieren.

Darüber hinaus bietet Amazon EKS jetzt Netzwerküberwachungsvisualisierungen in der AWS Konsole, die die präzise Fehlerbehebung beschleunigen und verbessern und so eine schnellere Ursachenanalyse ermöglichen. Sie können diese visuellen Funktionen auch nutzen, um Top-Talker und Netzwerkflüsse zu identifizieren, die zu erneuten Übertragungen und Timeouts bei der erneuten Übertragung führen, wodurch blinde Flecken bei Vorfällen beseitigt werden.

Diese Funktionen werden von Amazon CloudWatch Network Flow Monitor aktiviert.

Anwendungsfälle

Messen Sie die Netzwerkleistung, um Anomalien zu erkennen

Mehrere Teams verwenden standardmäßig einen Observability-Stack, der es ihnen ermöglicht, die Leistung ihres Systems zu messen, Systemmetriken zu visualisieren und bei Überschreitung eines bestimmten Schwellenwerts alarmiert zu werden. Die Beobachtbarkeit von Containernetzwerken in EKS passt genau darauf an, indem wichtige Systemmetriken offengelegt werden, die Sie auswerten können, um die Beobachtbarkeit der Netzwerkleistung Ihres Systems auf Pod- und Worker-Node-Ebene zu erweitern.

Nutzen Sie Konsolenvisualisierungen für eine genauere Fehlerbehebung

Falls Ihr Überwachungssystem einen Alarm ausgibt, sollten Sie sich auf den Cluster und die Arbeitslast konzentrieren, von denen das Problem herrührt. Um dies zu unterstützen, können Sie Visualisierungen in der EKS-Konsole nutzen, um den Untersuchungsumfang auf Clusterebene einzugrenzen und die Offenlegung der Netzwerkflüsse zu beschleunigen, die für die meisten Neuübertragungen, Zeitüberschreitungen bei der erneuten Übertragung und das übertragene Datenvolumen verantwortlich sind.

Verfolgen Sie Top-Talker in Ihrer Amazon EKS-Umgebung

Viele Teams verwenden EKS als Grundlage für ihre Plattformen und machen es somit zum Mittelpunkt der Netzwerkaktivitäten einer Anwendungsumgebung. Mithilfe der Netzwerküberwachungsfunktionen in dieser Funktion können Sie nachverfolgen, welche Workloads für den meisten Datenverkehr (gemessen am Datenvolumen) innerhalb des Clusters AZs, über und für den Verkehr zu externen Zielen innerhalb AWS (DynamoDB und S3) und außerhalb der AWS Cloud (Internet oder lokal) verantwortlich sind. Darüber hinaus können Sie die Leistung jedes dieser Datenflüsse anhand von Neuübertragungen, Zeitüberschreitungen bei der erneuten Übertragung und übertragenen Daten überwachen.

Features

Erste Schritte

Aktivieren Sie zunächst Container Network Observability in der EKS-Konsole für einen neuen oder vorhandenen Cluster. Dadurch wird die Erstellung von Network Flow Monitor (NFM) -Abhängigkeiten (Scope - und Monitor-Ressourcen) automatisiert. Darüber hinaus müssen Sie das Network Flow Monitor Agent-Add-on installieren. Alternativ können Sie diese Abhängigkeiten mithilfe von EKS APIs (für das AWS CLI Add-On), NFM APIs oder Infrastructure as Code (wie Terraform) installieren. Sobald diese Abhängigkeiten eingerichtet sind, können Sie Ihr bevorzugtes Überwachungstool so konfigurieren, dass Netzwerkleistungskennzahlen für Pods und Worker-Knoten vom NFM-Agenten abgerufen werden. Um die Netzwerkaktivität und Leistung Ihrer Workloads zu visualisieren, können Sie im Observability-Dashboard des Clusters unter der Registerkarte „Netzwerk“ zur EKS-Konsole navigieren.

Wenn Sie Network Flow Monitor in EKS verwenden, können Sie Ihren bestehenden Observability-Workflow und Ihren Technologie-Stack beibehalten und gleichzeitig eine Reihe zusätzlicher Funktionen nutzen, die es Ihnen ermöglichen, die Netzwerkschicht Ihrer EKS-Umgebung besser zu verstehen und zu optimieren. Weitere Informationen zu den Preisen von Network Flow Monitor finden Sie hier.

Voraussetzungen und wichtige Hinweise

Erforderliche IAM-Berechtigungen

EKS-Add-on für den NFM-Agenten

Sie können die CloudWatchNetworkFlowMonitorAgentPublishPolicy AWS verwaltete Richtlinie mit Pod Identity verwenden. Diese Richtlinie enthält Berechtigungen für den NFM-Agenten, Telemetrieberichte (Metriken) an einen Network Flow Monitor-Endpunkt zu senden.

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

Container-Netzwerk-Observability in der EKS-Konsole

Die folgenden Berechtigungen sind erforderlich, um die Funktion zu aktivieren und die Service-Map und die Flow-Tabelle in der Konsole zu visualisieren.

{
  "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": "*"
    }
  ]
}

Verwenden von AWS CLI, EKS-API und 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})"

Verwendung von Infrastruktur als Code (IaC)

Terraform

Wenn Sie Terraform zur Verwaltung Ihrer AWS Cloud-Infrastruktur verwenden, können Sie die folgenden Ressourcenkonfigurationen einbeziehen, um Container Network Observability für Ihren Cluster zu aktivieren.

NFM-Geltungsbereich

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-Monitor

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"
  }
}

EKS-Add-on für NFM

resource "aws_eks_addon" "example" {
  cluster_name                = aws_eks_cluster.example.name
  addon_name                  = "aws-network-flow-monitoring-agent"
}

Funktionsweise

Leistungsmetriken

Systemmetriken

Wenn Sie Drittanbieter-Tools (3P) zur Überwachung Ihrer EKS-Umgebung (wie Prometheus und Grafana) verwenden, können Sie die unterstützten Systemmetriken direkt vom Network Flow Monitor-Agenten abrufen. Diese Metriken können an Ihren Monitoring-Stack gesendet werden, um die Messung der Netzwerkleistung Ihres Systems auf Pod- und Worker-Node-Ebene zu erweitern. Die verfügbaren Metriken sind in der Tabelle unter Unterstützte Systemmetriken aufgeführt.

Um diese Metriken zu aktivieren, überschreiben Sie während des Installationsvorgangs die folgenden Umgebungsvariablen mithilfe der Konfigurationsvariablen (siehe: https://aws.amazon.com/blogs/amazon-eks-add-onscontainers/ -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]

Metriken auf Flussebene

Darüber hinaus erfasst Network Flow Monitor Netzwerkflussdaten zusammen mit Metriken auf Flussebene: Neuübertragungen, Zeitüberschreitungen bei der erneuten Übertragung und übertragene Daten. Diese Daten werden von Network Flow Monitor verarbeitet und in der EKS-Konsole visualisiert, um den Datenverkehr in der Umgebung Ihres Clusters zu ermitteln und anhand dieser Metriken auf Flussebene zu ermitteln, wie er abschneidet.

Das folgende Diagramm zeigt einen Workflow, in dem beide Arten von Metriken (System- und Flow-Ebene) genutzt werden können, um mehr betriebliche Informationen zu gewinnen.

Wichtiger Hinweis: Das Scraping von Systemmetriken aus dem NFM-Agenten und der Prozess, bei dem der NFM-Agent Metriken auf Flow-Ebene an das NFM-Backend überträgt, sind unabhängige Prozesse.

Unterstützte Systemmetriken

Wichtiger Hinweis: Systemmetriken werden im OpenMetricsFormat exportiert.

Unterstützte Metriken auf Flussebene

Servicekarte und Datenflusstabelle

Die von der Top Contributors API abgerufenen Netzwerkflüsse sind auf einen Zeitraum von 1 Stunde begrenzt und können bis zu 500 Datenflüsse aus jeder Kategorie umfassen. Für die Service Map bedeutet dies, dass bis zu 1000 Datenflüsse aus den Datenflusskategorien Intra AZ und Inter AZ über einen Zeitraum von 1 Stunde abgerufen und dargestellt werden können. Für die Flow-Tabelle bedeutet dies, dass bis zu 3000 Netzwerkflüsse aus allen 6 Netzwerkflusskategorien über einen Zeitraum von 2 Stunden abgerufen und dargestellt werden können.

Beispiel: Serviceübersicht

Bereitstellungsansicht

Pod-Ansicht

Bereitstellungsansicht

Pod-Ansicht

Beispiel: Flow-Tabelle

AWS Serviceansicht

Cluster-Ansicht

Überlegungen und Einschränkungen