Metodtips för distribution och klustertillförlitlighet för Azure Kubernetes Service (AKS)
Den här artikeln innehåller metodtips för klustertillförlitlighet som implementeras både på distributions- och klusternivå för dina Azure Kubernetes Service-arbetsbelastningar (AKS). Artikeln är avsedd för klusteroperatörer och utvecklare som ansvarar för att distribuera och hantera program i AKS.
Metodtipsen i den här artikeln är indelat i följande kategorier:
Metodtips på distributionsnivå
Följande metodtips på distributionsnivå hjälper dig att säkerställa hög tillgänglighet och tillförlitlighet för dina AKS-arbetsbelastningar. Dessa metodtips är lokala konfigurationer som du kan implementera i YAML-filerna för dina poddar och distributioner.
Kommentar
Se till att du implementerar dessa metodtips varje gång du distribuerar en uppdatering till ditt program. Annars kan det uppstå problem med programmets tillgänglighet och tillförlitlighet, till exempel oavsiktliga programavbrott.
Budgetar för poddstörningar (PDB)
Vägledning för bästa praxis
Använd POD-avbrottsbudgetar (PDB) för att säkerställa att ett minsta antal poddar förblir tillgängliga under frivilliga avbrott, till exempel uppgraderingsåtgärder eller oavsiktliga poddborttagningar.
Med budgetar för poddstörningar (PDB) kan du definiera hur distributioner eller replikuppsättningar svarar vid frivilliga avbrott, till exempel uppgraderingsåtgärder eller oavsiktliga borttagningar av poddar. Med hjälp av PDF-filer kan du definiera ett minsta eller högsta antal otillgängliga resurser. PDB:er påverkar endast borttagnings-API:et för frivilliga störningar.
Anta till exempel att du måste utföra en klusteruppgradering och redan har definierat en PDB. Innan du utför klusteruppgradering ser Kubernetes-schemaläggaren till att det minsta antalet poddar som definierats i PDB är tillgängliga. Om uppgraderingen skulle leda till att antalet tillgängliga poddar hamnar under det minimum som definierats i PDF-filerna schemalägger schemaläggaren extra poddar på andra noder innan uppgraderingen kan fortsätta. Om du inte anger ett PDB har schemaläggaren inga begränsningar för antalet poddar som kan vara otillgängliga under uppgraderingen, vilket kan leda till brist på resurser och potentiella klusteravbrott.
I följande exempel på PDB-definitionsfilen minAvailable anger fältet det minsta antal poddar som måste vara tillgängliga under frivilliga avbrott. Värdet kan vara ett absolut tal (till exempel 3) eller en procentandel av det önskade antalet poddar (till exempel 10 %).
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
Mer information finns i Planera för tillgänglighet med hjälp av PDF-filer och Ange en avbrottsbudget för ditt program.
Processor- och minnesgränser för poddar
Vägledning för bästa praxis
Ange poddernas processor- och minnesgränser för alla poddar för att säkerställa att poddar inte förbrukar alla resurser på en nod och för att ge skydd vid tjänsthot, till exempel DDoS-attacker.
Cpu- och minnesgränser för poddar definierar den maximala mängd cpu och minne som en podd kan använda. När en podd överskrider sina definierade gränser markeras den för borttagning. Mer information finns i CPU-resursenheter i Kubernetes - och Minnesresursenheter i Kubernetes.
Genom att ange cpu- och minnesgränser kan du upprätthålla nodhälsan och minimera påverkan på andra poddar på noden. Undvik att ange en poddgräns som är högre än vad noderna kan stödja. Varje AKS-nod reserverar en viss mängd cpu och minne för kubernetes-kärnkomponenterna. Om du anger en poddgräns som är högre än vad noden kan stödja kan programmet försöka använda för många resurser och påverka andra poddar negativt på noden. Klusteradministratörer måste ange resurskvoter för ett namnområde som kräver att resursbegäranden och gränser anges. Mer information finns i Framtvinga resurskvoter i AKS.
I följande exempel på podddefinitionsfilen resources anger avsnittet cpu- och minnesgränserna för podden:
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
Dricks
Du kan använda kubectl describe node kommandot för att visa processor- och minneskapaciteten för dina noder, som du ser i följande exempel:
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
Mer information finns i Tilldela CPU-resurser till containrar och poddar och Tilldela minnesresurser till containrar och poddar.
Förstoppade krokar
Vägledning för bästa praxis
Använd i tillämpliga fall förstoppade krokar för att säkerställa att en container avslutas korrekt.
En PreStop hook anropas omedelbart innan en container avslutas på grund av en API-begäran eller hanteringshändelse, till exempel preemption, resurskonkurrens eller ett liveness-/startavsökningsfel. Ett anrop till kroken PreStop misslyckas om containern redan är i ett avslutat eller slutfört tillstånd, och kroken måste slutföras innan TERM-signalen för att stoppa containern skickas. Nedräkningen av poddens respitperiod för avslutning börjar innan kroken PreStop körs, så containern avslutas så småningom inom respitperioden för uppsägning.
I följande exempel visar podddefinitionsfilen hur du använder en PreStop krok för att säkerställa en korrekt avslutning av en container:
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"]
Mer information finns i Krokar för containerlivscykel och Avslutning av poddar.
maxUnavailable
Vägledning för bästa praxis
Definiera det maximala antalet poddar som kan vara otillgängliga under en löpande uppdatering med hjälp av fältet i distributionen
maxUnavailableför att säkerställa att ett minsta antal poddar förblir tillgängliga under uppgraderingen.
Fältet maxUnavailable anger det maximala antalet poddar som kan vara otillgängliga under uppdateringsprocessen. Värdet kan vara ett absolut tal (till exempel 3) eller en procentandel av det önskade antalet poddar (till exempel 10 %). maxUnavailable gäller för borttagnings-API:et, som används under löpande uppdateringar.
Följande exempel på distributionsmanifestet maxAvailable använder fältet för att ange det maximala antalet poddar som kan vara otillgängliga under uppdateringsprocessen:
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
Mer information finns i Maximalt otillgängligt.
Spridningsbegränsningar för poddtopologi
Vägledning för bästa praxis
Använd begränsningar för poddtopologispridning för att säkerställa att poddar sprids över olika noder eller zoner för att förbättra tillgängligheten och tillförlitligheten.
Du kan använda begränsningar för poddtopologispridning för att styra hur poddar sprids över klustret baserat på nodernas topologi och sprida poddar över olika noder eller zoner för att förbättra tillgängligheten och tillförlitligheten.
I följande exempel visar podddefinitionsfilen hur du använder fältet topologySpreadConstraints för att sprida poddar över olika noder:
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
Mer information finns i Begränsningar för spridning av poddtopologi.
Beredskap, livskraft och startavsökningar
Vägledning för bästa praxis
Konfigurera beredskap, liveness och startavsökningar när det är tillämpligt för att förbättra återhämtning vid hög belastning och lägre omstarter av containrar.
Beredskapsavsökningar
I Kubernetes använder kubelet beredskapsavsökningar för att veta när en container är redo att börja acceptera trafik. En podd anses vara klar när alla dess containrar är klara. När en podd inte är klar tas den bort från tjänstens lastbalanserare. Mer information finns i Beredskapsavsökningar i Kubernetes.
Följande exempel på podddefinitionsfilen visar en konfiguration av beredskapsavsökning:
readinessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
Mer information finns i Konfigurera beredskapsavsökningar.
Liveness-avsökningar
I Kubernetes använder kubelet liveness-avsökningar för att veta när en container ska startas om. Om en container misslyckas med sin liveness-avsökning startas containern om. Mer information finns i Liveness-avsökningar i Kubernetes.
Följande exempel på en podddefinitionsfil visar en konfiguration av liveness-avsökning:
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
En annan typ av liveness-avsökning använder en HTTP GET-begäran. I följande exempel på podddefinitionsfilen visas en konfiguration för HTTP GET-begärandeavsökning:
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
Mer information finns i Konfigurera liveness-avsökningar och Definiera en HTTP-begäran för liveness.
Startavsökningar
I Kubernetes använder kubelet startavsökningar för att veta när ett containerprogram har startats. När du konfigurerar en startavsökning startar inte beredskaps- och liveness-avsökningarna förrän startavsökningen lyckas, vilket säkerställer att beredskaps- och livenessavsökningarna inte stör programstarten. Mer information finns i Startavsökningar i Kubernetes.
Följande exempel på en podddefinitionsfil visar en konfiguration av startavsökning:
startupProbe:
httpGet:
path: /healthz
port: 8080
failureThreshold: 30
periodSeconds: 10
Program med flera repliker
Vägledning för bästa praxis
Distribuera minst två repliker av ditt program för att säkerställa hög tillgänglighet och återhämtning i nod-down-scenarier.
I Kubernetes kan du använda fältet replicas i distributionen för att ange hur många poddar du vill köra. Om du kör flera instanser av ditt program kan du säkerställa hög tillgänglighet och återhämtning i scenarier med nod-down. Om du har aktiverat tillgänglighetszoner kan du använda fältet replicas för att ange hur många poddar du vill köra i flera tillgänglighetszoner.
Följande exempel på podddefinitionsfilen visar hur du använder fältet replicas för att ange antalet poddar som du vill köra:
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
Mer information finns i Rekommenderad aktiv-aktiv lösning för hög tillgänglighet för AKS och repliker i Distributionsspecifikationer.
Metodtips för kluster- och nodpoolnivå
Följande metodtips på kluster- och nodpoolnivå hjälper dig att säkerställa hög tillgänglighet och tillförlitlighet för dina AKS-kluster. Du kan implementera dessa metodtips när du skapar eller uppdaterar dina AKS-kluster.
Tillgänglighetszoner
Vägledning för bästa praxis
Använd flera tillgänglighetszoner när du skapar ett AKS-kluster för att säkerställa hög tillgänglighet i scenarier med zon ned. Tänk på att du inte kan ändra konfigurationen för tillgänglighetszonen när du har skapat klustret.
Tillgänglighetszoner är avgränsade grupper av datacenter i en region. Dessa zoner är tillräckligt nära för att ha anslutningar med låg latens till varandra, men tillräckligt långt ifrån varandra för att minska sannolikheten för att mer än en zon påverkas av lokala avbrott eller väder. Med hjälp av tillgänglighetszoner kan dina data förbli synkroniserade och tillgängliga i scenarier med zon ned. Mer information finns i Köra i flera zoner.
Autoskalning av kluster
Vägledning för bästa praxis
Använd autoskalning av kluster för att säkerställa att klustret kan hantera ökad belastning och minska kostnaderna vid låg belastning.
Om du vill hänga med i programkraven i AKS kan du behöva justera antalet noder som kör dina arbetsbelastningar. Komponenten autoskalning av kluster söker efter poddar i klustret som inte kan schemaläggas på grund av resursbegränsningar. När autoskalning av kluster identifierar problem skalar den upp antalet noder i nodpoolen för att uppfylla programbehovet. Den kontrollerar också regelbundet noder på grund av brist på poddar som körs och skalar ned antalet noder efter behov. Mer information finns i Autoskalning av kluster i AKS.
Du kan använda parametern --enable-cluster-autoscaler när du skapar ett AKS-kluster för att aktivera klustrets autoskalning, som du ser i följande exempel:
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
Du kan också aktivera autoskalning av kluster i en befintlig nodpool och konfigurera mer detaljerad information om autoskalning av klustret genom att ändra standardvärdena i autoskalningsprofilen för hela klustret.
Mer information finns i Använda autoskalning av kluster i AKS.
Standard Load Balancer
Vägledning för bästa praxis
Använd Standard Load Balancer för att ge bättre tillförlitlighet och resurser, stöd för flera tillgänglighetszoner, HTTP-avsökningar och funktioner i flera datacenter.
I Azure är Standard Load Balancer SKU utformad för att vara utrustad för belastningsutjämning av nätverksskiktstrafik när hög prestanda och låg svarstid behövs. Standard Load Balancer dirigerar trafik inom och mellan regioner och till tillgänglighetszoner för hög återhämtning. Standard-SKU:n är den rekommenderade och standard-SKU:n som ska användas när du skapar ett AKS-kluster.
Viktigt!
Den 30 september 2025 dras Basic Load Balancer tillbaka. Mer information finns i det officiella meddelandet. Vi rekommenderar att du använder Standard Load Balancer för nya distributioner och uppgraderar befintliga distributioner till Standard Load Balancer. Mer information finns i Uppgradera från Basic Load Balancer.
I följande exempel visas ett LoadBalancer tjänstmanifest som använder Standard Load Balancer:
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
Mer information finns i Använda en standardlastbalanserare i AKS.
Dricks
Du kan också använda en ingressstyrenhet eller ett tjänstnät för att hantera nätverkstrafik, där varje alternativ ger olika funktioner.
Systemnodpooler
Använda dedikerade systemnodpooler
Vägledning för bästa praxis
Använd systemnodpooler för att säkerställa att inga andra användarprogram körs på samma noder, vilket kan orsaka resursbrist och påverka systempoddar.
Använd dedikerade systemnodpooler för att säkerställa att inget annat användarprogram körs på samma noder, vilket kan orsaka brist på resurser och potentiella klusteravbrott på grund av konkurrensförhållanden. Om du vill använda en dedikerad systemnodpool kan du använda CriticalAddonsOnly taint i systemnodpoolen. Mer information finns i Använda systemnodpooler i AKS.
Automatisk skalning för systemnodpooler
Vägledning för bästa praxis
Konfigurera autoskalning för systemnodpooler för att ange minsta och högsta skalningsgränser för nodpoolen.
Använd autoskalning på nodpooler för att konfigurera minsta och högsta skalningsgränser för nodpoolen. Systemnodpoolen ska alltid kunna skalas för att uppfylla kraven från systempoddar. Om systemnodpoolen inte kan skalas får klustret slut på resurser för att hantera schemaläggning, skalning och belastningsutjämning, vilket kan leda till ett kluster som inte svarar.
Mer information finns i Använda autoskalning av kluster i nodpooler.
Minst tre noder per systemnodpool
Vägledning för bästa praxis
Se till att systemnodpooler har minst tre noder för att säkerställa återhämtning mot scenarier med frysning/uppgradering, vilket kan leda till att noder startas om eller stängs av.
Systemnodpooler används för att köra systempoddar, till exempel kube-proxy, coredns och Azure CNI-plugin-programmet. Vi rekommenderar att du ser till att systemnodpooler har minst tre noder för att säkerställa återhämtning mot scenarier med frysning/uppgradering, vilket kan leda till att noder startas om eller stängs av. Mer information finns i Hantera systemnodpooler i AKS.
Accelererat nätverk
Vägledning för bästa praxis
Använd Accelererat nätverk för att ge lägre svarstid, minskad jitter och minskad CPU-användning på dina virtuella datorer.
Accelererat nätverk möjliggör enkel rot-I/O-virtualisering (SR-IOV) på virtuella datortyper som stöds, vilket avsevärt förbättrar nätverksprestandan.
Följande diagram visar hur två virtuella datorer kommunicerar med och utan accelererat nätverk:
Mer information finns i Översikt över accelererat nätverk.
Bildversioner
Vägledning för bästa praxis
Bilder bör inte använda taggen
latest.
Taggar för containeravbildningar
Att använda taggen latest för containeravbildningar kan leda till oförutsägbart beteende och gör det svårt att spåra vilken version av avbildningen som körs i klustret. Du kan minimera dessa risker genom att integrera och köra genomsöknings- och reparationsverktyg i dina containrar vid kompilering och körning. Mer information finns i Metodtips för hantering av containeravbildningar i AKS.
Uppgraderingar av nodbild
AKS tillhandahåller flera automatiska uppgraderingskanaler för nod-OS-avbildningsuppgraderingar. Du kan använda dessa kanaler för att styra tidpunkten för uppgraderingar. Vi rekommenderar att du ansluter dessa kanaler för automatisk uppgradering för att säkerställa att noderna kör de senaste säkerhetskorrigeringarna och uppdateringarna. Mer information finns i Automatisk uppgradering av nodoperativsystemavbildningar i AKS.
Standardnivå för produktionsarbetsbelastningar
Vägledning för bästa praxis
Använd standardnivån för produktarbetsbelastningar för större klustertillförlitlighet och resurser, stöd för upp till 5 000 noder i ett kluster och Serviceavtal för drifttid aktiverat som standard. Om du behöver LTS kan du överväga att använda Premium-nivån.
Standardnivån för Azure Kubernetes Service (AKS) tillhandahåller ett serviceavtal på 99,9 % drifttid (SLA) för dina produktionsarbetsbelastningar. Standardnivån ger också större klustertillförlitlighet och resurser, stöd för upp till 5 000 noder i ett kluster och serviceavtal för drifttid aktiverat som standard. Mer information finns i Prisnivåer för AKS-klusterhantering.
Azure CNI för dynamisk IP-allokering
Vägledning för bästa praxis
Konfigurera Azure CNI för dynamisk IP-allokering för bättre IP-användning och för att förhindra IP-överbelastning för AKS-kluster.
Funktionen för dynamisk IP-allokering i Azure CNI allokerar podd-IP-adresser från ett undernät som är separat från undernätet som är värd för AKS-klustret och erbjuder följande fördelar:
- Bättre IP-användning: IP-adresser allokeras dynamiskt till klusterpoddar från poddundernätet. Detta leder till bättre användning av IP-adresser i klustret jämfört med den traditionella CNI-lösningen, som utför statisk allokering av IP-adresser för varje nod.
- Skalbart och flexibelt: Nod- och poddundernät kan skalas separat. Ett enda poddundernät kan delas mellan flera nodpooler i ett kluster eller över flera AKS-kluster som distribueras i samma virtuella nätverk. Du kan också konfigurera ett separat poddundernät för en nodpool.
- Höga prestanda: Eftersom podden har tilldelats IP-adresser för virtuella nätverk har de direkt anslutning till andra klusterpoddar och resurser i det virtuella nätverket. Lösningen stöder mycket stora kluster utan försämrad prestanda.
- Separata VNet-principer för poddar: Eftersom poddar har ett separat undernät kan du konfigurera separata VNet-principer för dem som skiljer sig från nodprinciper. Detta möjliggör många användbara scenarier som att endast tillåta internetanslutning för poddar och inte för noder, åtgärda käll-IP för podden i en nodpool med hjälp av en Azure NAT Gateway och använda NSG:er för att filtrera trafik mellan nodpooler.
- Kubernetes-nätverksprinciper: Både Azure-nätverksprinciperna och Calico fungerar med den här lösningen.
Mer information finns i Konfigurera Azure CNI-nätverk för dynamisk allokering av IP-adresser och utökat undernätsstöd.
virtuella V5 SKU-datorer
Vägledning för bästa praxis
Använd virtuella V5-SKU:er för att få bättre prestanda under och efter uppdateringar, mindre övergripande påverkan och en mer tillförlitlig anslutning för dina program.
För nodpooler i AKS använder du virtuella V5 SKU-datorer med tillfälliga OS-diskar för att tillhandahålla tillräckligt med beräkningsresurser för kube-systempoddar. Mer information finns i Metodtips för prestanda och skalning av stora arbetsbelastningar i AKS.
Använd inte virtuella datorer i B-serien
Vägledning för bästa praxis
Använd inte virtuella datorer i B-serien för AKS-kluster eftersom de har låga prestanda och inte fungerar bra med AKS.
Virtuella datorer i B-serien har låga prestanda och fungerar inte bra med AKS. I stället rekommenderar vi att du använder virtuella V5 SKU-datorer.
Premium-diskar
Vägledning för bästa praxis
Använd Premium-diskar för att uppnå 99,9 % tillgänglighet på en virtuell dator (VM).
Azure Premium-diskar erbjuder en konsekvent disksvarstid på undermillisekunder och hög IOPS och hela tiden. Premium-diskar är utformade för att ge prestanda med låg svarstid, höga prestanda och konsekventa diskprestanda för virtuella datorer.
Följande YAML-exempelmanifest visar en definition av lagringsklassen för en Premium-disk:
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
Mer information finns i Använda Azure Premium SSD v2-diskar på AKS.
Containerinsikter
Vägledning för bästa praxis
Aktivera Container Insights för att övervaka och diagnostisera prestanda för dina containerbaserade program.
Container Insights är en funktion i Azure Monitor som samlar in och analyserar containerloggar från AKS. Du kan analysera insamlade data med en samling vyer och fördefinierade arbetsböcker.
Du kan aktivera Container Insights-övervakning på ditt AKS-kluster med hjälp av olika metoder. I följande exempel visas hur du aktiverar Container Insights-övervakning på ett befintligt kluster med hjälp av Azure CLI:
az aks enable-addons -a monitoring --name myAKSCluster --resource-group myResourceGroup
Mer information finns i Aktivera övervakning för Kubernetes-kluster.
Azure Policy
Vägledning för bästa praxis
Tillämpa och tillämpa säkerhets- och efterlevnadskrav för dina AKS-kluster med hjälp av Azure Policy.
Du kan tillämpa och tillämpa inbyggda säkerhetsprinciper på dina AKS-kluster med hjälp av Azure Policy. Azure Policy hjälper till att framtvinga organisationsstandarder och utvärdera efterlevnad i stor skala. När du har installerat Azure Policy-tillägget för AKS kan du använda enskilda principdefinitioner eller grupper av principdefinitioner som kallas initiativ för dina kluster.
Mer information finns i Skydda dina AKS-kluster med Azure Policy.
Nästa steg
Den här artikeln fokuserar på metodtips för distribution och klustertillförlitlighet för AKS-kluster (Azure Kubernetes Service). Mer metodtips finns i följande artiklar:
Azure Kubernetes Service