Untersuchen der Integrität von Knoten und Pods

Dieser Artikel ist Teil einer Serie. Beginnen Sie mit der Übersicht.

Wenn die Cluster-Überprüfungen, die Sie im vorherigen Schritt durchgeführt haben, keine Probleme aufzeigen, überprüfen Sie den Zustand der Azure Kubernetes Service (AKS)-Arbeitsknoten. Führen Sie die sechs Schritte in diesem Artikel aus, um den Status von Knoten zu überprüfen, den Grund für einen fehlerhaften Knoten zu ermitteln und das Problem zu beheben.

Schritt 1: Überprüfen der Integrität von Workerknoten

Verschiedene Faktoren können zu fehlerhaften Knoten in einem AKS-Cluster beitragen. Ein allgemeiner Grund ist die Unterbrechung der Kommunikation zwischen der Kontrollebene und den Knoten. Diese Fehlkommunikation wird häufig durch Fehlkonfigurationen in Routing- und Firewallregeln verursacht.

Wenn Sie Ihren AKS-Cluster für benutzerdefiniertes Routing konfigurieren, müssen Sie Ausgangspfade über eine virtuelle Netzwerkanwendung (Network Virtual Appliance, NVA) oder eine Firewall konfigurieren, z. B. eine Azure-Firewall. Um ein Problem mit falscher Konfiguration zu beheben, empfehlen wir, die Firewall so zu konfigurieren, dass die erforderlichen Ports und vollqualifizierten Domänennamen (Fully Qualified Domain Names, FQDNs) gemäß den Richtlinien für den AKS-Übergabedatenverkehr zugelassen werden.

Ein weiterer Grund für fehlerhafte Knoten können unzureichende Compute-, Arbeitsspeicher- oder Speicherressourcen sein, die zur Auslastung von Kubelet führen. In solchen Fällen kann die Skalierung der Ressourcen das Problem effektiv lösen.

In einem privaten AKS-Cluster können Dns-Lösungsprobleme (Domain Name System) Kommunikationsprobleme zwischen der Steuerungsebene und den Knoten verursachen. Sie müssen überprüfen, ob der DNS-Name des Kubernetes-API-Servers in die private IP-Adresse des API-Servers aufgelöst wird. Falsche Konfiguration eines benutzerdefinierten DNS-Servers ist eine häufige Ursache für DNS-Auflösungsfehler. Wenn Sie benutzerdefinierte DNS-Server verwenden, stellen Sie sicher, dass Sie diese ordnungsgemäß als DNS-Server im virtuellen Netzwerk angeben, in dem Knoten bereitgestellt werden. Stellen Sie außerdem sicher, dass der private AKS-API-Server über den benutzerdefinierten DNS-Server aufgelöst werden kann.

Nachdem Sie diese potenziellen Probleme im Zusammenhang mit der Steuerungsebenenkommunikation und der DNS-Auflösung angegangen haben, können Sie Probleme mit der Knotengesundheit innerhalb Ihres AKS-Clusters effektiv lösen.

Sie können die Integrität Ihrer Knoten mithilfe einer der folgenden Methoden auswerten.

Containerintegritätsansicht in Azure Monitor

Führen Sie die folgenden Schritte aus, um die Integrität von Knoten, Benutzerpods und Systempods in Ihrem AKS-Cluster anzuzeigen:

1. Navigieren Sie im Azure-Portal zu Azure Monitor.
2. Wählen Sie im Abschnitt "Insights" des Navigationsbereichs "Container" aus.
3. Wählen Sie überwachte Cluster für eine Liste der zu überwachenden AKS-Cluster aus.
4. Wählen Sie einen AKS-Cluster aus der Liste aus, um die Integrität der Knoten, Benutzerpods und Systempods anzuzeigen.

AKS-Knotenansicht

Führen Sie die folgenden Schritte aus, um sicherzustellen, dass sich alle Knoten in Ihrem AKS-Cluster im Zustand "Bereit" befinden:

1. Navigieren Sie im Azure-Portal zu Ihrem AKS-Cluster.
2. Wählen Sie im Abschnitt "Einstellungen" des Navigationsbereichs die Option "Knotenpools" aus.
3. Wählen Sie Knoten aus.
4. Vergewissern Sie sich, dass sich alle Knoten im Zustand „Bereit“ befinden.

Clusterinterne Überwachung mit Prometheus und Grafana

Wenn Sie Prometheus und Grafana in Ihrem AKS-Cluster bereitgestellt haben, können Sie das K8 Cluster Detail Dashboard verwenden, um Einblicke zu erhalten. Dieses Dashboard zeigt Prometheus-Clustermetriken und stellt wichtige Informationen wie CPU-Auslastung, Speicherauslastung, Netzwerkaktivität und Dateisystemnutzung dar. Außerdem werden detaillierte Statistiken für einzelne Pods, Container und systemd-Dienste angezeigt.

Wählen Sie im Dashboard Knotenbedingungen aus, um Metriken zur Integrität und Leistung Ihres Clusters anzuzeigen. Sie können Knoten nachverfolgen, die Probleme haben können, z. B. Probleme mit ihren Zeitplänen, dem Netzwerk, Datenträgerdruck, Arbeitsspeicherdruck, PID-Druck oder Speicherplatz. Überwachen Sie diese Metriken, damit Sie potenzielle Probleme, die sich auf die Verfügbarkeit und Leistung Ihres AKS-Clusters auswirken, proaktiv identifizieren und beheben können.

Überwachen des verwalteten Diensts für Prometheus sowie von Azure Managed Grafana

Sie können vordefinierte Dashboards verwenden, um Prometheus-Metriken zu visualisieren und zu analysieren. Dazu müssen Sie Ihren AKS-Cluster einrichten, um Prometheus-Metriken im überwachten verwalteten Dienst für Prometheus zu sammeln und Ihren Monitor-Arbeitsbereich mit einem Azure Managed Grafana-Arbeitsbereich zu verbinden. Diese Dashboards bieten einen umfassenden Überblick über die Leistung und Integrität Ihres Kubernetes-Clusters.

Die Dashboards werden in der angegebenen Azure Managed Grafana-Instanz im Ordner "Managed Prometheus " bereitgestellt. Einige Dashboards umfassen:

• Kubernetes/Computeressourcen/Cluster
• Kubernetes / Compute Resources / Namespace (Pods)
• Kubernetes/Computeressourcen/Knoten (Pods)
• Kubernetes/Computeressourcen/Pod
• Kubernetes / Rechnerressourcen / Namespace (Workloads)
• Kubernetes/Computeressourcen/Workload
• Kubernetes/Kubelet
• Node Exporter / USE-Methode / Node
• Knoten-Exporter/Knoten
• Kubernetes/Computeressourcen/Cluster (Windows)
• Kubernetes / Compute Resources / Namespace (Windows)
• Kubernetes / Rechenressourcen / Pod (Windows)
• Kubernetes / USE-Methode / Cluster (Windows)
• Kubernetes / USE-Methode / Node (Windows)

Diese integrierten Dashboards werden in der Open-Source-Community für die Überwachung von Kubernetes-Clustern mit Prometheus und Grafana weit verbreitet. Verwenden Sie diese Dashboards, um Metriken anzuzeigen, z. B. Ressourcennutzung, Pod-Integrität und Netzwerkaktivität. Sie können auch benutzerdefinierte Dashboards erstellen, die auf Ihre Überwachungsanforderungen zugeschnitten sind. Dashboards helfen Ihnen, Prometheus-Metriken in Ihrem AKS-Cluster effektiv zu überwachen und zu analysieren, sodass Sie die Leistung optimieren, Probleme beheben und einen reibungslosen Betrieb Ihrer Kubernetes-Workloads sicherstellen können.

Sie können das Kubernetes/Compute Resources /Node (Pods) -Dashboard verwenden, um Metriken für Ihre Linux-Agent-Knoten anzuzeigen. Sie können die CPU-Auslastung, das CPU-Kontingent, die Speicherauslastung und das Speicherkontingent für jeden Pod visualisieren.

Wenn Ihr Cluster Windows-Agentknoten enthält, können Sie das Kubernetes/USE-Methoden-/Knoten-Dashboard (Windows) verwenden, um die Prometheus-Metriken zu visualisieren, die von diesen Knoten gesammelt werden. Dieses Dashboard bietet eine umfassende Übersicht über den Ressourcenverbrauch und die Leistung für Windows-Knoten innerhalb Ihres Clusters.

Nutzen Sie diese dedizierten Dashboards, damit Sie wichtige Metriken im Zusammenhang mit CPU, Arbeitsspeicher und anderen Ressourcen sowohl in Linux- als auch windows-Agent-Knoten problemlos überwachen und analysieren können. Diese Sichtbarkeit ermöglicht es Ihnen, potenzielle Engpässe zu identifizieren, die Ressourcenzuordnung zu optimieren und einen effizienten Betrieb in Ihrem AKS-Cluster sicherzustellen.

Schritt 2: Überprüfen der Konnektivität zwischen Steuerebene und Arbeitsknoten

Wenn die Workerknoten fehlerfrei sind, sollten Sie die Konnektivität zwischen der verwalteten AKS-Steuerungsebene und den Cluster-Workerknoten untersuchen. AKS ermöglicht die Kommunikation zwischen dem Kubernetes-API-Server und einzelnen Knoten kubelets über eine sichere Tunnelkommunikationsmethode. Diese Komponenten können kommunizieren, auch wenn sie sich in verschiedenen virtuellen Netzwerken befinden. Der Tunnel ist durch die MTLS-Verschlüsselung (Mutual Transport Layer Security) geschützt. Der primäre Tunnel, den AKS verwendet, wird als Konnectivity (früher als apiserver-network-proxy bezeichnet) bezeichnet. Stellen Sie sicher, dass alle Netzwerkregeln und FQDNs den erforderlichen Azure-Netzwerkregeln entsprechen.

Um die Konnektivität zwischen der verwalteten AKS-Steuerungsebene und den Cluster-Workerknoten eines AKS-Clusters zu überprüfen, können Sie das Befehlszeilentool kubectl verwenden.

Führen Sie den folgenden Befehl aus, um sicherzustellen, dass die Konnectivity-Agent-Pods ordnungsgemäß funktionieren:

kubectl get deploy konnectivity-agent -n kube-system

Stellen Sie sicher, dass sich die Pods in einem betriebsbereiten Zustand befinden.

Sollte ein Problem mit der Verbindung zwischen der Steuerungsebene und den Workerknoten bestehen, stellen Sie die Verbindung her, nachdem Sie sichergestellt haben, dass die erforderlichen Regeln für ausgehenden AKS-Datenverkehrsregeln zulässig sind.

Führen Sie den folgenden Befehl aus, um die konnectivity-agent Pods neu zu starten:

kubectl rollout restart deploy konnectivity-agent -n kube-system

Wenn beim Neustart der Pods die Verbindung nicht behoben wird, überprüfen Sie die Protokolle auf Anomalien. Führen Sie den folgenden Befehl aus, um die Protokolle der konnectivity-agent Pods anzuzeigen:

kubectl logs -l app=konnectivity-agent -n kube-system --tail=50

Die Protokolle sollten die folgende Ausgabe liefern:

I1012 12:27:43.521795       1 options.go:102] AgentCert set to "/certs/client.crt".
I1012 12:27:43.521831       1 options.go:103] AgentKey set to "/certs/client.key".
I1012 12:27:43.521834       1 options.go:104] CACert set to "/certs/ca.crt".
I1012 12:27:43.521837       1 options.go:105] ProxyServerHost set to "sethaks-47983508.hcp.switzerlandnorth.azmk8s.io".
I1012 12:27:43.521841       1 options.go:106] ProxyServerPort set to 443.
I1012 12:27:43.521844       1 options.go:107] ALPNProtos set to [konnectivity].
I1012 12:27:43.521851       1 options.go:108] HealthServerHost set to
I1012 12:27:43.521948       1 options.go:109] HealthServerPort set to 8082.
I1012 12:27:43.521956       1 options.go:110] AdminServerPort set to 8094.
I1012 12:27:43.521959       1 options.go:111] EnableProfiling set to false.
I1012 12:27:43.521962       1 options.go:112] EnableContentionProfiling set to false.
I1012 12:27:43.521965       1 options.go:113] AgentID set to b7f3182c-995e-4364-aa0a-d569084244e4.
I1012 12:27:43.521967       1 options.go:114] SyncInterval set to 1s.
I1012 12:27:43.521972       1 options.go:115] ProbeInterval set to 1s.
I1012 12:27:43.521980       1 options.go:116] SyncIntervalCap set to 10s.
I1012 12:27:43.522020       1 options.go:117] Keepalive time set to 30s.
I1012 12:27:43.522042       1 options.go:118] ServiceAccountTokenPath set to "".
I1012 12:27:43.522059       1 options.go:119] AgentIdentifiers set to .
I1012 12:27:43.522083       1 options.go:120] WarnOnChannelLimit set to false.
I1012 12:27:43.522104       1 options.go:121] SyncForever set to false.
I1012 12:27:43.567902       1 client.go:255] "Connect to" server="e9df3653-9bd4-4b09-b1a7-261f6104f5d0"

Hinweis

Wenn ein AKS-Cluster mit einer virtuellen API-Server-Netzwerkintegration und entweder einer Azure-Containernetzwerkschnittstelle (CNI) oder einem Azure CNI mit dynamischer Pod-IP-Zuweisung eingerichtet ist, müssen keine Konnectivity-Agenten bereitgestellt werden. Die integrierten API-Server-Pods können über private Netzwerke eine direkte Kommunikation mit den Cluster-Workerknoten herstellen.

Wenn Sie allerdings eine API-Server-VNet-Integration mit Azure-CNI-Überlagerung oder aber Ihre eigene CNI verwenden (Bring Your Own CNI, BYOCNI), wird Konnectivity bereitgestellt, um die Kommunikation zwischen den API-Servern und Pod-IPs zu erleichtern. Die Kommunikation zwischen den API-Servern und den Workerknoten bleibt direkt.

Sie können auch die Containerprotokolle im Protokollierungs- und Überwachungsdienst durchsuchen, um die Protokolle abzurufen. Ein Beispiel, in dem nach Konnektivitätsfehlern vom Typ aks-link gesucht wird, finden Sie unter Abfrageprotokolle aus Container Insights.

Führen Sie die folgende Abfrage aus, um die Protokolle abzurufen:

ContainerLogV2 
| where _ResourceId =~ "/subscriptions/<subscription-ID>/resourceGroups/<resource-group-name>/providers/Microsoft.ContainerService/managedClusters/<cluster-ID>" // Use the IDs and names of your resources for these values.
| where ContainerName has "aks-link"
| project LogSource,LogMessage, TimeGenerated, Computer, PodName, ContainerName, ContainerId
| order by TimeGenerated desc
| limit 200

Führen Sie die folgende Abfrage aus, um Containerprotokolle für alle fehlgeschlagenen Pods in einem bestimmten Namespace zu durchsuchen:

let KubePodInv = KubePodInventory
    | where TimeGenerated >= startTime and TimeGenerated < endTime
    | where _ResourceId =~ "<cluster-resource-ID>" // Use your resource ID for this value.
    | where Namespace == "<pod-namespace>" // Use your target namespace for this value.
    | where PodStatus == "Failed"
    | extend ContainerId = ContainerID
    | summarize arg_max(TimeGenerated, *)  by  ContainerId, PodStatus, ContainerStatus
    | project ContainerId, PodStatus, ContainerStatus;

    KubePodInv
    | join
    (
        ContainerLogV2
    | where TimeGenerated >= startTime and TimeGenerated < endTime
    | where PodNamespace == "<pod-namespace>" //update with target namespace
    ) on ContainerId
    | project TimeGenerated, PodName, PodStatus, ContainerName, ContainerId, ContainerStatus, LogMessage, LogSource

Wenn Sie die Protokolle nicht mithilfe von Abfragen oder dem Kubectl-Tool abrufen können, verwenden Sie die Secure Shell(SSH)-Authentifizierung. In diesem Beispiel wird nach dem Herstellen einer Verbindung mit dem Knoten über SSH der Pod für tunnelfront gefunden.

kubectl pods -n kube-system -o wide | grep tunnelfront
ssh azureuser@<agent node pod is on, output from step above>
docker ps | grep tunnelfront
docker logs …
nslookup <ssh-server_fqdn>
ssh -vv azureuser@<ssh-server_fqdn> -p 9000
docker exec -it <tunnelfront_container_id> /bin/bash -c "ping bing.com"
kubectl get pods -n kube-system -o wide | grep <agent_node_where_tunnelfront_is_running>
kubectl delete po <kube_proxy_pod> -n kube-system

Schritt 3: Überprüfen der DNS-Auflösung beim Einschränken des ausgehenden Datenverkehrs

Die DNS-Auflösung ist ein entscheidender Aspekt Ihres AKS-Clusters. Wenn die DNS-Auflösung nicht ordnungsgemäß funktioniert, kann dies zu Fehlern in der Steuerungsebene oder zu Fehlern beim Abrufen des Containerimages führen. Führen Sie die folgenden Schritte aus, um sicherzustellen, dass die DNS-Auflösung für den Kubernetes-API-Server ordnungsgemäß funktioniert:

1. Führen Sie den Befehl kubectl exec aus, um eine Befehlsshell im Container zu öffnen, der im Pod läuft.

   kubectl exec --stdin --tty your-pod --namespace <namespace-name> -- /bin/bash
   

2. Überprüfen Sie, ob die Tools "nslookup " oder " digup " im Container installiert sind.

3. Wenn kein Tool im Pod installiert ist, führen Sie den folgenden Befehl aus, um einen Hilfs-Pod im selben Namespace zu erstellen.

   kubectl run -i --tty busybox --image=busybox --namespace <namespace-name> --rm=true -- sh
   

4. Sie können die API-Serveradresse über die Übersichtsseite Ihres AKS-Clusters im Azure-Portal abrufen oder den folgenden Befehl ausführen.

   az aks show --name <aks-name> --resource-group <resource-group-name> --query fqdn --output tsv
   

5. Führen Sie den folgenden Befehl aus, um zu versuchen, den AKS-API-Server aufzulösen. Weitere Informationen finden Sie unter Behandeln von DNS-Auflösungsfehlern innerhalb des Pods, aber nicht vom Workerknoten aus.

   nslookup myaks-47983508.hcp.westeurope.azmk8s.io
   

6. Überprüfen Sie im Pod den Upstream-DNS-Server, um zu ermitteln, ob die DNS-Auflösung ordnungsgemäß funktioniert. Führen Sie z. B. für Azure DNS den nslookup Befehl aus.

   nslookup microsoft.com 168.63.129.16
   

7. Wenn die vorherigen Schritte keine Erkenntnisse liefern, stellen Sie eine Verbindung mit einem der Workerknoten her, und versuchen Sie, DNS vom Knoten aus aufzulösen. Mit diesem Schritt können Sie ermitteln, ob das Problem mit AKS oder der Netzwerkkonfiguration verbunden ist.

8. Wenn die DNS-Auflösung vom Knoten, aber nicht vom Pod aus erfolgreich ist, kann das Problem mit Kubernetes DNS zusammenhängen. Schritte zum Debuggen der DNS-Auflösung vom Pod finden Sie unter Problembehandlung bei DNS-Auflösungsfehlern.

   Wenn die DNS-Auflösung vom Knotenpunkt fehlschlägt, überprüfen Sie das Netzwerksetup, um sicherzustellen, dass die entsprechenden Routingpfade und Ports geöffnet sind, um eine DNS-Auflösung zu ermöglichen.

Schritt 4: Überprüfen auf Kubelet-Fehler

Überprüfen Sie den Zustand des Kubelet-Prozesses, der auf jedem Arbeitsknoten ausgeführt wird, und stellen Sie sicher, dass er nicht unter Druck steht. Potenzieller Druck kann sich auf CPU, Arbeitsspeicher oder Speicher beziehen. Um den Status einzelner Knoten kubelets zu überprüfen, können Sie eine der folgenden Methoden verwenden.

AKS-Kubelet-Arbeitsmappe

Führen Sie die folgenden Schritte aus, um sicherzustellen, dass die Agent-Knoten-Kubelets ordnungsgemäß funktionieren:

1. Navigieren Sie im Azure-Portal zu Ihrem AKS-Cluster.

2. Wählen Sie im Abschnitt "Überwachung " des Navigationsbereichs "Arbeitsmappen" aus.

3. Wählen Sie die Kubelet-Arbeitsmappe aus.

   

4. Wählen Sie Vorgänge aus, und stellen Sie sicher, dass die Vorgänge für alle Workerknoten abgeschlossen sind.

   

Clusterinterne Überwachung mit Prometheus und Grafana

Wenn Sie Prometheus und Grafana in Ihrem AKS-Cluster bereitgestellt haben, können Sie das Kubernetes/Kubelet-Dashboard verwenden, um Einblicke in die Integrität und Leistung einzelner Knoten kubelets zu erhalten.

Überwachen des verwalteten Diensts für Prometheus sowie von Azure Managed Grafana

Sie können das vordefinierte Dashboard Kubernetes/Kubelet verwenden, um die Prometheus-Metriken für die Workerknoten-Kubelets zu visualisieren und zu analysieren. Dazu müssen Sie Ihren AKS-Cluster einrichten, um Prometheus-Metriken im überwachten verwalteten Dienst für Prometheus zu sammeln und Ihren Monitor-Arbeitsbereich mit einem Azure Managed Grafana-Arbeitsbereich zu verbinden.

Die Ressourcenauslastung erhöht sich, wenn ein Kubelet neu gestartet wird, was zu sporadischem, unvorhersehbarem Verhalten führt. Stellen Sie sicher, dass die Fehleranzahl nicht kontinuierlich wächst. Ein gelegentlicher Fehler ist akzeptabel, aber ein konstantes Wachstum zeigt ein zugrunde liegendes Problem an, das Sie untersuchen und beheben müssen.

Schritt 5: Verwenden Sie das Node Problem Detector (NPD) Tool, um den Zustand der Knoten zu überprüfen.

NPD ist ein Kubernetes-Tool, mit dem Sie knotenbezogene Probleme identifizieren und melden können. Es arbeitet als systemd-Dienst auf jedem Knoten innerhalb des Clusters. Es sammelt Metriken und Systeminformationen, z. B. CPU-Auslastung, Datenträgerauslastung und Netzwerkkonnektivitätsstatus. Wenn ein Problem erkannt wird, generiert das NPD-Tool einen Bericht über die Ereignisse und die Knotenbedingung. In AKS wird das NPD-Tool verwendet, um Knoten in einem Kubernetes-Cluster zu überwachen und zu verwalten, der in der Azure-Cloud gehostet wird. Weitere Informationen finden Sie unter NPD in AKS-Knoten.

Schritt 6: Überprüfen von Datenträger-E/A-Vorgängen pro Sekunde (I/O Operations per Second, IOPS) auf Drosselung

Um sicherzustellen, dass IOPS nicht gedrosselt und Dienste und Workloads innerhalb Ihres AKS-Clusters beeinträchtigt werden, können Sie eine der folgenden Methoden verwenden.

AKS-Arbeitsmappe für Knotendatenträger-E/A

Zum Überwachen der Datenträger-E/A-bezogenen Metriken der Arbeitsknoten in Ihrem AKS-Cluster können Sie die Knotendatenträger-E/A-Arbeitsmappe verwenden. Führen Sie die folgenden Schritte aus, um auf die Arbeitsmappe zuzugreifen:

1. Navigieren Sie im Azure-Portal zu Ihrem AKS-Cluster.

2. Wählen Sie im Abschnitt "Überwachung " des Navigationsbereichs "Arbeitsmappen" aus.

3. Wählen Sie das Node Disk IO Workbook aus.

   

4. Überprüfen Sie die E/A-bezogenen Metriken.

   

Clusterinterne Überwachung mit Prometheus und Grafana

Wenn Sie Prometheus und Grafana in Ihrem AKS-Cluster bereitgestellt haben, können Sie das USE-Methoden-/Knoten-Dashboard verwenden, um Einblicke über die Datenträger-E/A für die Clusterarbeitsknoten zu erhalten.

Überwachen des verwalteten Diensts für Prometheus sowie von Azure Managed Grafana

Sie können das vordefinierte Dashboard "Node Exporter/Nodes " verwenden, um Datenträger-E/A-bezogene Metriken aus den Arbeitsknoten zu visualisieren und zu analysieren. Dazu müssen Sie Ihren AKS-Cluster einrichten, um Prometheus-Metriken im überwachten verwalteten Dienst für Prometheus zu sammeln und Ihren Monitor-Arbeitsbereich mit einem Azure Managed Grafana-Arbeitsbereich zu verbinden.

IOPS und Azure-Datenträger

Physische Speichergeräte haben inhärente Einschränkungen hinsichtlich der Bandbreite und der maximalen Anzahl von Dateivorgängen, die sie verarbeiten können. Azure-Datenträger werden verwendet, um das Betriebssystem zu speichern, das auf AKS-Knoten ausgeführt wird. Die Datenträger unterliegen den gleichen physischen Speichereinschränkungen wie das Betriebssystem.

Betrachten Sie das Konzept des Durchsatzes. Sie können die durchschnittliche E/A-Größe mit den IOPS multiplizieren, um den Durchsatz in Megabyte pro Sekunde (MBps) zu ermitteln. Größere I/O-Größen führen aufgrund des festen Durchsatzes des Datenträgers zu niedrigeren IOPS.

Wenn eine Workload die maximalen IOPS-Dienstgrenzwerte überschreitet, die den Azure-Datenträgern zugewiesen sind, reagiert der Cluster möglicherweise nicht mehr, und es wird ein E/A-Wartezustand eingegeben. In Linux-basierten Systemen werden viele Komponenten als Dateien behandelt, z. B. Netzwerksockets, CNI, Docker und andere Dienste, die auf Netzwerk-E/A angewiesen sind. Wenn der Datenträger daher nicht gelesen werden kann, wird der Fehler auf alle diese Dateien erweitert.

Mehrere Ereignisse und Szenarien können die IOPS-Drosselung auslösen, darunter:

• Eine erhebliche Anzahl von Containern, die auf Knoten ausgeführt werden, da Docker I/O den Betriebssystemdatenträger teilt.

• Benutzerdefinierte oder Drittanbietertools, die für Sicherheit, Überwachung und Protokollierung verwendet werden, wodurch möglicherweise zusätzliche E/A-Vorgänge auf dem Betriebssystemdatenträger generiert werden.

• Knotenfailoverereignisse und regelmäßige Aufträge, die die Arbeitsauslastung intensivieren oder die Anzahl von Pods skalieren. Diese höhere Auslastung erhöht die Wahrscheinlichkeit von Drosselungen, was dazu führen kann, dass alle Knoten bis zum Abschluss der E/A-Vorgänge in einen nicht bereiten Zustand versetzt werden.

Beitragende

Dieser Artikel wird von Microsoft verwaltet. Sie wurde ursprünglich von den folgenden Mitwirkenden verfasst.

Hauptautoren:

• Paolo Salvadori | Principal Customer Engineer
• Francis Simy Nazareth | Senior Technical Specialist

Um nicht öffentliche LinkedIn-Profile anzuzeigen, melden Sie sich bei LinkedIn an.

Nächste Schritte

• Datenträgerbeschränkungen für virtuelle Computer
• Virtuelle Computer und Datenträgerleistung

Verwandte Ressourcen

Überprüfen der Workloadbereitstellungen