Bewährte Methoden zur Bereitstellung und Clustersicherheit für Azure Kubernetes Service (AKS)
Dieser Artikel enthält bewährte Methoden für die Clustersicherheit, die sowohl auf Bereitstellungs- als auch Clusterebene für Ihre Azure Kubernetes Service-Workloads (AKS) 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:
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.
Hinweis
Stellen Sie sicher, dass Sie diese bewährten Methoden jedes Mal implementieren, wenn Sie ein Update für Ihre Anwendung bereitstellen. Andernfalls treten möglicherweise Probleme mit der Verfügbarkeit und Zuverlässigkeit Ihrer Anwendung auf, z. B. unbeabsichtigte Ausfallzeiten der Anwendung.
Pod Disruption Budgets (PDBs)
Best Practices-Leitfaden
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 es 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.
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.
Pod CPU- und Speichergrenzwerte
Best Practices-Leitfaden
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.
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
Tipp
Sie können den Befehl kubectl describe node verwenden, um die CPU- und Arbeitsspeicherkapazität Ihrer Knoten anzuzeigen, wie im folgenden Beispiel gezeigt:
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.
Vorstopp-Hooks
Best Practices-Leitfaden
Verwenden Sie gegebenenfalls Vorstopp-Hooks, um eine ordnungsgemäße Beendigung eines Containers sicherzustellen.
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. Ein Aufruf des PreStop Hooks schlägt fehl, wenn sich der Container bereits in einem beendeten oder abgeschlossenen Zustand befindet, und der Hook muss abgeschlossen sein, bevor das TERM-Signal gesendet wird, um den Container zu beenden. Der Ablauffrist-Countdown des Pods beginnt, bevor der PreStop Hook ausgeführt wird, sodass der Container schließlich innerhalb der Nachfrist der Kündigung beendet wird.
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:
postStart:
exec:
command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
preStop:
exec:
command: ["/bin/sh","-c","nginx -s quit; while killall -0 nginx; do sleep 1; done"]
Weitere Informationen finden Sie unter Containerlebenszyklus-Hooks und Beendigung von Pods.
maxUnavailable
Best Practices-Leitfaden
Definieren Sie die maximale Anzahl von Pods, die während eines parallelen Updates nicht verfügbar sein können, indem Sie das Feld
maxUnavailablein Ihrer Bereitstellung verwenden, um sicherzustellen, dass während des Upgrades eine Mindestanzahl von Pods verfügbar bleibt.
Das Feld maxUnavailable gibt die maximale Anzahl von Pods an, die während des Update-Prozesses nicht verfügbar sein können. Der Wert kann eine absolute Zahl (z. B. 3) oder ein Prozentsatz der gewünschten Anzahl von Pods (z. B. 10 %) sein. maxUnavailable bezieht sich auf die Lösch-API, die während der parellelen Updates verwendet wird.
Im folgenden Beispielbereitstellungsmanifest wird das FeldmaxAvailable verwendet, um die maximale Anzahl von Pods festzulegen, die während des Update-Prozesses nicht verfügbar sein können:
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:
maxUnavailable: 1 # Maximum number of pods that can be unavailable during the upgrade
Weitere Informationen finden Sie unter Max Nicht verfügbar.
Beschränkungen der Pod-Topologieverteilung
Best Practices-Leitfaden
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.
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
Best Practices-Leitfaden
Konfigurieren Sie Bereitschafts-, Live- und Starttests, wenn sie anwendbar sind, um die Resilienz bei hohen Lasten und niedrigeren Containerneustarts zu verbessern.
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
Best Practices-Leitfaden
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. 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.
Verfügbarkeitszonen
Best Practices-Leitfaden
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.
Automatische Skalierung von Clustern
Best Practices-Leitfaden
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.
Sie können den Parameter --enable-cluster-autoscaler verwenden, wenn Sie einen AKS-Cluster erstellen, um die Cluster-Autoskalierung zu aktivieren, wie im folgenden Beispiel gezeigt:
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.
Load Balancer Standard
Best Practices-Leitfaden
Verwenden Sie den Load Balancer Standard, um mehr Zuverlässigkeit und Ressourcen, Unterstützung für mehrere Verfügbarkeitszonen, HTTP-Prüfpunkte und Funktionen in mehreren Rechenzentren bereitzustellen.
In Azure ist die Load Balancer Standard-SKU so konzipiert, dass sie für den Lastenausgleich von Netzwerkschichtdatenverkehr ausgestattet ist, 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.
Wichtig
Am 30. September 2025 wird Load Balancer im Tarif „Basic“ eingestellt. Weitere Informationen finden Sie in der offiziellen Ankündigung. Es wird empfohlen, den Load Balancer Standard für neue Bereitstellungen zu verwenden und vorhandene Bereitstellungen auf den Standard Load Balancer zu aktualisieren. Weitere Informationen finden Sie unter Upgrade von Basic Load Balancer.
Das folgende Beispiel zeigt ein LoadBalancer Dienstmanifest, das den 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.
Tipp
Sie können auch einen Eingangscontroller oder ein Dienstgittermodell zum Verwalten des Netzwerkdatenverkehrs verwenden, wobei jede Option verschiedene Features und Funktionen bereitstellt.
Systemknotenpools
Verwenden dedizierter Systemknotenpools
Best Practices-Leitfaden
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
Best Practices-Leitfaden
Konfigurieren Sie die Autoskalierung für Systemknotenpools, um mindeste und maximale Skalierungsgrenzwerte für den Knotenpool festzulegen.
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 drei Knoten pro Systemknotenpool
Best Practices-Leitfaden
Stellen Sie sicher, dass Systemknotenpools mindestens drei Knoten aufweisen, um die Resilienz gegen Fixierungs-/Upgradeszenarien sicherzustellen, was dazu führen kann, dass Knoten neu gestartet oder heruntergefahren werden.
Systemknotenpools werden verwendet, um Systempods auszuführen, z. B. kube-proxy, coredns und das Azure CNI-Plug-In. Es wird empfohlen, sicherzustellen, dass Systemknotenpools mindestens drei Knoten aufweisen, um die Resilienz gegen Fixierungs-/Upgradeszenarien sicherzustellen, was dazu führen kann, dass Knoten neu gestartet oder heruntergefahren werden. Weitere Informationen finden Sie unter Verwalten von Systemknotenpools in AKS.
Beschleunigter Netzwerkbetrieb
Best Practices-Leitfaden
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
Best Practices-Leitfaden
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
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.
Standardebene für Produktionsworkloads
Best Practices-Leitfaden
Verwenden Sie die Standardebene für Produktworkloads für eine 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 abgesicherte Service-Level-Vereinbarung (SLA) mit einer Verfügbarkeit von 99,9 % 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.
Azure CNI für dynamische IP-Zuordnung
Best Practices-Leitfaden
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.
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.
- Höchstleistung: Da Pods VNet-IP-Adressen zugewiesen sind, besteht eine direkte Verbindung zu anderen Clusterpods 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. Das ermöglicht viele nützliche Anwendungsfälle wie die Beschränkung der Internetkonnektivität auf Pods statt auf Knoten, das Korrigieren der Quell-IP für Pods in einem Knotenpool mithilfe einer Azure NAT Gateway-Instanz und den Einsatz von Netzwerksicherheitsgruppen, um Datenverkehr zwischen Knotenpools zu filtern.
- Kubernetes-Netzwerkrichtlinien: Sowohl die Azure-Netzwerkrichtlinien als auch Calico sind mit dieser Lösung kompatibel.
Weitere Informationen finden Sie unter Konfigurieren von Azure CNI-Netzwerken für die dynamische Zuteilung von IP-Adressen und erweiterte Subnetzunterstützung.
v5 SKU VMs
Best Practices-Leitfaden
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
Best Practices-Leitfaden
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
Best Practices-Leitfaden
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 Verwenden von Azure Premium SSD v2 Datenträgern auf AKS.
Container Insights
Best Practices-Leitfaden
Aktivieren Sie Containererkenntnisse, um die Leistung Ihrer containerisierten Anwendungen zu überwachen und zu diagnostizieren.
Container Insights ist eine Funktion von Azure Monitor, die Containerprotokolle von AKS sammelt und analysiert. Sie können die gesammelten Daten mit einer Sammlung von Ansichten und vordefinierten Arbeitsmappen analysieren.
Sie können die Container Insights-Überwachung auf Ihrem AKS-Cluster mithilfe verschiedener Methoden aktivieren. Das folgende Beispiel zeigt, wie Container Insights-Überwachung auf einem vorhandenen Cluster mithilfe der Azure CLI aktiviert wird:
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
Best Practices-Leitfaden
Wenden Sie Sicherheits- und Complianceanforderungen für Ihre AKS-Cluster mithilfe der Azure-Richtlinie an und erzwingen Sie diese.
Mit der Azure-Richtlinie können Sie integrierte Sicherheitsrichtlinien auf Ihre AKS-Cluster anwenden und durchsetzen. Azure Policy unterstützt Sie bei der Durchsetzung von Organisationsstandards und der Bewertung der Compliance im großen Stil. Nachdem Sie das Azure-Richtlinien-Add-on für AKS installiert haben, können Sie einzelne Richtliniendefinitionen oder Gruppen von Richtliniendefinitionen, sogenannte Initiativen, auf Ihre Cluster anwenden.
Weitere Informationen finden Sie unter Sichern Ihrer AKS-Cluster mit der Azure-Richtlinie.
Nächste Schritte
Dieser Artikel befasst sich mit bewährten Methoden für die Bereitstellung und Clustersicherheit für Azure Kubernetes Service (AKS)-Cluster. Weitere bewährte Methoden finden Sie in den folgenden Artikeln:
Azure Kubernetes Service