Bewährte Methoden für die Bereitstellungs- und Clustersicherheit für Azure Kubernetes Service (AKS)

Gilt für: ✔️ AKS Automatic ✔️ AKS Standard

Dieser Artikel enthält bewährte Methoden für die Clustersicherheit, die sowohl auf Bereitstellungs- als auch Clusterebene für Ihre Azure Kubernetes Service (AKS) Workloads implementiert wird. Der Artikel richtet sich an Clusteroperatoren und Entwickler, die für die Bereitstellung und Verwaltung von Anwendungen in AKS verantwortlich sind.

Die bewährten Methoden in diesem Artikel sind in die folgenden Kategorien unterteilt:

AKS-Clustermodi und Zuverlässigkeit

AKS unterstützt zwei Clustermodi: AKS Automatic and AKS Standard. Viele Zuverlässigkeitsmethoden auf Arbeitsauslastungsebene gelten gleichermaßen für beide Modi, z. B. das Festlegen von Ressourcenanforderungen, das Definieren von Pod Disruption Budgets (PDBs), das Konfigurieren von Probes und das Ausführen mehrerer Replikate. Die Zuständigkeiten auf Clusterebene unterscheiden sich jedoch je nach Modus:

• AKS Automatic bietet mehr vorkonfigurierte Zuverlässigkeitsstandards, einschließlich verwalteter Systemknotenpools, Node AutoProvisioning (NAP), automatische Clusterupgrades, automatische Betriebssystemimageupgrades, Standardebene und LocalDNS.
• AKS Standard bietet eine umfassendere direkte Konfigurationskontrolle und erfordert, dass Operatoren mehr Zuverlässigkeitsfeatures auf Clusterebene explizit aktivieren und verwalten.

Weitere Informationen finden Sie unter Was ist AKS Automatic?

Bewährte Methoden auf Bereitstellungsebene

Die folgenden bewährten Methoden auf Bereitstellungsebene tragen dazu bei, hohe Verfügbarkeit und Zuverlässigkeit für Ihre AKS-Workloads sicherzustellen. Diese bewährten Methoden sind lokale Konfigurationen, die Sie in den YAML-Dateien für Ihre Pods und Bereitstellungen implementieren können.

Pod-CPU- und Speichergrenzwerte

Leitfaden für bewährte Methoden:

Legen Sie Pod-CPU- und Speichergrenzwerte für alle Pods fest, um sicherzustellen, dass Pods nicht alle Ressourcen auf einem Knoten verbrauchen, und um Schutz vor Dienstbedrohungen wie DDoS-Angriffen zu bieten.

Pod-CPU- und Speichergrenzwerte definieren die maximale CPU- und Speichermenge, die ein Pod verwenden kann. Wenn ein Pod seine definierten Grenzwerte überschreitet, wird er zum Entfernen markiert. Weitere Informationen finden Sie unter CPU-Ressourceneinheiten in Kubernetes und Speicherressourceneinheiten in Kubernetes.

Durch das Festlegen von CPU- und Speichergrenzwerten können Sie den Status von Knoten beibehalten und die Auswirkungen auf andere Pods auf dem Knoten minimieren. Vermeiden Sie es, einen höheren Podgrenzwert festzulegen, als Ihre Knoten unterstützen können. Jeder AKS-Knoten reserviert eine bestimmte Menge von CPU-Leistung und Arbeitsspeichermenge für die Kubernetes-Kernkomponenten. Wenn Sie einen Pod-Grenzwert höher festlegen, als der Knoten unterstützen kann, versucht Ihre Anwendung möglicherweise, zu viele Ressourcen zu verbrauchen und wirkt sich negativ auf andere Pods auf den Knoten aus. Clusteradministratoren müssen Ressourcenkontingente für einen Namespace festlegen, der von Ihnen das Festlegen von Ressourcenanforderungen und -grenzwerten erfordert. Weitere Informationen finden Sie unter Durchsetzen von Ressourcenkontingenten in AKS.

Clusteradministratoren können diese Einstellungen auch mit Kontingenten auf Namespace-Ebene und Richtlinienkontrollen zusätzlich absichern. In AKS Automatic können Bereitstellungsschutzmechanismen dazu beitragen, ressourcenbezogene bewährte Methoden zu erzwingen. Operatoren sollten jedoch weiterhin arbeitsauslastungsgerechte Anforderungen und Grenzwerte explizit definieren. Weitere Informationen finden Sie unter Durchsetzen von Ressourcenkontingenten in AKS.

In der folgenden Beispiel-Pod-Definitionsdatei legt der Abschnitt resources die CPU- und Speichergrenzwerte für den Pod fest:

kind: Pod
apiVersion: v1
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
    resources:
      requests:
        cpu: 100m
        memory: 128Mi
      limits:
        cpu: 250m
        memory: 256Mi

kubectl describe node <node-name>

# Example output
Capacity:
 cpu:                8
 ephemeral-storage:  129886128Ki
 hugepages-1Gi:      0
 hugepages-2Mi:      0
 memory:             32863116Ki
 pods:               110
Allocatable:
 cpu:                7820m
 ephemeral-storage:  119703055367
 hugepages-1Gi:      0
 hugepages-2Mi:      0
 memory:             28362636Ki
 pods:               110

Weitere Informationen finden Sie unter Zuweisen von CPU-Ressourcen zu Containern und Pods und Zuweisen von Speicherressourcen zu Containern und Pods.

Vertikale automatische Podskalierung (VPA)

Leitfaden für bewährte Methoden:

Verwenden Sie Vertical Pod Autoscaler (VPA), um CPU- und Speicheranforderungen für Ihre Pods basierend auf ihrer tatsächlichen Nutzung automatisch anzupassen.

Zwar nicht direkt über den Pod YAML implementiert, hilft der Vertical Pod Autoscaler (VPA) dabei, die Ressourcenzuordnung zu optimieren, indem die CPU- und Speicheranforderungen für Ihre Pods automatisch angepasst werden. Dadurch wird sichergestellt, dass Ihre Anwendungen über die benötigten Ressourcen verfügen, um effizient ausgeführt zu werden, ohne dass eine Über- oder Unterversorgung erfolgt.

In AKS Automatic ist VPA standardmäßig auf dem Cluster aktiviert. In AKS Standard wählen Operatoren aus, ob sie aktiviert werden sollen.

VPA arbeitet in drei Modi:

• Aus: Stellt nur Empfehlungen bereit, ohne Änderungen anzuwenden.
• Auto: Aktualisiert automatisch Pod-Ressourcenanforderungen während pod-Neustarts.
• Initial: Legt Ressourcenanforderungen nur während der Erstellung des Pods fest.

Das folgende Beispiel zeigt, wie Sie eine VPA-Ressource in Kubernetes konfigurieren:

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: my-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: my-deployment
  updatePolicy:
    updateMode: "Auto" # Options: Off, Auto, Initial

Weitere Informationen finden Sie in der Dokumentation zur Vertikalen automatischen Podskalierung.

Pod Disruption Budgets (PDBs)

Leitfaden für bewährte Methoden:

Verwenden Sie Pod Disruption Budgets (PDBs), um sicherzustellen, dass eine minimale Anzahl von Pods während freiwilliger Unterbrechungen verfügbar bleibt, z. B. Upgradevorgänge oder versehentliche Podlöschungen.

Pod Disruption Budgets (PDBs) ermöglichen Ihnen, zu definieren, wie Bereitstellungen oder Replikatgruppen während freiwilliger Unterbrechungen reagieren, z. B. Upgradevorgänge oder versehentliche Podlöschungen. Mithilfe von PDBs können Sie eine minimale oder maximale nicht verfügbare Ressourcenanzahl definieren. PDBs wirken sich nur auf die Entfernungs-API für freiwillige Unterbrechungen aus.

Angenommen, Sie müssen ein Clusterupgrade durchführen und haben bereits einen PDB definiert. Vor dem Durchführen des Clusterupgrades stellt der Kubernetes-Scheduler sicher, dass die Mindestanzahl der im PDB definierten Pods verfügbar ist. Wenn das Upgrade dazu führen würde, dass die Anzahl der verfügbaren Pods unter dem in den PDBs definierten Minimum fällt, plant der Scheduler zusätzliche Pods auf anderen Knoten, bevor das Upgrade fortgesetzt werden kann. Wenn Sie keinen PDB festlegen, hat der Scheduler keine Einschränkungen für die Anzahl der Pods, die während des Upgrades nicht verfügbar sein können, was zu einem Mangel an Ressourcen und potenziellen Clusterausfällen führen kann.

Die Automatisierung von Upgrades auf Clusterebene in AKS Automatic reduziert einige Betriebliche Belastung, die Arbeitsauslastung während einer Unterbrechung hängt jedoch weiterhin von Steuerelementen auf Anwendungsebene wie Z. B. PDBs ab.

Im folgenden Beispiel der PDB-Definitionsdatei legt das Feld minAvailable die Mindestanzahl von Pods fest, die während freiwilliger Unterbrechungen verfügbar bleiben müssen. Der Wert kann eine absolute Zahl (z. B. 3) oder ein Prozentsatz der gewünschten Anzahl von Pods (z. B. 10 %) sein.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
   name: mypdb
spec:
   minAvailable: 3 # Minimum number of pods that must remain available during voluntary disruptions
   selector:
    matchLabels:
      app: myapp

Weitere Informationen finden Sie unter Planen der Verfügbarkeit mithilfe von PDBs und Festlegen eines Unterbrechungsbudgets für Ihre Anwendung.

Informationen zum Automatisieren der PDB-Erstellung für ungeschützte Bereitstellungen und zum Verhindern von PDB-bezogenen Drainfehlern bei Upgrades finden Sie unter Automatische PDB-Verwaltung für AKS (Vorschau).

Sanfte Beendigung von Pods

Leitfaden für bewährte Methoden:

Verwenden Sie PreStop-Hooks und konfigurieren Sie einen geeigneten terminationGracePeriodSeconds-Wert, um sicherzustellen, dass Pods ordnungsgemäß beendet werden.

Eine ordnungsgemäße Beendigung stellt sicher, dass Pods genügend Zeit erhalten, um Ressourcen aufzuräumen, laufende Aufgaben abzuschließen oder abhängige Dienste zu benachrichtigen, bevor sie beendet werden. Dies ist besonders wichtig für zustandsbehaftete Anwendungen oder Dienste, die ordnungsgemäße Abschaltvorgänge erfordern.

Verwenden von PreStop-Hooks

Ein PreStop Hook wird unmittelbar aufgerufen, bevor ein Container aufgrund einer API-Anforderung oder eines Verwaltungsereignisses beendet wird, z. B. Vorbehaltung, Ressourcenverknügung oder Live-/Starttestfehler. Mit PreStop dem Hook können Sie benutzerdefinierte Befehle oder Skripts definieren, die ausgeführt werden sollen, bevor der Container beendet wird. Beispielsweise können Sie sie verwenden, um Protokolle zu leeren, Datenbankverbindungen zu schließen oder andere Dienste über das Herunterfahren zu benachrichtigen.

Die folgende Beispiel-Poddefinitionsdatei zeigt, wie Sie einen PreStop Hook verwenden, um eine ordnungsgemäße Beendigung eines Containers sicherzustellen:

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: nginx
    lifecycle:
      preStop:
        exec:
          command: ["/bin/sh", "-c", "nginx -s quit; while killall -0 nginx; do sleep 1; done"]

Konfigurieren von terminationGracePeriodSeconds

Das Feld terminationGracePeriodSeconds gibt die Zeitspanne an, die Kubernetes wartet, bevor ein Pod erzwungen beendet wird. Dieser Zeitraum umfasst die Zeit, die zum Ausführen des PreStop Hooks erforderlich ist. Wenn der PreStop-Hook nicht innerhalb der Toleranzperiode abgeschlossen wird, wird der Pod zwangsweise beendet.

Die folgende Poddefinition legt z. B. eine Nachfrist von 30 Sekunden fest:For example, the following pod definition sets a termination grace period of 30 seconds:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  terminationGracePeriodSeconds: 30
  containers:
  - name: example-container
    image: nginx

Weitere Informationen finden Sie unter Containerlebenszyklus-Hooks und Beendigung von Pods.

Hohe Verfügbarkeit während Upgrades

Verwenden maxSurge für schnellere Updates

Leitfaden für bewährte Methoden:

Konfigurieren Sie das maxSurge Feld so, dass zusätzliche Pods während rollierender Updates erstellt werden können, sodass schnellere Updates mit minimalen Ausfallzeiten möglich sind.

Das maxSurge Feld gibt die maximale Anzahl zusätzlicher Pods an, die während einer rollierenden Aktualisierung über die gewünschte Anzahl von Pods hinaus erstellt werden können. Auf diese Weise können neue Pods erstellt und bereit werden, bevor alte Pods beendet werden, um schnellere Updates sicherzustellen und das Risiko von Ausfallzeiten zu verringern.

Das folgende Beispiel Bereitstellungsmanifest zeigt, wie man maxSurge konfiguriert.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 33% # Maximum number of additional pods created during the update

Durch Die Einstellung maxSurge auf 3 stellt diese Konfiguration sicher, dass während des rollierenden Updates bis zu drei zusätzliche Pods erstellt werden können, um den Bereitstellungsprozess zu beschleunigen und gleichzeitig die Verfügbarkeit Ihrer Anwendung aufrechtzuerhalten. Weitere Informationen finden Sie unter Rolling Updates in Kubernetes.

Verwenden maxUnavailable für kontrollierte Updates

Leitfaden für bewährte Methoden:

Konfigurieren Sie das maxUnavailable Feld, um die Anzahl der Pods zu begrenzen, die während rollierender Updates nicht verfügbar sein können, um sicherzustellen, dass Ihre Anwendung mit minimalen Unterbrechungen betriebsbereit bleibt.

Das maxUnavailable Feld ist besonders nützlich für Anwendungen, die rechenintensiv sind oder bestimmte Infrastrukturanforderungen haben. Es gibt die maximale Anzahl von Pods an, die während eines rollierenden Updates zu einem bestimmten Zeitpunkt nicht verfügbar sein können. Dadurch wird sichergestellt, dass ein Teil Ihrer Anwendung funktionsfähig bleibt, während neue Pods bereitgestellt werden und alte beendet werden.

maxUnavailable Sie können eine absolute Zahl (z. B. 1) oder einen Prozentsatz der gewünschten Anzahl von Pods (z. B. 25%) festlegen. Beispielsweise sorgt Kubernetes, wenn Ihre Anwendung vier Replikate aufweist und Sie maxUnavailable auf 1 festlegen, dafür, dass mindestens drei Pods während des Aktualisierungsprozesses verfügbar bleiben.

Das folgende Beispiel Bereitstellungsmanifest zeigt, wie man maxUnavailable konfiguriert.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 4
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1 # Maximum number of pods that can be unavailable during the update

In diesem Beispiel wird durch das Setzen von maxUnavailable auf 1 sichergestellt, dass während des rollierenden Updates zu keinem Zeitpunkt mehr als ein Pod nicht verfügbar ist. Diese Konfiguration eignet sich ideal für Anwendungen, die eine spezielle Berechnung erfordern, bei der die Aufrechterhaltung eines minimalen Dienstverfügbarkeitsgrads von entscheidender Bedeutung ist.

Weitere Informationen finden Sie unter Rolling Updates in Kubernetes.

Beschränkungen der Pod-Topologieverteilung

Leitfaden für bewährte Methoden:

Verwenden Sie Podtopologie-Spread-Einschränkungen, um sicherzustellen, dass Pods über verschiedene Knoten oder Zonen verteilt sind, um die Verfügbarkeit und Zuverlässigkeit zu verbessern.

Sie können Beschränkungen der Pod-Topologieverteilung verwenden, um zu steuern wie Pods sich in Ihrem Cluster basierend auf der Topologie der Knoten verteilen und Pods sich über verschiedene Knoten oder Zonen verteilen, um Verfügbarkeit und Zuverlässigkeit zu erhöhen.

In AKS Automatic können Bereitstellungsvorkehrungen dabei helfen, einige bewährte Methoden für die Workloadverteilung anzuwenden, anwendungsspezifische Topologieanforderungen sollten jedoch weiterhin explizit in Workloadmanifesten definiert werden.

Die folgende Beispiel-Poddefinitionsdatei zeigt, wie Sie das topologySpreadConstraints-Feld zum Verteilen von Pods auf verschiedene Knoten verwenden:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  # Configure a topology spread constraint
  topologySpreadConstraints:
    - maxSkew: <integer>
      minDomains: <integer> # optional
      topologyKey: <string>
      whenUnsatisfiable: <string>
      labelSelector: <object>
      matchLabelKeys: <list> # optional
      nodeAffinityPolicy: [Honor|Ignore] # optional
      nodeTaintsPolicy: [Honor|Ignore] # optional

Weitere Informationen finden Sie unter Beschränkungen der Pod-Topologieverteilung.

Bereitschafts-, Live- und Starttests

Leitfaden für bewährte Methoden:

Konfigurieren Sie Bereitschafts-, Live- und Starttests, wenn sie anwendbar sind, um die Resilienz bei hohen Lasten und niedrigeren Containerneustarts zu verbessern.

Auch wenn AKS Automatic grundlegende Sicherheitsvorkehrungen bereitstellt, bleibt die Prüfpunktkonfiguration arbeitslastspezifisch und sollte weiterhin in Anwendungsmanifesten erstellt werden.

Bereitschaftstest

In Kubernetes verwendet das Kubelet Bereitschaftstests, um zu wissen, wann ein Container bereit ist, den Datenverkehr zu akzeptieren. Ein Pod gilt als bereit, wenn alle Container bereit sind. Wenn ein Pod nicht bereit ist, wird er aus Dienstlastenausgleichsmodulen entfernt. Weitere Informationen finden Sie unter Bereitschaftstests in Kubernetes.

Die folgende Beispiel-Pod-Definitionsdatei zeigt eine Konfiguration des Bereitschaftstests:

readinessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy
  initialDelaySeconds: 5
  periodSeconds: 5

Weitere Informationen finden Sie unter Konfigurieren von Bereitschaftstests.

Livetest

In Kubernetes verwendet das Kubelet Livetests, um zu wissen, wann ein Container neu gestartet werden soll. Wenn ein Container seinen Livetest nicht erfüllt, wird der Container neu gestartet. Weitere Informationen finden Sie unter Livetests in Kubernetes.

Die folgende Beispiel-Pod-Definitionsdatei zeigt eine Livetestkonfiguration:

livenessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy

Eine andere Art von Livetest verwendet eine HTTP GET-Anforderung. Die folgende Beispiel-Pod-Definitionsdatei zeigt eine Konfiguration eines HTTP GET-Anforderungs-Livetest:

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: registry.k8s.io/liveness
    args:
    - /server
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

Weitere Informationen finden Sie unter Livetest konfigurieren und Live-HTTP-Anforderung definieren.

Starttests

In Kubernetes verwendet das Kubelet Starttests, um zu wissen, wann eine Containeranwendung gestartet wurde. Wenn Sie einen Starttest konfigurieren, werden Bereitschafts- und Livetests erst gestartet, wenn der Starttest erfolgreich ist, um sicherzustellen, dass die Bereitschafts- und Livetests den Anwendungsstart nicht beeinträchtigen. Weitere Informationen finden Sie unter Starttests in Kubernetes.

Die folgende Beispiel-Poddefinitionsdatei zeigt eine Starttestkonfiguration:

startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  failureThreshold: 30
  periodSeconds: 10

Multireplikatanwendungen

Leitfaden für bewährte Methoden:

Stellen Sie mindestens zwei Replikate Ihrer Anwendung bereit, um hohe Verfügbarkeit und Ausfallsicherheit in Knotenausfallszenarien sicherzustellen.

In Kubernetes können Sie das Feldreplicas in Ihrer Bereitstellung verwenden, um die Anzahl der Pods anzugeben, die Sie ausführen möchten. Das Ausführen mehrerer Instanzen Ihrer Anwendung trägt dazu bei, hohe Verfügbarkeit und Resilienz bei Knotenausfallszenarien sicherzustellen. AKS Automatic verbessert die Betriebsbereitschaft und das Skalierungsverhalten, aber die Verfügbarkeit hängt dennoch davon ab, genügend Replikate auszuführen und geeignete Platzierungssteuerelemente zu verwenden. Wenn Verfügbarkeitszonen aktiviert sind, können Sie das Feldreplicas verwenden, um die Anzahl der Pods anzugeben, die über mehrere Verfügbarkeitszonen hinweg ausgeführt werden sollen.

Die folgende Beispiel-Poddefinitionsdatei zeigt, wie Sie das Feldreplicas verwenden, um die Anzahl der Pods anzugeben, die Sie ausführen möchten:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Weitere Informationen finden Sie unter Übersicht über empfohlene Aktiv-Aktiv-Hochverfügbarkeitslösungen für AKS und Replikate in den Bereitstellungsspezifikationen.

Bewährte Methoden auf Cluster- und Knotenpoolebene

Die folgenden bewährten Methoden auf Cluster- und Knotenpoolebene tragen dazu bei, hohe Verfügbarkeit und Zuverlässigkeit für Ihre AKS-Cluster sicherzustellen. Sie können diese bewährten Methoden implementieren, wenn Sie Ihre AKS-Cluster erstellen oder aktualisieren. Im Vergleich zu Einstellungen auf Bereitstellungsebene unterscheidet sich die Verantwortung erheblich zwischen AKS Automatic und AKS Standard.

Verfügbarkeitszonen

Leitfaden für bewährte Methoden:

Verwenden Sie beim Erstellen eines AKS-Clusters mehrere Verfügbarkeitszonen, um eine hohe Verfügbarkeit bei Knotenausfallszenarien sicherzustellen. Denken Sie daran, dass Sie die Verfügbarkeitszonenkonfiguration nach dem Erstellen des Clusters nicht mehr ändern können.

Verfügbarkeitszonen sind getrennte Gruppen von Rechenzentren innerhalb einer Region. Diese Zonen sind nahe genug, um Verbindungen mit geringer Latenz miteinander zu haben, aber weit genug auseinander, um die Wahrscheinlichkeit zu verringern, dass mehr als eine Zone von lokalen Ausfällen oder Wetter betroffen ist. Durch die Verwendung von Verfügbarkeitszonen können Ihre Daten bei Knotenausfallszenarien synchronisiert und zugänglich bleiben. Weitere Informationen finden Sie unter Ausführen in mehreren Zonen.

AKS Automatic vereinfacht den Day-2-Betrieb, macht es jedoch nicht überflüssig, die Topologie bei der Clustererstellung zu planen, wenn eine zonale Bereitstellung Teil der Architektur ist.

Automatische Skalierung von Clustern

Leitfaden für bewährte Methoden:

Verwenden Sie die automatische Skalierung von Clustern, um sicherzustellen, dass Ihr Cluster eine erhöhte Last verarbeiten und die Kosten bei geringer Auslastung reduzieren kann.

Um mit den Anwendungsanforderungen in AKS Schritt zu halten, müssen Sie möglicherweise die Anzahl der Knoten anpassen, auf denen Ihre Arbeitslasten ausgeführt werden. Die Komponente für die automatische Clusterskalierung überwacht auf Pods in Ihrem Cluster, die aufgrund von Ressourceneinschränkungen nicht geplant werden können. Wenn die automatische Clusterskalierung Probleme erkennt, skaliert sie die Anzahl der Knoten im Knotenpool hoch, um den Anwendungsbedarf zu erfüllen. Sie überprüft außerdem regelmäßig Konten auf einen Mangel an ausgeführten Pods und skaliert bei Bedarf die Anzahl der Knoten herunter. Weitere Informationen finden Sie unter Automatische Skalierung von Clustern in AKS.

Das Skalierungsverhalten unterscheidet sich je nach Clustermodus:

• AKS Automatic: Die automatische Bereitstellung von Knoten ist vorkonfiguriert und Workloadskalierungsfeatures wie HPA, KEDA und VPA sind standardmäßig aktiviert.
• AKS Standard: Betreiber aktivieren und konfigurieren explizit den Cluster Autoscaler, die automatische Knotenbereitstellung und Workloadautoskalierungsfunktionen.

Bei AKS Standard können Sie den --enable-cluster-autoscaler Parameter beim Erstellen eines Clusters verwenden:

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 2 \
    --vm-set-type VirtualMachineScaleSets \
    --load-balancer-sku standard \
    --enable-cluster-autoscaler  \
    --min-count 1 \
    --max-count 3 \
    --generate-ssh-keys

Sie können die Cluster-Autoskalierung auch in einem vorhandenen Knotenpool aktivieren und detailliertere Details der Cluster-Autoskalierung konfigurieren, indem Sie die Standardwerte im clusterweiten Autoskalierungsprofil ändern.

Weitere Informationen finden Sie unter Verwenden der automatischen Clusterskalierung in AKS.

Eingangs- und Ausgangssicherheit

Leitfaden für bewährte Methoden:

Verwenden Sie das Clusternetzwerkmodell, das Ihren AKS-Clustermodus- und Zuverlässigkeitsanforderungen entspricht.

Für AKS Standard bleibt Load Balancer Standard eine häufige und empfohlene Zuverlässigkeitsoption für eingehende und ausgehende Datenverkehrsszenarien.

Für AKS Automatic werden die Standardeinstellungen für Eingangs- und Ausgangsdatenverkehr stärker verwaltet:

• Verwaltetes virtuelles Netzwerk ist standardmäßig vorkonfiguriert.
• Verwaltetes NAT-Gateway ist für unterstützte szenarien mit verwaltetem virtuellem Netzwerk vorkonfiguriert.
• Der verwaltete Ingress über das Anwendungsrouting ist für unterstützte Clusterversionen vorkonfiguriert.

Wenn Sie AKS Standard verwenden, gelten weiterhin die folgenden Load Balancer Standard Anleitungen:

Load Balancer Standard

Leitfaden für bewährte Methoden:

Verwenden Sie die Load Balancer Standard, um mehr Zuverlässigkeit und Ressourcen bereitzustellen, Unterstützung für mehrere Verfügbarkeitszonen, HTTP-Prüfpunkte und Funktionen in mehreren Rechenzentren bereitzustellen.

In Azure ist die Load Balancer Standard-SKU für den Lastenausgleich von Netzwerkschichtdatenverkehr ausgelegt, wenn hohe Leistung und geringe Latenz erforderlich sind. Der Load Balancer Standard leitet den Datenverkehr innerhalb und zwischen Regionen und an Verfügbarkeitszonen weiter, um eine hohe Ausfallsicherheit zu gewährleisten. Die Standard-SKU ist die empfohlene und standardmäßige SKU, die beim Erstellen eines AKS-Clusters verwendet werden soll.

Das folgende Beispiel zeigt ein LoadBalancer-Dienstmanifest, das die Load Balancer Standard verwendet:

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-ipv4 # Service annotation for an IPv4 address
  name: azure-load-balancer
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: azure-load-balancer

Weitere Informationen finden Sie unter Verwenden eines Standard Load Balancer in AKS.

Systemknotenpools

Verwenden dedizierter Systemknotenpools

AKS Automatic verwendet verwaltete Systemknotenpools, die erstellt, skaliert, aktualisiert und von AKS betrieben werden. Der Fokus des Operators verlagert sich vom manuellen Aufbau der Systempool-Topologie hin zur Validierung der Workload-Platzierung, des Kapazitätsverhaltens und der Kontrollen auf Namespace-Ebene.

Die folgenden Richtlinien gelten weiterhin für AKS Standard:

Leitfaden für bewährte Methoden:

Verwenden Sie Systemknotenpools, um sicherzustellen, dass keine anderen Benutzeranwendungen auf denselben Knoten ausgeführt werden, was zu Ressourcenknappheit und Auswirkungen auf Systempods führen kann.

Verwenden Sie dedizierte Systemknotenpools, um sicherzustellen, dass keine andere Benutzeranwendung auf denselben Knoten ausgeführt wird, was zu Knappheit von Ressourcen und potenziellen Clusterausfällen aufgrund von Racebedingungen führen kann. Um einen dedizierten Systemknotenpool zu verwenden, können Sie den TaintCriticalAddonsOnly im Systemknotenpool verwenden. Weitere Informationen finden Sie unter Verwenden von Systemknotenpools in AKS.

Automatische Skalierung für Systemknotenpools

Leitfaden für bewährte Methoden:

Konfigurieren Sie die Autoskalierung für Systemknotenpools, um mindeste und maximale Skalierungsgrenzwerte für den Knotenpool festzulegen.

In AKS Automatic wird die Kapazität des Systemknotenpools von AKS verwaltet. Verwenden Sie in AKS Standard die AutoScaler-Konfiguration, damit der Systemknotenpool immer skaliert werden kann, um die Anforderungen von System pods zu erfüllen.

Verwenden Sie die Autoskalierung für Knotenpools, um die mindesten und maximalen Skalierungsgrenzwerte für den Knotenpool zu konfigurieren. Der Systemknotenpool sollte immer skaliert werden können, um die Anforderungen von Systempods zu erfüllen. Wenn der Systemknotenpool nicht skaliert werden kann, läuft der Cluster aus Ressourcen, um die Planung, Skalierung und Lastenausgleich zu verwalten, was zu einem nicht reagierenden Cluster führen kann.

Weitere Informationen finden Sie unter Verwenden der Cluster-Autoskalierung auf Knotenpools.

Mindestens zwei Knoten pro Systemknotenpool

Leitfaden für bewährte Methoden:

Stellen Sie sicher, dass Systemknotenpools mindestens zwei Knoten aufweisen, um die Resilienz gegen Fixierungs-/Upgradeszenarien sicherzustellen, was dazu führen kann, dass Knoten neu gestartet oder heruntergefahren werden.

In AKS Standard sollten Systemknotenpools mindestens zwei Knoten aufweisen, um die Resilienz bei Neustart- oder Upgradeereignissen zu verbessern. In AKS Automatic wird die Ausfallsicherheit des Systemknotenpools vom Dienst verwaltet, der Workloadentwurf sollte jedoch dennoch davon ausgehen, dass Systemkomponenten im Rahmen von Plattformvorgängen aktualisiert oder verschoben werden können.

Systemknotenpools werden verwendet, um Systempods auszuführen, z. B. kube-proxy, coredns und das Azure CNI-Plug-In. Wir empfehlen, sicherzustellen, dass Systemknotenpools mindestens zwei Knoten haben, um die Ausfallsicherheit gegenüber Einfrierungs- und Upgradeszenarien zu gewährleisten, die dazu führen können, dass Knoten neu gestartet oder heruntergefahren werden. Weitere Informationen finden Sie unter Verwalten von Systemknotenpools in AKS.

Konfigurationsaktualisierungen für Knotenpools

Die Zuständigkeit für das Upgrade variiert je nach Clustermodus:

• AKS Automatic: Cluster-Upgrades verwenden standardmäßig den Stable-Kanal, und Upgrades der Betriebssystemimages der Knoten verwenden standardmäßig den NodeImage-Kanal. Der Schwerpunkt des Betreibers liegt auf der Betriebsbereitschaft für Arbeitslasten, Kontrollen zur Minimierung von Unterbrechungen, Wartungsplänen und der Validierung einer sicheren Einführung.
• AKS Standard: Operatoren konfigurieren explizit Upgradekanäle und Knotenpooleinstellungen wie maxSurge und maxUnavailable.

Verwendung maxSurge für Knotenpool-Aktualisierungen

Leitfaden für bewährte Methoden:

Konfigurieren Sie die maxSurge Einstellung für Knotenpoolupgrades, um die Zuverlässigkeit zu verbessern und Ausfallzeiten während des Upgradevorgangs zu minimieren.

Die maxSurge Einstellung gibt die maximale Anzahl zusätzlicher Knoten an, die während eines Upgrades erstellt werden können. Dadurch wird sichergestellt, dass neue Knoten bereitgestellt und bereit sind, bevor alte Knoten entwässert und entfernt werden, wodurch das Risiko von Anwendungsausfallzeiten verringert wird.

Der folgende Azure CLI Befehl legt z. B. maxSurge auf 1 für einen Knotenpool fest:

az aks nodepool update \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name myNodePool \
  --max-surge 1

Durch die Konfiguration maxSurgekönnen Sie sicherstellen, dass Upgrades schneller ausgeführt werden, während die Anwendungsverfügbarkeit beibehalten wird.

Weitere Informationen finden Sie unter Upgrade von Knotenpools in AKS.

Verwendung maxUnavailable für Knotenpool-Aktualisierungen

Leitfaden für bewährte Methoden:

Konfigurieren Sie die maxUnavailable Einstellung für Knotenpoolupgrades, um die Anwendungsverfügbarkeit bei Upgradevorgängen sicherzustellen.

Die maxUnavailable Einstellung gibt die maximale Anzahl von Knoten an, die während eines Upgrades nicht verfügbar sein können. Dadurch wird sichergestellt, dass ein Teil des Knotenpools betriebsbereit bleibt, während Knoten aktualisiert werden.

Der folgende Azure CLI Befehl legt z. B. maxUnavailable auf 1 für einen Knotenpool fest:

az aks nodepool update \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name myNodePool \
  --max-unavailable 1

Durch die Konfiguration maxUnavailablekönnen Sie die Auswirkungen von Upgrades auf Ihre Workloads steuern und sicherstellen, dass genügend Ressourcen während des Prozesses verfügbar bleiben.

Weitere Informationen finden Sie unter Upgrade von Knotenpools in AKS.

Beschleunigter Netzwerkbetrieb

Leitfaden für bewährte Methoden:

Verwenden Sie beschleunigte Netzwerke, um eine geringere Latenz, verringerte Jitter- und verringerte CPU-Auslastung auf Ihren virtuellen Computern bereitzustellen.

Der beschleunigte Netzwerkbetrieb ermöglicht Single-Root-I/O-Virtualisierung (SR-IOV) auf unterstützten VM-Typen und verbessert so die Netzwerkleistung erheblich.

Das folgende Diagramm veranschaulicht, wie zwei VMs mit und ohne beschleunigten Netzwerkbetrieb kommunizieren:

Weitere Informationen finden Sie in der Übersicht über beschleunigte Netzwerke.

Imageversionen

Leitfaden für bewährte Methoden:

Bilder sollten das Tag latestnicht verwenden.

Containerimagetags

Die Verwendung des Tags latest für Containerbilder kann zu unvorhersehbarem Verhalten führen und macht es schwierig, zu verfolgen, welche Version des Bildes in Ihrem Cluster ausgeführt wird. Sie können diese Risiken minimieren, indem Sie Überprüfungs- und Wartungstools zur Build- und Laufzeit in Ihre Container integrieren und ausführen. Weitere Informationen finden Sie unter Bewährte Methoden für die Containerbildverwaltung in AKS.

Upgrades für Knotenimages

Das Verhalten beim Upgrade des Knoten-Images unterscheidet sich je nach Clustermodus:

• AKS Automatic: Node OS-Imageupgrades werden über den NodeImage-Kanal vorkonfiguriert.
• AKS Standard: Operatoren wählen die manuelle Verwaltung oder einen Kanal für automatische Upgrades aus.

AKS stellt mehrere automatische Upgradekanäle für Knoten-Betriebssystembildupgrades bereit. Sie können diese Kanäle verwenden, um die Anzeigedauer von Upgrades zu steuern. Wir empfehlen, diesen automatischen Upgrade-Kanälen beizutreten, um sicherzustellen, dass Ihre Knoten die neuesten Sicherheitspatches und -updates ausführen. Weitere Informationen finden Sie unter Betriebssystembilder für das automatische Upgrade in AKS.

Standard-Preisstufe für Produktionsworkloads

Leitfaden für bewährte Methoden:

Verwenden Sie die Standard-Preisstufe für Produktarbeitslasten für höhere Clusterzuverlässigkeit und Ressourcen, Unterstützung für bis zu 5.000 Knoten in einem Cluster und standardmäßig aktivierte SLA für Uptime. Wenn Sie LTS benötigen, sollten Sie die Premium-Ebene verwenden.

Die Standardebene für Azure Kubernetes Service (AKS) bietet eine finanziell gesicherte 99,9% Uptime service-Level Agreement (SLA) für Ihre Produktionsworkloads. Die Standardebene bietet außerdem eine größere Clusterzuverlässigkeit und Ressourcen, Unterstützung für bis zu 5.000 Knoten in einem Cluster und standardmäßig aktivierte SLA für Uptime. Weitere Informationen finden Sie unter Preisstufen für die AKS-Clusterverwaltung.

Hinweis für den Clustermodus:

• AKS Automatic ist mit der Standardebene, der Uptime-SLA und der SLA für die Pod-Bereitschaft vorkonfiguriert.
• AKS Standard ist standardmäßig auf "Kostenlose Stufe" festgelegt, es sei denn, Sie wählen "Standard" oder "Premium" explizit aus.

LocalDNS für DNS-Zuverlässigkeit

Leitfaden für bewährte Methoden:

Aktivieren Sie LocalDNS in Ihren Knotenpools, um die Zuverlässigkeit der DNS-Auflösung zu verbessern und die Dienstkonnektivität während vorübergehender DNS-Ausfälle aufrechtzuerhalten.

LocalDNS stellt einen DNS-Proxy auf jedem AKS-Knoten bereit und stellt eine niedrige Latenz, robuste DNS-Auflösung bereit. Durch das lokale Auflösen von Abfragen reduziert LocalDNS Ihre Abhängigkeit von zentralisierten CoreDNS-Pods und vermeidet conntrack die Tabellenausschöpfung, was eine häufige Ursache für verworfene DNS-Abfragen in Umgebungen mit hohem Durchsatz ist. LocalDNS unterstützt auch die Bereitstellung veralteter zwischengespeicherter Antworten für eine konfigurierbare Dauer, wenn upstream-DNS nicht verfügbar ist, wodurch die Pod-Konnektivität während Unterbrechungen beibehalten wird. Konfigurationsanweisungen und bewährte Methoden finden Sie unter Konfigurieren von LocalDNS in AKS.

Hinweis für den Clustermodus:

• AKS Automatic: LocalDNS ist vorkonfiguriert.
• AKS Standard: LocalDNS ist optional und muss explizit aktiviert werden.

Azure CNI für dynamische IP-Zuordnung

Leitfaden für bewährte Methoden:

Konfigurieren Sie Azure CNI für die dynamische IP-Zuordnung für eine bessere IP-Auslastung und um die IP-Ausschöpfung für AKS-Cluster zu verhindern.

Für AKS Standard trägt Azure dynamische CNI IP-Zuordnung dazu bei, die IP-Auslastung zu verbessern und die IP-Erschöpfung zu verhindern. Für AKS Automatic wird standardmäßig ein verwaltetes virtuelles Netzwerk mit Azure CNI Overlay auf Basis von Cilium verwendet; in unterstützten Szenarien sind optional benutzerdefinierte Konfigurationen für virtuelle Netzwerke möglich.

Die dynamische IP-Zuordnungsfunktion in Azure CNI weist Pod-IPs von einem subnetz getrennt vom Subnetz zu, das den AKS-Cluster hostet und bietet die folgenden Vorteile:

• Bessere Auslastung von IP-Adressen: IP-Adressen werden Clusterpods dynamisch aus dem Podsubnetz zugeordnet. Dies führt zu einer besseren Auslastung der IP-Adressen im Cluster im Vergleich zur herkömmlichen CNI-Lösung, bei der die IP-Adressen für jeden Knoten statisch zugeordnet werden.
• Skalierbar und flexibel: Knoten- und Podsubnetze können unabhängig voneinander skaliert werden. Ein einzelnes Podsubnetz kann für mehrere Knotenpools eines Clusters oder mehrere AKS-Cluster im selben VNET freigegeben werden. Sie können auch ein separates Podsubnetz für einen Knotenpool konfigurieren.
• Hohe Leistung: Da Pods virtuelle Netzwerk-IPs zugewiesen werden, verfügen sie über direkte Konnektivität zu anderen Cluster-Pods und Ressourcen im VNet. Die Lösung unterstützt selbst größte Cluster ohne Leistungseinbußen.
• Separate VNET-Richtlinien für Pods: Da für Pods ein separates Subnetz besteht, können Sie auch separate VNET-Richtlinien konfigurieren, die von den Knotenrichtlinien abweichen. Dies ermöglicht viele nützliche Szenarien, z. B. das Zulassen der Internetverbindung nur für Pods und nicht für Knoten, das Beheben der Quell-IP für Pod in einem Knotenpool mithilfe einer Azure NAT Gateway und die Verwendung von NSGs zum Filtern des Datenverkehrs zwischen Knotenpools.
• Kubernetes-Netzwerkrichtlinien: Sowohl die Azure Netzwerkrichtlinien als auch Calico arbeiten mit dieser Lösung zusammen.

Weitere Informationen finden Sie unter Configure Azure CNI-Netzwerk für die dynamische Zuweisung von IPs und erweiterter Subnetzunterstützung.

v5 SKU-VMs

Leitfaden für bewährte Methoden:

Verwenden Sie v5 VM-SKUs für eine verbesserte Leistung während und nach Updates, weniger Gesamtwirkungen und eine zuverlässigere Verbindung für Ihre Anwendungen.

Verwenden Sie für Knotenpools in AKS v5-SKU-VMs mit kurzlebigen Betriebssystemdatenträgern, um ausreichende Computeressourcen für Kube-System-Pods bereitzustellen. Weitere Informationen finden Sie unter Bewährte Methoden im Zusammenhang mit der Leistung und Skalierung großer Workloads in AKS.

Keine VMs der B-Serie verwenden

Leitfaden für bewährte Methoden:

Verwenden Sie keine VMs der B-Serie für AKS-Cluster, da sie eine geringe Leistung aufweisen und nicht gut mit AKS funktionieren.

VMs der B-Serie weisen eine geringe Leistung auf und funktionieren nicht gut mit AKS. Stattdessen empfehlen wir die Verwendung von v5 SKU VMs.

Premium-Datenträger

Leitfaden für bewährte Methoden:

Verwenden Sie Premium-Datenträger, um eine Verfügbarkeit von 99,9 % auf einem virtuellen Computer (VM) zu erzielen.

Azure Premium-Datenträger bieten eine konsistente Festplattenlatenz von unter einer Millisekunde und durchweg hohe IOPS. Premium-Datenträger sind für VMs mit geringer Latenz, hoher Leistung und konsistenter Datenträgerleistung ausgelegt.

Das folgende Beispiel-YAML-Manifest zeigt eine Speicherklassendefinition für einen Premium-Datenträger:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
   name: premium2-disk-sc
parameters:
   cachingMode: None
   skuName: PremiumV2_LRS
   DiskIOPSReadWrite: "4000"
   DiskMBpsReadWrite: "1000"
provisioner: disk.csi.azure.com
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true

Weitere Informationen finden Sie unter Use Azure Premium SSD v2 disks on AKS.

Containereinblicke

Leitfaden für bewährte Methoden:

Aktivieren Sie Containererkenntnisse, um die Leistung Ihrer containerisierten Anwendungen zu überwachen und zu diagnostizieren.

Container Insights ist ein Feature von Azure Monitor, das Containerprotokolle von AKS sammelt und analysiert. Sie können die gesammelten Daten mit einer Sammlung von Ansichten und vordefinierten Arbeitsmappen analysieren.

Hinweis für den Clustermodus:

• AKS Automatic: Container Insights ist standardmäßig in unterstützten Azure CLI- und Azure Portal-Erstellungsflüssen aktiviert.
• AKS Standard: Container Insights ist optional und explizit aktiviert.

Sie können die Container Insights-Überwachung auf Ihrem AKS-Cluster mithilfe verschiedener Methoden aktivieren. Das folgende Beispiel zeigt, wie Sie die Container Insights-Überwachung auf einem vorhandenen AKS Standard-Cluster mithilfe der Azure CLI aktivieren:

az aks enable-addons -a monitoring --name myAKSCluster --resource-group myResourceGroup

Weitere Informationen finden Sie unter Aktivieren der Überwachung für Kubernetes-Cluster.

Azure Policy

Leitfaden für bewährte Methoden:

Wenden Sie Sicherheits- und Complianceanforderungen für Ihre AKS-Cluster mithilfe von Azure Policy an und erzwingen Sie sie.

Sie können integrierte Sicherheitsrichtlinien für Ihre AKS-Cluster mithilfe von Azure Policy anwenden und erzwingen. Azure Policy hilft dabei, organisatorische Standards zu erzwingen und die Compliance im großen Maßstab zu bewerten. Nachdem Sie das Azure Policy-Add-On für AKS installiert haben, können Sie einzelne Richtliniendefinitionen oder Gruppen von Richtliniendefinitionen anwenden, die als Initiativen bezeichnet werden, auf Ihre Cluster.

Hinweis für den Clustermodus:

• AKS Automatic: Bereitstellungsschutzmaßnahmen und grundlegende Pod-Sicherheitsstandards sind im Erzwingungsmodus vorkonfiguriert.
• AKS Standard: Azure Policy- und Bereitstellungsschutzmechanismen sind optional und erfordern eine explizite Konfiguration.

Weitere Informationen finden Sie unter Secure your AKS clusters with Azure Policy.

Verwandte Inhalte

Dieser Artikel befasst sich mit bewährten Methoden für die Bereitstellung und Clustersicherheit für Azure Kubernetes Service (AKS) Cluster. Weitere Informationen zu verwandten Themen finden Sie in den folgenden Artikeln:

• Was ist AKS Automatic?
• Übersicht über hohe Verfügbarkeit und Notfallwiederherstellung für AKS
• Ausführen von AKS-Clustern im großen Maßstab
• Baselinearchitektur für einen AKS-Cluster