Bewährte Methoden im Zusammenhang mit der Leistung und Skalierung kleiner bis mittelgroßer Workloads in Azure Kubernetes Service (AKS)

Hinweis

In diesem Artikel werden in erster Linie allgemeine bewährte Methoden für kleine bis mittelgroße Workloads behandelt. Bewährte Methoden für große Workloads finden Sie unter Bewährte Methoden im Zusammenhang mit der Leistung und Skalierung großer Workloads in Azure Kubernetes Service (AKS).

Wenn Sie Cluster in AKS bereitstellen und verwalten, können Sie die folgenden bewährten Methoden verwenden, um die Leistung und Skalierung zu optimieren.

In diesem Artikel lernen Sie Folgendes:

• Nachteile und Empfehlungen für die automatische Skalierung Ihrer Workloads
• Verwalten von Knotenskalierung und -effizienz basierend auf Ihren Workloadanforderungen
• Netzwerküberlegungen für ein- und ausgehenden Datenverkehr
• Überwachung und Problembehandlung für Steuerungsebene und Knotenleistung
• Kapazitätsplanung, Szenarien mit plötzlichem Anstieg und Clusterupgrades
• Überlegungen zu Speicher und Netzwerk für die Leistung der Datenebene

Automatische Skalierung der Anwendung im Vergleich zur automatischen Skalierung der Infrastruktur

Automatische Skalierung der Anwendung

Die automatische Skalierung der Anwendung ist bei der Kostenoptimierung oder im Falle von Infrastrukturbeschränkungen hilfreich. Eine gut konfigurierte Autoskalierung gewährleistet die Hochverfügbarkeit Ihrer Anwendung und minimiert gleichzeitig die Kosten. Sie zahlen unabhängig vom Bedarf nur für die Ressourcen, die erforderlich sind, um die Verfügbarkeit zu aufrechtzuerhalten.

Wenn also beispielsweise ein vorhandener Knoten über Platz, aber nicht über genügend IP-Adressen im Subnetz verfügt, kann möglicherweise die Erstellung eines neuen Knotens übersprungen und stattdessen sofort mit der Ausführung der Anwendung in einem neuen Pod begonnen werden.

Horizontale automatische Podskalierung

Die Implementierung der horizontalen automatischen Podskalierung ist bei Anwendungen mit stetigem und vorhersehbarem Ressourcenbedarf hilfreich. Die horizontale automatische Podskalierung (Horizontal Pod Autoscaler, HPA) skaliert dynamisch die Anzahl von Podreplikaten, wodurch die Last effektiv auf mehrere Pods und Knoten verteilt wird. Von diesem Skalierungsmechanismus profitieren in der Regel insbesondere Anwendungen, die in kleinere, unabhängige und parallel ausführbare Komponenten zerlegt werden können.

Die horizontale automatische Podskalierung stellt standardmäßig Metriken für die Ressourcenverwendung bereit. Sie können auch benutzerdefinierte Metriken integrieren oder Tools wie Kubernetes Event-Driven Autoscaler (KEDA) (Vorschauversion) nutzen. Durch diese Erweiterungen kann die horizontale automatische Podskalierung Skalierungsentscheidungen auf der Grundlage mehrerer Perspektiven und Kriterien treffen und eine ganzheitlichere Sicht Ihrer Anwendungsleistung bieten. Dies ist besonders hilfreich für Anwendungen mit variierenden komplexen Skalierungsanforderungen.

Hinweis

Wenn die Aufrechterhaltung der Hochverfügbarkeit für Ihre Anwendung hohe Priorität hat, empfiehlt es sich, einen etwas größeren Puffer für die minimale Podanzahl Ihrer horizontalen automatischen Podskalierung zu lassen, um der Skalierungszeit Rechnung zu tragen.

Vertikale automatische Podskalierung

Die Implementierung der vertikalen automatischen Podskalierung ist bei Anwendungen mit schwankendem und unvorhersehbarem Ressourcenbedarf hilfreich. Mit der vertikalen automatischen Podskalierung (Vertical Pod Autoscaler, VPA) können Sie Ressourcenanforderungen (einschließlich CPU und Arbeitsspeicher) für einzelne Pods optimieren und die Ressourcenzuordnung präzise steuern. Diese Granularität minimiert die Vergeudung von Ressourcen und verbessert die Gesamteffizienz der Clusternutzung. Die vertikale automatische Podskalierung optimiert auch die Anwendungsverwaltung, indem sie die Ressourcenzuordnung automatisiert und so Ressourcen für kritische Aufgaben freigibt.

Warnung

Verwenden Sie die vertikale automatische Podskalierung nicht in Kombination mit der horizontalen automatischen Podskalierung für die gleichen CPU- oder Speichermetriken. Diese Kombination kann zu Konflikten führen, da beide Autoskalierungen anhand der gleichen Metriken versuchen, auf Bedarfsänderungen zu reagieren. Sie können allerdings die vertikale automatische Podskalierung für CPU oder Arbeitsspeicher und die horizontale automatische Podskalierung für benutzerdefinierte Metriken verwenden, um Überschneidungen zu vermeiden und sicherzustellen, dass sich die Autoskalierungen jeweils auf unterschiedliche Aspekte der Workloadskalierung konzentrieren.

Hinweis

Die vertikale automatische Podskalierung nutzt historische Daten. Es wird empfohlen, nach der Bereitstellung der vertikalen automatischen Podskalierung mindestens 24 Stunden zu warten, bevor Sie Änderungen anwenden, um der Skalierung genügend Zeit zum Sammeln von Empfehlungsdaten zu lassen.

Automatische Skalierung der Infrastruktur

Automatische Skalierung von Clustern

Die Implementierung einer automatischen Clusterskalierung hilft beim Hochskalieren und beim Bereitstellen neuer Knoten. Sie ist also hilfreich, wenn die Kapazität Ihrer vorhandenen Knoten nicht ausreicht.

Wenn Sie eine automatische Clusterkalierung in Betracht ziehen, müssen Sie bei der Entscheidung, wann ein Knoten entfernt werden soll, einen Kompromiss zwischen der Optimierung der Ressourcenverwendung und der Gewährleistung der Ressourcenverfügbarkeit eingehen. Das Entfernen wenig ausgelasteter Knoten verbessert zwar die Clusterauslastung, kann aber dazu führen, dass neue Workloads warten müssen, bis Ressourcen bereitgestellt werden, damit sie bereitgestellt werden können. Es ist wichtig, ein Gleichgewicht zwischen diesen beiden Faktoren zu finden, das Ihre Cluster- und Workloadanforderungen erfüllt, und die Einstellungen zur Autoskalierung für Cluster entsprechend zu konfigurieren.

Die Profileinstellungen für die automatische Clusterskalierung gelten universell für alle Knotenpools mit Autoskalierungsunterstützung in Ihrem Cluster. Das bedeutet, dass sich jede Skalierungsaktion, die in einem Knotenpools mit Autoskalierungsunterstützung ausgeführt wird, auf das Verhalten der automatischen Skalierung in einem anderen Knotenpool auswirken kann. Es ist wichtig, konsistente und synchronisierte Profileinstellungen für alle relevanten Knotenpools anzuwenden, um sicherzustellen, dass sich die Autoskalierung wie erwartet verhält.

Überbereitstellung

Überbereitstellung ist eine Strategie zur Verringerung des Risikos von Anwendungsdruck. Hierzu wird sichergestellt wird, dass mehr als genug verfügbare Ressourcen vorhanden sind. Dieser Ansatz ist besonders hilfreich bei Anwendungen mit stark variablen Lasten sowie bei Clusterskalierungsmustern mit häufiger Hoch- und Herunterskalierung.

Zur Ermittlung der optimalen Überbereitstellung können Sie die folgende Formel verwenden:

1-buffer/1+traffic

Angenommen, Sie möchten in Ihrem Cluster eine CPU-Auslastung von 100 Prozent vermeiden. Als Sicherheitsspielraum können Sie beispielsweise einen Puffer von 30 Prozent verwenden. Bei einer erwarteten durchschnittlichen Datenverkehrswachstumsrate von 40 Prozent können Sie gemäß der Formel eine Überbereitstellung um 50 Prozent in Betracht ziehen:

1-30%/1+40%=50%

Eine effektive Überbereitstellungsmethode beinhaltet die Verwendung von Pausenpods. Pausenpods sind Bereitstellungen mit niedriger Priorität, die problemlos durch Bereitstellungen mit hoher Priorität ersetzt werden können. Sie erstellen Pods mit niedriger Priorität, die einzig dazu dienen, einen Pufferbereich zu reservieren. Wenn ein Pod mit hoher Priorität Platz benötigt, werden die Pausenpods entfernt und auf einem anderen oder neuen Knoten neu geplant, um Platz für den Pod mit hoher Priorität zu bieten.

Der folgende YAML-Code zeigt ein Beispiel für ein Pausenpod-Manifest:

apiVersion: scheduling.k8s.io/v1 
kind: PriorityClass 
metadata: 
  name: overprovisioning 
value: -1 
globalDefault: false 
description: "Priority class used by overprovisioning." 
--- 
apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: overprovisioning 
  namespace: kube-system 
spec: 
  replicas: 1 
  selector: 
    matchLabels: 
      run: overprovisioning 
  template: 
    metadata: 
      labels: 
        run: overprovisioning 
    spec: 
      priorityClassName: overprovisioning 
      containers: 
      - name: reserve-resources 
        image: your-custome-pause-image 
        resources: 
          requests: 
            cpu: 1 
            memory: 4Gi 

Knotenskalierung und Effizienz

Best Practices-Leitfaden:

Überwachen Sie Ressourcenverwendung und Planungsrichtlinien sorgfältig, um sicherzustellen, dass Knoten effizient verwendet werden.

Mithilfe der Knotenskalierung kann die Anzahl von Knoten in Ihrem Cluster basierend auf Workloadanforderungen dynamisch angepasst werden. Es ist wichtig zu verstehen, dass das Hinzufügen weiterer Knoten zu einem Cluster nicht immer die beste Lösung zur Verbesserung der Leistung ist. Um eine optimale Leistung sicherzustellen, empfiehlt es sich, die Ressourcenverwendung und die Planungsrichtlinien sorgfältig zu überwachen, um sicherzustellen, dass Knoten effizient verwendet werden.

Knotenimages

Best Practices-Leitfaden:

Verwenden Sie die neueste Knotenimageversion, um sicherzustellen, dass Sie über die neuesten Sicherheitspatches und Fehlerbehebungen verfügen.

Die Verwendung der neuesten Knotenimageversion bietet die beste Leistung. AKS stellt Leistungsverbesserungen im Rahmen der wöchentlichen Image-Releases bereit. Die neuesten Daemonset-Images werden im neuesten VHD-Image zwischengespeichert, was zu kürzeren Wartezeiten bei der Knotenbereitstellung und beim Bootstrapping führt. Wenn Sie nicht über die neuesten Updates verfügen, kann sich dies negativ auf die Leistung auswirken. Daher ist es wichtig, große Versionslücken zu vermeiden.

Azure Linux

Der Azure Linux-Containerhost für AKS verwendet ein natives AKS-Image und bietet einen zentralen Ort für die Linux-Entwicklung. Jedes Paket wird basierend auf der Quelle erstellt und überprüft, um sicherzustellen, dass Ihre Dienste auf bewährten Komponenten funktionieren.

Azure Linux ist kompakt und umfasst lediglich die Pakete, die zum Ausführen von Containerworkloads erforderlich sind. Es bietet eine reduzierte Angriffsfläche und sorgt dafür, dass keine unnötigen Pakete gepatcht oder gewartet werden müssen. Auf der Basisebene befindet sich ein von Microsoft gehärteter und für Azure optimierter Kernel. Dieses Image eignet sich perfekt für leistungsabhängige Workloads sowie für Plattformtechniker*innen oder Operator*innen, die Gruppen von AKS-Clustern verwalten.

Ubuntu 2204

Das Ubuntu 2204-Image ist das Standardknotenimage für AKS. Es ist ein kompaktes und effizientes Betriebssystem, das für die Ausführung containerisierter Workloads optimiert ist. Das bedeutet, dass es dazu beitragen kann, die Ressourcenverwendung zu reduzieren und die Gesamtleistung zu verbessern. Das Image enthält die neuesten Sicherheitspatches und -updates, um Ihre Workloads vor Sicherheitsrisiken zu schützen.

Das Ubuntu 2204-Image wird vollständig von Microsoft, Canonical und der Ubuntu-Community unterstützt und kann Ihnen dabei helfen, die Leistung und Sicherheit Ihrer containerisierten Workloads zu verbessern.

Virtuelle Computer (VMs)

Best Practices-Leitfaden:

Achten Sie bei der Wahl eines virtuellen Computers darauf, dass Größe und Leistung des Betriebssystemdatenträgers und der VM-SKU nicht weit auseinanderliegen. Eine Diskrepanz bei der Größe oder Leistung kann zu Leistungsproblemen und Ressourcenkonflikten führen.

Die Anwendungsleistung ist eng mit den VM-SKUs verknüpft, die Sie in Ihren Workloads verwenden. Größere und leistungsstärkere VMs bieten im Allgemeinen eine bessere Leistung. Für unternehmenskritische Workloads oder Produktworkloads empfehlen wir die Verwendung virtueller Computer, die mindestens über eine CPU mit acht Kernen verfügen. Virtuelle Computer mit neueren Hardwaregenerationen wie v4 und v5 können ebenfalls zur Verbesserung der Leistung beitragen. Beachten Sie, dass die Wartezeiten bei der Erstellung und Skalierung abhängig von den verwendeten VM-SKUs variieren können.

Verwenden dedizierter Systemknotenpools

Aus Leistungs- und Zuverlässigkeitsgründen empfehlen wir die Verwendung eines dedizierten Systemknotenpools. Mit dieser Konfiguration reserviert der dedizierte Systemknotenpool Platz für kritische Systemressourcen wie Betriebssystem-Daemons des Systems. Ihre Anwendungsworkload kann dann in einem Benutzerknotenpool ausgeführt werden, um die Verfügbarkeit zuteilbarer Ressourcen für Ihre Anwendung zu erhöhen. Diese Konfiguration trägt auch dazu bei, das Risiko eines Ressourcenwettbewerbs zwischen System und Anwendung zu verringern.

Vorgänge erstellen

Überprüfen Sie die Erweiterungen und Add-Ons, die Sie während der Erstellung der Bereitstellung aktiviert haben. Erweiterungen und Add-Ons können die Gesamtdauer von Erstellungsvorgängen aufgrund von zusätzlicher Wartezeit verlängern. Es empfiehlt sich, nicht benötigte Erweiterungen oder Add-Ons zu entfernen, um die Wartezeit zu verbessern.

Sie können auch Verfügbarkeitszonen verwenden, um eine höhere Verfügbarkeit zu erreichen und sich vor Hardwarefehlern oder geplanten Wartungsereignissen zu schützen. AKS-Cluster verteilen Ressourcen auf logische Abschnitte der zugrunde liegenden Azure-Infrastruktur. Verfügbarkeitszonen trennen Knoten physisch voneinander, um sicherzustellen, dass sich ein einzelner Fehler nicht auf die Verfügbarkeit Ihrer Anwendung auswirkt. Verfügbarkeitszonen sind nur in bestimmten Regionen verfügbar. Weitere Informationen finden Sie unter Was sind Verfügbarkeitszonen in Azure?.

Kubernetes-API-Server

LIST- und WATCH-Vorgänge

Kubernetes verwendet LIST- und WATCH-Vorgänge, um mit dem Kubernetes-API-Server zu interagieren und Informationen zu Clusterressourcen zu überwachen. Diese Vorgänge sind von grundlegender Bedeutung für die Ressourcenverwaltung durch Kubernetes.

Der LIST-Vorgang ruft eine Liste von Ressourcen ab, die bestimmte Kriterien erfüllen, z. B. alle Pods in einem bestimmten Namespace oder alle Dienste im Cluster. Dieser Vorgang ist nützlich, wenn Sie sich einen Überblick über Ihre Clusterressourcen verschaffen möchten oder gleichzeitig Vorgänge für mehrere Ressourcen ausführen müssen.

Der LIST-Vorgang kann große Datenmengen abrufen, insbesondere in großen Clustern mit mehreren Ressourcen. Beachten Sie, dass unbegrenzte oder häufige LIST-Aufrufe den API-Server stark belasten und Antworten stark verzögern können.

Der WATCH-Vorgang dient zur Ressourcenüberwachung in Echtzeit. Wenn Sie einen WATCH-Vorgang für eine Ressource einrichten, sendet Ihnen der API-Server Updates, wenn Änderungen an dieser Ressource vorgenommen wurden. Dies ist wichtig für Controller (z. B. für den ReplicaSet-Controller), die WATCH nutzen, um den gewünschten Zustand der Ressourcen beizubehalten.

Beachten Sie, dass die Überwachung zu vieler änderbarer Ressourcen oder die Verwendung zu vieler gleichzeitiger WATCH-Anforderungen den API-Server überlasten und zu übermäßigem Ressourcenverbrauch führen kann.

Um potenzielle Probleme zu vermeiden und die Stabilität der Kubernetes-Steuerungsebene zu gewährleisten, können Sie folgende Strategien verwenden:

Ressourcenkontingente

Implementieren Sie Ressourcenkontingente, um die Anzahl von Ressourcen zu begrenzen, die von einem bestimmten Benutzer/einer bestimmten Benutzerin oder von einem bestimmten Namespace aufgelistet oder überwacht werden können, um übermäßig viele Aufrufe zu verhindern.

API-Priorität und Fairness

Kubernetes hat das Konzept von API-Priorität und Fairness (APF) eingeführt, um API-Anforderungen zu priorisieren und zu verwalten. Sie können APF in Kubernetes verwenden, um den API-Server des Clusters zu schützen und die Anzahl von Antworten vom Typ HTTP 429 Too Many Requests für Clientanwendungen zu verringern.

Benutzerdefinierte Ressource	Schlüsselfunktionen
PriorityLevelConfigurations	• Definieren unterschiedliche Prioritätsstufen für API-Anforderungen. • Geben einen eindeutigen Namen an und weisen einen ganzzahligen Wert zu, der die Prioritätsstufe darstellt. Höhere Prioritätsstufen haben niedrigere ganzzahlige Werte, um anzugeben, dass sie wichtiger sind. • Kann mehrere Elemente verwenden, um Anforderungen basierend auf ihrer Wichtigkeit in verschiedene Prioritätsstufen zu kategorisieren. • Ermöglichen die Angabe, ob für Anforderungen auf einer bestimmten Prioritätsstufe Ratenbegrenzungen gelten sollen.
FlowSchemas	• Definieren, wie API-Anforderungen basierend auf Anforderungsattributen an verschiedene Prioritätsstufen weitergeleitet werden sollen. • Geben Regeln an, die Anforderungen basierend auf Kriterien wie API-Gruppen, Versionen und Ressourcen abgleichen. • Wenn eine Anforderung einer bestimmten Regel entspricht, wird die Anforderung an die Prioritätsstufe weitergeleitet, die in der zugeordneten Prioritätsstufenkonfiguration (PriorityLevelConfiguration) angegeben ist. • Können verwendet werden, um die Reihenfolge der Auswertung festzulegen, wenn mehrere Flow-Schemas einer Anforderung entsprechen. So kann sichergestellt werden, dass bestimmte Regeln Vorrang haben.

Das Konfigurieren der API mit PriorityLevelConfigurations und FlowSchemas ermöglicht die Priorisierung kritischer API-Anforderungen gegenüber weniger wichtiger Anforderungen. Dadurch wird sichergestellt, dass wesentliche Vorgänge nicht durch Anforderungen mit niedrigerer Priorität blockiert oder verzögert werden.

Optimieren von Bezeichnungen und Selektoren

Optimieren Sie bei Verwendung von LIST-Vorgängen die Bezeichnungsauswahl, um den Umfang der abzufragenden Ressourcen einzugrenzen, damit weniger Daten zurückgegeben werden und der API-Server entlastet wird.

In Kubernetes beziehen sich CREATE- und UPDATE-Vorgänge auf Aktionen zum Verwalten und Ändern von Clusterressourcen.

CREATE- und UPDATE-Vorgänge

Der CREATE-Vorgang erstellt neue Ressourcen im Kubernetes-Cluster, z. B. Pods, Dienste, Bereitstellungen, ConfigMaps und Geheimnisse. Im Zuge eines CREATE-Vorgangs sendet ein Client (beispielsweise kubectl oder ein Controller) eine Anforderung an den Kubernetes-API-Server, um die neue Ressource zu erstellen. Der API-Server überprüft die Anforderung, stellt die Einhaltung aller ggf. vorhandenen Zulassungscontrollerrichtlinien sicher und erstellt dann die Ressource im gewünschten Zustand des Clusters.

Der UPDATE-Vorgang ändert vorhandene Ressourcen im Kubernetes-Cluster. Hierzu zählen auch Änderungen an Ressourcenspezifikationen wie der Anzahl von Replikaten, Containerimages, Umgebungsvariablen oder Bezeichnungen. Im Zuge eines UPDATE-Vorgangs sendet ein Client eine Anforderung an den API-Server, um eine vorhandene Ressource zu aktualisieren. Der API-Server überprüft die Anforderung, wendet die Änderungen auf die Ressourcendefinition an und aktualisiert die Clusterressource.

CREATE- und UPDATE-Vorgänge können sich unter folgenden Bedingungen auf die Leistung des Kubernetes-API-Servers auswirken:

• Hohe Parallelität: Wenn mehrere Benutzer*innen oder Anwendungen gleichzeitig CREATE- oder UPDATE-Anforderungen ausführen, kann dies zu einem plötzlichen Anstieg der API-Anforderungen führen, die gleichzeitig beim Server ankommen. Dies kann die Verarbeitungskapazität des API-Servers strapazieren und Leistungsprobleme verursachen.
• Komplexe Ressourcendefinitionen: Ressourcendefinitionen, die übermäßig komplex sind oder mehrere geschachtelte Objekte umfassen, können dazu führen, dass der API-Server mehr Zeit für die Überprüfung und Verarbeitung von CREATE- und UPDATE-Anforderungen benötigt, was wiederum Leistungsbeeinträchtigungen zur Folge haben kann.
• Ressourcenüberprüfung und Zulassungssteuerung: Kubernetes erzwingt verschiedene Zulassungssteuerungsrichtlinien und Validierungsprüfungen für eingehende CREATE- und UPDATE-Anforderungen. Umfangreiche Ressourcendefinitionen (beispielsweise Definitionen mit umfangreichen Anmerkungen oder Konfigurationen) erhöhen möglicherweise die Verarbeitungszeit.
• Benutzerdefinierte Controller: Benutzerdefinierte Controller, die die Umgebung auf Änderungen an Ressourcen überwachen (beispielsweise Deployments- oder StatefulSet-Controller), können beim Skalieren oder beim Rollout von Änderungen eine große Menge an Updates generieren. Diese Updates können die Ressourcen des API-Servers belasten.

Weitere Informationen finden Sie unter Behandeln von Problemen mit API-Servern und etcd in Azure Kubernetes Services.

Leistung der Datenebene

Die Kubernetes-Datenebene ist für die Verwaltung des Netzwerkdatenverkehrs zwischen Containern und Diensten verantwortlich. Probleme mit der Datenebene können zu langsamen Reaktionen sowie zu Leistungsbeeinträchtigungen und Anwendungsausfällen führen. Es ist wichtig, Datenebenenkonfigurationen wie Netzwerklatenz, Ressourcenzuordnung, Containerdichte und Netzwerkrichtlinien sorgfältig zu überwachen und zu optimieren, um sicherzustellen, dass Ihre containerisierten Anwendungen reibungslos und effizient ausgeführt werden.

Speichertypen

AKS empfiehlt kurzlebige Betriebssystemdatenträger und verwendet diese standardmäßig. Kurzlebige Betriebssystemdatenträger werden im lokalen VM-Speicher erstellt und nicht wie verwaltete Betriebssystemdatenträger in einem Azure-Remotespeicher gespeichert. Sie zeichnen sich durch schnelleres Reimaging und kürzere Startzeiten aus, was schnellere Clustervorgänge ermöglicht, und sie bieten geringere Wartezeiten bei Lese-/Schreibvorgängen auf dem Betriebssystemdatenträger von AKS-Agent-Knoten. Kurzlebige Betriebssystemdatenträger eignen sich gut für zustandslose Workloads, bei denen Anwendungen einzelne VM-Ausfälle tolerieren, aber nicht die VM-Bereitstellungsdauer oder einzelne VM-Reimaging-Instanzen. Da kurzlebige Betriebssystemdatenträger nur von bestimmten VM-SKUs unterstützt werden, müssen Sie darauf achten, dass die gewünschte SKU-Generation und die Größe kompatibel sind. Weitere Informationen finden Sie unter Verwenden eines kurzlebigen Betriebssystems in neuen Clustern.

Wenn Ihre Workload keine kurzlebigen Betriebssystemdatenträger nutzen kann, verwendet AKS standardmäßig SSD Premium-Betriebssystemdatenträger. Sollten SSD Premium-Betriebssystemdatenträger nicht mit Ihrer Workload kompatibel sein, verwendet AKS standardmäßig SSD Standard-Datenträger. Ansonsten ist derzeit nur noch „HDD Standard“ als anderer Betriebssystemdatenträgertyp verfügbar. Weitere Informationen finden Sie unter Speicheroptionen für Anwendungen in Azure Kubernetes Service (AKS).

Die folgende Tabelle enthält eine Aufschlüsselung der vorgeschlagenen Anwendungsfälle für Betriebssystemdatenträger, die in AKS unterstützt werden:

Typ des Betriebssystemdatenträgers	Schlüsselfunktionen	Vorgeschlagene Anwendungsfälle
Kurzlebige Betriebssystemdatenträger	• Schnelleres Reimaging und kürzere Startzeiten • Geringere Wartezeiten bei Lese-/Schreibvorgängen auf dem Betriebssystemdatenträger von AKS-Agent-Knoten • Hochleistung und -verfügbarkeit	• Anspruchsvolle Unternehmensworkloads wie SQL Server, Oracle, Dynamics, Exchange Server, MySQL, Cassandra, MongoDB, SAP Business Suite usw. • Zustandslose Produktionsworkloads, die Hochverfügbarkeit und geringe Wartezeit erfordern
SSD Premium-Betriebssystemdatenträger	• Konsistente Leistung und geringe Wartezeit • Hochverfügbarkeit	• Anspruchsvolle Unternehmensworkloads wie SQL Server, Oracle, Dynamics, Exchange Server, MySQL, Cassandra, MongoDB, SAP Business Suite usw. • E/A-intensive Unternehmensworkloads
SSD Standard-Betriebssystemdatenträger	• Konsistente Leistung • Höhere Verfügbarkeit und geringere Wartezeit im Vergleich zu HDD Standard-Datenträgern	• Webserver Anwendungsserver mit wenig Ein-/Ausgabevorgängen pro Sekunde (Input/Output Operations Per Second, IOPS) • Wenig genutzte Unternehmensanwendungen • Dev/Test-Workloads
Standard-HDD-Datenträger	• Geringe Kosten • Variabilität bei Leistung und Wartezeit	• Sicherungsspeicher • Massenspeicher mit seltenem Zugriff

IOPS und Durchsatz

Eingabe-/Ausgabevorgänge pro Sekunde (Input/Output Operations Per Second, IOPS) beziehen sich auf die Anzahl von Lese- und Schreibvorgängen, die ein Datenträger in einer einzelnen Sekunde ausführen kann. Der Durchsatz bezieht sich auf die Datenmenge, die in einem bestimmten Zeitraum übertragen werden kann.

Betriebssystemdatenträger dienen zum Speichern des Betriebssystems und der zugehörigen Dateien. Die virtuellen Computer sind für die Ausführung der Anwendungen zuständig. Achten Sie bei der Wahl eines virtuellen Computers darauf, dass Größe und Leistung des Betriebssystemdatenträgers und der VM-SKU nicht weit auseinanderliegen. Eine Diskrepanz bei der Größe oder Leistung kann zu Leistungsproblemen und Ressourcenkonflikten führen. Wenn der Betriebssystemdatenträger beispielsweise erheblich kleiner ist als die virtuellen Computer, begrenzt er möglicherweise den für Anwendungsdaten verfügbaren Speicherplatz, was dazu führen kann, dass dem System nicht genügend Speicherplatz auf dem Datenträger zur Verfügung steht. Hat der Betriebssystemdatenträger eine geringere Leistung als die virtuellen Computer, kann er zu einem Engpass werden und die Gesamtleistung des Systems beeinträchtigen. Achten Sie auf eine ausgewogene Größe und Leistung, um in Kubernetes eine optimale Leistung zu erzielen.

Mit den folgenden Schritten können Sie im Azure-Portal IOPS- und Bandbreitenverbrauchseinheiten für Betriebssystemdatenträger überwachen:

1. Navigieren Sie zum Azure-Portal.
2. Suchen Sie nach VM-Skalierungsgruppen, und wählen Sie Ihre VM-Skalierungsgruppe aus.
3. Wählen Sie unter Überwachung die Option Metriken aus.

Kurzlebige Betriebssystemdatenträger können IOPS und Durchsatz dynamisch für Ihre Anwendung bereitstellen. Bei verwalteten Datenträgern gibt es dagegen eine Obergrenze für IOPS und Durchsatz. Weitere Informationen finden Sie unter Kurzlebige Betriebssystemdatenträger für virtuelle Azure-Computer.

Azure SSD Premium v2 ist für E/A-intensive Unternehmensworkloads konzipiert, die Datenträgerwartezeiten unter einer Millisekunde und eine hohe IOPS- und Durchsatzleistung bei niedrigen Kosten erfordern. Diese Option eignet sich für eine breite Palette von Workloads wie SQL Server, Oracle, MariaDB, SAP, Cassandra, MongoDB, Big Data/Analysen, Gaming und Ähnliches. Dieser Datenträgertyp ist die leistungsstärkste Option, die derzeit für persistente Volumes verfügbar ist.

Pod-Zeitplanung

Der Arbeitsspeicher und die CPU-Ressourcen, die einem virtuellen Computer zugeordnet sind, haben direkte Auswirkungen auf die Leistung der auf dem virtuellen Computer ausgeführten Pods. Wenn ein Pod erstellt wird, wird ihm eine bestimmte Menge an Arbeitsspeicher- und CPU-Ressourcen zugewiesen, die zum Ausführen der Anwendung verwendet werden. Wenn der virtuelle Computer nicht über genügend Arbeitsspeicher- oder CPU-Ressourcen verfügt, werden die Pods möglicherweise verlangsamt oder stürzen sogar ab. Wenn der virtuelle Computer über zu viel Arbeitsspeicher- oder CPU-Ressourcen verfügt, ist die Ausführung der Pods möglicherweise ineffizient, wodurch Ressourcen vergeudet werden und höhere Kosten anfallen. Es empfiehlt sich, die Gesamtanzahl von Podanforderungen all Ihrer Workloads anhand der insgesamt zuteilbaren Ressourcen zu überwachen, um eine bestmögliche Planbarkeit und Leistung zu erzielen. Sie können auch --max-pods verwenden, um basierend auf Ihrer Kapazitätsplanung die maximale Anzahl von Pods pro Knoten festzulegen.